Configure episode filtering and breaking criteria in ITSI

Filtering criteria in IT Service Intelligence (ITSI) aggregation policies are a set of WHERE clauses that apply to fields within in a notable event. Any notable event that matches the filtering criteria of a particular aggregation policy is processed as a member of that aggregation policy. For more information about aggregation policies, see Overview of aggregation policies in ITSI.

The field names in original events that conflict in the itsi_tracked_alerts index are renamed with the prefix orig_*. To filter or split by fields in original events, append orig_ to the field name. For example, use orig_sourcetype instead of sourcetype. sourcetype means the sourcetype of generated notable events in the itsi_tracked_alerts index, rather than the sourcetype of original events.

Filtering criteria

Filtering criteria determine which events are processed by an aggregation policy. For example, the filtering criteria host="*.test.splunk.com" AND description="*disk*" includes any events with a host name ending in .test.splunk.com and a description containing the word "disk". Any notable event that matches the filtering criteria of a particular aggregation policy is processed as a member of that policy. Therefore, a single notable event can be a member of many unique policies if it matches their filtering criteria.

You can match on any fields in the event. The syntax for the field value doesn't follow standard SPL. The value must exactly match the field value in the event, including capitalization and spaces. You can use asterisks (*) as wildcards. For example, location does not match webserver*.

Use an AND clause to add additional rules to the rule block, or add an OR clause to start a new rule block. For example, if there are three rules in the first block and two rules in the second block, the total clause would read "(Rule1 AND Rule2 AND Rule3) OR (Rule1 AND Rule2)".

Split by field

You can provide an optional split by field to make episodes relevant to one or more specific fields. The split by field divides events into separate episodes based on one or more field values. For example, you can split by host to create episodes based on hosts, or split by datacenter and application to create episodes about infrastructure for each application focused on the data center from which it's served. Each event processed by a particular policy is placed in a unique episode based on the raw value of the split by field. Therefore, it's possible for a single policy to create multiple episodes.

The following example visually illustrates how an aggregation policy filters and splits events based on their field values. Suppose each notable event is a shape in the following diagram. Their fields include shape, color, and sides:

The first policy only includes shapes with four or more sides. The shapes that meet the criteria are then split into separate episodes based on their exact shape. One episode contains only pentagons and another contains only squares.

The second policy only includes triangles. The resulting triangles are then split into episodes based on their color, so there are separate episodes for gray, light green, and green triangles.

The third policy is the default aggregation policy. It doesn't include any filtering criteria, so it catches all events that don't match the filtering criteria of any other policies. For more information, see About the default aggregation policy in ITSI.

Break episode

Breaking criteria are conditions that determine where one episode ends and another begins. Breaking criteria help a user distinguish between time ranges of a particular problem's existence. These criteria can be any combination of a maximum pause in the flow of notable events (maximum 24 hours), a maximum count of events in the episode, and a special breaking event represented as a WHERE clause of field values. When the breaking criteria are met, the current episode can no longer have any events added to it, and a new episode starts with the next notable event.

For example, you might enter Break episode if the following event occurs: message matches *status Normal. This rule breaks an episode once it receives a normal notable event, indicating the problem is resolved.

When an episode is closed, either in Episode Review or through an aggregation policy, it automatically breaks.