Dynamic Rules¶
Feature Availability
This is a paid feature that is not available for every user. Access to dynamic rules starts with the Essential plan with sub-features only available to users on the Professional Plan (rules matching on the Event Time).
Using Dynamic Rules you can build extremely complex notification scenarios leveraging the tag-based configuration system of Argus.
They prevent you from manually configuring who to notify under which condition on a per-monitor basis and thereby saving you tons of time and work, especially when you're working with hundreds of monitors.
Concept¶
The idea behind dynamic rules is to define a certain set of rules (either connected to each other by a logical AND or OR) targeting certain kinds of notifications and monitors and then to define contacts that should receive these notifications (either by targeting contacts by tag or by statically assigning them to the dynamic rule).
We've collected a few real-life use cases so that you can get an idea how our customers are using dynamic rules in their setup:
Simple: Notify all employees for internal service alerts
Match all notifications for monitors that are tagged with internal and then send a notification to all contacts that are tagged with employee:email.
Intermediate: Call the IT Team Manager after 10 minutes
Match all notifications for all monitors indicating that a monitor went down and then send a phone call notification to a specific contact after 10 minutes, if the monitor is still down at that point in time.
Advanced: Call the night shift for critical customer services
Match all notifications for monitors tagged both customer and critical indicating that a monitor went down between 18:00 and 08:00 hours and then send a phone call notification to all contacts tagged employee:on-call.
As you can see, there's a variety of possible scenarios you can cover with dynamic rules, and it really depends on how you structured the tags of your monitors and contacts.
Building Rules¶
Building your dynamic rules is easy thanks to our visual rule builder. The rule builder works by selecting a field, an operation and then an expression.
Which operations and expressions you can use depends on the field, you're matching on.
As of today, your rules can use the following fields:
- Monitor Name (defined by you)
- Monitor Tags (defined by you)
- Monitor Type (either ICMP or HTTP)
- Event Type (either Up or Down)
- Event Time (when the event occurred; only available to users on the Professional plan)
Monitor Name¶
The name of a monitor can be defined by the user. In dynamic rules, the user can either match by name equality or by using a regular expression.
Regular Expressions
With regular expressions, you can make your rules even more powerful. You can for example write ^Customer A:.* to match all monitors whose name starts with Customer A:
Regular Expressions
When building regular expressions for dynamic rules, make sure you're using the PCRE2 flavor. You should use tools like regex101 to check whether your regular expression is valid or not.
Monitor Tags¶
The tags of a monitor can be defined by the user as well. In dynamic rules, the user can utilise the following operations on the field:
- Equals
- Is One Of
- Regular Expression
Tag Matching
Rules that are matching the tags of a monitor are evaluated for each tag. If you're using the equals operator on a monitor with multiple tags, the rule will evaluate positively if one of the tags of the monitor exactly equals the provided tag in the dynamic rule.
Monitor Type¶
This field allows you to apply dynamic rules only to certain types of monitors, for example only for ICMP monitors. You can match the monitor type by equality or by checking whether the monitor's type is in a list of provided monitor types that are allowed to match.
Event Type¶
This field allows you to distinguish between notifications that are being sent for a monitor that went down or up again. The only available operator for this field is the equality operator.
Event Type Matching
If you don't include a check for the event type, the rule automatically applies to both kinds of event types, effectively rendering any other possible operators useless.
Event Time¶
Feature Availability
Access to time-based dynamic rules starts with the Professional plan.
This is a very powerful field to match against as it allows you to build time-based notification rules. The time you're matching against is the time when Argus registers an event.
When matching against this field, you can only use the is between operator which requires you to specify a range of time.
Time-Based Dynamic Rules
A common pattern we can observe with our customers is that this feature is being used to build on-call rules that trigger phone notifications at night, effectively avoiding to dispatch phone calls using up phone notification during the day, when employees can quickly react to other means of notifications such as Pushover messages or emails.
Affected Contacts¶
You might notice that while creating a dynamic rule, you don't specify which contacts should be notified, when the rule matches.
Direct Affection¶
In order to let Argus know which contacts should receive a notification when the dynamic rule matches an event, you can directly associate contacts with it.
This is the easiest way, but also the one with the least amount of flexibility. You should use this mode for very static lists of not too many contacts, such as a fixed escalation phone number or a small amount of employees that don't change often.
Affection by Tag¶
This is the recommended way of working with dynamic rules and contacts.
You can add one or more tags to a dynamic rule. The dynamic rule then automatically affects all contacts that are tagged with at least one of the defined tags as well. With other words, the list of affected tags can be considered concatenated with a logical OR expression.
Whether a dynamic rule is affecting a contact or not, is being evaluated in the second when the system detects a notifiable event.
This is the most flexible way of handling dynamic rules, because it allows you to define a rule once and never touch it again, even if you're adding contacts that should receive notifications based on that rule in the future, e.g. when a new employee is being added to your organisation.
Evaluation¶
Whether a dynamic rule is matching an event for a monitor and triggers a notification or not is being made in the second where the system detects a notifiable event.
The list of affected contacts of a dynamic rule is also being evaluated at the same point in time and not later down the line. Even not so when a delay is configured for a dynamic rule.
Pitfall
If you are configuring a delay for your dynamic rule, it's still being evaluated when then system detects a notifiable event. The rule is not being reevaluated after the delay is over.
Notifications based on dynamic rules that include a delay are only dispatched after the delay, if the monitor didn't experience a status change of any kind in the meantime, thereby avoiding cascades of delayed notifications after a monitor experienced a flapping state where the monitoring check result quickly flapped between being available and being unavailable.
Pausing¶
You can pause and resume a dynamic rule. This can be manually done on the dynamic rule overview page as well as on a dynamic rule's detail page.
While a dynamic rule is in pause, it is not being evaluated when a notifiable event is detected by Argus.
Resuming a dynamic rule makes it work as expected again.