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 Monitoringagenten 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 Verbrauch von 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
Sie finden die Agentendateien im WATO-Modul
Monitoring agents. Bei den Enterprise Editions landen Sie zunächst in der
Agentenbäckerei. Von dort aus kommen Sie mit
dem Knopf Agent 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 (auch das Paket für
Windows mit der Endung .msi
ist hier):

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 Linux/Unix-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 oder falls Sie andere Unix-Derivate als Linux überwachen möchten.
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-1.6.0p11-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.
Das Nachinstallieren von xinetd
geht auf Red Hat/CentOS mit:
root@linux# yum install xinetd
Bei SUSE Linux verwenden Sie zypper
:
root@linux# zypper install xinetd
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_1.6.0p11-1_all.deb
Das Nachinstallieren von xinetd
:
root@linux# apt-get install xinetd
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:
RPM hat sogar ein eingebautes wget
. Hier können Sie Download und Installation in
einem Schritt machen:
2.3. Installation mit der Agent-Bakery
Die
Checkmk Enterprise Editions verfügen mit der Agent-Bakery über ein
WATO-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 Linux/Unix agents. Dort finden Sie die Datei {CMK} Agent for Linux:

Laden Sie diese Datei auf das Zielsystem und kopieren Sie sie in ein Verzeichnis,
dass 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: 1.6.0p11
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, welche den Befehl timeout
nicht kennt, dann laden Sie noch das kleine Programm waitmax
von der
Agentenseite und installieren Sie es ebenfalls nach /usr/local/bin
. timeout
und waitmax
machen das gleiche: 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 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: 1.6.0p11
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. Debugmodus
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 Debugmodus 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. Einbinden von klassischen Check-Plugins
4.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 Check-Plugins klassischer Machart 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 Pluginaufruf 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. 2
in der Ausgabe stehen für die Exitcodes der
Plugins und folgen nach 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[hilite]%20#Application /usr/local/bin/check_foo -w 60 -c 80
Bar[hilite]%20#Extender /usr/local/bin/check_bar -s -X -w 4:5
4.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 sehr viel Rechenzeit brauchen, auch in größeren Intervallen ausführen, ohne dass Sie dazu am Checkmk-Server etwas konfigurieren müssen.
4.3. MRPE mit der Agentenbäckerei
Stolze Besitzer der Enterprise Editions können MRPE auch mit der
Agentenbäckerei konfigurieren. Zuständig
dafür ist der Regelsatz
Monitoring Agents ⇒ 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 Checksplugins 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 Monitoring Agents ⇒ 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 brauchen Sie dann also /usr/bin/check_foo
anstelle von
/usr/local/bin/check_foo
.
5. Agent um Plugins erweitern
5.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
).
5.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 WATO (wie am Anfang des
Artikels beschrieben) sind diese im Kasten Linux/Unix Agents - Plugins
verfügbar:

Zu allen von uns mitgelieferten Agentenplugins gibt es auch die passenden Checksplugins, welche deren Daten auswerten und Services erzeugen können. Diese sind bereits dafür bereit und müssen nicht extra installiert werden.
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.
In älteren Versionen des Checkmk-Agenten kann sich das Pluginverzeichnis auch an einem anderen Ort befinden. Falls Sie sich unsicher sind, ob Sie davon betroffen sind, können Sie das Verzeichnis folgendermaßen identifizieren:
root@linux# grep MK_LIBDIR= /usr/bin/check_mk_agent
export MK_LIBDIR="/usr/lib/check_mk_agent"
5.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 zugehörigen Check-Plugins im WATO-Modul Check plugins
Kommentare im Plugin selbst (oft sehr hilfreich!)
Einen passenden Artikel in diesem Handbuch (z.B. über das Überwachen von Oracle)
5.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 zu 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 intern umsetzen. Dazu gehört mk_oracle
.
Installieren Sie solche Plugins direkt nach
/usr/lib/check_mk_agent/plugins
!
5.5. Plugins über die Bakery installieren
Die von Checkmk mitgelieferten Plugins können über die Agent Bakery 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 in Monitoring Agents ⇒ Agent plugins:

