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
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Verteilte Überwachung</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.75.1">
<meta name="keywords" content="Supervision, Icinga, Icinga, Linux">
<link rel="home" href="index.html" title="Icinga Version 1.0.2 Dokumentation">
<link rel="up" href="ch06.html" title="Kapitel 6. Fortgeschrittene Themen">
<link rel="prev" href="freshness.html" title="Service- und Host-Frische-Prüfungen">
<link rel="next" href="redundancy.html" title="Redundante und Failover-Netzwerk-Überwachung">
</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">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 6. 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="Verteilte Überwachung">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="distributed"></a>Verteilte Überwachung</h2></div></div></div>
<p><span class="bold"><strong>Einführung</strong></span></p>
<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>
<p><span class="bold"><strong>Ziele</strong></span></p>
<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>
<p><span class="bold"><strong>Referenzdiagramm</strong></span></p>
<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>
<p><span class="bold"><strong>Zentraler Server vs. Verteilte Server</strong></span></p>
<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="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>
<p><span class="bold"><strong>Service-Prüfungsinformationen von verteilten Servern erhalten</strong></span></p>
<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="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="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>
<p><span class="bold"><strong>Verteilte Server-Konfiguration</strong></span></p>
<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="Überblick Objektkonfiguration">Objekt-Konfigurationsdatei</a> definiert.</p>
</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="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>
<p><span class="bold"><strong>ocsp_command=submit_check_result</strong></span></p>
<p>Die Definition für den <span class="emphasis"><em>submit_check_result</em></span>-Befehl sieht ungefähr so aus:</p>
<pre class="screen">
<span class="bold"><strong>define command{ command_name submit_check_result command_line /usr/local/icinga/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$' }</strong></span>
</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="screen"> #!/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"><em> central_server</em></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>
<p><span class="bold"><strong>zentrale Server-Konfiguration</strong></span></p>
<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>enable_active_checks</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>
<p><span class="bold"><strong>Probleme bei passiven Prüfungen</strong></span></p>
<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>
<p><span class="bold"><strong>Frische-Prüfung (Freshness Checking)</strong></span></p>
<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="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>normal_check_interval</em></span>- oder der <span class="emphasis"><em>retry_check_interval</em></span>-Option
betrachtet (abhängig vom <a class="link" href="statetypes.html" title="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="screen">
<span class="bold"><strong> define command{ command_name service-is-stale command_line /usr/local/icinga/libexec/check_dummy 2 "CRITICAL: Service results are stale" }</strong></span>
</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>
<p><span class="bold"><strong>Host-Prüfungen durchführen</strong></span></p>
<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="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>
</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="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="id5596728"></a>
</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="ch06.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">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"> Redundante und Failover-Netzwerk-Überwachung</td>
</tr>
</table>
</div>
<P class="copyright">© 2009-2010 Icinga Development Team, http://www.icinga.org</P>
</body>
</html>
|
