Table Of Contents

Troubleshooting Faults

Software Function Architecture

Event Correlation Flow

Event Creation (VNE Level)

Precorrelation Rule (Event Correlator)

Local Correlation (Event Correlator)

Network Correlation (Event Correlator, Flow)

Correlation Logic (Event Correlator)

Alarm Sending (Event Correlator)

Interrupt Alarm (Event Correlator)

Post-Correlation Rule (Event Correlator)

Troubleshooting Faults

---

This chapter describes in detail the flow of alarms and events during the correlation process, and includes the following sections:

• Software Function Architecture

• Event Correlation Flow

Software Function Architecture

Figure 13-1 Event Correlation Flow (VNE Level)

---

Note See Managing Polling Groups, page 14-4 (Part 5 of this guide) for a detailed description of each parameter.

---

1. Decision based on the value of drop-event.

2. Decision based on the value of correlate.

3. Decision based on the value of send_uncorrelated.

4. Decision based on the value of is-correlation-allowed.

Event Correlation Flow

This section includes the following information:

• Event Creation (VNE Level)

• Precorrelation Rule (Event Correlator)

• Local Correlation (Event Correlator)

• Network Correlation (Event Correlator, Flow)

• Correlation Logic (Event Correlator)

• Alarm Sending (Event Correlator)

• Interrupt Alarm (Event Correlator)

• Post-Correlation Rule (Event Correlator)

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 13-1 Event Correlation Data Parameters 

Name	Description	Type
Event Type	The type of the event. Alarms with the same Source and Event Type are considered as a single alarm.	String
Event Subtype	The subtype 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.	OID
Correlation key	The string used for local correlation.	String
Flow destination	The destination of a flow (if activate-flow is enabled).	Object
Flow starting point	The beginning of a flow (if activate-flow is enabled).	XID
Event time	The time the event occurred (as determined in the VNE).	Long
Description	A description of the event.	String

Precorrelation Rule (Event Correlator)

If the drop-event flag is not set to true the event is processed by a set of precorrelation rules.

The following are the potential actions taken by the precorrelation rules:

1. Stop correlation.

2. Continue with next rule (if any).

3. Stop subsequent precorrelation rule processing (for the current processed event).

Currently there is one precorrelation rule:

•PreCorrelateDeviceUnreachableRule—This rule is used for special handling of device-unreachable and link-down correlation.

Local Correlation (Event Correlator)

Local correlation is performed if the correlate flag is set to 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 is put into the "waiting for correlation event" queue with its respective correlation key.

Network Correlation (Event Correlator, Flow)

Network correlation is performed if the event was not locally correlated and the activate_flow flag is set to true.

The following actions are performed:

1. A trigger message of the type specified for the specific event definition is created.

2. The message is sent to the Event Correlator with the flow-delay specified and triggers the flow to collect alarms.

3. The flow starting and ending points are defined by the event correlation parameters (see Figure 13-1).

4. After the flow finishes it gets 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.

5. Next, the completion of the flow initiates an Interrupt Alarm based on the alarms collected with the correlation key of the event that triggered the flow.

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 chooses from the alarms with the highest weight the alarm that is closest in time to the event that it is being correlated.

Alarm Sending (Event Correlator)

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

Interrupt Alarm (Event Correlator)

After the alarm is created it is interrupted on the correlation key of the original event that created it. The interrupt alarm causes all the events waiting for correlation to compare against the correlation key that is passed to the method to correlate them.

The interrupt alarm is then invoked recursively on every new alarm with the key being the source OID of the new alarm.

Post-Correlation Rule (Event Correlator)

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

Posted: Mon Sep 24 07:29:27 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.