1. Einleitung

Linux-Systeme können Sie mit Checkmk besonders gut überwachen. Das liegt weniger daran, dass sich das Checkmk-Entwicklerteam auf Linux „zuhause“ fühlt, sondern vielmehr daran, dass Linux ein sehr offenes System ist und zahlreiche gut dokumentierte und einfach abzufragende Schnittstellen für eine detaillierte Überwachung bereitstellt.
Natürlich ist die Installation eines Monitoring-Agenten unumgänglich, denn die meisten der Schnittstellen sind per se nicht über das Netzwerk erreichbar. Deswegen hat Checkmk einen eigenen Agenten für die Überwachung von Linux. Dieser ist einfach zu installieren und sparsam im Umgang mit Ressourcen.
Der Checkmk-Agent für Linux ist:
minimalistisch, denn er benötigt nur wenig CPU, RAM und Plattenplatz,
transparent, denn er ist ein Shellskript, in dem Sie sehen können, welche Befehle er aufruft, und
sicher, denn er erlaubt keinerlei Zugriffe aus dem Netzwerk.
Der Agent besteht aus einem simplen Shellskript, das nach
/usr/bin/check_mk_agent
installiert wird und der Reihe nach
vorhandene Systembefehle aufruft, um Daten für das Monitoring
zu ermitteln. Seine Ausgabe stellt er entweder per xinetd
oder
systemd
an TCP-Port 6556 bereit oder er wird alternativ per SSH
aufgerufen. Und wenn Ihnen beides nicht gefällt, können Sie
auch eigene Methoden implementieren, wie Checkmk die Daten vom Agenten
bekommen soll.
Monitoringinformationen, die der Agent nicht von Haus aus liefert, können Sie in Form von Agentenplugins hinzufügen. In den Enterprise Editions können Sie alle Einstellungen und Plugins zusammen mit dem Agenten in der Agentenbäckerei zu einem RPM oder DEB-Paket paketieren, das mit einem einzigen Befehl installiert und oder sogar vollautomatisch aktualisiert werden kann.
2. Installation
2.1. Verschiedene Möglichkeiten
Checkmk bietet Ihnen für die Installation des Linux-Agenten verschiedene Wege — von der manuellen Installation der Einzelteile bis hin zum vollautomatischen Deployment. Manche davon stehen nur in den Enterprise Editions zur Verfügung:
Methode | Beschreibung | CRE | CEE |
---|---|---|---|
Mitgeliefertes RPM/DEB-Paket | Einfache Installation eines Standard-Agenten mit manueller Konfiguration über Konfigurationsdateien. | X | X |
RPM/DEB-Paket aus der Agentenbäckerei | Konfiguration über die GUI, individuelle Konfiguration pro Host möglich. | X | |
Das Paket aus der Agentenbäckerei wird erstmalig von Hand oder per Skript installiert und von da an automatisch aktualisiert. | X | ||
Manuelle Installation | Sie kopieren die Einzeldateien ohne Paket auf das Zielsystem und setzen | X | X |
2.2. Installation per RPM/DEB-Paket
In der Checkmk Raw Edition finden Sie die Linux-Pakete des Agenten über Setup > Agents > Linux.
In den Enterprise Editions gelangen Sie im Setup-Menü über Agents > Windows, Linux, Solaris, AIX zunächst in die Agentenbäckerei.
Von dort aus kommen Sie mit dem Menüpunkt Related > Linux, Solaris, AIX files zur Liste der Agentendateien:

Alles was Sie brauchen, ist gleich im ersten Kasten mit dem Namen Packaged Agents. Dort finden Sie fertige RPM- und DEB-Pakete für die Installation eines Linux-Agenten mit Standardeinstellungen.
Ob Sie RPM oder DEB benötigen, hängt von der Linux-Distribution ab, auf der Sie das Paket installieren möchten:
Paket | Endung | Installation auf |
---|---|---|
RPM | .rpm | Red Hat Enterprise Linux, Fedora, CentOS, openSUSE, SLES, Derivate davon |
DEB | .deb | Debian, Ubuntu, alle anderen DEB-basierten Distributionen |
Achtung: Im Kasten Agents finden Sie die reinen Agentenskripten für die manuelle Installation nach /usr/bin/
.
Verwenden Sie diese nur, wenn die paketierten Agenten bei Ihnen nicht funktionieren.
Exotische Linux-Distributionen
Auch wenn der Checkmk-Server nur Enterprise-Linux-Distributionen unterstützt, die deren Hersteller noch supported, ist der Checkmk-Agent hier viel genügsamer. Er unterstützt jede Linux-Distribution — selbst uralte „Dinosaurier“, auf denen noch ein Kernel der Version 2.4 läuft! Es kann dann zwar sein, dass nicht alle Plugins im Agenten korrekt laufen, aber die grundsätzliche Überwachung wird funktionieren.
Installation mit RPM
Die Installation des Agenten mit dem RPM-Paket ist sehr einfach:
Laden Sie das Agentenpaket mit der Endung
*.rpm
herunter.Kopieren Sie es mit
scp
, WinSCP oder anders auf das zu überwachende Zielsystem.Installieren Sie es dort als
root
mit dem Befehlrpm -U
.Installieren Sie noch das Paket
xinetd
von Ihrer Distribution nach, falls es nicht schon installiert ist.
Hier ein Beispiel für die Installation des Pakets:
root@linux# rpm -U check-mk-agent-2.0.0p42-1.noarch.rpm
Das -U
steht übrigens für „Update“, kann aber auch eine
Erstinstallation korrekt durchführen. Das bedeutet, dass Sie den gleichen
Befehl auch später für ein Update auf eine neue Version verwenden können.
Nach der Installation ist der Agent sofort aktiv und kann auf TCP Port 6556 abgefragt werden.
Installation mit DEB
Das Verfahren ist das gleiche wie bei RPM, nur die Befehle lauten anders. Installation und ein späteres Update des Agenten gehen gleichermaßen mit:
root@linux# dpkg -i check-mk-agent_2.0.0p42-1_all.deb
Paket per HTTP holen
Manchmal ist scp
oder WinSCP sehr umständlich. Sie können das Paket vom Checkmk-Server
auch direkt per HTTP auf das Zielsystem laden. Für diesen Zweck sind die Downloads der Agentendateien
bewusst ohne Anmeldung möglich. Immerhin enthalten die Dateien keine Geheimnisse. Jeder
kann sich Checkmk selbst herunterladen und installieren und so auf die Dateien
zugreifen.
Am einfachsten geht das mit wget
. Die URLs können Sie über den Browser ermitteln.
Wenn Sie den Namen des Pakets bereits kennen, können Sie die URL einfach selbst zusammensetzen.
Setzen Sie einfach /mysite/check_mk/agents/
vor den Dateinamen:
root@linux# wget http://mycmkserver/mysite/check_mk/agents/check-mk-agent-2.0.0p42-1.noarch.rpm
RPM hat sogar ein eingebautes wget
.
Hier können Sie Download und Installation in einem Schritt machen:
root@linux# rpm -U http://mycmkserver/mysite/check_mk/agents/check-mk-agent-2.0.0p42-1.noarch.rpm
Paket per REST-API holen
Die REST-API von Checkmk bietet seit dem Release 2.0.0p18 die folgenden Möglichkeiten Agentenpakete herunterzuladen:
Herunterladen eines gebackenen Agenten nach Hostname und Betriebssystem
Herunterladen eines gebackenen Agenten nach Hash des Agenten und Betriebssystem
Herunterladen des mitgelieferten Agenten
Das mitgelieferte DEB-Paket des Linux-Agenten lässt sich beispielsweise wie folgt holen:
curl -OJG 'mycmkserver/mysite/check_mk/api/1.0/domain-types/agent/actions/download/invoke'; \
--data-urlencode 'os_type=linux_deb' \
-H 'accept: application/octet-stream' \
-H 'Authorization: Bearer automation myautomationsecret'
Hierbei handelt es sich nur um ein sehr einfaches Beispiel um die Funktionsweise dieses einen Endpoints zu demonstrieren. Details zu der Funktionsweise der Endpoints zum Herunterladen des Agenten entnehmen Sie bitte wie immer der in Checkmk verfügbaren API-Dokumentation, die Sie über Help > APIs > REST API documentation finden.
2.3. Installation mit der Agentenbäckerei
Die
Checkmk Enterprise Editions verfügen mit der Agentenbäckerei über ein
Setup-Modul zum automatischen Paketieren von individuell angepassten Agenten. Diese
wird im allgemeinen Kapitel über die Agenten beschrieben. Die
Installation der gebackenen Pakete geschieht genau wie oben beschrieben.
2.4. Automatisches Updaten
Wenn Sie die Agentenbäckerei verwenden, können Sie automatische Updates
des Agenten einrichten. Diese werden in einem eigenen Artikel
beschrieben.
2.5. Manuelle Installation
Die Manuelle Installation des Agenten ist zwar selten nötig, aber auch nicht sehr schwierig. Sie benötigen aus der Seite der Agentendateien dazu den Kasten Agents. Dort finden Sie die Datei Checkmk Agent for Linux:

