IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > Installation Guide > Set up event forwarding to Netcool/OMNIbus

IBM Tivoli Monitoring, Version 6.3 Fix Pack 2


Architecture overview

Event integration between a hub monitoring server (monitoring server), and Netcool/OMNIbus (event server) can be unidirectional or bidirectional.

By using the Tivoli Enterprise Portal or tacmd commands, you can create monitoring specifications called situations to detect when specific conditions or events occur in your environment and raise an event that is sent to Netcool/OMNIbus. Each situation is assigned (or distributed) to one or more managed systems that are to be monitored for a specific condition or a set of conditions.

Two types of events might be triggered by a situation: pure or sampled. When the determination of the event must be made based on observations made at specific intervals, the event is known as a sampled event. When the event is based on a spontaneous occurrence, the event is known as a pure event. Therefore, situations for sampled events have an interval associated with them, while those for pure events do not. In sampled events, the condition that caused the event can change, causing it to be no longer true. When a situation condition becomes true for a sampled situation, an event with open status is sent to Netcool/OMNIbus. When a situation condition is no longer true for a sampled situation, a status update event with the closed status is sent to Netcool/OMNIbus so that the event is cleared. Because pure events represent a spontaneous occurrence, an event with open status is sent to Netcool/OMNIbus each time the situation condition is true. No status update event is sent when the situation condition is not true. Therefore, pure events can be left open indefinitely unless you close them by using one of the following options:

Event integration between a hub monitoring server (monitoring server) and Netcool/OMNIbus (event server) can be unidirectional or bidirectional. Events can also be sent directly to Netcool/OMNIbus from IBM Tivoli Monitoring agents by using either SNMP or EIF. OMNIbus operators can use the Tivoli Netcool/OMNIbus WebGUI or native desktop environment to view events. By using the Netcool/OMNIbus Event List UI support in the WebGUI and native desktop, operators can acknowledge events, view event journals, take ownership of events, and run event management tools.

In a unidirectional architecture, hub monitoring servers use the Tivoli Event Integration Facility (EIF) interface to forward situation events to OMNIbus. The events are received by the Netcool/OMNIbus probe for Tivoli EIF, which maps them to OMNIbus events and then inserts them into the OMNIbus ObjectServer. If the status of a situation event changes, the hub monitoring server also sends status update events to Netcool/OMNIbus. The unidirectional architecture is similar when an agent is configured to send events to Netcool/OMNIbus. The situation events of the agent are forwarded to a Netcool/OMNIbus probe for Tivoli EIF, or to the Netcool/OMNIbus SNMP probe that maps them to OMNIbus events. The agents also forward status update events to Netcool/OMNIbus when a sampled event condition is no longer true.

In a bidirectional architecture, when an OMNIbus operator acknowledges, deacknowledges, deletes, or clears a forwarded event, OMNIbus sends those status changes back to the hub monitoring server that forwarded them using the IBM Tivoli Monitoring Situation Update Forwarder. (Severity changes, other than clearing an event, are not sent back to the hub monitoring server.) Bidirectional updates from Netcool/OMNIbus are supported only for events that originate from the hub monitoring server. Bidirectional updates are not supported for situation events sent directly from monitoring agents to SNMP, or EIF to Netcool/OMNIbus probes.

Use the bidirectional architecture in the following scenarios:

If you use the unidirectional architecture, the following conditions apply:

The event integration also supports single-tier, multitier and high availability Netcool/OMNIbus architectures. In a single-tier architecture without high availability, there is a single Netcool/OMNIbus ObjectServer. In a multitier architecture, there are multiple sets of ObjectServers for scalability purposes. You can add high availability to each of these architectures by adding a primary and backup ObjectServer to each tier. You can also configure EIF probes for peer-to-peer failover mode. For more information on configuring the event integration in multitier and high-availability architectures, see Netcool/OMNIbus Multitiered and High-availability Architecture.

Figure 1. A typical event flow showing both IBM Tivoli Monitoring and Netcool/OMNIbus environments for a single-tier architecture

The following steps outline the event flow for a typical bidirectional or unidirectional flow between IBM Tivoli Monitoring and Netcool/OMNIbus, with actions taken by Netcool/OMNIbus operators. Steps 1 to 5 are common to both bidirectional and unidirectional event flows. Steps 6 to 11 are specific to bidirectional event flows only.

  1. IBM Tivoli Monitoring generates situation events that are sent to the Netcool/OMNIbus probe for Tivoli EIF. These events are also displayed in the Tivoli Enterprise Portal.

  2. The probe maps a subset of the IBM Tivoli Monitoring EIF slots to the Netcool/OMNIbus ObjectServer attributes and creates an OMNIbus event.

  3. The OMNIbus events are inserted into the Netcool/OMNIbus ObjectServer by using IBM Tivoli Monitoring provided triggers.

  4. Events in the Netcool/OMNIbus ObjectServer are displayed in the Netcool/OMNIbus Native Event List or WebGUI and in the Tivoli Enterprise Portal.

  5. Forwarded events are acknowledged, deacknowledged, deleted, or cleared by Netcool/OMNIbus operators or by automation within OMNIbus or Impact. Event status can also be updated by an integrated trouble ticket system or by integration with another Event Server.

  6. IBM Tivoli Monitoring triggers in the Netcool/OMNIbus ObjectServer database forward the event status changes to the IBM Tivoli Monitoring Situation Update Forwarder.

  7. The IBM Tivoli Monitoring Situation Update Forwarder sends SOAP requests to the hub monitoring server.

  8. Status changes are propagated through the Tivoli Enterprise Portal Server and shown in the Tivoli Enterprise Portal. The complete list of open, acknowledged, and deacknowledged events is shown in the Situation Event Console workspace of the Tivoli Enterprise Portal.

  9. The event status change is also sent back to Netcool/OMNIbus and to any other event destinations that are configured for the situation.

  10. The probe maps a subset of the IBM Tivoli Monitoring EIF slots to the Netcool/OMNIbus ObjectServer attributes and creates an OMNIbus event.

  11. IBM Tivoli Monitoring triggers determine the event is a loopback event and ignores it.

A Tivoli Enterprise Portal operator can also acknowledge and deacknowledge events or close pure events for the bidirectional architecture. The Tivoli Enterprise Portal Server processes the event status changes from the Tivoli Enterprise Portal and notifies the hub Tivoli Enterprise Monitoring Server of the changes. The event status updates are sent by the hub Tivoli Enterprise Monitoring Server to Netcool/OMNIbus using the flows shown in Figure 1.


Parent topic:

Set up event forwarding to Netcool/OMNIbus

+

Search Tips   |   Advanced Search