Configuring event pattern processing

Configure how patterns are derived from related events using this example-driven wizard panel.

Before you begin

To configure event pattern processing, you must specify Historical Event Database fields to use for settings such as event type, event identity, and resource, or accept the fields specified as default.

Note: If you want to use custom fields, then you must first configure the Impact Event Reader to read these custom fields, as described in the following topic: Netcool®/Impact Knowledge Center: OMNIbus event reader service.

In order to generate analytics output, whether seasonal events, related event groups, or event groups based on patterns, you will need to create analytics configurations. When you create an analytics configuration, the fields you specify in this wizard pane are processed in the following way:

1. If there are no additional event types (see step 2) then all events in the Historical Event Database that match the configuration filter and date criteria in your analytics configuration are considered when looking for groups. The Default event identity field(s), specified in step 1, are used to pinpoint individual events. The Default event type field is used for the event type of the discovered related events, and is used to determine the event pattern.
2. If there is one additional event type (see step 2) then all events that match the filter of that additional event type in the Historical Event Database (and also match the filter and date criteria in your analytics configuration) are considered first when looking for groups. The Event identity field(s) of this additional event type are used to pinpoint individual events. The Event type field of this additional event type is used for the event type of the discovered related events. All other records in the Historical Event Database (that is, those record that do not match the filter of the additional event type but which do match the filter and date criteria in your analytics configuration) are processed using the Default event identity field(s) and Default event type field, specified in item 1.
   Note: The additional event type takes precedence over the default settings. Events which match the filter of the additional event type are processed first and then the remainder are processed using the default fields.
3. If there is more than one additional event type then they are processed in order; that is, events that match the filter for the first additional event type are processed first, then the second, and so on. All remaining events that do not qualify for any additional event type filters are processed using the default fields. The order of additional types can be configured using this wizard.

Note: By default, all additional event types apply to all analytics configurations. However, this can be changed when creating a new configuration.

1. Select the appropriate Historical Event Database field(s) in the Global settings section:

   Default event type field

   An event type is a category of event, for example: FAN-FAILURE, POWER-SUPPLY-FAILURE and DEVICE-FAILURE are event types. By default event type information is stored in the following Historical Event Database field: ALERTGROUP. If you have another set of events that you categorize in a different way, then you can specify additional event type fields in section 2.

   Default event identity field(s)

   The event identity uniquely identifies an event on a specific network resource. By default the event identity is stored in the following Historical Event Database field: IDENTIFIER.

   Default resource field(s)

   A resource identifies a network resource on which events occur. In the example, LON-ROUTER-1 and DAL-ROUTER-5 are examples of resources on which events occur. By default this resource information is stored in the following Historical Event Database field: NODE.

2. If you have another set of events that you categorize in a different way, you can add them as Additional event types.
   1. Select the check box to enable Additional event types.
   2. Click Add new. Add a row for each distinct set of events.
   3. Specify the filters and fields for each set of events. Event Analytics uses these settings to determine event patterns for a set of events. Filters are applied in the order that they appear in the table. You can change the order by using the controls at the end of the row.
      Draft comment: DEIRDRELAWTON
      DL Oct 2019 RTC 69237 and 69238

      Draft comment: posnerke@uk.ibm.com
      KJP Feb 2020 RTC 69798 Updated Type name based on further information from Dev

      Type name

      Specify the type name. Use a name that is easily understandable as it will be used later to identify this event type when associating specific event types with an event analytics configuration.

      Note: If at a later stage you are editing this page, and the event type has been associated with one or more event analytics configurations, then the Type name field is read-only.

      Database filter

      Specify the filter that matches this set of historical events in the Historical Event Database.

      ObjectServer filter

      Specify the filter that matches the corresponding set of live events in the ObjectServer. The ObjectServer filter should be semantically identical to the Database filter, except that you should specify ObjectServer field syntax for the fields.

      Event type field

      An event type is a category of event, for example: FAN-FAILURE, POWER-SUPPLY-FAILURE, and DEVICE-FAILURE are event types. For this set of events, specify the Historical Event Database field that stores event type information.

      Event identity field(s)

      The event identity uniquely identifies an event on a specific network resource. For this set of events, specify the Historical Event Database fields that stores event identity information.

   Note: You can delete any of the additional event types by clicking the trash can delete icon. If the type is already being used in one or more analytics configurations then deleting the type will remove it from those configurations. To ensure your analytics results are fully synchronized you should rerun the affected analytics configurations.