Checkmk
to checkmk.com

1. Der neue Agent

Linux-Logo.

Linux-Systeme können Sie mit Checkmk besonders gut überwachen. Das liegt weniger daran, dass sich das Checkmk-Entwicklerteam auf Linux „zu Hause“ 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.

Da die meisten der Schnittstellen per se nicht über das Netzwerk erreichbar sind, ist die Installation eines Monitoring-Agenten unumgänglich. Deswegen hat Checkmk einen eigenen Agenten für die Überwachung von Linux. Dieser ist ein simples Shellskript, das minimalistisch, transparent und sicher ist.

In der Checkmk-Version 2.1.0 gibt es nun einen neuen Linux-Agenten. Präziser gesagt, wird dem Agentenskript check_mk_agent eine neue Komponente zur Seite gestellt: der Agent Controller. Der Agent Controller ist dem Agentenskript vorgeschaltet, fragt dieses ab und kommuniziert an dessen Stelle mit dem Checkmk-Server. Dazu registriert er sich am Agent Receiver, einem ebenfalls neuen Prozess, der auf dem Checkmk-Server läuft.

Der neue Linux-Agent übernimmt also zum einen das Agentenskript, und damit dessen Vorteile. Zum anderen ergänzt er das Skript so, dass neue Funktionen hinzugefügt werden können wie die TLS-Verschlüsselung der Kommunikation, Datenkomprimierung — und auch die Umkehrung der Kommunikationsrichtung.

Der registrierte, verschlüsselte und komprimierte Pull-Modus mit dem Agent Controller ist ab Version 2.1.0 für alle Checkmk-Editionen verfügbar — sofern sowohl Checkmk-Server als auch Agent Version mindestens 2.1.0 haben.

Der Agent Controller wird als Hintergrundprozess (Daemon) vom init-System systemd gestartet, daher setzt der Agent eine Linux-Distribution mit systemd voraus. Wahrscheinlich wird diese Voraussetzung auf Ihrem Host erfüllt sein, da seit 2015 die meisten Linux-Distributionen systemd als init-System übernommen haben.

Allerdings beherrscht der Agent auch einen sogenannten Legacy-Modus, um Linux-Systeme zu unterstützen mit einer anderen Rechnerarchitektur als x86_64, ohne RPM- bzw. DEB-Paketmanagement und ohne init-System systemd. In diesem Legacy-Modus arbeitet der neue wie der alte Agent, d.h. ohne Agent Controller und damit auch ohne Registrierung am Checkmk-Server.

Der Artikel, den Sie gerade lesen, behandelt Installation, Konfiguration und Erweiterungen des Linux-Agenten mit Agent Controller. Er zeigt Ihnen aber auch, wie Sie herausfinden können, ob der Agent auf Ihrem Linux-System ohne Agent Controller im Legacy-Modus eingerichtet werden muss. Im Artikel Linux überwachen im Legacy-Modus finden Sie dann dazu alle Informationen.

2. Architektur des Agenten

Der Checkmk-Agent besteht aus dem Agentenskript und dem Agent Controller, der mit dem Agent Receiver auf dem Checkmk-Server kommuniziert. Im allgemeinen Artikel über die Monitoring-Agenten finden Sie Einzelheiten zur gemeinsamen Architektur von Linux-Agent und Windows-Agent. In diesem Kapitel geht es um die für Linux spezifische Implementierung.

Das Agentenskript check_mk_agent ist zuständig für die Sammlung der Monitoring-Daten und ruft für die Datensammlung der Reihe nach vorhandene Systembefehle auf. Um auch diejenigen Informationen zu erhalten, zu deren Beschaffung root-Rechte erforderlich sind, wird check_mk_agent unter root ausgeführt.

Das Agentenskript ist minimalistisch, sicher, leicht erweiterbar und transparent, denn es ist ein Shellskript, in dem Sie sehen können, welche Befehle es aufruft.

Der Agent Controller cmk-agent-ctl kümmert sich um den Transport der vom Agentenskript gesammelten Daten. Er wird unter dem Benutzer cmk-agent ausgeführt, der nur beschränkte Rechte besitzt, z.B. keine Login-Shell hat und nur zur Datenübertragung genutzt wird. Der Benutzer cmk-agent wird während der Installation des Agentenpakets angelegt. Der Agent Controller wird als Daemon von systemd gestartet und ist als Service an diesen gekoppelt. Er lauscht am TCP-Port 6556 auf eingehende Verbindungen der Checkmk-Instanz und fragt das Agentenskript über einen Unix-Socket (einer systemd Unit) ab.

3. Installation

Checkmk bietet Ihnen für die Installation des Linux-Agenten verschiedene Wege — von der manuellen Installation des Software-Pakets bis hin zum vollautomatischen Deployment inklusive Update-Funktion. Manche davon stehen nur in den Enterprise Editions zur Verfügung:

MethodeBeschreibungCRECEE

Mitgeliefertes RPM/DEB-Paket

Einfache Installation eines Standard-Agenten mit manueller Konfiguration über Konfigurationsdateien. Die Installationsroutine überprüft und konfiguriert in allen Editionen systemd und xinetd — in dieser Reihenfolge.

X

X

RPM/DEB-Paket aus der Agentenbäckerei

Konfiguration über die GUI, individuelle Konfiguration pro Host möglich.

X

Automatisches Updaten

Das Paket aus der Agentenbäckerei wird erstmalig von Hand oder per Skript installiert und von da an automatisch aktualisiert.

X

3.1. Download des RPM/DEB-Pakets

Sie installieren den Linux-Agenten durch Installation des RPM- oder des DEB-Pakets. Ob Sie RPM oder DEB benötigen, hängt von der Linux-Distribution ab, auf der Sie das Paket installieren möchten:

PaketEndungInstallation auf

RPM

.rpm

Red Hat Enterprise Linux (RHEL) basierte Systeme, SLES, Fedora, openSUSE, Derivate davon

DEB

.deb

Debian, Ubuntu, alle anderen DEB-basierten Distributionen

Vor der Installation müssen Sie das Paket holen und auf den Host bringen (zum Beispiel mit scp oder WinSCP), auf dem der Agent laufen soll.

Paket per Checkmk-GUI holen

In der CRE Checkmk Raw Edition finden Sie die Linux-Pakete des Agenten über Setup > Agents > Linux. In den CEE Checkmk Enterprise Editions gelangen Sie im Setup-Menü über Agents > Windows, Linux, Solaris, AIX zunächst in die Agentenbäckerei, wo Sie die gebackenen Pakete finden. Von dort aus kommen Sie mit dem Menüeintrag Related > Linux, Solaris, AIX files zur Liste der Agentendateien:

