Famous? You are talking about the ruleset sampcorrNuNd.rs, correct? That
ruleset will not work with TEC. It uses special features of nvevents to
do what it does.
It has an initial Event Stream node set to PASS, which will send all events
in the event stream to the target destination. Up to this point is it like
forwardall.rs. Then it selects two events, Node Up and Node Down, using
Trap Settings blocks. Node Down is set to be input 1 to a Pass-on-Match,
so it is held there. The Node Up is input 2. When the Node Up has a
matching hostname, the Node Down is sent on to the Resolve block, which
adds a flag to the event to tell nvevents to remove all copies it has of
similar events which match this one. And nvevents then removes it (them)
from the screen(s). The ability of nvevents to remove an event when it
gets a second copy of it with that removal flag included is what enables
this ruleset to work.
But TEC has no such mechanism to remove events once sent; you have to close
them instead. It knows nothing about the special flag that nvevents used,
and in fact never even saw it.
But it should not be necessary to send another event to close the Node Down
and remove it from the operator's console in TEC. The TEC rules that
Tivoli provides for NetView in TEC do that closure automatically, don't
they? Node Down events close and go off the screen automatically when the
matching Node Up arrives, or so I thought. If that's not happening, then
perhaps you are using your own rules in TEC instead.
If you want to stop the Node Downs from being sent in the first place,
you'd need to rewrite that ruleset completely. The initial node would have
to be set to BLOCK, so that only events which you specifically forward go
to the final destination. And then instead of a Pass-on-Match you'd need a
Reset-on-Match so that the Node Down was not sent if the matching Node Up
arrives in the allotted time period. And the Resolve would be changed to a
Forward to send those unmatched Node Down events along. But now you have a
ruleset which will send just one kind of event, unmatched Node Downs, to
TEC. That's all.
So if you wanted to see more events in TEC, then you would have to add
additional selection criteria, using either trap settings or event
attributes blocks, to select and forward all the other events you want to
see in TEC, just as the TEC_ITS.rs ruleset does. That's why it has an
event attributes block for every specific NetView trap it wants to go to
TEC. You'd have to do something similar.
Hope this helps,
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
"Liu, David"
<david.liu@eds.co
m> To
Sent by: "Tivoli NetView Discussions"
nv-l-bounces@list <nv-l@lists.ca.ibm.com>
s.ca.ibm.com cc
Subject
08/24/2006 09:18 [NV-L] Event correlation to TEC
AM
Please respond to
Tivoli NetView
Discussions
<nv-l@lists.ca.ib
m.com>
Dear list,
One question about the event correlation, the famous interface down/up
correlation ruleset is working fine in Netview (tested). My question is:
will this ruleset also work for forwarding to TEC, i.e. if I use the
ruleset in the tecint.conf? My test is failed (the down event is not
waiting 5mins for the up event). Or I need a separate ruleset in TEC?
Solaris, 7.1.4 FP3.
Regards,
David Liu
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
|