© Ljupco Smokovski, 123RF

Check_mk hat zurzeit Rückenwind: Es gilt nicht mehr als schnödes Nagios-Plugin und seine Oberfläche Multisite lässt die Konkurrenz alt aussehen. Doch wird Check_mk diesem Ruf in der Praxis gerecht?

Wer den Zustandvon mehr als einer Handvoll Systeme im Blick behalten möchte, muss auf handgestrickte Shellskripte oder gelegentliche Kontrollen verzichten und braucht ein vollwertiges Monitoring. Der freie Klassiker hierfür ist das altbekannte Nagios.

Ungeachtet aller Beliebtheit hakt es jedoch in traditionellen Nagios-Setups an mehreren Stellen. So zeichnet Nagios sich nicht gerade durch eine einsteigerfreundliche Konfiguration aus und verursacht durch eine wachsende Zahl zu überwachender Systeme und Dienste sowohl beim Admin als auch beim Monitoring-System einen steigenden Puls.

So muss der Nagios-Neuling nach der Installation genau überlegen, auf welchen Systemen er welche Services überwachen will und wie er dies möglichst optimal mittels Hostgruppen und Templates abbildet, damit seine Konfiguration wartbar bleibt. Zugleich wächst aber die Last auf dem Nagios-Server mit jeder Erweiterung: Je mehr Dienste und Hosts dieser überwacht, desto mehr wird die Serverhardware zum Engpass. Die Anzahl der “aktiven Checks” pro Prüfintervall bestimmt, wie leistungsfähig der Server sein muss (Abbildung 1, links).

Abbildung 1: In einem klassischen Setup baut Nagios eine Verbindung pro Check auf (oben), was den Monitoring-Server belastet. Check_mk übermittelt hingegen alle Ergebnisse in einem Rutsch (unten) und spart auf diese Weise Ressourcen.

Check_mk am Start

Speziell gegen diese beiden Probleme, gegen die komplexe Konfiguration und die hohe Serverlast, möchte Check_mk [2] vorgehen. Im Jahr 2008 vom Münchner Mathias Kettner als Ein-Mann-Projekt gestartet, entwickelte sich das 2009 unter GPL veröffentlichte Nagios-Plugin rasch weiter und stand bei Monitoring-Experten recht bald hoch im Kurs. Mehrere Entwickler pflegen das Projekt nach wie vor äußerst aktiv, die Firma hinter dem Projekt vertreibt heute auch Appliances. Check_mk ist also aus seinem Status als Nagios-Plugin herausgewachsen.

Das leistungssteigernde Konzept ist so einfach wie genial: An die Stelle der zahlreichen aktiven Nagios-Checks tritt ein Shellskript als Client-Agent, der seine Ergebnisse als passive Checks an den Nagios-Server übermittelt. Fragt das Server-Plugin die Check_mk-Agenten auf den zu überwachenden Hosts ab, prüfen diese eine Vielzahl von Daten und liefern alle Ergebnisse in einem Rutsch zurück. Das erfordert nur eine einzige Verbindung (Abbildung 1, rechts).

Auch Nagios wertet anders aus: Mit dem Nagios Remote Plugin Executor (NRPE) stupst es in der Regel ein Plugin auf dem Host an, das etwa die RAM-Auslastung misst. Das Plugin erhält einige Schwellenwerte und liefert einen Status zurück (»OK« , »Warning« , »Critical« ).

Check_mk bewertet die Ergebnisse hingegen erst auf dem Server. Dies hat den positiven Nebeneffekt, dass die Agents auf den zu überwachenden Hosts keine weitere Konfiguration benötigen. Der Check_mk-Server filtert die von den Agenten gelieferten Daten mit Hilfe der Konfigurationsparameter und Schwellenwerte, die der Admin festgelegt hat, und schickt die Ergebnisse an Nagios weiter.

Testlauf

