OMi event attributes
The set of attributes that the probe receives from OMi events depends on whether the events are resynchronization events or notification events. They can be different.
The availability of certain event attributes depends on the following factors:
- The data inclusion parameters used in the resynchronization query.
- The data in the OMi event, for example if an OMi event is never annotated, its OprEvent contains no annotation attributes. In notification, each forwarded OprEvent carries all attributes available in the event.
The following table describes which event attributes are included for each of the resynchronization inclusion parameters.
Data inclusion setting
Event attributes available
The range of each event token index is from
The bigger the set of event attributes you include, the bigger the overhead that is incurred and the greater the memory usage in HTTP transactions and OprEvent data extraction. To make the probe work efficiently, include only the attributes relevant to production.
Writing probe rules
When customizing probe
rules, you must take care when selecting the fields for the Netcool
the changes made must be able to facilitate event correlation and
deduplication in the ObjectServer.
ID field is the OMi event’s alert key.
ID field is the message ID to the OMi event update,
the OMi origin event’s alert key.
id cannot be used in
@Identifier, otherwise event
correlation will fail.
ID field is unique, the ID field alone is sufficient to be Netcool
@Identifier, however it is a good practice
to combine the ID field with other OMi event attributes to form
create a virtual boundary that helps avoid identifier clash, because
the ObjectServer might be receiving events from other target systems.