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 withinVMware Smart AssuranceNOTIF
Event information is passed toVMware Smart AssuranceNOTIF 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 theVMware Smart AssuranceNOTIF Editor from the Edit menu.
- Merged into theVMware Smart AssuranceNOTIF Editor based on specifications in the trap_mgr.conf file.Additionally, theVMware Smart AssuranceNOTIF 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 theVMware Smart AssuranceNOTIF Editor, the effects of the modifications take place when the next instance of the relevant event arrives.