Checkmk auf der Kommandozeile

Bei der Administration von Checkmk müssen Sie mit wenigen Ausnahmen niemals als root-Benutzer arbeiten. In diesem Artikel gehen wir grundsätzlich davon aus, dass Sie als Instanzbenutzer angemeldet sind. Das geht z.B. mit:

Auch ein direkter SSH-Login in eine Instanz ohne dem Umweg über root ist möglich. Da der Instanzbenutzer ein „ganz normaler“ Linux-Benutzer ist, müssen Sie dazu lediglich ein Passwort vergeben (was ein letztes Mal root-Rechte erfordert):

Danach sollte ein SSH-Login von einem anderen Rechner aus direkt möglich sein (Windows-Benutzer verwenden am besten PuTTY dafür). Von Linux aus geht das einfach mit dem Kommandozeilenbefehl ssh:

Beim ersten Login bekommen Sie wahrscheinlich eine Warnung wegen eines unbekannten Host-Schlüssels. Wenn Sie sicher sind, dass kein Angreifer in diesem Augenblick die IP-Adresse Ihres Monitoringsystem übernommen hat, können Sie diese einfach mit yes bestätigen.

Auch bei der Checkmk-Appliance können Sie auf die Kommandozeile zugreifen. Wie das geht, erklärt ein eigener Artikel.

Damit es zu möglichst wenig Problemen aufgrund von Besonderheiten einzelner Distributionen oder unterschiedlicher Betriebssystemkonfigurationen kommt, sorgt das Checkmk-System dafür, dass Instanzbenutzer — und gleichzeitig alle Prozesse des Monitorings — immer eine klar definierte Umgebung haben. Neben dem Homeverzeichnis und den Berechtigungen, spielen hier die Umgebungsvariablen (Environment) eine wichtige Rolle.

Unter anderem werden beim Login als Instanzbenutzer folgende Variablen gesetzt bzw. modifiziert. Sie stehen in allen Prozessen zur Verfügung, welche innerhalb der Instanz laufen. Das betrifft auch Skripten, die indirekt von diesen aufgerufen werden (z.B. eigene Alarmierungsskripten).

Mit dem Befehl env können Sie sich alle Umgebungsvariablen ausgeben lassen. Ein kleines, hübsches |sort dahinter, macht das Ganze etwas übersichtlicher:

Unter Linux ist das Environment eine Eigenschaft eines Prozesses. Jeder Prozess hat seine eigenen Variablen, welcher er an Unterprozesse automatisch vererbt. Dieser startet zwar dann erstmal mit den gleichen Variablen, kann diese aber verändern.

Mit dem Befehl env können Sie immer nur die Umgebung der aktuellen Shell ansehen. Wenn Sie einen Fehler in der Umgebung eines bestimmten Prozesses vermuten, können Sie diese mit einem kleinen Trick ausgeben lassen. Dazu brauchen Sie nur die Prozess-ID (PID). Diese könen Sie z.B. mit ps ax, pstree -p oder top ermitteln. Damit greifen Sie dann über das /proc-Dateisystem direkt auf die Datei environ des Prozesses zu. Hier ist ein passender Befehl für die Beispiel-PID 13222:

Wenn Sie für eigene Skripten oder andere Software, die in der Instanz laufen soll, eigene Variablen benötigen, so legen Sie diese bitte in der Datei etc/environment an, welche extra dafür vorgesehen ist. Alle hier definierten Variablen werden überall in der Instanz bereitgestellt:

Wenn Sie Ihre Shell anpassen möchten (Prompt oder andere Dinge), können Sie das wie gewohnt in der Datei .bashrc tun. Umgebungsvariablen gehören trotzdem nach etc/environment, damit diese auch sicher in allen Prozessen vorhanden sind.

Es spricht auch nichts gegen eine eigene .vimrc, falls Sie gerne mit VIM arbeiten.

Folgendes Schaubild zeigt die wichtigsten Verzeichnisse einer Checkmk-Installation mit einer Instanz mit dem Namen mysite, welche die Checkmk-Version 1.6.0p18 verwendet:

Die Basis bildet das Verzeichnis /omd. Alle Dateien von Checkmk befinden sich ohne Ausnahme hier. Zwar ist /omd ein symbolischer Link auf /opt/omd ist, womit die Daten physikalisch eigentlich unterhalb von /opt liegen. Aber alle Pfadangaben in Checkmk verwenden immer /omd.

Wichtig ist die Aufteilung in Daten (gelb dargestellt) und Software (blau). Die Daten der Instanzen liegen unterhalb von /omd/sites, die installierte Software unter /omd/versions.

