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
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Host Checks</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="ch05.html" title="Chapter 5. The Basics">
<link rel="prev" href="macrolist.html" title="Standard Macros in Icinga">
<link rel="next" href="servicechecks.html" title="Service Checks">
</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">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="Host Checks">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="hostchecks"></a><a name="host_checks"></a>Host Checks</h2></div></div></div>
<p><span class="bold"><strong>Introduction</strong></span></p>
<p>The basic workings of host checks are described here...</p>
<p><span class="bold"><strong>When Are Host Checks Performed?</strong></span></p>
<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="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="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="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="Predictive Dependency Checks">predictive host dependency
check</a> logic. These checks help ensure that the dependency logic is as accurate as possible.</p>
<p><span class="bold"><strong>Cached Host Checks</strong></span></p>
<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="Cached Checks">here</a>.</p>
<p><span class="bold"><strong>Dependencies and Checks</strong></span></p>
<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="Host and Service Dependencies">here</a>.</p>
<p><span class="bold"><strong>Parallelization of Host Checks</strong></span></p>
<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="Predictive Dependency Checks">predictive dependency checks</a>
and to determining the status of the host using the <a class="link" href="networkreachability.html" title="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="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, I
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>
<p><span class="bold"><strong>Host States</strong></span></p>
<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>
<p><span class="bold"><strong>Host State Determination</strong></span></p>
<p>Host checks are performed by <a class="link" href="plugins.html" title="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="Determining Status and Reachability of Network Hosts">here</a>.</p>
<p><span class="bold"><strong>Host State Changes</strong></span></p>
<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="State Types">state
types</a> (HARD or SOFT), which can trigger <a class="link" href="eventhandlers.html" title="Event Handlers">event handlers</a> to be run and <a class="link" href="notifications.html" title="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="Detection and Handling of State Flapping">here</a>.</p>
<a class="indexterm" name="id1983607"></a>
</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">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"> Service Checks</td>
</tr>
</table>
</div>
<P class="copyright">© 2009-2010 Icinga Development Team, http://www.icinga.org</P>
</body>
</html>
|
