James, I concur with
everything you said.
Like I said, I don’t
totally understand it but the ruleset author who reads this forum can give you
the details. I totally agree with your concerns about the trap being “lost” if
automation is recycled. However, I always felt that a) NetView should be
stable enough his doesn’t happen (true usually) and b) NetView should already
have a feature that eliminates the need for this.
Our approach is based
on the fact that our different groups all have different requirements (re:
insanity) so we had to accommodate all sorts of interesting down-wind
considerations. The script that executes uses the smartest name passed as a
parameter as a key to what notification processes to use. The last thing the
script does is use postemsg to forward the event to TEC.
Not necessarily
pretty, but it does work well.
The author of the
ruleset is the worst fantasy football manager I have ever
seen.
From:
owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com] On Behalf Of James Shanks
Sent: Wednesday, September 22, 2004 9:32
AM
To:
nv-l@lists.us.ibm.com
Subject: RE: [nv-l] Ruleset + up
event.
Mighty
complicated set of Reset-on-match and Pass-on-Match ruleset nodes back to
back. Not sure I follow it all.
But the key seems to be those
scripts at the end so far as I can see. Whatever happens, we pass them a
Node Down event originally and then later a matching Node Up. In between
we'll wait 3 minutes before sending the original Node Down, to see whether
this is a false alarm, and then we'll wait up to 144 hours (6 days) for the
matching Node Up. All of that is just to launch the appropriate
scripts. How do they work?
The
intervening razzle-dazzle of alternating Reset and Pass Nodes, the ones
with the 5-second wait intervals, seems to me to be some kind of timing
mechanism to guarantee that it will be possible to use the original Node Down
as the match criteria, for the much later Node Up. It delays the final
handling of the Node Down event so that there is time to save the Node
Up in the Pass-On-Match so that there will be something to match when the Node
Down is released. It's ingenious all right, and more than a little
unusual, as I don't recall seeing anything like it. Bet the original
developer would be surprised too.
But to my way of
thinking, this way has dependencies I don't care for. The biggest
dependency I see here is that if you have to stop and restart the daemons for
any reason, then the held events are lost. I'd prefer the setting
and querying of database fields myself, since you wouldn't be time or daemon
dependent. You could preserve continuity over a much longer time period
and you don't have to worry about keeping the daemons up, should you have to
recycle them for some other reason.
James Shanks
Level 3
Support for Tivoli NetView for UNIX and
Windows
Tivoli Software / IBM Software
Group
|
"Barr,
Scott" <Scott_Barr@csgsystems.com>
Sent by:
owner-nv-l@lists.us.ibm.com
09/22/2004 09:47
AM
|
|
To |
<nv-l@lists.us.ibm.com>
|
|
cc |
|
|
Subject |
RE: [nv-l]
Ruleset + up
event. |
|
Here is
a ruleset that does just what you need.
It’s got some extra
stuff in it because it processes a bunch of different groups node downs so
you’ll want to strip out the extra query smartsets and actions. Don’t try and
figure out how it works, I still don’t understand but a netview guru
helped me work it out and it works like 100 bucks.
1.
Accepts node up and
node down traps
2.
Holds the node down
for 3 minutes
3.
If the node up
happens, pass the node up trap
4.
If the node up trap
does not happen in 3 minutes, execute the notification script
From:
owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com] On Behalf Of James Shanks
Sent: Wednesday, September 22, 2004
8:20 AM
To:
nv-l@lists.us.ibm.com
Subject: Re: [nv-l] Ruleset + up
event.
What you see is what you
get, Tom.
If you want to pass a
Router Up event, then you have to do it explicitly. The logic you are
saying you want here is much more complicated than just a simple
reset-on-match. What you have just said is that you want the Router
Down held for just five minutes and then passed to TEC if no Router Up.
And then you want something to "remember" that you passed this Router
Down, and pass a matching Router up for time period much later. Well, a
simple ruleset cannot do that. So you have to design something else more
sophisticated.
When you design a custom
ruleset for TEC, you and the TEC guy have to work together. He can code
rules on his end, just as you can. I don't see why you cannot send all
Router Up events to TEC as harmless and let a TEC rule over there match them
to any open Router Downs, and if there are none them close them. Or let
the operator close them. If he sees them, then clearly there was no
match so they no longer matter, right?
If you have
to do this in NetView, then I think you'd have to do something like this.
You have to keep a record somewhere of Router Down events you sent to
TEC, and query that list when a Router Up comes in. One way them would
be create a file, add the router name to it when you send the event TEC (use
an action node for that), and then query it in an inline action script when
the Router Up comes in, and if there is a match, then delete the name from the
list and send the Router Up. An alternative would be to Set and Query
Database fields on the router objects in the database . You can create
your own field or use CorrState1 - 4. You set the field to indicate that
you sent the trap, then you could query it when the Router Up came in and take
action that way. Then clear the field. You get the idea, I'm
sure
James Shanks
Level
3 Support for Tivoli NetView for UNIX and
Windows
Tivoli Software / IBM Software
Group
|
Tom
Hallberg <gimli@hhcrew.tk>
Sent
by: owner-nv-l@lists.us.ibm.com
09/22/2004 03:41
AM
|
|
To |
nv-l@lists.us.ibm.com
|
|
cc |
|
|
Subject |
[nv-l] Ruleset +
up event. |
|
Hi
I got some
ruleset design problem. For the moment I got first a "Trap
Settings" (for
Router down events), then a "Inline Action" to check that
its one of the
routers I want to have status check on. After that I have a
"Reset on
Match" because I also take in Router up events so I can reset on
match
within 5 mins. But the problem is that if a router goes down, and if
it
have been down for more then 5 min then it will pass that down event
to
TEC. And let say now that the router when up again, so we got a Router
up
event. But that up event will not pass to our TEC. So are there
any
Templets that can handle the problem about sending onlye one up event
when
there have been a down event passed to TEC. Or do I have to make a
new
Inline Action to take care about that up event that comes after 5
min?
The TEC guy dont want to have all up events. Because the net is
quite big.
Thank you
//Tom