Besonderheiten des CMC

Die wichtigsten Vorteile des CMC liegen in seiner gegenüber Nagios höheren Performance und schnelleren Reaktionszeiten. Es gibt jedoch auch darüber hinaus einige interessante Besonderheiten, die Sie kennen sollten. Die Wichtigsten sind:

Bei Nagios ist es üblich, die Erreichbarkeit von Hosts mittels eines „Ping“ zu prüfen. Dazu wird für jeden Host einmal pro Intervall (in der Regel eine Minute) ein Plugin wie check_Ping oder check_icmp aufgerufen. Dieses sendet dann z.B. fünf Ping-Pakete und wartet auf deren Rückkehr. Das Erzeugen der Prozesse für den Aufruf der Plugins verbraucht wertvolle CPU-Ressourcen. Zudem sind diese recht lange blockiert, falls ein Host nicht erreichbar ist und lange Timeouts abgewartet werden müssen.

Der CMC führt Hostchecks hingegen — soweit nicht anders definiert — mit einem Verfahren namens Smart-Ping aus. Dabei wird an jeden Host pro Intervall ein Ping-Paket versendet. Das erledigt ein Hilfsprozess mit dem Namen icmpsender — und zwar direkt und ohne Prozesserzeugung. Der icmpsender hat zu diesem Zweck eine von uns entwickelte eigenständige Ping-Implementierung und ist ausgesprochen effizient. In Benchmarks konnten wir bis zu 45 MBit/sec Netzwerkverkehr nur durch Ping erzeugen! Das Intervall für die Pings ist pro Host per Default auf sechs Sekunden eingestellt. Sie können das über den Regelsatz Normal check interval for host checks anpassen.

Die Antworten auf die Pings werden nicht explizit abgewartet. Eingehende Ping-Pakete werden einfach als erfolgreiche Hostchecks gewertet. Dafür ist der Hilfsprozess icmpreceiver verantwortlich. Wenn für eine einstellbare Zeit kein Paket von einem Host empfangen wurde, wird dieser als DOWN gewertet. Diese Timeoutzeit ist per Default auf 15 Sekunden (2,5 Intervalle) eingestellt und kann per WATO pro Host über den Regelsatz Settings for host checks via Smart-Ping geändert werden.

Eine Lehre aus der schlechten Performance von Nagios in größeren Umgebungen ist, dass das Erzeugen von Prozessen eine teuere Operation ist. Entscheidend hierbei ist aber vor allem die Größe des Mutterprozesses. Bei jeder Ausführung eines aktiven Checks muss zunächst der komplette Nagios-Prozess dupliziert werden (fork), bevor er durch den neuen Prozess — das Check-Plugin — ersetzt wird. Je mehr Hosts und Services überwacht werden, desto größer ist dieser Prozess und desto länger dauert der Fork. Da der Prozess während dessen auch noch blockiert ist, bleiben auch die anderen Aufgaben des Cores liegen — da helfen auch keine 24 CPU-Kerne.

Um das Forken des Cores zu vermeiden, erzeugt der CMC beim Programmstart eine festgelegte Anzahl von sehr schlanken Hilfsprozessen, deren Aufgabe das Starten der aktiven Check-Plugins ist: die Check-Helper. Nicht nur forken diese viel schneller, das Forken skaliert auch noch über alle vorhandenen CPU-Kerne, da der Core selbst nicht mehr blockiert wird. Dadurch wird das Ausführen von aktiven Checks (z.B. check_http), deren eigentliche Laufzeit recht kurz ist, stark beschleunigt.

Aber der CMC geht noch einen wesentlichen Schritt weiter. Denn in einer Checkmk-Umgebung sind aktive Checks eher die Ausnahme. Hier kommen hauptsächlich Checkmk-basierte Checks zum Einsatz, bei denen pro Host und Intervall nur noch ein Fork notwendig ist. Checkmk berechnet die Ergebnisse von allen Services ganz ohne weitere Prozesserzeugungen. Doch auch das Checkmk-Plugin selbst braucht etwas CPU-Zeit. Dabei wird der Großteil beim Starten des Plugins benötigt.

