Automate event correlation with Event iQ Detect in ITSI

Event iQ Detect in IT Service Intelligence (ITSI) uses machine learning to correlate notable events into episodes, reducing alert noise. Use Event iQ Detect to facilitate notable event aggregation policy configuration.

Automatically group alerts into episodes

Event iQ Detect in IT Service Intelligence (ITSI) uses machine learning algorithms to compare field values and correlate notable events into episodes. Instead of defining manual attributes to correlate events, you can automatically identify the correct attributes to use in your grouping policies. After you onboard alerts to ITSI, you can set criteria to filter alerts, and use Event iQ Detect to create your event correlation policies based on an analysis of historical event data. Additionally, configure episode actions to run based on defined criteria.

Using Event iQ Detect in your workflow helps you quickly set up automated alert monitoring, reduce alert noise, and execute event actions. Additionally, algorithms can be continuously tuned to fit your environment's alerting needs.

Prerequisites

  • You must be an itoa_admin or itoa_team_admin to configure Event iQ Detect.

How Event iQ Detect grouping works

Event Analytics can correlate events from various sources and reduce alert noise by grouping related events together with notable event aggregation policies (NEAPs). Event iQ Detect simplifies the NEAP configuration process by automatically identifying the fields required to define event grouping criteria, selecting a correlation strategy, and prioritizing the fields to evaluate.

Event iQ Detect searches for events that match the following criteria. When a match is found, an alert is placed into that episode:
  • (Optional) Matching event_identifier_string: Alerts that have the same event_identifier_string values in the alert data can be grouped together if enabled. For example, two alerts that include event_identifier_string: "memory_high_app_server_0" in the data are grouped.

  • (Optional) Matching producer_event_id: Alerts that have the same alert identifier from a third party application (populated during data integration onboarding) can be grouped together if enabled.

  • Group by fields: If the values of grouping fields match, then alerts will be grouped together using AND/OR logic with exact or fuzzy matching. Fields at the same rank (AND criteria) are evaluated at first priority, and fields with different ranks (OR criteria) are evaluated in priority order, and the first match wins.

  • Service topology: If two alerts share at least one common service ID for the impacted_services field, they are grouped together (indicating a shared root cause).

  • CMDB CI Topology: Alerts enriched with parent/child relationship data are grouped if their configuration objects are related.

To learn how to use Event iQ Detect when configuring a notable event aggregation policy, see Apply Event iQ Detect to an aggregation policy.

Matching methods for grouping fields

When grouping by interesting fields, each field can match using one of two strategies:

Exact matching: The field values must be identical. Best for fields where precision matters, like host .

For exact matching, a Normalized exact match can also be used. For this method, before comparing, both values run through a normalization pipeline that removes superficial differences between values, such as converting everything to lowercase or replacing certain punctuation with a single space. For example, database_error becomes database error.

You can also enable cross-field value matching to compare the value of a field in one payload against the values of all fields in another payload.

Pattern matching: Extracts a template and compares each variable part by type. Pattern matching does not use a fuzzy threshold. It is recommended when the extracted template is strong enough and adds value beyond exact matching. For example, Dynatrace Problem 10001 for MoveIT and Dynatrace Problem 10002 for MoveIT will match. The problem ID is treated as NUMBER_ID and ignored. The service is STRING and matches exactly: MoveIT.

Fuzzy matching: Uses algorithms to determine if two field values are close enough to be considered a match. Values are compared using a similarity algorithm with a confidence threshold. Each fuzzy match has a confidence score (0–1) representing match reliability, and thresholds can be configured (for example, 85% for semantic similarity). For fuzzy matching, the following matching methods can be used:
Matching method Best for Example
Semantic similarity Abbreviations and synonyms user-authentication-service and user_auth_svc will match (85% threshold)
Jaro-Wrinkler Minor formatting or typo differences web-server-01 and web-server-1 will match (90% threshold)
Token Cosine Short to medium length text where the same important tokens/words appear, possibly in different order CPU High Usage and High CPU Utilization will match