Tunen von Nagios für maximale Performance
Einleitung
So, Sie haben schlussendlich Nagios zum Laufen gebracht und nun möchten Sie wissen wie man das Ganze etwas beschleunigen kann ... Hier einige Punkte die berücksichtigt werden könnten um Nagios zu optimieren. Lassen Sie mich wissen, wenn Ihnen andere Punkte einfallen ...
Tipps zur Optimierung:
- Nutzen Sie "aggregated status updates". Wenn Sie "aggregated status updates" aktivieren (über die Option aggregate_status_updates) reduziert dies zum Großteil die Last des Überwachungsservers, da dadurch nicht permanent versucht wird das Status Log zu aktualisieren. Insbesondere ist dies dann zu empfehlen, wenn Sie eine große Anzahl von Services überwachen. Der Hauptkompromiss im Zusammenhang mit der Verwendung von "aggregated status updates" ist, dass sich Statusänderungen von Hosts und Services nicht unmittelbar in den Status Files niederschlagen. Das kann, oder auch nicht, für Sie sehr interessant sein.
- Verwenden Sie RAM-Disks zur Haltung von Statusdaten. Wenn Sie die Standard Status Log Funktionalität und nicht "aggregated status updates" nutzen, achten Sie darauf, dass sich das Directory indem sich das Status Log befindet auf einem RAM-Disk befindet. Das beschleunigt das Ganze, aufgrund der großen Anzahl an Plattenzugriffen, ein wenig (sowohl das Hauptprogramm als auch die CGI-Programme).
- Überprüfen Sie Serviceverzögerungen um die bestmöglichen Werte für die Anzahl maximal gleichzeitiger Überprüfungen festzustellen.
Nagios ist in der Lage die Anzahl der maximal möglichen gleichzeitigen Service Checks über den Inhalt der Option max_concurrent_checks festzulegen. Dieser Umstand ermöglicht es die Last des Nagios Überwachungsrechners zu steuern, allerdings kann dadurch auch die Performance negativ beeinflußt werden. Wenn Sie hohe Verzögerungsraten (> 10 oder 15 Sekunden) für die Mehrzahl Ihrer Service Checks (über das extinfo CGI) erkennen, ist Nagios mit den Checks überfordert. Das ist nicht die Schuld von Nagios, es ist Ihre. Unter idealen Bedingungen können alle Service Checks mit einer Verzögerung von 0, das bedeutet sie werden exakt zum geplant beauftragten Zeitpunkt durchgeführt. Es ist nicht ganz normal, wenn einige Checks kleine Verzögerungszeiten aufweisen.
Ich würde empfehlen die kleinste Zahl für die maximal gleichzeitig durchgeführten Checks, wenn Nagios mit dem -s Kommandozeilen-Argument gestartet wurde, zu ermitteln und diese zu verdoppeln. Sie können diesen Wert leicht erhöhen solange die mittlere Service Check Verzögerungszeit gering ist. Mehr Informationen über die Service Check Planung können hier aufgerufen werden.
- Nutzen Sie, wenn immer möglich, passive Checks. Der Overhead der für passive Service Checks ist um ein Vielfaches geringer als jener für "normale" aktive Checks. Deshalb machen Sie Gebrauch von dieser Möglichkeit. Es ist anzumerken, dass passive Service Checks nur dann wirklich nützlich sind, wenn Sie zusätzlich einige extern laufende Anwendungen betreiben die Monitoring- oder Reportingaufgaben wahrnehmen. Setzen Sie ausschließlich Nagios für all diese Aufgaben ein, macht diese Möglichkeit keinen Sinn.
- Vermeiden Sie den Einsatz von interpretierenden Plugins. Eine Sache die signifikant die Last Ihres Überwachungsrechners reduziert ist die Verwendung von kompilierten (C/C++, usw.) Plugins gegenüber der Verwendung von interpretierenden Skripten (Perl, usw.). Während Perl-Skripte und Skripte anderer Interpretersprachen schnell zu schreiben sind und gut arbeiten, ist die Tatsache vor Augen zu führen, dass diese bei jedem Aufruf kompiliert/interpretiert werden müssen, signifikant Ihren Überwachungsrechner belasten, wenn damit viele Service Checks durchgeführt werden müssen. Wenn Sie Perl Plugins einsetzen wollen, überlegen Sie nicht diese mit Hilfe von perlcc(1) (Werkzeug, Bestandteil der Standard Perl Distribution) in ein Executable umzuwandeln oder über den eingebetteten Nagios-Perl interpreter zu kompilieren (siehe unten).
- Nutzen Sie den eingebetteten Interpreter. Wenn Sie eine große Anzahl an Perlskripten für Ihre Service Checks, usw., verwenden werden Sie vermutlich erkennen, dass das Umwandeln der Skripte über den eingebetteten Perl Interpreter in Nagios Binaries den Vorgang beschleunigt. Um das Kompilieren mit dem eingebetteten Perl Interpreter zu ermöglichen, müssen Sie beim Kompilieren von Nagios die entsprechende Kompilationsoption --enable-embedded-perl angeben. Ebenso können alle über den eingebetteten Perl Interpreter kompilierte Perl Skripte bei der Durchführung für eine spätere Wiederverwendung gecached werden, soferne Sie die Installationsoption --with-perlcache angegeben haben.
- Optimieren Sie Host Check Commands. Wenn Sie Host Stati mit Hilfe des check_ping Plugin ermitteln, werden Sie erkennen, dass die Performance steigt, wenn Sie Checks abbrechen. Anstelle den Wert von max_attempts bei der Hostdefinition auf 1 zu setzen, während das check_ping Plugin 10 ICMP Pakete zum Host sendet, ist es um vieles besser den Wert von max_attempts auf 10 zu setzen und nur 1 ICMP Paket bei jeder Durchführung zu senden. Dieses liegt an der Tatsache, daß Nagios den Status eines Hots häufig erstmaligen Durchführung des Plugin ermitteln kann, deshalb ist es angebracht die ersten Checks so schnell als möglich zu gestalten. Diese Methode hat in manchen Situationen einen Haken (z.B. wird bei träg reagierenden Hosts angenommen sie wären down), aber Sie werden viel schnellere Host Checks erleben, wenn Sie diesen Hinweis nutzen. Eine andere Option wäre die Nutzung schnellerer Plugins (z.B. check_fping) als host_check_command anstelle von check_ping.
- Verwenden Sie kein agressives Host Checking. Es sei denn sie haben Probleme damit, Recoveries von Hosts zu erkennen, würde ich Ihnen empfehlen die Option use_aggressive_host_checking nicht zu verwenden. Mit dieser deaktivierten Option werden Host Checks um ein vielfaches schneller durchgeführt, was sich betreffend raschere Durchführung der Service Check bemerkbar macht. Wie auch immer, Host Recoveries können unter bestimmten Umständen wenn sie abgeschaltet wurden nicht erkannt werden. Wenn beispielsweise ein Host recovert und sich alle seine laufenden Services in einem non-OK Status befinden, kann das bedeuten, dass Nagios nicht mitbekommt, dass der Host recovert wurde. Wenige Leute aktivieren diese Option, aber nicht die Mehrheit und ich würde empfehlen es solange nicht zu verwenden, bis Sie glauben dass es unabdingbar ist ...
- Optimieren Sie die Hardware um maximale Performance zu erhalten. Die Systemkonfiguration und die Hardwarezusammenstellung haben direkten Einfluss darauf wie das Betriebsystem Ihres Servers, indirekt wie Nagios performt. Die häufigste Optimierungsmethode können Sie an Hand Ihrer Plattenlaufwerke vornehmen. CPU und Speichergeschwindigkeit sind offensichtliche Faktoren die Auswirkungen auf die Performance haben, aber die Anzahl der Plattenzugriffe stellen den größten Flaschenhals dar. Speichern sie keine Plugins, das Status-Log, usw auf langsamen Laufwerken (z.M. alten IDE Laufwerken oder NFS Mounts). Wenn möglich verwenden Sie UltraSCSI Laufwerke oder schnelle IDE Laufwerke. Ein wichtiger Hinweis für IDE/Linux Anwender ist, adss viele Linux Installationen nicht versuchen die Plattenzugriffe zu optimieren. Wenn Sie die Plattenzugriffsparameter nicht anpassen (unter Verwendung eines Werkzeuges wie hdparam), büßen Sie sehr viel von den Geschwindigkeits-Features Ihres neuen IDE Laufwerkes ein. Lesen Sie diesen Artikel um mehr Informationen über das Performancetuning von Plattenlaufwerken unter Linux zu erfahren.