Download-Seite mit den RPM/DEB-Paketen.
Auf der Download-Seite finden Sie die RPM- und DEB-Pakete

Alles was Sie brauchen, finden Sie gleich im ersten Kasten mit dem Namen Packaged Agents: die fertigen RPM- und DEB-Pakete für die Installation des Linux-Agenten mit Standardeinstellungen.

Paket per HTTP holen

Manchmal ist der Download auf einen Rechner und das anschließende Kopieren auf den Zielrechner mit 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 URL 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 /mysite/check_mk/agents/ vor den Dateinamen, im folgenden Beispiel für das RPM-Paket:

root@linux# wget http://mycmkserver/mysite/check_mk/agents/check-mk-agent-2.1.0b1-1.noarch.rpm

Tipp: RPM hat sogar ein eingebautes wget. Hier können Sie Download und Installation mit einem Kommando durchführen:

root@linux# rpm -U http://mycmkserver/mysite/check_mk/agents/check-mk-agent-2.1.0b1-1.noarch.rpm

Paket per REST-API holen

Die REST-API von Checkmk bietet die folgenden Möglichkeiten Agentenpakete vom Checkmk-Server herunterzuladen:

  • Herunterladen des mitgelieferten Agenten.

  • Herunterladen eines gebackenen Agenten nach Host-Name und Betriebssystem.

  • Herunterladen eines gebackenen Agenten nach Hash des Agenten und Betriebssystems.

Auch per REST-API haben Sie die Möglichkeit, das Paket vom Checkmk-Server direkt auf den Zielrechner zu holen. Das mitgelieferte DEB-Paket des Linux-Agenten lässt sich beispielsweise mit dem folgenden curl-Kommando holen:

root@linux# curl -OJG "http://mycmkserver/mysite/check_mk/api/1.0/domain-types/agent/actions/download/invoke" \
--header 'Accept: application/octet-stream' \
--header 'Authorization: Bearer automation myautomationsecret' \
--data-urlencode 'os_type=linux_deb'

Hierbei handelt es sich nur um ein einfaches Beispiel, um die Funktionsweise dieses einen REST-API-Endpunkts zum Herunterladen des Agenten zu demonstrieren. Details zu diesem und anderen REST-API-Endpunkten finden Sie in der API-Dokumentation, die Sie in Checkmk über Help > Developer resources > REST API documentation aufrufen können.

3.2. Paket installieren

Nachdem Sie das RPM- oder das DEB-Paket geholt und — falls nötig — mit scp, WinSCP oder anderen Mitteln auf den zu überwachenden Host kopiert haben, ist die Installation mit einem Kommando erledigt.

Die Installation des RPM-Pakets erfolgt unter root mit dem Befehl rpm -U:

root@linux# rpm -U check-mk-agent-2.1.0b1-1.noarch.rpm

Die Option -U steht übrigens für „Update“, kann aber auch eine Erstinstallation korrekt durchführen. Das bedeutet auch, dass Sie mit diesem Befehl einen bereits installierten Agenten auf die aktuelle Version updaten können — und ihn auch zukünftig für Updates des Agentenpakets nutzen können.

Die Installation des DEB-Pakets — und ein Update — erfolgt unter root mit dem Befehl dpkg -i:

root@linux# dpkg -i check-mk-agent_2.1.0b1-1_all.deb
(Reading database ... 739920 files and directories currently installed.)
Preparing to unpack .../check-mk-agent_2.1.0b5-1_all.deb ...
Unpacking check-mk-agent (2.1.0b5-1) ...
Setting up check-mk-agent (2.1.0b5-1) ...

Deploying systemd units: check-mk-agent.socket check-mk-agent-async.service cmk-agent-ctl-daemon.service check-mk-agent@.service
Deployed systemd
Creating/updating cmk-agent user account ...

WARNING: The agent controller is operating in an insecure mode! To secure the connection run cmk-agent-ctl register.

Reloading xinetd
Activating systemd unit 'check-mk-agent.socket'...
Created symlink /etc/systemd/system/sockets.target.wants/check-mk-agent.socket → /lib/systemd/system/check-mk-agent.socket.
Activating systemd unit 'check-mk-agent-async.service'...
Created symlink /etc/systemd/system/multi-user.target.wants/check-mk-agent-async.service → /lib/systemd/system/check-mk-agent-async.service.
Activating systemd unit 'cmk-agent-ctl-daemon.service'...
Created symlink /etc/systemd/system/multi-user.target.wants/cmk-agent-ctl-daemon.service → /lib/systemd/system/cmk-agent-ctl-daemon.service.

Hier wurde das Paket auf einem zuvor agentenlosen Host erstmalig installiert. Der Benutzer cmk-agent wurde erstellt und systemd konfiguriert. Auf die dazwischen angezeigte Warnung zum insecure mode, also dem Legacy-Pull-Modus, gehen wir gleich ein.

3.3. Installation mit der Agentenbäckerei

CEE Die CEE Checkmk Enterprise Editions verfügen mit der Agentenbäckerei über ein Software-Modul zum automatischen Paketieren von individuell angepassten Agenten. Eine ausführliche Beschreibung dazu finden Sie im allgemeinen Artikel über die Agenten. Die Installation der gebackenen Pakete geschieht genauso wie es für die mitgelieferten Pakete oben beschrieben ist.

3.4. Automatisches Update

CEE Wenn Sie die Agentenbäckerei verwenden, können Sie automatische Updates des Agenten einrichten. Diese werden in einem eigenen Artikel beschrieben.

3.5. Wie geht es weiter nach der Installation?

Falls der Agent Controller bei der Installation mit systemd konfiguriert werden konnte, ist der nächste Schritt die Registrierung, mit der die TLS-Verschlüsselung eingerichtet wird, so dass die verschlüsselte Agentenausgabe vom Checkmk-Server entschlüsselt und im Monitoring angezeigt werden kann.

Eine Besonderheit gibt es, falls der Agent mit Agent Controller erstmalig installiert wurde. Dann schaltet der Agent in den unverschlüsselten Legacy-Pull-Modus, damit der Checkmk-Server nicht von den Monitoring-Daten abgeschnitten wird und diese weiterhin anzeigen kann. Das betrifft sowohl eine Neuinstallation als auch das Update eines Agenten der Version 2.0.0 und älter.

Einen Hinweis auf den aktivierten Legacy-Pull-Modus erhalten Sie bereits in der Kommandoausgabe bei der Installation des Agenten. Im Monitoring sieht das dann etwa so aus:

