How events are handled depends on several criteria, including the architecture type (unidirectional versus bidirectional) and the event type (pure versus sampled).
| Action | Event type | Unidirectional behavior | Bidirectional behavior |
|---|---|---|---|
| Situation condition becomes true. | Pure and sampled events. | Summary: A new event is opened in the hub monitoring server and in the Netcool/OMNIbus ObjectServer if it does not deduplicate an existing event. Details: The hub monitoring server opens a new situation event and sends an event with the Open status to Netcool/OMNIbus ObjectServer using flows 1 to 4 as shown in Figure 1 and a new event is opened in Netcool/OMNIbus if it does not deduplicate an existing event. Note: The hub monitoring server sends an event
with open status to Netcool/OMNIbus each time a condition is true
for a pure situation. For sampled situations, an event with open status
is sent when the situation condition transitions from not true to
true. Until the sampled situation condition becomes false, another
event is not sent unless the status of the event is changed, for example
to acknowledged.
|
Same as unidirectional behavior. |
Sampled event situation condition is no longer true or a pure sampled situation UNTIL modifier condition becomes true. |
Pure and sampled events. | Summary: Event is closed in the hub monitoring server and cleared in the Netcool/OMNIbus ObjectServer. Details: After the event is closed in the hub monitoring server, a closed status update event is sent to Netcool/OMNIbus ObjectServer by using flows 1 to 4 as shown in Figure 1. When the IBM Tivoli Monitoring triggers process the status update event they clear the event in the Netcool/OMNIbus ObjectServer. Note: For
more information about creating a situation UNTIL modifier and details
on when sampled events are closed if they have an UNTIL modifier,
see the IBM Tivoli Monitoring Tivoli Enterprise
Portal User's Guide.
|
Same as unidirectional behavior. |
| Event acknowledged using the Netcool/OMNIbus Event List UI. | Pure and sampled events. | Summary: Event status is changed to acknowledged in the Netcool/OMNIbus ObjectServer. However, the event status is not updated in the hub monitoring server and Tivoli Enterprise Portal. |
Summary: The event status is changed to acknowledged in the Netcool/OMNIbus ObjectServer, the hub monitoring server, and Tivoli Enterprise Portal. Details: After the event status is changed to acknowledged in the Netcool/OMNIbus ObjectServer, the hub monitoring server is notified about the status change by flows 5 through 8 in Figure 1. In flow 7, the IBM Tivoli Monitoring Situation Update Forwarder sends a CT_Acknowledge SOAP request to the hub monitoring server. The hub monitoring server changes the event status to Acknowledged when it processes the SOAP request and sends a status update event back to OMNIbus using flows 9 through 11. |
| Event cleared or deleted using the Netcool/OMNIbus Event List UI. | Pure events. | Summary: The pure event is cleared or deleted in the Netcool/OMNIbus ObjectServer. However, the event remains open in the hub monitoring server and Tivoli Enterprise Portal until the UNTIL modifier condition of the situation becomes true. |
Summary: The pure event is cleared or deleted in the Netcool/OMNIbus ObjectServer and closed in the hub monitoring server and Tivoli Enterprise Portal. Details: After the event is cleared or deleted in the Netcool/OMNIbus ObjectServer, the hub monitoring server is notified about the status change by flows 5 through 8 in Figure 1. In flow 7, the IBM Tivoli Monitoring Situation Update Forwarder sends a CT_Reset SOAP request to the hub monitoring server. The hub monitoring server closes the event when it processes the SOAP request and sends a status update event back to OMNIbus using flows 9 through 11. |
| Event cleared or deleted using the Netcool/OMNIbus Event List UI. | Sampled events. | Summary: The sampled event is cleared or deleted in the Netcool/OMNIbus ObjectServer. However, the event remains open in the hub monitoring server and Tivoli Enterprise Portal until the situation condition is no longer true. No further status updates are sent to Netcool/OMNIbus until the situation condition becomes false and then true again. Therefore, the Netcool/OMNIbus operator is not notified that the event condition has not been resolved. |
Summary: The sampled event is cleared or deleted in the Netcool/OMNIbus ObjectServer but its status is changed to Acknowledged in the hub monitoring server and Tivoli Enterprise Portal for a specified time. If the situation condition is still true after the specified time, a status update event is sent to Netcool/OMNIbus and an event is opened. This status update notifies the Netcool/OMNIbus operator that the event condition is not resolved. Details: When the sampled event is cleared or deleted, the event data is cached by the ObjectServer in an IBM Tivoli Monitoring table. Then the hub monitoring server is notified of the status change by flows 5 through 8 in Figure 1. In flow 7, the IBM Tivoli Monitoring Situation Update Forwarder sends a CT_Acknowledge SOAP request with a configurable timeout to the hub monitoring server. The hub monitoring server changes the event status to Acknowledged and starts an expiration timer. A status update event is sent back to OMNIbus by using flows 9 through 11. The events are marked as Acknowledged in the hub monitoring server and Tivoli Enterprise Portal because a sampled event cannot be closed unless the situation condition is no longer true. By leaving the situation as Acknowledged, Netcool/OMNIbus is notified if the situation condition is still true after the timeout expires.If the situation condition is still true when the timeout expires, the hub monitoring server sends an Acknowledgement Expired status update event to Netcool/OMNIbus ObjectServer by using flows 1 to 4 as shown in Figure 1. If the event has already been removed from the Netcool/OMNIbus ObjectServer alerts.status table, a new event is opened in the ObjectServer. |
| Event cleared or deleted using the Netcool/OMNIbus Event List UI (continued) | Details: (continued) Because status update events contain only base ITM EIF slots and no agent-specific slots, the event is re-opened using data that was cached when the event was cleared or deleted from the Netcool/OMNIbus Event List UI. However, if the event is still in the Netcool/OMNIbus ObjectServer alerts.status table when the status update event is processed, the event is deduplicated by the ITM triggers. The event is then reopened and contains event attribute settings from the original event. | ||
| Event deacknowledged by using the Netcool/OMNIbus Event List UI. | Pure and sampled events. | Summary: The event status is changed to deacknowledged in the Netcool/OMNIbus ObjectServer. However, the event status is not updated in the hub monitoring server and Tivoli Enterprise Portal. |
Summary: The event status is changed to deacknowledged in the Netcool/OMNIbus ObjectServer and to resurfaced in the hub monitoring server and Tivoli Enterprise Portal. Details: After the event status is changed to deacknowledged in the Netcool/OMNIbus ObjectServer, the hub monitoring server is notified about the status change by flows 5 through 8 in Figure 1. In flow 7, the IBM Tivoli Monitoring Situation Update Forwarder sends a CT_Resurface request to the hub monitoring server. The hub monitoring server changes the event status to Resurfaced when it processes the SOAP request and sends a status update event back to OMNIbus using flows 9 through 11. |
| Event acknowledged without a timeout by using the Tivoli Enterprise Portal Situation Event Console. | Pure and sampled events. | Tivoli Enterprise Portal operators should not change the event status when the unidirectional architecture is being used. | Summary: The event status is changed to acknowledged in both the hub monitoring server and Netcool/OMNIbus ObectServer. Details: After the event status is changed to acknowledged in the hub monitoring server, an Acknowledged status update event is sent to Netcool/OMNIbus using flows 1 to 4 as shown in Figure 1 and the event status is changed to Acknowledged in the Netcool/OMNIbus ObjectServer and Netcool/OMNIbus Event List UI. |
| Event acknowledged with timeout by using the Tivoli Enterprise Portal Situation Event Console. | Pure and sampled events. | Tivoli Enterprise Portal operators should not change the event status when the unidirectional architecture is being used. | Summary: The event status is changed to acknowledged in both the hub monitoring server and Netcool/OMNIbus ObjectServer and you can configure how Netcool/OMNIbus handles the timeout notification event. See the detailed description for more information. Details: After the event status is changed to acknowledged in the hub monitoring server, an Acknowledged status update event is sent to Netcool/OMNIbus using flows 1 to 4 as shown in Figure 1 and the event status is changed to Acknowledged in the Netcool/OMNIbus ObjectServer and Netcool/OMNIbus Event List UI. When the timeout expires and the situation event is still open in the hub monitoring server, the hub monitoring server sets the event status to Acknowledgement Expired and sends an Acknowledgement Expired status update event to Netcool/OMNIbus using flows 1 to 4 as shown in Figure 1. By default, the IBM Tivoli Monitoring triggers reject the Acknowledgement Expired status update event and use flows 5 to 8 to send a request to the hub monitoring server to set the event status to Acknowledged. (In flow 7, the Situation Update Forwarder sends a CT_Acknowledge request to the hub monitoring server.) The hub monitoring server sets the event status to Acknowledged when it processes the SOAP request and sends a status update event back to OMNIbus using flows 9 through 11. You can override the default IBM Tivoli Monitoring trigger behavior by setting the sit_ack_expired_def_action variable to ACCEPT using the procedure described in Customizing how the IBM Tivoli Monitoring OMNIbus triggers handle event status updates from the monitoring servers. If you set the variable to ACCEPT, the IBM Tivoli Monitoring triggers deacknowledge the event in the Netcool/OMNIbus ObjectServer but the event still has the acknowledgment expired status in the hub monitoring server. |
Event deacknowledged using the Tivoli Enterprise Portal Situation Event Console. |
Pure and sampled events. | Tivoli Enterprise Portal operators should not change the event status when the unidirectional architecture is being used. | Summary: Behavior is configurable. See the detailed description for the two types of behaviors that are supported. Details: After the event status is changed to Resurfaced in the hub monitoring server, a Resurfaced status update event is sent to Netcool/OMNIbus using flows 1 to 4 as shown in Figure 1. By default the IBM Tivoli Monitoring triggers accept the Resurfaced status update event and deacknowledge the event in the Netcool/OMNIbus ObjectServer. You can override the default trigger behavior by setting the sit_resurface_def_action variable to REJECT using the procedure described in Customizing how the IBM Tivoli Monitoring OMNIbus triggers handle event status updates from the monitoring servers. If you set the variable to REJECT then the IBM Tivoli Monitoring triggers use flows 5 to 8 in Figure 1 to send a CT_ACKNOWLEDGE SOAP request to the hub monitoring server. The hub monitoring server sets the event status to Acknowledged when it processes the SOAP request and sends a status update event back to OMNIbus using flows 9 through 11. |
| Situation is stopped. Note: Situations are stopped
if an operator initiates the situation stop action from the Tivoli Enterprise Portal or modifies
the situation definition. However, a situation is not stopped if its
distribution list is modified.
|
Pure events. | Summary: The hub monitoring server closes all pure events for the situation. These same events are cleared in the Netcool/OMNIbus ObjectServer unless you configure a different behavior in the IBM Tivoli Monitoring triggers. Details: As the hub monitoring server closes all pure events for the situation, it sends a situation stop event to Netcool/OMNIbus for each remote monitoring server that was monitoring the situation. The situation stop event specifies the remote monitoring server in the situation_thrunode EIF slot. (This slot is mapped to the ITMThruNodeOMNIbus attribute by the Tivoli Netcool/OMNIbus EIF Probe.) When the IBM Tivoli Monitoring triggers in Netcool/OMNIbus process a situation stop event, they clear all events for the situation that are detected by the remote monitoring server specified by the ITMThruNode OMNIbus attribute. However, you can configure the IBM Tivoli Monitoring triggers to ignore situation stop events for pure events. For more information, see Customizing how the IBM Tivoli Monitoring OMNIbus triggers handle event status updates from the monitoring servers. |
Same as unidirectional behavior. |
| Situation is stopped. Note: Situations are stopped
if an operator initiates the situation stop action from the Tivoli Enterprise Portal or modifies
the situation definition. However, a situation is not stopped if its
distribution list is modified.
|
Sampled events. | Summary: The hub monitoring server closes all sampled events for the situation. These same events are cleared in the Netcool/OMNIbus ObjectServer. Details: As the hub monitoring server closes all sampled events for the situation, it sends a situation stop event to Netcool/OMNIbus for each remote monitoring server that was monitoring the situation. The situation stop event specifies the remote monitoring server in the situation_thrunode EIF slot. (This slot is mapped to the ITMThruNode OMNIbus attribute by the Tivoli Netcool/OMNIbus EIF Probe.) When the IBM Tivoli Monitoring triggers in Netcool/OMNIbus process a situation stop event, they clear all events for the situation that are detected by the remote monitoring server specified by the ITMThruNode OMNIbus attribute. |
Same as unidirectional behavior. |
| Agent stopped. | Pure events. | Summary: Stopping the agent has no effect on pure situation event status. An MS_Offline situation event is also sent to Netcool/OMNIbus to indicate that either the monitoring agent has been stopped or it has lost connectivity to the monitoring server. |
Same as unidirectional behavior. |
| Agent stopped. | Sampled events. | Summary: The sampled events from the agent are closed in the hub monitoring server if the agent is stopped for long enough. Its events are also cleared in the Netcool/OMNIbus ObjectServer. An MS_Offline situation event is also sent to Netcool/OMNIbus to indicate that either the monitoring agent has been stopped or it has lost connectivity to the monitoring server. Details: After the monitoring server of the agent detects that the agent has not responded for three situation sampling intervals, the situation's event is closed in the hub monitoring server. A Closed status update event is sent to Netcool/OMNIbus ObjectServer by using flows 1 to 4 as shown in Figure 1. When the IBM Tivoli Monitoring triggers process the status update event, the triggers clear the event in the Netcool/OMNIbus ObjectServer. If you do not want events to be closed in Netcool/OMNIbus after an agent is stopped, you can customize this behavior. For more information, see Customizing event status processing behavior when agent switching is used or the agent goes offline. |
Same as unidirectional behavior. |
| Agent loses connectivity to the primary monitoring server and switches to the secondary monitoring server. | Pure and sampled events. | When an agent has a situation that has triggered
and the situation is true, and the agent subsequently loses connectivity
to the Tivoli Enterprise
Monitoring Server and switches to a different monitoring server, the
Hub monitoring server sends an EIF event with class type ITM_ControlSignal
to the Netcool/OMNIbus ObjectServer for each situation event that
is still open for the agent. When the IBM Tivoli Monitoring triggers process
this event, they update the ITMThruNode attribute to specify the new
monitoring server for the agent. However, the event might be closed
by the original monitoring server if it detects the agent is no longer
responding to it before the new monitoring server determines that
the situation event is still true and the Hub monitoring server sends
the ITM_ControlSignal event. There are environment variables that can be added to the monitoring server environment file to customize the behavior of event status processing when agent switching occurs to help ensure that events are not closed by the original monitoring server. For a complete description of these variables, see Customizing event status processing behavior when agent switching is used or the agent goes offline. Note: If
an agent switches to another monitoring server because the original
monitoring server was stopped, all sampled events for the agent will
be closed by the original monitoring server. This behavior is not
configurable. However, you can configure whether pure events are closed
in this scenario. For more information, see Customizing how the IBM Tivoli Monitoring OMNIbus triggers handle event status updates from the monitoring servers.
|
Same as unidirectional behavior. |
| Hub monitoring server stopped. | Pure and sampled events. | Summary: No flows occur between the hub monitoring server and Netcool/OMNIbus when the hub monitoring server is stopped. | Same as unidirectional behavior. |
| Hub monitoring server started. | Pure events. | Summary: The pure events in the Netcool/OMNIbus ObjectServer are unaffected. However, the hub monitoring server and Netcool/OMNIbus might not have the same status for pure events. Details: When the hub monitoring server is started, it sends a master_reset event to Netcool/OMNIbus using flows 1 to 4 as shown in Figure 1. The IBM Tivoli Monitoring triggers in the Netcool/OMNIbus ObjectServer do not update the status of pure events when the master reset event is processed. However,
Netcool/OMNIbus and the hub monitoring server (and Tivoli Enterprise Portal) might have a different
status for the pure events after the hub is restarted.
|
Same as unidirectional behavior. |
| Hub monitoring server started. | Sampled events. | Summary: The sampled events in the Netcool/OMNIbus ObjectServer from this hub monitoring event are cleared. Details: When the hub monitoring server is started, it sends a master_reset event to Netcool/OMNIbus using flows 1 to 4 as shown in Figure 1. The IBM Tivoli Monitoring triggers in the Netcool/OMNIbus ObjectServer clear all sampled events from this hub monitoring server when the master reset event is processed. The master reset handling ensures that events are cleared in Netcool/OMNIbus if the situation condition became false while the hub monitoring server was stopped. The events whose situation conditions are still true will be reopened in Netcool/OMNIbus after the master reset event is sent. |
Same as unidirectional behavior. |
| Remote monitoring server stopped. | Pure events. | Summary: The hub monitoring server closes all of the pure events for agents connected to the remote monitoring server. The same events are cleared in Netcool/OMNIbus Object unless you configure a different behavior. An MS_Offline situation event is sent to Netcool/OMNIbus for the remote monitoring server to indicate that these managed systems are not being monitored. You will not see an MS_Offline message for each of the monitoring agents when the remote monitoring server goes offline. Details: As the hub monitoring server closes the pure events for each situation being monitored by the remote monitoring server, it sends a situation stop event to Netcool/OMNIbus and specifies the remote monitoring server in the situation_thrunode EIF slot. (This slot is mapped to the ITMThruNode OMNIbus attribute by the Tivoli Netcool/OMNIbus EIF Probe.) When the IBM Tivoli Monitoring triggers in Netcool/OMNIbus process a situation stop event, they clear all events for the situation that are detected by the remote monitoring server specified by the ITMThruNode OMNIbus attribute. However, you can configure the IBM Tivoli Monitoring triggers to ignore situation stop events for pure events. For more information, see Customizing how the IBM Tivoli Monitoring OMNIbus triggers handle event status updates from the monitoring servers. |
Same as unidirectional behavior. |
| Remote monitoring server stopped. | Sampled events. | Summary: The hub monitoring server closes all of the sampled events for agents connected to the remote monitoring server. The same events are cleared in Netcool/OMNIbus Object. An MS_Offline situation event is sent to Netcool/OMNIbus for the remote monitoring server and each of the monitoring agents connected to the monitoring server to indicate that these managed systems are not being monitored. You will not see an MS_Offline message for each of the monitoring agents when the remote monitoring server goes offline. Details: As the hub monitoring server closes the sampled events for each situation being monitored by the remote monitoring server, it sends a situation stop event to Netcool/OMNIbus and specifies the remote Tivoli Enterprise Monitoring Server in the situation_thrunode EIF slot. (This slot is mapped to the ITMThruNode OMNIbus attribute by the Tivoli Netcool/OMNIbus EIF Probe.) When the IBM Tivoli Monitoring triggers in Netcool/OMNIbus process a situation stop event, they clear all events for the situation that are detected by the remote monitoring server specified by the ITMThruNode OMNIbus attribute. |
Same as unidirectional behavior. |
| Remote monitoring server started. | Pure and sampled events. | Same as unidirectional behavior when a remote monitoring server is stopped. | Same as bidirectional behavior when a remote monitoring server is stopped. |
| Action | Event Type | Behavior |
|---|---|---|
| Situation condition becomes true. | Pure and sampled events. | A new event is opened in the agent and in the Netcool/OMNIbus ObjectServer if it does not deduplicate an existing event. An event with open status is sent from the agent to Netcool/OMNIbus
each time the situation condition is true, if the following conditions
are met:
|
| Sampled event situation condition is no longer true. | Sampled events. | Event is closed in the agent and cleared in the Netcool/OMNIbus ObjectServer. |
| Event acknowledged or deacknowledged using Netcool/OMNIbus Event List UI in OMNIbus. | Pure and sampled events. | The event status is changed to acknowledged or deacknowledged in Netcool/OMNIbus but the event status maintained by the agent is unaffected. |
| Event cleared or deleted using Netcool/OMNIbus Event List UI. | Pure events. | The event is cleared or deleted in the Netcool/OMNIbus ObjectServer. However, the event status maintained by the agent is not affected. |
| Event cleared or deleted using Netcool/OMNIbus Event List UI. | Sampled events. | The event is cleared or deleted in the Netcool/OMNIbus
ObjectServer. However, the event status maintained by the agent is
unaffected and the Netcool/OMNIbus operator is not notified if the
event condition has not been resolved, unless the following conditions
are met:
|
| Situation is stopped using the Agent Service Interface. | Pure and sampled events. | If the agent is configured to send lifecycle events when a situation is stopped, a EE_SIT_STOPPED event is sent to Netcool/OMNIbus. For agents that send SNMP events to Netcool/OMNIbus, the events in Netcool/OMNIbus are not affected by this lifecycle event. For agents that send EIF events to Netcool/OMNIbus, the events from the agent for the stopped situation are cleared in Netcool/OMNIbus. |
| Agent is stopped. | Pure and sampled events. | No events are sent by the agent when it is stopped. |
| Agent is started. | Pure and sampled events. | If the agent is configured to send SNMP events to Netcool/OMNIbus, no events other than lifecycle traps are sent by the agent when it is started. If the agent is configured to send EIF events to Netcool/OMNIbus, by default the agent does not send any events (other than lifecycle events) to Netcool/OMNIbus when it is started. However, you can change this behavior and configure the agent to send a master reset event to Netcool/OMNIbus when the agent is started. When the IBM Tivoli Monitoring triggers in Netcool/OMNIbus process this event, they clear all events for the agent. This ensures that events are cleared in Netcool/OMNIbus if the situation condition became false while the agent was stopped. The events whose situation conditions are still true will be reopened in Netcool/OMNIbus after the master reset event is sent. Note: The
agent does not maintain event status across restarts.
|
Agents can also send lifecycle and heartbeat events to Netcool/OMNIbus. For more details on lifecycle and heartbeat events, see the Agent Autonomy chapter in the IBM Tivoli Monitoring Administrator's Guide.