1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Notification Escalations</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.75.1">
<meta name="keywords" content="Supervision, Icinga, Nagios, Linux">
<link rel="home" href="index.html" title="Icinga Version 1.0.2 Documentation">
<link rel="up" href="ch06.html" title="Chapter 6. Advanced Topics">
<link rel="prev" href="flapping.html" title="Detection and Handling of State Flapping">
<link rel="next" href="escalation_condition.html" title="Escalation Condition">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<CENTER><IMG src="../images/logofullsize.png" border="0" alt="Icinga" title="Icinga"></CENTER>
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Notification Escalations</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="flapping.html">Prev</a> </td>
<th width="60%" align="center">Chapter 6. Advanced Topics</th>
<td width="20%" align="right"> <a accesskey="n" href="escalation_condition.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="section" title="Notification Escalations">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="escalations"></a><a name="notification_escalations"></a>Notification Escalations</h2></div></div></div>
<p><span class="bold"><strong>Introduction</strong></span></p>
<p><span class="inlinemediaobject"><img src="../images/objects-contacts.png"></span></p>
<p>Icinga supports optional escalation of contact notifications for hosts and services. Escalation of host and service
notifications is accomplished by defining <a class="link" href="objectdefinitions.html#objectdefinitions-hostescalation">host escalations</a> and <a class="link" href="objectdefinitions.html#objectdefinitions-serviceescalation">service escalations</a> in your <a class="link" href="configobject.html" title="Object Configuration Overview">object
configuration file(s)</a>.</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.png"></td>
<th align="left">Note</th>
</tr>
<tr><td align="left" valign="top">
<p>The examples we provide below all make use of service escalation definitions, but host escalations work the same way.
Except, of course, that they're for hosts instead of services. :-)</p>
</td></tr>
</table></div>
<p><span class="bold"><strong>When Are Notifications Escalated?</strong></span></p>
<p>Notifications are escalated <span class="emphasis"><em>if and only if</em></span> one or more escalation definitions matches the current
notification that is being sent out. If a host or service notification <span class="emphasis"><em>does not</em></span> have any valid escalation
definitions that applies to it, the contact group(s) specified in either the host group or service definition will be used for
the notification. Look at the example below:</p>
<pre class="screen"> define serviceescalation{
host_name webserver
service_description HTTP
first_notification 3
last_notification 5
notification_interval 90
contact_groups nt-admins,managers
}
define serviceescalation{
host_name webserver
service_description HTTP
first_notification 6
last_notification 10
notification_interval 60
contact_groups nt-admins,managers,everyone
}</pre>
<p>Notice that there are "holes" in the notification escalation definitions. In particular, notifications 1 and 2 are not
handled by the escalations, nor are any notifications beyond 10. For the first and second notification, as well as all
notifications beyond the tenth one, the <span class="emphasis"><em>default</em></span> contact groups specified in the service definition are
used. For all the examples we'll be using, we'll be assuming that the default contact groups for the service definition is
called <span class="emphasis"><em>nt-admins</em></span>.</p>
<p><span class="bold"><strong>Contact Groups</strong></span></p>
<p>When defining notification escalations, it is important to keep in mind that any contact groups that were members of
"lower" escalations (i.e. those with lower notification number ranges) should also be included in "higher" escalation
definitions. This should be done to ensure that anyone who gets notified of a problem <span class="emphasis"><em>continues</em></span> to get
notified as the problem is escalated. Example:</p>
<pre class="screen"> define serviceescalation{
host_name webserver
service_description HTTP
first_notification 3
last_notification 5
notification_interval 90
contact_groups nt-admins,managers
}
define serviceescalation{
host_name webserver
service_description HTTP
first_notification 6
last_notification 0
notification_interval 60
contact_groups nt-admins,managers,everyone
}</pre>
<p>The first (or "lowest") escalation level includes both the <span class="emphasis"><em>nt-admins</em></span> and
<span class="emphasis"><em>managers</em></span> contact groups. The last (or "highest") escalation level includes the
<span class="emphasis"><em>nt-admins</em></span>, <span class="emphasis"><em>managers</em></span>, and <span class="emphasis"><em>everyone</em></span> contact groups. Notice that the
<span class="emphasis"><em>nt-admins</em></span> contact group is included in both escalation definitions. This is done so that they continue to
get paged if there are still problems after the first two service notifications are sent out. The <span class="emphasis"><em>managers</em></span>
contact group first appears in the "lower" escalation definition - they are first notified when the third problem notification
gets sent out. We want the <span class="emphasis"><em>managers</em></span> group to continue to be notified if the problem continues past five
notifications, so they are also included in the "higher" escalation definition.</p>
<p><span class="bold"><strong>Overlapping Escalation Ranges</strong></span></p>
<p>Notification escalation definitions can have notification ranges that overlap. Take the following example:</p>
<pre class="screen"> define serviceescalation{
host_name webserver
service_description HTTP
first_notification 3
last_notification 5
notification_interval 20
contact_groups nt-admins,managers
}
define serviceescalation{
host_name webserver
service_description HTTP
first_notification 4
last_notification 0
notification_interval 30
contact_groups on-call-support
}</pre>
<p>In the example above:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>The <span class="emphasis"><em>nt-admins</em></span> and <span class="emphasis"><em>managers</em></span> contact groups get notified on the third
notification</p>
</li>
<li class="listitem">
<p>All three contact groups get notified on the fourth and fifth notifications</p>
</li>
<li class="listitem">
<p>Only the <span class="emphasis"><em>on-call-support</em></span> contact group gets notified on the sixth (or higher) notification</p>
</li>
</ul></div>
<p><span class="bold"><strong>Recovery Notifications</strong></span></p>
<p>Recovery notifications are slightly different than problem notifications when it comes to escalations. Take the following
example:</p>
<pre class="screen"> define serviceescalation{
host_name webserver
service_description HTTP
first_notification 3
last_notification 5
notification_interval 20
contact_groups nt-admins,managers
}
define serviceescalation{
host_name webserver
service_description HTTP
first_notification 4
last_notification 0
notification_interval 30
contact_groups on-call-support
}</pre>
<p>If, after three problem notifications, a recovery notification is sent out for the service, who gets notified? The
recovery is actually the fourth notification that gets sent out. However, the escalation code is smart enough to realize that
only those people who were notified about the problem on the third notification should be notified about the recovery. In this
case, the <span class="emphasis"><em>nt-admins</em></span> and <span class="emphasis"><em>managers</em></span> contact groups would be notified of the
recovery.</p>
<p><span class="bold"><strong>Notification Intervals</strong></span></p>
<p>You can change the frequency at which escalated notifications are sent out for a particular host or service by using the
<span class="emphasis"><em>notification_interval</em></span> option of the hostgroup or service escalation definition. Example:</p>
<pre class="screen"> define serviceescalation{
host_name webserver
service_description HTTP
first_notification 3
last_notification 5
notification_interval 45
contact_groups nt-admins,managers
}
define serviceescalation{
host_name webserver
service_description HTTP
first_notification 6
last_notification 0
notification_interval 60
contact_groups nt-admins,managers,everyone
}</pre>
<p>In this example we see that the default notification interval for the services is 240 minutes (this is the value in the
service definition). When the service notification is escalated on the 3rd, 4th, and 5th notifications, an interval of 45
minutes will be used between notifications. On the 6th and subsequent notifications, the notification interval will be 60
minutes, as specified in the second escalation definition.</p>
<p>Since it is possible to have overlapping escalation definitions for a particular hostgroup or service, and the fact that a
host can be a member of multiple hostgroups, Icinga has to make a decision on what to do as far as the notification
interval is concerned when escalation definitions overlap. In any case where there are multiple valid escalation definitions for
a particular notification, Icinga will choose the smallest notification interval. Take the following example:</p>
<pre class="screen"> define serviceescalation{
host_name webserver
service_description HTTP
first_notification 3
last_notification 5
notification_interval 45
contact_groups nt-admins,managers
}
define serviceescalation{
host_name webserver
service_description HTTP
first_notification 4
last_notification 0
notification_interval 60
contact_groups nt-admins,managers,everyone
}</pre>
<p>We see that the two escalation definitions overlap on the 4th and 5th notifications. For these notifications,
Icinga will use a notification interval of 45 minutes, since it is the smallest interval present in any valid escalation
definitions for those notifications.</p>
<p>One last note about notification intervals deals with intervals of 0. An interval of 0 means that Icinga should
only sent a notification out for the first valid notification during that escalation definition. All subsequent notifications
for the hostgroup or service will be suppressed. Take this example:</p>
<pre class="screen">define serviceescalation{
host_name webserver
service_description HTTP
first_notification 3
last_notification 5
notification_interval 45
contact_groups nt-admins,managers
}
define serviceescalation{
host_name webserver
service_description HTTP
first_notification 4
last_notification 6
notification_interval 0
contact_groups nt-admins,managers,everyone
}
define serviceescalation{
host_name webserver
service_description HTTP
first_notification 7
last_notification 0
notification_interval 30
contact_groups nt-admins,managers
}</pre>
<p>In the example above, the maximum number of problem notifications that could be sent out about the service would be four.
This is because the notification interval of 0 in the second escalation definition indicates that only one notification should
be sent out (starting with and including the 4th notification) and all subsequent notifications should be repressed. Because of
this, the third service escalation definition has no effect whatsoever, as there will never be more than four
notifications.</p>
<p><span class="bold"><strong>Time Period Restrictions</strong></span></p>
<p>Under normal circumstances, escalations can be used at any time that a notification could normally be sent out for the
host or service. This "notification time window" is determined by the <span class="emphasis"><em>notification_period</em></span> directive in the
<a class="link" href="objectdefinitions.html#objectdefinitions-host">host</a> or <a class="link" href="objectdefinitions.html#objectdefinitions-service">service</a>
definition.</p>
<p>You can optionally restrict escalations so that they are only used during specific time periods by using the
<span class="emphasis"><em>escalation_period</em></span> directive in the host or service escalation definition. If you use the
<span class="emphasis"><em>escalation_period</em></span> directive to specify a <a class="link" href="timeperiods.html" title="Time Periods">timeperiod</a> during which the
escalation can be used, the escalation will only be used during that time. If you do not specify any
<span class="emphasis"><em>escalation_period</em></span> directive, the escalation can be used at any time within the "notification time window"
for the host or service.</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../images/note.png"></td>
<th align="left">Note</th>
</tr>
<tr><td align="left" valign="top">
<p>Escalated notifications are still subject to the normal time restrictions imposed by the
<span class="emphasis"><em>notification_period</em></span> directive in a host or service definition, so the timeperiod you specify in an
escalation definition should be a subset of that larger "notification time window".</p>
</td></tr>
</table></div>
<p><span class="bold"><strong>State Restrictions</strong></span></p>
<p>If you would like to restrict the escalation definition so that it is only used when the host or service is in a
particular state, you can use the <span class="emphasis"><em>escalation_options</em></span> directive in the host or service escalation
definition. If you do not use the <span class="emphasis"><em>escalation_options</em></span> directive, the escalation can be used when the host or
service is in any state.</p>
<a class="indexterm" name="id1995257"></a>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="flapping.html">Prev</a> </td>
<td width="20%" align="center"><a accesskey="u" href="ch06.html">Up</a></td>
<td width="40%" align="right"> <a accesskey="n" href="escalation_condition.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Detection and Handling of State Flapping </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td>
<td width="40%" align="right" valign="top"> Escalation Condition</td>
</tr>
</table>
</div>
<P class="copyright">© 2009-2010 Icinga Development Team, http://www.icinga.org</P>
</body>
</html>
|
