Set Service action
Available for event, alert, and incident workflows |
This action adds to or replaces the service list of an event, alert, or incident with user-specified services.
The standard practice is to place this action after a filter in the Workflow trigger or an action such as Time Filter Action.
This action takes the following inputs:
Action
Select one of the following options:
Replace all service names
Add to any service names that already exist
Note
New service names are always appended to the end of the existing list of services.
Service
The new service names that should go into the service field list of the event or incident. You can provide the service names one of two ways:
Data from another field
Pass data from another selected field in the event or incident.
Text
Provide the new service names as text. Enter the name of the new service without using any quotes.
Event example
Set Service works the same way for events, alerts, and incidents. In all cases, it supplements or substitutes the list of services associated with an event, alerts, or incident with services chosen by the user.
Suppose you want to change the value of the service field for all events coming from a particular source. You can accomplish this by creating an event workflow using a Set Service action.
After setting up the Trigger to activate the workflow only for relevant source events, you can configure the Set Service action as follows:
Action
Replace all service names
Service
Text:
payment
Here is an example event that was processed by this workflow:
Event fields before | Event fields after |
---|---|
{ "description": "CPU spike to 80%", "severity": 5, "source": "ussf-sw99", "check": "cpu", "service": [ "retail", "support" ], "tags": { "devicename": "sw99" } } | { "description": "CPU spike to 80%", "severity": 5, "source": "ussf-sw99", "check": "cpu", "service": [ "payment" ], "tags": { "devicename": "sw99" } } |
Alert example
Suppose that you are setting up data ingestion. After examining the structure of the incoming data, you realize that you can improve the service mapping if you map the application tag tags.application
to the service
field for a subset of your servers which have that information available. You can accomplish this with an alert workflow with Trigger and Set Service actions.
Set the workflow trigger to New or changed alerts (select Changes from anywhere), and add a filter for the application tag:
tags.application != NULL
Configure the Set Service action as follows:
Action
Replace all service names
Service
Select Data from Another Field, choose Tags from the dropdown, choose Add a Tag if necessary, and choose or enter
application
.
Here is an example alert that was processed by this workflow:
Alert fields before | Alert fields after |
---|---|
{ .... "service": [ "retail" ], "tags": { "application": "CheckoutV2" } } | { .... "service": [ "CheckoutV2" ], "tags": { "application": "CheckoutV2" } } |
Incident example
Suppose you want to add a new service name to all new incidents. You can accomplish this by creating an incident workflow with a Set Service action.
After setting up the Trigger, you can configure the Set Service action as follows:
Action
Add to any service names that already exist
Service
Text:
payment
Here is an example incident that was processed by this workflow:
Incident fields before | Incident fields after |
---|---|
{ .... "services": [ "support", "retail" ], } | { .... "services": [ "support", "retail", "payment" ], } |