Wie jeder Linux-Benutzer hat auch der Instanzbenutzer ein Homeverzeichnis, welches wir als Instanzverzeichnis bezeichnen. Wenn Ihre Instanz mysite heißt, so liegt dieses unter /omd/sites/mysite. Wie bei Linux üblich kürzt die Shell das eigene Homeverzeichnis mit einer Tilde (~) ab. Da Sie sich nach einem Login direkt in diesem Verzeichnis befinden, erscheint die Tilde im Eingabeprompt:

Unterverzeichnisse des Instanzverzeichnisses werden relativ zur Tilde dargestellt:

Direkt im Instanzverzeichnis befinden sich etliche Unterverzeichnisse, die Sie mit ll (Alias für ls -alF) auflisten können:

Wie Sie sehen können, sind die Verzeichnisse bin, include, lib, share und version symbolische Links. Beim Rest handelt es sich um „normale“ Verzeichnisse. Dies spiegelt die oben genannte Trennung von Software und Daten wieder. Die Verzeichnisse zur Software müssen zwar in der Instanz als Unterverzeichnisse verfügbar sein, liegen aber physikalisch unterhalb von /omd/versions und werden dort eventuell noch von weiteren Instanzen genutzt.

Die Verzeichnisse der Software gehören wie unter Linux üblich root und sind daher vor Veränderungen durch den Instanzbenutzer geschützt. Es gibt folgende Unterverzeichnisse, welche hier im Beispiel physikalisch unterhalb von /omd/versions/1.6.0p18.cee liegen und über symbolische Links vom Instanzverzeichnis aus erreichbar sind:

Der symbolische Link version/ ist ein „Zwischenstop“ und dient als zentrale Umschaltstelle für die von der Instanz verwendete Version. Bei einem Softwareupdate wird dieser symbolische Link von der alten auf die neue Version umgeboben. Bitte versuchen Sie trotzdem nicht, ein Update von Hand durch Ändern des Links zu durchzuführen, denn beim Update sind noch einige weitere Schritte notwendig, die dann fehlen würden.

Die eigentlichen Daten einer Instanz liegen in den restlichen Unterverzeichnissen des Instanzverzeichnisses. Diese gehören ohne Ausnahme dem Instanzbenutzer. Auch das Instanzverzeichnis selbst gehört dazu. Checkmk legt dort außer den hier gezeigten Verzeichnissen keine Dinge ab. Sie können hier aber problemlos eigene Dateien und Verzeichnisse anlegen, in denen Sie Tests, heruntergeladene Dateien, Kopien von Logdateien oder was auch immer ablegen möchten.

Es gibt folgende vordefinerte Verzeichnisse:

Wie gerade in der Tabelle gezeigt, ist das Verzeichnis local mit seinen zahlreichen Unterverzeichnissen für Ihre eigenen Erweiterungen vorgesehen. In einer neuen Instanz sind alle Verzeichnisse unter local/ zunächst leer.

Mit dem praktischen Befehl tree können Sie sich schnell einen Überblick über die Struktur unter local verschaffen. Die Option -L 3 begrenzt hier die Tiefe auf 3:

Alle Verzeichnisse der unteresten Ebene sind aktiv in die Software eingebunden. Legen Sie hier eine Datei ab, so wird diese genauso behandelt, als läge sie im gleichnamigen Verzeichnis unterhalb von /omd/versions/…​ (bzw. im logischen Pfad von der Instanz aus unter bin, lib oder share).

Beispiel: In der Instanz werden ausführbare Programme in bin und in local/bin gesucht.

Dabei gilt, dass bei einer exakten Namensgleichheit die Datei unter local immer Vorrang hat. Das ermöglicht Ihnen, Dateien der Software zu modifizieren, ohne Installationsdateien unterhalb von /omd/versions/ ändern zu müssen. Das Vorgehen ist einfach:

Falls Sie beim dritten Punkt nicht genau wissen, welche Dienste das sind, so können Sie einfach mit omd restart die ganze Instanz neu starten.

Die Logdateien werden bei Checkmk unterhalb des bereits erwähnten Datenverzeichnis var/ abgelegt. Hier finden Sie zu allen Komponenten das entsprechende Logfile:

Auf der Weboberfläche können Sie über die Global Settings bequem konfigurieren, in welchem Umfang Daten in die Logdateien geschrieben werden sollen:

Natürlich können Sie alternativ auch die Loglevel auf der Kommandozeile in der Datei global.mk anpassen. Diese liegt in dem Verzeichnis für Konfigurationsdateien. Setzen Sie die Einträge, wenn Sie noch nicht vorhanden sind:

Für cmc_log_levels nimmt der Umfang der geloggten Daten mit größeren Zahlen zu. Hier gibt es acht Abstufungen (0 bis 7), wobei 0 für Emergency und 7 für Debug steht.

Für notification_logging stehen die drei Zahlenwerte 10 für Full dump of all variables and command, 15 für Normal logging und 20 für minimal logging.

Das alert_logging wiederum kann die Werte 10 für Full dump of all variables oder 20 für Normal logging bekommen.

Mit den drei Werten 'terse', 'full' und None für cmc_log_rrdcreation können Sie festlegen, inwiefern die Erzeugung von RRDs geloggt werden soll.

Für das Log der Weboberfläche können Sie das Level entsprechend hier ändern:

Der Umfang der geloggten Daten steigt hier, je kleiner die Zahl ist. Das geringste Loglevel ist somit 50 (Critical), während 10 dem dann dem höchsten Loglevel (Debug) entspricht.

Das Loglevel für den Liveproxydaemon wird in der folgenden Datei gesetzt. Die Syntax ist die Gleiche, wie für das Log der Weboberfläche:

Wichtig: Logdateien können schnell sehr groß werden, wenn ein hohes Level eingestellt ist. Es eignet sich daher vor allem zur temporären Anpassung, um Probleme besser identifizieren zu können.

Der Befehl cmk ist eigentlich eine Abkürzung für check_mk, welche eingeführt wurde, damit der Befehl leichter zu tippen ist. Der Befehl verfügt über eine eingebaute Onlinehilfe, die Sie wie üblich mit --help aufrufen können:

Einige Optionen funktionieren immer — egal mit welchem Modus Sie den Befehl aufrufen:

Die Checkmk Enterprise Editions verwenden als Monitoringkern den Checkmk Micro Core (CMC), bei der Checkmk Raw Edition kommt Nagios zum Einsatz. Eine wichtige Aufgabe von cmk ist es, eine für den Kern lesbare Konfigurationsdatei zu erzeugen, welche alle konfigurierten Hosts, Services, Kontakte, Kontaktgruppen, Zeitperioden usw. enthält. Anhand dieser weiß der Kern, welche Checks er ausführen muss und welche Objekte er per Livestatus der GUI bereitstellen soll.

Grundsätzlich gilt sowohl für Nagios also auch für den CMC, dass die Menge der Hosts, Services und anderen Objekte zur Laufzeit immer statisch ist und sich nur durch das Erstellen einer neuen Konfiguration ändern kann, welche der Kern anschließend neu laden muss. Bei Nagios ist dazu ein Neustart des Kerns nötigt. Der CMC beherrscht ein sehr effizientes Neuladen der Konfiguration im laufenden Betrieb.

Folgende Tabelle zeigt wichtige Unterschiede bei der Konfiguration der beiden Kerne:

Das Neuerzeugen der Konfiguration ist immer dann notwendig, wenn sich Inhalte der Konfigurationsdateien unterhalb von etc/check_mk/conf.d oder automatisch erkannte Services unter var/check_mk/autochecks geändert haben. WATO führt Buch über solche Änderungen und zeigt diese in der GUI an. Falls Sie die Konfiguration manuell oder durch Skripte „an WATO vorbei“ modifizieren, müssen Sie sich selbst um das Aktivieren kümmern. Dazu dienen folgende Befehle:

Zusammengefasst bedeutet das: Wenn Sie von Hand die Checkmk-Konfiguration anpassen und die Änderungen aktivieren möchten, benötigen Sie anschließend bei Nagios:

Und beim CMC:

Eine zweiter Modus von Checkmk befasst sich mit der Ausführung von Checkmk-basierten Checks eines Hosts. Damit können Sie alle automatisch erkannten und auch manuell hinzu konfigurierten Services sofort checken lassen, ohne dass Sie dafür den Monitoringkern oder die GUI bemühen müssen. Geben Sie dazu einfach den Befehl cmk und direkt den Namen eines im Monitoring konfigurierten Hosts an. Außerdem sollten Sie immer folgende beiden Optionen hinzufügen:

Hinweise dazu:

Folgende Optionen beeinflussen den Befehl:

Eine automatische Serviceerkennung können Sie auf der Kommandozeile mit cmk -I oder cmk -II und der Angabe von einem oder mehreren Hosts durchführen:

Dabei gibt es zwei Modi:

Alle Details dazu finden Sie im entsprechenden Abschnitt im Artikel über die Services.

Der Befehl cmk kennt auch einige Modi, die allgemein zur Diagnose und Fehlersuche nützlich sind. Hier ist eine Übersicht:

