Check_MK auf der Kommandozeile

Letzte Aktualisierung: 06. April 2017


1. Warum Kommandozeile?

Wenn ein Check_MK-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 Check_MK,
  • beim Programmieren und Testen von eigenen Erweiterungen,
  • um zu verstehen, wie Check_MK 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 Check_MK.

2. Der Instanzbenutzer

2.1. Login als Instanzbenutzer

Bei der Administration von Check_MK 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 Check_MK-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 Check_MK-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 (mysite). In eigenen Skripten sollten Sie anstelle eines hartkodierten Instanznamens immer diese Variable verwenden (z. B. in der Shell mit $OMD_SITE). So können Sie das Skipt unverändert auch in andere Instanzen übernehmen.
OMD_ROOT Der Pfad des Instanzverzeichnisses (/omd/sites/mysite).
PATH Verzeichnisse, in denen ausführbare Programme gesucht werden. Check_MK hängt hier z. B. das bin/ der Instanz mit ein. Bei Namensgleichheit haben Check_MK-Programme Vorrang. Das ist z. B. wichtig beim Befehl mail, den Check_MK in einer ganz bestimmten Version mit ausliefert.
LD_LIBRARY_PATH Verzeichnisse, in denen nach zusätzlichen Binärbibliotheken gesucht wird. Durch diese Variable stellt Check_MK sicher, dass mit ausgelieferte Bibliotheken Vorrang vor den im normalen Betriebssystem installierten haben.
PYTHONPATH Suchpfad für Python-Module. Auch hier haben von Check_MK 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 LANG ist sehr wichtig, denn einige klassische Nagios-Plugins verwenden sonst z. B. bei deutscher Spracheinstellung ein Komma anstelle eines Punkts als Dezimaltrenner. Ihre Ausgabe könnte dann nicht sauber ausgewertet werden.

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:

etc/environment
# 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 Check_MK-Installation mit einer Instanz mit dem Namen mysite, welche die Check_MK-Version 1.4.0p1 verwendet:

Die Basis bildet das Verzeichnis /omd. Alle Dateien von Check_MK 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 Check_MK 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 Instanz­verzeichnis 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]:~$

Unterverzeichnisse des Instanzverzeichnisses werden relativ zur Tilde dargestellt:

OMD[mysite]:~$ cd var/log
OMD[mysite]:~/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 root Instanzbenutzer (mysite)
Entsteht durch Installation von Check_MK 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 cmk.
lib/ C-Bibliotheken, Plugins für Apache und Python und – im Unterverzeichnis nagios/plugins klassische Monitoringplugins, die meist in C oder Perl geschrieben sind.
share/ Hauptteil der installierten Software. Sehr viele Komponenten befinden sich unter share/check_mk – unter anderem auch die weit über 1.300 Checkplugins.
include/ Enthält Include-Dateien für C-Programme, die mit den in lib/ befindlichen Bibliotheken gelinkt werden sollen. Dieses Verzeichnis ist nicht wichtig und wird nur verwendet, wenn Sie selbst C-Programme übersetzen möchten.

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. Check_MK 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 etc/init.d sind zwar - weil sie unter etc/ liegen – auch „Konfigurationsdateien“. Dies ist in Anlehnung an das gleiche Schema, das Sie auf jedem Linux-System unter /etc/init.d/ finden. Aber wir empfehlen, diese Skripten nicht zu ändern, da dies zu Konflikten bei einem Softwareupdate führen kann. Änderungen an den Skripten sind nicht notwendig.
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 Check_MK und andere Komponenten temporäre Daten ab, die nicht persistiert werden müssen. Deswegen ist hier ein tmpfs gemountet. Das ist ein Dateisystem, welches die Daten im RAM verwaltet und deswegen keinerlei Disk-IO erzeugt. Beim Neustart des Rechners gehen alle Daten in tmp/ verloren! Ein Stoppen und Starten der Instanz löscht die Daten nicht.

Unter tmp/run finden Sie Dateien wie Sockets, Pipes und PID-Dateien, welche zur Kommunikation und Verwaltung der Serverprozesse notwendig sind.

Verwenden Sie tmp/ nicht für die Ablage von eigenen Dateien. Da dieses Verzeichnis im RAM liegt, ist der Platz begrenzt. Legen Sie eigene Dinge direkt in das Instanzverzeichnis oder in ein eigenes Unterverzeichnis davon.

local/ Eigene Erweiterungen. Unter local/ finden Sie eine „Schattenhierarchie“ der Softwareverzeichnisse bin/, lib/ und share/. Diese sind für Ihre eigenen Änderungen oder Erweiterungen der Software vorgesehen.

