Configuring event pattern processing
You can configure how patterns are derived from related events by editing properties in the generated NOI Shared Configuration properties file.
In Netcool®
Operations Insight® v1.4.1.2 and later
(corresponding to Netcool/Impact v7.1.0.13 and later)
it is recommended to use the Event Analytics Configuration Wizard
instead of the ./nci_trigger
command to edit properties in the NOI Shared
Configuration properties file.
- You should perform this configuration task prior to running any related events configurations that use the global type properties associated with event pattern creation. It is expected that you will perform this configuration task only when something in your environment changes that affects where type information is found in events.
- Avoid configuring multiple types for the same event. By default,
Identifier
is used to identify the same events. This can be overridden, but assuming the default, you should setup the type properties so that events identified by the sameIdentifier
only have one type value. For example, if there are 10 events withIdentifier=xxx
and you want to use atype=ALERTGROUP
then the events should have the same ALERTGROUP. If events for the sameIdentifier
have many alert group values, the first one will be picked.
The default NOI Shared Configuration properties file is divided into sections, where each section contains a number of properties that allow you to instruct how Netcool/Impact handles a variety of operations, such as how it should handle event pattern creation. There are three categories of event pattern creation properties defined in the NOI Shared Configuration properties file:
- Properties related to configuring which table columns in the Historical Event Database that Netcool/Impact should use in performing the event pattern analysis.
- Properties related to configuring the default unique event identifier and event type in the Historical Event Database that you want Netcool/Impact to use when there is no match in the event type index related properties.
- Properties related to configuring one or more event identity and event type indexes.
Global type | Description | Example |
---|---|---|
Properties related to configuring table columns in the Historical Event Database | ||
|
Specifies the name of the table column or columns in the Historical Event Database that Netcool/Impact should use in performing the event pattern analysis. |
The NOI Shared
Configuration
properties file that you generate with the
Note: You should use the default value,
NODE . |
|
Specifies the name of the table column in the Historical Event Database that contains the name of the server associated with any particular event that arrives in the Historical Event Database. |
The NOI Shared
Configuration
properties file that you generate with the
Note: You should use the default value,
SERVERNAME , where possible. |
|
Specifies the name of the table column in the Historical Event Database that contains the server serial number associated with any particular event that arrives in the Historical Event Database. Note that the server serial number should be unique. |
The NOI Shared
Configuration
properties file that you generate with the
Note: You should use the default value,
SERVERSERIAL , where possible. |
Properties related to configuring the default unique event identifier and event type in the Historical Event Database | ||
|
This property contains the database field in the Historical Event Database that you want to specify as the default Event Identity. An Event Identity is a database field that identifies a unique event in the Historical Event Database. When you configure a related events configuration, you select database fields for the Event Identity from a drop-down list of available fields. In the User Interface, you perform this from the Advanced tab when you want to override the settings in the configuration file. Netcool/Impact uses the database
field specified in this property as the default Event Identity when there is no match in the
value specified in the Note: The database field specified for this property should not contain a timestamp
component.
|
The NOI Shared
Configuration
properties file that you generate with the
|
|
Specifies the default related events type to use when creating an event pattern to generalize. Netcool/Impact uses this default
related events type when there is no match
in the Note: You choose the related events type
values based on the fields for which you want to create a generalized pattern. For example, if you
want to create a pattern and generalize it based on the EVENTID for an event, you would specify that
value in this property.
When the related events configuration completes and you create a pattern for generalization, the pattern generalization screen will contain a drop down menu that lists all of the EVENTIDs found in the Historical Event Database. You can then create a pattern/rule that will be applied to all EVENTIDs selected for that pattern. This means that you can expand the definition of the pattern to include all types, not just the types in the Related Events Group. |
The NOI Shared
Configuration
properties file that you generate with the
|
Properties related to configuring one or more event identity
and event type indexes. You should specify values for each of the properties described in this
section. Note: You can delete any of the additional event types by removing the
relevant lines from this file. If the type is already being used in one or more analytics
configurations then deleting the type will remove it from those configurations, and the default
event type will be used. To ensure your analytics results are valid you should rerun the affected
analytics configurations.
|
||
|
Specifies the number of types to use in the NOI Shared Configuration properties file for the global type configuration. There is no limit on how many types you can configure. |
The following example specifies two types for the global type configuration:
Thus, you would define the other
|
|
Specifies the database field in the Historical Event Database that you want to specify as the Event Identity. Multiple fields are separated by commas. |
The following shows an example of a database field used as the Event Identity:
The following shows an example of multiple database fields used as the Event Identity:
|
|
Specifies the event type to return for pattern generalization. Note: The returned event types display in the event type drop down menu in the pattern
generalization screen.
|
The following example shows an event type to return for pattern generalization:
|
|
Specifies an Historical Event Database filter
that defines a set of events. For the set of events defined by this filter, the event type will be
found in the table column or columns in the Note: It is recommended that you create one or more database indexes on the reporter status table
for the fields used in the
type.index.filterclause to speed up
the query. |
|
|
Specifies an ObjectServer filter to filter matching event types. Note: The filter that you specify for the
type.index.osfilterclause property should be semantically
identical to the filter that you specify for the
type.index.filterclause property, except for this property you
use the ObjectServer syntax. |
|
|
Specifies a user-defined name for this event type. The name should be easily understandable as it
will be used later to identify this event type when associating specific event types with an event
analytics configuration.
Note: You can rename any of the additional event types by modifying the
relevant
type.index.typename value. If the type is already being
used in one or more analytics configurations then renaming the type will remove it from those
configurations. You must then manually add the newly name type to each of the affected analytics
configurations. To ensure your analytics results are fully synchronized you must rerun the affected
analytics configurations. |
|
The following example sets the Event Identity, defines a set of events, and finds the type information in the specified table column or columns in the Historical Event Database:
type_number_of_type_configurations=1
type.0.eventid=NODE,SUMMARY,ALERTGROUP
type.0.eventtype=ACMEType
type.0.filterclause=( Vendor = 'ACME' )
type.0.osfilterclause=Vendor = 'ACME'
More specifically,
the examples shows that if there is an event and the value for Vendor
for
that event is ACME
, then look in the table column
called ACMEType
to find the event type.
The
following example expands on the previous example by showing two configurations
(as indicated by the value 2
in the type_number_of_type_configurations
property:
type_number_of_type_configurations=2
type.0.eventid=NODE
type.0.eventtype=ACMEType
type.0.filterclause=( Vendor = 'ACME' )
type.0.osfilterclause=Vendor = 'ACME'
type.0.typename=Vendor = Type0
type.1.eventid=NODE,SUMMARY,ALERTGROUP
type.1.eventtype=TAURUSType
type.1.filterclause=( Vendor = 'TAURUS' )
type.1.osfilterclause=Vendor = 'TAURUS'
type.1.typename=Vendor = Type1
0
first.
If the event matches the filter defined in configuration 0
,
then Netcool/Impact defines
the event's type as defined in the filter. If the event does not match
the filter defined in configuration 0
, Netcool/Impact attempts
to match the event to the filter defined in configuration 1
.
If the event matches the filter defined in configuration 1
,
then Netcool/Impact defines
the event's type as defined in the filter. Netcool/Impact continues
this processing sequence for as many configuration types you define.If no events match the filters defined in the defined configuration types you define, Netcool/Impact uses the default configuration to determine where type and identity are to be found.