5.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!
6. Absicherung
6.1. Vorüberlegung
Heutzutage muss alles sicher sein. Und da darf Monitoring natürlich keine Ausnahme sein. Da der Monitoringagent 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 irgendeine Art von Befehlen oder Skriptbestandteilen einschleusen könnte.
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.
6.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 auch schon 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 Monitoringservers. 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
}
Benutzer der Agentenbäckerei können die erlaubten IP-Adressen über den Regelsatz Monitoring agents ⇒ Rules ⇒ Generic options ⇒ Allowed agent access via IP address per WATO konfigurieren.
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 Monitoringserver geht. Oder er bekommt sie tatsächlich, aber der Checkmk-Server bekommt keinerlei Daten und wird sehr bald einen Fehler melden.
Systemd
Weil Systemd jetzt das neue Tolle ist, was alle machen, arbeiten Linux-Distributoren hart daran, den guten alten xinetd abzuschaffen. Der vorpaketierte Linux-Agent (nicht der aus der Bakery!) installiert sich daher bereits mit Mitteln des Systemd, wenn das Zielsystem auf Systemd basiert und kein xinetd verfügbar ist.
Nun kann aber Systemd leider so einfache Dinge wie only_from
nicht. Man wird lapidar auf iptables
verwiesen.
Sollte Ihr Agent also ohne xinetd rein mit Systemd aufgerufen werden, gibt
es leider keine einfachere Möglichkeit der IP-Adressbeschränkung, als in
die Konfiguration der Firewall einzusteigen.
Wenn Sie noch nicht zu den Systemd-Evangelisten 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. Und dann geht auch wieder die oben beschriebene Methode
mit only_from
. Installieren Sie dazu das Paket xinetd
und danach den Checkmk-Agenten erneut. Dieser sollte
dann xinetd finden und bevorzugt einrichten.
6.3. Aufruf über SSH
Die ultimative 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). Sie machen das
als Instanzbenutzer mit ssh-keygen -t ed25519
:
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:
root@linux# mkdir /root/.ssh
Die Berechtigungen des Verzeichnisses müssen 700
sein,
damit SSH es anerkennt. Falls Sie das Verzeichnis selbst angelegt haben,
brauchen Sie daher noch:
root@linux# chmod 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 Publickeys 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. Die 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
Jetzt sollte vom Monitoringserver aus ein Zugriff auf den Agenten per SSH möglich sein. Das können Sie so überprüfen:
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: 1.6.0p3
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?
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 den Neustart von xinetd nicht vergessen:
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
Datasource programs ⇒ Individual program call instead of agent access.
Erstellen Sie hier für die betroffenen Hosts eine Regel und tragen
Sie als Befehl ssh -T -oStrictHostKeyChecking=no root@<IP>
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.
Einzelheiten über die „Datasource programs“ erfahren Sie in einem eigenen Artikel.
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. Beim „Datasource program“ 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
). Dann ist 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 Datasource programs verwenden.
6.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 Bakery
Auch ohne Agentenbäckerei geht der erste Schritt über WATO: Anlegen einer Regel im Regelsatz Host & Service Parameters ⇒ Access to agents ⇒ Check_MK 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):
Ein Aufruf von
check_mk_agent
auf dem Zielsystem muss wirren Zeichensalat ausgeben.Ein
telnet myhost123 6556
vom Checkmk-Server muss den gleichen Zeichensalat ausgeben.Ein
cmk -d myshost123
auf dem Checkmk-Server muss die sauberen Klartextdaten anzeigen.
Aufsetzen mit der Bakery
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.
7. Ü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 WATO im Kasten Data sources die Einstellung Check_MK Agent auf eine der beiden Optionen die mit Normal Checkmk agent beginnen 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 Doppeltübertragung automatisch vermieden.
8. Hardwareüberwachung
8.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.
8.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:

8.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
8.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 Linuxhost 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.
8.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.
9. Dateien und Verzeichnisse
9.1. Pfade auf dem überwachten Host
Pfad | Bedeutung |
---|---|
/usr/bin/check_mk_agent | Installationsort des Checkmk-Agenten auf dem Zielsystem. |
/usr/lib/check_mk_agent | Basisverzeichnis für Erweiterungen des Agenten. |
/usr/lib/check_mk_agent/plugins | Plugins, welche den Agenten um zusätzliche Überwachungsdaten erweitern. Plugins können in jeder verfügbaren Programmiersprache geschrieben werden. |
/usr/lib/check_mk_agent/local | Eigene „Localchecks“. |
/var/lib/check_mk_agent | Datenverzeichnis des Checkmk-Agenten auf dem Zielsystem. |
/var/lib/check_mk_agent/cache | Hier werden Cache-Daten einzelner Sektionen abgelegt und dem Agenten, solange die Cache-Daten gültig sind, bei jeder Ausführung wieder angehängt. |
/var/lib/check_mk_agent/job | Verzeichnis für überwachte Jobs. Diese werden der Agentenausgabe bei jeder Ausführung angehängt. |
/var/lib/check_mk_agent/spool | Enthält Daten, die z.B. von Cronjobs erstellt werden und eine eigene Sektion beinhalten. Diese werden ebenfalls der Agentenausgabe angehängt. |
/etc/check_mk | Ablage von Konfigurationsdateien für den Agenten. |
/etc/check_mk/mrpe.cfg | Konfigurationsdatei für MRPE — für die Ausführung von klassischen Nagios-kompatiblen Check-Plugins. |
/etc/check_mk/encryption.cfg | Konfiguration für die Verschlüsselung der Agentendaten. |
/etc/xinetd.d/check-mk-agent | Konfiguration für den |