Der WARN-Zustand des 'Check_MK' Services wegen fehlender Verschlüsselung.
Warnung im Checkmk-Monitoring, dass TLS noch nicht genutzt wird

Die Checkmk-Instanz erkennt an der Agentenausgabe, dass der Agent Controller vorhanden und damit die TLS-Verschlüsselung möglich ist — aber noch nicht eingeschaltet ist. Der Service Check_MK Agent wechselt in den Zustand WARN und bleibt es solange, bis Sie die Registrierung durchgeführt haben. Nach der Registrierung wird nur noch im verschlüsselten Pull-Modus kommuniziert. Der Legacy-Pull-Modus wird abgeschaltet und bleibt es auch. Allerdings kann er im Bedarfsfall per Kommando wieder eingeschaltet werden.

Anders liegt der Fall, wenn der Agent Controller sich während der Installation nicht als Daemon bei systemd registrieren konnte. Dann ist die Registrierung des Hosts nicht möglich und der einzige Kommunikationsweg verbleibt der Legacy-Modus. Im nächsten Kapitel können Sie durch Test von Agent Controller und Systemumgebung feststellen, ob Sie mit der Registrierung fortsetzen können.

Hinweis: Im Regelsatz Checkmk Agent installation auditing finden Sie verschiedene Einstellungen, um den Zustand des Agenten zu prüfen und im Monitoring sichtbar zu machen. Unter anderem können Sie hier festlegen, welchen Zustand der Service Check_MK Agent bei einer noch nicht durchgeführten TLS-Konfiguration haben soll.

4. Registrierung

4.1. Übersicht und Voraussetzungen

Unmittelbar nach der Installation des neuen Agenten (auch als Update eines Agenten der Version 2.0.0 und älter) ist nur unverschlüsselte Kommunikation im Legacy-Pull-Modus möglich. Eine ausschließlich verschlüsselte Datenübertragung ist erst nach Aufbau eines Vertrauensverhältnisses aktiv.

Führen Sie die Registrierung daher zeitnah nach Installation/Update durch. Wie Sie dies bewerkstelligen, zeigt dieses Kapitel.

Die Registrierung und damit die Herstellung des gegenseitigen Vertrauensverhältnisses erfolgt unter einem Checkmk-Benutzer mit Zugriff auf die REST-API. Dafür bietet sich der Automationsbenutzer an, der bei jeder Checkmk-Installation automatisch angelegt wird und dessen Passwort Sie auswürfeln können.

Voraussetzungen auf dem Host

Die Registrierung mit dem Agent Controller setzt ein Linux-System voraus mit einem init-System systemd ab Version 220 und einer x86_64-Rechnerarchitektur. Im Abschnitt Agent Controller und Systemumgebung testen erfahren Sie, wie Sie diese Voraussetzungen überprüfen.

Voraussetzungen auf dem Checkmk-Server

Damit die Registrierung direkt auf dem ins Monitoring aufzunehmenden Host durchgeführt werden kann, muss dieser die REST-API des Checkmk-Servers (Port 443 oder 80) und den Agent Receiver (Port 8000 bei der ersten Instanz, 8001 bei der zweiten…) erreichen können. Lesen Sie den Abschnitt Netzwerkumgebung für die Registrierung, falls in Ihrer IT-Infrastruktur eine dieser Bedingungen nicht erfüllt werden kann.

4.2. Host ins Setup aufnehmen

Erstellen Sie zunächst den neuen Host über Setup > Hosts > Add host. Ein Host muss in der Konfigurationsumgebung existieren, bevor er registriert werden kann.

4.3. Agent Controller und Systemumgebung testen

Der Agent mit Agent Controller setzt eine Linux-Distribution mit systemd voraus, präziser systemd in einer Version 220 oder neuer.

Die Chance ist groß, dass diese Voraussetzung auf Ihrem Host erfüllt ist, da seit 2015 die meisten Linux-Distributionen systemd als init-System übernommen und damit andere init-Systeme wie SysVinit ersetzt haben, z.B. SUSE Linux Enterprise Server ab Version 12, openSUSE ab Version 12.1, Red Hat Enterprise Linux ab Version 7, Fedora ab Version 15, Debian ab Version 8 und Ubuntu ab Version 15.04. Leider bringt der Vergleich der Versionsnummer alleine keine Gewissheit, da systemd auch auf einem aktuellen Linux-System fehlen kann, wenn dieses Jahre lang „nur“ aktualisiert wurde.

Prüfen Sie daher auf dem Host, auf dem der Agent installiert werden soll, ob und in welcher Version systemd läuft:

root@linux# systemctl --version
systemd 245 (245.4-4ubuntu3.15)

Die obige Kommandoausgabe zeigt, dass systemd in der richtigen Version installiert ist. Falls systemd nicht, oder nur in einer zu alten Version läuft, kann der Agent Controller nicht verwendet werden. Schließen Sie die Einrichtung ab wie im Artikel Linux überwachen im Legacy-Modus beschrieben.

Prüfen Sie nun, ob der Agent Controller gestartet werden kann:

root@linux# cmk-agent-ctl --version

Als Ausgabe sollte die Versionsnummer zu sehen sein, beispielsweise:

cmk-agent-ctl 0.1.0

In seltenen Fällen erscheint die folgende Fehlermeldung:

bash: /usr/bin/cmk-agent-ctl: cannot execute binary file: Exec format error

Ursache hierfür ist, dass Ihr Linux eine andere Rechnerarchitektur als x86_64 nutzt, zum Beispiel das ältere 32-Bit x86 oder ARM. In diesem Fall kann der Agent Controller nicht verwendet werden. Schließen Sie die Einrichtung ab wie im Artikel Linux überwachen im Legacy-Modus beschrieben.

Im nächsten Schritt gilt es herauszufinden, welches Programm auf Port 6556 auf Anfragen wartet:

root@linux# ss -tulpn | grep 6556
tcp	LISTEN	0	1024	0.0.0.0:6556	0.0.0.0:*	users:(("cmk-agent-ctl",pid=1861810,fd=9))

Hier ist es cmk-agent-ctl, die Voraussetzungen für verschlüsselte Kommunikation sind erfüllt. Steht innerhalb der Klammer stattdessen systemd, xinetd oder inetd, sind die Voraussetzungen für die Verwendung des Agent Controllers nicht gegeben. Schließen Sie auch in diesem Fall die Einrichtung wie im Artikel Linux überwachen im Legacy-Modus beschrieben, ab.

4.4. Host beim Server registrieren

