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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Host and Service Dependencies</title>
<STYLE type="text/css">
<!--
.Default { font-family: verdana,arial,serif; font-size: 8pt; }
.PageTitle { font-family: verdana,arial,serif; font-size: 12pt; font-weight: bold; }
-->
</STYLE>
</head>
<body bgcolor="#FFFFFF" text="black" class="Default">
<p>
<div align="center">
<h2 class="PageTitle">Host and Service Dependencies</h2>
</div>
</p>
<hr>
<p>
<strong><u>Introduction</u></strong>
</p>
<p>
Service and host dependencies are an <i>advanced</i> feature 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.
</p>
<p>
<strong><u>Service Dependencies Overview</u></strong>
</p>
<p>
The image below shows an example logical layout of service dependencies. There are a few things you should notice:
</p>
<p>
<ol>
<li>A service can be dependent on one or more other services
<li>A service can be dependent on services which are not associated with the same host
<li>Service dependencies are not inherited (unless specifically configured to)
<li>Service dependencies can be used to cause service execution and service notifications to be suppressed under different circumstances (OK, WARNING, UNKNOWN, and/or CRITICAL states)
</ol>
</p>
<p>
<a href="images/service-dependencies.png"><img src="images/service-dependencies.png" alt="Service Dependencies" width="150" height="160" border=1></a>
</p>
<p>
<strong><u>Defining Service Dependencies</u></strong>
</p>
<p>
First, the basics. You create service dependencies by adding service dependency definitions 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).
</p>
<p>
You can create several dependencies for a given service, but you must add a separate service dependency definition for each dependency you create.
</p>
<p>
In the image above, the dependency definitions for <i>Service F</i> on <i>Host C</i> would be defined as follows:
</p>
<p>
<strong>
<font color='red'>
<pre>
define servicedependency{
host_name Host B
service_description Service D
dependent_host_name Host C
dependent_service_description Service F
execution_failure_criteria o
notification_failure_criteria w,u
}
define servicedependency{
host_name Host B
service_description Service E
dependent_host_name Host C
dependent_service_description Service F
execution_failure_criteria n
notification_failure_criteria w,u,c
}
define servicedependency{
host_name Host B
service_description Service C
dependent_host_name Host C
dependent_service_description Service F
execution_failure_criteria w
notification_failure_criteria c
}
</pre>
</font>
</strong>
</p>
<p>
The other dependency definitions shown in the image above would be defined as follows:
</p>
<p>
<strong>
<font color='red'>
<pre>
define servicedependency{
host_name Host A
service_description Service A
dependent_host_name Host B
dependent_service_description Service D
execution_failure_criteria u
notification_failure_criteria n
}
define servicedependency{
host_name Host A
service_description Service B
dependent_host_name Host B
dependent_service_description Service E
execution_failure_criteria w,u
notification_failure_criteria c
}
define servicedependency{
host_name Host B
service_description Service C
dependent_host_name Host B
dependent_service_description Service E
execution_failure_criteria n
notification_failure_criteria w,u,c
}
</pre>
</font>
</strong>
</p>
<p>
<strong><u>How Service Dependencies Are Tested</u></strong>
</p>
<p>
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:
</p>
<p>
<ol>
<li>Nagios gets the current status<sup><a href="#hard_dependencies">*</a></sup> of the service that is being <i>depended upon</i>.
<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).
<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.
<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>
</p>
<p>
This cycle continues until either all dependencies for the service have been checked or until one dependency check fails.
</p>
<p>
<a name="hard_dependencies"></a>
<sup>*</sup>One important thing to note is that by default, Nagios will use the most current <a href="statetypes.html">hard</a> state 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_service_dependencies">soft_service_dependencies</a> option.
</p>
<p>
<strong><u>Execution Dependencies</u></strong>
</p>
<p>
Execution dependencies are used to restrict when <i>active</i> checks of a service can be performed. Passive checks are not restricted by execution dependencies.
</p>
<p>
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>.
</p>
<p>
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.
</p>
<p>
<strong><u>Notification Dependencies</u></strong>
</p>
<p>
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>.
</p>
<p>
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.
</p>
<p>
<strong><u>Dependency Inheritance</u></strong>
</p>
<p>
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.
</p>
<p>
If you <i>do</i> wish to make service dependencies inheritable, you must use the <i>inherits_parent</i> directive in the <a href="xodtemplate.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.
</p>
<p>
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:
</p>
<p>
<strong>
<font color='red'>
<pre>
define servicedependency{
host_name Host B
service_description Service D
dependent_host_name Host C
dependent_service_description Service F
execution_failure_criteria o
notification_failure_criteria n
inherits_parent 1
}
</pre>
</font>
</strong>
</p>
<p>
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.
</p>
<p>
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).
</p>
<p>
<strong><u>Host Dependencies</u></strong>
</p>
<p>
As you'd probably expect, host dependencies work in a similiar fashion to service dependencies. The big difference is that they're for hosts, not services. Another difference is that host dependencies only work for suppressing host notifications, not host checks.
</p>
<p>
<strong>BEWARE!</strong> 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="xodtemplate.html#host">host</a> definitions) for most cases, rather than host dependencies.
</p>
<p>
The image below shows an example of the logical layout of host dependencies.
</p>
<p>
<a href="images/host-dependencies.png"><img src="images/host-dependencies.png" alt="Host Dependencies" width="125" height="160" border=1></a>
</p>
<p>
In the image above, the dependency definitions for <i>Host C</i> would be defined as follows:
</p>
<p>
<strong>
<font color='red'>
<pre>
define hostdependency{
host_name Host A
dependent_host_name Host C
notification_failure_criteria d
}
define hostdependency{
host_name Host B
dependent_host_name Host C
notification_failure_criteria d,u
}
</pre>
</font>
</strong>
</p>
<p>
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.
</p>
<p>
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>.
</p>
<p>
<strong>NOTE:</strong> Host execution dependencies work in a similiar manner to service execution dependencies. However, they only have an affect on <i>regularly scheduled host checks</i>. On-demand host checks are not affected by host execution dependencies.
</p>
<hr>
</body>
</html>
|
