Overview of aggregation policies in ITSI

A notable event aggregation policy is the fundamental unit of event grouping in IT Service Intelligence (ITSI). Aggregation policies are the data structure the Rules Engine uses to group notable events into deduplicated episodes and organize them in Episode Review. These episodes have their own title, description, severity, status, and assignee that are separate from the individual notable events within the episode. Aggregation policies are also the container for action rules that automate episode actions, such as sending an email or pinging a host.

The default aggregation policy shipped with ITSI ensures that all events are grouped into episodes and none are skipped. Unlike custom aggregation policies which can potentially receive events that also appear in other policies, the default policy only receives notable events matching no other aggregation policy's filtering criteria. Otherwise, it functions like any other policy. For more information, see About the default aggregation policy in ITSI.

You can enable Smart Mode on an aggregation policy to employ machine learning algorithms to group events. For more information, see Group similar events with Smart Mode in ITSI.

Example

When taken together, the components of a notable event aggregation policy enable the Rules Engine to simultaneously deduplicate and categorize events, as well as execute automated actions.

The following example illustrates a series of simultaneous configurations you can make within a single policy:

1. You group all disk-related events for a particular set of servers into unique sets for each server.
2. You define rules that send a single email to a particular user at the beginning of any problem.
3. You define a particular clearing event that immediately closes all events in the episode.
4. A certain volume of events or amount of time since the start of the problem might result in the elevation of all events within the episode to a critical severity and trigger another email to a broader audience.
5. Simultaneously, each event that comes in could result in an immediate ping of the host indicated in the event.

Aggregation policy components

An aggregation policy has three distinct components:

Component	Topic
Filtering, splitting, and breaking criteria	Configure episode filtering and breaking criteria in ITSI
Episode information	Configure episode information and episode dashboards in ITSI
Action rules	Configure episode action rules in ITSI

Filtering criteria

Filtering criteria are a set of WHERE clauses that apply to fields within in a notable event. For example, host="*.test.splunk.com" AND description="*disk*". Any notable event that matches the filtering criteria of a particular aggregation policy is processed as a member of that aggregation policy. Therefore, a single notable event can be a member of many unique episodes, because it's grouped by all policies for which it matches the filtering criteria.

Split by field

The split by field prevents aggregation policies from triggering a large quantity of duplicated actions. Each event processed by a particular notable event aggregation policy is placed into a unique episode based on the value of the configured split by field in that event. In this manner it's possible for a single aggregation policy to produce many deduplicated episodes.

For example, an administrator might split events by host, allowing for the existence of a unique deduplicated episode for each value of host present in the notable events that matches the policy's filtering criteria. As a result, actions are executed uniquely for each value of host so you can manage notable events more easily in Episode Review.

Breaking criteria

Breaking criteria are conditions used to determine where one episode ends and another begins. Breaking criteria help you distinguish between time ranges of a particular problem's existence. These criteria can be any combination of a pause in the flow of notable events, a certain count of events in the episode, or some special clearing or breaking event criteria represented as a WHERE clause of field values.

When the breaking criteria is met, the current episode breaks and a new episode begins with the next notable event.

Episode information

Episode information determines how episodes that are grouped by an aggregation policy appear in Episode Review. You can choose whether episode fields such as title, severity, and status get their values from the first event in the episode, the last event, or a custom value. You can also add a custom JSON-formatted dashboard to display in each episode grouped by the policy.

Action rules

Action rules perform automated actions when an episode's activation criteria are met. Action rules consist of the following distinct parts:

Component	Description
Activation Criteria	Activation criteria are a set of WHERE clauses that determine when the trigger conditions for a specific action are met.
Action	Actions are a set of THEN clauses that represent the things being done to an episode when the activation criteria are met. Examples of actions taken on episodes include changing the status, severity, or owner of an episode. Actions can also be taken on things other than the specific episode that triggered the action. Examples of external actions include pinging a host, sending an email, or creating a ticket in an external ticketing system.

Set aggregation policy permissions

After you create a notable event aggregation policy, set read/write permissions for it to control who can modify or read it.

1. Click Configuration > Notable Event Aggregation Policies.
2. Locate the policy and click Edit > Edit Permissions.
3. Assign read or write permissions to roles as desired. You can't assign write permissions unless the role possesses the write_itsi_notable_aggregation_policy capability.
4. Click Save.