Im Folgenden zeigen wir, wie Sie die Befehle verwenden können. Die Beispielausgaben sind meist gekürzt dargestellt.

WATO ist ein tolles webbasiertes Konfigurationswerkzeug. Aber es gibt viele Gründe, eine Konfiguration mit Textdateien in guter alter Linux-Tradition zu bevorzugen. Wenn auch Sie diese Meinung haben, gibt es für Sie eine gute Nachricht: Sie können Checkmk vollständig über Textdateien konfigurieren. Und da WATO ebenfalls nichts anderes macht, als (dieselben) Textdateien zu bearbeiten, ist das noch nicht einmal ein Entweder/Oder.

Falls Sie jetzt allerdings ein umfassendes Kompendium über den genauen Aufbau von allen von Checkmk verwendeten Konfigurationsdateien erwarten, müssen wir Sie leider an dieser Stelle enttäuschen. Die Komplixät und Vielfalt, die in den Konfigurationsdateien steckt, ist einfach viel zu groß, um sie in einem Handbuch komplett zu beschreiben.

Folgendes Beispiel zeigt einen komplett ausgefüllten Parametersatz für das Check-Plugin, welches in Checkmk Dateisysteme überwacht. Wegen der vielen Parameter ist der Screenshot in zwei Teile zerlegt und in kleiner Schrift gesetzt:

Die entsprechende Passage dazu in der Konfigurationsdatei sieht (etwas hübscher formatiert) so aus:

Wie Sie sehen, gibt es hier nicht weniger als 14 verschiedene Parameter, die jeweils eine ganz eigene Logik haben. Manche werden über Fließkommazahlen (0.8), manche über Ganzzahlen (24), manche über Schlüsselworte ('onlow'), manche über boolsche Werte (True) und andere wieder über Tupel aus solchen Dingen konfiguriert ((5.0, 10.0)).

Dieses Beispiel ist nur eines von über 1.300 Plugins. Und dann gibt es ja auch noch andere Konfigurationen als Checkparameter: Man denke nur an Timeperiods, Regeln der Event Console, Benutzerprofile und vieles mehr.

Das soll natürlich nicht heißen, dass Sie auf eine Konfiguration über Textdateien verzichten müssen! Wenn Sie die genaue Syntax für die Konfigurationsaufgabe Ihrer Wahl noch nicht kennen, brauchen Sie dafür nur das richtige Werkzeug. Und das heißt: WATO:

Sie müssen also nur wissen, in welche Datei WATO was schreibt.

Um herauszufinden, welche Datei WATO gerade verändert hat, gibt es einen praktischen Befehl: find. Mit folgenden Parametern aufgerufen, finden Sie alle Dateien (-type f) unterhalb von etc/, welche innerhalb der letzten Minute (-mmin -1) geändert wurden:

Die Basis der Konfiguration ist immer das Verzeichnis etc/check_mk. Darunter gibt es eine Aufteilung in verschiedene Domänen, welche meist einen bestimmten Dienst betreffen. Dabei gibt es jeweils ein Verzeichnis mit der Endung .d, unterhalb dessen alle Dateien mit der Endung .mk automatisch und in alphabetischer Reihenfolge eingelesen werden. Bei manchen gibt es noch eine Hauptdatei, welche als Erstes eingelesen wird. Diese wird von WATO nie angefasst und ist nur für manuelle Änderungen vorgesehen.

Unterhalb der conf.d/-Verzeichnisse gibt es immer das Unterverzeichnis wato, z.B. etc/check_mk/conf.d/wato. WATO liest und schreibt grundsätzlich nur dort. Der eigentliche Dienst liest aber auch die übrigen Dateien aus conf.d, falls Sie dort welche von Hand anlegen. Das bedeutet:

Rein formal gilt für alle Konfigurationsdateien von Checkmk, dass diese in Python-2-Syntax geschrieben sind. Dabei gibt es zwei Arten von Dateien:

Die ausführbaren Dateien erkennen Sie daran, dass hier Variablen durch Zuweisungen (=) mit Werten belegt werden. Die anderen Dateien enthalten meist ein Python-Dictionary, welches mit einer öffnenden geschweiften Klammer beginnt. Manchmal sind es auch einfache Werte.

Falls Sie in einer Datei einen Umlaut benötigen — genauer gesagt ein Nicht-Ascii-Zeichen –, so müssen Sie in die erste oder zweite Zeile folgenden Kommentar einfügen:

Andernfalls wird es beim Einlesen zu einem Syntaxfehler kommen. Für weitere Hinweise zur Syntax von Python verweisen wir auf dafür spezialisierte Seiten, zum Beispiel auf die offizielle Referenz von Python 2.