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
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>7.23. Service- und Host-Prüfungsplanung</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="passivestatetranslation.html" title="7.22. Passive Host-Zustandsübersetzung">
<link rel="next" href="cgiincludes.html" title="7.24. Angepasste Classic UI-Modul-Kopf- und Fußzeilen">
<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.23. Service- und Host-Prüfungsplanung</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="passivestatetranslation.html">Zurück</a> </td>
<th width="60%" align="center">Kapitel 7. Fortgeschrittene Themen</th>
<td width="20%" align="right"> <a accesskey="n" href="cgiincludes.html">Weiter</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="section" title="7.23. Service- und Host-Prüfungsplanung">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="checkscheduling"></a>7.23. <a name="checkscheduling-check_scheduling"></a>Service- und Host-Prüfungsplanung</h2></div></div></div>
<div class="toc"><dl>
<dt><span class="section">7.23.1. <a href="checkscheduling.html#introduction">Einführung</a></span></dt>
<dt><span class="section">7.23.2. <a href="checkscheduling.html#configurationoptions">Konfigurationsoptionen</a></span></dt>
<dt><span class="section">7.23.3. <a href="checkscheduling.html#initialscheduling">Initiale Planung</a></span></dt>
<dt><span class="section">7.23.4. <a href="checkscheduling.html#serviceintercheckdelay">Inter-Check-Verzögerung (inter-check delay)</a></span></dt>
<dt><span class="section">7.23.5. <a href="checkscheduling.html#serviceinterleaving">Service-Verschachtelung (service interleaving)</a></span></dt>
<dt><span class="section">7.23.6. <a href="checkscheduling.html#maxconcurrentchecks">Maximale Zahl gleichzeitiger Service-Prüfungen</a></span></dt>
<dt><span class="section">7.23.7. <a href="checkscheduling.html#timerestraints">Zeitbeschränkungen</a></span></dt>
<dt><span class="section">7.23.8. <a href="checkscheduling.html#normalscheduling">Normale Planung</a></span></dt>
<dt><span class="section">7.23.9. <a href="checkscheduling.html#problemscheduling">Planung bei Problemen</a></span></dt>
<dt><span class="section">7.23.10. <a href="checkscheduling.html#hostcheckscheduling">Host-Prüfungen</a></span></dt>
<dt><span class="section">7.23.11. <a href="checkscheduling.html#schedulingdelays">Planungsverzögerungen</a></span></dt>
<dt><span class="section">7.23.12. <a href="checkscheduling.html#schedulingexample">Planungsbeispiel</a></span></dt>
<dt><span class="section">7.23.13. <a href="checkscheduling.html#serviceoptions">Service-Definitionsoptionen, die die Planung beeinflussen</a></span></dt>
<dt><span class="section">7.23.14. <a href="checkscheduling.html#todo">TODO</a></span></dt>
</dl></div>
<a class="indexterm" name="idm139734665059072"></a>
<div class="section" title="7.23.1. Einführung">
<div class="titlepage"><div><div><h3 class="title">
<a name="introduction"></a>7.23.1. Einführung</h3></div></div></div>
<p>Es gab eine Menge Fragen dazu, wie Service-Prüfungen in bestimmten Situationen geplant werden, außerdem wie sich Planung und
eigentliche Ausführung unterscheiden und wie die Ergebnisse verarbeitet werden. Wir werden versuchen, ein bisschen mehr ins Detail zu
gehen, wie dies alles funktioniert...</p>
</div>
<div class="section" title="7.23.2. Konfigurationsoptionen">
<div class="titlepage"><div><div><h3 class="title">
<a name="configurationoptions"></a>7.23.2. Konfigurationsoptionen</h3></div></div></div>
<p>Es gibt es verschiedene Konfigurationsoptionen, die beeinflussen, wie Service-Prüfungen geplant, ausgeführt und verarbeitet
werden. Als Anfang enthält jede <a class="link" href="objectdefinitions.html#objectdefinitions-service">Service-Definition</a> drei Optionen, die festlegen, wann
und wie jede einzelne Service-Prüfung geplant und ausgeführt wird Diese drei Optionen sind:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p><span class="emphasis"><em>check_interval</em></span></p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>retry_interval</em></span></p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>check_period</em></span></p>
</li>
</ul></div>
<p>Es gibt außerdem vier Konfigurationsoptionen in der <a class="link" href="configmain.html" title="3.2. Optionen der Hauptkonfigurationsdatei">Hauptkonfigurationsdatei</a>, die
Service-Prüfungen beeinflussen. Dies sind:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p><a class="link" href="configmain.html#configmain-service_inter_check_delay_method"> <span class="emphasis"><em>service_inter_check_delay_method</em></span>
</a></p>
</li>
<li class="listitem">
<p><a class="link" href="configmain.html#configmain-service_interleave_factor"> <span class="emphasis"><em>service_interleave_factor</em></span> </a></p>
</li>
<li class="listitem">
<p><a class="link" href="configmain.html#configmain-max_concurrent_checks"> <span class="emphasis"><em>max_concurrent_checks</em></span> </a></p>
</li>
<li class="listitem">
<p><a class="link" href="configmain.html#configmain-check_result_reaper_frequency"> <span class="emphasis"><em>check_result_reaper_frequency</em></span> </a></p>
</li>
</ul></div>
<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>Die letzte Direktive betrifft auch Host-Prüfungen.</p>
</td></tr>
</table></div>
<p>Wir werden nun mehr ins Detail gehen, wie all diese Optionen die Service-Prüfungsplaung beeinflussen. Lassen Sie uns zuerst
betrachten, wie Services beim ersten (Neu-)Start von Icinga eingeplant werden...</p>
<a class="indexterm" name="idm139734665038768"></a>
</div>
<div class="section" title="7.23.3. Initiale Planung">
<div class="titlepage"><div><div><h3 class="title">
<a name="initialscheduling"></a>7.23.3. Initiale Planung</h3></div></div></div>
<p>Wenn Icinga (neu) startet, wird es versuchen, die initialen Prüfungen aller Services in einer Art und Weise so zu planen,
dass die Load auf dem lokalen und den entfernten Hosts mimimiert wird. Dies wird durch die Verteilung und das Verschachteln der Services
erreicht. Die Verteilung von Service-Prüfungen (auch als inter-check-delay bekannt) wird benutzt, um die Last des lokalen
Icinga-Servers zu minimieren/auszugleichen und die Verschachtelung wird benutzt, um die Last auf entfernten Hosts zu
minimieren/auszugleichen. Sowohl inter-check-relay als auch Verschachtelungsfunktion werden nachfolgend erläutert.</p>
<p>Selbst wenn die Service-Prüfungen initial geplant werden, um die Last auf lokalen und entfernten Hosts auszubalancieren, werden
die Dinge dem eintretenden Chaos nachgeben und ein wenig zufällig werden. Gründe dafür sind u.a., dass Services nicht alle mit dem
gleichen Intervall geprüft werden, dass die Ausführung einiger Services länger dauert als andere, dass Host- und/oder Service-Probleme
das Timing von ein oder mehreren Services verändern können, etc. Wenigstens versuchen wir, die Dinge gut zu beginnen. Hoffentlich hält
die initiale Planung die Last auf dem lokalen und den entfernten Hosts im Laufe der Zeit relativ ausgeglichen...</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>Wenn Sie die initiale Service-Prüfungs-Planungsinformationen ansehen möchten, dann starten Sie Icinga mit der <span class="bold"><strong>-s</strong></span> Kommandozeilenoption. Dabei werden Ihnen grundlegende Planungsinformationen (inter-check-Verzögerung,
Verschachtelungsfaktor, erste und letzte Service-Prüfzeit, etc., angezeigt) und es wird ein neues Status-Log angezeigt, das die
genauen Zeiten darstellt, zu denen alle Services initial eingeplant werden. Weil diese Option das Status-Log überschreibt, sollte Sie
sie nicht nutzen, solange eine weitere Icinga-Instanz läuft. Icinga wird <span class="emphasis"><em>nicht</em></span> die Überwachung
starten, wenn diese Option benutzt wird.</p>
</td></tr>
</table></div>
<a class="indexterm" name="idm139734665031184"></a>
</div>
<div class="section" title="7.23.4. Inter-Check-Verzögerung (inter-check delay)">
<div class="titlepage"><div><div><h3 class="title">
<a name="serviceintercheckdelay"></a>7.23.4. Inter-Check-Verzögerung (inter-check delay)</h3></div></div></div>
<p>Wie bereits erwähnt, versucht Icinga die Last auf dem Rechner, auf dem Icinga läuft, auszugleichen, indem die
Service-Prüfungen verteilt werden. Der Abstand zwischen aufeinander folgenden Service-Prüfungen wird "inter-check delay" genannt. Durch
die Angabe eines Werts für die Variable <a class="link" href="configmain.html#configmain-service_inter_check_delay_method">service_inter_check_delay_method</a> in der Hauptkonfigurationsdatei können Sie
festlegen, wie diese Verzögerung berechnet wird. Wir werden erläutern, wie die "schlaue" Berechnung arbeitet, weil dies die Einstellung
ist, die Sie für die normale Verarbeitung benutzen sollten.</p>
<p>Wenn Sie die Einstellung "smart" bei der Variable <span class="emphasis"><em>service_inter_check_delay_method</em></span> angeben, wird
Icinga den Wert für die inter-check-Verzögerung wie folgt berechnen:</p>
<p><span class="emphasis"><em>inter-check-Verzögerung = (durchschnittl. Check-Intervall für alle Services) / (Gesamtzahl der
Services)</em></span></p>
<p>Nehmen wir ein Beispiel. Sagen wir, Sie haben 1.000 Services mit einem normalen Prüfintervall von fünf Minuten (natürlich werden
einige Services mit anderen Intervallen geprüft, aber wir vereinfachen an dieser Stelle...). Die gesamte Check-Intervall-Zeit ist 5.000
(1.000 * 5). Das bedeutet, dass das durchschnittliche Check-Intervall für jeden Service fünf Minuten ist (5.000 / 1.000). Aufgrund
dieser Information wissen wir, dass wir (im Durchschnitt) 1.000 Prüfungen pro fünf Minuten benötigen. Das heißt, dass wir eine
inter-check-Verzögerung von 0,005 Minuten (5 / 1000, also etwa 0,3 Sekunden) benutzen sollten, wenn die Services das erste Mal verteilt
werden. Durch die Verteilung alle 0,3 Sekunden können wir erreichen, dass Icinga jede Sekunde drei Service-Prüfungen einplant
und/oder ausführt. Durch die gleichmäßige Aufteilung über die Zeit können wir hoffen, dass die Last auf dem lokalen Rechner, auf dem
Icinga läuft, in etwa gleich bleibt.</p>
<a class="indexterm" name="idm139734665023632"></a>
</div>
<div class="section" title="7.23.5. Service-Verschachtelung (service interleaving)">
<div class="titlepage"><div><div><h3 class="title">
<a name="serviceinterleaving"></a>7.23.5. Service-Verschachtelung (service interleaving)</h3></div></div></div>
<p>Wie oben erläutert hilft die inter-check-Verzögerung dabei, die Last auf dem lokalen Host auszugleichen. Was ist aber mit
entfernten Hosts? Ist es notwendig, die Last auf entfernten Hosts auszugleichen? Warum? Ja, es ist wichtig, und ja, Icinga kann
dabei helfen. Wenn Sie eine große Zahl von Services auf einem entfernten Host überwachen und die Prüfungen nicht verteilt wären, dann
könnte der entfernte Host denken, dass er das Opfer einer SYN-Attacke wurde, wenn es viele offene Verbindungen auf dem gleichen Port
gibt. Außerdem ist es nett, wenn man versucht, die Last auf den Hosts auszugleichen/zu minimieren...</p>
<p>Durch die Angabe eines Werts für die Variable <a class="link" href="configmain.html#configmain-service_interleave_factor">service_interleave_factor</a> in der Hauptkonfigurationsdatei können beeinflussen, wie
dieser Faktor berechnet wird. Wir werden erläutern, wie die "schlaue" Berechnung arbeitet, weil dies die Einstellung ist, die Sie for
die normale Verarbeitung nutzen sollten. Sie können, natürlich, einen Wert vorgeben, anstatt ihn von Icinga berechnen zu lassen.
Außerdem ist zu beachten, dass die Verschachtelung bei einem Wert von 1 praktisch deaktiviert ist.</p>
<p>Wenn Sie die Einstellung "smart" bei der Variable <span class="emphasis"><em>service_interleave_factor</em></span> angeben, wird Icinga den
Wert für den Verschachtelungsfaktor wie folgt berechnen:</p>
<p><span class="emphasis"><em>interleave factor = ceil ( Gesamtzahl der Services / Gesamtzahl der Hosts )</em></span></p>
<p>Nehmen wir ein Beispiel. Sagen wir, Sie haben insgesamt 1.000 Services und 150 Hosts, die Sie überwachen. Icinga würde
einen Verschachtelungsfaktor von 7 berechnen (1000 / 150 = 6,6; aufgerundet 7). Das bedeutet, dass Icinga bei der initialen
Planung die erste Service-Prüfung einplant, die es findet, dann die nächsten sechs überspringt, den nächsten einplant, usw... Dieser
Prozess wird wiederholt, bis alles Service-Prüfungen eingeplant sind. Weil die Services nach dem Namen des Hosts sortiert sind (und
damit eingeplant werden), mit dem sie verbunden sind, wird dies helfen, die Last auf entfernten Hosts zu
minimieren/auszugleichen.</p>
<p>Die folgenden Bilder zeigen, wie Service-Prüfungen eingeplant werden, wenn sie nicht verschachtelt werden
(<span class="emphasis"><em>service_interleave_factor</em></span>=1) und wenn sie mit einem Wert von 4 für <span class="emphasis"><em>service_interleave_factor</em></span>
verschachtelt werden.</p>
<div class="informaltable">
<table border="0">
<colgroup>
<col>
<col>
</colgroup>
<tbody>
<tr>
<td><p>nicht verschachtelte Prüfungen</p></td>
<td><p>verschachtelte Prüfungen</p></td>
</tr>
<tr>
<td align="left" valign="middle"><p> <span class="inlinemediaobject"><img src="../images/noninterleaved1.png" width="500"></span> </p></td>
<td align="left" valign="middle"><p> <span class="inlinemediaobject"><img src="../images/interleaved1.png" width="500"></span> </p></td>
</tr>
<tr>
<td align="left" valign="middle"><p> <span class="inlinemediaobject"><img src="../images/noninterleaved2.png" width="500"></span> </p></td>
<td align="left" valign="middle"><p> <span class="inlinemediaobject"><img src="../images/interleaved2.png" width="500"></span> </p></td>
</tr>
<tr>
<td> </td>
<td align="left" valign="middle"><p> <span class="inlinemediaobject"><img src="../images/interleaved3.png" width="500"></span> </p></td>
</tr>
</tbody>
</table>
</div>
<a class="indexterm" name="idm139734664990944"></a>
</div>
<div class="section" title="7.23.6. Maximale Zahl gleichzeitiger Service-Prüfungen">
<div class="titlepage"><div><div><h3 class="title">
<a name="maxconcurrentchecks"></a>7.23.6. Maximale Zahl gleichzeitiger Service-Prüfungen</h3></div></div></div>
<p>Um Icinga davon abzuhalten, all Ihre CPU-Ressourcen zu verbrauchen, können Sie die maximale Zahl von gleichzeitigen
Service-Prüfungen beschränken, die zu einer beliebigen Zeit laufen können. Dies wird durch die Option <a class="link" href="configmain.html#configmain-max_concurrent_checks">max_concurrent_checks</a> in der Hauptkonfigurationsdatei festgelegt.</p>
<p>Gut daran ist, dass Sie mit dieser Einstellung Icingas CPU-Nutzung beeinflussen können. Schlecht ist, dass
Service-Prüfungen ins Hintertreffen geraten können, wenn dieser Wert zu niedrig eingestellt ist. Wenn es Zeit wird, eine Service-Prüfung
auszuführen, wird Icinga sicherstellen, dass nicht mehr als x Service-Prüfungen ausgeführt werden bzw. darauf warten, dass die
Prüfergebnisse verarbeitet werden (wobei x die Anzahl der Prüfungen ist, die Sie über die Option
<span class="emphasis"><em>max_concurrent_checks</em></span> angegeben haben). Falls diese Grenze erreicht ist, wird Icinga die Ausführung von
anstehenden Prüfungen aufschieben, bis einige der vorherigen Prüfungen beendet sind. Also wie kann man einen geeigneten Wert für die
Option <span class="emphasis"><em>max_concurrent_checks</em></span> festlegen?</p>
<p>Zuerst müssen Sie einige Dinge wissen...</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>die inter-check-Verzögerung, die Icinga benutzt, um die initialen Service-Prüfungen einzuplanen (nutzen Sie die Option
<span class="bold"><strong>-s</strong></span>, um den Wert zu kontrollieren)</p>
</li>
<li class="listitem">
<p>die Häufigkeit (in Sekunden) von "reaper events", wie sie in der <a class="link" href="configmain.html#configmain-check_result_reaper_frequency">check_result_reaper_frequency</a>-Variable in der Hauptkonfigurationsdatei
angegeben ist</p>
</li>
<li class="listitem">
<p>eine Vorstellung der durchschnittlichen Zeit, die Service-Prüfungen wirklich zur Ausführung benötigen (die meisten Plugins
haben einen Timeout von 10 Sekunden, so dass der Durchschnitt wahrscheinlich niedriger liegt)</p>
</li>
</ul></div>
<p>Dann benutzen Sie die folgende Berechnung, um einen geeigneten Wert für die maximale Zahl von gleichzeitig erlaubten Prüfungen zu
errechnen...</p>
<p><span class="emphasis"><em>max. Anzahl gleichzeitiger Prüfungen = ceil( max( check result reaper frequency , average check execution time ) /
inter-check delay )</em></span></p>
<p>Die errechnete Zahl sollte einen guten Ausgangspunkt für die <span class="emphasis"><em>max_concurrent_checks</em></span>-Variable bieten. Es kann
sein, dass Sie diesen Wert noch ein wenig erhöhen müssen, falls Service-Prüfungen nach wie vor nicht zur geplanten Zeit ausgeführt
werden oder verringern Sie, falls Icinga zu viel CPU-Zeit beansprucht.</p>
<p>Nehmen wir an, dass Sie 875 Services, jeder mit einem durchschnittlichen Intervall von zwei Minuten. Das bedeutet, dass die
inter-check-Verzögerung etwa 0,137 Sekunden ist. Wenn Sie die "check result reaper frequency" auf zehn Sekunden einstellen, können Sie
einen ungefähren Wert für die maximale Zahl von gleichzeitigen Prüfungen wie folgt berechnen (wir nehmen an, dass die durchschnittliche
Ausführungszeit für Service-Prüfungen kleiner als zehn Sekunden ist) ...</p>
<p><span class="emphasis"><em>max. Zahl gleichzeitiger Prüfungen = ceil( 10 / 0.137 )</em></span></p>
<p>In diesem Fall ist der berechnete Wert 73. Das ergibt Sinn, denn Icinga wird etwas mehr als sieben neue Service-Prüfungen
pro Sekunde ausführen und es wird Service-Prüfergebnisse nur alle zehn Sekunden verarbeiten. Das bedeutet, dass es zu einer beliebigen
Zeit nur etwas mehr als 70 Service-Prüfungen gibt, die ausgeführt werden bzw. deren Ergebnisse verarbeitet werden. In diesem Fall würden
wir wahrscheinlich empfehlen, den Wert für die Zahl der gleichzeitigen Prüfungen auf 80 zu erhöhen, weil es Verzögerungen gibt, wenn
Icinga Service-Prüfergebnisse verarbeitet bzw. andere Dinge tut. Sie werden offensichtlich ein wenig testen und verändern müssen,
damit alles reibungslos funktioniert, aber mit diesen Informationen sollten Sie ein paar generelle Richtlinien an der Hand
haben...</p>
<a class="indexterm" name="idm139734664974528"></a>
</div>
<div class="section" title="7.23.7. Zeitbeschränkungen">
<div class="titlepage"><div><div><h3 class="title">
<a name="timerestraints"></a>7.23.7. Zeitbeschränkungen</h3></div></div></div>
<p>Die Option <span class="emphasis"><em>check_period</em></span> legt den <a class="link" href="timeperiods.html" title="5.9. Zeitfenster">Zeitraum</a> fest, in dem Icinga
Service-Prüfungen ausführen kann. Falls die Zeit, zu der eine Prüfung für einen bestimmten Service ausgeführt werden werden soll, nicht
innerhalb des angegebenen Zeitraum liegt, wird die Prüfung <span class="emphasis"><em>nicht</em></span> ausgeführt, und zwar unabhängig vom Status des
Service. Statt dessen wird Icinga die Service-Prüfung für die nächste gültige Zeit des Zeitraums einplanen. Wenn die Prüfung
gestartet werden kann (d.h. die Zeit ist gültig innerhalb des Zeitraums), wird die Service-Prüfung ausgeführt.</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>Auch wenn eine Service-Prüfung nicht zu einer bestimmten Zeit ausgeführt werden kann, könnte Icinga sie trotzdem
<span class="emphasis"><em>einplanen</em></span>. Das wird höchstwahrscheinlich während der initialen Planung von Services passieren, aber es kann auch
in anderen Fällen passieren. Das bedeutet nicht, dass Icinga die Prüfung ausführen wird. Wenn es Zeit wird, die Prüfung
tatsächlich <span class="emphasis"><em>auszuführen</em></span>, wird Icinga kontrollieren, ob die Prüfung zur angegeben Zeit gestartet werden
kann. Falls nicht, wird Icinga die Service-Prüfung nicht ausführen, sondern sie zu einer späteren Zeit einplanen. Lassen Sie
sich nicht verwirren! Die Planung und Ausführunge von Service-Prüfungen sind zwei unterschiedliche (wenn auch, zusammenhängende)
Dinge.</p>
</td></tr>
</table></div>
<a class="indexterm" name="idm139734664966480"></a>
</div>
<div class="section" title="7.23.8. Normale Planung">
<div class="titlepage"><div><div><h3 class="title">
<a name="normalscheduling"></a>7.23.8. Normale Planung</h3></div></div></div>
<p>In einer idealen Welt hätten Sie keine Netzwerkprobleme. Aber wenn das so wäre, dann hätten Sie auch kein
Netzwerküberwachungsprogramm. Wie auch immer, wenn die Dinge reibungslos laufen und ein Service in einem OK-Zustand ist, nennen wir das
"normal". Service-Prüfungen werden normalerweise in der Häufigkeit geplant, die in der Option <span class="emphasis"><em>check_interval</em></span>
angegeben ist. Das war's. Einfach, oder?</p>
<a class="indexterm" name="idm139734664962512"></a>
</div>
<div class="section" title="7.23.9. Planung bei Problemen">
<div class="titlepage"><div><div><h3 class="title">
<a name="problemscheduling"></a>7.23.9. Planung bei Problemen</h3></div></div></div>
<p>Also, was passiert, wenn es Probleme mit einem Service gibt? Nun, eins der Dinge ist, dass sich die Service-Prüfungsplanung
ändert. Wenn Sie die Option <span class="emphasis"><em>max_attempts</em></span> auf einen Wert größer als eins gesetzt haben, wird Icinga die
Prüfung erneut einplanen, bevor es entscheidet, dass ein wirkliches Problem existiert. Während der Service erneut geprüft wird (bis zu
<span class="emphasis"><em>max_attempts</em></span> Mal), wird er als in einem "soft"-Status befindlich angesehen (wie <a class="link" href="statetypes.html" title="5.8. Statustypen">hier</a> beschrieben) und die Service-Prüfungen werden mit einer Häufigkeit eingeplant, die in der Option
<span class="emphasis"><em>retry_interval</em></span> angegeben ist.</p>
<p>Wenn Icinga den Service <span class="emphasis"><em>max_attempts</em></span> Mal erneut eingeplant hat und er immer noch in einem nicht-OK
Status ist, wird Icinga den Service in einen "Hard"-Status versetzen, Benachrichtigungen an Kontakte versenden (falls zutreffend)
und weitere Prüfungen des Service wieder mit der Häufigkeit planen, die in der Option <span class="emphasis"><em>check_interval</em></span> festgelegt
ist.</p>
<p>Wie immer gibt es Ausnahmen der Regel. Wenn eine Service-Prüfung zu einem nicht-OK-Status führt, wird Icinga den mit diesem
Service verbundenen Host prüfen, um festzustellen, ob er "up" ist oder nicht (siehe die Anmerkung <a class="link" href="checkscheduling.html#hostcheckscheduling" title="7.23.10. Host-Prüfungen">unten</a> zu Informationen, wie dies passiert). Wenn der Host nicht "up" ist (also "down" oder
"unreachable"), wird Icinga den Service sofort in einen harten nicht-OK-Status versetzen und die Zahl der aktuellen Versuche auf
1 zurücksetzen. Da der Service in einem harten nicht-OK-Status ist, wird die Service-Prüfung mit der normalen Häufigkeit geplant, die in
der Option <span class="emphasis"><em>check_interval</em></span> angegeben ist, statt des Wertes aus der Option
<span class="emphasis"><em>retry_interval</em></span>.</p>
<a class="indexterm" name="idm139734664952176"></a>
</div>
<div class="section" title="7.23.10. Host-Prüfungen">
<div class="titlepage"><div><div><h3 class="title">
<a name="hostcheckscheduling"></a>7.23.10. Host-Prüfungen</h3></div></div></div>
<p>Ein Fall, wo Icinga den Status eines Hosts prüft, ist, wenn ein Service-Prüfung einen nicht-OK-Zustand ergibt.
Icinga prüft den Host, um zu entscheiden, ob der Host "up" ist oder nicht, bzw. ob der Host "up", "down" oder "unreachable" ist.
Wenn die erste Host-Prüfung einen nicht-OK-Zustand ergibt, wird Icinga Host-Prüfungen wie bei den Services durchführen.</p>
<a class="indexterm" name="idm139734664948544"></a>
</div>
<div class="section" title="7.23.11. Planungsverzögerungen">
<div class="titlepage"><div><div><h3 class="title">
<a name="schedulingdelays"></a>7.23.11. Planungsverzögerungen</h3></div></div></div>
<p>Es sollte erwähnt werden, dass Service-Prüfungsplanung und -ausführung geschieht, so gut es geht. Individuelle Service-Prüfungen
werden inIcinga als Ereignisse mit niedriger Priorität angesehen, so dass sie verzögert werden können, wenn Ereignisse mit
höherer Priorität ausgeführt werden müssen. Beispiel von Ereignissen mit hoher Priorität umfassen Log-Datei-Rotationen, externe
Befehlsprüfungen und Prüfergebnis-Ernteereignisse.</p>
<a class="indexterm" name="idm139734664946640"></a>
</div>
<div class="section" title="7.23.12. Planungsbeispiel">
<div class="titlepage"><div><div><h3 class="title">
<a name="schedulingexample"></a>7.23.12. Planungsbeispiel</h3></div></div></div>
<p>Die Planung von Service-Prüfungen, ihre Ausführung und die Verarbeitung ihrer Ergebnisse können ein bisschen schwierig zu
verstehen sein, deshalb schauen wir uns ein einfaches Beispiel an. Betrachten wir das folgende Diagramm - wir werden uns darauf
beziehen, während wir die Dinge erklären.</p>
<p><span class="inlinemediaobject"><img src="../images/checktiming.png"></span></p>
<p>Zuallererst sind <span class="bold"><strong>X</strong></span><sub>n</sub> Prüfergebnis-Ernteereignisse, die in der Häufigkeit
geplant werden, die durch die Option <a class="link" href="configmain.html#configmain-check_result_reaper_frequency">check_result_reaper_frequency</a> in
der Hauptkonfigurationsdatei angegeben ist. Prüfergebnis-Ernteereignisse übernehmen die Arbeit, Service-Prüfergebnisse zu sammeln und zu
verarbeiten. SIe dienen als die Kernlogik für Icinga, starten Host-Prüfungen, Ereignisbehandlung-Routinen und Benachrichtigungen,
wenn das notwendig ist.</p>
<p>Für das Beispiel hier ist die Ausführung eines Service für den Zeitpunkt <span class="bold"><strong>A </strong></span>geplant. Allerdings
kam Icinga in der Ereigniswarteschlange ins Hintertreffen, so dass die Prüfung erst zum Zeitpunkt <span class="bold"><strong>B</strong></span> ausgeführt wird. Die Service-Prüfung endet zum Zeitpunkt <span class="bold"><strong>C</strong></span>, so dass die
Differenz zwischen den Punkten <span class="bold"><strong>C</strong></span> and <span class="bold"><strong>B</strong></span> die Laufzeit der Prüfung
ist.</p>
<p>Die Ergebnisse der Service-Prüfungen werden nicht sofort nach der Prüfung verarbeitet. Statt dessen werden die Ergebnisse für eine
spätere Verarbeitung durch einen Prüfergebnis-Ernteereignis gespeichert. Das nächste Prüfergebnis-Ernteereignis findet zum Zeitpunkt
<span class="bold"><strong>D</strong></span> statt, so dass dies ungefähr die Zeit ist, zu der die Ergebnisse verarbeitet werden (die tatsächliche
Zeit kann später als <span class="bold"><strong>D</strong></span> sein, weil ggf. andere Service-Prüfergebnisse vor diesem Service verarbeitet
werden).</p>
<p>Zu der Zeit, zu der das Prüfergebnis-Ernteereignis die Service-Prüfergebnisse verarbeitet, wird es die nächste Service-Prüfung
einplanen und in Icingas Ereigniswarteschlange stellen. Wir nehmen an, dass die Service-Prüfung einen OK-Zustand ergibt, so dass
die nächste Prüfung zum Zeitpunkt <span class="bold"><strong>E</strong></span> nach der ursprünglich geplanten Prüfzeit geplant wird, mit einem
zeitlichen Abstand, der in der <span class="emphasis"><em>check_interval</em></span>-Option angegeben ist. Beachten Sie, dass der Service
<span class="emphasis"><em>nicht</em></span> erneut eingeplant wird basierend auf der Zeit, zu der er tatsächlich ausgeführt wird! Es gibt eine Ausnahme
(es gibt immer eine, oder?) - falls die Zeit, zu der die Service-Prüfung tatsächlich ausgeführt wird (Punkt <span class="bold"><strong>B</strong></span>) nach der nächsten Service-Prüfzeit liegt (Punkt <span class="bold"><strong>E</strong></span>), wird Icinga das
durch das Anpassen der nächsten Prüfzeit ausgleichen. Das wird gemacht, damit Icinga nicht verrückt wird beim Versuch, mit den
Service-Prüfungen Schritt zu halten, wenn eine hohe Last auftritt. Außerdem, wie sinnvoll ist es, etwas in der Vergangenheit zu
planen...?</p>
<a class="indexterm" name="idm139734664925680"></a>
</div>
<div class="section" title="7.23.13. Service-Definitionsoptionen, die die Planung beeinflussen">
<div class="titlepage"><div><div><h3 class="title">
<a name="serviceoptions"></a>7.23.13. Service-Definitionsoptionen, die die Planung beeinflussen</h3></div></div></div>
<p>Jede Service-Definition enthält eine <span class="emphasis"><em>check_interval</em></span>- und eine <span class="emphasis"><em>retry_interval</em></span>-Option.
Hoffentlich klärt das Folgende, was diese zwei Optionen tun, wie sie mit der <span class="emphasis"><em>max_check_attempts</em></span>-Option in der
Service-Definition zusammenwirken, und wie sie die Planung des Service beeinflussen.</p>
<p>Zuallererst gibt die <span class="emphasis"><em>check_interval</em></span>-Option das Intervall an, in dem der Service unter "normalen" Umständen
geprüft wird. "Normale" Umstände bedeutet, wenn sich der Service in einem "OK"- oder einem <a class="link" href="statetypes.html" title="5.8. Statustypen">harten</a>
nicht-OK-Zustand befindet.</p>
<p>Wenn ein Service das erste Mal von einem OK- in einen nicht-OK-Zustand wechselt, gibt Ihnen Icinga die Möglichkeit, das
Intervall temporär zu verkleinern oder zu vergrößern, in dem nachfolgende Prüfungen für diesen Service ausgeführt werden. Wenn der
Service-Zustand das erste Mal wechselt, wird Icinga bis zu <span class="emphasis"><em>max_check_attempts</em></span>-1 Versuche durchführen, bevor
es entscheidet, dass es sich um ein richtiges Problem handelt. Während die Prüfungen wiederholt werden, werden sie gemäß der
<span class="emphasis"><em>retry_interval</em></span>-Option neu eingeplant, was schneller oder langsam als die <span class="emphasis"><em>check_interval</em></span>-Option
ist. Während der Service erneut geprüft wird (bis zu <span class="emphasis"><em>max_check_attempts</em></span>-1 mal), ist der Service in einem <a class="link" href="statetypes.html" title="5.8. Statustypen">soft-Zustand</a>. Wenn der Service <span class="emphasis"><em>max_check_attempts</em></span>-1 mal geprüft wurde und sich immer
noch in einem nicht-OK-Zustand befindet, wird der Service in einen <a class="link" href="statetypes.html" title="5.8. Statustypen">hard-Zustand</a> wechseln und wird
nachfolgend wieder mit der normalen Rate eingeplant, die in der <span class="emphasis"><em>check_interval</em></span>-Option festgelegt ist.</p>
<p>Als Randbemerkung, wenn Sie einen Wert von 1 für die <span class="emphasis"><em>max_check_attempts</em></span>-Option definieren, wird der Service
niemals mit dem Intervall geprüft, das in der <span class="emphasis"><em>retry_interval</em></span>-Option angegeben ist. Statt dessen wird er sofort in
einen <a class="link" href="statetypes.html" title="5.8. Statustypen">hard-Zustand</a> wechseln und anschließend mit dem in der Option <span class="emphasis"><em>check_interval</em></span>
festgelegten Intervall geprüft.</p>
<a class="indexterm" name="idm139734664910800"></a>
</div>
<div class="section" title="7.23.14. TODO">
<div class="titlepage"><div><div><h3 class="title">
<a name="todo"></a>7.23.14. TODO</h3></div></div></div>
<p><span class="bold"><strong><a name="hostintercheckdelay"></a>Host-Prüfungs-Direktiven</strong></span></p>
<p>Die meisten der o.g. Informationen treffen auch auf Host-Prüfungen zu.</p>
<p>Dieser Abschnitt wird aktualisiert. Voraussichtlich gibt es mehr Informationen in einer der nächsten Ausgaben...</p>
<a class="indexterm" name="idm139734664905616"></a>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="passivestatetranslation.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="cgiincludes.html">Weiter</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">7.22. Passive Host-Zustandsübersetzung </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td>
<td width="40%" align="right" valign="top"> 7.24. Angepasste Classic UI-Modul-Kopf- und Fußzeilen</td>
</tr>
</table>
</div>
<P class="copyright">© 1999-2009 Ethan Galstad, 2009-2017 Icinga Development Team, https://www.icinga.com</P>
</body>
</html>
|
