~yolanda.robla/ubuntu/saucy/nagios3/dep-8-tests

« back to all changes in this revision

Viewing changes to html/docs/dependencies.html

  • Committer: Package Import Robot
  • Author(s): Alexander Wirt
  • Date: 2012-06-16 09:05:19 UTC
  • mfrom: (1.1.7)
  • Revision ID: package-import@ubuntu.com-20120616090519-ne14zejkhhyboolc
Tags: 3.4.1-1
* [28e077b] Imported Upstream version 3.3.1
* [d5314e0] don't call updatepo in clean target
* [45b3eb9] Don't remove config foo
* [54e3dff] Don't fix permissions in cgi postinst
* [d7be9db] Build-depend on libpng-dev (Closes: #662441)
* [4c47006] Add dutch po translation (Closes: #654855)
* [2b6573b] Refresh 10_p1_pl_shebang.dpatch
* [316fd7a] Update 40_fix_spurious_dollar_signs_added_to_command_lines
* [5ff2780] Refresh 55_strip_logarchivepath.dpatch
* [811d269] Refresh 60_fix_p1.pl_patch_mini_epn.dpatch
* [39a1e9c] Remove now unneeded patch 98_fix_XSS_CVE-2011-2179
* [785a4e8] Remove unneded patch 99_fix_XSS_CVE-2011-1523
* [6ce98ef] Remove unneeded patchs from 00list
* [1d18266] Imported Upstream version 3.4.0
* [05584c8] Refresh patches
* [58098cd] Imported Upstream version 3.4.1
* [3e9e07a] Bump standards version
* [fe991e2] wrap-and-sort
* [1ba78f7] Also create /var/run/nagios in cgi package (Closes: #626854)

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
2
 
 
3
 
 
4
 
 
5
 
<html>
6
 
 
7
 
<head>
8
 
 
9
 
<title>Host and Service Dependencies</title>
10
 
 
11
 
 
12
 
 
13
 
<STYLE type="text/css">
14
 
 
15
 
<!--
16
 
 
17
 
        .Default { font-family: verdana,arial,serif; font-size: 8pt; }
18
 
 
19
 
        .PageTitle { font-family: verdana,arial,serif; font-size: 16pt; font-weight: bold; }
20
 
 
21
 
-->      
22
 
 
23
 
</STYLE>
24
 
 
25
 
 
26
 
 
27
 
</head>
28
 
 
29
 
 
30
 
 
31
 
<body bgcolor="#FFFFFF" text="black" class="Default">
32
 
 
33
 
 
34
 
 
35
 
<div align="center">
36
 
 
37
 
<img src="images/nagios.jpg" border="0" alt="Nagios" title="Nagios">
38
 
 
39
 
<h1 class="PageTitle">Host and Service Dependencies</h1>
40
 
 
41
 
</div>
42
 
 
43
 
 
44
 
 
45
 
<hr>
46
 
 
47
 
 
48
 
 
49
 
<p>
50
 
 
51
 
<img src="images/upto.gif" border="0" align="middle" alt="Up To" title="Up To">Up To: <a href="toc.html">Contents</a><br>
52
 
 
53
 
<img src="images/seealso.gif" border="0" align="middle" alt="See Also" title="See Also"> See Also: <a href="dependencychecks.html">Predictive Dependency Checks</a>, <a href="servicechecks.html">Service Checks</a>, <a href="hostchecks.html">Host Checks</a>
54
 
 
55
 
</p>
56
 
 
57
 
 
58
 
 
59
 
<p>
60
 
 
61
 
<strong><u>Introduction</u></strong>
62
 
 
63
 
</p>
64
 
 
65
 
 
66
 
 
67
 
<p>
68
 
 
69
 
Service and host dependencies are an advanced feature of Nagios that allow you to control the behavior of hosts and services based on the status of one or more other hosts or services.  I'll explain how dependencies work, along with the differences between host and service dependencies.
70
 
 
71
 
</p>
72
 
 
73
 
 
74
 
 
75
 
<p>
76
 
 
77
 
<strong><u>Service Dependencies Overview</u></strong>
78
 
 
79
 
</p>
80
 
 
81
 
 
82
 
 
83
 
<p>
84
 
 
85
 
There are a few things you should know about service dependencies:
86
 
 
87
 
</p>
88
 
 
89
 
<ol>
90
 
 
91
 
<li>A service can be dependent on one or more other services
92
 
 
93
 
<li>A service can be dependent on services which are not associated with the same host
94
 
 
95
 
<li>Service dependencies are not inherited (unless specifically configured to)
96
 
 
97
 
<li>Service dependencies can be used to cause service check execution and service notifications to be suppressed under different circumstances (OK, WARNING, UNKNOWN, and/or CRITICAL states)
98
 
 
99
 
<li>Service dependencies might only be valid during specific <a href="timeperiods.html">timeperiods</a></li>
100
 
 
101
 
</ol>
102
 
 
103
 
 
104
 
 
105
 
 
106
 
 
107
 
<p>
108
 
 
109
 
<strong><u>Defining Service Dependencies</u></strong>
110
 
 
111
 
</p>
112
 
 
113
 
 
114
 
 
115
 
<p>
116
 
 
117
 
First, the basics.  You create service dependencies by adding <a href="objectdefinitions.html#servicedependency">service dependency definitions</a> in your <a href="configobject.html">object config file(s)</a>.  In each definition you specify the <i>dependent</i> service, the service you are <i>depending on</i>, and the criteria (if any) that cause the execution and notification dependencies to fail (these are described later).
118
 
 
119
 
</p>
120
 
 
121
 
 
122
 
 
123
 
<p>
124
 
 
125
 
You can create several dependencies for a given service, but you must add a separate service dependency definition for each dependency you create.
126
 
 
127
 
</p>
128
 
 
129
 
 
130
 
 
131
 
 
132
 
 
133
 
<p>
134
 
 
135
 
<strong><u>Example Service Dependencies</u></strong>
136
 
 
137
 
</p>
138
 
 
139
 
 
140
 
 
141
 
<p>
142
 
 
143
 
The image below shows an example logical layout of service notification and execution dependencies.   Different services are dependent on other services for notifications and check execution.
144
 
 
145
 
</p>
146
 
 
147
 
 
148
 
 
149
 
<img src="images/service-dependencies.png" alt="Service Dependencies">
150
 
 
151
 
 
152
 
 
153
 
<p>
154
 
 
155
 
In this example, the dependency definitions for <i>Service F</i> on <i>Host C</i> would be defined as follows:
156
 
 
157
 
</p>
158
 
 
159
 
 
160
 
 
161
 
<pre>
162
 
 
163
 
define servicedependency{
164
 
 
165
 
        host_name                       Host B
166
 
 
167
 
        service_description             Service D
168
 
 
169
 
        dependent_host_name             Host C
170
 
 
171
 
        dependent_service_description   Service F
172
 
 
173
 
        execution_failure_criteria      o
174
 
 
175
 
        notification_failure_criteria   w,u
176
 
 
177
 
        }
178
 
 
179
 
 
180
 
 
181
 
define servicedependency{
182
 
 
183
 
        host_name                       Host B
184
 
 
185
 
        service_description             Service E
186
 
 
187
 
        dependent_host_name             Host C
188
 
 
189
 
        dependent_service_description   Service F
190
 
 
191
 
        execution_failure_criteria      n
192
 
 
193
 
        notification_failure_criteria   w,u,c
194
 
 
195
 
        }
196
 
 
197
 
 
198
 
 
199
 
define servicedependency{
200
 
 
201
 
        host_name                       Host B
202
 
 
203
 
        service_description             Service C
204
 
 
205
 
        dependent_host_name             Host C
206
 
 
207
 
        dependent_service_description   Service F
208
 
 
209
 
        execution_failure_criteria      w
210
 
 
211
 
        notification_failure_criteria   c
212
 
 
213
 
        }
214
 
 
215
 
</pre>
216
 
 
217
 
 
218
 
 
219
 
 
220
 
 
221
 
<p>
222
 
 
223
 
The other dependency definitions shown in the image above would be defined as follows:
224
 
 
225
 
</p>
226
 
 
227
 
 
228
 
 
229
 
<pre>
230
 
 
231
 
define servicedependency{
232
 
 
233
 
        host_name                       Host A
234
 
 
235
 
        service_description             Service A
236
 
 
237
 
        dependent_host_name             Host B
238
 
 
239
 
        dependent_service_description   Service D
240
 
 
241
 
        execution_failure_criteria      u
242
 
 
243
 
        notification_failure_criteria   n
244
 
 
245
 
        }
246
 
 
247
 
 
248
 
 
249
 
define servicedependency{
250
 
 
251
 
        host_name                       Host A
252
 
 
253
 
        service_description             Service B
254
 
 
255
 
        dependent_host_name             Host B
256
 
 
257
 
        dependent_service_description   Service E
258
 
 
259
 
        execution_failure_criteria      w,u
260
 
 
261
 
        notification_failure_criteria   c
262
 
 
263
 
        }
264
 
 
265
 
 
266
 
 
267
 
define servicedependency{
268
 
 
269
 
        host_name                       Host B
270
 
 
271
 
        service_description             Service C
272
 
 
273
 
        dependent_host_name             Host B
274
 
 
275
 
        dependent_service_description   Service E
276
 
 
277
 
        execution_failure_criteria      n
278
 
 
279
 
        notification_failure_criteria   w,u,c
280
 
 
281
 
        }
282
 
 
283
 
</pre>
284
 
 
285
 
 
286
 
 
287
 
 
288
 
 
289
 
<p>
290
 
 
291
 
<strong><u>How Service Dependencies Are Tested</u></strong>
292
 
 
293
 
</p>
294
 
 
295
 
 
296
 
 
297
 
<p>
298
 
 
299
 
Before Nagios executes a service check or sends notifications out for a service, it will check to see if the service has any dependencies.  If it doesn't have any dependencies, the check is executed or the notification is sent out as it normally would be.  If the service <i>does</i> have one or more dependencies, Nagios will check each dependency entry as follows:
300
 
 
301
 
</p>
302
 
 
303
 
 
304
 
 
305
 
<ol>
306
 
 
307
 
<li>Nagios gets the current status<sup><a href="#hard_dependencies">*</a></sup> of the service that is being <i>depended upon</i>.
308
 
 
309
 
<li>Nagios compares the current status of the service that is being <i>depended upon</i> against either the execution or notification failure options in the dependency definition (whichever one is relevant at the time).
310
 
 
311
 
<li>If the current status of the service that is being <i>depended upon</i> matches one of the failure options, the dependency is said to have failed and Nagios will break out of the dependency check loop.
312
 
 
313
 
<li>If the current state of the service that is being <i>depended upon</i> does not match any of the failure options for the dependency entry, the dependency is said to have passed and Nagios will go on and check the next dependency entry.  </ol>
314
 
 
315
 
 
316
 
 
317
 
<p>
318
 
 
319
 
This cycle continues until either all dependencies for the service have been checked or until one dependency check fails.
320
 
 
321
 
</p>
322
 
 
323
 
 
324
 
 
325
 
<p>
326
 
 
327
 
<a name="hard_dependencies"></a>
328
 
 
329
 
<img src="images/note.gif" border="0" align="bottom" alt="Note" title="Note"> Note: <sup>*</sup>One important thing to note is that by default, Nagios will use the most current <a href="statetypes.html">hard state</a> of the service(s) that is/are being depended upon when it does the dependeny checks.  If you want Nagios to use the most current state of the services (regardless of whether its a soft or hard state), enable the <a href="configmain.html#soft_state_dependencies">soft_state_dependencies</a> option.
330
 
 
331
 
</p>
332
 
 
333
 
 
334
 
 
335
 
<p>
336
 
 
337
 
<strong><u>Execution Dependencies</u></strong>
338
 
 
339
 
</p>
340
 
 
341
 
 
342
 
 
343
 
<p>
344
 
 
345
 
Execution dependencies are used to restrict when <a href="activechecks.html">active checks</a> of a service can be performed.  <a href="passivechecks.html">Passive checks</a> are not restricted by execution dependencies.
346
 
 
347
 
</p>
348
 
 
349
 
 
350
 
 
351
 
<p>
352
 
 
353
 
If <i>all</i> of the execution dependency tests for the service <i>passed</i>, Nagios will execute the check of the service as it normally would.  If even just one of the execution dependencies for a service fails, Nagios will temporarily prevent the execution of checks for that (dependent) service.  At some point in the future the execution dependency tests for the service may all pass.  If this happens, Nagios will start checking the service again as it normally would.  More information on the check scheduling logic can be found <a href="checkscheduling.html">here</a>.
354
 
 
355
 
</p>
356
 
 
357
 
 
358
 
 
359
 
<p>
360
 
 
361
 
In the example above, <b>Service E</b> would have failed execution dependencies if <b>Service B</b> is in a WARNING or UNKNOWN state.  If this was the case, the service check would not be performed and the check would be scheduled for (potential) execution at a later time.
362
 
 
363
 
</p>
364
 
 
365
 
 
366
 
 
367
 
<p>
368
 
 
369
 
<strong><u>Notification Dependencies</u></strong>
370
 
 
371
 
</p>
372
 
 
373
 
 
374
 
 
375
 
<p>
376
 
 
377
 
If <i>all</i> of the notification dependency tests for the service <i>passed</i>, Nagios will send notifications out for the service as it normally would.  If even just one of the notification dependencies for a service fails, Nagios will temporarily repress notifications for that (dependent) service.  At some point in the future the notification dependency tests for the service may all pass.  If this happens, Nagios will start sending out notifications again as it normally would for the service.  More information on the notification logic can be found <a href="notifications.html">here</a>.
378
 
 
379
 
</p>
380
 
 
381
 
 
382
 
 
383
 
<p>
384
 
 
385
 
In the example above, <b>Service F</b> would have failed notification dependencies if <b>Service C</b> is in a CRITICAL state, <i>and/or</i> <b>Service D</b> is in a WARNING or UNKNOWN state, <i>and/or</i> if <b>Service E</b> is in a WARNING, UNKNOWN, or CRITICAL state.  If this were the case, notifications for the service would not be sent out.
386
 
 
387
 
</p>
388
 
 
389
 
 
390
 
 
391
 
<p>
392
 
 
393
 
<strong><u>Dependency Inheritance</u></strong>
394
 
 
395
 
</p>
396
 
 
397
 
 
398
 
 
399
 
<p>
400
 
 
401
 
As mentioned before, service dependencies are <i>not</i> inherited by default.  In the example above you can see that Service F is dependent on Service E.  However, it does not automatically inherit Service E's dependencies on Service B and Service C.  In order to make Service F dependent on Service C we had to add another service dependency definition.  There is no dependency definition for Service B, so Service F is <i>not</i> dependent on Service B.
402
 
 
403
 
</p>
404
 
 
405
 
 
406
 
 
407
 
<p>
408
 
 
409
 
If you <i>do</i> wish to make service dependencies inheritable, you must use the <i>inherits_parent</i> directive in the <a href="objectdefinitions.html#servicedependency">service dependency</a> definition.  When this directive is enabled, it indicates that the dependency inherits dependencies of the service <i>that is being depended upon</i> (also referred to as the master service). In other words, if the master service is dependent upon other services and any one of those dependencies fail, this dependency will also fail. 
410
 
 
411
 
</p>
412
 
 
413
 
 
414
 
 
415
 
<p>
416
 
 
417
 
In the example above, imagine that you want to add a new dependency for service F to make it dependent on service A.  You could create a new dependency definition that specified service F as the <i>dependent</i> service and service A as being the <i>master</i> service (i.e. the service <i>that is being dependend on</i>).  You could alternatively modify the dependency definition for services D and F to look like this:
418
 
 
419
 
</p>
420
 
 
421
 
 
422
 
 
423
 
<pre>
424
 
 
425
 
define servicedependency{
426
 
 
427
 
        host_name                       Host B
428
 
 
429
 
        service_description             Service D
430
 
 
431
 
        dependent_host_name             Host C
432
 
 
433
 
        dependent_service_description   Service F
434
 
 
435
 
        execution_failure_criteria      o
436
 
 
437
 
        notification_failure_criteria   n
438
 
 
439
 
        inherits_parent         1
440
 
 
441
 
        }
442
 
 
443
 
 
444
 
 
445
 
</pre>
446
 
 
447
 
 
448
 
 
449
 
<p>
450
 
 
451
 
Since the <i>inherits_parent</i> directive is enabled, the dependency between services A and D will be tested when the dependency between services F and D are being tested.
452
 
 
453
 
</p>
454
 
 
455
 
 
456
 
 
457
 
<p>
458
 
 
459
 
Dependencies can have multiple levels of inheritence.  If the dependency definition between A and D had its <i>inherits_parent</i> directive enable and service A was dependent on some other service (let's call it service G), the service F would be dependent on services D, A, and G (each with potentially different criteria).
460
 
 
461
 
</p>
462
 
 
463
 
 
464
 
 
465
 
<p>
466
 
 
467
 
<strong><u>Host Dependencies</u></strong>
468
 
 
469
 
</p>
470
 
 
471
 
 
472
 
 
473
 
<p>
474
 
 
475
 
As you'd probably expect, host dependencies work in a similiar fashion to service dependencies.  The difference is that they're for hosts, not services.
476
 
 
477
 
</p>
478
 
 
479
 
 
480
 
 
481
 
<p>
482
 
 
483
 
<img src="images/tip.gif" border="0" align="bottom" alt="Tip" title="Tip"> Tip:  Do not confuse host dependencies with parent/child host relationships.  You should be using parent/child host relationships (defined with the <i>parents</i> directive in <a href="objectdefinitions.html#host">host</a> definitions) for most cases, rather than host dependencies.  A description of how parent/child host relationships work can be found in the documentation on <a href="networkreachability.html">network reachability</a>.
484
 
 
485
 
</p>
486
 
 
487
 
 
488
 
 
489
 
<p>
490
 
 
491
 
Here are the basics about host dependencies:
492
 
 
493
 
</p>
494
 
 
495
 
<ol>
496
 
 
497
 
<li>A host can be dependent on one or more other host
498
 
 
499
 
<li>Host dependencies are not inherited (unless specifically configured to)
500
 
 
501
 
<li>Host dependencies can be used to cause host check execution and host notifications to be suppressed under different circumstances (UP, DOWN, and/or UNREACHABLE states)
502
 
 
503
 
<li>Host dependencies might only be valid during specific <a href="timeperiods.html">timeperiods</a></li>
504
 
 
505
 
</ol>
506
 
 
507
 
 
508
 
 
509
 
<p>
510
 
 
511
 
<strong><u>Example Host Dependencies</u></strong>
512
 
 
513
 
</p>
514
 
 
515
 
 
516
 
 
517
 
<p>
518
 
 
519
 
The image below shows an example of the logical layout of host notification dependencies.  Different hosts are dependent on other hosts for notifications.
520
 
 
521
 
</p>
522
 
 
523
 
 
524
 
 
525
 
<img src="images/host-dependencies.png" alt="Host Dependencies">
526
 
 
527
 
 
528
 
 
529
 
<p>
530
 
 
531
 
In the example above, the dependency definitions for <i>Host C</i> would be defined as follows:
532
 
 
533
 
</p>
534
 
 
535
 
 
536
 
 
537
 
<pre>
538
 
 
539
 
define hostdependency{
540
 
 
541
 
        host_name                       Host A
542
 
 
543
 
        dependent_host_name             Host C
544
 
 
545
 
        notification_failure_criteria   d
546
 
 
547
 
        }
548
 
 
549
 
 
550
 
 
551
 
define hostdependency{
552
 
 
553
 
        host_name                       Host B
554
 
 
555
 
        dependent_host_name             Host C
556
 
 
557
 
        notification_failure_criteria   d,u
558
 
 
559
 
        }
560
 
 
561
 
</pre>
562
 
 
563
 
 
564
 
 
565
 
<p>
566
 
 
567
 
As with service dependencies, host dependencies are not inherited.  In the example image you can see that Host C does not inherit the host dependencies of Host B.  In order for Host C to be dependent on Host A, a new host dependency definition must be defined.
568
 
 
569
 
</p>
570
 
 
571
 
 
572
 
 
573
 
<p>
574
 
 
575
 
Host notification dependencies work in a similiar manner to service notification dependencies.  If <i>all</i> of the notification dependency tests for the host <i>pass</i>, Nagios will send notifications out for the host as it normally would.  If even just one of the notification dependencies for a host fails, Nagios will temporarily repress notifications for that (dependent) host.  At some point in the future the notification dependency tests for the host may all pass.  If this happens, Nagios will start sending out notifications again as it normally would for the host.  More information on the notification logic can be found <a href="notifications.html">here</a>.
576
 
 
577
 
</p>
578
 
 
579
 
 
580
 
 
581
 
 
582
 
 
583
 
 
584
 
 
585
 
<hr>
586
 
 
587
 
 
588
 
 
589
 
</body>
590
 
 
591
 
</html>
592