Ob Check_mk hält, was es verspricht, soll das Testszenario (siehe Kasten “So haben wir getestet”) zeigen. Beide Systeme nutzen als Basis Ubuntu 12.04.4 LTS (die 64-Bit-Ausgabe) sowie alle notwendigen Pakete aus dem hauseigenen Universe-Repository, die einen vermeintlich schnellen Einstieg versprechen. Im Paketdepot fand der Tester jedoch neben einem betagten Check_mk 1.1.12 (aktuell ist Version 1.2.4) nur ein vormodernes Icinga 1.6.1 (aktuell ist 1.10.1). Der Artikel verwendet im Folgenden Icinga und Nagios synonym, wobei Check_mk auch Shinken unterstützt.

Stolpersteine

Warum Ubuntu für die Universe-Paketquelle keinen Support anbietet, wird schnell klar. Denn wer erwartet, dass die angeblich an Icinga angepasste Check_mk-Konfiguration des Pakets »check-mk-config-icinga« als Abhängigkeit auch Icinga selbst auflistet, wird enttäuscht. Ähnliches gilt für das Paket »check-mk-agent« , das den Agenten im Schlepptau hat, der auf den zu überwachenden Systemen läuft. Ihn soll der Daemon »xinetd« starten, doch installiert Ubuntu 12.04.2 Letzteren nicht automatisch – hier müssen die Paketmaintainer dringend nachbessern.

Aufgrund der unsauber definierten Abhängigkeiten dauert die händische Installation von Check_mk 1.2.4 kaum länger und lohnt sich, weil es neue Features und eine doppelte Anzahl an Checks mitbringt – insgesamt 491. Wie der Admin die Software auf den Server spielt, dokumentiert Listing 1. Ein Installationsskript ermittelt die meisten notwendigen Parameter automatisch.

01 wget http://mathias-kettner.de/download/check_mk-1.2.4.tar.gz
02 tar xvfz check_mk-1.2.4.tar.gz
03 cd check_mk-1.2.4/
04 ./setup.sh

Wer nicht nur die Hosts, sondern auch den Monitoring-Server selbst überwachen möchte, braucht dort ebenfalls das Agenten-Paket. Die Prozedur aus Listing 2 installiert das »check-mk-agent« -Paket nicht nur auf den Hosts, sondern auch auf dem Server. Eine RPM- und eine Debian-Variante des Pakets finden sich auf der DELUG-DVD.

01 wget http://mathias-kettner.de/download/check-mk-agent_1.2.4-2_all.deb
02 dpkg -i check-mk-agent_1.2.4-2_all.deb

Nach dem Installieren der Agents prüft der Admin jeweils, ob der »xinetd« -Superserver läuft, und setzt gegebenenfalls in der Konfigurationsdatei »/etc/xinetd.d/check_mk« die Option »disable = no« , da sonst der Verbindungsaufbau zum Check_mk-Agent über TCP-Port 6556 nicht klappt.

Sicherheitsbewusste Administratoren schränken über die Einstellung »only_from« den Zugriff auf den Check_mk-Agenten ein, und zwar auf die IP-Adresse des Monitoring-Servers. Dies ist keine wirklich saubere Lösung, weil Abfragen und Daten weiterhin unauthentifiziert und unverschlüsselt im Klartext durch das Netzwerk rauschen, aber ein Anfang. Anleitungen im Netz [3] beschreiben, wie ein Check_mk-Nutzer den Datentransport mittels SSH absichert – alternativ kann er mit Stunnel arbeiten. Wer zudem wissen möchte, welche Informationen der überwachte Host an den Monitoring-Server zurückliefert, kann sich über »nc Hostname 6556« die noch nicht ausgewerteten Rohdaten holen.

Unter Beobachtung

