Event Configuration and Use

This is the largest domain on the exam. It is about what happens to an event after it lands in the instance and before a human ever sees it: how events are normalized, filtered, matched, transformed, thresholded, deduplicated, and ultimately bound to a configuration item (CI) and turned into an alert.

Events versus alerts (the foundational distinction)

An event is a single, raw, machine-generated notification that something happened on a monitored resource, such as a CPU spike, a service stopping, a disk filling. Events are noisy and high-volume. They are stored in the Event [em_event] table. An event by itself does not demand action; it is data.

An alert is the actionable, deduplicated, human-facing record that Event Management produces from one or more events. Alerts live in the Alert [em_alert] table. Many events typically collapse into a single alert. The whole point of Event Management is this reduction: turn a flood of events into a small number of meaningful, prioritized, CI-bound alerts that an operator or automation can act on.

A useful mental model: events are the input signal; alerts are the curated output. Event rules are the machinery in between.

The event-to-alert processing flow

When you can recite this pipeline in order, most configuration questions become answerable. The high-level flow:

1. Event ingestion: events arrive (push via web service/REST, or pull via a MID Server connector) and are inserted into em_event with state Ready.
2. Event rule evaluation: the processing job evaluates event rules against each event. Rules can filter (ignore), transform/normalize field values, set severity, compose the message key, and define how the resulting alert binds to a CI. Event field mappings (a separate Event Field Mapping [em_mapping_rule] table) then translate values such as vendor severities; they apply after event rule processing and before alert generation, even when no event rule matched.
3. Threshold checks: optional thresholds can suppress alert creation until a number of matching events occur within a window (reduces flapping/noise).
4. Alert creation or update: events sharing the same message key are deduplicated onto the same alert. The first matching event opens the alert; subsequent matching events increment the event count and update the alert rather than creating new alerts.
5. CI binding: the alert is associated to a CI in the CMDB so impact and correlation can be calculated.
6. Downstream processing: alert correlation, aggregation, alert management/remediation rules, and (optionally) incident creation.

Event processing states you should know are Ready (received and waiting to be processed), Processed (successfully processed), and Error (processing failed, for example because the event severity is blank). The State choice Ignored exists but is documented as not in use: an event dropped by an event rule's ignore filter is still recorded in em_event, and its Processing Notes show which rules were applied.

The message key: the heart of deduplication

The message key is the identity fingerprint of an alert. Event Management builds a message key for each event (by default from a combination of fields such as source, node, type, resource, and metric name, but you control it in event rules). All events that produce the same message key are treated as the same problem and roll up to one alert.

This is the single most important configuration concept in the domain. Get the message key too broad and unrelated problems collapse into one alert (loss of fidelity). Get it too narrow and one real problem fragments into many alerts (noise returns). Tuning the message key is the lever that controls deduplication granularity.

Event rules: the core configuration object

An event rule processes events that match its filter and applies actions. Event rules are evaluated in ascending Order; lower order runs first. By default only the first matching rule is applied; selecting Apply additional matching rules lets later matching rules run as well. A well-designed rule set runs cheap, specific filters early.

An event rule has these functional parts:

• Filter / event matching: the conditions that decide whether this rule applies to a given event (for example, source equals "SCOM" and the description contains a pattern). If the event does not match, the rule is skipped.
• Transform and compose: map and normalize raw vendor fields into the standard Event Management fields. You can use regular expressions to extract substrings from the raw text, JavaScript for richer logic, and templates to compose values. Common targets: type, resource, metric_name, severity, node, and the message key itself.
• Threshold: optionally require N matching events within a time window before an alert is generated, suppressing transient blips.
• CI binding / additional information: specify how the resulting alert binds to a CI, and add supplementary fields.
• Ignore: on the Event Filter tab, Ignore events that match this filter stops matching events from creating alerts while the events stay recorded in em_event (a clean way to drop known-benign noise).

A practical note that frequently appears as a distractor: an event rule that does not bind a CI does not stop alert creation; the alert can still be created but may be unbound (or bound by fallback logic).

Binding events/alerts to CIs (CI binding)

CI binding is what makes Event Management service-aware. An alert bound to a CI can be placed on a service map, correlated with topologically related alerts, and used to compute service impact.

Binding strategies, in rough order of reliability:

• Direct CI match: the event carries a value (such as cmdb_ci sys_id, name, FQDN, or IP) that maps to exactly one CI. The event rule's binding configuration names which event field maps to which CI identifier.
• Binding rules / additional binding logic: when a single field is not enough, additional binding logic resolves the correct CI, often using the node plus another attribute.
• No match: if no CI is found, the alert may remain unbound; unbound alerts still appear but cannot participate in topology-based correlation or service impact.

Know the difference between binding to a CI versus simply storing a node name string: only a resolved CI reference participates in CMDB-driven correlation and impact.

Thresholds

A threshold suppresses alert generation until a configured count of matching events is reached within a configured interval. Thresholds are how you tame flapping (a resource that rapidly oscillates between healthy and unhealthy). They live as part of event-rule configuration. The exam may test the difference between a threshold (count over time gates alert creation) and deduplication (message key collapses many events into one existing alert).

Tools for configuration and validation

• Regular expressions are used inside event rules to parse and extract values from unstructured event text.
• JavaScript is available for transform logic that is too complex for a simple regex or field map.
• PowerShell appears on the collection side for Windows-based connectors (for example, pulling from SCOM).
• Event simulation / test: you can simulate event processing to see which rule matches, what the transformed event looks like, and what alert (and message key) results, without waiting for live data. This is the recommended way to validate rule logic before deploying.
• Event processing statistics let you monitor throughput, backlog, and error rates of the processing job.

Operator-facing use

Operators consume alerts in Service Operations Workspace (the current workspace experience) and through alert/console views. The older Operator Workspace is deprecated from the Vancouver release onward and remains only for customers who upgraded from a release before Utah. The configuration you do upstream (good message keys, correct CI binding, sensible severity normalization) is what makes the operator view usable.

---