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

Create a custom aggregation policy in ITSI

You can create one or more customized notable event aggregation policies. By default, users assigned the itoa_admin role or itoa_team_admin role can create, modify, and delete aggregation policies. Users assigned the itoa_analyst role can view notable event aggregation policies but cannot modify or delete them.

If you want to use Smart Mode in a custom aggregation policy, you must first create and save the custom aggregation policy. After you save the policy, re-open it to turn on and configure Smart Mode.

What aggregation policies do

An aggregation policy lets you group notable events into episodes based on the following criteria:

  • A field matches a string
  • A field does not match a string
  • A field is greater than a number
  • A field is greater than or equal to a number
  • A field is less than a number
  • A field is less than or equal to a number

The field can be the name of a saved search, the name of a field from a raw event, or the Status, Severity, or Owner field of the notable event. You can create rules based on multiple AND/OR conditions.

An aggregation policy lets you control the grouping of events in the following ways:

  • Split events into multiple episodes by one or more fields, such as source or host.
  • Stop grouping when certain criteria are met. For example, when a certain number of events is reached, the episode has existed for a certain amount of time, or a certain event occurs, such as Severity matches Normal. These are called breaking conditions. You can have multiple breaking conditions.

An aggregation policy lets you take the following actions on an episode:

  • Change the severity
  • Change the status
  • Change the owner
  • Add a comment
  • Run a script
  • Send an email
  • Ping a host
  • Create an incident in ServiceNow (requires the Splunk Add-on for ServiceNow)
  • Create an incident in Remedy (requires the Splunk Add-on for Remedy)
  • Create an incident in VictorOps (requires VictorOps For Splunk)
  • Other custom actions that have been configured

All actions might not be available if role-based permissions are set. For information about episode actions, see Take action on an episode in ITSI.

Create an aggregation policy

When creating a new policy, be mindful of the policies that have already been created. Multiple aggregation policies can be created with filtering criteria that capture the same set or subset of events. If the same notable events are captured by more than one policy, the action rules from each policy are applied to the notable events.

To create an aggregation policy:

  1. Click Configure > Notable Event Aggregation Policies. The default policy and any other policies that have been created are listed.
  2. Click Create Notable Event Aggregation Policy. The Filtering Criteria step opens.

Filtering Criteria

You can create rules for determining which notable events are included in the group based on multiple AND/OR conditions. You can use wildcard characters in fields. You must specify at least one rule.

Field Description
Include the events if Click + Add Rule (OR) to add rules for including events in this group. For example, you could specify severity matches Critical. To include events based on a saved search, type search_name matches <name of saved search>.

Click + Add Rule (AND) to add another rule to the rule block, or + Add Rule (OR) to start a new block of rules that is separated from the previous block by an OR condition.

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 events by field Split events into separate groups based on one or more field names. Each field is considered separately. For example, if you split by name and norm_severity and there are three values for each field, nine episodes are created. A preview shows the events that meet the filtering criteria grouped by the specified fields.
Break episode Add breaking conditions to stop grouping. If the conditions are met, the current episode ends and a new episode is started. For example, an episode might end when the number of events reaches a certain number, the episode has existed for a certain amount of time, or when a certain event (that meets the filtering criteria for the episode) occurs. Use wildcards to search for a string in a field.

For example, you might enter "Break episode if the following event occurs: message matches *status Normal". Note that the breaking event must be included in the episode (in other words it must meet the filtering criteria for the episode).

If an episode is closed in Episode Review, this automatically breaks the episode.

Episode Information Specify how you want episode information to appear in Episode Review. This information is at the episode level and is separate from the information for the underlying notable events in the episode.
  • Same as the first event names the episode using the fields from the first event in the episode.
  • Same as the last event continually updates the episode fields as each new event enters the episode.
  • Static value lets you provide a specific name. If you select Static value for Episode Title or Episode Description, you can use a token such as %title% or %description% to insert the value of a field.

Action Rules

Add action rules to take specific actions on each episode created by the aggregation policy. Action rules are optional. You can define more than one action rule per aggregation policy.

  • Use the If pane to specify the trigger conditions for the action(s).
  • Use the Then pane to specify the actions to take if the trigger conditions are met.

For example, if you want to close the episode and change the severity level to Info when a clearing event comes in, you could specify the following:

If the following event occurs: severity matches Normal, change severity to Info for the episode, add a comment Don't worry for the episode, and change status to Closed for the episode.

Choose from the following default actions:

Action Notes
Change severity For example, change the severity to Critical when the number of events in the episode is greater than 100.
Change status For descriptions of each status, see Update the status of an episode.

Changing an episode's status to Closed through an aggregation policy action rule does not break the episode. Although it's closed, the episode will continue to receive events. There is no way to automatically break an episode when it gets closed. However, you can add an action rule to close an episode when it is broken.

Change owner Episodes are unassigned by default.
Add a comment Does not accept token replacement.
Ping a host Provide the event field that contains the host that you want to ping in the Host field. For example, %server%.
Send an email For information on configuring an email, see Send an email in the ITSI User Manual.
Run a script Provide the file name of the script stored in $SPLUNK_HOME/bin/scripts. For more information, see Configure scripted alerts in the Splunk Enterprise Alerting Manual.
Create an incident in ServiceNow Requires the Splunk Add-on for ServiceNow. For configuration information, see Create a ticket in ServiceNow or Remedy
Create an incident in Remedy Requires the Splunk Add-on for Remedy. For configuration information, see Create a ticket in ServiceNow or Remedy.
Create an incident in VictorOps Requires VictorOps For Splunk. For configuration information, see Create a ticket in VictorOps.

Policy Info

Specify a title and description for your notable event aggregation policy. The policy is enabled by default and immediately takes effect. Disable it if you do not want it to take effect yet.

Click Next and you will see the message that the policy has been successfully created. After the policy has been created, new incoming notable events are grouped in Episode Review according to the criteria in the policy. Note that notable events that existed before the policy was created are not grouped by the policy.

Enable Smart Mode on an aggregation policy

After creating and saving a custom aggregation policy, you can edit the policy to enable and configure Smart Mode. For information on enabling Smart Mode, see Enable Smart Mode in ITSI.

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 Configure > Notable Event Aggregation Policies.
  2. Locate the policy and click Edit > Edit Permissions.
  3. Assign read or write permissions to roles as desired.

    You cannot assign write permissions unless the role possesses the write_itsi_notable_aggregation_policy capability.

  4. Click Save.
Last modified on 29 April, 2019
About the default aggregation policy in ITSI
Group similar events with Smart Mode 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

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