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
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>8.3. Icinga für maximale Leistung optimieren</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="ch08.html" title="Kapitel 8. Sicherheit und Leistungsoptimierung">
<link rel="prev" href="cgisecurity.html" title="8.2. Verbesserte Classic UI Modul-Sicherheit und Authentifizierung">
<link rel="next" href="faststartup.html" title="8.4. Schnellstart-Optionen">
<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">8.3. Icinga für maximale Leistung optimieren</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="cgisecurity.html">Zurück</a> </td>
<th width="60%" align="center">Kapitel 8. Sicherheit und Leistungsoptimierung</th>
<td width="20%" align="right"> <a accesskey="n" href="faststartup.html">Weiter</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="section" title="8.3. Icinga für maximale Leistung optimieren">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="tuning"></a>8.3. Icinga für maximale Leistung optimieren</h2></div></div></div>
<div class="toc"><dl>
<dt><span class="section">8.3.1. <a href="tuning.html#introduction">Einführung</a></span></dt>
<dt><span class="section">8.3.2. <a href="tuning.html#optimizationtips">Optimierungshinweise:</a></span></dt>
</dl></div>
<div class="section" title="8.3.1. Einführung">
<div class="titlepage"><div><div><h3 class="title">
<a name="introduction"></a>8.3.1. Einführung</h3></div></div></div>
<div class="mediaobject"><img src="../images/tuning.png"></div>
<p>Jetzt haben Sie Icinga endlich eingerichtet und lauffähig und nun wollen Sie wissen, wie man ein wenig daran drehen kann.
Die Leistung von Icinga zu optimieren kann notwendig sein, wenn Sie eine große Zahl (> 1.000) von Hosts und Services haben.
Hier ein paar Dinge, nach denen Sie schauen können, um Icinga zu optimieren...</p>
</div>
<div class="section" title="8.3.2. Optimierungshinweise:">
<div class="titlepage"><div><div><h3 class="title">
<a name="optimizationtips"></a>8.3.2. Optimierungshinweise:</h3></div></div></div>
<div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem">
<p><span class="bold"><strong>Stellen Sie Performance-Statistiken mit PNP4Nagios dar</strong></span>. Um zu verfolgen, wie die Last Ihrer
Icinga-Installation aussieht und welche Auswirkungen Ihre Konfigurationsänderungen darauf haben, sollten Sie verschiedene
wichtige Statistiken mit PNP4Nagios darstellen. Das ist wirklich sehr, sehr sinnvoll, wenn es um die Leistungsoptimierung einer
Icinga-Installation geht. Informationen, wie das zu tun ist, finden Sie <a class="link" href="perfgraphs.html" title="8.7. Grafische Darstellung von Performance-Informationen mit PNP4Nagios">hier</a>.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Benutzen Sie "Verbesserungen für große Installationen"</strong></span> (large installation tweaks). Das
Aktivieren der <a class="link" href="configmain.html#configmain-use_large_installation_tweaks">use_large_installation_tweaks</a>-Option kann Ihnen
bessere Leistung bringen. Lesen Sie <a class="link" href="largeinstalltweaks.html" title="8.5. Large Installation Tweaks">hier</a> mehr darüber, was diese Option tut.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Deaktivieren Sie Umgebungs-Makros</strong></span>. Makros werden Prüfungen, Benachrichtigungen, Eventhandlern
usw. normalerweise über Umgebungsvariablen zur Verfügung gestellt. Das kann in einer großen Icinga-Installation zu einem
Problem werden, weil es zusätzlichen Speicher (und wichtiger) mehr CPU verbraucht. Wenn Ihre Scripte nicht über Umgebungsvariablen
auf Makros zugreifen (d.h., wenn Sie alle benötigen Makros in der Kommandozeile übergeben), dann brauchen Sie dieses Feature nicht.
Sie können über die <a class="link" href="configmain.html#configmain-enable_environment_macros">enable_environment_macros</a>-Option einstellen, ob
Makros als Umgebungsvariablen verfügbar sind.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Prüfergebnis-Ernterhythmus</strong></span> (Check Result Reaper Frequency). Die <a class="link" href="configmain.html#configmain-check_result_reaper_frequency">check_result_reaper_frequency</a>-Variable legt fest, wie oft Icinga
prüfen soll, ob Host- und Service-Ergebnisse verarbeitet werden müssen. Die maximale Zeit, die es zur Verarbeitung solcher
Ergebnisse benötigen darf, ist durch die maximale Erntezeit (max reaper time) festgelegt (siehe unten). Wenn Ihr Ernterhythmus zu
hoch (zu selten) ist, könnten Sie hohe Latenzzeiten für Host- und Service-Prüfungen sehen.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>maximale Erntezeit</strong></span> (Max Reaper Time). Die <a class="link" href="configmain.html#configmain-max_check_result_reaper_time">max_check_result_reaper_time</a>-Variable legt die maximale Zeit fest, die der
Icinga-Daemon für die Verarbeitung der Ergebnisse von Host- und Service-Prüfungen verbringen darf, bevor er sich anderen
Dingen zuwendet - wie z.B. dem Ausführen von neuen Host- und Service-Prüfungen. Ein zu hoher Wert kann zu hohen Latenzzeiten bei
Ihren Host- und Service-Prüfungen führen. Ein zu niedriger Wert kann den gleichen Effekt haben. Wenn Sie zu hohe Latenzzeiten haben,
dann passen Sie diesen Wert an und sehen Sie, welchen Effekt das hat. <a class="link" href="perfgraphs.html" title="8.7. Grafische Darstellung von Performance-Informationen mit PNP4Nagios">Graphisch dargestellte
Statistiken</a> helfen Ihnen bei der Auswertung der Auswirkungen.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Anpassen der Pufferwerte</strong></span>. Gegebenenfalls müssen Sie den Wert der <a class="link" href="configmain.html#configmain-external_command_buffer_slots">external_command_buffer_slots</a>-Option anpassen. Die graphische Analyse mit
<a class="link" href="perfgraphs.html" title="8.7. Grafische Darstellung von Performance-Informationen mit PNP4Nagios">PNP4Nagios</a> (siehe oben) zeigt Ihnen, welche Werte Sie für diese Option nutzen sollten.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Prüfen Sie Service-Latenzzeiten, um den besten Wert für die maximale Anzahl von gleichzeitigen Prüfungen
zu ermitteln</strong></span>. Icinga kann die Anzahl von gleichzeitig ausgeführten Prüfungen durch die <a class="link" href="configmain.html#configmain-max_concurrent_checks">max_concurrent_checks</a>-Option begrenzen. Das ist gut, weil es Ihnen etwas Kontrolle
darüber gibt, wieviel Last Icinga auf Ihrem Überwachungsrechner erzeugt, aber es kann auch die Dinge verlangsamen. Wenn Sie
für die Mehrzahl Ihrer Service-Prüfungen hohe Latenzzeiten sehen (> 10 oder 15 Sekunden), dann enthalten Sie Icinga
Prüfungen vor, die es braucht. Das ist nicht der Fehler von Icinga - es ist Ihrer. Unter idealen Bedingungen hätten alle
Service-Prüfungen eine Latenzzeit von 0, was bedeutet, dass alle Prüfungen zu der Zeit stattfinden, für die sie geplant sind.
Allerdings ist es normal, dass einige Prüfungen kleine Latenzzeiten haben. Wir würden empfehlen, die niedrigste Zahl der meisten
gleichzeitigen Prüfungen zu nehmen, wenn Sie Icinga mit der <span class="bold"><strong>-s</strong></span>-Option starten und diesen
Wert zu verdoppeln. Erhöhen Sie diesen Wert dann soweit, bis die durchschnittlichen Latenzzeiten für Service-Prüfungen ziemlich
niedrig ist. Mehr Informationen zur Planung von Service-Prüfungen finden Sie <a class="link" href="checkscheduling.html" title="7.23. Service- und Host-Prüfungsplanung">hier</a>.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Nutzen Sie passive Prüfungen, wenn möglich</strong></span>. Der nötige Overhead, um die Ergebnisse von <a class="link" href="passivechecks.html" title="5.7. Passive Prüfungen (Passive Checks)">passiven Service-Prüfungen</a> zu verarbeiten, ist viel niedriger als bei "normalen" aktiven Prüfungen,
also machen Sie Gebrauch von dieser Information, wenn Sie eine Menge von Services überwachen. Es sollte angemerkt werden, dass
passive Prüfungen nur dann wirklich sinnvoll sind, wenn Sie irgendeine externe Applikation haben, die überwachen oder berichten
kann; wenn also Icinga all die Arbeit machen muss, ist das nicht hilfreich.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Vermeiden Sie interpretierte Plugins</strong></span>. Etwas, was spürbar die Last Ihres Überwachungs-Hosts
senkt, ist die Nutzung von kompilierten (C/C++, usw.) Plugins statt interpretierter Scripts (Perl, usw.). Während Perl und ähnliches
einfach zu schreiben ist und gut läuft, kann die Tatsache, dass es bei jeder Ausführung kompiliert/interpretiert werden muss, zu
einer spürbaren Steigerung der Last Ihres Überwachungs-Hosts führen, wenn Sie eine Menge von Service-Prüfungen haben. Wenn Sie
Perl-Plugins nutzen wollen, dann überlegen Sie, ob Sie diese nicht mit perlcc(1) (einem Utility, das Teil der
Standard-Perl-Distribution ist) zu einem richtigen Programm umwandeln oder Icinga mit eingebettetem Perl-Interpreter
kompilieren (siehe unten).</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Nutzen Sie den eingebetteten Perl-Interpreter</strong></span>. Wenn Sie eine Menge von Perl-Scripten für
Prüfungen benutzen, dann werden Sie vielleicht feststellen, dass das Kompilieren des <a class="link" href="embeddedperl.html" title="7.18. Benutzen des Embedded Perl Interpreters">eingebetteten
Perl-Interpreters</a> (embedded Perl interpreter) in das Icinga-Binary die Dinge beschleunigt.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Optimieren Sie Host-Prüfbefehle</strong></span>. Wenn Sie Host-Zustände mit dem check_ping-Plugin prüfen,
dann werden Sie feststellen, dass die Host-Prüfungen viel schneller durchgeführt werden, wenn Sie diese abbrechen. Statt einen
<span class="emphasis"><em>max_attempts</em></span>-Wert von 1 anzugeben und mit dem check_ping-Plugins 10 ICMP-Pakete an den Host zu schicken, wäre
es viel schneller, den <span class="emphasis"><em>max_attempts</em></span>-Wert auf 10 zu setzen und jedes Mal nur ein ICMP-Paket zu senden. Das liegt
daran, dass Icinga den Zustand eines Hosts oft nach der Ausführung eines Plugins feststellen kann, so dass Sie die erste
Prüfung so schnell wie möglich machen sollten. Diese Methode hat in einigen Situationen ihre Fallstricke (z.B. Hosts, die langsam
reagieren, könnten als "down" angesehen werden), aber wir denken, dass Sie schnellere Host-Prüfungen sehen werden, wenn Sie sie
benutzen. Eine weitere Möglichkeit wäre, statt check_ping ein schnelleres Plugin (z.B. check_fping) als
<span class="emphasis"><em>host_check_command</em></span> zu benutzen.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Planen Sie regelmäßige Host-Prüfungen</strong></span>. Regelmäßige Host-Prüfungen zu planen kann tatsächlich
die Leistung von Icinga steigern. Das liegt an der Art, wie die <a class="link" href="cachedchecks.html" title="7.21. Zwischengespeicherte Prüfungen">Zwischenspeicher-Prüflogik</a> (cached check logic) arbeitet (siehe unten). Um regelmäßige Prüfungen eines
Hosts zu planen, setzen Sie die <span class="emphasis"><em>check_interval</em></span>-Direktive in der <a class="link" href="objectdefinitions.html#objectdefinitions-host">Host-Definition</a> auf einen Wert größer als Null.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Aktivieren Sie zwischengespeicherte Host-Prüfungsergebnisse</strong></span> (cached host checks).
Host-Prüfungen nach Bedarf können von der Zwischenspeicherung (caching) profitieren. Host-Prüfungen nach Bedarf werden ausgeführt,
wenn Icinga einen Service-Zustandswechsel feststellt. Diese Prüfungen nach Bedarf werden ausgeführt, wenn Icinga
wissen will, ob der mit dem Service verbundene Host den Zustand gewechselt hat. Durch die Aktivierung von zwischengespeicherten
Host-Prüfungsergebnissen können Sie die Leistung optimieren. In einigen Fällen könnte Icinga in der Lage sein, den
alten/zwischengespeicherten Zustand des Hosts zu benutzen, statt eine Host-Prüfung auszuführen. Das kann die Dinge beschleunigen und
die Last des Überwachungsservers reduzieren. Damit zwischengespeicherte Prüfungen effektiv sind, müssen Sie regelmäßige Prüfungen
für Ihre Hosts planen (siehe oben). Mehr Informationen zu zwischengespeicherten Prüfungen finden Sie <a class="link" href="cachedchecks.html" title="7.21. Zwischengespeicherte Prüfungen">hier</a>.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Nutzen Sie keine agressiven Host-Prüfungen</strong></span>. Solange Sie keine Probleme damit haben, dass
Icinga Host-Erholungen nicht korrekt erkennt, würden wir empfehlen, die <a class="link" href="configmain.html#configmain-use_aggressive_host_checking">use_aggressive_host_checking</a>-Option nicht zu aktivieren. Wenn diese Option
abgeschaltet ist, werden Host-Prüfungen viel schneller ausgeführt, was zu schnellerer Ausführung von Service-Prüfungen führt.
Allerdings können Host-Erholungen unter bestimmten Umständen übersehen werden, wenn sie ausgeschaltet ist. Wenn sich z.B. der Host
erholt, aber alle mit ihm verbundenen Services in einem nicht-OK-Zustand bleiben (und nicht zwischen verschiedenen
nicht-OK-Zuständen "kippeln"), dann könnte Icinga übersehen, dass sich der Host erholt hat. Einige wenige Leute könnten diese
Option aktivieren, aber die Mehrheit nicht und wir würden empfehlen, sie nicht zu aktivieren, solange Sie nicht glauben, dass Sie
sie benötigen...</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Optimierung externer Befehle</strong></span>. Wenn Sie eine Menge externer Befehle verarbeiten (d.h. passive
Prüfungen in einer <a class="link" href="distributed.html" title="7.6. Verteilte Überwachung">verteilten Umgebung</a>, dann wollen Sie vielleicht die <a class="link" href="configmain.html#configmain-command_check_interval">command_check_interval</a>-Variable auf <span class="bold"><strong>-1</strong></span> setzen.
Das bewirkt, dass Icinga so oft wie möglich auf externe Befehle prüft. Sie sollten außerdem überlegen, die Anzahl verfügbarer
<a class="link" href="configmain.html#configmain-external_command_buffer_slots">externer Befehlspuffer</a> zu erhöhen. Puffer werden benutzt, um externe
Befehle zu speichern, die (durch einen separaten Thread) aus dem <a class="link" href="configmain.html#configmain-command_file">external command
file</a> gelesen werden, bevor sie vom Icinga-Daemon verarbeitet werden. Wenn Ihr Icinga-Daemon eine Menge von
passiven Prüfungen oder externen Befehlen empfängt, dann könnten Sie in eine Situation kommen, in der immer alle Puffer voll sind.
Das führt zu blockierenden Kind-Prozessen (externe Scripte, NSCA-Daemon usw.), wenn sie versuchen, in das "external command
file" zu schreiben. Wir würden sehr empfehlen, dass Sie die Nutzung von externen Befehlspuffern graphisch mit Hilfe von PNP4Nagios
und dem icingastats-Utility darstellen, wie es <a class="link" href="perfgraphs.html" title="8.7. Grafische Darstellung von Performance-Informationen mit PNP4Nagios">hier</a> beschrieben ist, so dass Sie die typische
externe Befehlspuffernutzung Ihrer Icinga-Installation sehen.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Optimieren Sie die Hardware für maximale Leistung</strong></span>. Hinweis: Hardware-Leistung sollte kein
Thema sein, solange Sie nicht 1) Tausende von Services überwachen, 2) eine Menge von Nachverarbeitung von Performance-Daten usw.
machen. Ihre Systemkonfiguration und Ihre Hardware-Ausstattung werden direkt beeinflussen, was Ihr Betriebssystem leistet, so dass
sie beeinflussen, was Icinga leistet. Die häufigste Hardware-Optimierung betrifft die Festplatte(n). CPU und
Speichergeschwindigkeit sind offensichtliche Faktoren, die die Leistung beeinflussen, aber der Plattenzugriff wird Ihr größter
Flaschenhals sein. Speichern Sie Plugins, das Status-Log usw. nicht auf langsamen Platten (d.h. alte IDE-Platten oder NFS-Mounts).
Wenn Sie sie haben, dann nutzen Sie UltraSCSI- oder schnelle IDE-Platten. Ein wichtiger Hinweis für IDE/Linux-Benutzer ist,
dass viele Linux-Installationen nicht versuchen, den Plattenzugriff zu optimieren. Wenn Sie die Plattenzugriffsparameter
nicht ändern (z.B. mit einem Utility wie <span class="bold"><strong>hdparam</strong></span>), werden Sie eine <span class="bold"><strong>Menge</strong></span> der schnellen Features der neuen IDE-Platten verlieren.</p>
</li>
<li class="listitem">
<p><span class="bold"><strong>Benutzen Sie eine RAM-Disk für temporäre Daten</strong></span> . Verschiedene Dateien werden sehr oft
angelegt und verarbeitet. Das betrifft u.a. den aktuellen Zustand, der im <a class="link" href="configmain.html#configmain-status_file">status file</a>
gespeichert wird und die laufende Konfiguration, die im <a class="link" href="configmain.html#configmain-object_cache_file">object cache file</a>
abgelegt ist. Um physikalischen I/O zu reduzieren, ist es ratsam, diese Daten auf einer RAM-Disk abzulegen. Datenverlust durch einen
Stromausfall oder etwas ähnliches ist nicht kritisch, weil diese beiden Dateien bei jedem (Re-)Start von Icinga neu erzeugt
werden. Das Anlegen einer RAM-Disk und die Änderungen an der Hauptkonfigurationsdatei werden <a class="link" href="temp_data.html" title="8.8. Temporäre Daten">hier</a>
beschrieben.</p>
</li>
</ol></div>
<a class="indexterm" name="idm139734664374176"></a>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="cgisecurity.html">Zurück</a> </td>
<td width="20%" align="center"><a accesskey="u" href="ch08.html">Nach oben</a></td>
<td width="40%" align="right"> <a accesskey="n" href="faststartup.html">Weiter</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">8.2. Verbesserte Classic UI Modul-Sicherheit und Authentifizierung </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td>
<td width="40%" align="right" valign="top"> 8.4. Schnellstart-Optionen</td>
</tr>
</table>
</div>
<P class="copyright">© 1999-2009 Ethan Galstad, 2009-2017 Icinga Development Team, https://www.icinga.com</P>
</body>
</html>
|
