Tuning des Monitoring-Kerns

Lesen Sie den Artikel zu Instanzdiensten, um zu erfahren, auf welche Dienste Sie möglicherweise verzichten können und wie Sie den Instanz-Apache optimal auf das Nutzungsverhalten auf Ihrem Checkmk-Server einstellen. Falls Sie wegen akuten Performance-Problemen auf diesen Artikel gestoßen sind, reduzieren Sie die Zahl der Apache-Prozesse vor der Anwendung der hier vorgestellten Maßnahmen auf das absolute Minimum. Sie können diese dann später — wenn genügend RAM und CPU freigeräumt wurden — wieder auf ein sinnvolles Maß anheben.

Ein Punkt, an dem Sie ansetzen sollten, bevor Sie Monitoring-Kern und kernnahe Prozesse optimieren, ist die Laufzeit von Agenten. Zwischen dem Kontakt mit dem Agenten und dem Eingang der vollständigen Agentenausgabe wartet ein Prozess lediglich. Bei Checkmk Community ist das ein einziger Python-Prozess, der die Agentenausgabe einholt und anschließend verarbeitet. Meist benötigt dieser 80 bis 100 MB residenten Speicher. Bei den kommerziellen Editionen ist das ein sogenannter Fetcher, der nichts anderes tut als Agentenausgaben weiterzugeben. Auch diese benötigen in der Regel 30 bis 60 MB residenten Speicher.

Für die Optimierung ermitteln Sie zunächst die Zahl der mit regulären Agenten, Spezialagenten und SNMP überwachten Hosts und deren durchschnittliche Ausführungsdauer. Bei der Ermittlung hilft der Blick ins Monitoring „typischer“ Hosts — dort interessiert vor allem der Service Check_MK. Eine Topliste liefert Monitor > History > Service check durations, eine vollständige Liste kann per Livestatus eingeholt werden.

Die folgende Tabelle zeigt die Wartezeit auf Agentenausgaben und die Dauer der folgenden Verarbeitung in einer fiktiven Umgebung (mit eher pessimistischen Annahmen der CPU-Zeit), aufsummiert für ein Check-Intervall von einer Minute. Die angenommenen Zahlen resultieren in der Praxis meist in 3000 bis 5000 Services.

Auf diese Tabelle werden wir im weiteren Verlauf dieses Artikels noch einige Male — bei der Berechnung der Checker und Fetcher und der gleichzeitigen Nagios-Checks — Bezug nehmen.

Da eine Minute nur 60 Sekunden hat, resultiert aus der Tabelle, dass wenigstens 11 parallele Prozesse benötigt werden, die nur warten. Zwischen 330 und 1100 MB RAM sind in dieser Zeit zwar belegt, werden aber nicht sinnvoll genutzt. Offensichtlich ist, dass bereits ein Tuning der langsamsten Hosts positive Auswirkungen auf die Performance Ihrer Checkmk-Instanz haben kann.

Auf die CPU-Zeit wollen wir an dieser Stelle noch nicht eingehen. Da aber andere Prozesse und der Overhead für die Erstellung von Prozessen noch nicht berücksichtigt sind, ergibt eine grobe Schätzung, dass zwei CPU-Kerne hier nicht reichen werden. Auf drei Kernen sollte ein brauchbarer Betrieb möglich sein und auf vier Kernen dürfte noch Luft für die Aufnahme weiterer Hosts bleiben.

Mögliche Maßnahmen zur Optimierung der Wartezeiten sind:

Checker sind die Hilfsprozesse, die Monitoring-Daten verarbeiten, bevor diese in den Monitoring-Kern geschrieben werden. Ihr Job ist praktisch nur CPU-lastig: Zu verarbeitende Daten liegen meist bereits im Arbeitsspeicher, weshalb kein auf I/O wartender Prozess ausgelagert werden muss.

Die Auslastung der Checker hängt sehr stark von der Komplexität der ausgeführten Check-Plugins und der Menge der jeweils verarbeiteten Daten ab. Exakte Berechnungsgrundlagen sind daher schwer zu nennen. Im Idealfall haben Sie per Livestatus eine Liste der CPU-Zeiten erstellt und diese aufsummiert. In diesem Fall müssen Sie nur das Ergebnis durch 60 teilen (das reguläre Check-Intervall) und zunächst grob verdoppeln.

