James Shanks wrote:
>
> 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.
>
Okay, check my logic here, please.
I'm going to make three rulesets, one for each collection that contains
things we need to notify operators of through email to a helpdesk alias
and page certain oncall personnel through email to their pagers.
I've created a prototype with modifications based on your suggestion
above. First, we our polling is as such, every 5 minutes with a 30sec.
timeout; no retries. This is to minimize network traffic and account
for possible network slowdown...basically we want to know that the
device is actually up--we don't care about speed of connectivity because
this is for off-hours purposes.
I've got the pizza as first node, then splitting to two trap nodes: one
for nv6000 Node Down and one for nv6000 Node Up. These both funnel into
a Reset on Match node which has one comparison: Attribute 1 (2, as you
said the hostname in a netview trap) equal to Attribute 2 (2, again, the
hostname) during a 10-minute interval. This should have the effect of
taking the results of two polls and comparing them in the event that a
node down is received: if the next is a node up, then wait for another
node down; otherwise forward the event to the next node.
The next node is a Query Database Collection which will check for a
match on Origin with the relevant collection for this ruleset (network
devices, unix/nt servers, mvs servers). This should forward only those
events coming from machines which are a part of the given collection. I
use Origin as the ID source in case $NVATTR_2, the hostname, doesn't
match the selection name (I'm assuming Origin will contain the selection
name from the database as the identifier for the trap originator). This
will flow into two Actions, one a mailx command sending a simple subject
line to the pager alias stating that $NVATTR_2 is down (unless there's a
nice variable for the Origin, in which case I'll use that), and the
other one a mailx command sending a simple subject line to our helpdesk
alias to let the operators know...just in case they haven't been doing
their scheduled netview monitor check.
Am I on the right track here?
--
Sean Aaron
UNIX System Administrator
University of California
Office of the President
|