Die zu überwachenden Systeme macht der Admin schnell mit Check_mk bekannt. Hierzu genügt auf dem Monitoring-Server ein Eintrag in die Datei »/etc/check_mk/main.mk« . Der muss, wie alle Check_mk-Konfigurationsdateien, in Python verfasst sein. Listing 3 stellt dies für den Monitoring-Server »mon-host-ubu« und die virtuelle Maschine »mon-vm-ubu« dar. Hosts versieht der Admin dabei mit optionalen Host-Tags, die ein Pipe-Zeichen trennt. Im Beispiel trägt die virtuelle Maschine das Tag »guest« . Für so markierte Systeme kann der Systemverwalter abweichende Schwellenwerte oder alternative Abfragemechanismen definieren.

01 # Put your host names here
02 all_hosts = [
03 'mon-host-ubu',
04 'mon-vm-ubu|guest',
05 ]

Wer der Verfügbarkeit seines DNS-Servers nicht traut, kann zudem die Python-Dictionary-Datenstruktur »ipaddresses« befüllen, wodurch der Monitoring-Server DNS-Lookups umgeht. Weitere Tipps und Syntax-Fragen beantwortet die Check_mk-Dokumentation [4].

Das Inventar

Nun ist der ebenso spannende wie einförmige Augenblick gekommen, in dem »check_mk -I« alle Hosts in der Datei »main.mk« automatisch inventarisiert. In diesem Zuge liefern die Agenten auf den Hosts alle dort gefundenen und überprüfbaren Items an den Server zurück. Diese Items dürfen fast beliebiger Natur sein und zeigen beispielsweise die Auslastung von Systemressourcen wie der CPU und des Arbeitsspeichers oder die Zustände von Diensten an – die Möglichkeiten sind vielfältig.

Der Befehl »check_mk -L« listet alle verfügbaren Checks auf, der Befehl »check_mk -M Check« liefert Details zu Schwellenwerten und eventuell notwendigen Abhängigkeiten zurück. Ein Plus dieser Automatik: Der Admin muss sich vorher keine Gedanken darüber machen, was er auf den jeweiligen Systemen überwachen möchte: Die automatische Diensterkennung prüft vielmehr, was möglich ist, und liefert eine komplette Liste zurück. Das reduziert den Pflegeaufwand beim Einbinden von Dienstüberprüfungen deutlich.

Das so ermittelte Inventar bildet die Grundlage für automatisch erzeugte Checks und die passend generierte Nagios-Konfiguration. Beide Vorgänge stößt »check_mk -R« an. Der Befehl erstellt nicht nur vorkompilierte Checks zur Verbesserung der Geschwindigkeit, sondern spuckt auch eine Nagios-Konfiguration aus und startet den Monitoring-Core neu. Diesen Schritt muss der Admin immer dann wiederholen, wenn er Hosts hinzufügt, entfernt oder neue Checks findet, also wenn er das Setting ändert.

Neugierige Admins untersuchen nun mit »check_mk -N« die generierte Nagios-Konfiguration oder lassen sich über »check_mk -v Hostname« auf der Konsole den Gesundheitszustand ihres Systems anzeigen. Weitere Konfigurationsschritte sind nicht notwendig. Die Konsole ersetzt der Admin auf Wunsch durch einen Webbrowser, über den er Zugriff auf das grafische Frontend der Wahl erhält, im Test war dies zunächst das Icinga-Webinterface.

Weitere Plugins

Im Testszenario leistete Check_mk, wie in der Werbung versprochen, gute Dienste beim automatischen Erkennen der möglichen Checks. Es überwachte ohne Umstände die Auslastung von Systemressourcen und erkannte auch die Warteschlangen von Cups und Postfix ohne weiteres Zutun. Auch den Status von Apache erkennt Check_mk, sofern es auf dem Webserver die Seite »server-status« erreicht, was bei Ubuntu auch so vorkonfiguriert ist.

Über diese Seite greift die Monitoring-Software auf eine Reihe von Apaches Leistungsparametern zu, etwa die Anzahl der Zugriffe oder die Laufzeit des Dienstes. Die Werte fragt dann zum Beispiel das Check_mk-Plugin »apache_status« ab, das der Admin auf dem System im Verzeichnis »/usr/lib/check_mk_agent/plugins/« ablegt.

