ECI processing overview

Event Configuration Information (ECI) processing involves two steps:
  • Determining whether a raw event should be processed to create an unpublished notification that is passed to notification processing (that is, filtering events at the lowest level possible).
  • Determining the instance/class/event name of the notification that should be created if the event is processed.
    ECI processing and NCI processing steps within Smarts NOTIF shows the overall flow of ECI processing steps. Chapter 3, Notification Configuration Information Processing. provides details on how ECI processing steps relate to the NCI processing steps.
    ECI processing and NCI processing steps within
    VMware Smart Assurance
    NOTIF
    Event information is passed to
    VMware Smart Assurance
    NOTIF through a common structure. This packaging allows for common information to logically identify an event and pass additional information that may be used to further convert raw information into a specific notification.
    The packaging of the event data is performed by the specific adapter and should be referenced by the individual adapter documentation. The general format of the wrapper is explained in
    “Raw event normalization” on page 26
    .
    Events are grouped by three identifying fields: baseID, sub1ID, and sub2ID. An event is only processed if an associated ECI is found to match these fields.
    After an ECI matches a given raw event, a series of configuration tests are performed on the raw event to determine if the event should be processed further. Configuration test checks on a raw event include the following parameters:
Event Active
The event must be active in order to be processed.
Is Managed
Un-managed objects are not processed.
<
x
events in
y
minutes
Sliding window squelch.
ASL hook
Hard-coded test of other values.
Setting up ECI configuration parameters on page 32
provides details on all the available ECI configuration values. Failure of any raw event test prevents the ECI process from determining what unpublished notification will be created or updated.
After basic event tests are complete, the event is formed into a notification. This phase of processing allows the instance, class, event name and all notification values to be changed based upon event data with variable substitution from raw event data. After this point, it is an unpublished notification that is no longer connected to the raw event, though the event data may be passed in the notification.
ECI configurations are saved as *.ncf files and remain unchanged through the stopping and starting of the
Adapter Platform
(OI) server.
There are several ways in which ECI objects can be loaded or added into a SAM/
Adapter Platform
server. ECI objects can be:
  • Defined by *.ncf files provided from other sources (that is, pre-packaged configurations).
  • Created directly from the
    VMware Smart Assurance
    NOTIF Editor from the Edit menu.
  • Merged into the
    VMware Smart Assurance
    NOTIF Editor based on specifications in the trap_mgr.conf file.
    Additionally, the
    VMware Smart Assurance
    NOTIF Editor provides a means to copy an existing ECI object as the basis for another, and to save all defined configurations to an .import file.
    After a raw event arrives and the best ECI object match is found, the behavior of the configuration object is performed relative to the event. If ECI objects are modified with the
    VMware Smart Assurance
    NOTIF Editor, the effects of the modifications take place when the next instance of the relevant event arrives.