Laden Sie diese Datei auf das Zielsystem und kopieren Sie sie in ein Verzeichnis,
das für root
ausführbar ist. Sehr gut eignet sich /usr/local/bin/
,
da es sich im Suchpfad befindet und für eigene Erweiterungen gedacht ist. Auch
hier können Sie wieder direkt mit wget
arbeiten:
root@linux# cd /usr/local/bin
root@linux# wget http://mycmkserver/mysite/check_mk/agents/check_mk_agent.linux
root@linux# mv check_mk_agent.linux check_mk_agent
root@linux# chmod 755 check_mk_agent
Vergessen Sie bitte nicht die letzten beiden Befehle: Damit entfernen Sie
die Endung .linux
und machen die Datei ausführbar. Wenn Sie
alles richtig gemacht haben, muss der Agent jetzt einfach als
Befehl ausführbar sein und seine typische Ausgabe erzeugen. Das geht auch,
wenn Sie nicht in /usr/local/bin
stehen. Das | head
schneidet hier alles ab der 11. Zeile weg:
root@linux# check_mk_agent | head
<<<check_mk>>>
Version: 2.0.0p42
AgentOS: linux
Hostname: mycmkserver
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
<<<df>>>
Falls Sie eine sehr alte Distribution haben (vor 2010 veröffentlicht), welche den Befehl timeout
nicht kennt, dann laden Sie noch das kleine Programm waitmax
von der Agentenseite (ebenfalls im Kasten Agents) und installieren Sie es ebenfalls nach /usr/local/bin
.
timeout
und waitmax
haben dieselbe Funktionalität. Sie erzwingen einen Timeout bei der Ausführung eines Programms:
root@linux# timeout --help
Usage: timeout [OPTION] DURATION COMMAND [ARG]...
or: timeout [OPTION]
Start COMMAND, and kill it if still running after DURATION.
Waitmax wurde als Teil von Checkmk zu einer Zeit entwickelt, als timeout
noch nicht verbreitet war. Es hat fast die gleiche Aufrufsyntax:
root@linux# waitmax --help
age: waitmax [-s SIGNUM] MAXTIME PROGRAM [ARGS...]
Execute PROGRAM as a subprocess. If PROGRAM does not exit before MAXTIME
seconds, it will be killed with SIGTERM or an alternative signal.
-s, --signal SIGNUM kill with SIGNUM on timeout
-h, --help this help
-V, --version show version an exit
Falls Sie den Agenten konfigurieren oder erweitern möchten, müssen Sie
die dafür notwendigen Verzeichnisse selbst anlegen. Der Ort für die
drei notwendigen Verzeichnisse ist im Agenten hart kodiert in Variablen,
die mit MK_
beginnen und über das Environment auch den Plugins
bereitgestellt werden:
root@linux# grep 'export MK_' check_mk_agent
export MK_LIBDIR="/usr/lib/check_mk_agent"
export MK_CONFDIR="/etc/check_mk"
export MK_VARDIR="/var/lib/check_mk_agent"
Diese drei Verzeichnisse sollten Sie anlegen (mit den Standardrechten 755):
root@linux# mkdir /usr/lib/check_mk_agent /etc/check_mk /var/lib/check_mk_agent
Falls Sie die Pfade ändern möchten, so editieren Sie einfach
/usr/local/bin/check_mk_agent
.
Falls Sie den Agenten grundsätzlich über SSH abrufen möchten, brauchen
Sie keine Konfiguration für den xinetd
und benötigen nur noch
die SSH-Konfiguration. Wie das geht, beschreiben wir
weiter unten.
Die Konfiguration per xinetd
ermöglicht einen Zugriff auf die
Agentendaten via TCP Port 6556 und ist der Standardweg im lokalen
Netzwerk. Installieren Sie dazu das Paket xinetd
und legen
Sie folgende Datei an:
service check_mk
{
type = UNLISTED
port = 6556
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/local/bin/check_mk_agent
only_from = 10.118.14.5 10.118.14.37
disable = no
}
Tragen Sie hier unter only_from
die IP-Adressen Ihrer Checkmk-Server ein, die
auf den Agenten zugreifen dürfen. Danach braucht es nur noch ein Aktivieren und der
Agent ist bereit:
root@linux# /etc/init.d/xinetd reload
Wenn Sie systemd verwenden, führen Sie stattdessen dieses Kommando aus:
root@linux# systemctl reload xinetd.service
3. Test und Fehlerdiagnose
3.1. Übersicht
Sobald Sie den Agent installiert und konfiguriert haben, stellen Sie sich sicher die Frage, wie Sie ausprobieren können, ob Sie alles richtig gemacht haben. Alle Möglichkeiten, die es vom Checkmk-Server aus gibt, sind im allgemeinen Kapitel über die Agenten beschrieben. Aber natürlich gibt es noch weitere Diagnosemöglichkeiten, wenn man direkt auf dem Zielsystem selbst eingeloggt ist.
Da der „Agent“ im Grunde nichts als ein einfaches Programm ist, das Daten über Ihr System beschafft und diese als lose formatierten Text ausgibt, können Sie ihn auch als Programm aufrufen, und zwar ganz einfach so:
root@linux# check_mk_agent
<<<check_mk>>>
Version: 2.0.0p42
AgentOS: linux
Hostname: myhost123
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
<<<df>>>
udev devtmpfs 8155492 4 8155488 1% /dev
tmpfs tmpfs 1634036 1204 1632832 1% /run
/dev/sda5 ext4 226298268 176973752 37806104 83% /
none tmpfs 4 0 4 0% /sys/fs/cgroup
Da die Ausgabe etwas
länger sein kann, ist less
auch hier sehr praktisch (Sie können es
mit der Taste Q verlassen):
root@linux# check_mk_agent | less
Diese Ausgabe beweist natürlich nicht, dass der Agent auch über das Netzwerk erreichbar ist. Aber Sie können so testen, ob in der Ausgabe alle gewünschten Daten enthalten sind.
Sie müssen übrigens nicht unbedingt root
sein, um den Agenten
aufzurufen. Allerdings werden dann in der Ausgabe eventuell einige
Informationen fehlen, zu deren Beschaffung root
-Rechte erforderlich
sind (z.B. Multipath-Informationen und die Ausgaben von ethtool
).
3.2. Debug-Modus
Damit eventuelle Fehlerausgaben von nicht funktionierenden Plugins oder
Befehlen nicht die eigentlichen Daten „verunreinigen“, unterdrückt der
Agent generell den Standardfehlerkanal. Sind Sie auf der Suche nach
einem bestimmten Problem, können Sie diesen wieder aktivieren, indem
Sie den Agenten in einem speziellen Debug-Modus aufrufen. Das machen
Sie mit der Option -d
. Dabei werden auch sämtliche Shellbefehle
ausgegeben, die der Agent ausführt.
Damit Sie hier mit less
arbeiten können, müssen Sie Standardausgabe
und Fehlerkanal mit 2>&1
zusammenfassen:
root@linux# check_mk_agent -d 2>&1 | less
4. Deaktivieren von Sektionen
Die Ausgabe des Checkmk-Agenten ist in Sektionen unterteilt. Jede dieser Sektionen enthält zusammengehörige Informationen und ist meist einfach die Ausgabe eines Diagnosebefehls. Sektionen beginnen immer mit einem Sektions-Header. Dies ist eine Zeile, die in <<< und >>> eingeschlossen ist.
Bis auf die Checkmk-eigenen Sektionen, können Sie jede der über 40 Sektionen, die der Agent standardmäßig erzeugt, einzeln deaktivieren. Konkret bedeutet dies, dass die entsprechenden Befehle durch den Agenten überhaupt nicht ausgeführt werden und ggf. Rechenzeit eingespart werden kann. Andere Gründe für die Deaktivierung könnten sein, dass Sie sich für bestimmte Informationen einer gewissen Gruppe oder Art von Hosts schlicht nicht interessieren oder das ein bestimmter Host fehlerhafte Werte liefert und Sie den Abruf dieser Daten kurzzeitig aussetzen wollen.
Als Nutzer einer der Checkmk Enterprise Editions können Sie über Setup > Agents > Windows, Linux,
Solaris, AIX > Agent rules > Disabled sections (Linux agent) einfach eine Regel
anlegen, welche dann von der Agentenbäckerei
berücksichtigt wird.

