Patterns and related event groups

The use of patterns allows events with different Identifier fields to be grouped in the Event Viewer.

Discovered related event groups can be deployed independently of a pattern. In this case, incoming events are matched by using the event's Identifier field and grouped together if they match the Identifier field of the events of the deployed group.

In contrast to ungrouped deployed based on related event groups, the use of patterns allows events with different Identifier fields to be grouped in the Event Viewer. In this case, incoming events are matched by using the Event Type field. Matching events for deployed patterns are grouped by Resource in the Event Viewer. To allow a group of related events, with different Resource field values, to be allocated to a pattern, use name similarity or specify a regular expression in the pattern. To allow deployed patterns to group events across multiple resources, use name similarity or specify a regular expression in the pattern.

Event Types

By default, the Event Type field is set to the AlertGroup column in the Object Server alerts.status table. You can configure the system to use a different column or combination of columns by using the Event Analytics configuration wizard, as described in Configuring event pattern processing.

When a pattern is manually created, at least one Event Type must be selected in the drop-down list. There is no maximum number of Event Types. Whichever related event groups are allocated to the pattern must have all the Event Types specified (and no extra ones). For example, if a pattern is created with Event Type set to NmosEventType and ITNMMonitor then only groups with related events that have both these event types can be allocated. In this example, if a group contains three related events with AlertGroup values of, in turn, NmosEventType, ITNMMonitor, and some other value, then this group is not a candidate for allocation to the pattern. It is not a candidate because its related events contain an Event Type that is not part of the pattern.

Resources

A resource can be a hostname (“server name”), or an IP address.

By default the Resource field is set to the Node column in the Object Server alerts.status table. You can configure the system to use a different column by using the Event Analytics configuration wizard, as described in Configuring event pattern processing.

If name similarity is disabled and no regular expression is specified for the pattern, then all the resource values for the events within a related events group must be the same.

Note: The check on the Resource field is performed by using the historical event data, not the related event data. However, most of the time the Resource value in the historical event data is the same as the Resource value in the related event data.

If many related events groups are allocated to a pattern, then the Resource value does not have to match across groups; however, the Resource value must match within a group. Name similarity is enabled by default in Netcool® Operations Insight® 1.5.0 and higher. When name similarity is enabled, the Resource values in the related events group (by default, the contents of the Node column) must be sufficiently similar based on the name similarity settings. The default name similarity settings require the lead characters to be the same and the text to be 90% similar.

Warning: There is an important exception to this scenario. If the Node column contains IP addresses, then the different IP address values must match down to the subnet value; that is, the first, second, and third segment of the IP address must be the same. For example:

123.456.789.10 matches 123.456.789.11.
123.456.789.10 does not match 123.456.788.10.

Example

For example, assume that Link up and Link down regularly occurs on Node A. Analytics detects the occurrence in the historical data and generates a specific grouping of those two events for Node A. Likewise, if Link up and Link down also regularly occurs on Node B, a grouping of those two events is generated but specifically for Node B.

With patterns, the association of such events is encapsulated by the system as a pattern: Link up / Link down on any Node. In pattern terms, Link Up / Link Down represents the event type and Node* represents the resource.

Advantages of patterns

A created pattern has the following advantages over a related event group:

For any instance of a pattern, not all of the events in the definition must occur for the pattern to apply. This is dependent on the Trigger Action settings. For more information about Trigger Action setting, see Creating and editing event patterns.
The pattern definition encompasses groups of events with the defined event types.
A single pattern can capture the occurrence of events on any resource. For example, with discovered groups, analytics only found historical events that occurred on a specific hostname, and created groups for each hostname. If real time events happen on different hostnames in the future, the discovered groups will not capture them. However, patterns will discover the events because the event type is the same.
A pattern can encompass event groupings that were not previously seen in the event history. An event group that did not previously occur on a specific resource is identified by the pattern, as the pattern is not resource dependent, but event type specific. Note: when selecting an event type (during the event type configuration), the column that identifies the event type should be unique across multiple event groups.
A single pattern definition can encompass multiple event groups. Patterns will act on event types for different hostnames which might have occurred historically (discovered groups) or will happen in future real time events. For example, an event type could be Server Shutting Down, Server Starting Up, Interface Ping Failure, and so on. Each group is resource specific, but an event pattern is event type specific. Therefore, an environment might have multiple groups for different resources, and an event pattern will encompass all of those different groups since their event type is the same.

Differences between patterns and event groups

These are the differences between patterns and event groups:

Parent events for deployed related event groups can be synthetic only. In contrast, parent events for deployed groups based on patterns can be either the most important event (also known as the most actionable event) in the group or a synthetic event.
The time window for a deployed related event group is the time difference between the first and last event in the discovered related event group. The time window for a pattern is the time difference between the first and last events across all of the events for the groups used to create the pattern.
Name similarity and regular expression matching does not apply for resources that form part of events within deployed groups. However, name similarity and regular expressions do apply to groups based on patterns.

The following table summaries the differences:

Table 1. Differences between deployed groups based on patterns and related event groups
	Related event groups	Patterns
Parent events	Synthetic event only	Most Important event, or Synthetic event
Time window	Time difference between the first and last event in the discovered related event group¹	Time difference between the first and last events across all of the events for the groups used to create the pattern
Name similarity on resources within the deployed groups	No	Yes
Regular expression matching on resources within the deployed groups	No	Yes

¹ Any events that match the Event Identity field of the group and that arrive after this time window are placed in a separate event group in the Event Viewer.