1. Warum Kommandozeile?
Wenn ein Checkmk-System mal installiert ist, können Sie es zu 100% über die Weboberfläche konfigurieren und bedienen. Trotzdem gibt es Situationen, in denen es nützlich ist, sich auf die Untiefen der Kommandozeile zu begeben, z.B.
bei der Suche nach der Ursache von Problemen,
beim Automatisieren der Administration von Checkmk,
beim Programmieren und Testen von eigenen Erweiterungen,
um zu verstehen, wie Checkmk intern funktioniert oder
einfach, weil Sie gerne auf der Kommandozeile arbeiten!
Dieser Artikel zeigt Ihnen die wichtigsten Befehle, Dateien und Verzeichnisse auf der Kommandozeile von Checkmk.
2. Der Instanzbenutzer
2.1. Login als Instanzbenutzer
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:
root@linux# su - mysite
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):
root@linux# passwd mysite
Enter new UNIX password: *
Retype new UNIX password: *
passwd: password updated successfully
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
:
user@otherhost> ssh mysite@mycmkserver
mysite@localhost's password: ***
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.
2.2. Profil und Umgebungsvariablen
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).
OMD_SITE | Der Name der Instanz ( |
OMD_ROOT | Der Pfad des Instanzverzeichnisses ( |
PATH | Verzeichnisse, in denen ausführbare Programme gesucht werden. Checkmk hängt hier z.B. das |
LD_LIBRARY_PATH | Verzeichnisse, in denen nach zusätzlichen Binärbibliotheken gesucht wird. Durch diese Variable stellt Checkmk sicher, dass mit ausgelieferte Bibliotheken Vorrang vor den im normalen Betriebssystem installierten haben. |
PYTHONPATH | Suchpfad für Python-Module. Auch hier haben von Checkmk ausgelieferte Modulvarianten im Zweifel den Vorrang. |
PERL5LIB | Suchpfad für Perl-Module. Hier gilt das Gleiche wie bei Python. |
LANG | Spracheinstellung für Kommandozeilenbefehle. Diese Einstellung wird von der Spracheinstellung Ihrer Linux-Installation übernommen. Bei Prozessen der Instanz wird diese Variable aber automatisch entfernt! Die Sprache fällt dann auf die Systemsprache zurück (Englisch). Das betrifft auch andere regionale Einstellungen. Das Entfernen von |
Mit dem Befehl env
können Sie sich alle Umgebungsvariablen ausgeben lassen.
Ein kleines, hübsches |sort
dahinter, macht das Ganze etwas
übersichtlicher:
OMD[mysite]:~$ env | sort
HOME=/omd/sites/mysite
LANG=de_DE.UTF-8
LD_LIBRARY_PATH=/omd/sites/mysite/local/lib:/omd/sites/mysite/lib
LOGNAME=mysite
MAILRC=/omd/sites/mysite/etc/mail.rc
MAIL=/var/mail/mysite
MANPATH=/omd/sites/mysite/share/man:
MODULEBUILDRC=/omd/sites/mysite/.modulebuildrc
MP_STATE_DIRECTORY=/omd/sites/mysite/var/monitoring-plugins
NAGIOS_PLUGIN_STATE_DIRECTORY=/omd/sites/mysite/var/monitoring-plugins
OMD_ROOT=/omd/sites/mysite
OMD_SITE=mysite
PATH=/omd/sites/mysite/lib/perl5/bin:/omd/sites/mysite/local/bin:/omd/sites/mysite/bin:/omd/sites/mysite/local/lib/perl5/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
PERL5LIB=/omd/sites/mysite/local/lib/perl5/lib/perl5:/omd/sites/mysite/lib/perl5/lib/perl5:
PERL_MM_OPT=INSTALL_BASE=/omd/sites/mysite/local/lib/perl5/
PWD=/omd/sites/mysite
PYTHONPATH=/omd/sites/mysite/lib/python:/omd/sites/mysite/local/lib/python
SHELL=/bin/bash
SHLVL=1
TERM=xterm
USER=mysite
_=/usr/bin/env
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
:
OMD[mysite]:~$ tr \\0 \\n < /proc/13222/environ | sort
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:
# Custom environment variables
#
# Here you can set environment variables. These will
# be set in interactive mode when logging in as site
# user and also when starting the OMD processes with
# omd start.
#
# This file has shell syntax, but without 'export'.
# Better use quotes if your values contain spaces.
#
# Example:
#
# FOO="bar"
# FOO2="With some spaces"
#
*MY_SUPER_VAR=blabla123*
*MY_OTHER_VAR=10.88.112.17*
2.3. Anpassung der Shell und Ähnliches
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.
3. Die Verzeichnisstruktur
3.1. Trennung von Software und Daten
Folgendes Schaubild zeigt die wichtigsten Verzeichnisse einer
Checkmk-Installation mit einer Instanz mit dem Namen mysite
,
welche die Checkmk-Version 1.4.0p1
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
.
3.2. Das Instanzverzeichnis
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:
OMD[mysite]:[hilite]~$
Unterverzeichnisse des Instanzverzeichnisses werden relativ zur Tilde dargestellt:
OMD[mysite]:~$ cd var/log
OMD[mysite]:[hilite]~/var/log$
Direkt im Instanzverzeichnis befinden sich etliche Unterverzeichnisse,
die Sie mit ll
(Alias für ls -alF)
auflisten können:
OMD[mysite]:~$ ll
total 16
lrwxrwxrwx 1 mysite mysite 11 Jan 24 11:56 bin -> version/bin/
drwxr-xr-x 19 mysite mysite 4096 Jan 24 11:56 etc/
lrwxrwxrwx 1 mysite mysite 15 Jan 24 11:56 include -> version/include/
lrwxrwxrwx 1 mysite mysite 11 Jan 24 11:56 lib -> version/lib/
drwxr-xr-x 5 mysite mysite 4096 Jan 24 11:56 local/
lrwxrwxrwx 1 mysite mysite 13 Jan 24 11:56 share -> version/share/
drwxr-xr-x 2 mysite mysite 4096 Jan 24 09:57 tmp/
drwxr-xr-x 12 mysite mysite 4096 Jan 24 11:56 var/
lrwxrwxrwx 1 mysite mysite 29 Jan 24 11:56 version -> ../../versions/1.4.0p1/
Wie Sie sehen können, sind die Verzeichnisse bin
, lib
,
include
, 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.
Software | Daten | |
Verzeichnisse | bin include lib share | etc local tmp var |
Eigentümer |
| Instanzbenutzer ( |
Entsteht durch | Installation von Checkmk | Anlegen der Instanz, Konfiguration, Monitoring |
Physikalischer Ort | `/omd/versions/1.4.0p1/ | `/omd/sites/mysite/ |
Dateityp | symbolische Links | normale Verzeichnisse |
3.3. Die Software
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.4.0p1
liegen und über symbolische
Links vom Instanzverzeichnis aus erreichbar sind:
bin/ | Verzeichnis für ausführbare Programme. Dort liegt z.B. der Befehl |
lib/ | C-Bibliotheken, Plugins für Apache und Python und — im Unterverzeichnis |
share/ | Hauptteil der installierten Software. Sehr viele Komponenten befinden sich unter |
include/ | Enthält Include-Dateien für C-Programme, die mit den in |
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.
3.4. Die Daten
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:
etc/ | Konfigurationsdateien. Diese können Sie entweder von Hand oder mittels WATO editieren. Hinweis: Die Skripten unter |
var/ | Laufzeitdaten. Hier werden alle vom Monitoring erzeugten Daten abgelegt. Je nach Anzahl der überwachten Hosts und Services können immense Datenmengen zusammenkommen. Den größten Umfang haben dabei die aufgezeichnete Messdaten in den RRDs. |
tmp/ | Flüchtige Daten. Hier legen Checkmk und andere Komponenten temporäre Daten ab, die nicht persistiert werden müssen. Deswegen ist hier ein |
local/ | Eigene Erweiterungen. Unter |
3.5. Checkmk verändern und erweitern - die local
-Hierarchie
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:
OMD[mysite]:~$ tree -L 3 local
local
|-- bin
|-- lib
| |-- apache
| |-- icinga -> nagios
| |-- nagios
| | `-- plugins
| `-- python
`-- share
|-- check_mk
| |-- agents
| |-- alert_handlers
| |-- checkman
| |-- checks
| |-- inventory
| |-- mibs
| |-- notifications
| |-- pnp-rraconf
| |-- pnp-templates
| |-- reporting
| `-- web
|-- diskspace
|-- doc
| `-- check_mk
|-- dokuwiki
| `-- htdocs
|-- icinga
| `-- htdocs
|-- nagios
| `-- htdocs
|-- nagvis
| `-- htdocs
`-- snmp
`-- mibs
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:
Kopieren Sie die gewünschte Datei in das passende Verzeichnis unter
local
.Ändern Sie diese Datei.
Starten Sie betroffenen Dienste neu, damit die Änderung wirksam wird.
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.
3.6. Logdateien
Die Logdateien werden bei Checkmk unterhalb des bereits erwähnten
Datenverzeichnis var/
abgelegt. Hier finden
Sie zu allen Komponenten das entsprechende Logfile:
OMD[mysite]:~$ ll -R var/log/
var/log/:
total 48
-rw-r--r-- 1 mysite mysite 759 Sep 21 16:54 alerts.log
drwxr-xr-x 2 mysite mysite 4096 Sep 21 16:52 apache/
-rw-r--r-- 1 mysite mysite 8603 Sep 21 16:54 cmc.log
-rw-r--r-- 1 mysite mysite 313 Sep 21 16:54 liveproxyd.log
-rw-r--r-- 1 mysite mysite 62 Sep 21 16:54 liveproxyd.state
drwxr-xr-x 2 mysite mysite 4096 Sep 20 13:44 mkeventd/
-rw-r--r-- 1 mysite mysite 676 Sep 21 16:54 mkeventd.log
-rw-r--r-- 1 mysite mysite 310 Sep 21 16:54 mknotifyd.log
-rw-r--r-- 1 mysite mysite 327 Sep 21 16:54 notify.log
-rw-r--r-- 1 mysite mysite 458 Sep 21 16:54 rrdcached.log
-rw-r--r-- 1 mysite mysite 0 Sep 21 16:52 web.log
var/log/apache:
total 32
-rw-r--r-- 1 mysite mysite 26116 Sep 21 16:54 access_log
-rw-r--r-- 1 mysite mysite 841 Sep 21 16:54 error_log
-rw-r--r-- 1 mysite mysite 0 Sep 22 10:21 stats
var/log/mkeventd:
total 0
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:
cmc_log_rrdcreation = None
notification_logging = 1
cmc_log_levels = {
'cmk.alert' : 5,
'cmk.carbon' : 5,
'cmk.core' : 5,
'cmk.downtime' : 5,
'cmk.helper' : 5,
'cmk.livestatus' : 5,
'cmk.notification' : 5,
'cmk.rrd' : 5,
'cmk.smartping' : 5,
}
alert_logging = 1
Das Loglevel steigt mit der Größe der Zahl. Für notification_log
und alert_logging
gibt es zwei Abstufungen (1 und 2),
für cmc_log_levels
gibt es acht Abstufungen (0 bis 7). Für
cmc_log_rrdcreation
gibt es zwei Abstufungen und die Deaktivierung
('terse', 'full' und None).
Für das Log der Weboberfläche können Sie das Level entsprechend hier ändern:
log_levels = {
'cmk.web' : 50,
'cmk.web.auth' : 10,
'cmk.web.bi.compilation' : 30,
'cmk.web.ldap' : 20,
}
Das Loglevel steigt, anders als bei den anderen Logs, je kleiner die Zahl ist. Das geringste Loglevel ist 50 und kann in Zehnerschritten nach unten gesetzt werden. 10 entspricht dann dem höchsten Loglevel.
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:
liveproxyd_log_levels = {'cmk.liveproxyd': 30}
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.
4. Der Befehl cmk
Neben dem wichtigen Befehl omd
, welcher zum Starten und Stoppen
von Instanzen, zur Grundkonfiguration der Komponenten und dem Starten eines
Softwareupdates dient, ist cmk
der wichtigste Befehl.
Mit diesem können Sie eine Konfiguration für den Monitoringkern erzeugen,
Checks von Hand ausführen, eine Serviceerkennung durchführen und vieles mehr.
4.1. Allgemeine Optionen von cmk
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:
OMD[mysite]:~$ cmk --help
WAYS TO CALL:
cmk [-n] [-v] [-p] HOST [IPADDRESS] check all services on HOST
cmk -I [HOST ..] discovery - find new services
cmk -II ... renew discovery, drop old services
cmk -N [HOSTS...] output Nagios configuration
cmk -B create configuration for core
...
Einige Optionen funktionieren immer — egal mit welchem Modus Sie den Befehl aufrufen:
-v | „Verbose“: Veranlasst |
-vv | „Very verbose“: das Ganze noch etwas ausführlicher. |
--debug | Falls es zu einem Fehler kommt, sorgt diese Option dafür, dass dieser nicht mehr abgefangen, sondern die ursprüngliche Python-Exception vollständig angezeigt wird. Das kann den Entwicklern als wichtige Information dienen, wo genau im Programm der Fehler auftritt. Auch wird es Ihnen sehr helfen, Fehler in selbstgeschriebenen Check-Plugins zu lokalisieren. Falls Sie bei einem Aufruf von |
4.2. Befehle für den Monitoringkern
Die Checkmk Enterprise Editions verwenden als Monitoringkern den 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:
Nagios | CMC | |
---|---|---|
Konfigdatei | etc/nagios/conf.d/check_mk_objects.cfg | var/check_mk/core/config |
Dateiart | Textdatei mit | Komprimierte und optimierte Binärdatei |
Aktivierung | Neustart des Kerns | Befehl an den Kern zum Neuladen der Konfiguration |
Befehl | cmk -R | cmk -O |
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:
Kurz | Lang | Wirkung |
---|---|---|
cmk -R | --restart | Erzeugt eine neue Konfiguration für den Kern und startet diesen dann neu (analog zu |
cmk -O | --reload | Erzeugt die Konfiguration für den Kern und lädt diese ohne einen Neustart im laufenden Betrieb (analog zu Achtung: Bei Nagios als Kern funktioniert diese Option zwar auch, kann aber zu Speicherlöchern und anderen Instabilitäten führen. Außerdem wird dort ohnehin kein echter Reload ausgeführt, sondern nur der Prozess quasi innerlich runter- und wieder hochgefahren. |
cmk -C | --compile | Nur bei Nagios sinnvoll: Erzeugt die vorkompilierten Python-Dateien unter |
cmk -U | --update | Erzeugt die Konfiguration für den Kern, ohne diese zu aktivieren. Bei Nagios wird dabei zusätzlich automatisch auch der Schritt |
cmk -B | Erzeugt nur die Konfiguration für den Kern, ohne diese zu aktivieren. Bei Nagios als Kern wird hier | |
cmk -N | Nur Nagios: Gibt zu Diagnosezwecken die zu erzeugende Konfiguration auf der Standardausgabe aus, ohne die eigentliche Konfigurationsdatei zu ändern. Sie können dabei den Namen eines Hosts angeben, um nur die Konfiguration dieses Hosts zu sehen (z.B. |
Zusammengefasst bedeutet das: Wenn Sie von Hand die Checkmk-Konfiguration anpassen und die Änderungen aktivieren möchten, benötigen Sie anschließend bei Nagios:
OMD[mysite]:~$ cmk -R
Und beim CMC:
OMD[mysite]:~$ cmk -O
4.3. Checks von Hand ausführen
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:
-v | Checkergebnisse ausgeben: Ohne diese Option sehen nur Sie die Ausgabe des Checkmk-Services selbst und nicht die Resultate der anderen Services. |
-n | Trockenlauf: Ergebnisse nicht an den Kern übermitteln, Performancecounter nicht aktualisieren. |
OMD[mysite]:~$ cmk -nv myserver123
Check_MK version 2017.01.16
CPU load OK - 15 min load 0.22 at 8 Cores (0.03 per Core)
CPU utilization OK - user: 1.2%, system: 0.8%, wait: 0.0%, steal: 0.0%, guest: 0.0%, #
Disk IO SUMMARY [green]#OK - Utilization: 0.1%, Read: 0.00 B/s, Write: 52.21 kB/s, Average Wa
Filesystem / WARN - 82.0% used (177.01 of 215.81 GB), (warn/crit at 80.00/90.00%),
Interface 2 OK - [wlan0] (up) MAC: 6c:40:08:92:e6:54, speed unknown, in: 1.78 kB/
Kernel Context Switches OK - 2283/s
Kernel Major Page Faults OK - 0/s
Kernel Process Creations OK - 10/s
Memory OK - RAM used: 2.24 GB of 15.58 GB (14.4%),
Mount options of / OK - mount options exactly as expected
NTP Time OK - sys.peer - stratum 2, offset 16.62 ms, jitter 5.19 ms, last reac
Nullmailer Queue OK - Mailqueue length is 4 having a size of 28.00 B
Number of threads OK - 532 threads
TCP Connections OK - ESTABLISHED: 35, TIME_WAIT: 4, LISTEN: 14
Temperature Zone 0 OK - 56.0 °C
Uptime OK - up since Thu Jan 26 09:59:14 2017 (0d 05:55:35)
OK - Agent version 1.4.0i4, execution time 0.1 sec|execution_time=0.128 user_time=0.010 system_time=0.000
Hinweise dazu:
Verwenden Sie diesen Befehl nicht bei produktiv überwachten Hosts, welche Logfilemonitoring verwenden. Logmeldungen werden vom Agenten nur einmal gesendet. Es kann Ihnen passieren, dass Ihr manueller
cmk -nv
diese „erwischt“ und sie dann für das Monitoring verloren sind. Verwenden Sie in diesem Fall die Option--no-tcp
.Wenn Sie Nagios als Kern verwenden und
-n
weglassen, führt das zu einer sofortigen Aktualisierung der Checkergebnisse im Kern und in der GUI.Der Befehl ist nützlich beim Entwickeln eigener Check-Plugins, weil so ein schnellerer Test möglich ist als über die GUI. Falls der Check in einen Fehler läuft und UNKNOWN wird, hilft die Option
--debug
die genaue Stelle im Code zu finden.
Folgende Optionen beeinflussen den Befehl:
--cache | Falls der Host bereits vom Kern aktiv überwacht wird, werden die gecachten Agentendaten des Hosts unter |
--no-tcp | Ist wie |
--usewalk | Für SNMP-Hosts: Verwendet anstatt eines Zugriffs auf den SNMP-Agenten einen gespeicherten SNMP-Walk, der zuvor mit |
--checks=df,uptime | Beschränkt die Ausführung auf die Check-Plugins |
4.4. Serviceerkennung von Hand ausführen
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:
OMD[mysite]:~$ cmk -vI myserver123
Dabei gibt es zwei Modi:
cmk -I | Findet und ergänzt fehlende Services. |
cmk -II | Verwirft alle zuvor erkannten Services und führt die Erkennung komplett neu durch. |
4.5. Hilfsbefehle
Der Befehl cmk
kennt auch einige Modi, die allgemein zur Diagnose und
Fehlersuche nützlich sind. Hier ist eine Übersicht:
cmk -d myserver123 | Daten vom Checkmk-Agenten holen und ausgeben. |
cmk -D myserver123 | Konfiguration von Hosttags, Gruppen und Services anzeigen. |
cmk --paths | Wichtige Verzeichnisse von Checkmk: Was liegt wo? |
cmk -X | Konfiguration in |
cmk -l | Namen aller konfigurierten Hosts ausgeben. |
cmk --list-tag mytag | Namen aller konfigurierten Hosts mit Tag |
cmk -L | Liste aller Check-Plugins ausgeben. |
cmk -m | Katalog der Dokumentation der Check-Plugins interaktiv aufrufen. |
cmk -M df | Dokumentation des Check-Plugins |
Im Folgenden zeigen wir, wie Sie die Befehle verwenden können. Die Beispielausgaben sind meist gekürzt dargestellt.
Agentenausgabe holen
cmk -d
holt die Ausgabe des Checkmk-Agenten eines Hosts und zeigt
sie an. Das ist nicht immer das Gleiche wie ein telnet
zum Port
6556 des Zielhosts, da hier auch eventuelle Einstellungen zu
Datasource programs, eine Verschlüsselung der Agentenausgabe und andere Dinge
berücksichtigt werden. Die Agentendaten werden bei cmk -d
also
auf dem gleichen Weg geholt wie während des eigentlichen Monitorings.
OMD[mysite]:~$ cmk -d myserver123
<<<check_mk>>>
Version: 1.4.0i4
AgentOS: linux
Hostname: Klappfisch
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins
LocalDirectory: /usr/lib/check_mk_agent/local
OnlyFrom:
<<<df>>>
udev devtmpfs 8155492 4 8155488 1% /dev
tmpfs tmpfs 1634036 1208 1632828 1% /run
/dev/sda5 ext4 226298268 175047160 39732696 82% /
none tmpfs 4 0 4 0% /sys/fs/cgroup
Sie können cmk -d
sogar mit dem Namen oder der IP-Adresse eines Hosts aufrufen,
der nicht im Monitoring angelegt ist. In diesem Fall werden für den Host Standardeinstellungen
angenommen (also TCP-Verbindung zu Port 6556, keine Verschlüsselung, kein Datenquellenprogramm).
Konfigurationsübersicht eines Hosts
cmk -D
zeigt für einen bestimmten Host die konfigurierten Services,
Hostmerkmale und andere Attribute. Da die Liste der Services sehr breit ist,
kann das Ganze im Terminal etwas unübersichtich aussehen. Schicken Sie die
Ausgabe durch less -S
um einen Umbruch zu vermeiden:
OMD[mysite]:~$ cmk -D myserver123 | less -S
myserver123
Addresses: 10.17.1.111
Tags: /wato/, cmk-agent, lan, prod, tcp, wato
Host groups:
Contact groups: all
Type of agent: TCP (port: 6556)
Is aggregated: no
Services:
checktype item params
---------------- ----------------- ------------
cpu.loads None (5.0, 10.0)
kernel.util None {}
Pfadübersicht von Checkmk
Der Befehl cmk --paths
zeigt Ihnen, in welchen Verzeichnissen Checkmk
welche Dinge erwartet. Diese Liste umfasst nicht das komplette
Checkmk-System, sondern nur Dinge, mit denen das Kommandozeilentool cmk
selbst arbeitet. Trotzdem hilft es manchmal, Dinge schneller zu finden:
OMD[mysite]:~$ cmk --paths
Files copied or created during installation
Main components of check_mk : /omd/sites/mysite/share/check_mk/modules/
Checks : /omd/sites/mysite/share/check_mk/checks/
Notification scripts : /omd/sites/mysite/share/check_mk/notifications/
Inventory plugins : /omd/sites/mysite/share/check_mk/inventory/
Agents for operating systems : /omd/sites/mysite/share/check_mk/agents/
Documentation files : /omd/sites/mysite/share/doc/check_mk/
Check_MK's web pages : /omd/sites/mysite/share/check_mk/web/
Check manpages (for check_mk -M) : /omd/sites/mysite/share/check_mk/checkman/
Binary plugins (architecture specific) : /omd/sites/mysite/lib/
Templates for PNP4Nagios : /omd/sites/mysite/share/check_mk/pnp-templates/
Configuration files edited by you
Directory that contains main.mk : /omd/sites/mysite/etc/check_mk/
Directory containing further *.mk files : /omd/sites/mysite/etc/check_mk/conf.d/
Konfigurationscheck
Wenn Sie von Hand Konfigurationsdateien in etc/check_mk/
editieren, ist der
Konfigurationscheck durch ein cmk -X
praktisch. Er zeigt nicht nur Fehler in
der Python-Syntax, sondern auch falsch geschriebene oder nicht definierte Variablen:
OMD[mysite]:~$ cmk -X
Invalid configuration variable 'foo'
--> Found 1 invalid variables
If you use own helper variables, please prefix them with _.
Konfigurierte Hosts ausgeben
Der Befehl cmk -l
listet einfach die Namen aller konfigurierten
Hosts auf:
OMD[mysite]:~$ cmk -l
myserver123
myserver124
myserver125
Da die Daten „nackt“ und ohne Verzierungen ausgegeben werden, können Sie sie leicht in Skripten nutzen. Zum Beispiel können Sie damit leicht eine Schleife über alle Hostnamen bauen:
OMD[mysite]:~$ for host in $(cmk -l) ; do echo "Host: $host" ; done
Host: myserver123
Host: myserver124
Host: myserver125
Wenn Sie jetzt anstelle des echo
einen Befehl einsetzen, der
etwas Sinnvolles macht, kann das wirklich nützlich sein.
Der Aufruf cmk --list-tag
gibt ebenfalls Hostnamen aus, bietet dabei aber
die Möglichkeit, nach Merkmalen zu filtern. Geben Sie
einfach ein Hosttag an und Sie erhalten alle Hosts, die dieses Tag besitzen.
Folgendes Beispiel listet alle Host auf, die per SNMP überwacht werden:
OMD[mysite]:~$ cmk --list-tag snmp
myswitch01
myswitch02
myswitch03
Geben Sie mehrere Tags an, so werden diese per UND verknüpft. Folgendes liefert alle Hosts, die gleichzeitig per SNMP und normalem Agent überwacht werden:
OMD[mysite]:~$ cmk --list-tag snmp tcp
Übersicht über die Check-Plugins
Checkmk liefert eine große Zahl von fertigen Plugins mit aus. In jedem Release kommen
etliche dazu und Version 1.4.0 umfasst bereits rund 1.300 Plugins. Drei der Aufrufarten
geben Ihnen Zugriff auf die Liste der vorhandenen Plugins. Dabei werden auch solche
aufgelistet, welche Sie eventuell per Hand unterhalb von local/
nachinstalliert
haben.
cmk -L
gibt in einer Tabelle alle Plugins mit Namen, Typ und Beschreibung
aus. Beim Typ gibt es folgende Möglichkeiten:
tcp | Wertet Daten eines Checkmk-Agenten aus. Dieser wird (normalerweise) per TCP Port 6556 abgerufen — daher die Abkürzung. |
snmp | Dient zur Überwachung von Geräten via SNMP. |
active | Ruft für die Überwachung ein Nagios-kompatibles Plugin nach klassischer Art auf. Hier übernimmt Checkmk eigentlich nur die Konfiguration. |
Natürlich können Sie in der Liste einfach mit grep
filtern, wenn Sie nach etwas
Bestimmten suchen:
OMD[mysite]:~$ cmk -L | grep f5
f5_bigip_chassis_temp snmp F5 Big-IP: Chassis temperature
f5_bigip_cluster snmp F5 Big-IP: Cluster state, up to firmware version 10
f5_bigip_cluster_status snmp F5 Big-IP: active/active or passive/active cluster status
f5_bigip_cluster_v11 snmp F5 Big-IP: Cluster state for firmware version >= 11
f5_bigip_conns snmp F5 Big-IP: number of current connections
f5_bigip_cpu_temp snmp F5 Big-IP: CPU temperature
f5_bigip_fans snmp F5 Big-IP: System fans
f5_bigip_interfaces snmp F5 Big-IP: Special Network Interfaces
f5_bigip_pool snmp F5 Big-IP: Load Balancing Pools
f5_bigip_psu snmp F5 Big-IP: Power Supplies
f5_bigip_snat snmp F5 Big-IP: Source NAT
f5_bigip_vserver snmp F5 Big-IP: Virtual servers
Wenn Sie zu einem der Plugins mehr Information möchten, können Sie dessen Dokumentation
mit cmk -M
aufrufen:
OMD[mysite]:~$ cmk -M f5_bigip_pool
Das ergibt dann folgende Ausgabe:

Mit einem cmk -m
ohne weitere Angaben kommen Sie in den kompletten Katalog
aller Check-Manpages.
OMD[mysite]:~$ cmk -m
Hier können Sie interaktiv navigieren:


5. Konfiguration ohne WATO
5.1. Wo ist die Doku?
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 vier Teile zerlegt und in kleiner Schrift gesetzt:

Die entsprechende Passage dazu in der Konfigurationsdatei sieht (etwas hübscher formatiert) so aus:
{ 'inodes_levels' : (10.0, 5.0),
'levels' : (80.0, 90.0),
'levels_low' : (50.0, 60.0),
'magic' : 0.8,
'magic_normsize' : 20,
'show_inodes' : 'onlow',
'show_levels' : 'onmagic',
'show_reserved' : True,
'trend_mb' : (100, 200),
'trend_perc' : (5.0, 10.0),
'trend_perfdata' : True,
'trend_range' : 24,
'trend_showtimeleft' : True,
'trend_timeleft' : (12, 6)},
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:
Erzeugen Sie eine Testinstanz von Checkmk.
Konfigurieren Sie dort die gewünschten Parameter mit WATO.
Suchen Sie von WATO dabei bearbeitete Konfigurationsdatei (dazu gleich mehr).
Übernehmen Sie die exakte Syntax des betroffenen Abschnitts aus dieser Datei in Ihr Produktivsystem.
Sie müssen also nur wissen, in welche Datei WATO was schreibt.
5.2. Welche Datei ist die richtige?
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:
OMD[mysite]:~$ find etc/ -mmin -1 -type f
etc/check_mk/conf.d/wato/rules.mk
Die Basis der Konfiguration ist immer das Verzeichnis etc/check_mk
.
Darunter gibt es eine Aufteilung in verschieden 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 angeasst und ist nur für manuelle Änderungen
vorgesehen.
Domäne | Verzeichnis | Hauptdatei | Änderungen aktivieren |
---|---|---|---|
Monitoring | conf.d/ | main.mk |
|
multisite.d/ | multisite.mk | automatisch | |
mkeventd.d/ | mkeventd.mk | omd reload mkeventd | |
mknotifyd.d/ | automatisch |
5.3. Zusammenarbeit mit WATO
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:
Möchten Sie, dass Ihre manuelle Konfiguration in WATO sichtbar und editierbar wird, so verwenden Sie die exakt gleichen Pfade wie WATO.
Möchten Sie, dass Ihre Konfiguration einfach nur wirksam, aber in WATO nicht sichtbar wird, so verwenden Sie eigene Dateien außerhalb von
wato/
.Möchten Sie, dass Ihre Konfiguration in WATO sichtbar, aber nicht änderbar wird, so können Sie manche der Dateien sperren.
Sperren von WATO-Dateien
Ein häufiger Grund für das Erzeugen von Konfigurationsdateien ohne WATO ist
der Import von zu überwachenden Hosts aus einer CMDB. Im Gegensatz zur Methode
über die Web-API erzeugen Sie hier mit einem Skript direkt die
Ordner für die Hosts und darin jeweils die Datei hosts.mk
und eventuell
auch die Datei .wato
, welche die Ordnereigenschaften enthält.
Wenn dieser Import nicht nur einmalig geschieht sondern regelmäßig wiederholt wird, weil die CMDB das führende System ist, wäre es sehr ungünstig, wenn Ihre Benutzer über WATO irgendwelche Änderungen an den Dateien machen würden. Denn diese gingen dann beim nächsten Export verloren.
Eine hosts.mk
-Datei können Sie sperren, indem Sie folgende Zeile
einbauen:
# Created by WATO
# encoding: utf-8
_lock = True
Beim Zugriff auf den entsprechenden Ordner in WATO erhält der Benutzer folgende Information:

Sämtliche Aktionen, welche eine Änderung an der Datei hosts.mk
erfordern würden, sind in der GUI dann gesperrt. Das betrifft übrigens
nicht die Serviceerkennung. Die konfigurierten Services eines Hosts
werden unter var/check_mk/autochecks/
gespeichert.
Sie können auch die Ordnereigenschaften sperren. Dies geschieht durch
einen Eintrag im dict
in der Datei .wato
des
Ordners:
{'attributes': {},
'lock': True,
'lock_subfolders': False,
'num_hosts': 1,
'title': u'Main Directory'}
Setzen Sie auch noch das Attribut lock_subfolders
, so verhindern
Sie das Anlegen und Löschen von Unterordnern.
Das Sperren von anderen Dateien — wie z.B. rules.mk
— ist aktuell
nicht möglich.
5.4. Die Syntax der Dateien
Rein formal gilt für alle Konfigurationsdateien von Checkmk, dass diese in Python-2-Syntax geschrieben sind. Dabei gibt es zwei Arten von Dateien:
solche, die von Python wie ein Skript ausgeführt werden, wozu z.B.
hosts.mk
gehört undsolche, die von Python als Wert eingelesen werden, wozu z.B.
.wato
gehört.
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:
# encoding: utf-8
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.