Alert binding procedures

Alerts can be bound to CIs from the CMDB for tracking purposes and remediation. Event Management uses event rules and various mechanisms to automatically bind CIs to alerts. When information from an event populates a field with a value, the value either originates from the event source or from event rules. This enhances remediation, functionality, and integration with other ITOM products.

You can use these procedures to ensure that alerts bind properly to CIs.
Note: In this section, the phrase "populate event field XXX with value YYY", occurs by sending the field value from the event source, or by using event rules to populate the field (assuming this information is contained somewhere in the event).

Binding to an application running on a specific host

If the event is specific to an application type, use the following steps to bind alerts to a specific application:
  • Use the recommendations in Binding to a host computer, switch, or router CI.
  • Create an event rule with a filter that captures events on the application type you want.
  • In the event rule, select Bind.
  • Click Active.
  • In the Binding Type field, select either CI's Identification or Legacy
    • For CI's Identification, specify the Class.
      • In the Class criterion attributes field, specify name and sys_class_name.
      • In the name Add Value field, specify the required name.
      • In the Container level 1 area, specify the required values.
      • If further container level fields appear, specify the required values.
    • For Legacy, specify the required CI Type.
  • In the binding process, after the host is found, the algorithm matches all additional_info attributes that have the same name as CI fields for that CI type. If the match is successful, the event is bound to the CI.
  • If more than one matching application is found on the host, the alert is bound to the host and not to the application.
If there is no CI Type, for example, you want to bind alerts to a SQL server application when the CPU on sqlServer.exe is over 90%, use these steps instead:

Binding to a non-host CI

If the event is specific to a non-host CI, for example a business service, manual Service, or alert group, use the following steps to bind alerts to a non-host CI:
  • Leave the Node field empty.
  • Populate the CI Type with the CI type you want to bind.
  • Make sure the additional_info field has enough information to uniquely identify the CI. The algorithm matches all additional_info attributes that have the same name as CI fields for that Event Type. If the match is successful, the event will be bound to the CI.
Optional method:
  • Leave the Node field empty.
  • Populate the CI Identifier (ci2metric_id) field as above with attributes that will uniquely identify the CI.

Binding to a host computer, switch, or router CI

Use the following steps to bind alerts to a host, such as a computer, switch, or router CI:
  • Populate the Node field in the event with the CI name, FQDN, IP, or MAC address value. The bind is successful even if host has more than one IP address or MAC.
  • If you want to use a unique identifier that is not one of the four mentioned above, populate the event rule CI Identifier (ci2metric_id) field with one or more unique identifiers of the CI. This field should be in JSON format. For example, if you want to use a unique identifier that is not one of the four mentioned above, add a CI Identifier (ci2metric_id) filter field with one or more unique identifiers of the CI. If the host CI is VMWare VM, and it has a field called MOID, use the JSON format and specify: {"moid":"<CI moid>"}

Binding to a process

You can define a pattern of processes that matches with the sa_process_name variable. The sa_process_name variable must be filled with the process name using an event rule. The Process to CI Type Mapping table is used for process binding. The table includes default patterns. The pattern variables extract from this table according to the host related CI Type. The table contains these columns for process binding:
  • The Process field contains the process pattern. Use any combination of free text, regex, and pattern.
  • The ci_type field contains the CI type in CMDB.

Binding an alert to a process, Event Management first receives all the processes that are running on the node (the alert resolving node). Then, Event Management matches every related process pattern with the name that is defined in the sa_process_name variable. Regular expressions are supported.

For example, if the sa_process_name contains /ora92/pmon_U2P3_db for an Oracle instance:
  • The sa_process_name variable must be filled by the event rule to store the process name.
  • The Process to CI Type Mapping table has the following record: 
Process: ${oracle_home}/pmon_${instance}
CI type: cmdb_ci_db_ora_instance.
  • Binding the process, Event Management finds a process of type cmdb_ci_db_ora_instance is running on the node.
  • Event Management matches /ora92/pmon_U2P3_db from the sa_process_name variable with the process pattern from the Process to CI Type Mapping table for type cmdb_ci_db_ora_instance.
  • If the Oracle instance has ${oracle_home} = ora92 and ${instance} = U2P3_db extracted from the database, then there is a match and this Oracle process is bound in the alert cmdb_ci. 
/ora92/pmon_U2P3_db= ${oracle_home}/pmon_${instance}.

To bind a process, use the Process to CI Type Mapping [em_binding_process_map] table.

Binding to an application

In the binding process, the following steps occur:
  • Identify the host.
  • If the host is found, find the application on the host. An application is considered to be running on the host if it has a "Runs on:Runs" relationship from the application to the host CI in the cmdb_rel_ci table.
  • If the event rule for the transform CI type is defined, find an application CI on that host in the CMDB.
  • If all the alert additional_info about the CI matches CMDB CI fields, bind the alert to the application CI.

Binding to a device

The Process to CI Type Mapping table provides all of the necessary information for binding the alert to device CIs. The table can be extended to support more device types in the future. The Process to CI Type Mapping table contains these columns for device binding:
  • The from_ci_type field matches with the Event Type.
  • The to_ci_type field contains the CI Type to look for in the CMDB.
  • The mapped_column field contains the name of the column which stores the relationship to the node.
To bind a device, use the Process to CI Type Mapping [em_binding_process_map] table. For example, the table below shows a record in the Process to CI Type Mapping table. If the Event Type is cmdb_ci_file_system, Event Management searches the File System [cmdb_ci_file_system] device table for a computer field contains the node sys_id. If there is a match, the alert binds with this CI.
Table field Value
from_ci_type cmdb_ci_file_system
to_ci_type cmdb_ci_network_adapter
mapped_column computer

Binding to a device to a specific host CI

In the binding process, after the host is found, the algorithm matches all additional_info attributes that have the same name as CI fields for that event type. If match is successful, the event is bound to the CI. If more than one matching device is found on the host, the alert is bound to the host and not the application. Use the following steps to bind alerts to a specific device:
  • Use the recommendations in Binding to a host computer, switch, or router CI.
  • Create an event rule with a filter that captures events on the device type you want. In the event rule, select the Transform check box and select the appropriate CI Type:
    Device to bind CI Type
    File System cmdb_ci_file_system
    Port cmdb_ci_network_adapter
    Storage Device cmdb_ci_storage_device
    Volume cmdb_ci_storage_volume
  • To bind custom device types, use the Process to CI Type Mapping [em_binding_process_map] table.