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 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.
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 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.|
A notable event can belong to multiple episode if it matches the criteria for those episodes.
Ingest SNMP traps in ITSI
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