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
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>7.6. Verteilte Überwachung</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 Dokumentation">
<link rel="up" href="ch07.html" title="Kapitel 7. Fortgeschrittene Themen">
<link rel="prev" href="freshness.html" title="7.5. Service- und Host-Frische-Prüfungen">
<link rel="next" href="redundancy.html" title="7.7. Redundante und Failover-Netzwerk-Überwachung">
<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">7.6. Verteilte Überwachung</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="freshness.html">Zurück</a> </td>
<th width="60%" align="center">Kapitel 7. Fortgeschrittene Themen</th>
<td width="20%" align="right"> <a accesskey="n" href="redundancy.html">Weiter</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="section" title="7.6. Verteilte Überwachung">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="distributed"></a>7.6. Verteilte Überwachung</h2></div></div></div>
<div class="toc"><dl>
<dt><span class="section">7.6.1. <a href="distributed.html#introduction">Einführung</a></span></dt>
<dt><span class="section">7.6.2. <a href="distributed.html#goals">Ziele</a></span></dt>
<dt><span class="section">7.6.3. <a href="distributed.html#referencediagram">Referenzdiagramm</a></span></dt>
<dt><span class="section">7.6.4. <a href="distributed.html#centralvsdistributed">Zentraler Server vs. Verteilte Server</a></span></dt>
<dt><span class="section">7.6.5. <a href="distributed.html#servicecheckinfo">Service-Prüfungsinformationen von verteilten Servern erhalten</a></span></dt>
<dt><span class="section">7.6.6. <a href="distributed.html#distributedconfig">Verteilte Server-Konfiguration</a></span></dt>
<dt><span class="section">7.6.7. <a href="distributed.html#oscpsubmitcheckresult">ocsp_command=submit_check_result</a></span></dt>
<dt><span class="section">7.6.8. <a href="distributed.html#centralconfig">zentrale Server-Konfiguration</a></span></dt>
<dt><span class="section">7.6.9. <a href="distributed.html#problemspassive">Probleme bei passiven Prüfungen</a></span></dt>
<dt><span class="section">7.6.10. <a href="distributed.html#freshnesschecks">Frische-Prüfung (Freshness Checking)</a></span></dt>
<dt><span class="section">7.6.11. <a href="distributed.html#hostcheckperforming">Host-Prüfungen durchführen</a></span></dt>
</dl></div>
<div class="section" title="7.6.1. Einführung">
<div class="titlepage"><div><div><h3 class="title">
<a name="introduction"></a>7.6.1. Einführung</h3></div></div></div>
<p>Icinga kann konfiguriert werden, so dass es verteilte Überwachung von Netzwerk-Services und Ressourcen unterstützt. Wir
werden versuchen, kurz zu beschreiben, wie das erreicht werden kann...</p>
</div>
<div class="section" title="7.6.2. Ziele">
<div class="titlepage"><div><div><h3 class="title">
<a name="goals"></a>7.6.2. Ziele</h3></div></div></div>
<p>Das Ziel der verteilten Überwachungsumgebung, das wir beschreiben wollen, ist die Reduzierung des Overheads (CPU-Belastung, etc.)
bei der Service-Prüfung von einem "zentralen" Server auf ein oder mehrere "verteilte" Server. Die meisten kleinen bis mittleren
Unternehmen werden keinen wirklichen Bedarf für das Aufsetzen solch einer Umgebung haben. Wenn Sie allerdings hunderte oder sogar
tausende von <span class="emphasis"><em>Hosts</em></span> (und ein Mehrfaches an Services) mit Icinga überwachen wollen, dann kann das ziemlich
wichtig werden.</p>
</div>
<div class="section" title="7.6.3. Referenzdiagramm">
<div class="titlepage"><div><div><h3 class="title">
<a name="referencediagram"></a>7.6.3. Referenzdiagramm</h3></div></div></div>
<p>Das folgende Diagramm soll Ihnen eine generelle Idee davon geben, wie verteilte Überwachung mit Icinga arbeitet. Wir werden
uns auf die Elemente im Diagramm beziehen, während wir die Dinge erklären...</p>
<p><span class="inlinemediaobject"><img src="../images/distributed.png"></span></p>
</div>
<div class="section" title="7.6.4. Zentraler Server vs. Verteilte Server">
<div class="titlepage"><div><div><h3 class="title">
<a name="centralvsdistributed"></a>7.6.4. Zentraler Server vs. Verteilte Server</h3></div></div></div>
<p>Beim Einrichten einer verteilten Überwachungsumgebung mit Icinga gibt es Unterschiede in der Art, wie zentrale und
verteilte Server konfiguriert sind. Wir werden Ihnen zeigen, wie beide Arten von Servern konfiguriert werden und erklären, welche
Auswirkungen die gemachten Änderungen auf die gesamte Überwachung haben. Für den Anfang beschreiben wir den Zweck der verschiedenen
Server-Typen...</p>
<p>Die Funktion eines <span class="emphasis"><em>verteilten Servers</em></span> ist es, aktiv Prüfungen für alle Services durchzuführen, die Sie für
eine "Gruppe" (Cluster) von Hosts definieren. Wir benutzen den Begriff "Gruppe" locker - er meint lediglich eine willkürliche Gruppe von
Hosts in Ihrem Netzwerk. Abhängig von Ihrem Netzwerk-Layout können Sie mehrere Gruppen in einem physischen Standort haben oder jede
Gruppe kann durch ein WAN voneinander getrennt sein, mit einer eigenen Firewall, usw. Wichtig anzumerken ist, dass es für jede Gruppe
von Hosts (wie immer Sie diese definieren mögen) einen verteilten Server gibt, auf dem Icinga läuft, und der die Services der
Hosts dieser Gruppe überwacht. Ein verteilter Server enthält meistens eine simple Installation von Icinga. Es muss kein
Web-Interface installiert sein, keine Benachrichtigungen versenden, keine Eventhandler-Scripts ausführen, noch etwas anderes tun außer
Service-Prüfungen ausführen, wenn Sie das nicht wollen. Detaillierte Informationen zur Konfiguration eines verteilten Services gibt es
später...</p>
<p>Der Zweck des <span class="emphasis"><em>zentralen</em></span> Servers ist es lediglich, auf Service-Prüfungsergebnisse von einem oder mehreren
verteilten Servern zu horchen. Obwohl Services ab und zu aktiv durch den zentralen Server geprüft werden, werden diese aktiven Prüfungen
nur unter schlimmen Umständen ausgeführt, also lassen Sie uns im Moment sagen, dass der zentrale Server lediglich passive Prüfungen
annimmt. Da der zentrale Server Ergebnisse von <a class="link" href="passivechecks.html" title="5.7. Passive Prüfungen (Passive Checks)">passiven Service-Prüfungen</a> von einem oder mehreren
verteilten Servern erhält, dient er als Mittelpunkt der gesamten Überwachungslogik (d.h., er versendet Benachrichtigungen, startet
Eventhandler-Scripts, legt den Zustand von Hosts fest, enthält das Web-Interface, usw.).</p>
</div>
<div class="section" title="7.6.5. Service-Prüfungsinformationen von verteilten Servern erhalten">
<div class="titlepage"><div><div><h3 class="title">
<a name="servicecheckinfo"></a>7.6.5. Service-Prüfungsinformationen von verteilten Servern erhalten</h3></div></div></div>
<p>Bevor wir näher auf Konfigurationsdetails eingehen, müssen wir wissen, wie die Service-Prüfungsergebnisse von den verteilten
Servern zum zentralen Server geschickt werden. Wir haben bereits erwähnt, wie man passive Prüfungsergebnisse an den gleichen Host
schickt, auf dem Icinga läuft (wie in der Dokumentation zu <a class="link" href="passivechecks.html" title="5.7. Passive Prüfungen (Passive Checks)">passive Prüfungen</a> beschrieben),
aber wir haben keinerlei Informationen darüber gegeben, wie man passive Prüfergebnisse von anderen Hosts verschickt.</p>
<p>Um den Versand von passiven Prüfergebnissen an einen anderen Host zu erleichtern, haben wir das <a class="link" href="addons.html#addons-nsca">nsca-Addon</a> geschrieben. Das Addon besteht aus zwei Teilen. Das erste ist ein Client-Programm (send_nsca),
das auf einem entfernten Host läuft und benutzt wird, um die Service-Prüfergebnisse an einen anderen Server zu senden. Das zweite Teil
ist der nsca-Daemon (nsca), der entweder als eigenständiger Daemon oder unter inetd läuft und auf Verbindungen von Client-Programmen
horcht. Nach dem Empfang von Service-Prüfinformationen von einem Client wird der Daemon die Prüfinformationen an Icinga (auf dem
zentralen Server) weiterleiten, indem ein <span class="emphasis"><em>PROCESS_SVC_CHECK_RESULT</em></span> zusammen mit den Prüfergebnissen in das <a class="link" href="configmain.html#configmain-command_file">external command file</a> eingefügt wird. Das nächste Mal, wenn Icinga auf <a class="link" href="extcommands.html" title="7.1. Externe Befehle">externe Befehle</a> prüft, wird es die passiven Prüfergebnisse finden, die von den verteilten Servern geschickt
wurden und sie verarbeiten. Einfach, oder?</p>
</div>
<div class="section" title="7.6.6. Verteilte Server-Konfiguration">
<div class="titlepage"><div><div><h3 class="title">
<a name="distributedconfig"></a>7.6.6. Verteilte Server-Konfiguration</h3></div></div></div>
<p>Also wie genau wird Icinga auf einem verteilten Server konfiguriert? Grundsätzlich ist es eine einfache Installation. Sie
müssen weder ein Web-Interface installieren noch Benachrichtigungen versenden, weil dies alles vom zentralen Server aus erledigt
wird.</p>
<p>Haupt-Konfigurationsanpassungen:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>Nur die direkt durch den verteilten Server zu überwachenden Services werden in der <a class="link" href="configobject.html" title="3.3. Überblick Objektkonfiguration">Objekt-Konfigurationsdatei</a> definiert.</p>
<div class="note" title="Anmerkung" 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="[Anmerkung]" src="../images/note.png"></td>
<th align="left">Anmerkung</th>
</tr>
<tr><td align="left" valign="top">
<p>Obwohl "obsess_over_service" per Standard in der Objektdefinition aktiviert ist, kann es ggf. durch Templates
<span class="emphasis"><em>de</em></span>aktiviert sein, so dass Sie sicherstellen sollten, dass diese Direktive aktiviert ist, wie sie benötigt
wird.</p>
</td></tr>
</table></div>
</li>
<li class="listitem">
<p>Die <a class="link" href="configmain.html#configmain-enable_notifications">enable_notifications</a>-Direktive auf dem verteilten Server wird auf 0
gesetzt. Das verhindert das Versenden von Benachrichtigungen.</p>
</li>
<li class="listitem">
<p>Die <a class="link" href="configmain.html#configmain-obsess_over_services">obsess over services</a>-Direktive auf dem verteilten Server wird
aktiviert.</p>
</li>
<li class="listitem">
<p>Auf dem verteilten Server ist ein <a class="link" href="configmain.html#configmain-ocsp_command">ocsp command</a> definiert (wie unten
beschrieben).</p>
</li>
</ul></div>
<p>Damit alles zusammenkommt und ordentlich arbeitet, wollen wir, dass der verteilte Server die Ergebnisse <span class="emphasis"><em>aller</em></span>
Service-Prüfungen an Icinga meldet. Wir können <a class="link" href="eventhandlers.html" title="7.3. Eventhandler">Eventhandler</a> benutzen, um
<span class="emphasis"><em>Änderungen</em></span> am Zustand eines Service mitzuteilen, aber das bringt's nicht. Um den verteilten Server zu zwingen, alle
Prüfergebnisse zu melden, müssen Sie die <a class="link" href="configmain.html#configmain-obsess_over_services">obsess_over_services</a>-Option in der
Hauptkonfigurationsdatei aktivieren und ein <a class="link" href="configmain.html#configmain-ocsp_command">ocsp_command</a> bereitstellen, was nach jeder
Service-Prüfung ausgeführt wird. Wir werden das ocsp-Kommando benutzen, um die Ergebnisse aller Service-Prüfungen an den zentralen
Server zu senden und den send_nsca-Client sowie den nsca-Daemon benutzen (wie oben beschrieben), um die Übertragung zu erledigen.</p>
<p>Um dies zu erreichen, müssen Sie ein ocsp-Kommando wie folgt definieren:</p>
</div>
<div class="section" title="7.6.7. ocsp_command=submit_check_result">
<div class="titlepage"><div><div><h3 class="title">
<a name="oscpsubmitcheckresult"></a>7.6.7. ocsp_command=submit_check_result</h3></div></div></div>
<p>Die Definition für den <span class="emphasis"><em>submit_check_result</em></span>-Befehl sieht ungefähr so aus:</p>
<pre class="programlisting"> define command{
command_name submit_check_result
command_line /usr/local/icinga/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$'
}</pre>
<p>Die <span class="emphasis"><em>submit_check_result</em></span> Shell-Scripte sehen ungefähr so aus (ersetzen Sie <span class="emphasis"><em>central_server</em></span>
durch die IP-Adresse des zentralen Servers):</p>
<pre class="programlisting"> #!/bin/sh
# Arguments:
# $1 = host_name (Short name of host that the service is
# associated with)
# $2 = svc_description (Description of the service)
# $3 = state_string (A string representing the status of
# the given service - "OK", "WARNING", "CRITICAL"
# or "UNKNOWN")
# $4 = plugin_output (A text string that should be used
# as the plugin output for the service checks)
#
# Convert the state string to the corresponding return code
return_code=-1
case "$3" in
OK)
return_code=0
;;
WARNING)
return_code=1
;;
CRITICAL)
return_code=2
;;
UNKNOWN)
return_code=-1
;;
esac
# pipe the service check info into the send_nsca program, which
# in turn transmits the data to the nsca daemon on the central
# monitoring server
/bin/printf "%s\t%s\t%s\t%s\n" "$1" "$2" "$return_code" "$4" | /usr/local/icinga/bin/send_nsca -H <span class="emphasis"><strong> central_server</strong></span> -c /usr/local/icinga/etc/send_nsca.cfg</pre>
<p>Das Script oben geht davon aus, dass das send_nsca-Programm und die Konfigurationsdatei (send_nsca.cfg) in den Verzeichnissen
<span class="emphasis"><em>/usr/local/icinga/bin/</em></span> und <span class="emphasis"><em>/usr/local/icinga/etc/</em></span> zu finden sind.</p>
<p>Das ist alles! Wir haben erfolgreich einen entfernten Host konfiguriert, auf dem Icinga als ein verteilter
Überwachungs-Server läuft. Lassen Sie uns genau betrachten, was mit dem verteilten Server passiert und wie er Service-Prüfungsergebnisse
an Icinga schickt (die unten skizzierten Schritte entsprechen den Zahlen im obigen Referenzdiagramm):</p>
<div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem">
<p>Nachdem der verteilte Server eine Service-Prüfung beendet hat, führt er den Befehl aus, den Sie mit der Variable <a class="link" href="configmain.html#configmain-ocsp_command">ocsp_command</a> definiert haben. In unserem Beispiel ist dies das
<span class="emphasis"><em>/usr/local/icinga/libexec/eventhandlers/submit_check_result</em></span>-Script. Beachten Sie, dass die Definition für den
<span class="emphasis"><em>submit_check_result</em></span>-Befehl vier Parameter für das Script übergibt: den Namen des Hosts, der mit dem Service
verbunden ist, die Service-Beschreibung, den Rückgabewert der Service-Prüfung und die Plugin-Ausgabe der Service-Prüfung.</p>
</li>
<li class="listitem">
<p>das <span class="emphasis"><em>submit_check_result</em></span>-Script übergibt die Informationen der Service-Prüfung (Host-Name, Beschreibung,
Rückgabewert und Ausgabe) an das <span class="emphasis"><em>send_nsca</em></span>-Client-Programm.</p>
</li>
<li class="listitem">
<p>das <span class="emphasis"><em>send_nsca</em></span>-Programm überträgt die Informationen der Service-Prüfung an den
<span class="emphasis"><em>nsca</em></span>-Daemon auf dem zentralen Überwachungs-Server.</p>
</li>
<li class="listitem">
<p>der <span class="emphasis"><em>nsca</em></span>-Daemon auf dem zentralen Server nimmt die Informationen der Service-Prüfung und schreibt sie in
das external command file, damit Icinga sie später dort aufsammeln kann.</p>
</li>
<li class="listitem">
<p>der Icinga-Prozess auf dem zentralen Server liest das external command file und verarbeitet die passiven
Service-Prüfungsergebnisse, die vom verteilten Überwachungs-Server stammen.</p>
</li>
</ol></div>
</div>
<div class="section" title="7.6.8. zentrale Server-Konfiguration">
<div class="titlepage"><div><div><h3 class="title">
<a name="centralconfig"></a>7.6.8. zentrale Server-Konfiguration</h3></div></div></div>
<p>Wir haben betrachtet, wie verteilte Überwachungs-Server konfiguriert werden sollten, daher wenden wir uns nun dem zentralen Server
zu. Für alle wichtigen Dinge wird der zentrale so konfiguriert wie ein einzelner Server. Dessen Setup ist wie folgt:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>auf dem zentralen Server ist das Web-Interface installiert (optional, aber empfohlen)</p>
</li>
<li class="listitem">
<p>auf dem zentralen Server ist die <a class="link" href="configmain.html#configmain-enable_notifications">enable_notifications</a>-Direktive auf 1
gesetzt. Das aktiviert Benachrichtungen (optional, aber empfohlen)</p>
</li>
<li class="listitem">
<p>auf dem zentralen Server sind <a class="link" href="configmain.html#configmain-execute_service_checks">aktive Service-Prüfungen</a> deaktiviert
(optional, aber empfohlen - beachten Sie die folgenden Anmerkungen)</p>
</li>
<li class="listitem">
<p>auf dem zentralen Server sind <a class="link" href="configmain.html#configmain-check_external_commands">external command checks</a> aktiviert
(erforderlich)</p>
</li>
<li class="listitem">
<p>auf dem zentralen Server sind <a class="link" href="configmain.html#configmain-accept_passive_service_checks">passive Service-Prüfungen</a>
aktiviert (erforderlich)</p>
</li>
</ul></div>
<p>Es gibt drei andere sehr wichtige Dinge, die Sie beachten sollten, wenn Sie den zentralen Server konfigurieren:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>Der zentrale Server muss Service-Definitionen für <span class="emphasis"><em>alle Services</em></span> haben, die auf allen verteilten Servern
überwacht werden. Icinga wird passive Prüfungsergebnisse ignorieren, wenn sie nicht zu einem Service passen, den Sie
definiert haben.</p>
</li>
<li class="listitem">
<p>Wenn Sie den zentralen Server nur benutzen, um Services zu verarbeiten, deren Ergebnisse von verteilten Hosts stammen, können
Sie alle aktiven Service-Prüfungen auf programmweiter Basis durch das Setzen der <a class="link" href="configmain.html#configmain-execute_service_checks">execute_service_checks</a>-Direktive auf 0 deaktivieren. Wenn Sie den zentralen
Server nutzen, um selbst einige Services aktiv zu überwachen (ohne die Hilfe von verteilten Servern), dann sollten Sie die
<span class="emphasis"><em>active_checks_enabled</em></span>-Option der Service-Definitionen auf 0 setzen, die von den verteilten Servern überwacht
werden. Das hindert Icinga daran, diese Services aktiv zu prüfen.</p>
</li>
</ul></div>
<p>Es ist wichtig, dass Sie entweder alle Service-Prüfungen auf einer programmweiten Basis deaktivieren oder die
<span class="emphasis"><em>enable_active_checks</em></span>-Option in jeder Service-Definition deaktivieren, die von einem verteilten Server überwacht
werden. Das stellt sicher, dass aktive Service-Prüfungen unter normalen Umständen niemals ausgeführt werden. Die Services werden
weiterhin im normalen Prüfintervall geplant (3 Min., 5 Min., usw.), aber nicht ausgeführt. Wir werden bald erklären, warum das so
ist...</p>
<p>Das war's! Einfach, oder?</p>
</div>
<div class="section" title="7.6.9. Probleme bei passiven Prüfungen">
<div class="titlepage"><div><div><h3 class="title">
<a name="problemspassive"></a>7.6.9. Probleme bei passiven Prüfungen</h3></div></div></div>
<p>Für alle wichtigen Dinge können wir sagen, dass sich der zentrale Server bei Überwachungen allein auf passive Prüfungen verlässt.
Das Hauptproblem daran, sich komplett auf passive Prüfungen zu verlassen besteht darin, dass Icinga darauf vertrauen muss, dass
jemand anders die Daten liefert. Was passiert, wenn der entfernte Host, der passive Prüfergebnisse sendet, herunterfährt oder
unerreichbar wird? Wenn Icinga nicht aktiv die Services auf dem Host prüft, wie soll es wissen, wann es ein Problem gibt?</p>
<p>Glücklicherweise gibt es einen Weg, diese Art von Problemen zu behandeln...</p>
</div>
<div class="section" title="7.6.10. Frische-Prüfung (Freshness Checking)">
<div class="titlepage"><div><div><h3 class="title">
<a name="freshnesschecks"></a>7.6.10. Frische-Prüfung (Freshness Checking)</h3></div></div></div>
<p>Icinga unterstützt ein Feature, das eine "Frische"-Prüfung für die Ergebnisse von Service-Prüfungen durchführt. Mehr
Informationen über Frische-Prüfung finden Sie <a class="link" href="freshness.html" title="7.5. Service- und Host-Frische-Prüfungen">hier</a>. Dieses Feature sorgt für etwas Schutz gegen
Situationen, in denen entfernte Hosts keine passiven Service-Prüfungen mehr an den zentralen Überwachungs-Server schicken. Der Zweck der
"Frische"-Prüfung besteht darin, sicherzustellen, dass Service-Prüfungen entweder regelmäßig passiv durch verteilte Server oder aktiv
durch den zentralen Server durchgeführt werden, falls dies notwendig sein sollte. Wenn die Service-Prüfergebnisse von verteilten Servern
als "abgestanden" angesehen werden, kann Icinga so konfiguriert werden, um aktive Prüfungen des Service vom zentralen
Überwachungs-Server aus zu erzwingen.</p>
<p>Wie machen Sie das? Auf dem zentralen Überwachungs-Server müssen Sie Services konfigurieren, die von verteilten Server wie folgt
überwacht werden:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>Die <span class="emphasis"><em>check_freshness</em></span>-Option in der Service-Definition ist auf 1 zu setzen. Das aktiviert
"Frische"-Prüfungen für den Service.</p>
</li>
<li class="listitem">
<p>Die <span class="emphasis"><em>freshness_threshold</em></span>-Option in den Service-Definitionen sollte auf einen Wert (in Sekunden) gesetzt
werden, der widerspiegelt, wie "frisch" die (von den entfernten Servern gelieferten) Ergebnisse der Service-Prüfungen sein
sollten.</p>
</li>
<li class="listitem">
<p>Die <span class="emphasis"><em>check_command</em></span>-Option in den Service-Definitionen sollte gültige Befehle enthalten, die genutzt werden
können, um den Service aktiv vom zentralen Server aus zu prüfen.</p>
</li>
</ul></div>
<p>Icinga prüft periodisch die "Frische" der Ergebnisse aller Services, für die Frische-Prüfungen aktiviert sind. Die
<span class="emphasis"><em>freshness_threshold</em></span>-Option in jeder Service-Definition wird benutzt, um festzulegen, wie "frisch" die Ergebnisse
für jeden Service sein sollen. Wenn Sie z.B. diesen Wert für einen Ihrer Services auf 300 setzen, wird Icinga das
Service-Ergebnis als "abgestanden" betrachten, wenn es älter als 5 Minuten (300 Sekunden) ist. Falls Sie keinen Wert für die
<span class="emphasis"><em>freshness_threshold</em></span>-Option angeben, wird Icinga automatisch einen "Frische"-Schwellwert berechnen, indem es
die Werte der <span class="emphasis"><em>check_interval</em></span>- oder der <span class="emphasis"><em>retry_interval</em></span>-Option betrachtet (abhängig vom <a class="link" href="statetypes.html" title="5.8. Statustypen">Statustyp</a>, in dem sich der Service befindet). Wenn die Service-Ergebnisse als "abgestanden" angesehen
werden, wird Icinga den Service-Prüf-Befehl ausführen, der in der <span class="emphasis"><em>check_command</em></span>-Option der
Service-Definition angegeben ist, und dadurch den Service aktiv prüfen.</p>
<p>Denken Sie daran, dass Sie eine <span class="emphasis"><em>check_command</em></span>-Option in den Service-Definitionen angeben müssen, die genutzt
werden kann, um den Status des Service aktiv vom zentralen Server aus zu prüfen. Unter normalen Umständen wird dieser Prüfbefehl niemals
ausgeführt (weil aktive Prüfungen auf programmweiter Ebene bzw. für den einzelnen Service deaktiviert wurden). Wenn Frische-Prüfungen
aktiviert sind, wird Icinga diesen Befehl ausführen, um den Zustand des Service aktiv zu prüfen, <span class="emphasis"><em>auch wenn aktive
Prüfungen auf einer programmweiten Ebene oder Service-spezifischen Basis deaktiviert sind</em></span>.</p>
<p>Falls Sie es nicht schaffen, Befehle zu definieren, um aktiv einen Service vom zentralen Überwachungs-Host aus zu prüfen (oder
wenn es zu einer großen Qual wird), können Sie ganz einfach bei all Ihren Services in der <span class="emphasis"><em>check_command</em></span>-Option ein
Dummy-Script angeben, das einen kritischen Status zurückliefert. Hier ein Beispiel... Lassen Sie uns annehmen, Sie definieren einen
Befehl namens 'service-is-stale' und benutzen den Befehlsnamen in der <span class="emphasis"><em>check_command</em></span>-Option Ihrer Services. Hier
nun, wie die Definition aussehen könnte...</p>
<pre class="programlisting"> define command{
command_name service-is-stale
command_line /usr/local/icinga/libexec/check_dummy 2 "CRITICAL: Service results are stale"
}</pre>
<p>Wenn Icinga feststellt, dass das Service-Ergebnis abgestanden ist und das <span class="bold"><strong>service-is-stale</strong></span>-Kommando aufruft, wird das <span class="emphasis"><em>/usr/local/icinga/libexec/check_dummy</em></span>-Plugin
ausgeführt und der Service geht in einen kritischen Zustand. Das wird wahrscheinlich dazu führen, dass Benachrichtigungen versandt
werden, so dass Sie wissen, dass es ein Problem gibt.</p>
</div>
<div class="section" title="7.6.11. Host-Prüfungen durchführen">
<div class="titlepage"><div><div><h3 class="title">
<a name="hostcheckperforming"></a>7.6.11. Host-Prüfungen durchführen</h3></div></div></div>
<p>An diesem Punkt wissen Sie, wie man Service-Ergebnisse von verteilten Servern auf passive Weise erhält. Das bedeutet, der zentrale
Server nicht aktiv Service-Prüfungen ausführt. Aber was ist mit Host-Prüfungen? Sie müssen sie trotzdem erledigen, aber wie?</p>
<p>Nachdem Host-Prüfungen normalerweise einen kleinen Teil der Überwachungsaktivität verbrauchen (sie werden nur ausgeführt, wenn es
dringend notwendig ist), raten wir dazu, dass Sie die Host-Prüfungen aktiv vom zentralen Server aus durchführen. Das bedeutet, dass Sie
Host-Prüfungen auf dem zentralen Server genau wie auf den verteilten Servern definieren (und auf die gleiche Weise, wie Sie das in einer
normalen, nicht-verteilten Umgebung tun würden).</p>
<p>Passive Host-Prüfungen sind verfügbar (lesen Sie <a class="link" href="passivechecks.html" title="5.7. Passive Prüfungen (Passive Checks)">hier</a>), so dass Sie diese in Ihrer verteilten
Umgebung nutzen können, allerdings gibt es dabei ein paar Probleme. Das größte Problem besteht darin, dass Icinga Ergebnisse von
passiven Host-Prüfungen (die Problemzustände DOWN und UNREACHABLE) nicht übersetzt, wenn sie verarbeitet werden. Das bedeutet, falls
Ihre Überwachungs-Server eine unterschiedliche Eltern-/Kind-Host-Struktur haben (und das werden sie, wenn Ihre Überwachungs-Server an
unterschiedlichen Standorten stehen), wird der zentrale Überwachungs-Server eine ungenaue Sicht Ihrer Host-Zustände haben.</p>
<p>Falls Sie in Ihrer verteilten Überwachungs-Umgebung passive Host-Prüfungen an einen zentralen Server senden möchten, dann stellen
Sie sicher:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>dass auf dem zentralen Server <a class="link" href="configmain.html#configmain-accept_passive_host_checks">passive Host-Prüfungen</a> aktiviert
sind (notwendig)</p>
</li>
<li class="listitem">
<p>dass auf dem verteilten Server <a class="link" href="configmain.html#configmain-obsess_over_hosts">obsess over hosts</a> aktiviert ist.</p>
<div class="note" title="Anmerkung" 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="[Anmerkung]" src="../images/note.png"></td>
<th align="left">Anmerkung</th>
</tr>
<tr><td align="left" valign="top">
<p>Obwohl "obsess_over_host" per Standard in der Objektdefinition aktiviert ist, kann es ggf. durch Templates
<span class="emphasis"><em>de</em></span>aktiviert sein, so dass Sie sicherstellen sollten, dass diese Direktive aktiviert ist, wie sie benötigt
wird.</p>
</td></tr>
</table></div>
</li>
<li class="listitem">
<p>dass auf dem verteilten Server ein <a class="link" href="configmain.html#configmain-ochp_command">ochp command</a> definiert ist.</p>
</li>
</ul></div>
<p>Der ochp-Befehl, der zur Verarbeitung von Host-Prüfergebnissen genutzt wird, arbeitet ähnlich wie der ocsp-Befehl, der für die
Verarbeitung von Service-Prüfergebnissen benutzt wird (siehe oben). Um sicherzustellen, dass passive Host-Prüfergebnisse aktuell sind,
sollten Sie <a class="link" href="freshness.html" title="7.5. Service- und Host-Frische-Prüfungen">Frische-Prüfungen</a> für Hosts aktivieren (ähnlich zu dem, was weiter oben für Services
beschrieben wird).</p>
<a class="indexterm" name="idm139734666025072"></a>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="freshness.html">Zurück</a> </td>
<td width="20%" align="center"><a accesskey="u" href="ch07.html">Nach oben</a></td>
<td width="40%" align="right"> <a accesskey="n" href="redundancy.html">Weiter</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">7.5. Service- und Host-Frische-Prüfungen </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td>
<td width="40%" align="right" valign="top"> 7.7. Redundante und Failover-Netzwerk-Überwachung</td>
</tr>
</table>
</div>
<P class="copyright">© 1999-2009 Ethan Galstad, 2009-2017 Icinga Development Team, https://www.icinga.com</P>
</body>
</html>
|
