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.
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:
- You group all disk-related events for a particular set of servers into unique sets for each server.
- You define rules that send a single email to a particular user at the beginning of any problem.
- You define a particular clearing event that immediately closes all events in the episode.
- 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.
- 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:
|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 are a set of WHERE clauses that apply to fields within in a notable event. For example,
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 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 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 perform automated actions when an episode's activation criteria are met. Action rules consist of the following distinct parts:
|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.
- Click Configuration > Notable Event Aggregation Policies.
- Locate the policy and click Edit > Edit Permissions.
- 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.
- Click Save.
Clear all notable events in ITSI
About the default aggregation policy in ITSI
This documentation applies to the following versions of Splunk® IT Service Intelligence: 4.9.0, 4.9.1, 4.9.2, 4.9.3, 4.9.4, 4.9.5, 4.9.6, 4.10.0 Cloud only, 4.10.1 Cloud only, 4.10.2 Cloud only, 4.10.3 Cloud only, 4.10.4 Cloud only, 4.11.0, 4.11.1, 4.11.2, 4.11.3, 4.11.4, 4.11.5, 4.11.6, 4.12.0 Cloud only, 4.12.1 Cloud only, 4.12.2 Cloud only, 4.13.0, 4.13.1, 4.13.2, 4.14.0 Cloud only, 4.14.1 Cloud only, 4.14.2 Cloud only, 4.15.0, 4.15.1, 4.16.0 Cloud only
Feedback submitted, thanks!