Die Registrierung erfolgt mit dem Agent Controller cmk-agent-ctl, der für die Konfiguration der Verbindungen eine Kommandoschnittstelle bietet. Sie können sich mit dem Kommando cmk-agent-ctl help die Hilfe zu den Optionen anzeigen lassen.

Begeben Sie sich nun zum Host, der registriert werden soll. Hier ist mit root-Rechten eine Anfrage an die Checkmk-Instanz zu stellen:

root@linux# cmk-agent-ctl register --hostname mynewhost \
    --server cmkserver --site mysite \
    --user automation --password 'test23'

Dabei ist der Host-Name hinter der Option --hostname exakt so anzugeben, wie zuvor beim Erstellen im Setup. Die Optionen --server und --site geben den Namen des Checkmk-Servers und der Instanz an. Der Server-Name darf auch die IP-Adresse sein, der Instanzname (hier mysite) entspricht demjenigen, den Sie im URL-Pfad der Weboberfläche sehen. Komplettiert werden die Optionen durch Name und Passwort des Automationsbenutzers. Wenn Sie die Option --password auslassen, wird das Passwort interaktiv abgefragt.

Waren die angegebenen Werte korrekt, werden Sie aufgefordert, die Identität der Checkmk-Instanz zu bestätigen, zu der Sie die Verbindung herstellen wollen. Das zu bestätigende Server-Zertifikat haben wir aus Gründen der Übersichtlichkeit stark verkürzt:

Attempting to register at cmkserver:8000/mysite. Server certificate details:

PEM-encoded certificate:
---BEGIN CERTIFICATE---
MIIC6zCCAdOgAwIBAgIUXbSE8FXQfmFqoRNhG9NpHhlRJ40wDQYJKoZIhvcNAQEL
[...]
nS+9hN5ILfRI+wkdrQLC0vkHVYY8hGIEq+xTpG/Pxw==
---END CERTIFICATE---

Issued by:
	Site 'mysite' local CA
Issued to:
	localhost
Validity:
	From Thu, 10 Feb 2022 15:13:22 +0000
	To   Tue, 13 Jun 3020 15:13:22 +0000

Do you want to establish this connection? [Y/n]
> Y

Bestätigen Sie mit Y, um den Vorgang abzuschließen.

Falls keine Fehlermeldung angezeigt wird, ist die verschlüsselte Verbindung hergestellt. Über diese Verbindung werden alle Daten komprimiert übertragen.

4.5. Vertrauensverhältnis überprüfen

Das Kommando cmk-agent-ctl status zeigt nun genau ein Vertrauensverhältnis zum Checkmk-Server:

root@linux# cmk-agent-ctl status
Connection: 12.34.56.78:8000/mysite
	UUID: d38e7e53-9f0b-4f11-bbcf-d19617971595
	Local:
		Connection type: pull-agent
		Certificate issuer: Site 'mysite' local CA
		Certificate validity: Mon, 21 Feb 2022 11:23:57 +0000 - Sat, 24 Jun 3020 11:23:57 +0000
	Remote:
		Connection type: pull-agent
		Registration state: operational
		Host name: mynewhost

Hinweis: Es kann stets nur ein Vertrauensverhältnis zwischen Host und Instanz geben. Wenn Sie beispielsweise den bereits registrierten Host mynewhost unter anderem Namen (mynewhost2), aber mit der gleichen IP-Adresse registrieren, dann ersetzt die neue Verbindung die bestehende. Die Verbindung von mynewhost zur Instanz wird gelöst und für den Host werden keine Agentendaten mehr für das Monitoring geliefert.

4.6. Im Auftrag registrieren

Zur leichteren Registrierung mehrerer Hosts kann ein beliebiger Host, auf dem der Agent installiert ist, eine Registrierung im Auftrag anderer durchführen. Dabei wird eine JSON-Datei exportiert, die dann auf den Ziel-Host übertragen und dort importiert werden kann. Auch hier gilt wie zuvor: Der im Auftrag registrierte Host muss in der Instanz bereits eingerichtet sein.

Zunächst wird auf einem beliebigen im Setup befindlichen Host die Registrierung stellvertretend durchgeführt. Hier bietet sich natürlich der Checkmk-Server an, der in der Regel als erster Host eingerichtet wird. Wie beim Beispiel oben gilt, dass Sie das Passwort per Option übergeben können oder interaktiv danach gefragt werden, wenn Sie die Option --password weglassen. Die JSON-Ausgabe leiten wir im Beispiel in eine Datei um:

root@linux# cmk-agent-ctl proxy-register \
    --hostname mynewhost3  \
    --server cmkserver --site mysite \
    --user automation > /tmp/mynewhost3.json

Nun übertragen wir die Datei /tmp/mynewhost3.json auf den Host, für den wir die Registrierung durchgeführt haben, und importieren die Datei:

root@linux# cmk-agent-ctl import /tmp/mynewhost3.json

Der gesamte Vorgang ist auch in einer Pipeline möglich, in der Sie die Ausgabe von cmk-agent-ctl proxy-register an ssh hostname cmk-agent-ctl import übergeben:

root@linux# cmk-agent-ctl proxy-register --hostname mynewhost3 \
    --server cmkserver --site mysite \
    --user automation --password 'test23' | \
    ssh root@mynewhost3 cmk-agent-ctl import

4.7. Host ins Monitoring aufnehmen

Sobald die Registrierung fertiggestellt ist, führen Sie im Setup des Checkmk-Servers einen Verbindungstest und eine Service-Erkennung durch. Anschließend nehmen Sie die gefundenen Services ins Monitoring auf, indem Sie als letzten Schritt die Änderungen aktivieren.

Falls der Verbindungstest fehlschlägt, finden Sie im folgenden Kapitel Informationen zu Test und Fehlerdiagnose.

4.8. Host deregistrieren

Die Registrierung eines Hosts können Sie auch wieder rückgängig machen.

Auf einem Host, der mit dem Checkmk-Server verbunden ist, können Sie das Vertrauensverhältnis widerrufen. Dabei ist im folgenden Kommando der anzugebende Universally Unique Identifier (UUID) derjenige, der beim Kommando cmk-agent-ctl status ausgegeben wird:

root@linux# cmk-agent-ctl delete d38e7e53-9f0b-4f11-bbcf-d19617971595

Um alle Verbindungen des Hosts zu entfernen und zusätzlich den Legacy-Pull-Modus wiederherzustellen, geben Sie folgendes Kommando ein:

root@linux# cmk-agent-ctl delete-all --enable-insecure-connections

