O'Reilly logo

Event Management and Best Practices by Michael Wallace, Guilherme Pereira, Jacqueline Meckwood, Peter Glasmacher, Tony Bhe

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

296 Event Management and Best Practices
up, NetView sends a router up event to IBM Tivoli Enterprise Console, which
netview.rls correlates with the original router down and closes it.
If you get the router down event in IBM Tivoli Enterprise Console from
NetView and then you acknowledge that event in IBM Tivoli Enterprise
Console, IBM Tivoli Enterprise Console sends a trap back to NetView so that
router’s icon is displayed as
acknowledged on the NetView console.
If you close that router on the IBM Tivoli Enterprise Console, IBM Tivoli
Enterprise Console then sends a trap back to NetView. When NetView
receives this trap, it polls the affected device to see if it is still up. However
NetView does not send a new event back to IBM Tivoli Enterprise Console
because of its state change nature. The main purpose of the netview.rls rule
is for synchronization between IBM Tivoli Enterprise Console and the
NetView console.
Upward synchronization is not as vital. NetView doesn’t perform duplicate
detection, so it doesn’t need to update slot in IBM Tivoli Enterprise Console.
NetView typically does state change monitoring, which necessitates sending
a new event.
򐂰 Upward synchronization done by NetView sending an event of the same
class, with status=close.
6.6.2 IBM Tivoli Enterprise Console gateway and IBM Tivoli
Enterprise Console
IBM Tivoli Enterprise Console gateway and IBM Tivoli Enterprise Console event
server event synchronization is handled automatically by the IBM Tivoli
Enterprise Console product set. Event synchronization only occurs from the IBM
Tivoli Enterprise Console gateway to the IBM Tivoli Enterprise Console event
server. When state correlation is enabled on the IBM Tivoli Enterprise Console
gateway, and the XML rule is in place, depending on how you wrote the XML rule,
correlation occurs on the gateway. It is based on events that match your defined
criteria and events received within a defined timing interval which match that
same criteria. The events are correlated as you defined them. Then a summary
event is sent to the defined IBM Tivoli Enterprise Console event server.
There is no data flow from the IBM Tivoli Enterprise Console event server to the
IBM Tivoli Enterprise Console gateways. This is simply because the IBM Tivoli
Enterprise Console state correlation gateways handle all event correlation for
their managed event sources before sending data to the IBM Tivoli Enterprise
Console event server. There is no need for downstream data from the IBM Tivoli
Enterprise Console event server to the IBM Tivoli Enterprise Console gateways.
Once state correlation takes place at the gateway, all subsequent events are
handled independently. If you set a time interval for a specific correlation, and

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required