In der Regel finden Sie dann für jede deaktivierbare Sektion eine eigene
Checkbox. Für jede angewählte Checkbox finden Sie - nachdem der neu gebackene
Agent auf den ausgewählten Hosts installiert wurde - in der Datei
/etc/check_mk/exclude_sections.cfg
einen eigenen Eintrag. Würden Sie in der
Regel beispielsweise die beiden Optionen Running processes
und Systemd
services
auswählen, sähe die passende Konfigurationsdatei wie folgt aus:
MK_SKIP_PS=yes
MK_SKIP_SYSTEMD=yes
Nutzer der Checkmk Raw Edition können die oben genannte Datei
/etc/check_mk/exclude_sections.cfg
manuell anlegen und dort die Sektionen eintragen, die deaktiviert werden sollen. Alle deaktivierbaren Sektionen sind in der Datei
~/share/check_mk/agents/cfg_examples/exclude_sections.cfg
aufgelistet.
5. Einbinden von klassischen Check-Plugins
5.1. Plugins über MRPE ausführen
Wenn Sie Ihr Monitoring von einer Nagios-basierten Lösung auf Checkmk migriert haben, ist es nicht ganz ausgeschlossen, dass Sie ältere Check-Plugins haben, zu denen es (noch) kein Pendant in Checkmk gibt. In den meisten Fällen sind das selbstgeschriebene Plugins in Perl oder Shell.
Der Checkmk-Agent bietet einen einfachen Mechanismus, solche Plugins weiter zu verwenden: MK’s Remote Plugin Executor oder kurz MRPE. Der Name ist bewusst eine Analogie zum NRPE von Nagios, der dort die gleiche Aufgabe übernimmt.
Der MRPE ist im Agenten fest eingebaut und wird mit einer einfachen
Textdatei konfiguriert, welche Sie unter /etc/check_mk/mrpe.cfg
selbst anlegen. Dort geben Sie pro Zeile einen Plugin-Aufruf an — zusammen
mit dem Namen, den Checkmk für den Service verwenden soll, den es dafür
automatisch erzeugt. Hier ist ein Beispiel:
Foo_Application /usr/local/bin/check_foo -w 60 -c 80
Bar_Extender /usr/local/bin/check_bar -s -X -w 4:5
Wenn Sie jetzt den Agenten lokal laufen lassen, finden Sie
pro Plugin eine neue Sektion mit dem Titel <<<mrpe>>>
,
welche Name, Exitcode und Ausgabe des Plugins enthält. Das können Sie mit folgendem
praktischen grep
-Befehl überprüfen:
root@linux# check_mk_agent | grep -A1 '^...mrpe'
<<<mrpe>>>
(check_foo) Foo_Application 0 OK - Foo server up and running
<<<mrpe>>>
(check_bar) Bar_Extender 1 WARN - Bar extender overload 6.012|bar_load=6.012
Die 0
bzw. 1
in der Ausgabe stehen für die Exitcodes der
Plugins und folgen dem klassischen Schema: 0
= OK, 1
=
WARN, 2
= CRIT und 3
= UNKNOWN.
Den Rest macht jetzt Checkmk automatisch. Sobald Sie die Serviceerkennung für den Host aufrufen, werden die beiden neuen Services als verfügbar angezeigt. Das sieht dann so aus:

