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
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>5.4. Host Checks</title>
<link rel="stylesheet" href="../stylesheets/icinga-docs.css" type="text/css">
<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.14 Documentation">
<link rel="up" href="ch05.html" title="Chapter 5. The Basics">
<link rel="prev" href="macrolist.html" title="5.3. Standard Macros in Icinga">
<link rel="next" href="servicechecks.html" title="5.5. Service Checks">
<script src="../js/jquery-min.js" type="text/javascript"></script><script src="../js/icinga-docs.js" type="text/javascript"></script>
</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">5.4. Host Checks</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="macrolist.html">Prev</a> </td>
<th width="60%" align="center">Chapter 5. The Basics</th>
<td width="20%" align="right"> <a accesskey="n" href="servicechecks.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="section" title="5.4. Host Checks">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="hostchecks"></a>5.4. <a name="host_checks"></a>Host Checks</h2></div></div></div>
<div class="toc"><dl>
<dt><span class="section">5.4.1. <a href="hostchecks.html#introduction">Introduction</a></span></dt>
<dt><span class="section">5.4.2. <a href="hostchecks.html#whenrun">When Are Host Checks Performed?</a></span></dt>
<dt><span class="section">5.4.3. <a href="hostchecks.html#caching">Cached Host Checks</a></span></dt>
<dt><span class="section">5.4.4. <a href="hostchecks.html#dependencieschecks">Dependencies and Checks</a></span></dt>
<dt><span class="section">5.4.5. <a href="hostchecks.html#parallelization">Parallelization of Host Checks</a></span></dt>
<dt><span class="section">5.4.6. <a href="hostchecks.html#hoststates">Host States</a></span></dt>
<dt><span class="section">5.4.7. <a href="hostchecks.html#hoststatedetermination">Host State Determination</a></span></dt>
<dt><span class="section">5.4.8. <a href="hostchecks.html#hoststatechanges">Host State Changes</a></span></dt>
</dl></div>
<div class="section" title="5.4.1. Introduction">
<div class="titlepage"><div><div><h3 class="title">
<a name="introduction"></a>5.4.1. Introduction</h3></div></div></div>
<p>The basic workings of host checks are described here...</p>
</div>
<div class="section" title="5.4.2. When Are Host Checks Performed?">
<div class="titlepage"><div><div><h3 class="title">
<a name="whenrun"></a>5.4.2. When Are Host Checks Performed?</h3></div></div></div>
<p>Hosts are checked by the Icinga daemon:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>At regular intervals, as defined by the <span class="emphasis"><em>check_interval</em></span> and <span class="emphasis"><em>retry_interval</em></span> options in
your <a class="link" href="objectdefinitions.html#objectdefinitions-host">host definitions</a>.</p>
</li>
<li class="listitem">
<p>On-demand when a service associated with the host changes state.</p>
</li>
<li class="listitem">
<p>On-demand as needed as part of the <a class="link" href="networkreachability.html" title="5.10. Determining Status and Reachability of Network Hosts">host reachability</a> logic.</p>
</li>
<li class="listitem">
<p>On-demand as needed for <a class="link" href="dependencychecks.html" title="7.20. Predictive Dependency Checks">predictive host dependency checks</a>.</p>
</li>
</ul></div>
<p>Regularly scheduled host checks are optional. If you set the <span class="emphasis"><em>check_interval</em></span> option in your host definition to
zero (0), Icinga will not perform checks of the hosts on a regular basis. It will, however, still perform on-demand checks of the
host as needed for other parts of the monitoring logic.</p>
<p>On-demand checks are made when a service associated with the host changes state because Icinga needs to know whether the
host has also changed state. Services that change state are often an indicator that the host may have also changed state. For example,
if Icinga detects that the HTTP service associated with a host just changed from a CRITICAL to an OK state, it may indicate that
the host just recovered from a reboot and is now back up and running.</p>
<p>On-demand checks of hosts are also made as part of the <a class="link" href="networkreachability.html" title="5.10. Determining Status and Reachability of Network Hosts">host reachability</a> logic.
Icinga is designed to detect network outages as quickly as possible, and distinguish between DOWN and UNREACHABLE host states.
These are very different states and can help an admin quickly locate the cause of a network outage.</p>
<p>On-demand checks are also performed as part of the <a class="link" href="dependencychecks.html" title="7.20. Predictive Dependency Checks">predictive host dependency check</a> logic.
These checks help ensure that the dependency logic is as accurate as possible.</p>
</div>
<div class="section" title="5.4.3. Cached Host Checks">
<div class="titlepage"><div><div><h3 class="title">
<a name="caching"></a>5.4.3. Cached Host Checks</h3></div></div></div>
<p>The performance of on-demand host checks can be significantly improved by implementing the use of cached checks, which allow
Icinga to forgo executing a host check if it determines a relatively recent check result will do instead. More information on
cached checks can be found <a class="link" href="cachedchecks.html" title="7.21. Cached Checks">here</a>.</p>
</div>
<div class="section" title="5.4.4. Dependencies and Checks">
<div class="titlepage"><div><div><h3 class="title">
<a name="dependencieschecks"></a>5.4.4. Dependencies and Checks</h3></div></div></div>
<p>You can define <a class="link" href="objectdefinitions.html#objectdefinitions-hostdependency">host execution dependencies</a> that prevent Icinga from
checking the status of a host depending on the state of one or more other hosts. More information on dependencies can be found <a class="link" href="dependencies.html" title="7.13. Host and Service Dependencies">here</a>.</p>
</div>
<div class="section" title="5.4.5. Parallelization of Host Checks">
<div class="titlepage"><div><div><h3 class="title">
<a name="parallelization"></a>5.4.5. Parallelization of Host Checks</h3></div></div></div>
<p>Scheduled host checks are run in parallel. When Icinga needs to run a scheduled host check, it will initiate the host check
and then return to doing other work (running service checks, etc). The host check runs in a child process that was fork()ed from the
main Icinga daemon. When the host check has completed, the child process will inform the main Icinga process (its parent)
of the check results. The main Icinga process then handles the check results and takes appropriate action (running event
handlers, sending notifications, etc.).</p>
<p>On-demand host checks are also run in parallel if needed. As mentioned earlier, Icinga can forgo the actual execution of an
on-demand host check if it can use the cached results from a relatively recent host check.</p>
<p>When Icinga processes the results of scheduled and on-demand host checks, it may initiate (secondary) checks of other
hosts. These checks can be initated for two reasons: <a class="link" href="dependencychecks.html" title="7.20. Predictive Dependency Checks">predictive dependency checks</a> and to
determining the status of the host using the <a class="link" href="networkreachability.html" title="5.10. Determining Status and Reachability of Network Hosts">network reachability</a> logic. The secondary checks
that are initiated are usually run in parallel. However, there is one big exception that you should be aware of, as it can have negative
effect on performance...</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>Hosts which have their <span class="emphasis"><em>max_check_attempts</em></span> value set to <span class="bold"><strong>1</strong></span> can cause serious
performance problems. The reason? If Icinga needs to determine their true state using the <a class="link" href="networkreachability.html" title="5.10. Determining Status and Reachability of Network Hosts">network reachability</a> logic (to see if they're DOWN or UNREACHABLE), it will have to launch
<span class="bold"><strong>serial</strong></span> checks of all of the host's immediate parents. Just to reiterate, those checks are run
<span class="emphasis"><em>serially</em></span>, rather than in parallel, so it can cause a big performance hit. For this reason, we would recommend
that you always use a value greater than 1 for the <span class="emphasis"><em>max_check_attempts</em></span> directives in your host definitions.</p>
</td></tr>
</table></div>
</div>
<div class="section" title="5.4.6. Host States">
<div class="titlepage"><div><div><h3 class="title">
<a name="hoststates"></a>5.4.6. Host States</h3></div></div></div>
<p>Hosts that are checked can be in one of three different states:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>UP</p>
</li>
<li class="listitem">
<p>DOWN</p>
</li>
<li class="listitem">
<p>UNREACHABLE</p>
</li>
</ul></div>
</div>
<div class="section" title="5.4.7. Host State Determination">
<div class="titlepage"><div><div><h3 class="title">
<a name="hoststatedetermination"></a>5.4.7. Host State Determination</h3></div></div></div>
<p>Host checks are performed by <a class="link" href="plugins.html" title="5.1. Icinga Plugins">plugins</a>, which can return a state of OK, WARNING, UNKNOWN, or
CRITICAL. How does Icinga translate these plugin return codes into host states of UP, DOWN, or UNREACHABLE? Lets see...</p>
<p>The table below shows how plugin return codes correspond with preliminary host states. Some post-processing (which is described
later) is done which may then alter the final host state.</p>
<div class="informaltable">
<table border="1">
<colgroup>
<col>
<col>
</colgroup>
<tbody>
<tr>
<td><p> <span class="bold"><strong>Plugin Result</strong></span> </p></td>
<td><p> <span class="bold"><strong>Preliminary Host State</strong></span> </p></td>
</tr>
<tr>
<td><p>OK</p></td>
<td><p>UP</p></td>
</tr>
<tr>
<td><p>WARNING</p></td>
<td><p>UP or DOWN<sup>*</sup></p></td>
</tr>
<tr>
<td><p>UNKNOWN</p></td>
<td><p>DOWN</p></td>
</tr>
<tr>
<td><p>CRITICAL</p></td>
<td><p>DOWN</p></td>
</tr>
</tbody>
</table>
</div>
<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>WARNING results usually means the host is UP. However, WARNING results are interpreted to mean the host is DOWN if the <a class="link" href="configmain.html#configmain-use_aggressive_host_checking">use_aggressive_host_checking</a> option is enabled.</p>
</td></tr>
</table></div>
<p>If the preliminary host state is DOWN, Icinga will attempt to see if the host is really DOWN or if it is UNREACHABLE. The
distinction between DOWN and UNREACHABLE host states is important, as it allows admins to determine root cause of network outages
faster. The following table shows how Icinga makes a final state determination based on the state of the hosts parent(s). A
host's parents are defined in the <span class="emphasis"><em>parents</em></span> directive in host definition.</p>
<div class="informaltable">
<table border="1">
<colgroup>
<col>
<col>
<col>
</colgroup>
<tbody>
<tr>
<td><p> <span class="bold"><strong>Preliminary Host State</strong></span> </p></td>
<td><p> <span class="bold"><strong>Parent Host State</strong></span> </p></td>
<td><p> <span class="bold"><strong>Final Host State</strong></span> </p></td>
</tr>
<tr>
<td><p>DOWN</p></td>
<td><p>At least one parent is UP</p></td>
<td><p>DOWN</p></td>
</tr>
<tr>
<td><p>DOWN</p></td>
<td><p>All parents are either DOWN or UNREACHABLE</p></td>
<td><p>UNREACHABLE</p></td>
</tr>
</tbody>
</table>
</div>
<p>More information on how Icinga distinguishes between DOWN and UNREACHABLE states can be found <a class="link" href="networkreachability.html" title="5.10. Determining Status and Reachability of Network Hosts">here</a>.</p>
</div>
<div class="section" title="5.4.8. Host State Changes">
<div class="titlepage"><div><div><h3 class="title">
<a name="hoststatechanges"></a>5.4.8. Host State Changes</h3></div></div></div>
<p>As you are probably well aware, hosts don't always stay in one state. Things break, patches get applied, and servers need to be
rebooted. When Icinga checks the status of hosts, it will be able to detect when a host changes between UP, DOWN, and UNREACHABLE
states and take appropriate action. These state changes result in different <a class="link" href="statetypes.html" title="5.8. State Types">state types</a> (HARD or
SOFT), which can trigger <a class="link" href="eventhandlers.html" title="7.3. Event Handlers">event handlers</a> to be run and <a class="link" href="notifications.html" title="5.11. Notifications">notifications</a> to be sent out. Detecting and dealing with state changes is what Icinga is all
about.</p>
<p>When hosts change state too frequently they are considered to be "flapping". A good example of a flapping host would be server
that keeps spontaneously rebooting as soon as the operating system loads. That's always a fun scenario to have to deal with.
Icinga can detect when hosts start flapping, and can suppress notifications until flapping stops and the host's state stabilizes.
More information on the flap detection logic can be found <a class="link" href="flapping.html" title="7.8. Detection and Handling of State Flapping">here</a>.</p>
<a class="indexterm" name="idm140381628917488"></a>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="macrolist.html">Prev</a> </td>
<td width="20%" align="center"><a accesskey="u" href="ch05.html">Up</a></td>
<td width="40%" align="right"> <a accesskey="n" href="servicechecks.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">5.3. Standard Macros in Icinga </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td>
<td width="40%" align="right" valign="top"> 5.5. Service Checks</td>
</tr>
</table>
</div>
<P class="copyright">© 1999-2009 Ethan Galstad, 2009-2017 Icinga Development Team, https://www.icinga.com</P>
</body>
</html>
|