Anschließend verhält sich der Agent wie nach der erstmaligen Installation und vor der ersten Registrierung und sendet seine Daten unverschlüsselt.

Komplettiert wird die Deregistrierung auf dem Checkmk-Server: Im Setup wählen Sie auf der Seite Properties of host den Menüeintrag Host > Remove TLS registration aus und bestätigen die Nachfrage.

Falls Sie die Kommandozeile bevorzugen: Auf dem Checkmk-Server existiert für jede Verbindung eines registrierten Hosts, der sich im Monitoring befindet, ein Softlink mit der UUID, welcher auf den Ordner mit der Agentenausgabe zeigt:

OMD[mysite]:~$ cd ~/var/agent-receiver/received-outputs
OMD[mysite]:~$ ls -l d38e7e53-9f0b-4f11-bbcf-d19617971595
lrwxrwxrwx 1 mysite mysite 67 Feb 23 07:18 d38e7e53-9f0b-4f11-bbcf-d19617971595 -> /omd/sites/mysite/tmp/check_mk/data_source_cache/push-agent/mynewhost

Wenn Sie diesen Softlink löschen, ist eine erneute Registrierung des Hosts erforderlich.

5. Test und Fehlerdiagnose

Ein modulares System kann an vielen Stellen nicht wie vorgesehen funktionieren. Da mit dem Agenten in der 2.1.0 die beiden Komponenten Agent Controller auf dem Host und Agent Receiver auf dem Checkmk-Server eingeführt wurden, steigt die Zahl der Stellen, an denen etwas schief gehen kann.

Bei der Fehlersuche ist daher eine strukturierte Vorgehensweise sinnvoll. Selbstverständlich können Sie die hier beschriebene schrittweise Analyse auch nutzen, die Datenerhebung und Kommunikation von Checkmk näher kennenzulernen.

Alle Möglichkeiten, die es vom Checkmk-Server aus gibt, sind im allgemeinen Artikel über die Monitoring-Agenten beschrieben. Aber natürlich gibt es noch weitere Diagnosemöglichkeiten, wenn man direkt auf dem überwachten Host selbst eingeloggt ist.

Wir arbeiten uns im Folgenden vom Agentenskript über den Agent Controller und den TCP-Port 6556 bis zur Checkmk-Instanz durch. In den meisten Fällen können Sie nach Korrektur eines Fehlers die Service-Erkennung erneut starten und die Aufnahme ins Monitoring abschließen.

5.1. Ausgabe des Agentenskripts

Das Agentenskript ist ein einfaches Shellskript, welches Daten über Ihr System beschafft und als lose formatierten Text ausgibt. Sie können es direkt auf der Kommandozeile aufrufen. Da die Ausgabe etwas länger sein kann, ist der Pager less zum Scrollen der Ausgabe hier sehr praktisch. Sie können Ihn mit der Taste Q verlassen:

root@linux# check_mk_agent | less
<<<check_mk>>>
Version: 2.1.0b1
AgentOS: linux
Hostname: mynewhost
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
AgentController: cmk-agent-ctl 0.1.0

So ermitteln Sie, ob in der Ausgabe alle gewünschten Daten enthalten sind – beispielsweise, ob alle installierten Plugins die erwartete Ausgabe liefern.

Sie müssen übrigens nicht unbedingt root sein, um den Agenten aufzurufen. Allerdings werden dann in der Ausgabe einige Informationen fehlen, zu deren Beschaffung root-Rechte erforderlich sind (z.B. Multipath-Informationen und die Ausgaben von ethtool).

5.2. Agentenskript im Debug-Modus

Damit eventuelle Fehlerausgaben von nicht funktionierenden Plugins oder Befehlen nicht die eigentlichen Daten „verunreinigen“, unterdrückt das Agentenskript generell den Standardfehlerkanal (STDERR). Sind Sie auf der Suche nach einem bestimmten Problem, können Sie diesen wieder aktivieren, indem Sie das Agentenskript in einem speziellen Debug-Modus aufrufen. Das machen Sie mit der Option -d. Dabei werden auch sämtliche Shellbefehle ausgegeben, die das Skript ausführt.

Damit Sie hier mit less arbeiten können, müssen Sie Standardausgabe (STDOUT) und Fehlerkanal mit 2>&1 zusammenfassen:

root@linux# check_mk_agent -d 2>&1 | less

5.3. Netzwerkumgebung für die Registrierung

Schlägt die Registrierung eines Hosts im Monitoring fehl, ohne dass überhaupt das Zertifikat angezeigt wird, hilft Kenntnis der involvierten Netzwerkkommunikation bei der Identifizierung des Problems — und natürlich bei der Behebung.

Nach Absetzen des Kommandos cmk-agent-ctl register fragt der Agent Controller zunächst mittels REST-API den Checkmk-Server nach dem Port des Agent Receivers. Im zweiten Schritt wird eine Verbindung zum Agent Receiver aufgebaut, um das Zertifikat abzurufen. Sie können die erste Anfrage auf dem Host mit einem Programm wie curl simulieren:

root@linux# curl -v --insecure https://mycmkserver/mysite/check_mk/api/1.0/domain-types/internal/actions/discover-receiver/invoke

Der Parameter --insecure weist curl hier an, keine Zertifikatsprüfung vorzunehmen. Dieses Verhalten entspricht dem Verhalten des Agent Controller an dieser Stelle. Die Antwort ist lediglich wenige Byte groß und besteht aus der Port-Nummer des Agent Receiver. Bei der ersten Instanz auf einem Server wird die Antwort einfach 8000 lauten, bei der zweiten 8001 und so weiter. Typische Probleme bei dieser Anfrage sind:

  • Der Checkmk-Server ist vom Host aus gar nicht erreichbar.

  • Der von der REST-API verwendete Port weicht von den Standard-Ports 443 (https) oder 80 (http) ab.

Falls die obige Anfrage fehlschlägt, können Sie die Routing- oder Firewall-Einstellungen so verändern, dass der Zugriff möglich ist, beziehungsweise die interne CA der Trust Chain des Hosts hinzufügen.

Wenn der zu registrierende Host einen HTTP-Proxy verwendet, nutzt curl diesen, cmk-agent-ctl jedoch nicht in den Standardeinstellungen. Mit der zusätzlichen Option --detect-proxy weisen Sie cmk-agent-ctl an, den systemweit konfigurierten Proxy zu nutzen.

Oft dürfte es am einfachsten sein, auf dem Checkmk-Server den Port des Agent Receiver auszulesen und zu notieren. Führen Sie dazu den folgenden Befehl als Instanzbenutzer aus:

