Filter conditions in Flashduty are used to match different alerts, incidents, or events. Through filter conditions, we can screen specific objects for further operations. This article introduces the design and configuration methods of filter conditions.Where Are Filters Used?#
Filter conditions are applied in the following scenarios:1.
Escalation Rules: Multiple escalation rules can be created within the same channel, each with different filter conditions. You can set different responders for different incidents.
2.
Silence Rules: Set filter conditions to match specific incidents, and matched incidents will be silenced.
3.
Inhibit Rules: Set filter conditions to match both newly triggered incidents and existing active incidents. When new incidents meet the conditions, they will be inhibited.
4.
Alert Grouping: Alert grouping supports default grouping dimensions, but when you need fine-grained control, you can set filter conditions to match specific alerts and set new grouping dimensions for these incidents.
5.
Routing Rules: When using alert integration in the integration center, you can set global routing matching rules. Use different filter conditions to match different alerts and route them to specific channels.
6.
Label Enhancement: Set filter conditions to match specific alerts, and generate labels according to rules for alerts that meet the conditions.
Rule Design#
Flashduty has abstracted the entire filter condition system, aiming to achieve minimal configuration while meeting most scenario requirements.The overall judgment logic is divided into multiple groups of conditions:Conditions within a group have an and relationship, meaning all conditions must match for the group to match.
Groups have an or relationship with each other, meaning if any group matches, the overall condition matches.
Match: There can be multiple values, and if any value matches, the condition is satisfied.
Not Match: There can be multiple values, and if none of the values match, the condition is satisfied.
The target values in conditions are all strings. They support multiple matching methods including exact, regex, wildcard, CIDR matching, and numeric comparison.
As shown above, we have two groups of conditions, each with two conditions and multiple matching values. If the severity is "Critical" or "Warning" AND the check label equals "Binlog Sync Delay", the overall condition is satisfied. Alternatively, if the check label contains any of "cpu", "io", or "disk" AND the value label is greater than 90, the overall condition is also satisfied. We can also describe the filter conditions with an intuitive expression:( severity == Critical|Warning && labels.check == Binlog Sync Delay )
or
( labels.check == /cpu/|/io/|/disk/ && labels.value == num:gt:90 )
Regex Filtering#
When a value string is prefixed and suffixed with /, the entire value will be treated as a regex. The target value must match this regex to be considered a match.labels.check: /down/, matches when the check label contains "down".
Flashduty uses the RE2 regex standard platform-wide. Some Perl syntax may not work. You can use AI Chatbot to generate expressions and verify them at RE2 Playground. Wildcard Filtering#
When a value string contains * or ? without / prefix/suffix, it will be treated as a wildcard. Currently, only * and ? are supported, where * matches zero or more characters, and ? matches any single character. The target value must match this wildcard string to be considered a match.labels.check: down*, matches when the check label starts with "down".
You can use * to check if a field Exists or NotExists.If a field matches *, it means the field must exist. If a field does not match *, it means the field must not exist.
CIDR Matching#
When a value is prefixed with cidr, the entire value will be treated as an IP range.labels.host: cidr:10.0.0.206/24, matches when the IP label is within the "10.0.0.206/24" range.
Numeric Comparison#
When a value is prefixed with num:[gt|ge|lt|le]:, it will be treated as a numeric comparison. The comparison rules are:ge: greater than or equal to
le: less than or equal to
labels.value: num:ge:90, matches when the value label is greater than or equal to 90.
Exact Value Filtering#
When a value doesn't match any of the above formats, it will be treated as an exact match. Only when the strings are exactly equal will it be considered a match.FAQ#
Why doesn't the system suggest available labels?
Flashduty receives large amounts of data, and to ensure system stability, it only searches for and deduplicates labels from up to 500 alert events within the past 24 hours. Therefore, the available labels may change dynamically, and no labels may be available if there's no new data in the past 24 hours.In this case, you can manually enter labels.My regex passes offline validation, why doesn't it match in the system?
Flashduty uses the RE2 regex standard platform-wide. Some Perl syntax may not work. You can use AI Chatbot to generate expressions and verify them at RE2 Playground. 