Matching conditions for the Rules Engine
About matching conditions in rules for Splunk On-Call alerts.
Matching conditions determine when a rule is applied. You can choose any field that exists within the payload of an alert and match on a specific value for that field using a direct match, wildcard matching, or by using a regular expression.
Requirements
This integration is compatible with the following versions of Splunk On-Call:
Enterprise
Field names
When viewing an incident in the timeline, field names are on the left and values are on the right:
In the previous example, the field of interest is the entity_display_name field and the value that matters is the phrase This is an incident!. The matching condition is the following:
Routing key matching
In addition to wildcard and regular expression matching, you can explicitly define routing key matching via the Associated routing key selector. This provides AND logic to the matching parameters specified in your wildcard or regex matching section.
Wildcard matching
Rules can match an alert field value using a simplified wildcard syntax to match some or all of the string. The asterisk character (*) matches 0 or more characters and you can use it anywhere in the match pattern.
Wildcard examples
Phrase | Matches | Does Not Match |
|---|---|---|
|
|
|
|
|
|
|
|
|
Matching with regular expressions
Regular expressions are characters that define search patterns. To set a rule to use regular expressions, change the menu option to RegEx Match. If you don’t see the option, contact support to turn on the advanced configuration.
The following limitations apply:
Compatible with Java regular expressions.
Expressions are currently limited to 128 characters.
Add
(?si)to the beginning of your regular expression to match multi-line input in a non-case-sensitive way.As the previous technique matches the entire input string, you might need to add
.*at the beginning and at the end of your regular expression.
Regular expression examples
Phrase | Matches | Does Not Match |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Boolean logic
You can use disjunction logic (OR) by replicating a rule with a different matching condition.
A set of sequential rules, when ordered correctly, can achieve basic AND logic in the Rules Engine. As with scope limiting rules, the first rule must create a new field which can be acted upon by a subsequent rule.
Rule processing order
Alert Rules uses three criteria to determine the processing order:
Top-to-bottom order of the alert rules
The optional Stop after this rule has been applied setting on each rule
Rules with a matching routing key based on the Associated routing key
For each ingested alert, all rules without a matching Associated routing key will process based on the top-to-bottom order. If a rule matches with the Stop after this rule has been applied setting, it will stop the application of alert rules for that alert. Lastly, rules with a specific matching routing key based on the Associated routing key are applied. These rules are applied last so they can match on the final routing key of an alert, in case this value is changed by a different alert rule.
AND logic example
In the following example, you want to capture disk space from the entity_id field, as well as the name stage-db-26 from the host_name field to convert these alerts to INFO events only when both conditions are met.
The matching condition for the first rule catches the first desired phrase and use variable expansion to import the value of the second field into a newly declared field.
The matching condition for the second rule, which you must position below the first rule, checks the newly declared field for the value stage-db-26 and takes the appropriate action.