OMD[mysite]:~$ omd config show | grep AGENT_RECEIVER
AGENT_RECEIVER: on
AGENT_RECEIVER_PORT: 8000

Sie können nun den ermittelten Port bei der Registrierung direkt angeben und so die erste Anfrage via REST-API überspringen. Die Kommunikation findet dann ohne Umwege direkt mit dem Agent Receiver statt:

root@linux# cmk-agent-ctl register --hostname mynewhost \
    --server mycmkserver:8000 --site mysite \
    --user automation --password 'test23'

Auch dieser Port 8000 muss vom Host aus erreichbar sein. Ist er das nicht, erhalten Sie die eindeutige Fehlermeldung:

ERROR [cmk_agent_ctl] Connection refused (os error 111)

Analog zu Port 443 (respektive 80) oben können Sie jetzt die Routing- oder Firewall-Einstellungen so anpassen, dass der zu registrierende Host den Checkmk-Server auf dem Port des Agent Receiver (8000 oder 8001…) erreichen kann.

Sollten Sicherheitsrichtlinien in Ihrer Umgebung den Zugriff auf den Agent Receiver nicht zulassen, haben sie die Möglichkeit, auf dem Checkmk-Server selbst die Registrierung im Auftrag vorzunehmen.

5.4. Agent Controller im Dump-Modus

Der Agent Controller stellt ein eigenes Subkommando dump bereit, das die vollständige Agentenausgabe anzeigt, wie sie im Monitoring ankommt:

root@linux# cmk-agent-ctl dump | less
<<<check_mk>>>
Version: 2.1.0b1
AgentOS: linux
Hostname: mynewhost

So können Sie überprüfen, ob die Daten vom Agentenskript beim Agent Controller angekommen sind. Diese Ausgabe beweist noch nicht, dass der Agent auch über das Netzwerk erreichbar ist.

In einigen Fällen sieht die Ausgabe wie folgt aus:

ERROR [cmk_agent_ctl] Error collecting monitoring data.

Caused by:
    No such file or directory (os error 2)

Dies ist der Fall, wenn der Agent Controller Daemon nicht im Hintergrund läuft – beispielsweise unmittelbar nach einem Update. Starten Sie diesen Hintergrundprozess neu:

root@linux# systemctl restart cmk-agent-ctl-daemon

Schlägt cmk-agent-ctl dump erneut fehl, prüfen Sie, ob und wenn, welches Programm an Port 6556 lauscht:

root@linux# ss -tulpn | grep 6556
tcp	LISTEN	0	1024	0.0.0.0:6556 0.0.0.0:*	users:(("cmk-agent-ctl",pid=1861810,fd=9))

Ist die Ausgabe leer oder innerhalb der Klammer steht ein anderer Befehl als cmk-agent-ctl, sind die Systemvoraussetzungen für die Nutzung des Agent Controllers nicht erfüllt. Schließen Sie in diesem Fall die Einrichtung ab wie im Artikel Linux überwachen im Legacy-Modus beschrieben.

5.5. Verbindungstest von außen

Ist sichergestellt, dass lokal das Agentenskript und die mitinstallierten Plugins korrekt ausgeführt werden, können Sie als Nächstes per netcat (oder nc) prüfen, ob Port 6556 über die externe IP-Adresse des Hosts erreichbar ist:

root@linux# echo | nc 10.76.23.189 6556
16

Die Ausgabe 16 zeigt an, dass die Verbindungsaufnahme erfolgreich war und nun der TLS-Handshake stattfinden kann. Da alles weitere hier TLS verschlüsselt stattfindet, ist keine detaillierte Prüfung möglich.

Schlägt der Verbindungstest von außen fehl, liegt dies meist an der Firewall-Einstellung. Konfigurieren Sie iptables oder nftables in diesem Fall so, dass Zugriff auf TCP Port 6556 vom Checkmk-Server aus möglich ist.

Falls die Kommunikation zwischen Agent und Checkmk-Server noch unverschlüsselt ist (wie im Legacy-Pull-Modus) oder unverschlüsselt ist und auch bleibt (wie im Legacy-Modus), erhalten Sie mit diesem Kommando statt der 16 die komplette unverschlüsselte Agentenausgabe.

Hinweis: Weitere Diagnosemöglichkeiten zur Ausführung auf dem Checkmk-Server finden Sie im allgemeinen Artikel über die Monitoring-Agenten.

Bleibt die Ausgabe auch nach Registrierungsversuch unverschlüsselt, verwenden Sie grep, um den Status aus der Ausgabe zu ermitteln:

root@linux# echo | nc 10.76.23.189 6556 | grep -A1 cmk_agent_ctl_status
<<<cmk_agent_ctl_status:sep(0)>>>
{"version":"0.1.0","ip_allowlist":[],"allow_legacy_pull":false, ... }

Ist die Variable allow_legacy_pull auf false gesetzt, erlaubt der Agent Controller selbst keine Klartextausgabe, aber für TCP Port 6556 ist ein anderer Dienst, beispielsweise xinetd zuständig. Dies ist gelegentlich Zustand nach Update eines Systems, das die Voraussetzungen für die Verwendung des Agent Controller nicht erfüllt. Führen Sie in diesem Fall zuerst eine Deregistrierung durch und schließen Sie dann die Einrichtung ab wie im Artikel Linux überwachen im Legacy-Modus beschrieben.

6. Absicherung

6.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.

6.2. Transport Layer Security (TLS)

Für einen Angreifer kann jedoch bereits eine Prozessliste ein erster Ansatz sein, Rückschlüsse auf lohnenswerte Ziele zu ziehen. Daher ist die Transportverschlüsselung zwischen Agent und Checkmk-Server mit Transport Layer Security (TLS) ab Checkmk-Version 2.1.0 obligatorisch. Hierbei "pingt" der Checkmk-Server den überwachten Host an, der daraufhin die TLS-Verbindung zum Checkmk-Server aufbaut und darüber die Agentenausgabe überträgt. Da nur Checkmk-Server, zu denen ein Vertrauensverhältnis besteht, diese Datenübertragung initiieren können, besteht schon einmal kein Risiko, dass Daten in die falschen Hände gelangen.

6.3. Zugriff über IP-Adressen beschränken

