Splunk® IT Service Intelligence

Administration Manual

Acrobat logo Download manual as PDF

Splunk IT Service Intelligence version 4.0.x reached its End of Life on January 19, 2021. See the Splunk Software Support Policy for details. For information about upgrading to a supported version, see Plan an upgrade of IT Service Intelligence.
This documentation does not apply to the most recent version of Splunk® IT Service Intelligence. Click here for the latest version.
Acrobat logo Download topic as PDF

Notable event aggregation policies overview for 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.

ITSI provides a default aggregation policy to ensure 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 that match no other aggregation policy's filtering criteria. Otherwise, this aggregation policy functions like any other policy. For more information, see About the default aggregation policy in ITSI.

You can also create your own aggregation policies if you're familiar with your data and want to define very precisely how events are grouped. For instructions, see Create a custom aggregation policy in ITSI.

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.

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

The 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.

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.

A notable event can belong to multiple episode if it matches the criteria for those episodes.

See also

Last modified on 03 March, 2020
Notable Event Actions SDK reference
About the default aggregation policy in ITSI

This documentation applies to the following versions of Splunk® IT Service Intelligence: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.1.0, 4.1.1, 4.1.2, 4.1.5, 4.2.0, 4.2.1, 4.2.2, 4.2.3, 4.3.0, 4.3.1, 4.4.0, 4.4.1, 4.4.2, 4.4.3, 4.4.4, 4.4.5

Was this documentation topic helpful?

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters