Configure episode action rules in ITSI
Set up action rules within an aggregation policy in IT Service Intelligence (ITSI) to take automated actions when an episode's activation criteria are met. Action rules are optional. You can define more than one action rule per aggregation policy. For more information about aggregation policies, see Overview of aggregation policies in ITSI.
For example, if you want to close the episode and change the episode severity level to Info
when a notable event comes in, you could specify the following rule:
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.
Action rules consist of the following distinct parts:
Component | Description |
---|---|
Activation Criteria | A set of WHERE clauses that determine when the trigger conditions for a specific action are met. |
Action | 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. |
Activation criteria
Choose from the following conditions that trigger an action:
Trigger condition | Notes |
---|---|
The following event occurs | Trigger an action when an event containing specific field values is added to the episode. For example, when severity matches Critical . You can match on any fields in the event.
|
The episode existed for | Trigger an action if the episode has existed for a given amount of time, in seconds. You might close an episode if it's existed for 86400 seconds (one day). |
The number of events in the episode is | Trigger an action if the number of events in the episode exceeds or does not reach a certain limit. By default, an episode breaks when it reaches 10,000 events, and a new episode is created. |
The flow of events into the episode paused for | Trigger an action if the episode hasn't received any events for a given amount of time, in seconds.
The maximum value for this field is |
You can enable time-based actions to run only one time per episode by enabling the Run Time-Based Actions Once toggle on the Notable Event Aggregation Policy page. For example, if you create an action to add a comment after an episode has existed for 60 seconds, a comment will only be added once for the episode. There are 2 conditions that trigger time-based actions:
- The episode existed for
- The flow of events into the episode paused for
Action rules
Choose from the following actions to take on an episode:
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 |
Change owner | Episodes are unassigned by default. |
Add a comment | Does not accept token replacement. |
Ping a host | Determine whether a host is still active on the network by pinging the host. Provide the event field that contains the host that you want to ping in the Host field. For example, %server% .
|
Send an email | Send an email to the appropriate team as a result of an event. Make sure the mail server is configured in the Splunk platform before configuring this action.
You can use tokens in the email subject or message. The tokens are replaced with field values in the email message. The following episode fields are available:
You can also use fields contained in the last event in the episode. If a field isn't present in the last event, although it may exist in other events in the episode, ITSI does not replace the token with the field value in the email message. Optionally, select a message template which populates the message field with a preconfigured email body. Tokens are supported in templates. Click Manage templates to configure additional templates or remove existing ones. Anyone with the admin, itoa_admin, or itoa_analyst role can create and edit email templates. Once you create a template it's available for selection in all aggregation policies and is not policy-specific. |
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.
|
External episode actions
In addition to the default episode actions included with ITSI, you can also integrate with certain third-party alerting systems. Once you configure an integration, you can set up action rules that create tickets in those third-party systems when certain activation criteria are met.
ITSI offers the following external actions you can take within integrated systems:
Action | Notes |
---|---|
Create an incident in ServiceNow | Requires the Splunk Add-on for ServiceNow. For configuration information, see Integrate ITSI with ServiceNow. |
Create an incident in BMC Remedy | Requires the Splunk Add-on for BMC Remedy. For configuration information, see Integrate ITSI with BMC Remedy. |
Create an incident in Splunk On-Call (VictorOps) | Requires Splunk On-Call. For configuration information, see Integrate ITSI with Splunk On-Call (VictorOps). |
For more information about the integrations shipped with ITSI, see Overview of episode ticketing integrations in ITSI.
Configure episode information and episode dashboards in ITSI | Dispatch episode actions to a remote ITSI instance |
This documentation applies to the following versions of Splunk® IT Service Intelligence: 4.14.0 Cloud only, 4.14.1 Cloud only, 4.14.2 Cloud only, 4.15.0, 4.15.1, 4.15.2, 4.15.3, 4.16.0 Cloud only, 4.17.0, 4.17.1
Feedback submitted, thanks!