The pipeline is where most of the logic of cause-and-effect relationships of messages is defined. Each correlation rule has one pipeline listing the pipeline items, each of which contains descriptions of similar messages. Each pipeline item deals with only one message type. You group pipeline items to form a pipeline that has a cause-and-effect relationship among the items. The order of the items in a pipeline is important, as any item is considered to be the root cause of all the items below it.
When AEC receives many messages that are matched by different pipeline items, it chooses the highest item and determines that message to be the root cause. For example:
Pipeline Item # 1: Ping Failure on Server Pipeline Item # 2: Service Critical on Server
The Promote/Demote feature lets you modify the order.
The main components of pipeline items are as follows:
This component indicates conditions (message string and node name) under which the item triggers the rule.
The Local Correlation and Local Reset Events describe the message strings that are sent to the Event Console at maturity (reset) of the correlation rule. In this way they are similar to the Root Correlation and Root Reset Events.
However, you can configure AEC to use either the Local or the Root Correlation (Reset) message by setting one of two flags. The flags Use Root Correlation Event and Use Root Reset Event let the Root Correlation and Root Reset messages override the Local Event Messages.
The advantage of setting the Root Correlation (Reset) message is that, for example, you must configure the correlation (Reset) message at only one place. However, the disadvantage may be that, regardless of the root cause, AEC generates the same formatted message (although, using tokens, it can be specialized to reflect the root cause event in each case).
The disadvantage of setting the Local Correlation (Reset) message is that you must configure these messages at each of the individual pipeline items. This lets you configure different messages to be sent to the Event Console when you have different root causes.
You can use the Exclusion Event with the Match Event to help restrict the events that match the matching element. For example, you could define a Match Event to match any events containing the text ABC but exclude any events also containing the text DEF.
If you defined the following events in a rule, all Application Failure events are matched except for those that refer to lab applications.
Match Event: ^Application .* has failed$
Exclusion Event: ^Application LAB_APP1|LAB_APP2 has failed$
You can also use the Exclusion Event to restrict the matching of any element of an event. For example, you could use it with the Match Event to match a given event from all servers except those specified in the Node field of the Exclusion Event.
The Reset Request Event lets you reset an individual pipeline item.
Set the Enable Local Reset Request Event flag to reset an individual pipeline item. In addition, this lets you decrement the counter for the number of matching events associated with a pipeline item when a Reset Request Event is received. When you set this flag, a pipeline item is reset only when the counter is decremented to zero.
For example, suppose that you have five automated procedures that generate consecutive events to indicate that they have started and completed successfully. Using this flag, you can match the five start events and decrement the counter by assigning the Reset Request Event to the completion event. If the matching element has not reset at the end of the maturity period, one or more of the automated procedures must have failed to complete, and the rule can generate a Root Correlation Event to indicate that.
Configured at the rule or matching element level, you can use the Reformat Event to change the format of a matched event. The reformatted event can consist of the following:
For example, suppose that you want to prefix any event that matches Pipeline Item # 1 with the string %AEC_HOLD. This prefix could then be identified by a standard Event Management message record/action, resulting in the event being placed in the Held Messages queue.
It is possible that a higher pipeline item can be matched after a correlation event has been generated (for example, where the rule matures before the highest pipeline item is matched). In that case, you may want to generate an event indicating that the previous correlation event has been superseded. A Revised Correlation Event can consist of the following:
For example, if Event B was initially determined to be the root cause but was subsequently replaced by Event A, you could generate the Revised Correlation Event “Event A has been replaced by Event B as the root cause for Problem X” using the template “&TEXT has been replaced by &RCTEXT as the root cause for Problem X.”
The Reset Request Acknowledge Event can be generated whenever a rule or pipeline item resets in response to a Reset Request Event.
If the rule is configured to generate impact events, the pipeline item Use Root Impact Event flag is set to false, and this is not the root cause item, this output event is generated to the Event Console after maturity to report the events impacted by the root cause.
|
Copyright © 2010 CA.
All rights reserved.
|
|