1. Der Windows-Agent
Die Überwachung von Windows-Servern war von Anfang an eine der wichtigsten Aufgaben von Checkmk. Wie für alle anderen Server-Betriebssysteme liefert Checkmk daher auch für Windows einen eigenen Agenten aus. Dieser ist ein Agentenprogramm, das minimalistisch und sicher ist.
In der Checkmk-Version 2.1.0 wurde diesem Agentenprogramm mit dem Agent Controller eine neue Komponente zur Seite gestellt. Der Agent Controller ist dem Agentenprogramm vorgeschaltet, fragt dieses ab und kommuniziert an dessen Stelle mit dem Checkmk-Server. Dazu registriert er sich am Agent Receiver, einem Prozess, der auf dem Checkmk-Server läuft.
Der Windows-Agent übernimmt also zum einen das Agentenprogramm, und damit dessen Vorteile. Zum anderen ergänzt er das Programm so, dass neue Funktionen hinzugefügt werden können wie die TLS-Verschlüsselung der Kommunikation oder die Datenkomprimierung.
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. Ab der Checkmk-Version 2.2.0 gibt es in Checkmk Cloud zusätzlich den Push-Modus, welcher die Überwachung von Hosts hinter Firewalls erleichtert. Kombiniert wird dieser meist mit der automatischen Registrierung des Checkmk-Agenten.
Standard-Agentenpakete öffnen sofort nach der Installation Port 6556. Sie geben darüber die unverschlüsselte Agentenausgabe an jeden, der sie anfordert aus. Bei Hosts, die aus dem Internet erreichbar sind, sollten Sie daher vor der Installation per Firewall sicherstellen, dass der Zugriff auf diesen Port nur ausgewählten Hosts erlaubt ist. Führen Sie die Registrierung und die damit verbundene Aktivierung der TLS-Verschlüsselung zeitnah nach der Installation durch. |
Aus Kompatibilitätsgründen unterstützt der Agent nur die aktuellen Versionen der Microsoft Windows NT Produktlinie (Edition).
Die folgende Tabelle listet diese explizit auf.
In der Spalte Version finden Sie den Anfang der Versionsnummer, die Sie sich mit den Kommandos ver
und systeminfo
auf dem Windows-System ausgeben lassen können.
Edition | Version |
---|---|
Windows 10, 11, Windows Server 2016, 2019, 2022 |
10.0 |
Wichtig: Editionen, die in der Tabelle nicht erwähnt werden, werden nicht offiziell unterstützt. Dazu gehört zum Beispiel auch Windows Embedded. Für die Überwachung älterer Windows-Editionen, wie z.B. Windows Server 2008, können Sie auf eigenes Risiko einen Legacy-Agenten verwenden. Ein Legacy-Agent ist ein Agent einer älteren Checkmk-Version ohne Agent Controller, der dann auch nicht die an den Agent Controller gekoppelten Features bietet wie TLS-Verschlüsselung und Datenkomprimierung. Legacy-Agenten stellen wir hier zum Download zur Verfügung. Für einen Legacy-Agenten sind einige Besonderheiten zu beachten, die im Installationskapitel zusammengefasst sind.
Die Installation, Registrierung und Einrichtung des Agenten ist mit wenigen Schritten erledigt, denn dieser braucht für seine Funktion zum Beispiel keine zusätzlichen Bibliotheken. Zudem wird der Agent mit einer Grundkonfiguration ausgeliefert, die für die meisten Anwendungsfälle ausreicht.
2. Architektur des Agenten
Der Checkmk-Agent besteht aus dem Agentenprogramm 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 Windows spezifische Implementierung.
Das Agentenprogramm check_mk_agent.exe
ist zuständig für die Sammlung der Monitoring-Daten.
Es wird als Windows-Dienst unter dem LocalSystem-Konto gestartet.
Es sammelt bei einem Aufruf Daten zu dem lokalen System und stellt sie dem Agent Controller zur Verfügung.
Das Agentenprogramm ist minimalistisch, sicher, leicht erweiterbar und umfassend, denn es hat Zugriff auf wichtige Daten, die per WMI oder SNMP nicht erreichbar sind. In einigen Fällen kann allerdings die Überwachung per SNMP zusätzlich zum Checkmk-Agenten sinnvoll sein. Im Artikel zur Überwachung mit SNMP finden Sie mehr zu diesem Thema. Außerdem ist das Agentenprogramm so transparent, wie es eine als ausführbar gelieferte Datei sein kann, denn Sie haben jederzeit Zugriff auf den Quellcode und damit Einsicht in die Funktionalität und können den Agenten prinzipiell auch selbst kompilieren.
Der Agent Controller cmk-agent-ctl.exe
kümmert sich um den Transport der vom Agentenprogramm gesammelten Daten.
Er wird als Hintergrundprozess unter dem LocalSystem-Konto von Windows ausgeführt.
Im Pull-Modus lauscht er am TCP-Port 6556 auf eingehende Verbindungen der Checkmk-Instanz und fragt das Agentenprogramm über Mailslot ab.
3. Installation
Checkmk bietet Ihnen für die Installation des Windows-Agenten verschiedene Wege — von der manuellen Installation des Software-Pakets bis hin zur vollautomatischen Verteilung inklusive Update-Funktion. Manche davon stehen nur in den kommerziellen Editionen zur Verfügung:
Methode | Beschreibung | Checkmk Raw | Kommerzielle Editionen |
---|---|---|---|
Mitgeliefertes MSI-Paket |
Einfache Installation eines Standard-Agenten mit manueller Konfiguration über Konfigurationsdateien. |
X |
X |
MSI-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 |
Alternativ können Sie das MSI-Paket auch über andere Wege, wie zum Beispiel das Microsoft Active Directory, verteilen. Die Installation kann hier durch das MSI-Format komplett automatisiert werden.
3.1. Download des MSI-Pakets
Sie installieren den Windows-Agenten durch Installation des MSI-Pakets.
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 Checkmk Raw finden Sie das Windows-Paket des Agenten über Setup > Agents > Windows. In den kommerziellen Editionen 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 > Windows files zur Liste der Agentendateien:
Alles, was Sie brauchen, finden Sie gleich im ersten Kasten mit dem Namen Packaged Agents:
die fertige MSI-Paketdatei check_mk_agent.msi
für die Installation des Windows-Agenten mit Standardeinstellungen.
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.
Per REST-API haben Sie die Möglichkeit, das Paket vom Checkmk-Server direkt auf den Zielrechner zu holen.
Das mitgelieferte MSI-Paket des Windows-Agenten lässt sich beispielsweise mit dem folgenden curl
-Kommando holen.
In neueren Windows-Versionen wird curl
bereits mitgeliefert, in älteren müssen Sie sich vorher die curl
-Kommandoumgebung per curl for Windows extra installieren.
C:\Users\hhirsch\Downloads\> 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=windows_msi"
Hinweis: Der Befehl wurde zugunsten der Lesbarkeit in vier Zeilen aufgeteilt.
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
Manuelle Installation
Nachdem Sie das MSI-Paket geholt und — falls nötig — mit scp
, WinSCP oder anderen Mitteln auf den zu überwachenden Host kopiert haben, starten Sie die Installation entweder per Doppelklick auf die MSI-Datei oder wie folgt von der Kommandozeile:
C:\Users\hhirsch\Downloads\> check_mk_agent.msi
Sie erhalten die Startseite des Setup-Assistenten:
Mit den Next-Knöpfen hangeln Sie sich durch die Seiten des Assistenten. Akzeptieren Sie die Lizenzbedingungen der GNU GENERAL PUBLIC LICENSE, um fortzufahren. Anschließend präsentiert Ihnen der Setup-Assistent die folgende Seite:
Die Auswahlmöglichkeiten dieser Seite sind für Sie nur dann relevant, wenn bereits ein Windows-Agent auf dem Host installiert ist und dieser älter als Version 1.6.0 ist. In der Version 1.6.0 hatte sich die Architektur des Windows-Agenten grundlegend geändert. Falls Sie von einem Windows-Agenten vor Version 1.6.0 auf den aktuellen Agenten updaten (oder migrieren), dann lesen Sie zuerst im Checkmk-Handbuch der Version 2.0.0 das Kapitel zum alten Agenten. Dort erfahren Sie, welche der angebotenen Optionen Sie in diesem speziellen Update-Fall auswählen sollten.
In allen anderen Fällen empfehlen wir die Auswahl von Clean installation.
Bestätigen Sie den Start der Installation und erlauben Sie dann noch im Dialog zur Benutzerkontensteuerung (User Account Control), dass das Installationsprogramm Änderungen durchführen darf. Nach dem Abschluss können Sie den Setup-Assistenten beenden.
Nach der Installation wird der Agent sofort als Windows-Dienst gestartet und ist für die Überwachung des Systems bereit.
Unbeaufsichtigte Installation
Windows bietet über die Kommandozeile für Administratoren mit msiexec
die Möglichkeit, MSI-Pakete automatisiert, ohne Benutzerinteraktion zu installieren.
Eine automatisierte Installation kann dann zum Beispiel folgendermaßen aussehen:
C:\Users\hhirsch\Downloads\> msiexec /i check_mk_agent.msi /qn
In diesem Fall wird der Agent ohne Benutzerinteraktion und Benutzeroberfläche (/qn
) installiert (/i
) und ebenfalls sofort als Windows-Dienst gestartet.
Diese Methode eignet sich also hervorragend zum automatischen Verteilen des Agenten auf viele Hosts.
Sie können auf diesem Wege auch die drei Optionen auswählen, die Ihnen während der manuellen Installation im Setup-Assistenten angeboten wurden. Für jede Option gibt es einen Bezeichner, den Sie für das Installationskommando verwenden können:
Option im Setup-Assistenten | Bezeichner |
---|---|
Clean installation. |
|
Remove Legacy Windows Agent (pre 1.6) if present. |
|
Migrate from Legacy Windows Agent (pre 1.6) configuration if present. |
|
Um eine Option zu aktivieren, hängen Sie deren Bezeichner gefolgt von einem Gleichheitszeichen an:
C:\Users\hhirsch\Downloads\> msiexec /i check_mk_agent.msi /qn WIXUI_CLEANINSTALL=
Um eine Option explizit zu deaktivieren, müssen Sie hinter dem Gleichheitszeichen noch zwei Anführungszeichen anfügen:
C:\Users\hhirsch\Downloads\> msiexec /i check_mk_agent.msi /qn WIXUI_MIGRATELEGACY=""
3.3. Installation mit der Agentenbäckerei
Die kommerziellen Editionen 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 des gebackenen MSI-Pakets geschieht genauso wie es für die mitgelieferten Pakete oben beschrieben ist.
In Checkmk Cloud können Sie die Agentenbäckerei zusätzlich nutzen, um Agentenpakete mit einer Konfiguration für die Autoregistrierung zu versehen, was die automatische Erstellung von Hosts ermöglicht. In diesem Fall erfolgt die Registrierung des Agenten automatisch nach der Installation des Agentenpakets und eine manuelle Registrierung, wie im folgenden Kapitel beschrieben, ist nicht mehr notwendig.
3.4. Automatisches Update
Wenn Sie die Agentenbäckerei verwenden, können Sie automatische Updates des Agenten einrichten. Diese werden in einem eigenen Artikel beschrieben.
3.5. Konfigurationsdateien des Agenten
Das MSI-Paket speichert bei der Installation die programmspezifischen Dateien in C:\Program Files (x86)\checkmk\service\
und die Host-spezifischen Dateien in C:\ProgramData\checkmk\agent\
.
Die programmspezifischen Dateien brauchen Sie nicht anzupassen.
Mit den Host-spezifischen Dateien werden Plugins, Log- und Konfigurationsdateien abgelegt und das Verhalten des Agenten konfiguriert.
Hinweis: Standardmäßig ist das gesamte Verzeichnis C:\ProgramData
in Windows versteckt (hidden).
Der Agent liest nacheinander drei Konfigurationsdateien ein:
C:\Program Files (x86)\checkmk\service\check_mk.yml
ist die Standardkonfigurationsdatei, die Sie nicht ändern sollten.C:\ProgramData\checkmk\agent\bakery\check_mk.bakery.yml
wird von der Agentenbäckerei erstellt und sollte nicht manuell geändert werden.C:\ProgramData\checkmk\agent\check_mk.user.yml
ist Ihre Konfigurationsdatei, in der Sie von Hand individuelle Anpassungen vornehmen können, um eine Einstellung oder eine Erweiterung auf einem Host zu testen.
Wird eine Option in mehreren Dateien gesetzt, dann bestimmt die zuletzt eingelesene Datei den Wert dieser Option.
Für das manuelle Arbeiten mit dem Agenten ist also lediglich die letzte Konfigurationsdatei check_mk.user.yaml
relevant, weil sie als letzte eingelesen wird und damit das letzte Wort hat.
Wenn die Agentenbäckerei nicht genutzt wird, ist sie sogar die einzige Datei, in der Anpassungen an der Konfiguration des Agenten vorgenommen werden dürfen.
Wie Sie vielleicht schon an der Dateiendung der Konfigurationsdateien erkannt haben, wird als Dateiformat YAML verwendet.
3.6. Wie geht es weiter nach der Installation?
Nach der Installation des Agenten mit Agent Controller 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.
Im Monitoring sieht das dann etwa so aus:
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 so lange, 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 bei Nutzung eines Legacy-Agenten auf einem sehr alten Windows-System. Ohne Agent Controller ist keine Registrierung möglich. Für einen Legacy-Agenten sind im Kapitel Registrierung daher nur die Abschnitte relevant, um den Host ins Setup und anschließend ins Monitoring aufzunehmen. Im Kapitel Test und Fehlerdiagnose können Sie sich den Test zum Aufruf des Agent Controllers sparen, da dieser bei einem Legacy-Agenten nicht vorhanden ist. Da es ohne Agent Controller auch keine TLS-Verschlüsselung gibt, müssen Sie bei Bedarf andere Wege der Verschlüsselung wählen. Wir empfehlen, in diesem Fall die eingebaute (symmetrische) Verschlüsselung zu nutzen, sie wird mit der Regel Symmetric encryption (Linux, Windows) eingerichtet.
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 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.
Eine Ausnahme hiervon sind die für die Autoregistrierung vorkonfigurierten und via Agentenbäckerei heruntergeladene Pakete in Checkmk Cloud. Diese Pakete führen die Registrierung automatisch nach der Installation durch.
In allen anderen Fällen führen Sie die manuelle Registrierung zeitnah nach der Installation des Agenten 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 agent_registration
an, der nur die Berechtigung zur Registrierung von Agenten besitzt und bei jeder Checkmk-Installation automatisch angelegt wird.
Das zugehörige Automationspasswort (automation secret) können Sie mit auswürfeln.
Hinweis: Da es auf sehr alten Windows-Systemen keinen Agent Controller, und da mit keine Registrierung und TLS-Verschlüsselung gibt, müssen Sie bei Bedarf andere Wege der Verschlüsselung wählen. Wir empfehlen, in diesem Fall die eingebaute (symmetrische) Verschlüsselung zu nutzen, sie wird mit der Regel Symmetric encryption (Linux, Windows) eingerichtet.
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.
In Checkmk Cloud finden Sie in den Eigenschaften des Hosts im Abschnitt zu den Monitoring-Agenten die Option Checkmk agent connection mode. Hier können Sie alternativ zum Pull-Modus, der in allen Editionen verfügbar ist, für den Checkmk-Agenten den Push-Modus aktivieren.
4.3. 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 cmk-agent-ctl help
die Kommandohilfe anzeigen lassen, auch spezifisch für die verfügbaren Subkommandos, z.B. mit cmk-agent-ctl help register
.
Ob der Host dabei für den Pull-Modus (alle Editionen) oder den Push-Modus (nur Checkmk Cloud) konfiguriert ist, macht für die Befehlsbeispiele keinen Unterschied. In welchem Modus der Agent Controller arbeiten soll, teilt ihm der Agent Receiver bei der Registrierung mit.
Begeben Sie sich nun zum Host, der registriert werden soll. Hier ist mit Administratorrechten eine Anfrage an die Checkmk-Instanz zu stellen:
C:\Windows\system32> "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" ^
register ^
--hostname mynewhost ^
--server cmkserver --site mysite ^
--user agent_registration --password "PTEGDYXBFXVGNDPRL"
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.
Vorsicht, Falle: Falls Sie vorrangig Unix-Maschinen administrieren, sind Sie es gewohnt, Pfade oder Parameter mit Leer- oder Sonderzeichen in einfachen Anführungszeichen (apostrophes, 0x27
) zu umschließen.
Dieses Zeichen interpretiert Windows als Teil des Aufrufs – hier des Passworts –, und die Registrierung wird fehlschlagen.
Verwenden Sie stattdessen doppelte Anführungszeichen (quotation marks, 0x22
).
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.
Wenn Sie die interaktive Zertifikatsprüfung – beispielsweise, um die Registrierung komplett automatisieren zu können – abschalten wollen, können Sie den zusätzlichen Parameter --trust-cert
verwenden.
Dem übermittelten Zertifikat wird dann automatisch vertraut.
Beachten Sie in diesem Fall, dass Sie auf anderem Weg die Integrität des Zertifikats sicher stellen sollten.
Dies kann (von Hand oder per Skript) durch Kontrolle der Datei /var/lib/cmk-agent/registered_connections.json
erfolgen.
4.4. Host beim Server automatisch registrieren lassen
Checkmk Cloud bietet die Möglichkeit, Hosts automatisch bei der Registrierung anzulegen. Für die Autoregistrierung benötigen Sie zusätzlich zu einem Benutzer mit der Berechtigung Hosts zu registrieren, mindestens einen Ordner, der für die Aufnahme der automatisch zu erstellenden Hosts konfiguriert ist.
Ist dies der Fall, können Sie die Registrierung inklusive automatischer Erstellung des Hosts auch per Kommandozeile vornehmen.
In der Regel werden Sie den Weg über die Einstellungen der Agentenbäckerei gehen,
welche die Konfigurationsdatei /var/lib/cmk-agent/pre_configured_connections.json
ins Agentenpaket integrieren und die Registrierung automatisch bei der Installation vornehmen.
Der hier vorgestellte Kommandozeilenaufruf dient daher primär dem Test und der Fehlersuche, beispielsweise dem Ausprobieren eigener Agenten-Labels mit der Option --agent-labels <KEY=VALUE>
.
C:\Windows\system32> "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" ^
register-new ^
--server cmkserver --site mysite ^
--agent-labels testhost:true ^
--user agent_registration --password "PTEGDYXBFXVGNDPRL"
Größter Unterschied hier ist das geänderte Subkommando register-new
in Zusammenspiel mit Angabe des Benutzers für die Autoregistrierung.
Beide zusammen fragen an der Checkmk-Instanz die Erstellung eines neuen Hosts an.
Als Name des Hosts wird der in der Umgebungsvariable %COMPUTERNAME%
hinterlegte verwendet.
Die anschließende Bestätigung des Zertifikats entspricht der im letzten Abschnitt gezeigten.
Ob der Host im Pull-Modus, im Push-Modus oder überhaupt nicht angelegt wird, entscheiden Ihre Einstellungen des Regelsatzes Agent registration. Nach erfolgreicher Registrierung können mehrere Minuten vergehen, bis der Host im Monitoring auftaucht.
4.5. Vertrauensverhältnis überprüfen
Das Kommando cmk-agent-ctl status
zeigt nun genau ein Vertrauensverhältnis zum Checkmk-Server:
C:\Windows\system32> "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" status
Connection: 12.34.56.78:8000/mysite
UUID: d38e7e53-9f0b-4f11-bbcf-d196deadbeef
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
Host name: mynewhost
Ist die Information in einem maschinenlesbaren Format erforderlich, hängen Sie den zusätzlichen Parameter --json
an, um die Ausgabe als JSON-Objekt formatiert zu erhalten.
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 agent_registration > /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:
C:\Windows\system32> "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" ^
import %TEMP%\mynewhost3.json
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:
C:\Windows\system32> "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" ^
delete d38e7e53-9f0b-4f11-bbcf-d196deadbeef
Um alle Verbindungen des Hosts zu entfernen und zusätzlich den Legacy-Pull-Modus wiederherzustellen, geben Sie folgendes Kommando ein:
C:\Windows\system32> "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" ^
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
4.9. Umstellung zwischen Push- und Pull-Modus
In Checkmk Cloud können Sie Hosts vom Push- zum Pull-Modus und umgekehrt umstellen. Dies kann in Einzelfällen nötig sein, wenn Änderungen an der Netzwerktopologie anstehen oder ein Downgrade auf Checkmk Enterprise durchgeführt werden soll, wo nur der Pull-Modus möglich sind.
Stellen Sie zunächst im Setup, in den Eigenschaften des Hosts, den Zugriffsmodus mit der Option Checkmk agent connection mode um.
Innerhalb der nächsten Minute werden alle Services den Status UNKNOWN annehmen, weil keine Monitoring-Daten eingehen.
Führen Sie anschließend eine erneute Registrierung durch.
Bei dieser erneuten Registrierung teilt der Agent Receiver des Checkmk-Servers dem Agent Controller mit, ob er Daten im Pull- oder im Push-Modus erwartet.
Die anschließende Kontrolle mit cmk-agent-ctl status
zeigt dann eine neue UUID und den Modus konsistent mit der Änderung im Setup an.
5. Test und Fehlerdiagnose
Ein modulares System kann an vielen Stellen nicht wie vorgesehen funktionieren. Da mit dem Agenten seit der Version 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 schiefgehen 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 angemeldet ist.
Wir arbeiten uns im Folgenden vom Agentenprogramm über den Agent Controller und den TCP-Port 6556 bis zur Checkmk-Instanz durch. Beim Agent Controller im Push-Modus von Checkmk Cloud überspringen Sie Tests auf Port 6556 – selbst wenn der Port 6556 vor der Registrierung geöffnet ist, wird er nach der Registrierung im Push-Modus geschlossen. 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. Prüfen der Konfiguration
Um zu prüfen, ob die Konfiguration so eingelesen wurde, wie Sie das erwarten, rufen Sie das Agentenprogramm mit der Option showconfig
auf.
Mit dieser Option bekommen Sie nicht nur die Konfiguration ausgegeben, wie sie derzeit vom Agenten benutzt wird.
Zusätzlich werden auch immer die benutzten Umgebungsvariablen sowie die verwendeten Konfigurationsdateien angezeigt.
Ist nur ein bestimmter Teil der Konfiguration interessant, schränken Sie die Ausgabe auf diesen Teil ein.
Hier wird zum Beispiel geprüft, ob die Optionen der Sektion ps
korrekt gesetzt sind:
C:\Windows\system32> "C:\Program Files (x86)\checkmk\service\check_mk_agent.exe" showconfig ps
# Environment Variables:
# MK_LOCALDIR="C:\ProgramData\checkmk\agent\local"
# MK_STATEDIR="C:\ProgramData\checkmk\agent\state"
# MK_PLUGINSDIR="C:\ProgramData\checkmk\agent\plugins"
# MK_TEMPDIR="C:\ProgramData\checkmk\agent\tmp"
# MK_LOGDIR="C:\ProgramData\checkmk\agent\log"
# MK_CONFDIR="C:\ProgramData\checkmk\agent\config"
# MK_SPOOLDIR="C:\ProgramData\checkmk\agent\spool"
# MK_INSTALLDIR="C:\ProgramData\checkmk\agent\install"
# MK_MSI_PATH="C:\ProgramData\checkmk\agent\update"
# Loaded Config Files:
# system: 'C:\Program Files (x86)\checkmk\service\check_mk.yml'
# bakery: 'C:\ProgramData\checkmk\agent\bakery'
# user : 'C:\ProgramData\checkmk\agent\check_mk.user.yml'
# ps
enabled: yes
use_wmi: yes
full_path: no
Über diesen Weg bekommen Sie einen schnellen Überblick, wie die drei verschiedenen Konfigurationsdateien vom Agentenprogramm zusammengeführt und benutzt werden. Fehler werden somit sofort sichtbar.
5.2. 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:
C:\Windows\system32> curl.exe -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 Bytes 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.
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:
C:\Windows\system32> "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" ^
register ^
--hostname mynewhost ^
--server cmkserver:8000 --site mysite ^
--user agent_registration --password PTEGDYXBFXVGNDPRL
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.
Im Falle der Registrierung im Push-Modus von Checkmk Cloud gilt: Hat die Registrierung funktioniert, wird auch der minütliche Transfer der Agentenausgabe erfolgreich sein.
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.3. Agent Controller im Dump-Modus
Da das Agentenprogramm unter dem LocalSystem-Konto aufgerufen werden muss, um exakt jene Daten zu liefern, die im Monitoring ankommen, sollten Sie es nie in einer Shell starten.
Wenn Sie die Agentenausgabe lokal untersuchen wollen, verwenden Sie den Agent Controller im Dump-Modus (Subkommando dump
).
Dieser startet das Agentenprogramm mit der richtigen Environment und unter der richtigen Nutzerkennung und gibt anschließend das Ergebnis aus.
Weil die Ausgabe etwas länger sein kann, ist der Pager more
hier sehr praktisch.
Sie können Ihn mit der Taste Q verlassen:
C:\Windows\system32> "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" dump | more
<<<check_mk>>>
Version: 2.3.0p16
BuildDate: Mar 14 2023
AgentOS: windows
Hostname: DESKTOP-QVPV284
Architecture: 64bit
WorkingDirectory: C:\Windows\system32
ConfigFile: C:\Program Files (x86)\checkmk\service\check_mk.yml
LocalConfigFile: C:\ProgramData\checkmk\agent\check_mk.user.yml
AgentDirectory: C:\Program Files (x86)\checkmk\service
PluginsDirectory: C:\ProgramData\checkmk\agent\plugins
StateDirectory: C:\ProgramData\checkmk\agent\state
ConfigDirectory: C:\ProgramData\checkmk\agent\config
TempDirectory: C:\ProgramData\checkmk\agent\tmp
LogDirectory: C:\ProgramData\checkmk\agent\log
SpoolDirectory: C:\ProgramData\checkmk\agent\spool
LocalDirectory: C:\ProgramData\checkmk\agent\local
OnlyFrom:
<<<cmk_agent_ctl_status:sep(0)>>>
So können Sie überprüfen, welche Daten vom Agentenprogramm beim Agent Controller angekommen sind. Diese Ausgabe beweist aber noch nicht, dass der Agent auch über das Netzwerk erreichbar ist.
5.4. Verbindungstest von außen
Ist im Pull-Modus sichergestellt, dass lokal das Agentenprogramm und die mitinstallierten Plugins korrekt ausgeführt werden,
können Sie als Nächstes vom Checkmk-Server per netcat
(oder nc
) prüfen, ob Port 6556 über die externe IP-Adresse des Hosts erreichbar ist:
OMD[mysite]:~$ 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.
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 beim Legacy-Agenten),
erhalten Sie mit diesem Kommando statt der 16
die komplette unverschlüsselte Agentenausgabe.
Weitere Diagnosemöglichkeiten zur Ausführung auf dem Checkmk-Server finden Sie im allgemeinen Artikel über die Monitoring-Agenten. Sie können insbesondere einen Verbindungstest auch über die Checkmk-Oberfläche durchführen. Das Ergebnis erhalten Sie im Kasten Agent:
Falls Sie beim Verbindungstest, wie im obigen Beispiel, keine Informationen bzw. nur eine Fehlermeldung über einen Timeout erhalten, so sollten Sie auf dem Host die Inbound Rules der Windows-Firewall prüfen.
5.5. Windows Firewall
Der Agent legt bei seiner Installation bereits eine Regel in der Windows Firewall an, damit der Agent Controller über den Port 6556 von außen erreichbar ist. Bei Verwendung des Push-Modus von Checkmk Cloud ist in der Regel keine Änderung der Einstellungen nötig. Falls Sie eine sehr strenge Firewall-Konfiguration verwenden, sind die Outbound Rules für Verbindungen zum Monitoring-Server so anzupassen, dass wenigstens Port 8000 (für einfachere Registrierung zusätzlich 80 oder 443) erreichbar ist.
In aktuellen Versionen von Windows können Sie die Windows Defender Firewall with Advanced Security über die Windows Einstellungen (Settings > Windows Security) finden oder über den Aufruf von wf.msc
über die Kommandozeile starten:
Sollten Sie in den Einstellungen der Windows Firewall keinen solchen Eintrag finden, können Sie diesen genau an dieser Stelle hinzufügen. Klicken Sie dafür im Menü Action auf New Rule.
Daraufhin öffnet sich ein Assistent für die Erstellung einer neuen Firewall-Regel. Stellen Sie die fünf Auswahlmöglichkeiten wie folgt ein:
Rule Type |
Belassen Sie die Auswahl hier auf Program. |
Program |
Tragen Sie unter This program path |
Action |
Belassen Sie die Auswahl auf Allow the connection. |
Profile |
Dieser Punkt kommt stark auf die Konfiguration Ihres Netzwerks an. Es empfiehlt sich allerdings in den meisten Fällen hier nur Domain und Private zu aktivieren. |
Name |
Geben Sie der Regel einen prägnanten und kurzen Namen. |
Alternativ können Sie auch diesen Schritt automatisieren und die Regel direkt auf der Kommandozeile setzen. Passen Sie den folgenden Befehl gegebenenfalls Ihrem angepassten Installationspfad an:
C:\Windows\System32> netsh advfirewall firewall add rule name="Checkmk Agent" ^
description="Allow inbound network traffic to the Checkmk Agent" dir=in localport=6556 protocol=tcp action=allow ^
program="%ALLUSERSPROFILE%\checkmk\agent\bin\cmk-agent-ctl.exe" ^
profile=private,domain enable=yes
OK.
Hinweis: Der Befehl wurde zugunsten der Lesbarkeit in vier Zeilen aufgeteilt.
5.6. Fehlersuche beim Push-Agent
Im Ordner ~/var/agent-receiver/received-outputs/
Ihrer Checkmk-Instanz finden Sie für jeden registrierten Host einen Softlink, der als Name die UUID des Hosts verwendet.
Bei Push-Hosts von Checkmk Cloud zeigt dieser Softlink auf den Ordner mit der Agentenausgabe, bei Pull-Hosts auf eine nicht vorhandene Datei mit dem Namen des Hosts, wie er im Monitoring verwendet wird.
Anhand des Alters der zwischengespeicherten Agentenausgabe können Sie ermitteln, ob die regelmäßige Übertragung erfolgreich war oder beispielsweise durch sporadische Netzwerkprobleme vereitelt wird.
Des Weiteren können Sie auf dem Host einen Blick in die Log-Datei C:\ProgramData\checkmk\agent\log\check_mk.log
werfen (Pfade können abweichend konfiguriert sein).
Zeilen wie die folgende deuten auf Verbindungsprobleme hin:
Dez 15 17:59:49 myhost23 cmk-agent-ctl[652648]: WARN [cmk_agent_ctl::modes::push] https://mycmkserver:8000/mysite: Error pushing agent output.
5.7. Verbindungen gehen verloren
Wurde ein Host für die Autoregistrierung in Checkmk Cloud mit dem Regelsatz Agent controller auto-registration konfiguriert und die Option Keep existing connections auf no gesetzt, werden bei jedem Neustart des Dienstes cmk-agent-ctl-daemon
(beispielsweise beim Neustart eines Hosts) alle anderen Verbindungen entfernt — außer der für die Autoregistrierung konfigurierten Verbindung.
Dies betrifft beispielsweise Hosts, auf denen vor der Installation des gebackenen Agentenpakets Verbindungen zu mehreren Instanzen eingerichtet waren oder nach der Installation des Agentenpakets manuell Verbindungen hinzugefügt wurden.
Sie können dieses Verhalten temporär ändern, indem Sie auf dem Host in der Datei C:\ProgramData\checkmk\agent\pre_configured_connections.json
die Variable keep_existing_connections
auf true
setzen.
Eine dauerhafte Änderung über ein Update der Agentenpakete hinweg erreichen Sie, indem Sie im oben genannten Regelsatz Keep existing connections auf yes setzen.
5.8. Zeitdauer bis Änderungen sichtbar werden
Bei der Autoregistrierung eines Hosts in Checkmk Cloud vergehen typischerweise etwa zwei Minuten, bis der Host im Monitoring auftaucht.
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.
Für die Absicherung der TLS-Verbindung verwendet Checkmk ein selbst signiertes Zertifikat, das kurz vor Ablauf seiner Gültigkeit automatisch ersetzt wird. Der Agent Controller kümmert sich um die rechtzeitige Erneuerung des Zertifikates vor seinem Ablauf. Nur längere Zeit inaktive Agenten, d.h., ohne laufenden Agent Controller, können ihre Registrierung bei Ablauf verlieren und müssen dann erneut registriert werden. Die Laufzeit des Zertifikats kann über die globale Einstellung Agent Certificates > Lifetime of certificates festgelegt werden.
Hinweis: Da es auf sehr alten Windows-Systemen keinen Agent Controller, und damit keine Registrierung und TLS-Verschlüsselung gibt, müssen Sie bei Bedarf andere Wege der Verschlüsselung wählen. Wir empfehlen, in diesem Fall die eingebaute (symmetrische) Verschlüsselung zu nutzen, sie wird mit der Regel Symmetric encryption (Linux, Windows) eingerichtet.
6.3. Zugriff über IP-Adressen beschränken
Die Einschränkung auf bestimmte IP-Adressen können Sie zwar auch über die Firewall konfigurieren. Zusätzlich bietet aber auch der Agent selbst die Möglichkeit, Anfragen von fremden IP-Adressen schlicht zu ignorieren. Fügen Sie der Konfigurationsdatei lediglich die folgende Einschränkung in den globalen Optionen hinzu. Beachten Sie, dass davor oder danach noch andere Parameter in der Konfigurationsdatei gesetzt sein können und dies nur ein Ausschnitt ist:
global:
only_from: 127.0.0.1/32 192.168.42.0/24
Wie in dem Beispiel gut zu sehen ist, können Sie prinzipiell beliebig viele Subnetze erlauben.
Mit einem /32
geben Sie z.B. ein Subnetz der Größe 1 an, so dass nur diese eine Adresse erlaubt ist, während sie mit 192.168.42.0/24
alle Adressen zwischen 192.168.42.0
und 192.168.42.255
erlauben.
In der Agentenbäckerei können Sie die erlaubten IP-Adressen über folgenden Regelsatz konfigurieren: Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Allowed agent access via IP address (Linux, Windows)
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 Agentenprogramm 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 Ver- und Entschlüsselungsschritten belasten.
Aus diesem Grund sollten Sie die eingebaute Verschlüsselung zeitnah nach dem Wechsel auf TLS deaktivieren.
Im ersten Schritt schalten Sie in der vorhandenen Regel unter Setup > Agents > Access to agents > Checkmk agent > Symmetric encryption (Linux, Windows) die Verschlüsselung ab.
Im zweiten Schritt ändern Sie auf dem Host des Agenten in der Konfigurationsdatei C:\ProgramData\checkmk\agent\check_mk.user.yml
den Wert des Parameters encrypted
auf no
:
global:
encrypted: no
passphrase: D0e5NotMat7erAnym0r3
Im dritten und letzten Schritt legen Sie mit der Regel Enforce agent data encryption fest, dass der Checkmk-Server nur noch per TLS verschlüsselte Daten akzeptiert. Wählen Sie dazu in der Regel den Wert Accept TLS encrypted connections only aus.
Das Abschalten der Verschlüsselung mit der Agentenbäckerei geht so:
Mit dem ersten Schritt, dem Ändern der Regel Symmetric encryption (Linux, Windows), sind Sie fast fertig.
Sie brauchen nur noch neue Agenten zu backen und zu verteilen.
Die Konfigurationsdatei C:\ProgramData\checkmk\agent\check_mk.user.yml
wird automatisch für Sie geändert und mit in die Agentenpakete eingebaut.
Übrig bleibt dann nur der dritte Schritt, d.h. die Änderung der Regel Enforce agent data encryption.
Nach dem nächsten automatischen Agenten-Update ist die Verschlüsselung des Agentenprogramms 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.
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 kommerziellen Editionen können Sie über Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Disabled sections (Windows agent) einfach eine Regel anlegen, welche dann von der Agentenbäckerei berücksichtigt wird.
Hinweis: Das obige Bild zeigt, dass es zu Disabled sections (Windows agent) auch eine gegenteilige Regel Enabled sections (Windows agent) gibt. Sie können also statt mit der Negativ- auch mit der Positivliste arbeiten. Um den Überblick zu behalten, empfehlen wir aber, nur eine der beiden Regeln zu verwenden.
In der Regel Disabled sections (Windows agent) finden Sie für jede deaktivierbare Sektion eine eigene Checkbox.
Für die angewählten Checkboxen finden Sie dann — nachdem der neu gebackene Agent auf den ausgewählten Hosts installiert wurde — in der Konfigurationsdatei der Agentenbäckerei C:\ProgramData\checkmk\agent\bakery\check_mk.bakery.yml
unterhalb von global:
eine Zeile disabled_sections:
, in der die ausgewählten Sektionen aufgelistet sind.
Würden Sie in der Regel beispielsweise die beiden Optionen System uptime
und Web Services
auswählen, sähe die passende Konfigurationsdatei wie folgt aus:
global:
disabled_sections: [uptime, wmi_webservices]
Nutzer von Checkmk Raw können einen Eintrag in der Konfigurationsdatei C:\ProgramData\checkmk\agent\check_mk.user.yml
manuell anlegen und dort die Sektionen eintragen, die deaktiviert werden sollen.
Alle deaktivierbaren Sektionen sind in dieser Datei unterhalb von global:
im Abschnitt _sections:
aufgelistet.
8. Agent um Plugins erweitern
8.1. Was sind Agentenplugins?
Das Agentenprogramm check_mk_agent.exe
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 kann seine Daten nur über interne Schnittstellen holen, die der Agent nicht bereitstellt (Beispiel: PowerShell).
Das Plugin benötigt sowieso eine Konfiguration, ohne die es nicht funktionieren würde (Beispiel:
mk_oracle.ps1
).Das Plugin ist so speziell, dass es von den meisten Anwendern nicht benötigt wird (Beispiel:
citrix_licenses.vbs
).
8.2. Manuelle Installation
Die mitgelieferten Plugins für Windows finden Sie alle auf dem überwachten Host im Installationsverzeichnis des Agenten unter C:\Program Files (x86)\checkmk\service\plugins
.
Sie werden dort abgelegt, damit sie auch direkt zur Verfügung stehen.
Alternativ liegen die Plugins für Windows auch auf dem Checkmk-Server unter ~/share/check_mk/agents/windows/plugins
.
Auch über die Download-Seite des Agenten im Setup-Menü (wie im Kapitel Installation beschrieben) sind diese im Kasten Plugins verfügbar:
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 werden 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 C:\ProgramData\checkmk\agent\plugins
.
Sobald das Plugin 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.ps1
) erzeugen sogar eine ganze Reihe an neuen Sektionen.
8.3. Konfiguration
Manche Plugins benötigen eine Konfigurationsdatei in C:\ProgramData\checkmk\agent\config
, damit sie funktionieren können.
Bei anderen ist eine Konfiguration optional (z.B. mssql.vbs
) 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 in der Plugin-Datei (oft sehr hilfreich!)
Einen passenden Artikel in diesem Handbuch (z.B. über das Überwachen von Oracle)
Bei speziellen (Skript)-Sprachen kann es notwendig sein, diese erst in der Konfiguration des Agenten freizuschalten.
So werden beispielsweise Python-Skripte nicht ausgeführt, wenn sie nicht explizit freigegeben wurden.
Sie können dazu in der Konfigurationsdatei check_mk.user.yml
in der Sektion global
die Dateiendungen erweitern, wie im folgenden Ausschnitt zu sehen:
global:
execute: [exe, bat, vbs, cmd, ps1, py]
Wichtig: Der Einsatz solcher Plugins setzt voraus, dass die Dateien auch in einer regulären Kommandozeile ohne spezielle Pfade aufgerufen werden können. Im Fall von Python muss dieses entsprechend korrekt installiert und der Pfad zu dem Interpreter in den Umgebungsvariablen vorhanden sein. Anleitungen, wie Sie Python korrekt einrichten, finden Sie direkt auf den Seiten der Python Software Foundation.
8.4. Ausführung eines speziellen Plugins anpassen
Jedes Plugin kann in unterschiedlichen Modi ausgeführt werden. Dabei stehen die folgenden Optionen zur Eingabe in der Konfigurationsdatei zur Verfügung.
Option | Wert | Beschreibung |
---|---|---|
|
|
Setzt die Reichweite der nachfolgenden Optionen. Hier kann auch mit Wildcards gearbeitet werden. Dann beziehen sich die nachfolgenden Optionen auf alle Plugins, auf die der Ausdruck zutrifft. Führend wird bestimmt, ob das Plugin direkt aus dem Installationsverzeichnis unter |
|
|
Bestimmt, ob die Ausführung eines Plugins unterdrückt werden soll. |
|
|
Führt ein Plugin asynchron aus und legt die Daten in einer Datei ab. Bei synchroner Ausführung wird die Ausgabe direkt dem Agenten übergeben. |
|
|
Setzt die maximale Ausführungszeit. Danach wird das Plugin beendet, auch wenn keine Ausgabe gekommen ist. Der Standardwert orientiert sich an dem Standard für das Abfrageintervall des Agenten. |
|
|
Legt in Sekunden fest, wie lange eine Ausgabe gültig ist. |
|
|
Die Häufigkeit, wie oft ein Plugin fehlschlagen darf, bevor eine Ausgabe aus dem Cache verworfen wird. |
|
|
Hier können Sie einen freien Text eintragen, der den Logs angefügt werden soll. |
Eine Konfiguration für das Veeam-Plugin sieht dann zum Beispiel so aus (der Auszug ist gekürzt und enthält nur den relevanten Teil für das Beispiel):
plugins:
enabled: yes
execution:
- pattern: $CUSTOM_PLUGINS_PATH$\veeam_backup_status.ps1
async: yes
timeout: 120
cache_age: 300
retry_count: 2
Nach der obigen beispielhaften Konfiguration wird das Plugin im Datenverzeichnis C:\ProgramData\checkmk\agent\plugins
ausgeführt, und zwar asynchron alle fünf Minuten (300 Sekunden) und darf dabei maximal zwei Minuten (120 Sekunden) laufen.
Falls das Plugin in diesen Timeout läuft, wird ein zweites Mal versucht ein Ergebnis zu bekommen.
8.5. Installation über die Agentenbäckerei
In den kommerziellen Editionen 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:
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 gegebenenfalls von Hand, wenn sie in dem Skript oder Programm benötigt werden.
9. Einbinden von Legacy 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 weiter nutzen. In vielen Fällen sind das selbst geschriebene Plugins in Perl oder Shell.
Der zweite Grund für die Verwendung 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 über verschiedene Konfigurationsdateien gesteuert.
MRPE aktivieren und deaktivieren
Standardmäßig ist die Berücksichtigung von MRPE-Plugins aktiviert. Falls Sie diese Funktion nicht nutzen wollen, können Sie sie in der Konfigurationsdatei deaktivieren, indem Sie die folgende Definition hinzufügen:
mrpe:
enabled: no
Die Ausführungszeit begrenzen
Manchmal ist die Laufzeit eines Skripts oder Nagios-Plugins nicht vorhersehbar und im schlimmsten Fall wird ein Plugin nie beendet. Um hier die Kontrolle zu behalten, können Sie die maximale Laufzeit der MRPE-Plugins begrenzen. Der hier gezeigte Wert ist auch gleichzeitig der Standardwert in Sekunden. Anpassungen sind also nur notwendig, wenn Sie ein kürzeres oder längeres Intervall festlegen möchten:
mrpe:
# enabled: yes
timeout: 60
MRPE-Plugins hinzufügen
Um dem Agenten mitzuteilen, wo sich die auszuführende Datei befindet und wie diese aufzurufen ist, fügen Sie einen Eintrag in der Konfiguration des MRPE hinzu:
mrpe:
config:
- check = MyServiceName 'C:\ProgramData\checkmk\agent\mrpe\my_check_plugin.bat' -w 10 -c 20 MyParameter
Es ist nicht notwendig, die Datei ebenfalls in dem Verzeichnis des Agenten abzulegen, auch wenn es sich anbietet, um alle an einem gemeinsamen Ort zu sammeln. In dieser Beispielkonfiguration sehen Sie nun folgende Elemente der relevanten Zeile:
Element | Beschreibung |
---|---|
|
Der Servicename, wie er in Checkmk angezeigt werden soll. |
|
Auszuführendes Programm; Anführungszeichen für eventuelle Leerzeichen. |
|
Übergebene Optionen: Ein Schwellwert von 10 für WARN und 20 für CRIT. |
|
Beispielhafte Übergabe weiterer Parameter. |
Nachdem Sie das MRPE-Plugin eingerichtet haben, ist es direkt und ohne Neustart des Agenten aktiv und wird der Ausgabe hinzugefügt. In der Service-Erkennung werden Sie nun Ihren neuen Service automatisch finden:
9.2. MRPE mit der Agentenbäckerei
Alternativ zu der Konfiguration direkt auf einem Host in der benutzerspezifischen Konfigurationsdatei können Sie Ihre MRPE-Plugins auch direkt im Setup-Menü definieren. Benutzen Sie dazu den Regelsatz Setup > Agents > Windows, Linux, Solaris, AIX > Agent > Agent rules > Execute MRPE checks. Der notwendige Eintrag wird dann automatisch in der Konfigurationsdatei der Agentenbäckerei erzeugt.
10. Hardware überwachen
Die Hardware-Überwachung von Windows-Hosts wird vom Checkmk-Agenten, mitgelieferten Plugins und in der Checkmk Exchange erhältlichen Erweiterungen gut abgedeckt. Dennoch gibt es Situationen, in denen weder fertige Plugins noch Programmierschnittstellen zur Erstellung eigener Plugins erhältlich sind, aber entweder eine Anwendungssoftware oder ein Hardware-Überwachungstool eines Hardware-Herstellers Überwachungsdaten per SNMP liefern kann.
Setzen Sie in so einem Fall in den Eigenschaften des Hosts im Setup im Kasten Monitoring agents die Einstellung SNMP auf die geeignete Verbindungsart (SNMP v2 or v3 oder SNMP v1). Services, die sowohl per SNMP als auch per Checkmk-Agent verfügbar sind (z.B. CPU-Auslastung, Dateisysteme, Netzwerkkarten), werden dann automatisch vom Checkmk-Agenten geholt und nicht per SNMP. Damit wird eine Doppelübertragung automatisch vermieden.
Weitere Informationen entnehmen Sie dem Artikel zur Überwachung mit SNMP.
11. Deinstallation
Für die Deinstallation des Agenten haben Sie in Windows mehrere Möglichkeiten. In allen Versionen von Windows finden Sie einen Eintrag in der Systemsteuerung unter Control Panel > Programs and Features > Uninstall a program. In neueren Versionen finden Sie den Eintrag für den Checkmk-Agenten zudem in den Einstellungen unter Settings > Apps > Apps & features.
Über die Kommandozeile für Administratoren haben Sie mehrere Möglichkeiten den Agenten zu entfernen. Sollte Ihnen das zuletzt installierte MSI-Paket noch vorliegen, können Sie dieses wie folgt für die Deinstallation nutzen:
C:\Users\hhirsch\Downloads\> msiexec /x check_mk_agent.msi /qn
Alternativ können Sie auch das Windows Management Instrumentation Command (WMIC) für die Deinstallation verwenden:
C:\> wmic product where name="Check MK Agent 2.1" call uninstall /nointeractive
War die Deinstallation erfolgreich, erhalten Sie als Bestätigung die Meldung Method execution successful.
Hinweis: Der String hinter name=
muss exakt stimmen.
Wenn Sie hier eine andere Version des Agenten deinstallieren wollen, finden Sie eine Auflistung aller installierten Produkte mit folgendem Aufruf:
C:\> wmic product get name
Der Vorgang kann bisweilen recht lange dauern und gibt derweil keinerlei Statusmeldungen aus, dafür dann aber sehr lange Listen. Zum Filtern können Sie den Befehl zur Pipe ausbauen:
C:\> wmic product get name | findstr Check
Check MK Agent 2.1
Da die verschiedenen Routinen von Windows nur Dateien entfernen, welche auch durch den Installationsprozess dorthin gekommen sind, ist es vollkommen normal, dass in den Verzeichnissen des Agenten noch Dateien übrig bleiben. Diese können manuell gelöscht werden.
12. Dateien und Verzeichnisse
12.1. Pfade auf dem überwachten Host
Pfad | Bedeutung |
---|---|
|
Installationsverzeichnis für die programmspezifischen Dateien inklusive des Agentenprogramms |
|
Die Standardkonfigurationsdatei des Agenten. Ändern Sie diese Datei nicht. |
|
Installationsverzeichnis für die Host-spezifischen Dateien. Hier befinden sich Erweiterungen, Log- und Konfigurationsdateien, welche spezifisch für diesen Host gelten. |
|
Diese Konfigurationsdatei wird von der Agentenbäckerei erstellt und überschreibt gegebenenfalls Werte aus der Standardkonfigurationsdatei. |
|
Konfigurationsdatei für Ihre individuellen Anpassungen. Diese Datei wird als letztes eingelesen und überschreibt gegebenenfalls Werte aus den anderen Konfigurationsdateien. |
|
Verzeichnis für Plugins, welche automatisch vom Agenten ausgeführt werden sollen und dessen Ausgabe um zusätzliche Überwachungsdaten erweitern. |
|
Enthält Daten, die z.B. von Log-Dateien erstellt werden und eine eigene Sektion beinhalten. Diese werden ebenfalls der Agentenausgabe angehängt. Mehr dazu erfahren Sie im Artikel Das Spool-Verzeichnis. |
|
Enthält eine Liste der mit dem Agent Controller registrierten Verbindungen. |
|
Enthält eine vorkonfigurierte und per Agentenbäckerei in das Agentenpaket integrierte Verbindung zu einer Instanz für die Autoregistrierung in Checkmk Cloud. |
|
Ablage von Konfigurationsdateien für den Agenten. |
|
Verzeichnis für eigene lokale Checks. |
|
MRPE-Erweiterungen können hier gespeichert werden. |
|
Nach jeder Änderung des Checkmk-Agenten-Service wird von der Benutzerkonfiguration hier ein Backup angelegt. |
|
Hier finden Sie Log-Dateien. Neben der ständig im Betrieb aktualisierten |
12.2. Pfade auf dem Checkmk-Server
Pfad | Bedeutung |
---|---|
|
Basisverzeichnis für eigene Dateien, die mit einem gebackenen Agenten ausgeliefert werden sollen. |
|
Verzeichnis mit dem MSI-Paket des Agenten. In diesem Verzeichnis finden Sie auch Konfigurationsbeispiele und alle Agentenplugins. |
|
Enthält für jede Verbindung deren UUID als Softlink, der auf einen Ordner mit dem Namen des Hosts zeigt. Im Push-Modus enthält dieser Ordner die Agentenausgabe. |