The trap variables will be parsed into environment variables which you can
access in your script. As for example, trap variable one will be accessible as
$NVATTR_1, var 2 as $NVATTR_2, and so on up to 50 or however many you have. In
addition such things as $NVA will give you the agent sending the trap and $NVE
the enterprise id. More information on these are given in the NetView
Administrator's Guide, Chapter 5. You can pass these or reference them
internally.
But notice here we are talking about trap variables. In a NetView trap, the
second variable is always the hostname, which is usually the selection name.
And the third variable of a NetView trap is the content that netmon sends, which
is the event description. But this correspondence is not guaranteed for other
sources. In MLM traps for example, the hostname is in variable nine. And
other vendors may not send one in a variable at all at all.
And now for a bit of my own opinion. I don't wish to offend you, but I
question the design of this ruleset. Under what conditions do you expect to get
2 Node Down traps in ten minutes? For that to happen you would have to get an
intervening Node Up (or Node Marginal), because netmon won't send a Node Down
unless that status has changed. So using the standard default polling cycle
of 5 minutes, in the first one, netmon's pings fail so he issues "Node Down".
He tries again in 5 minutes. This time let's assume they would work so you
would get Node Up. But then you would probably just miss the threshold window
in your ruleset even if the third cycle yielded a second Node Down.
You could fix this by either shortening the default polling cycle (which might
not be a good idea in your network performance-wise) or by lengthening the
threshold time. But even with the latter, I wonder what problem you will be
paging people for. Under what conditions does the interface go down and come
back and go down again? Are you trying to determine network congestion?
I think you might want to consider an alternate design, one which sends a page
if, after ten minutes no matching Node Up has arrived. You would do that with a
Reset-On-Match rather than a threshold. The Node Down is Input one, the Node Up
is Input 2, and the match is on attribute two, the hostname. You could of
course extend the reset period to wait longer, say 30 minutes, so that people
only get paged when there is no chance of things working out for themselves.
Do you follow me or am I missing something?
James Shanks
Tivoli (NetView for UNIX) L3 Support
Sean Aaron <sean.aaron AT UCOP DOT EDU> on 10/04/99 02:53:32 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L AT UCSBVM.UCSB DOT EDU>
To: NV-L AT UCSBVM.UCSB DOT EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: using a script in a ruleset.
I'm trying to build a grand overarching ruleset that checks for a node
down trap and if it gets two in a 10 minute period executes a script
that sends mail to a pager alias for the group responsible for the
machine. I've done everything up to the threshold; my question is "what
kind of output will be passed on to the action node (i.e. will there be
a $1, $2, etc. with $1 being selection name and $2 status?) so I can
write my script with a case statement of actions to take depending on
the selection name being this or that?"
The manual only states that the variables are preserved, but if the
variables exist in the ruleset, how would my shell script know what they
are?
--
Sean Aaron
UNIX System Administrator
University of California
Office of the President
|