Wenn Sie nicht gerechnet haben, sondern lieber schätzen und optimieren: Auf aktueller Hardware kann ein Checker meist eine mittlere vierstellige bis deutlich fünfstellige Zahl von Checks bedienen. Eine grobe Kalkulation der Zahl der Checker kann daher zunächst einen Checker pro 5000 Services vorsehen.

Da Checker ihre Konfiguration im Arbeitsspeicher halten müssen und die Prozessgröße daher einige hundert Megabytes betragen kann, sollten Sie die Auslastung prüfen und die Zahl der Checker alsbald wieder in einen Bereich reduzieren, in dem die Auslastung um 50 % liegt. Von dieser Auslastung ausgehend können Sie unter Beobachtung von Latenzen (insbesondere nach einem Neustart der Checkmk-Instanz) und Lastspitzen die Zahl der Checker weiter reduzieren (oder weitere Services ins Monitoring aufnehmen), bis die Auslastung um 80 % liegt.

Fetcher sind die Hilfsprozesse, die die Agentenausgabe einholen, Spezialagenten starten und SNMP-Geräte abfragen. Die Bestimmung ihrer Zahl ist etwas aufwendiger als die der Checker. Pauschale Aussagen zur Zahl können nicht getroffen werden, zu unterschiedlich sind die Anforderungen verschiedener Monitoring-Umgebungen.

Im Kontext der Tabelle der Agentenausführung haben wir bereits angedeutet, dass Sie aus der Wartezeit auf Agenten recht gut die Zahl der benötigten Fetcher bestimmen können. Neben dieser eher theoretischen Herangehensweise können Sie auch die aktuelle Auslastung identifizieren, und die Zahl der Fetcher auf die aktuelle Auslastungssituation optimieren.

In der Praxis werden Sie beide Wege miteinander kombinieren wollen: Kalkulation und Optimierung.

Für ein initiales Setup sollten Sie um 50 % Fetcher-Auslastung anstreben. Bei dem oben gezeigten Beispiel wären Sie mit elf benötigten, aber nur 13 vorhandenen Fetchern deutlich über 80 % Auslastung. Hier böte es sich also an, zunächst die Zahl der Fetcher in den Bereich von etwa 20 zu erhöhen. Feedback in der Praxis liefert Ihnen das erwähnte Snapin Core statistics. Ergeben Ihre Berechnungen nur eine sehr kleine Zahl benötigter Fetcher, gehen Sie nicht unter drei.

Auch für Fetcher gilt langfristig: Von dieser Auslastung ausgehend können Sie unter Beobachtung von Latenzen (insbesondere nach einem Neustart der Checkmk-Instanz), dem Verhalten bei Netzwerkproblemen und Lastspitzen die Zahl der Fetcher weiter reduzieren (oder weitere Services ins Monitoring aufnehmen). Fetcher sind jedoch empfindlicher gegenüber externen Faktoren als Checker: Steigen Netzwerklatenzen oder es treten Paketverluste auf, wird die Fetcher-Auslastung deutlich steigen. Eine Obergrenze von 75–80 % sollten Sie daher nur bei einem sehr zuverlässigen Netz anstreben.

Für die Ausführung von aktiven Checks sind die Active check helpers genannten Hilfsprozesse zuständig. Die Standardeinstellung für aktive Checks des CMC liegt bei maximal fünf gleichzeitigen. Bei der Abschätzung hilft wieder der Blick in die Hitliste Monitor > History > Service check durations. Hier werden Sie sehen, dass der (standardmäßig einmal pro Tag ausgeführte) Inventur-Check auch einmal eine Minute benötigen kann, ein check_cert oft in ein paar hundert Millisekunden fertig ist und die Werte bei check_httpv2 — abhängig von der Performance des überprüften Endpunktes — erheblich schwanken. Letztlich können Sie eine Rechnung wie oben anstellen — bei fünf Active check helpers stehen pro Intervall 300 Sekunden zur Verfügung.

Oder Sie werfen zuerst einen Blick in den Service OMD mysite performance, konkret in die Metrik Helper usage und dort die Graph-Linie Active check helper usage.