Übrigens: Aufgrund der Syntax der Datei darf
der Name keine Leerzeichen enthalten. Sie können aber mithilfe der gleichen
Syntax wie in URLs ein Space durch %20
ersetzen (ASCII-Code 32 für Space
ist Hexadezimal 20):
Foo%20Application /usr/local/bin/check_foo -w 60 -c 80
Bar%20Extender /usr/local/bin/check_bar -s -X -w 4:5
5.2. Asynchrone Ausführung
Bitte beachten Sie, dass alle Plugins, die Sie in mrpe.cfg
aufführen,
der Reihe nach synchron ausgeführt werden. Die Plugins sollten daher keine
allzu große Ausführungszeit haben. Wenn ein Plugin hängt, verzögert sich die
Ausführung aller weiteren. Das kann dazu führen, dass das komplette Abfragen
des Agenten durch Checkmk in einen Timeout laufen und der Host nicht mehr
zuverlässig überwacht werden kann.
Wenn Sie wirklich länger laufende Plugins benötigen, sollten Sie diese auf
asynchrone Ausführung umstellen und das Problem damit vermeiden. Dabei legen
Sie eine Zeit in Sekunden fest, die ein berechnetes Ergebnis Gültigkeit
haben soll, z.B. 300
für fünf Minuten. Setzen Sie dazu in
mrpe.cfg
nach dem Servicenamen den Ausdruck (interval=300)
:
Foo_Application (interval=300) /usr/local/bin/check_foo -w 60 -c 80
Bar_Extender /usr/local/bin/check_bar -s -X -w 4:5
Das hat mehrere Auswirkungen:
Das Plugin wird in einem Hintergrundprozess ausgeführt und bremst nicht mehr die Ausführung des Agenten.
Weil der Agent die Ausführung nicht abwartet, wird das Ergebnis erst beim nächsten Aufruf des Agenten geliefert.
Frühestens nach 300 Sekunden wird das Plugin neu ausgeführt. Bis dahin wird das alte Ergebnis wiederverwendet.
Damit können Sie also Tests, die etwas mehr Rechenzeit benötigen, auch in größeren Intervallen ausführen, ohne dass Sie dazu am Checkmk-Server etwas konfigurieren müssen.
5.3. MRPE mit der Agentenbäckerei
Nutzer der Enterprise Editions können MRPE auch mit der Agentenbäckerei konfigurieren.
Zuständig dafür ist der Regelsatz Setup > Agents > Windows, Linux Solaris, AIX > Agent Rules > Generic Options > Execute MRPE checks.
Dort können Sie die gleichen Dinge wie oben beschrieben konfigurieren.
Die Datei
mrpe.cfg
wird dann von der Bäckerei automatisch generiert.

Backen der Plugins
Auch die Check-Plugins selbst können Sie mit dem Paket ausliefern lassen. Damit ist der Agent dann komplett und braucht keine manuelle Installation von weiteren Dateien. Das Ganze geht so:
Erzeugen Sie auf dem Checkmk-Server das Verzeichnis
local/share/check_mk/agents/custom
.Erzeugen Sie dort ein Unterverzeichnis — z.B.
my_mrpe_plugins
.Erzeugen Sie wiederum darin das Unterverzeichnis
bin
.Kopieren Sie Ihre Plugins in den bin-Ordner.
Legen Sie eine Regel in Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Generic Options > Deploy custom files with agent an.
Wählen Sie
my_mrpe_plugins
aus, speichern Sie und backen Sie!
Die Check-Plugins werden jetzt in das Standard-bin
-Verzeichnis Ihres Agenten installiert.
Per Default ist das /usr/bin
. Bei der Konfiguration der MRPE-Checks verwenden Sie dann also /usr/bin/check_foo
anstelle von /usr/local/bin/check_foo
.
6. Agent um Plugins erweitern
6.1. Was sind Plugins?
Der Standardagent /usr/bin/check_mk_agent
enthält eine ganze
Reihe von Sektionen, welche Überwachungsdaten für diverse Checks
liefern und dann von der Serviceerkennung automatisch gefunden werden.
Dazu gehören alle wichtigen Überwachungen des Betriebssystems.
Darüber hinaus gibt es die Möglichkeit, den Agenten um Agentenplugins zu erweitern. Das sind kleine Skripten oder Programme, die vom Agenten aufgerufen werden und diesen um weitere Sektionen mit zusätzlichen Monitoring-Daten erweitern. Das Checkmk-Projekt liefert eine ganze Reihe solcher Plugins mit aus, welche — wenn sie korrekt installiert und konfiguriert sind — in der Serviceerkennung automatisch neue Checks liefern.
Warum sind diese Plugins nicht einfach in den Standardagenten fest integriert? Für jedes der Plugins gibt es einen der folgenden Gründe:
Das Plugin ist in einer anderen Programmiersprache als Shell geschrieben und kann daher nicht inline realisiert werden (Beispiel:
mk_logwatch
).Das Plugin braucht sowieso eine Konfiguration, ohne die es nicht funktionieren würde (Beispiel:
mk_oracle
).Das Plugin ist so speziell, dass es von den meisten Anwendern nicht benötigt wird (Beispiel:
plesk_domains
).
6.2. Manuelle Installation von Plugins
Die vom Projekt mitgelieferten Plugins für Linux und UNIX finden Sie alle
auf dem Checkmk-Server unter share/check_mk/agents/plugins
.
Auch über die Downloadseite der Agenten im Setup-Menü (wie am Anfang des
Artikels beschrieben) sind diese im Kasten Plugins
verfügbar:

Zu allen von uns mitgelieferten Agentenplugins existieren die passenden Checkplugins, welche deren Daten auswerten und Services erzeugen können. Diese sind bereits mitinstalliert, so dass neu gefundene Dienste sofort erkannt werden und konfiguriert werden können.
Bevor Sie ein Plugin im Agenten installieren, werfen Sie bitte einen Blick in die entsprechende Datei. Oft finden Sie dort wichtige Hinweise zur korrekten Verwendung des Plugins.
Die eigentliche Installation ist dann einfach: Kopieren Sie die Datei
nach /usr/lib/check_mk_agent/plugins
. Achten Sie dabei darauf,
dass diese ausführbar ist. Falls nicht, verwenden Sie ein chmod
755
. Der Agent wird das Plugin sonst nicht ausführen. Insbesondere,
wenn Sie die Dateien nicht per scp
übertragen sondern per HTTP von
der Downloadseite holen, geht die Ausführungsberechtigung verloren!
Sobald das Plugin ausführbar und im richtigen Verzeichnis ist, wird
es vom Agenten aufgerufen und es entsteht eine neue Sektion in der
Agentenausgabe. Diese trägt üblicherweise den gleichen Namen wie
das Plugin. Komplexe Plugins (z.B. mk_oracle
) erzeugen
sogar eine ganze Reihe von Sektionen.
6.3. Konfiguration der Plugins
Manche Plugins brauchen eine Konfigurationsdatei in /etc/check_mk/
,
damit sie funktionieren können. Bei anderen ist eine Konfiguration optional
und ermöglicht besondere Features oder Anpassungen. Wieder andere funktionieren
einfach so. Sie haben verschiedene Quellen, um an Informationen zu kommen:
Die Dokumentation der Check-Plugins in Ihrer Checkmk-Instanz, welche Sie über Setup > Services > Catalog of check plugins erreichen
Kommentare im Plugin selbst (oft sehr hilfreich!)
Einen passenden Artikel in diesem Handbuch (z.B. über das Überwachen von Oracle)
6.4. Asynchrone Ausführung
Ebenso wie bei MRPE können Sie auch Plugins asynchron ausführen lassen. Das ist sehr nützlich, wenn die Plugins eine lange Laufzeit haben und die gewonnenen Statusdaten ohnehin nicht jede Minute neu erzeugt werden brauchen.
Die asynchrone Ausführung wird nicht über eine Datei konfiguriert. Stattdessen
erzeugen Sie unter plugins
ein Unterverzeichnis, dessen Name eine Zahl
ist: eine Anzahl von Sekunden. Plugins in diesem Verzeichnis werden nicht nur
asynchron ausgeführt, sondern gleichzeitig geben Sie mit der Sekundenzahl
eine Mindestwartezeit vor, bevor das Plugin erneut ausgeführt werden soll.
Wird der Agent vor Ablauf der Zeit erneut abgefragt, verwendet er gecachte
Daten von der letzten Ausführung des Plugins. Damit können Sie quasi ein größeres
Intervall für das Plugin konfigurieren, als die typische eine Minute.
Folgendes Beispiel zeigt, wie das Plugin my_foo_plugin
von synchroner
Ausführung auf eine asynchrone Ausführung mit einem Intervall von 5 Minuten
umgestellt wird:
root@linux# cd /usr/lib/check_mk_agent/plugins
root@linux# mkdir 300
root@linux# mv my_foo_plugin 300
Bitte beachten Sie, dass einige Plugins bereits von sich aus eine asynchrone Ausführung umsetzen.
Dazu gehört mk_oracle
.
Installieren Sie solche Plugins direkt nach /usr/lib/check_mk_agent/plugins
!
6.5. Plugins über die Agentenbäckerei installieren
In den
Checkmk Enterprise Editions können die mitgelieferten Plugins über die Agentenbäckerei konfiguriert werden.
Diese sorgt sowohl für die Installation des Plugins selbst als auch für die korrekte Erstellung der Konfigurationsdatei, falls eine notwendig sein sollte.
Jedes Plugin wird über eine Agentenregel konfiguriert. Sie finden die passenden Regelsätze über Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Agent plugins:

6.6. Plugins von Hand ausführen
Da Agentenplugins ausführbare Programme sind, können Sie diese zu Test- und Diagnosezwecken auch von Hand ausführen. Es gibt allerdings Plugins, welche bestimmte vom Agenten gesetzten Umgebungsvariablen brauchen, um z.B. ihre Konfigurationsdatei zu finden. Setzen Sie diese vor der Ausführung von Hand:
root@linux# export MK_LIBDIR=/usr/lib/check_mk_agent
root@linux# export MK_CONFDIR=/etc/check_mk
root@linux# export MK_VARDIR=/var/lib/check_mk_agent
root@linux# /usr/lib/check_mk_agent/plugins/mk_foobar
<<<foobar>>>
FOO BAR BLA BLUBB 17 47 11
Einige Plugins kennen auch spezielle Aufrufoptionen zum Debuggen. Werfen Sie einfach einen Blick ins Plugin!
7. Absicherung
7.1. Vorüberlegung
Sicherheit ist ein wichtiges Kriterium für jegliche Software, hier darf Monitoring keine Ausnahme machen. Da der Monitoring-Agent auf jedem überwachten Server installiert wird, hätte hier ein Sicherheitsproblem besonders gravierende Auswirkungen.
Deswegen wurde schon beim Design von Checkmk auf Sicherheit Wert gelegt und es gilt seit den ersten Tagen von Checkmk ein eherner Grundsatz: Der Agent liest keine Daten vom Netzwerk. Punkt. Somit ist mit Sicherheit ausgeschlossen, dass ein Angreifer über den Überwachungsport 6556 irgendwelche Befehle oder Skriptbestandteile einschleusen kann.
Das allein liefert bereits ein so hohes Sicherheitsniveau, dass die meisten Anwender im LAN auf weitere Maßnahmen verzichten. Kann das überwachte System nur über eine unsichere Internetverbindung erreicht werden, gelten natürlich ganz andere Maßstäbe und hier ist sicher eine Verschlüsselung mit SSH die erste Wahl.
Der Checkmk-Agent verfügt ferner über eine eingebaute Verschlüsselung, welche einen guten Kompromiss aus Sicherheit und Aufwand darstellt. Im Folgenden zeigen wir Ihnen alle Möglichkeiten zur Absicherung im Detail.
7.2. Beschränkung des Zugriffs über IP-Adressen
Auch wenn ein Angreifer keine Befehle ausführen kann: Die Monitoring-Daten des Agenten könnten für ihn bereits nützlich sein, denn sie enthalten unter anderem eine Liste von allen auf dem System laufenden Prozessen. Am besten ist es daher, wenn die Daten nicht jeder einfach abrufen kann.
xinetd
Wenn Sie den Checkmk-Agenten ganz normal über den xinetd
freigeben,
ist es sehr einfach und effektiv, den Zugriff auf bestimmte IP-Adressen zu
beschränken — und zwar natürlich auf die des Monitoring-Servers. Das ist
einfach gemacht und war schon im Beispiel weiter oben zu sehen:
service check_mk
{
type = UNLISTED
port = 6556
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/bin/check_mk_agent
only_from = 10.118.14.5 10.118.14.37
disable = no
}
In den Enterprise Editions können Benutzer der Agentenbäckerei die erlaubten IP-Adressen über
den Regelsatz Allowed agent access via IP address konfigurieren.
Diesen Regelsatz finden Sie über Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Generic Options.
Natürlich kann ein Angreifer sehr leicht seine IP-Adresse fälschen und so eine Verbindung zum Agenten bekommen. Aber dann ist es sehr wahrscheinlich, dass er die Antwort nicht bekommt — weil diese zum echten Monitoring-Server geht. Oder er bekommt sie tatsächlich, aber der Checkmk-Server bekommt keinerlei Daten und wird sehr bald einen Fehler melden.
systemd
Da die meisten Distributionen zu systemd gewechselt sind, der nicht nur die Aufgaben des Init-Systems, sondern auch Netzwerkfunktionalität bereitstellt, arbeiten Linux-Distributoren daran, den guten alten xinetd abzuschaffen. Der vorpaketierte Linux-Agent (nicht der aus der Agentenbäckerei!) installiert sich daher bereits mit Mitteln des systemd, wenn das Zielsystem auf systemd basiert und kein bereits installierter xinetd verfügbar ist.
Bei der Verwendung von systemd lässt sich natürlich auch einschränken, welcher Rechner bzw. welche IP den Checkmk-Agenten abfragen darf. Das Pendant zum von xinetd bekannten only_from heißt hier IPAddressAllow. Der Agent erkennt während der Installation, ob die laufende Version von systemd diese Option bereits kennt und konfiguriert sich entsprechend.
Wenn Sie noch nicht zu den von systemd überzeugten gehören, gibt es aber
einen einfachen Ausweg: Es ist selbst bei systemd-basierten Systemen
(noch) möglich, xinetd zu verwenden. Dieser läuft dann als Dienst
unter systemd. Installieren Sie dazu das Paket xinetd
und danach den Checkmk-Agenten erneut.
Dieser wird dann xinetd finden und bevorzugt einrichten.
7.3. Aufruf über SSH
Die beste Sicherheit beim Aufruf des Checkmk-Agenten bietet der Aufruf desselben über Secure Shell — bei Linux in Form der Implementierung OpenSSH. Diese Methode ist angebracht bei:
Überwachung von Linux-Servern, die nur über das Internet erreichbar sind
Überwachung von Rechnern in einer DMZ
In ähnlichen Situationen, in denen eine TCP-Verbindung vom Checkmk-Server auf den Agenten überhaupt möglich ist.
Das Einrichten geschieht in folgenden Schritten:
Erstellen Sie ein SSH-Schlüsselpaar speziell für diesen Zweck.
Erlauben Sie auf den Zielsystemen den Zugriff auf den Agenten mittels dieses Schlüssels.
Klemmen Sie den Zugriffs über xinetd ab.
Konfigurieren Sie den Checkmk-Server so, dass er anstelle der TCP-Verbindung auf Port 6556 SSH verwendet.
Und das Ganze jetzt Schritt für Schritt mit allen notwendigen Details:
SSH-Schlüsselpaar erstellen
SSH arbeitet mit einer „Public-Key-Authentifizierung“. Dazu erzeugt
man zunächst ein Paar von aufeinander abgestimmten Schlüsseln, bei denen
einer öffentlich (public) ist und einer geheim (private). Bei der Wahl der
Algorithmen können Sie wählen zwischen rsa
, ecdsa
oder ed25519
. In
dem nachfolgenden Beispiel nutzen Sie den Befehl ssh-keygen -t ed25519
als Instanzbenutzer:
OMD[mysite]:~$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/omd/sites/mysite/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /omd/sites/mysite/.ssh/id_ed25519.
Your public key has been saved in /omd/sites/mysite/.ssh/id_ed25519.pub.
The key fingerprint is:
cc:87:34:d2:ed:87:ed:f7:1b:ec:58:1f:7c:23:00:e2 mysite@mycmkserver
The key's randomart image is:
--[ED25519 256--
| |
| . . |
| .... |
| .=..o |
| ES .o |
| . o. o |
| ...B.|
| .=.*|
| . o|
-----------------
Wichtig: Geben Sie hier keine Passphrase an! Es nützt Ihnen nichts, die Datei mit dem geheimen Schlüssel zu verschlüsseln. Denn Sie möchten ja sicher nicht jedes Mal beim Start des Checkmk-Servers die Passphrase eingeben müssen…
Das Ergebnis sind zwei Dateien im Verzeichnis .ssh
:
OMD[mysite]:~$ ll .ssh
total 8
-rw------- 1 mysite mysite 1679 Feb 20 14:18 id_ed25519
-rw-r--r-- 1 mysite mysite 398 Feb 20 14:18 id_ed25519.pub
Der private Schlüssel heißt id_ed25519
und ist nur für den Instanzbenutzer
lesbar (-rw-------
) — und das ist auch gut so! Der öffentliche
Schlüssel id_ed25519.pub
sieht etwa so aus:
OMD[mysite]:~$ cat .ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGb6AaqRPlbEmDnBkeIW3Q6Emb5lr2QEbWEQLmA5pb48 mysite@mycmkserver
Zugriff per SSH erlauben
Der nächste Schritt muss jetzt auf (je-)dem per SSH überwachten Linux-Server
stattfinden. Loggen Sie sich dort als root
ein und legen Sie in
dessen Homeverzeichnis (/root
) das Unterverzeichnis .ssh
an, falls es das nicht bereits gibt. Mit dem folgenden Befehl werden die
Zugriffsrechte gleich korrekt auf 700 gesetzt:
root@linux# mkdir -m 700 /root/.ssh
Öffnen Sie jetzt die Datei authorized_keys
mit einem
(konsolenbasierten) Texteditor Ihrer Wahl. Falls die Datei nicht
existiert, wird sie der Editor automatisch anlegen:
root@linux# vim /root/.ssh/authorized_keys
Kopieren Sie jetzt den Inhalt der Public Keys in diese Datei. Das geht z.B. mit der Maus und Copy & Paste. Seien Sie genau! Jedes Leerzeichen zählt. Achten Sie auch darauf, dass nirgendwo zwei Leerzeichen hintereinander sind. Und: Das ganze ist eine Zeile! Wenn die Datei schon existiert, dann hängen Sie einfach unten eine neue Zeile an.
Zugriff auf die Ausführung des Agenten beschränken
Was jetzt kommt, ist sehr wichtig! Der SSH-Schlüssel soll ausschließlich
zur Ausführung des Agenten dienen. SSH bietet so etwas unter dem Namen
Command restriction an. Dazu setzen Sie den Text
command="/usr/bin/check_mk_agent"
an den Anfang der Zeile, die Sie
gerade erzeugt haben — mit einem Leerzeichen vom Rest getrennt. Das
sieht dann etwa so aus:
command="/usr/bin/check_mk_agent" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGb6AaqRPlbEmDnBkeIW3Q6Emb5lr2QEbWEQLmA5pb48 mysite@mycmkserver
Speichern Sie die Datei, kontrollieren Sie die Rechte. Diese müssen auf 600
gesetzt sein:
root@linux# chmod 600 /root/.ssh/authorized_keys
root@linux# ll /root/.ssh/authorized_keys
-rw------- 1 root root 1304 Feb 20 14:36 authorized_keys
Testen Sie jetzt einmalig den Zugriff auf den Agenten per SSH. Beim ersten Mal müssen Sie den Fingerprint des Schlüssels mit der Eingabe von "yes" bestätigen. Erst danach können die Zugriffe im Hintergrund durch Checkmk erfolgen:
OMD[mysite]:~$ ssh root@myhost123
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is 55:34:f9:dd:2b:db:a7:fc:5d:4c:9d:37:28:f7:69:62.
Are you sure you want to continue connecting (yes/no)? yes
<<<check_mk>>>
Version: 2.0.0p42
AgentOS: linux
Hostname: myhost123
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
<<<df>>>
Die Abfrage nach dem key fingerprint kommt übrigens nur beim ersten Mal. Wenn es nicht klappt, überprüfen Sie bitte:
Ist der SSH-Server auf dem Zielsystem überhaupt installiert?
Haben die genannten Dateien und Verzeichnisse die richtigen Berechtigungen?
Haben Sie die Syntax von
authorized_keys
korrekt getippt?Haben Sie dort den richtigen öffentlichen Schlüssel eingetragen?
Haben Sie sich als der richtige Benutzer eingeloggt (
root@…
)?Haben Sie an das
command="…"
gedacht?
Bei sehr alten Zielsystemen kann es zudem vorkommen, dass Schlüssel mit
elliptischen Kurven (ed25519 und ecdsa) nicht bekannt sind. Erzeugen Sie in
diesem Fall zusätzlich einen RSA-Schlüssel und tragen Sie auch diesen in die
authorized_keys
ein. SSH wird für die Verbindung dann automatisch den
stärksten bekannten Schlüssel verwenden.
Zugriff über xinetd abklemmen
Das ganze Einrichten von SSH nützt nichts, wenn der Zugriff über Port 6556
nach wie vor möglich ist. Um den zu schließen, setzen Sie den xinetd-Dienst
von Checkmk auf disabled
. Löschen Sie nicht die ganze
Konfigurationsdatei. Diese würde beim nächsten Agentenupdate sonst wieder
auftauchen!
Das Deaktivieren geht in /etc/xinetd.d/check-mk-agent
:
service check_mk
{
type = UNLISTED
port = 6556
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/bin/check_mk_agent
disable = yes
}
Danach starten Sie xinetd neu:
root@linux# /etc/init.d/xinetd restart
Die Deinstallation von xinetd ist natürlich auch möglich — aber dann wird sich der Checkmk-Agent beim nächsten Update unter Umständen wieder über systemd aktivieren!
Vergessen Sie auf keinen Fall einen abschließenden Test. Eine Verbindung auf Port 6556 darf jetzt nicht mehr möglich sein:
OMD[mysite]:~$ telnet myhost123 6556
Trying 10.118.15.23...
telnet: Unable to connect to remote host: Connection refused
Zugriff von Checkmk auf SSH umstellen
Das Zielsystem ist vorbereitet. Jetzt fehlt nur noch die Konfiguration von Checkmk
selbst. Das geschieht über den Regelsatz Setup > Agents > Other
integrations> Custom integrations > Individual program call instead of agent access. Erstellen Sie
hier für die betroffenen Hosts eine Regel und tragen Sie als Befehl ssh -T
root@$HOSTADDRESS$
ein:

Nach einem Speichern und einem Activate changes sollte alles funktionieren!
Als Diagnose bieten sich die Befehle cmk -D
und cmk -d
an,
die im Artikel über die Kommandozeile erklärt werden.
Mehrere SSH-Schlüssel
Sie können auch mit mehr als einem SSH-Schlüssel arbeiten. Legen Sie die
Schlüssel in einem beliebigen Verzeichnis ab. In der Regel Individual program
call instead of agent access müssen Sie den Pfad zum jeweiligen privaten
Schlüssel dann mit der Option -i angeben. Verwenden Sie hier am besten
$OMD_ROOT
als Ersatz für den Pfad zum Instanzverzeichnis
(/omd/sites/mysite
). Der vollständige Befehl könnte dann ssh -i
$OMD_ROOT/.ssh/my_key -T root@$HOSTADDRESS$
lauten und damit wäre die
Konfiguration auch in einer Instanz mit einem anderen Namen lauffähig:

Sie können so für verschiedene Gruppen von Hosts verschiedene SSH-Schlüssel verwenden, indem Sie mehrere unterschiedliche Regeln in verwenden.
Übliche Fehlermeldungen beim Umgang mit SSH
Wenn Sie den Checkmk-Agenten über SSH abrufen möchten, kann es mitunter vorkommen, dass eben dieser Abruf nicht klappt und der Service Check_MK auf Ihrem Host in den Zustand CRIT geht. Diese Fehlermeldungen beginnen dann häufig mit Agent exited with code 255.
Informationen zur Behebung solcher Fehler, können Sie in dem entsprechenden Artikel in unserer Wissensdatenbank finden.
7.4. Eingebaute Verschlüsselung
Der Checkmk-Agent kann seine Daten ohne Zusatzmittel selbst verschlüsseln. Dies ist streng genommen kein Ersatz für eine Zugangskontrolle. Da aber ein Angreifer ja keine Befehle senden und mit verschlüsselten Ausgabedaten nichts anfangen kann, kommt es einer solchen schon sehr nahe.
Der Aufwand für die Verwendung der Verschlüsselung und die nötige zusätzliche CPU-Last sind beide geringer, als bei der oben beschriebenen Methode mit SSH, welche wir aber nach wie vor bei der Übertragung über das Internet empfehlen.
Die Verschlüsselung braucht natürlich sowohl auf dem Agenten als auch auf dem Server eine passende Konfiguration. Diese kann entweder von Hand erstellt werden (Raw Edition) oder mit der Agentenbäckerei (Enterprise Editions).
Aufsetzen ohne Agentenbäckerei
Auch ohne Agentenbäckerei geht der erste Schritt dennoch über Setup und das Anlegen einer Regel im Regelsatz Setup > Agents > Access to Agents > Checkmk agent > Encryption. Die Regel soll auf alle Hosts greifen, für die Sie Verschlüsselung einsetzen möchten. SNMP-Hosts ignorieren diese Einstellung, daher müssen Sie sie nicht explizit ausschließen.

Wichtig ist die Einstellung für Encryption for Agent. Solange Sie die Regel auf dem Default Disable lassen, bleibt natürlich alles beim Alten. Sie haben also die Wahl zwischen:
Enable: Verschlüsselung wird aktiviert, aber Daten von Agenten ohne Verschlüsselung werden weiter akzeptiert.
Enforce: Verschlüsselung wird aktiviert, nur noch verschlüsselte Daten werden akzeptiert.
Sinnvoll ist es, zunächst mit Enable zu beginnen. Sobald Sie meinen, dass alle Agenten auf Verschlüsselung umgestellt sind, stellen Sie auf Enforce, um dadurch Hosts zu finden, die noch Daten im Klartext senden.
Die Verschlüsselung funktioniert mit einem gemeinsamen Passwort, das Sie hier angeben und sowohl auf dem Checkmk-Server als auch auf dem Agenten im Klartext gespeichert werden muss („Shared secret“). Wählen Sie ein zufälliges Passwort aus und halten Sie es parat für den zweiten Schritt: die Konfiguration des Agenten.
Dort erzeugen Sie die Datei /etc/check_mk/encryption.cfg
mit folgendem Inhalt:
ENCRYPTED=yes
PASSPHRASE='XEwks9fm'
Natürlich setzen Sie hier bei PASSPHRASE
Ihr eigenes Passwort ein. Und Sie sollten
die Datei unbedingt vor Lesezugriffen anderer Benutzer schützen:
root@linux# chmod 600 /etc/check_mk/encryption.cfg
Jetzt können Sie folgende Tests machen (siehe dazu auch den Artikel über die Kommandozeile von Checkmk):
Der Aufruf von
check_mk_agent
auf dem Zielsystem muss wirren Zeichensalat ausgeben.Der Zugriff via
telnet myhost123 6556
vom Checkmk-Server muss den gleichen Zeichensalat ausgeben.Der Befehl
cmk -d myhost123
auf dem Checkmk-Server muss die sauberen Klartextdaten anzeigen.
Aufsetzen mit der Agentenbäckerei
Das Aufsetzen der Verschlüsselung mit der Agentenbäckerei ist sehr einfach. Mit dem Erstellen
der gerade beschriebenen Regel sind Sie im Grunde fertig. Sie brauchen nur noch neue Agenten
zu backen und zu verteilen. Die Datei
/etc/check_mk/encryption.cfg
wird automatisch
für Sie erzeugt und mit in die Agentenpakete eingebaut.
8. Überwachen von Linux per SNMP
Da es für Linux einen einfach aufzusetzenden SNMP-Agenten gibt, kommt gelegentlich die Frage auf, ob es nicht möglich oder sogar sinnvoll wäre, Linux per SNMP zu überwachen. Die Antwort ist sehr einfach: möglich ja, sinnvoll nein. Warum?
Die Monitoring-Daten des SNMP-Agenten sind sehr begrenzt. Daher brauchen Sie den Checkmk-Agenten für eine halbwegs sinnvolle Überwachung sowieso.
Der SNMP-Agent liefert keine sinnvollen Daten, die nicht auch der Checkmk-Agent liefern würde.
Der SNMP-Agent ist umständlicher aufzusetzen.
Nicht zuletzt braucht das Protokoll SNMP deutlich mehr CPU- und Netzwerkressourcen als die normale Überwachung mit Checkmk.
Es gibt allerdings ein paar wenige Situationen, in denen eine Überwachung per SNMP zusätzlich zum normalen Agenten sinnvoll sein kann. Und zwar ist das der Fall, wenn entweder eine eigene Anwendungssoftware oder ein Hardwareüberwachungstool des Serverherstellers Überwachungsdaten nur per SNMP liefern.
Setzen Sie in so einem Fall in den Eigenschaften des Hosts im Setup-Menü im Kasten Monitoring agents die Option Checkmk agent / API integrations auf einen Wert mit Checkmk-Agent (Configured API integrations and Checkmk agent oder API integrations if configured, else Checkmk agent) und die Einstellung SNMP auf SNMP v2 or v3 bzw. SNMP v1. Services, die sowohl per SNMP als auch per Checkmk-Agent verfügbar sind (z.B. CPU-Auslastung, Dateisysteme, Netzwerkkarten), werden dann automatisch vom Checkmk-Agenten geholt und nicht per SNMP. Damit wird eine Doppelübertragung automatisch vermieden.
9. Hardwareüberwachung
9.1. Grundsätzliches
Zu einer möglichst vollständigen Überwachung eines Linux-Servers gehört natürlich auch die Hardware. Dies geschieht teils direkt mit dem Checkmk-Agenten, teils auch über spezielle Plugins. Außerdem gibt es noch Fälle, in denen man per SNMP oder sogar über ein separates Managementboard eine Überwachung umsetzen kann.
9.2. Überwachung der SMART-Werte
Moderne Festplatten verfügen fast immer über S.M.A.R.T. (Self-Monitoring,
Analysis and Reporting Technology).
Dieses System zeichnet kontinuierlich Daten zu dem Zustand der HDD oder SSD auf und Checkmk kann mit dem Plugin smart
diese Werte abrufen und die wichtigsten davon auswerten.
Damit das Plugin nach der Installation auch funktioniert, müssen folgende Voraussetzungen erfüllt sein:
Das Paket
smartmontools
muss installiert sein. Sie können es auf allen modernen Distributionen über den jeweiligen Paketmanager installieren.Falls die Festplatten an einen RAID-Controller angeschlossen sind und dieser Zugriff auf die Smart-Werte erlaubt, muss das jeweilige Tool dazu installiert sein. Unterstützt werden
tw_cli
(3ware) undmegacli
(LSI).
Sind diese Voraussetzungen erfüllt und ist das Plugin installiert, werden die Daten automatisch ausgelesen und der Ausgabe des Agenten angehängt. In Checkmk können Sie die neuen Services dann auch direkt aktivieren:

Sollte — wie im Screenshot zu sehen — gelegentlich cmd_timeout
auftreten, stellen
Sie das Smart-Plugin auf asynchrone Ausführung im Abstand einiger Minuten um.
9.3. Überwachung mit Hilfe von IPMI
IPMI (Intelligent Platform Management Interface) ist eine Schnittstelle zum Hardwaremanagement, welche unter anderem die Überwachung der Hardware ermöglicht. Checkmk nutzt dafür freeipmi, um direkt und ohne Netzwerk auf die Hardware zuzugreifen. Es wird dafür aus den Paketquellen installiert und ist danach sofort einsatzbereit, so dass die Daten schon bei dem nächsten Aufruf von Checkmk übermittelt werden.
Falls freeipmi
nicht verfügbar ist, oder andere Gründe gegen eine
Installation sprechen, kann auch ipmitool
verwendet werden. Dieses
ist oft bereits auf dem System vorhanden und muss lediglich mit einem IPMI
Gerätetreiber versorgt werden, wie ihn z.B. das Paket openipmi
zur Verfügung stellt. Auch hier müssen Sie danach nichts weiter tun. Die
Daten werden von Checkmk automatisch erfasst.
Zur Fehlerdiagnose können Sie die Tools auch händisch in
einer Shell des Hosts ausführen. Haben Sie das Paket freeipmi
installiert, können Sie die Funktion hiermit kontrollieren:
root@linux# ipmi-sensors Temperature
32 Temperature_Ambient 20.00_C_(1.00/42.00) [OK]
96 Temperature_Systemboard 23.00_C_(1.00/65.00) [OK]
160 Temperature_CPU_1 31.00_C_(1.00/90.00) [OK]
224 Temperature_CPU_2 NA(1.00/78.00) [Unknown]
288 Temperature_DIMM-1A 54.00_C_(NA/115.00) [OK]
352 Temperature_DIMM-1B 56.00_C_(NA/115.00) [OK]
416 Temperature_DIMM-2A NA(NA/115.00) [Unknown]
480 Temperature_DIMM-2B NA(NA/115.00) [Unknown]
Wenn ipmitool
installiert wurde, können Sie die Ausgabe der Daten
mit folgendem Befehl prüfen:
root@linux# ipmitool sensor list
UID_Light 0.000 unspecified ok na na 0.000 na na na
Int._Health_LED 0.000 unspecified ok na na 0.000 na na na
Ext._Health_LED 0.000 unspecified ok na na 0.000 na na na
Power_Supply_1 0.000 unspecified nc na na 0.000 na na na
Fan_Block_1 34.888 unspecified nc na na 75.264 na na na
Fan_Block_2 29.792 unspecified nc na na 75.264 na na na
Temp_1 39.000 degrees_C ok na na -64.000 na na na
Temp_2 16.000 degrees_C ok na na -64.000 na na na
Power_Meter 180.000 Watts cr na na 384.00
9.4. Herstellerspezifische Tools
Viele große Server-Hersteller bieten auch eigene Tools an, um die Hardwareinformationen auszulesen und über SNMP bereitzustellen. Es gelten dabei die folgenden Voraussetzungen, um diese Daten abrufen und Checkmk bereitstellen zu können:
Auf dem Linux-Host ist ein SNMP-Server eingerichtet.
Das Tool des Herstellers ist installiert (z.B. Dells OpenManage oder Supermicros SuperDoctor ).
Der Host ist in Checkmk für die zusätzliche Überwachung per SNMP konfiguriert.
Die dadurch unterstützten neue Services für die Hardwareüberwachung werden dann automatisch erkannt. Es werden keine weiteren Plugins benötigt.
9.5. Zusätzliche Überwachung über das Managementboard
Man kann zu jedem Host ein Managementboard konfigurieren und zusätzliche Daten per SNMP holen. Die dadurch erkannten Services werden dann ebenfalls dem Host zugeordnet.
Die Einrichtung des Managementboard ist dabei sehr einfach. Geben Sie in den Eigenschaften des Hosts lediglich das Protocol, die IP-Adresse und die Zugangsdaten für SNMP an und speichern Sie die neuen Einstellungen ab:

In der Service Discovery werden die neu erkannten Services dann wie gewohnt aktiviert.
10. Dateien und Verzeichnisse
10.1. Pfade auf dem überwachten Host
Pfad | Bedeutung |
---|---|
| Installationsort des Checkmk-Agenten auf dem Zielsystem. |
| Basisverzeichnis für Erweiterungen des Agenten. |
| Plugins, welche den Agenten um zusätzliche Überwachungsdaten erweitern. Plugins können in jeder verfügbaren Programmiersprache geschrieben werden. |
| Eigene lokale Checks. |
| Datenverzeichnis des Checkmk-Agenten auf dem Zielsystem. |
| Hier werden Cache-Daten einzelner Sektionen abgelegt und dem Agenten, solange die Cache-Daten gültig sind, bei jeder Ausführung wieder angehängt. |
| Verzeichnis für überwachte Jobs. Diese werden der Agentenausgabe bei jeder Ausführung angehängt. |
| Enthält Daten, die z.B. von Cronjobs erstellt werden und eine eigene Sektion beinhalten. Diese werden ebenfalls der Agentenausgabe angehängt. |
| Ablage von Konfigurationsdateien für den Agenten. |
| Konfigurationsdatei für MRPE — für die Ausführung von klassischen Nagios-kompatiblen Check-Plugins. |
| Konfiguration für die Verschlüsselung der Agentendaten. |
| Konfigurationsdatei für die Deaktivierung bestimmter Sektionen des Agenten |
| Konfiguration für den |
10.2. Pfade auf dem Checkmk-Server
Pfad | Bedeutung |
---|---|
| Basisverzeichnis für eigene Dateien, die mit einem gebackenen Agenten mit ausgeliefert werden sollen. |
| Beispielhafte Konfigurationsdatei für das Deaktivieren von Sektionen |