Hierhin gehört auch das MySQL-Plugin »mk_mysql« , das zusätzlich noch Konfigurationsparameter in »/etc/check_mk/mysql.cfg« erwartet. Die Datei darf nur Root lesen, da sie das MySQL-Root-Passwort enthält. Laut Check_mk-Dokumentation [5] besteht kein Weg, auf dem User mit Nur-Lesezugriff an die nötigen Statusinformationen kommen.

Die Smart-Werte auf dem Monitoring-Server ermittelt der Systemverwalter, indem er das Smart-Plugin im Verzeichnis »/usr/share/check_mk/agents/plugins/smart« verstaut und die Smartmontools installiert. Im Test benörgelte ein Check die zu hohe Festplattentemperatur.

Eigenbedarf

Wider Erwarten befand sich im Lieferumfang kein Check für die installierten Samba- und Vsftpd-Server. Hier bot sich im Test die Chance, eigene Checks zu definieren. Bei beiden half Mathias Kettners Remote Plugin Executor, besser bekannt unter dem Namen MRPE-Agent. Das bewusst einfach gehaltene Beispiel wertet für Samba den Rückgabewert eines lokal auf dem Samba-Server abgesetzten Smbclient-Aufrufs aus. Für Vsftpd wählten die Tester ein ähnliches Verfahren: Hier öffnete Netcat eine Verbindung auf Port 21 des FTP-Servers.

Listing 4 zeigt exemplarisch das selbst erstellte Smbclient-basierte Plugin, das der MRPE dann aufruft. Wer mit dem Skript lieber Vsftpd überwachen möchte, ersetzt den einzeiligen Smbclient-Aufruf durch den Eintrag »/bin/nc -v -z localhost 21 >/dev/null 2>&1« und passt die Ausgabe an.

01 #!/bin/sh
02 UNKNOWN=3
03 CRITICAL=2
04 WARNING=1
05 OK=0
06
07 /usr/bin/smbclient -L localhost -N >/dev/null 2>&1
08
09 if [ $? -eq 0 ]; then
10   echo "OK - Samba is up and running"
11   exit ${OK}
12 else
13   echo "CRITICAL - Samba is not running"
14   exit ${CRITICAL}
15 fi

Nach dem Schreiben der Skripte trägt der Admin die folgenden Zeilen in die Datei »/etc/check_mk/mrpe.cfg« ein:

Samba   /usr/local/mrpe/check_smbclient
VSFTPD  /usr/local/mrpe/check_vsftpd

Hat der Systemverwalter die Konfiguration angepasst, muss er noch die Hosts über »Check_mk -II« neu inventarisieren und die Nagios-Konfiguration mittels »check_mk -R« erneut erstellen und aktivieren.

Nach getaner Konfigurationsarbeit möchte der Betrachter meist wissen, ob auf seinen Systemen alles rund läuft. Statt ständig auf das Webinterface zu starren, kann er sich auch aktiv über Ausfälle informieren lassen. Hierzu bieten sich Benachrichtigungen via E-Mail an. Listing 5 entwirft eine einfache Benachrichtigung, die einen Kontakt über Statusänderungen auf den Hosts informiert. Sie lässt sich in der Datei »/etc/Check_mk/conf.d/contacts.mk« einrichten. Die »notification_options« basieren auf den Optionen von Nagios [6].

01 define_contactgroups = True
02 host_contactgroups = [
03   ("administrators", ALL_HOSTS),
04 ]
05 contacts.update(
06   {
07     "hhirsch": {
08       "alias":"Harry Hirsch",
09       "contactgroups":[ "administrators" ],
10       "email":"h.hirsch@localhorst.localdomain",
11       "notification_method":"email",
12       "host_notification_options":"dufr",
13       "service_notification_options":"wucrf",
14     },
15   },
16 )

Sichtbarer Mehrwert