Für die Berechnung der Zahl gilt wie bei den Fetchern: Gehen Sie nicht unter drei und streben Sie in größeren Umgebungen eine initiale Auslastung um 50 % an, die Sie später langsam erhöhen können.

Eine Besonderheit des CMC ist, dass bei Änderungen an der Konfiguration nicht der ganze Monitoring-Kern neu gestartet werden muss. Der CMC kann eine neue Konfiguration während des Betriebs einlesen und arbeitet dann nach Sekundenbruchteilen weiter. Die Einstellungen für einen echten Neustart des Kerns sind daher eher bei Updates und Reboots des Servers relevant.

Hier sehen die Standardeinstellungen 150 Millisekunden Wartezeit zwischen aktiven Checks und 1200 Millisekunden zwischen dem Einholen der Agentenausgabe vor. Das ist weit entspannter als der Standardwert der Fetcher sonst zulässt. Grund ist die Erwartung, dass während des Neustarts des Servers auch andere Dienste noch hochfahren. Bei großzügig dimensionierten Servern mit vielen Hosts im Monitoring bedeutet dies möglicherweise, dass bereits wenige Minuten nach dem Neustart zwar die Last niedrig ist, aber Checkmk noch lange nicht alle Services aktualisiert hat.

Vorausgesetzt, die Zahl der Fetcher und Checker ist bereits optimiert, können Sie in solchen Fällen diese Intervalle deutlich senken.

Bevor Sie Forks optimieren, sollten Sie Forks nach Möglichkeit vermeiden. Bedenken Sie, dass ein Aufruf des Services Check_MK, welcher die Agentenausgabe einholt — und dann zig Check-Ergebnisse als passive Checks direkt an den Monitoring-Kern übergibt — denselben Overhead bei Prozesserstellung und Übergabe der Ergebnisse hat wie ein simpler aktiver Check, der genau einen Netzwerkdienst überwacht. Daher ist es sinnvoll, die Zahl der aktiven Checks nach Möglichkeit zu reduzieren. Mögliche Beispiele sind:

In der Standardkonfiguration sind beliebig viele parallele Checks möglich. Diese Einstellung funktioniert bei niedriger Last von sehr kleinen bis sehr großen Systemen. Allerdings lohnt es sich, die Zahl konsequent auf das eigene Monitoring anzupassen und so Speicherauslastung und CPU-Nutzung in ein bestmögliches Verhältnis zu bringen.

Für die theoretische Berechnung des Wertes teilen Sie die gesamte Ausführungszeit der Tabelle oben durch das Check-Intervall (Standard 60 Sekunden) und schlagen noch einmal 30 bis 50 % oben drauf. Bei der oben errechneten Gesamtzeit von 715 Sekunden, wäre demnach ein Wert zwischen 16 und 18 ein passabler Startpunkt, von dem aus Sie weiter optimieren können.

Sollen nach dem Start des Kerns möglichst viele Services möglichst schnell wieder aktuell sein, muss ein Wert gefunden werden, der zwei Dinge sicherstellt:

Bei dem oben erwähnten Verhältnis von 8:1 (715 Sekunden insgesamt zu 90 Sekunden CPU-Zeit) würde bei vier Kernen ein Wert von 32 max_concurrent_checks beide Bedingungen erfüllen.

Wenn Sie nicht initial rechnen wollen, sondern eine Faustregel für die Zahl der max_concurrent_checks suchen: Starten Sie — nach Gefühl — mit einem Wert zwischen der zwei- und vierfachen Zahl der CPU-Kerne und optimieren Sie von dort aus.

Wenn Sie auch gut fünf Minuten nach dem Neustart des Monitoring-Kerns noch Services haben, die Stale sind, müssen Sie die max_concurrent_checks erhöhen. Umgekehrt gilt: Sind bereits nach weniger als einer Minute keine Services mehr Stale, halten Sie mit htop danach Ausschau, ob am Anfang eines Check-Intervalls Spitzen auftreten. Wir empfehlen bei htop, mit der Taste U (User) die Anzeige auf den Instanzbenutzer zu beschränken und dann mit T (Tree) in die Baumansicht zu wechseln. Gegebenenfalls senken Sie die Zahl maximaler gleichzeitiger Checks dann weiter. Gehen Sie aber auch in kleinen Installationen nicht unter zwei.

