[dev.icinga.com #270] Patch for Extension of Escalation Condition

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/270

Created by jhein on 2010-02-08 11:18:27 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2010-02-15 18:32:54 +00:00)
Target Version: 1.0.1
Last Update: 2010-02-15 18:32:54 +00:00 (in Redmine)

---

/*****

• This patch extends the nagios escalation functionality.
• It is based on nagios release version 3.2.0, affected files are:
• base/config.c , base/notifications.c ,
• common/objects.c , include/objects.h ,
• xdata/xodtemplate.c , xdata/xodtemplate.h
  *
• All changes are free to use under the GPL
• 06.01.2010
• Vitali Voroth, DECOIT GmbH, Germany
• http://www.decoit.de
  *****/

// Introduction
It is now possible to define an escalation_condition
(similar to escalation_options [w,u,c,r]).

An escalation with an defined condition will only be escalated if
the current state of a particular host/service fits the condition.
One possible usecase for this could be the folowing scenario:
Think of 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 an company
and the admin has to react instantly if it is down. Bar could
be an service indicating if the admin is in the office or at home
and the escalation would react as following:
If the admin is in the office, send an email first, after 5 minutes
send an SMS.
If the admin is at home, send an SMS fist and after 30 minutes an second
SMS to the admin and the head of department.

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

// Syntax
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 ( [ & / | ] )*
where 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.
w = WARNING
u = UNKNOWN
c = CRITICAL
o = OK for services or UP for hosts (one could think of ONLINE)
d = DOWN for hosts

// Example
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.

Attachments

• escalation_condition_patch.zip jhein - 2010-02-08 11:18:27 +00:00 - Patch
• escalation_condition_readme.txt jhein - 2010-02-08 11:18:27 +00:00 - Readme

Changesets

2010-02-15 16:18:29 +00:00 by mfriedrich ebf6b65

add escalation_condition definition

/*****************************************************************
* This patch extends the nagios escalation functionality.
* It is based on nagios release version 3.2.0, affected files are:
*       base/config.c , base/notifications.c ,
*       common/objects.c , include/objects.h ,
*       xdata/xodtemplate.c , xdata/xodtemplate.h
*
* All changes are free to use under the GPL
* 06.01.2010
* Vitali Voroth, DECOIT GmbH, Germany
* http://www.decoit.de
*****************************************************************/

// Introduction
It is now possible to define an escalation_condition
(similar to escalation_options [w,u,c,r]).

An escalation with an defined condition will only be escalated if
the current state of a particular host/service fits the condition.
One possible usecase for this could be the folowing scenario:
Think of 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 an company
and the admin has to react instantly if it is down. Bar could
be an service indicating if the admin is in the office or at home
and the escalation would react as following:
If the admin is in the office, send an email first, after 5 minutes
send an SMS.
If the admin is at home, send an SMS fist and after 30 minutes an second
SMS to the admin and the head of department.

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

// Syntax
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.
        w = WARNING
        u = UNKNOWN
        c = CRITICAL
        o = OK for services or UP for hosts (one could think of ONLINE)
        d = DOWN for hosts

// Example
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.

--------------------------
refs #270

2010-02-15 17:03:45 +00:00 by mfriedrich 8d7ba82

fix wrong brackets set in escalation_codition config check

(did i already mention that i hate that \t coding style for
ending brackets?)

refs #270

[icinga-migration]

Updated by mfriedrich on 2010-02-08 17:40:40 +00:00

• Assigned to set to Meier

@meier

please test that, maybe we can get it into 1.0.1

[icinga-migration]

Updated by mfriedrich on 2010-02-12 02:15:21 +00:00

• Assigned to changed from Meier to mfriedrich
• Target Version set to 1.0.1

applied in my testbranch for testing.

[icinga-migration]

Updated by mfriedrich on 2010-02-15 18:32:54 +00:00

• Status changed from New to Resolved
• Done % changed from 0 to 100