Auch hier gilt: Legen Sie unter local/ auf keinen Fall Testdateien, Logfiles, Sicherheitskopien oder Sonstiges an, was dort nicht hingehört. Check_MK könnte versuchen, diese Dateien als Teil der Software auszuführen. Auch werden die Dateien beim verteilten Monitoring auf alle Slaves verteilt.

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

  1. Kopieren Sie die gewünschte Datei in das passende Verzeichnis unter local.
  2. Ändern Sie diese Datei.
  3. 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 Check_MK 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:

~/etc/check_mk/conf.d/wato/global.mk
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:

~/etc/check_mk/multisite.d/wato/global.mk
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:

~/etc/check_mk/liveproxyd.d/wato/global.mk
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 cmk zu einer ausführlichen Ausgabe, was er gerade macht.
-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 Checkplugins zu lokalisieren.

Falls Sie bei einem Aufruf von cmk auf einen Fehler stoßen, den Sie dem Support oder als Feedback melden möchten, rufen Sie bitte den gleichen Befehl nochmal mit --debug auf und fügen den Python-Trace in Ihre Email ein.

4.2. Befehle für den Monitoringkern

Die  Check_MK Enterprise Edition verwendet als Monitoringkern den CMC, bei der  Check_MK 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 define-Befehlen 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 omd restart core). Das ist die bei Nagios vorgesehende Methode.
cmk -O --reload Erzeugt die Konfiguration für den Kern und lädt diese ohne einen Neustart im laufenden Betrieb (analog zu omd reload core). Das ist die beim CMC empfohlene Variante.

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 var/check_mk/precompiled neu, welche die Ausführung von Check_MK während des Monitorings stark beschleunigen. Dieser Vorgang ist in cmk -R mit enthalten.
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 -C ausgeführt.
cmk -B Erzeugt nur die Konfiguration für den Kern, ohne diese zu aktivieren. Bei Nagios als Kern wird hier cmk -C nicht mit ausgeführt.
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. cmk -N myserver123).

Zusammengefasst bedeutet das: Wenn Sie von Hand die Check_MK-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 Check_MK befasst sich mit der Ausführung von Check_MK-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 Check_MK-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      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 Checkplugins, 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 gedachten Agentendaten des Hosts unter tmp/check_mk/cache verwendet und der Agent nicht kontaktiert. Das vermeidet z. B. oben beschriebenes Problem mit den Logdateien.
--no-tcp Ist wie --cache, bricht allerdings mit einem Fehler ab, wenn keine Cachedatei da ist oder diese nicht aktuell ist. So können Sie einen Zugriff auf den Agenten in jedem Fall unterbinden.
--usewalk Für SNMP-Hosts: Verwendet anstatt eines Zugriffs auf den SNMP-Agenten einen gespeicherten SNMP-Walk, der zuvor mit cmk --snmpwalk myserver123 gezogen wurde. Diese Walks liegen unter var/check_mk/snmpwalks.
--checks=df,uptime Beschränkt die Ausführung auf die Checkplugins df und uptime. Im Falle von SNMP-Hosts werden auch nur die dafür benötigten Daten geholt. Diese Option ist praktisch, wenn Sie eigene Checkplugins entwickeln und nur diese testen möchten.

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.

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

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 Check_MK-Agenten holen und ausgeben.
cmk -D myserver123 Konfiguration von Hosttags, Gruppen und Services anzeigen.
cmk --paths Wichtige Verzeichnisse von Check_MK: Was liegt wo?
cmk -X Konfiguration in main.mk und etc/check_mk/conf.d auf Syntax prüfen.
cmk -l Namen aller konfigurierten Hosts ausgeben.
cmk --list-tag mytag Namen aller konfigurierten Hosts mit Tag mytag ausgeben.
cmk -L Liste aller Checkplugins ausgeben.
cmk -m Katalog der Dokumentation der Checkplugins interaktiv aufrufen.
cmk -M df Dokumentation des Checkplugins df anzeigen.

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

Der Befehl cmk --paths zeigt Ihnen, in welchen Verzeichnissen Check_MK welche Dinge erwartet. Diese Liste umfasst nicht das komplette Check_MK-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 Checkplugins

Check_MK 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 Check_MK-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 Check_MK 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 Check_MK 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 Check_MK 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 Checkplugin, welches in Check_MK 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:

  1. Erzeugen Sie eine Testinstanz von Check_MK.
  2. Konfigurieren Sie dort die gewünschten Parameter mit WATO.
  3. Suchen Sie von WATO dabei bearbeitete Konfigurationsdatei (dazu gleich mehr).
  4. Ü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 cmk -O, bzw. cmk -R
GUI multisite.d/ multisite.mk automatisch
Event Console mkeventd.d/ mkeventd.mk omd reload mkeventd
Alarmspooler 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:

hosts.mk
# 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:

.wato
{'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 Check_MK, 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 und
  • solche, 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:

somefile.mk
# 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.