Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Alert binding to CIs with event rules

Log in to subscribe to topics and get notified when content changes.

Alert binding to CIs with event rules

When alerts are associated with CIs, the task of remediation is simplified. During alert generation, Event Management uses event rules and other mechanisms to automatically bind alerts to CI information from the CMDB. For tracking purposes and remediation, the alert shows information about the CI that caused the event.

Alert binding process flow

Alerts bind to CIs based on the following process flow:
  1. When an event arrives, Event Management checks the node or CI identifiers.
  2. If no node exists, the generated alert can bind to the CI using the alert Type, Additional information, or Configuration item identifier fields.
  3. If the event has a node value, search for a valid host.
  4. If the event has a host and a CI type, try to bind to a device CI.
  5. If the event has a host, try to bind to the application CI.
Figure 1. How alerts bind to CIs
The event can contain the binding process flow in its Processing Notes field. For example, while binding the alert to a process, the following steps occurred:
  • The node, which is found by node name, resolved to the CI ID 775cbc6093120200e0e931f6357ffb17.
  • There was no CI type on the event and the sa_process_name variable was set to /ora92/pmon_U2P3_db.
  • Event Management tried to match the CI ID to the process pattern from the em_binding_process_map table.
  • Event Management found the CI ID 6d6cbc6093120200e0e931f6357ffb78: pattern ${oracle_home}/pmon_${instance} (from em_binding_process_map) and matched it to the /ora92/pmon_U2P3_db pattern that was defined in the sa_process_name variable.
  • The alert was bound to CI ID 6d6cbc6093120200e0e931f6357ffb7.