Contents

Alert binding to CIs with event rules

SAVE AS PDF

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:

When an event arrives, Event Management checks
the node or CI identifiers.

If no node exists, the generated alert can bind to the CI using the alert
Type, Additional
information, or Configuration item
identifier fields.

If the event has a node value, search for a valid host.

If the event has a host and a CI type, try to bind to a device CI.

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.

Tracking and remediation

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.

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 procedures in the topic.

Create an event rule with a filter that captures events on the application
type you want.

In the event rule, select Binding.

Click Override default binding.

In the Binding Type field, select either CI's
Identification or CI field
matching.

For CI's Identification, specify the
Class.

In the 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 CI field matching, 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.

Where there is no CI Type, for example, if you want to bind
alerts to a SQL server application when the CPU on sqlServer.exe is over 90%,
instead use these procedures:

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
address.

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, 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>"}

Create an event rule with an event match field which maps the process name
to the mapping variable sa_process_name. In this case, do
not use the CI type.

Binding procedures

You can create an event rule to bind alerts to the correct device CI. An incoming event from a device CI can bind to an alert based on event rule transform information. However, first identify the host CI that the device is running on.

An incoming event from a discovered business service, application service, or alert group can bind to an alert based on an event rule and the corresponding event field mapping. The event field mapping requires a URL or the port number and corresponding IP address for each service or alert group.