Besonderheiten des CMC


1. Besonderheiten des Check_MK Micro Cores

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:

  • Smart-Ping – Intelligente Hostchecks
  • Check-Helper und Check_MK-Helper
  • Initiales Scheduling
  • Verarbeitung von Messdaten
  • Einige Funktionen von Nagios sind nicht oder anders umgesetzt.

2. Smart-Ping – Intelligente Hostchecks

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.

2.1. Keine On-Demand-Hostchecks

Hostchecks dienen nicht nur der Alarmierung bei einem Totalausfall eines Hosts, sondern auch dazu, Alarmierungen zu Serviceproblemen während dieser Zeit zu unterdrücken. Hierbei ist es wichtig, im Falle eines Serviceproblems schnell und präzise den Zustand des Hosts zu kennen. Selbst wenn der letzte Hostcheck nicht lange her ist, kann dessen Ergebnis bereits veraltet sein. Dazu genügt es, wenn direkt nach einem Ausfall des Host durch Zufall zuerst der Servicecheck ausgeführt wird. Der Host würde dann noch als UP angesehen und der Alarm für den Service – fälschlicherweise – versendet.

Der CMC löst dieses Problem sehr einfach: Ist bei einem Serviceproblem der Host im Zustand UP, dann wird einfach der nächste Hostcheck abgewartet. Da das Intervall mit sechs Sekunden sehr kurz ist, ergibt sich keine nennenswerte Verzögerung der Alarmierung, falls der Host UP ist. Zusätzlich verwendet der CMC einen weiteren Trick: Der icmpreceiver wertet nämlich nicht nur eingehende Antworten auf Ping aus, sondern auch Pakete, die beim TCP-Verbindungsaufbau entstehen (SYN und RST).

Nehmen Sie als Beispiel den Fall, dass ein check_http-Plugin einen CRIT-Status liefert, weil der abgefragte Webserver nicht erreichbar ist. In diesem Fall wurde nach dem Beginn des Servicechecks ein TCP-RST-Paket von dem Server empfangen (Connection Refused). Der CMC weiß daher mit Sicherheit, dass der Host selbst UP ist und kann den Alarm ohne Verzögerung sofort versenden.

Das gleiche Prinzip wird beim Berechnen von Netzwerkausfällen angewendet, wenn Parents definiert sind. Auch hier werden Alarmierungen teilweise kurz zurückgehalten, um einen gesicherten Status abzuwarten.

2.2. Der Nutzen

Durch dieses Verfahren ergibt sich eine Reihe von Vorteilen:

  • Nahezu vernachlässigbarer CPU-Verbrauch durch Hostchecks: Es können selbst ohne besonders leistungsfähige Hardware Zigtausende von Hosts überwacht werden.
  • Kein Ausbremsen des Monitorings durch blockierende On-Demand-Hostchecks, falls Hosts DOWN sind.
  • Keine Fehlalarmierungen von Servics bei nicht aktuellem Hoststatus.

Ein Nachteil soll dabei nicht verschwiegen werden: Die Hostchecks via Smart-Ping erzeugen keine Performance-Daten (Paketlaufzeiten). Auf Hosts, bei denen Sie diese benötigen, können Sie einfach einen Ping-Check einrichten (über den Regelsatz Active Checks ➳ Check hosts with PING).

2.3. Nicht Ping-bare Hosts

In der Praxis sind nicht alle Hosts durch Ping überprüfbar. Für diese Fälle kann man auch im CMC andere Methoden für den Hostcheck verwenden, z. B. einen TCP-Connect. Da dies in der Regel Ausnahmen sind, wirken sie sich nicht negativ auf die Gesamtperformance aus. Der Regelsatz dazu lautet Monitoring Configuration ➳ Host Check Command.

2.4. Probleme mit Firewalls

Es gibt Firewalls, die TCP-Verbindungspakete an nicht erreichbare Hosts mit einem TCP RST beantworten. Das Trickreiche ist dabei, dass die Firewall als Absender dieser Pakete nicht sich selbst eintragen darf, sondern die IP-Adresse des Zielhosts angeben muss. Smart-Ping wird dieses Paket als Lebenzeichen werten und somit zu Unrecht annehmen, dass der Zielhost erreichbar ist.

In so einer (seltenen) Situation haben Sie die Möglichkeit, über die globale Einstellung Monitoring Core ➳ Tuning of Smart-Ping die Option Ignore TCP Reset Packets zu aktivieren. Oder Sie wählen für die betroffenen Hosts als Host-Check einen klassischen Ping mit check_icmp.

3. Check-Helper und Check_MK-Helper

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 Check_MK-Umgebung sind aktive Checks eher die Ausnahme. Hier kommen hauptsächlich Check_MK-basierte Checks zum Einsatz, bei denen pro Host und Intervall nur noch ein Fork notwendig ist. Check_MK berechnet die Ergebnisse von allen Services ganz ohne weitere Prozesserzeugungen. Doch auch das Check_MK-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 Check_MK-Helper. Jeder Helper kann einen parallelen Check_MK-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 + Check_MK 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.

3.1. Anzahl der Helper richtig einstellen

Standardmäßig werden 20 Check-Helper und 5 Check_MK-Helper gestartet. Daraus folgt, dass maximal 5 Check_MK-Checks gleichzeitig laufen können. Wenn Sie eine größere Zahl von Hosts überwachen wollen, könnte es sein, dass diese Größen nicht ausreichen. Das gilt vor allem dann, wenn Sie Hosts mit größeren Wartezeiten haben (z. B. beim Monitoring von VMWare ESXi oder langsam antwortenden SNMP-Geräten). Das Seitenleistenelement Micro Core Statistics zeigt Ihnen die prozentuale Auslastung der Helper im Durchschnitt der letzten 10-20 Sekunden:

In den globalen Einstellungen zum Monitoring Core können Sie die Anzahl bequem einstellen.

4. Initiales Scheduling

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 Check_MK 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.

5. Verarbeitung von Messdaten

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

  • das Anlegen und Aktualisieren der Round-Robin-Datenbanken und
  • die grafische Darstellung der Daten in der GUI.

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:

  • Einsparen von Disk-I/O und CPU
  • Einfachere Implementierung mit deutlich mehr Stabilität

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 Check_MK-Format (gilt nur für Neuinstallationen). Ein Wechsel von Nagios auf CMC hat daher keinen Einfluß auf bestehende RRD-Dateien. Diese werden nahtlos weitergepflegt.

Die grafische Darstellung der Daten in der GUI übernimmt ab Version 1.2.8 der  Check_MK Enterprise Edition direkt die GUI von Check_MK selbst, so dass keine Komponente von PNP4Nagios mehr beteiligt ist.