Wer Check_mk bislang nur als “Nagios Check Multiplexer”-Plugin kannte, wird überrascht sein, was inzwischen alles zum Lieferumfang der Software gehört. Seit geraumer Zeit ist das GUI Multisite (Abbildung 2) Teil von Check_mk. Es enthält vieles, was der Admin in einem normalen Nagios- oder Icinga-Frontend vermisst, und zeichnet sich zudem durch eine hohe Geschwindigkeit aus. Das Nagios-Broker-Modul Livestatus, das direkten Zugang zu Statusdaten von Hosts und Services bietet, sorgt hier für einen Geschwindigkeitsschub. Multisite ermöglicht zudem verteiltes Monitoring auf mehreren Servern. Benutzer können Ansichten definieren, daneben bietet das Webinterface eine Optimierung für mobile Clients, wie sie Abbildung 3 zeigt. Das kommt besonders mobilen Admins zugute, die gern mit Tablets und Smartphones hantieren [7].

Abbildung 2: Die moderne Weboberfläche Multisite zeigt den Zustand des überwachten Systems an. Sie erwartet die Logindaten vom Icinga-Setup.

Abbildung 3: Multisite sorgt auf kleinen Bildschirmen für Übersicht, der Admin behält auch unterwegs seine Hosts und Dienste im Blick.

Das komplette System lässt sich dank Web Administration Tool (Wato) aus dem Browser heraus konfigurieren, was neben Anpassungen von Hosts und Services beispielsweise die nur kurz angerissene Konfiguration von Benachrichtigungen deutlich vereinfacht oder das Anlegen von aktiven Checks ermöglicht. So schaut der Admin auch den Diensten Apache, Vsftp oder Samba problemlos von außen auf die Finger.

Nicht zuletzt verarbeitet eine Eventkonsole SNMP-Traps und Logmeldungen. Ein Business-Intelligence-Modul aggregiert aus einzelnen Zuständen eine bessere Sicht auf das möglicherweise komplexe Gesamtsystem, was die Auswirkungen kleiner Störungen sichtbarer macht.

Der Administrator spielt diese Komponenten im Verlauf eines normalen Setup-Prozesses von Check_mk ein, was lediglich die Existenz von »make« und eines C++-Compilers auf dem System erfordert. In der auf Ubuntu beruhenden Testumgebung waren hier im Nachgang zwar einige kleinere Hürden bezüglich der Zugriffsrechte zu meistern, was einen erfahrenen Linux-Admin allerdings nicht vor eine unlösbare Aufgabe stellt.

Dass Ubuntu in der Standardinstallation seinen Apache von »apache2-mpm-prefork« auf »apache2-mpm-worker« umgestellt hat, mit dem das für Multisite notwendige »mod_python« (im Paket »libapache2-mod-python« ) nicht mehr läuft, erforderte dagegen im Test ein wenig mehr Recherche.

Fazit

Wer eine große Umgebung mit vielen Checks oder Hosts überwachen muss, der findet in Check_mk ein passendes Tool, das sowohl den Admin als auch den Monitoring-Server entlastet und zudem in größeren Setups skaliert [8]. Die passiven Checks fordern vom Monitoring-System wesentlich weniger Ressourcen als die Alternativen, und Admins Herz schlägt durch die im Vergleich zu Nagios vereinfachte Konfiguration vor Freude etwas schneller.

Außerdem haben bei Check_mk nicht nur Konsolenmuffel mit dem in Multisite integrierten Web Administration Tool die Möglichkeit, sich ihr komplettes Monitoring grafisch zu konfigurieren, sie können sich Warnungen und Nachrichten auch sogar auf dem Smartphone ansehen. Wer ohnehin Nagios oder Icinga im Einsatz hat, sollte einen Gedanken darauf verwenden, sich Check_mk mit ins Boot zu holen, selbst wenn er auf die neueren erweiterten Möglichkeiten eventuell verzichten kann.