This sounds good, but I am wondering if it wouldn't work in my situation.
Since I am thresholding on more than one variable, if a node had two
different thresholds happen one after another, the second threshold would
reset the first threshold. So if router1 has a "cpu" threshold set, then
within 30 minutes router1 has an "input errors" threshold set, the reset on
match would see router1 twice within 30 minutes (from IBM_NV_DCOL_EV) and I
would never get notified.
Thanks for the help.
Jeff
-----Original Message-----
From: Boyles, Gary P [mailto:gary.p.boyles@intel.com]
Sent: Thursday, December 17, 1998 3:36 PM
To: 'jeff.singer@metricom.com'; 'nv-l@ucsbvm.ucsb.edu'
Subject: RE: Ruleset Help
Jeff,
Instead of using this methodology... why don't you set the re-arm
event to a proper value... (like say 85%), and then use the
"reset-on-match" rule.
Basic logic is this:
a) Use trap-setting icon to filter for threshold event, then use
"reset on match", with a timer of 30 minutes. What you'll
be checking for in the match... is the node-name.
b) Use trap-setting iocn to filter for the rearm event, then pipe
this into the 2nd leg of the "reset on match" logic.
Result Is:
a) If threshold occurs, without rearm, then the event gets passed
after the timer expires (30 minutes), and you'll get mail.
b) If threshold occurs, and rearm occurs within 30 minutes... then
nothing will happen (the reset occurred).
Just a thought.
Gary Boyles
-----Original Message-----
From: Jeff Singer [mailto:jsinger@RICOCHET.NET]
Sent: Thursday, December 17, 1998 10:20 AM
To: NV-L@UCSBVM.UCSB.EDU
Subject: Ruleset Help
Currently I am collecting certain mib variables off routers and
servers. I am collecting the information every 5 minutes. Additionally
I have set thresholds for some of these values as well. What I would
like to do is create a ruleset that will send me an email when a
mibvalue is at a certain level for a specified period of time. So, for
example if CPU utilization is over 90% for 30 minutes. I have not been
able to successfully create this ruleset and am now turning to you for
help.
Here is what I've tried so far, but this isn't working. This ruleset is
supposed send an email when a router's CPU is over 90% for 30 minutes:
event stream -> trap settings (set for netview6000 enterprise,
IBM_NVDCOL_EV event) ->
event attribute (attribute: 4 equal to value: .1.3.6.1.4.1.9.2.1.58) ->
thresholds (after, count: 5, Time Period:30) -> action (echo "$2: $3" |
mailx -s "Threshold Exceeded" mailme@myemail.com) -> forward
A few questions and comments:
- In the event attribute node, attribute 4 in IBM_NVDCOL_EV is the mib
variable being collected.
- The reason I sent count to 5 is, since I am collecting on 5 minute
intervals, if the threshold is met every collection interval and an
event is sent from IBM_NVDCOL_EV, then after 5 would be approximately 30
minutes.
- While testing the action node, I got it to send me an email, but the
$2 and $3 were not passed (all I got was a : with nothing on either
side). I know this command works because it is virtually the same
command I use in the event configuration to send me messages when a
IBM_NVNDWN_EV happens. With IBM_NV_DCOL_EV, $2 is the node name or IP
address and $3 is the event description. Why didn't these get sent
properly ?
- In the thresholds node, what is the "Threshold by attribute 1...n "
supposed to do. I though I would be able to make a comparison with this
value but there is no place to input a value to compare against. So if
I set attribute 1 to, say, source, what is this doing ? The
documentation doesn't provide much help. All the documentation says is
that it "Specifies the first attribute in the trap to be used." Used
how ?
Is this what I should be doing to get my intended results ? One thing I
realized is, that in order to get a IBM_NV_DCOL_EV event to be sent every
time the threshold is exceededd, I need to set the re-arm event higher than
the threshold event. Otherwise, if the threshold doesn't go below the rearm
event for the 5 polling periods, only one event will be sent.
Sorry if this is long winded and I pointed out obvious things, but the
way the ruleset nodes work are not too intuitive.
Thanks
Jeff
*************************************************************
* Jeffrey H. Singer Phone: 408-399-8257 *
* Network Engineer Email: jeff.singer@metricom.com *
* Metricom, Inc. Web: http://www.metricom.com *
*************************************************************
|