Cisco Active Network Abstraction Fault Management User Guide, 3.6.1
Event and Alarm Correlation Flow

Table Of Contents

Event and Alarm Correlation Flow

Software Function Architecture

Event Correlation Flow

Event Creation (VNE level)

Event Correlation

Local Correlation (Event Correlator)

Network Correlation (Event Correlator, Flow)

Correlation Logic (Event Correlator)

Alarm Sending (Event Correlator)

Post-Correlation Rule (Event Correlator)


Event and Alarm Correlation Flow


This chapter describes in detail the flow of alarms and events during the correlation process.

Software Function Architecture—Provides an event correlation flow diagram.

Event Correlation Flow—Includes the following sections:

Event Creation (VNE level)

Event Correlation

Correlation Logic (Event Correlator)

Alarm Sending (Event Correlator)

Post-Correlation Rule (Event Correlator)

Software Function Architecture

Figure B-1 Event Correlation Flow (VNE level)

Event Correlation Flow

Event Creation (VNE level)

An event (EventCorrelationData) is created in the VNE level by three different sources:

Device Component (DC)—When processing service alarms.

EventProcessor—After parsing Syslog and SNMP trap.

TCA Extension—After identifying a change in a property in the IMO.

The EventCorrelationData holds the following information:

Table B-1 Event Correlation Data Parameters

Name
Description
Type

Event Type

The type of the event. Alarms with the same Source and Event Type will be considered as a single alarm.

String

Event Sub Type

The sub type of the event (identifies the exact event definition that needs to be loaded).

String

Source

The OID of the IMO on which the event occurred on.

Oid

Correlation key

The object used for correlation

Correlation key array

iFlowForwardData

All forwarding data for the flow (if activate-flow is enabled).

iFlowForwardData

Event time

The time the event occurred (as determined in the VNE).

Long

Description

A description of the event.

String


Event Correlation

Local Correlation (Event Correlator)

Local correlation will be performed if the correlate flag is set true and after waiting the time specified by the correlation-delay value.

The event correlation key is used to extract alarms that were waiting for correlation on that specific key. If alarms with the same correlation key exist the correlation logic is invoked to determine the best candidate of the locally available alarms. If the event did not find an alarm to correlate to, it will be put into the waiting for correlation event queue with its respective correlation key.

Network Correlation (Event Correlator, Flow)

Network correlation will be performed if the event has the activate_flow flag set to true. The following actions will be executed:

1. The Event Correlation application receives an event and it checks the correlation delay depending on whether it is box-level or flow-level correlation.

If it is box-level correlation the event is stored in the application for the correlation delay period and during this period collects all possible root causes having the same correlation delay.

If it is flow-level correlation, then the flow will start after the correlation delay.

2. The flow starting and ending points are defined by the event correlation parameters (see Table B-1).

3. After the flow finishes it will get a message that contains all the collected alarms. Alarms are collected on every DC that the flow intercepts regardless of the original correlation key of the event that triggered it.

Correlation Logic (Event Correlator)

The correlation logic is used for determining the most fitting alarm to serve as a root cause for the specified event. It selects from the alarms, the most fitting alarm (root cause), based on the correlation filters and selects the root cause method.

Alarm Sending (Event Correlator)

Once an event has gone through the correlation process it will be transformed into an alarm and will be sent to the gateway.

Post-Correlation Rule (Event Correlator)

The post-correlation rule is used for performing logic which needs to be performed after the event had been sent. Usually the post-correlation rule is used for triggering additional behaviors such as search for affected services that where influenced by the alarm.