Nun gilt es, auch sicherzustellen, dass Ihr Linux-Kern den Start all dieser Prozesse auch zulässt.

Seit mehr als einem Vierteljahrhundert lässt der Linux-Kernel Memory Overcommitment zu. Das bedeutet, Linux erlaubt es Prozessen in der Summe mehr Arbeitsspeicher anzufordern, als ein Gerät physikalisch vorhanden hat. Die Standardeinstellung dabei ist, eine Heuristik zu verwenden, die aus in der Vergangenheit gestarteten und beendeten Prozessen versucht, auf zukünftige zu schließen. Allerdings ist bei Nagios das Verhältnis zwischen einfach mal so angefordertem („könnte ich vielleicht mal brauchen…​“) und tatsächlich resident genutztem Speicher so groß, dass der Linux-Kernel oft ohne Not die Erzeugung neuer Prozesse verweigert.

Sie müssen also ermitteln, ob der für Nagios-Prozesse benutzte virtuelle Speicher plausibel beim Linux-Kernel angefordert werden kann. Ist das nicht der Fall, müssen Sie Änderungen an den Einstellungen für das Memory Overcommitment vornehmen.

Hier gezeigte Einstellungen sind vor allem relevant, wenn Sie die max_concurrent_host_checks unlimitiert oder auf einen recht hohen Wert konfiguriert haben.

Standardmäßig versucht Nagios eine smarte Berechnung des Abstands, in dem Checks initial gestartet werden. Das kann aber zu Spitzen am Anfang der ersten Check-Intervalle führen, die auch viele Minuten nach dem Start der Checkmk-Instanz bestehen. In solchen Fällen können Sie initiale Checks künstlich über mehr als ein Check-Intervall verteilen. Oder aber, Sie wollen bereits deutlich unter einer Minute volle Sichtbarkeit erreichen, dann können Sie ein aggressives Startverhalten erzwingen.

Angenommen, Sie ermitteln bei den oben angenommenen 130 Hosts 400 aktive Checks (inclusive Check_MK), dann sorgt ein Wert von 0.15 dafür, dass diese exakt in das 60-Sekunden-Intervall passen. Für einen sanfteren Start und besseres Spreading können Sie den Start auch über zwei oder drei Check-Intervalle verteilen.

Analog verhält es sich mit der Variable host_inter_check_delay_method, welche die gleiche Einstellung für Host-Checks vornimmt. Hier ist die Rechnung einfach: ein Check pro Host. Bei der oben genannten Zahl von 130 Hosts würde als sinnvoller Wert 0,4 Sekunden resultieren.

Wenn Sie die Zahl der max_concurrent_host_checks auf einen niedrigen Wert eingestellt haben, können Sie mit service_inter_check_delay_method=n erreichen, dass das initiale Scheduling in der maximalen Parallelität stattfindet.

Der eigentliche Nagios-Kern (Scheduler, Statusberechnung) läuft Single-Threaded, kann also nicht von Mehrkernprozessoren profitieren. Im Haupt-Thread passiert relativ viel und alles muss sequentiell stattfinden. Für Checkmk relevant ist:

Bei Checkmk leisten die als aktive Checks gestarteten Python-Prozesse zur Einholung und Verarbeitung der Agentendaten die Hauptarbeit. Sie schreiben die Check-Ergebnisse in das Nagios-Spool-Verzeichnis, wo sie vom Reaper in Sekundenintervallen eingelesen werden.

Mögliche Flaschenhälse sind uns zwei bekannt:

Der erste genannte kann durchaus auf Instanzen auftreten, die ein hohes Verhältnis aktiver zu passiven Checks nutzen. Der zweite eher auf größer dimensionierter Hardware mit vielen Prozessorkernen und sehr vielen passiven Checks.

Mit dem Betrieb von Checkmk Community erfahrene Admins verteilen daher die Arbeit oft auf mehrere Monitoring-Kerne, indem sie auf einer physikalischen Maschine ein verteiltes Monitoring einrichten. Eine sinnvolle Obergrenze für solch ein verteiltes Monitoring ist in der Regel eine Checkmk-Instanz pro Prozessorkern.