Da nur autorisierte Checkmk-Server Daten abrufen können und nicht berechtigte Server nach einigen Bytes Handshake scheitern, ist die Gefahr einer Denial of Service (DoS) Attacke sehr gering. Aus diesem Grund ist aktuell keine weitere Zugriffsbeschränkung vorgesehen. Selbstverständlich können Sie Port 6556 per iptables gegen unberechtigten Zugriff sperren. Eine möglicherweise vorhandene und per Agentenbäckerei auf Clients übertragene Regel zur Einschränkung des Zugriffs auf bestimmte IP-Adressen wird vom Agent Controller ignoriert.

6.4. Eingebaute Verschlüsselung abschalten

Insbesondere bei einem Update des Agenten kann es sein, dass die eingebaute (symmetrische) Verschlüsselung aktiv ist, die vom Agentenskript selbst durchgeführt wird. Sind TLS-Verschlüsselung und eingebaute Verschlüsselung gleichzeitig aktiv, dann ist die Entropie der übertragenen Daten so hoch, dass die ab Version 2.1.0 aktive Komprimierung keine Ersparnis der übertragenen Daten bringt – und die CPUs sowohl des Hosts als auch des Checkmk-Servers mit zusätzlichen weiteren Ver- und Entschlüsselungsschritten belasten.

Aus diesem Grund sollten Sie die eingebaute Verschlüsselung zeitnah nach dem Wechsel auf TLS deaktivieren. In der CRE Checkmk Raw Edition erreichen Sie das, indem Sie die Konfigurationsdatei /etc/check_mk/encryption.cfg umbenennen.

CEE In den CEE Checkmk Enterprise Editions können Sie vorhandene Regeln unter Setup > Agents > Access to agents > Encryption (Linux, Windows) im Abschnitt Encryption (Linux, Windows) auf Use TLS encryption umstellen und anschließend die Agentenpakete neu backen. Nach dem nächsten automatischen Agenten-Update ist die Verschlüsselung des Agentenskriptes abgeschaltet, aber durch den Agent Controller die Verschlüsselung garantiert. Beachten Sie, dass nach dem automatischen Agenten-Update nur noch registrierte Hosts Monitoring-Daten liefern können.

7. Sektionen deaktivieren

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 30 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 von Hosts schlicht nicht interessieren, oder dass ein bestimmter Host fehlerhafte Werte liefert und Sie den Abruf dieser Daten kurzzeitig aussetzen wollen.

Als Nutzer einer der CEE 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.

Liste der Agentenregeln für den Linux-Agenten.
In den Enterprise Editions können Sie Sektionen per Regel deaktivieren

In der Regel finden Sie für jede deaktivierbare Sektion eine eigene Checkbox. Für jede angewählte Checkbox finden Sie dann — nachdem der neu gebackene Agent auf den ausgewählten Hosts installiert wurde — in der Konfigurationsdatei der Agentenbäckerei /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:

/etc/check_mk/exclude_sections.cfg
MK_SKIP_PS=yes
MK_SKIP_SYSTEMD=yes

Nutzer der CRE 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.

8. Agent um Plugins erweitern

8.1. Was sind Agentenplugins?

Das Agentenskript /usr/bin/check_mk_agent enthält eine ganze Reihe von Sektionen, welche Überwachungsdaten für diverse Check-Plugins liefern, die dann von der Service-Erkennung 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 Skripte 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 Service-Erkennung automatisch neue Services liefern.

Warum sind diese Plugins nicht einfach in den Agenten 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 benötigt 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).

8.2. Manuelle Installation

Die mitgelieferten Plugins für Linux und Unix finden Sie alle auf dem Checkmk-Server unter share/check_mk/agents/plugins. Auch über die Download-Seite der Agenten im Setup-Menü (wie im Kapitel Installation beschrieben) sind diese im Kasten Plugins verfügbar:

Download-Seite mit den Agentenplugins.
Der Anfang der langen Liste verfügbarer Agentenplugins

Zu allen von uns mitgelieferten Agentenplugins existieren die passenden Check-Plugins, welche deren Daten auswerten und Services erzeugen können. Diese sind bereits mitinstalliert, so dass neu gefundene Services sofort erkannt und konfiguriert werden können.

Hinweis: Bevor Sie ein Plugin auf dem Host installieren, werfen Sie 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 Download-Seite holen, geht die Ausführungsberechtigung verloren.

Sobald das Plugin ausführbar ist und im richtigen Verzeichnis liegt, wird es vom Agenten automatisch 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 an neuen Sektionen.

8.3. Konfiguration

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

8.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 /usr/lib/check_mk_agent/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 zwischengespeicherte Daten von der letzten Ausführung des Plugins. Damit können Sie 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 (oder 300 Sekunden) umgestellt wird:

root@linux# cd /usr/lib/check_mk_agent/plugins
root@linux# mkdir 300
root@linux# mv my_foo_plugin 300

Hinweis: 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.

8.5. Installation über die Agentenbäckerei

CEE In den CEE 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 in Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Agent Plugins:

Seite mit den Regeln zur Konfiguration der Agentenplugins in den Enterprise Editions.
Liste mit Regeln für die Agentenplugins in den Enterprise Editions

8.6. Manuelle Ausführung

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 gesetzte 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 in die Plugin-Datei.

9. Einbinden von klassischen (Nagios-) Check-Plugins

9.1. Plugins über MRPE ausführen

Es gibt zwei gute Gründe, Nagios-Plugins auch unter Checkmk zu nutzen. Wenn Sie Ihr Monitoring von einer Nagios basierten Lösung auf Checkmk migriert haben, können Sie ältere Check-Plugins, zu denen es noch kein Checkmk-Pendant gibt, zunächst weiternutzen. In vielen Fällen sind das selbst geschriebene Plugins in Perl oder Shell.

Der zweite Grund für die Verwendung von Nagios-Plugins ist echtes End-to-End-Monitoring. Nehmen wir an, Sie haben Ihren Checkmk-Server, einen Webserver und einen Datenbankserver über ein großes Rechenzentrum verteilt. In so einem Fall sind die Antwortzeiten des Datenbankservers vom Checkmk-Server aus gemessen wenig aussagekräftig. Weit wichtiger ist es, diese Werte für die Verbindung zwischen Web- und Datenbankserver zu kennen.

Der Checkmk-Agent bietet einen einfachen Mechanismus, diesen beiden Anforderungen gerecht zu werden: 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 als /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:

/etc/check_mk/mrpe.cfg
Foo_Application /usr/local/bin/check_foo -w 60 -c 80
Bar_Extender /usr/local/bin/check_bar -s -X -w 4:5