Um dies zu vermeiden unterhält der CMC noch eine zweite Klasse von Hilfsprozessen: die Checkmk-Helper. Jeder Helper kann einen parallelen Checkmk-Check für einen Host ausführen. Da der Prozess kontinuierlich weiterläuft und immer wieder verwendet wird, entfällt der Overhead durch den Fork und das Laden des Programms. Dies hat gegenüber der Kombination Nagios + Checkmk zwei sehr angenehme Folgen: Die benötigte CPU-Zeit für einen Check-Durchlauf verringert sich etwa um den Faktor 15! Zudem entfällt das Vorkompilieren der Hostchecks, was wiederum Konfigurationsänderungen beschleunigt.

Beim Scheduling wird festgelegt, welche Checks zu welcher Zeit ausgeführt werden sollen. Nagios hat hier mehrere Verfahren implementiert, die dafür sorgen sollen, dass die Checks gleichmäßig über die Zeit verteilt werden. Dabei wird auch versucht, die Abfragen, die auf einem einzelnen Zielsystem laufen, über das Intervall zu verteilen.

Der CMC hat hier ein eigenes, einfacheres Verfahren. Dies trägt dem Umstand Rechnung, dass Checkmk einen Host ohnehin nur einmal pro Intervall kontaktiert. Außerdem sorgt der CMC dafür, dass neue Checks sofort ausgeführt werden und nicht über mehrere Minuten verteilt. Für den Anwender ist das sehr angenehm, da ein neu aufgenommener Host sofort nach dem Aktivieren der Konfiguration abgefragt wird. Um eine Lastspitze bei einer großen Zahl von neuen Checks zu vermeiden, werden neue Checks, die eine bestimmte einstellbare Zahl überschreiten, auf das ganze Intervall verteilt. In den globalen Einstellungen finden Sie dazu den Punkt Initial Scheduling.

Eine wichtige Funktion von Checkmk ist das Verarbeiten von Messdaten — wie (z.B. CPU-Auslastung) und deren Speicherung über einen längeren Zeitraum. In der Checkmk Raw Edition Dazu kommt dabei PNP4Nagios von Jörg Linge zum Einsatz, welches wiederum auf RRDTool aufsetzt. Die Software erledigt zwei Aufgaben:

Bei Verwendung des Nagios-Cores läuft der erste Part über einen recht langen Weg. Je nach Methode kommen dabei Spooldateien, Perlskripte und ein Hilfsprozess zum Einsatz, der in C geschrieben ist (npcd). Am Ende werden leicht umgewandelte Daten in das Unixsocket des RRD-Cache-Daemons geschrieben.

Der CMC kürzt diese Kette ab, in dem er direkt zum RRD-Cache-Daemon schreibt — alle Zwischenschritte werden ausgelassen. Das Parsen der Daten und Umwandeln in das Format der RRD-Tools erfolgt direkt in C++. Dieses Verfahren ist heute möglich und sinnvoll, da der RRD-Cache-Daemon ohnehin sein eigenes sehr effizientes Spooling implementiert und mithilfe von Journaldateien auch bei einem Absturz des Systems keine Daten verliert. Die Vorteile:

Das Neuanlegen von RRDs erledigt der CMC mit einem weiteren Helper, der per cmk --create-rrd aufgerufen wird. Dieser legt die Dateien wahlweise kompatibel zu PNP an oder alternativ im neuen Checkmk-Format (gilt nur für Neuinstallationen). Ein Wechsel von Nagios auf CMC hat daher keinen Einfluß auf bestehende RRD-Dateien. Diese werden nahtlos weitergepflegt.

In den Checkmk Enterprise Editions übernimmt die grafische Darstellung der Daten direkt die GUI von Checkmk selbst, so dass keine Komponente von PNP4Nagios mehr beteiligt ist.