Escalation Condition


Starting with Icinga 1.0.1 a patch is implemented which introduces the ability to define an escalation_condition (similar to escalation_options [w,u,c,r]). An escalation with a defined condition will only be escalated if the current state of a particular host/service fits the condition. One possible example of use for this could be the following scenario:

Imagine two different escalations for the same service foo. One of them should only escalate when service bar is OK, the other should escalate if bar is CRITICAL or WARNING. Now think about foo being the main service offered by a company and the admin has to react immediately if it is down. bar could be a service indicating if the admin is in the office or at home and the escalation would react as following:

This should be achieved without reloading or restarting the Icinga service.


The escalation_condition option is completely optional and can be defined for host escalations as well as for service escalations. The syntax is:

escalation_condition <condition> ( [ & / | ] <condition> )*

where <condition> is either: host hostname = [u,d,o] or service hostname.service_description = [w,u,c,o].

As you can see, the escalation_condition accepts a list of one or more conditions separated by "&" (logical AND) or "|" (logical OR). The meanings of [w,u,c,o,d] differ a bit from the ones used for escalation_options:


define serviceescalation {
   host_name               localhost
   service_description     HTTP
   first_notification      5
   contact_groups          admins, managers
   escalation_condition    host linux=d | service linux.SSH=w,c

This example escalation would be escalated if the HOST 'linux' is DOWN or the Service 'linux.SSH' is WARNING or CRITICAL.

[ Thanks to: Vitali Voroth, DECOIT GmbH * http://www.decoit.de ]