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
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Erkennung und Behandlung von Status-Flattern</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="redundancy.html" title="Redundante und Failover-Netzwerk-Überwachung">
<link rel="next" href="escalations.html" title="Benachrichtigungseskalationen">
</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">Erkennung und Behandlung von Status-Flattern</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="redundancy.html">Zurück</a> </td>
<th width="60%" align="center">Kapitel 6. Fortgeschrittene Themen</th>
<td width="20%" align="right"> <a accesskey="n" href="escalations.html">Weiter</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="section" title="Erkennung und Behandlung von Status-Flattern">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="flapping"></a>Erkennung und Behandlung von Status-Flattern</h2></div></div></div>
<p><span class="bold"><strong>Einführung</strong></span></p>
<p>Icinga unterstützt die Erkennung von Hosts und Services, die "flattern". Flattern tritt auf, wenn Hosts oder
Services zu oft den Zustand wechseln und dadurch einen Sturm von Problemen und Erholungsbenachrichtigungen erzeugen. Flattern
kann auf Konfigurationsprobleme hinweisen (z.B. Schwellwerte, die zu niedrig gesetzt sind), störende Services oder wirkliche
Netzwerkprobleme.</p>
<p><span class="bold"><strong>Wie Flatter-Erkennung arbeitet</strong></span></p>
<p>Bevor wir darauf eingehen, lassen Sie uns sagen, dass es etwas schwierig war, Flatter-Erkennung zu implementieren. Wie
genau legt man fest, was "zu häufig" in Bezug auf Statusänderungen für einen Host oder Service ist? Als Ethan Galstad zuerst an
die Implementierung der Flatter-Erkennung gedacht hat, versuchte er Informationen zu finden, wie Flattern erkannt werden
könnte/sollte. Er konnte keinerlei Informationen darüber finden, was andere benutzten (benutzen andere so etwas?), also
entschied er sich für das, was er für eine sinnvolle Lösung hielt...</p>
<p>Sobald Icinga den Zustand eines Hosts oder Services prüft, wird es prüfen, ob dafür Flattern begonnen oder geendet
hat. Es tut dies durch:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>speichern der Ergebnisse der letzten 21 Prüfungen des Hosts oder Service</p>
</li>
<li class="listitem">
<p>analysieren der historischen Prüfergebnisse und feststellen, wo Statusänderungen/-übergänge auftreten</p>
</li>
<li class="listitem">
<p>benutzen der Statusübergänge, um einen Statuswechsel-Prozentsatz (ein Maß für die Änderung) für den Statuswechsel des
Hosts oder Service festzulegen</p>
</li>
<li class="listitem">
<p>vergleichen des Statuswechsel-Prozentwertes gegen die Flatter-Schwellwerte (hoch und niedrig)</p>
</li>
</ul></div>
<p>Ein Host oder Service wird angesehen, mit dem Flatter <span class="emphasis"><em>begonnen</em></span> zu haben, wenn der Prozentsatz das
erste Mal einen <span class="emphasis"><em>hohen</em></span> Flatter-Schwellwert überschritten hat.</p>
<p>Ein Host oder Service wird angesehen, das Flattern <span class="emphasis"><em>beendet</em></span> zu haben, wenn der Prozentsatz unter einen
<span class="emphasis"><em>niedrigen</em></span> Flatter-Schwellwert sinkt (vorausgesetzt, dass er vorher geflattert hat).</p>
<p><span class="bold"><strong>Beispiel</strong></span></p>
<p>Lassen Sie uns etwas detaillierter beschreiben, wie Flatter-Erkennung bei Services arbeitet...</p>
<p>Das Bild unten zeigt eine chronologische Historie von Service-Zuständen der letzten 21 Service-Prüfungen. OK-Zustände sind
in grün dargestellt, WARNING-Zustände in gelb, CRITICAL-Zustände in rot und UNKNOWN-Zustände in orange.</p>
<div class="mediaobject"><img src="../images/statetransitions.png"></div>
<p>Die historischen Service-Prüfergebnisse werden untersucht, um festzustellen, wo Statusänderungen/-übergänge auftreten.
Statusänderungen treten auf, wenn ein archivierter Status sich von den archivierten Zuständen unterscheidet, die ihm direkt
vorausgehen. Da wir die Ergebnisse der letzten 21 Status-Prüfungen in dem Array ablegen, können wir bis zu 20 Statusänderungen
haben. In diesem Beispiel gibt es sieben Statusänderungen, die im Bild durch blaue Pfeile gekennzeichnet sind.</p>
<p>Die Flatter-Erkennungslogik nutzt die Statusänderungen, um einen Gesamtprozentsatz für den Service festzulegen. Dies ist
ein Maßstab für die Sprunghaftigkeit/Änderung des Service. Services, die nie den Status wechseln, haben einen
Statusänderungswert von 0%, während Services, die ihren Status bei jeder Prüfung wechseln, einen Wert von 100% haben. Die
meisten Services werden einen Prozentwert irgendwo dazwischen haben.</p>
<p>Während der Berechnung des Prozentsatzes für den Service wird der Flatter-Erkennungsalgorithmus mehr Gewicht auf neuere
Statusänderungen legen als auf alte. Genauer gesagt sind die Flatter-Erkennungsroutinen im Moment so ausgelegt, dass der neueste
Statuswechsel 50% mehr Gewicht hat als der älteste. Das Bild unten zeigt, wie neuere Statuswechsel mehr Gewicht erhalten als
ältere, während der Gesamtprozentwert für einen bestimmten Service berechnet wird.</p>
<div class="mediaobject"><img src="../images/statetransitions2.png"></div>
<p>Lassen Sie uns mit dem obigen Bild eine Berechnung der prozentualen Statusänderungen für den Service durchführen. Sie
werden bemerken, dass es insgesamt sieben Statuswechsel gibt (bei t<sub>3</sub>, t<sub>4</sub>,
t<sub>5</sub>, t<sub>9</sub>, t<sub>12</sub>, t<sub>16</sub> und
t<sub>19</sub>). Ohne Gewichtung der Statuswechsel über die Zeit würde dies einen Gesamtwert von 35% ergeben:</p>
<p>(7 beobachtete Statuswechsel / 20 mögliche Statuswechsel) * 100 = 35 %</p>
<p>Nachdem die Flatter-Erkennungslogik neueren Statuswechseln mehr Gewicht gibt als älteren, wird der eigentliche Wert in
diesem Beispiel geringfügig kleiner sein als 35%. Lassen Sie uns annehmen, dass der gewichtete Prozentwert 31% ist...</p>
<p>Der errechnete Prozentwert für den Service (31%) wird dann gegen die Flatter-Schwellwerte verglichen, um zu sehen, was
passiert:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>wenn der Service bisher <span class="emphasis"><em>nicht</em></span> flatterte und 31% <span class="emphasis"><em>gleich oder größer</em></span> als der
hohe Flatter-Schwellwert ist, nimmt Icinga an, dass der Service gerade angefangen hat zu flattern.</p>
</li>
<li class="listitem">
<p>wenn der Service <span class="emphasis"><em>bereits</em></span> flatterte und 31% <span class="emphasis"><em>unter</em></span> dem niedrigen
Flatter-Schwellwert liegt, nimmt Icinga an, dass der Service gerade aufgehört hat zu flattern.</p>
</li>
</ul></div>
<p>wenn keine der beiden Bedingungen zutrifft, dann macht die Flatter-Erkennungslogik nichts weiteres mit dem Service, da er
entweder (noch) nicht flattert oder bereits flattert.</p>
<p><span class="bold"><strong>Flatter-Erkennung für Services</strong></span></p>
<p>Icinga prüft jedes Mal, wenn der Service geprüft wird (egal ob aktiv oder passiv), ob ein Service flattert.</p>
<p>Die Flatter-Erkennungslogik für Services arbeitet wie in dem obigen Beispiel beschrieben.</p>
<p><span class="bold"><strong>Flatter-Erkennung für Hosts</strong></span></p>
<p>Host-Flatter-Erkennung arbeitet in einer ähnlichen Weise wie die Service-Flatter-Erkennung, mit einem wichtigen
Unterschied: Icinga wird versuchen zu prüfen, ob ein Host flattert, wenn:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>der Host geprüft wird (aktiv oder passiv)</p>
</li>
<li class="listitem">
<p>manchmal, wenn ein Service geprüft wird, der mit dem Host verbunden ist. Genauer gesagt, wenn wenigstens
<span class="emphasis"><em>x</em></span> der Zeit vergangen ist, seit die letzte Flatter-Erkennung durchgeführt wurde, wobei
<span class="emphasis"><em>x</em></span> dem Durchschnittsintervall aller Services entspricht, die mit dem Host verbunden sind.</p>
</li>
</ul></div>
<p>Warum wird das gemacht? Bei Services wissen wir, dass die minimale Zeit zwischen zwei aufeinander folgenden
Flatter-Erkennungsroutinen gleich dem Service-Prüfintervall sein wird. Allerdings werden Sie Hosts wahrscheinlich nicht auf
einer regelmäßigen Basis überwachen, so dass es kein Prüfintervall gibt, das in der Flatter-Erkennungslogik benutzt werden kann.
Außerdem ist es sinnvoll, dass die Prüfung eines Service der Erkennung eines Host-Flatterns dienen sollte. Services sind
Attribute eines Hosts bzw. bezogen auf Dinge, die mit dem Host verbunden sind. Auf jeden Fall ist es die beste Methode, die
Ethan Galstad gefunden hat, um festzulegen, wie oft die Flatter-Erkennung auf einem Host ausgeführt werden kann.</p>
<p><span class="bold"><strong>Flatter-Erkennungsschwellwerte</strong></span></p>
<p>Icinga benutzt verschiedene Variablen, um die Schwellwert-Prozentsätze der Statusänderungen festzulegen, die es für
die Flatter-Erkennung nutzt. Für Hosts und Services gibt es hohe und niedrige <span class="emphasis"><em>globale</em></span> und
<span class="emphasis"><em>Host-</em></span> und <span class="emphasis"><em>Service-spezifische</em></span> Schwellwerte, die Sie konfigurieren können.
Icinga wird die globalen Schwellwerte für die Flatter-Erkennung nutzen, wenn Sie keine Host- oder Service-spezifischen
Schwellwerte angegeben haben.</p>
<p>Die Tabelle unten zeigt die globalen und die Host- oder Service-spezifischen Variablen, die die verschiedenen Schwellwerte
kontrollieren, die bei der Flatter-Erkennung benutzt werden.</p>
<div class="informaltable">
<table border="1">
<colgroup>
<col>
<col>
<col>
</colgroup>
<tbody>
<tr>
<td><p> <span class="bold"><strong>Objekt-Typ</strong></span> </p></td>
<td><p> <span class="bold"><strong>Globale Variable</strong></span> </p></td>
<td><p> <span class="bold"><strong>Objekt-spezifische Variablen</strong></span> </p></td>
</tr>
<tr>
<td><p>Host</p></td>
<td>
<p>
<a class="link" href="configmain.html#configmain-low_host_flap_threshold">low_host_flap_threshold</a>
</p> <p>
<a class="link" href="configmain.html#configmain-high_host_flap_threshold">high_host_flap_threshold</a>
</p>
</td>
<td>
<p>
<a class="link" href="objectdefinitions.html#objectdefinitions-host">low_flap_threshold</a>
</p> <p>
<a class="link" href="objectdefinitions.html#objectdefinitions-host">high_flap_threshold</a>
</p>
</td>
</tr>
<tr>
<td><p>Service</p></td>
<td>
<p>
<a class="link" href="configmain.html#configmain-low_service_flap_threshold">low_service_flap_threshold</a>
</p> <p>
<a class="link" href="configmain.html#configmain-high_service_flap_threshold">high_service_flap_threshold</a>
</p>
</td>
<td>
<p>
<a class="link" href="objectdefinitions.html#objectdefinitions-service">low_flap_threshold</a>
</p> <p>
<a class="link" href="objectdefinitions.html#objectdefinitions-service">high_flap_threshold</a>
</p>
</td>
</tr>
</tbody>
</table>
</div>
<p><span class="bold"><strong>Zustände, die für die Flatter-Erkennung benutzt werden</strong></span></p>
<p>Normalerweise wird Icinga die Ergebnisse der letzten 21 Präfungen eines Hosts oder Service verfolgen, unabhängig
vom Prüfergebnis (Host-/Service-Zustand), um sie für die Flatter-Erkennungslogik zu benutzen.</p>
<p><span class="inlinemediaobject"><img src="../images/tip.gif"></span> Hinweis: Sie können durch die <span class="emphasis"><em>flap_detection_options</em></span>-Direktive in Ihren Host- oder
Service-Definitonen verschiedene Host- oder Service-Zustände von der Nutzung in der Flatter-Erkennungslogik ausschließen. Diese
Direktive erlaubt Ihnen die Angabe, welche Host- oder Service-Zustände (z.B. "UP", "DOWN", "OK", "CRITICAL") Sie für die
Flatter-Erkennung benutzen wollen. Wenn Sie diese Direktive nicht nutzen wollen, werden alle Host- und Service-Zustände in der
Flatter-Erkennung benutzt.</p>
<p><span class="bold"><strong>Flatter-Behandlung</strong></span></p>
<p>Wenn bei einem Service- oder Host das erste Mal Flattern erkannt wird, wird Icinga:</p>
<div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem">
<p>eine Meldung protokollieren, dass der Service oder Host flattert</p>
</li>
<li class="listitem">
<p>einen nicht-permanenten Kommentar zum Host oder Service hinzufügen, dass er flattert</p>
</li>
<li class="listitem">
<p>eine "flapping start"-Benachrichtigung für den Host oder Service an die betreffenden Kontakte versenden</p>
</li>
<li class="listitem">
<p>andere Benachrichtigungen für den Service oder Host unterdrücken (das ist einer der Filter in der <a class="link" href="notifications.html" title="Benachrichtigungen">Benachrichtigungslogik</a>)</p>
</li>
</ol></div>
<p>Wenn ein Service oder Host aufhört zu flattern, wird Icinga:</p>
<div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem">
<p>eine Meldung protokollieren, dass der Service oder Host nicht mehr flattert</p>
</li>
<li class="listitem">
<p>den Kommentar löschen, der zum Service oder Host hinzugefügt wurde, als dieser anfing zu flattern</p>
</li>
<li class="listitem">
<p>eine "flapping stop"-Benachrichtigung für den Host oder Service an die betreffenden Kontakte versenden</p>
</li>
<li class="listitem">
<p>die Blockade von Benachrichtigungen für den Service oder Host entfernen (Benachrichtigungen sind nach wie vor an die
normale <a class="link" href="notifications.html" title="Benachrichtigungen">Benachrichtigungslogik</a> gebunden)</p>
</li>
</ol></div>
<p><span class="bold"><strong>Aktivieren der Flatter-Erkennung</strong></span></p>
<p>Um die Flatter-Erkennungsmöglichkeiten in Icinga zu aktivieren, müssen Sie folgendes tun:</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>setzen Sie die <a class="link" href="configmain.html#configmain-enable_flap_detection">enable_flap_detection</a>-Direktive auf 1.</p>
</li>
<li class="listitem">
<p>setzen Sie die <span class="emphasis"><em>flap_detection_enabled</em></span>-Direktive in Ihren Host- und Service-Definitionen auf
1.</p>
</li>
</ul></div>
<p>Wenn Sie die Flatter-Erkennung auf einer globalen Ebene deaktivieren wollen, setzen Sie die <a class="link" href="configmain.html#configmain-enable_flap_detection">enable_flap_detection</a>-Direktive auf 0.</p>
<p>Wenn Sie die Flatter-Erkennung nur für einige Hosts oder Services deaktivieren wollen, nutzen Sie die
<span class="emphasis"><em>flap_detection_enabled</em></span>-Direktive in den Host- oder Service-Definitionen, um das zu tun.</p>
<a class="indexterm" name="id5598494"></a>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="redundancy.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="escalations.html">Weiter</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Redundante und Failover-Netzwerk-Überwachung </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td>
<td width="40%" align="right" valign="top"> Benachrichtigungseskalationen</td>
</tr>
</table>
</div>
<P class="copyright">© 2009-2010 Icinga Development Team, http://www.icinga.org</P>
</body>
</html>
|