Hinweis: Die Nagios-Plugins dürfen nicht im Verzeichnis /usr/lib/check_mk_agent/plugins abgelegt werden. Dieses Verzeichnis ist den Agentenplugins vorbehalten. Abgesehen von diesem Verzeichnis steht Ihnen die Wahl frei, solange der Agent die Plugins dort finden und ausführen kann.

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 Service-Erkennung für den Host aufrufen, werden die beiden neuen Services als verfügbar angezeigt. Das sieht dann so aus:

Liste der erkannten Services für die per MRPE eingerichteten Plugins.
Für die beiden MRPE Plugins wird je ein Service erkannt

Ü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):

/etc/check_mk/mrpe.cfg
Foo%20Application /usr/local/bin/check_foo -w 60 -c 80
Bar%20Extender /usr/local/bin/check_bar -s -X -w 4:5

9.2. Asynchrone Ausführung

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 läuft 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):

/etc/check_mk/mrpe.cfg
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.

9.3. MRPE mit der Agentenbäckerei

CEE 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.

Regel zur MRPE-Konfiguration in der Agentenbäckerei.
MRPEs können in den Enterprise Editions bequem per Regel konfiguriert werden

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:

  1. Erzeugen Sie auf dem Checkmk-Server das Verzeichnis local/share/check_mk/agents/custom.

  2. Erzeugen Sie dort ein Unterverzeichnis — z.B. my_mrpe_plugins.

  3. Erzeugen Sie wiederum darin das Unterverzeichnis bin.

  4. Kopieren Sie Ihre Plugins in den bin-Ordner.

  5. Legen Sie eine Regel in Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Generic Options > Deploy custom files with agent an.

  6. 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.

10. Hardware überwachen

Zu einer möglichst vollständigen Überwachung eines Linux-Servers gehört natürlich auch die Hardware. Die Überwachung 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.

10.1. Ü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 zum 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) und megacli (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:

Liste gefundener SMART-Services in der Service-Erkennung.
Von der Service-Erkennung gefundene SMART-Services

Sollte — wie im Screenshot zu sehen — gelegentlich cmd_timeout auftreten, stellen Sie das Plugin auf asynchrone Ausführung im Abstand einiger Minuten um.

10.2. Überwachung mit Hilfe von IPMI

IPMI (Intelligent Platform Management Interface) ist eine Schnittstelle zum Hardware-Management, welche auch die Überwachung der Hardware ermöglicht. Checkmk nutzt dafür freeipmi, um direkt und ohne Netzwerk auf die Hardware zuzugreifen. freeipmi wird aus den Paketquellen installiert und ist danach sofort einsatzbereit, so dass die Daten schon beim 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. ipmitool 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

10.3. Herstellerspezifische Tools

Viele große Server-Hersteller bieten auch eigene Tools an, um die Hardware-Informationen 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 Überwachung per SNMP zusätzlich zum Checkmk-Agenten konfiguriert. Im Artikel zur Überwachung mit SNMP erfahren Sie, wie das geht.

Die dadurch unterstützten neuen Services für die Hardware-Überwachung werden dann automatisch erkannt. Es werden keine weiteren Plugins benötigt.

10.4. 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 Managementboards ist dabei sehr einfach. Geben Sie in den Eigenschaften des Hosts lediglich das Protokoll, die IP-Adresse und die Zugangsdaten für SNMP an und speichern Sie die neuen Einstellungen ab:

Die Konfiguration des Managementboards für SNMP in den Eigenschaften des Hosts.
In den Eigenschaften des Hosts im Setup wird das Managementboard für SNMP konfiguriert

In der Service-Erkennung werden die neu erkannten Services dann wie gewohnt aktiviert.

11. Deinstallation

Wie die Installation erfolgt auch die Deinstallation des Agenten mit dem Paketmanager des Betriebssystems. Geben Sie hier den Namen des installierten Pakets an, nicht den Dateinamen der ursprünglichen RPM/DEB-Datei.

So finden Sie heraus, welches DEB-Paket installiert ist:

root@linux# dpkg -l | grep check-mk-agent
ii  check-mk-agent          2.1.0b1-1          all          Checkmk Agent for Linux

Die Deinstallation des DEB-Pakets erfolgt dann mit dpkg --purge:

root@linux# dpkg --purge check-mk-agent
(Reading database ... 739951 files and directories currently installed.)
Removing check-mk-agent (2.1.0b5-1) ...
Removing systemd units: check-mk-agent.socket, check-mk-agent-async.service, cmk-agent-ctl-daemon.service, check-mk-agent@.service
Deactivating systemd unit 'check-mk-agent.socket'...
Deactivating systemd unit 'check-mk-agent-async.service'...
Deactivating systemd unit 'cmk-agent-ctl-daemon.service'...
Reloading xinetd
Purging configuration files for check-mk-agent (2.1.0b5-1) ...

So finden Sie heraus, welches RPM-Paket installiert ist:

root@linux# rpm -qa | grep check-mk

Die Deinstallation des RPM-Pakets erfolgt unter root mit dem Befehl rpm -e.

12. Dateien und Verzeichnisse

12.1. Pfade auf dem überwachten Host

PfadBedeutung

/usr/bin/

Installationsverzeichnis für das Agentenskript check_mk_agent und des Agent Controllers cmk-agent-ctl auf dem Zielsystem.

/usr/lib/check_mk_agent

Basisverzeichnis für Erweiterungen des Agenten.

/usr/lib/check_mk_agent/plugins

Verzeichnis für Plugins, welche automatisch vom Agenten ausgeführt werden sollen und dessen Ausgabe um zusätzliche Überwachungsdaten erweitern. Plugins können in jeder verfügbaren Programmiersprache geschrieben werden.

/usr/lib/check_mk_agent/local

Verzeichnis für eigene lokale Checks.

/var/lib/check_mk_agent

Basisverzeichnis für Daten des Agenten.

/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.

/var/lib/cmk-agent/registered_connections.json

Enthält eine Liste der mit dem Agent Controller registrierten Verbindungen.

/var/agent-receiver/received-outputs

Enthält für jede Verbindung deren UUID als Softlink, der auf den Ordner mit der Agentenausgabe zeigt.

/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 eingebaute Verschlüsselung der Agentendaten.

/etc/check_mk/exclude_sections.cfg

Konfigurationsdatei für die Deaktivierung bestimmter Sektionen des Agenten.

12.2. Pfade auf dem Checkmk-Server

PfadBedeutung

local/share/check_mk/agents/custom

Basisverzeichnis für eigene Dateien, die mit einem gebackenen Agenten ausgeliefert werden sollen.

share/check_mk/agents/cfg_examples/exclude_sections.cfg

Beispielhafte Konfigurationsdatei für das Deaktivieren von Sektionen.

Auf dieser Seite