Event policy types and evaluation order
This topic provides information about the event policy types, the order in which event policies are evaluated, and the out-of-the-box event policy templates.
Event policy types
The following event policy types are available in BMC Helix Operations Management :
- Basic Enrichment: Processes events with refined slot values to make the events more meaningful.
- Suppression: Automatically drops new events matching the event selection criteria.
- Advanced Enrichment: Processes events with refined slot values based on advanced settings and the defined policy workflow.
- Dynamic Enrichment: An extension of advanced enrichment, this policy helps you enrich events with external data.
- Time Based: Processes events with refined slot values after a scheduled duration of time and based on the advanced settings and the defined policy workflow.
- Correlation: Correlates and combines multiple matching events into a single aggregated event.
- Notification: Notifies users via email or incidents generated for Proactive Service Integration (PSR) about an event occurrence so that actions can be taken.
Policy evaluation order for processing events
In general, events flow through phases based on certain built-in rules. Each phase represents a logical state of processing.
The event policy types and blackout policies are associated with a particular phase through which the event must flow. These policies process each incoming event one phase at a time, and evaluate each event based on the built-in rules.
Before the various policy phases run, the _node_id, _service_id, and _service_name details (entity details) are looked up in
BMC Discovery
for the out-of-the-box or custom class event slots that are defined for looking up the topology information. These results relate nodes and their associated services to the event. For more information about topology lookup slots, see Slot facets.
Based on the built-in rules, policies are automatically run in the following evaluation order, irrespective of the order in which they were configured.
- Basic enrichment policy
- Blackout policy
- Suppression policy
- Advanced enrichment policy and dynamic enrichment policy (between the two policies, that which was configured first is evaluated first)
- Time-based enrichment policy
- Correlation policy
- Notification policy
Multiple configurations in a single event policy execute as independent policies according to the preceding policy phases. For each configuration in the policy, the event selection criteria is checked to process incoming events. If a previously executed policy phase changes the state of an event, then the updated event state is considered for the execution of the next policy phase.
The policy evaluation order supersedes the precedence number specified in the various types of policies. This means, even if you configure a separate event policy for each of the types with varying precedence numbers, the policy evaluation order is used to run the policies.
However, if you have configured the following precedence numbers in event policies, then these conditions apply:
- Multiple event policies of different types with varying precedence numbers, then policies of the same type are run based on the precedence number specified.
- Multiple event policies of different types with the same precedence numbers, then the policy that was created first among the policies is run to process events.
Example scenarios
Where to go from here
To create, edit, enable, disable, or delete an event policy, see Defining event policies for enrichment, correlation, notification, and suppression.
To understand advanced, time-based, and dynamic enrichment policies, see Advanced, time-based, and dynamic enrichment policies.
To understand correlation policies, see Correlating events.
To understand the out-of-the-box event classes and associated slots, see Event classification and formatting.
Comments
The Following Statement and the example provided in Scenario 3 are contradictory.
The policy evaluation order supersedes the precedence number specified in the various types of policies. This means, even if you configure a separate event policy for each of the types with varying precedence numbers, the policy evaluation order is used to run the policies.
However, if you have multiple event policies of different types with varying precedence numbers, then policies of the same type are run based on the precedence number specified.
If Policies are evaluated first by Policy type, within the type they must be handled by precedence, but in the Scenario 3 it indicates they are executed in creation order. Why would they not be by precedence as shown in Scenario 1 and 4?
In essence lower numbered (precedence number) execute first and higher numbered (precedence number) are executed after the lower numbered precedence.
If example I have a Basic Enrichment with a precedence of 100 that changes the information in the message slot. I have a second Advanced Enrichment Policy with a precedence of 200 that also changes the information in the message slot.
The message slot will contain what was done in the Advanced Enrichment policy since Basic policies are evaluated first and Advanced are evaluated after.
If we look at Scenario 4 there is no precedence provided for Policy 4 which makes no sense since you have to have a precedence for a Policy. If the precedence of policy 4 was 150 then Policy 2 would become step 4 instead of step 2.
This area of the documentation could use quite a bit of clarification since the absence of a precedence in some of the Scenarios make it very confusing.
Log in or register to comment.