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:

• Refinement: Performs conditional enrichment on topology lookup slots such as the host.
• Basic Enrichment: Processes events with refined slot values to make the events more meaningful. Quickly enriches popular event slots such as Severity, Priority, Category, Location, and Message.
• Suppression: Automatically drops new events matching the event selection criteria.
• Advanced Enrichment: Processes events with refined slot values based on advanced and conditional enrichment settings. These settings apply on a wide range of event slots by using matching criteria, functions, and variables in the defined policy workflow.
• Dynamic Enrichment: An extension of advanced enrichment, this policy helps you enrich events with external data, which is stored in a csv file. 
• 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. Perform delayed event enrichment by using this policy type.
• Correlation: Correlates and combines multiple matching events into a single aggregated event and reduces event noise.
• 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.

Based on the built-in rules, policies are automatically run in the following evaluation order. Events are processed in the same order.

1. Normalize
   The normalize phase is a system-defined phase. In this phase, the default values for internal event slots, for example, Modified (_modified_time) and Occurred (creation_time) are set. This phase also validates the event slots and the event class name. If the slots do not confirm to the event schema, they are listed as unmapped data in the event. If the class name is invalid, the Event-base-event-class is considered as the default class for the event. 
2. Refinement policy
   Use the refinement policy to enrich event topology slots such as the Host (source_hostname). This event policy phase allows you to perform limited advanced event enrichment and dynamic event enrichment. Advanced event enrichment in this phase is limited to using the If, Enrich, and Variable actions.
   For more information about these actions, see Actions-for-advanced-and-time-based-enrichment.
   To learn more about the refinement policy, see Event-enrichment-through-refinement-policies.
3. Topology enrichment
   Topology enrichment is a system-defined phase. In this phase, the Service ID (service_id) and Node ID (_node_id) details (entity details) are looked up from BMC Discovery according to the topology lookup slots in the event class. For example, the source_hostname slot for the Event class. These slots are attributes of service models in BMC Helix AIOps. Based on the topology lookup slots, the system uses BMC Discovery APIs to fetch the node details and enriches them in the event. The API query retrieves the node details by using the AND or OR operators in the query conditions and associates multiple nodes to an event. 
   Consider populating the cdmclass slot in the event with the specific node kind that is present in BMC Discovery. This process makes the node lookup quicker because only specific node kinds are associated with the event instead of all possible nodes. 
   To learn more about topology enrichment, see Event-enrichment-with-topology-information.
   To learn how to retrieve CI attributes, see the LookupNodeDetails function.
4. Basic enrichment policy
   Use the basic enrichment policy to quickly enrich popular event slots such as Severity, Priority, Category, Location, and Message. 
5. Out-of-the-box suppression policies and configurable suppression policies
   The system executes the out-of-the-box suppression policies internally. For more information, see Out-of-the-box-event-policies-and-templates.
   Use the suppression policy to suppress unnecessary events and reduce event noise. For more information, see Event-deduplication-and-suppression-for-filtering-unwanted-events. 
6. Blackout policy
   Incoming events are blacked out based on the conditions configured in the blackout policy. Blackout policies have a different workflow than event policies.
   For more information, see Blackout-policies.
7. Time-based enrichment policy
   Use the time-based enrichment policy to process events after a specific duration. Events are retrieved and enriched after a delayed duration. For an event, only one time-based policy is applied. However, you can configure up to a maximum of three time-based configurations in a single time-based policy. Time-based policies execute 30 seconds to a minute after the delayed duration lapses because the scheduler checks every 30 seconds whether the system should execute the time-based policy.
   For more information, see Advanced-time-based-and-dynamic-enrichment-policies.
8. Advanced enrichment policy and dynamic enrichment policy (between the two policies, that which was configured first is evaluated first)
   Use the advanced enrichment policy to enrich events and add additional context to events to help operators resolve events efficiently. You can use functions and variables in the policy workflow to enrich events. You can also retrieve and enrich existing events by using the advanced enrichment policy. For more information, see Building-a-policy-workflow-for-advanced-and-time-based-enrichment.
   Use the dynamic enrichment policy to enrich events with external data. For more information, see Dynamically-enriching-events-with-external-data.
9. Correlation policy
   Use the correlation policy to group related events, detect event patterns, and reduce event storms. For more information, see Event-correlation-for-aggregating-related-events.
10. Notification policy
    Use the notification policy to send email notifications and generate incidents in BMC Helix IT Service Management to notify operators about important issues or changes. For more information, see Event-based-notifications-for-alerting-users.
    

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 policies are run according to the policy evaluation order to process events.
• Multiple event policies of the same type with the same precedence numbers, then the policy that was last modified 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 refinement policies, see Event-enrichment-through-refinement-policies.

To understand the out-of-the-box event classes and associated slots, see Event-classification-and-formatting.