Windows überwachen

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.

Die Checkmk Enterprise Editions verfügen mit der Agentenbäckerei über ein Software-Modul zum automatischen Paketieren von individuell angepassten Agenten — auch Windows-Agenten. Eine ausführliche Beschreibung dazu finden Sie im allgemeinen Artikel über die Agenten. Die Installation des gebackenen MSI-Pakets geschieht dann wieder genau wie oben beschrieben.

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

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:

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.

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, wenn der Agent auf sehr alten Windows-Systemen installiert ist. Die Installation des Agenten mag erfolgreich sein. Falls der Agent Controller aber wegen API-Inkompatibilitäten nicht gestartet werden kann, wird auf die unverschlüsselte Übertragung zurückgegriffen. Ohne Agent Controller ist die Registrierung nicht möglich und der einzige Kommunikationsweg verbleibt der Legacy-Modus. Im Legacy-Modus sind im Kapitel Registrierung 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 im Legacy-Modus 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 mit der Regel Encryption (Linux, Windows) und/oder einen SSH-Tunnel einzurichten.

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.

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.

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 mit der Regel Encryption (Linux, Windows) oder einen SSH-Tunnel einzurichten.

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

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 Administratorrechten eine Anfrage an die Checkmk-Instanz zu stellen:

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:

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.

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

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.

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:

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

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.

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:

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

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:

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

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:

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

Das Agentenprogramm ist ein simples Windows Executable, welches Daten über Ihr System beschafft und als lose formatierten Text ausgibt. Sie können es direkt auf der Kommandozeile aufrufen. Mit dem Parameter test gibt es alles auf die Standardausgabe aus. Mit der Option help bekommen Sie unter anderem eine ausführliche und vollständige Liste an Möglichkeiten, die Ihnen über die hier beschriebenen hinaus zur Verfügung stehen. Da die Ausgabe etwas länger sein kann, ist der Pager more hier sehr praktisch, Sie können Ihn mit der Ausgabe mit der Taste Q verlassen:

So können Sie testen, ob in der Ausgabe alle gewünschten Daten enthalten sind – beispielsweise, ob alle installierten Plugins Daten liefern.

Da das Agentenprogramm auf dem lokalen Loopback-Interface (127.0.0.1) auf Port 50001 lauscht, können Sie auch die Verbindungsaufnahme zu diesem mit Telnet oder Putty testen.

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:

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:

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 dem zusätzlichen Flag --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:

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:

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

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.

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

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

Ist 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:

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

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.

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:

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:

Hinweis: Der Befehl wurde zugunsten der Lesbarkeit in vier Zeilen aufgeteilt.

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.

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.

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 mit der Regel Encryption (Linux, Windows) und/oder einen SSH-Tunnel einzurichten.

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:

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)

Neuere Versionen von Windows (Windows 10 ab Version 1809 und Windows Server ab 2019) haben eine native Unterstützung für SSH. OpenSSH kann hier über Apps > Apps & Features > Optionale Features nachinstalliert werden. Aber auch bei älteren Versionen können Sie einen SSH-Server über Cygwin nachrüsten und damit eine identische Konfiguration nachstellen, wie Sie unter Linux möglich ist. Beachten Sie dabei die aktuellen Hilfestellungen seitens Cygwin oder Microsoft für die Einrichtung. Sobald ein SSH-Server gestartet und erreichbar ist, ist die weitere Einrichtung identisch zu der unter Linux: Sie richten die authorized_keys auf dem überwachten Host ein und beschränken den Zugriff auf die Ausführung des Agenten.

Der Eintrag in der Datei authorized_keys ist auf Windows Hosts allerdings etwas holprig, da hier viele Zeichen maskiert werden müssen. Orientieren Sie sich an dem folgenden (gekürzten) Beispiel. Die Forwardslashes als Pfadtrenner sind in beiden Beispielen eine zulässige und bevorzugte (erspart Escaping) Ausnahme von den sonst üblichen Backslashes:

Soll der Aufruf unter einem Nutzer mit Administratorrechten erfolgen, müssen beim Microsoft OpenSSH-Server die folgenden beiden Zeilen in der globalen Konfigurationsdatei sshd_config mit Raute (#) auskommentiert werden:

Beachten Sie, dass Sie den Windows-Dienst danach stoppen können und auch eine eventuell eingerichtete Firewall-Regel damit obsolet ist.

Bei einem Update des Agenten kann es vorkommen, dass die vom Agentenprogramm selbst durchgeführte eingebaute (symmetrische) Verschlüsselung aktiv bleibt. 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. In der Checkmk Raw Edition erreichen Sie das, indem Sie in der Konfigurationsdatei C:\ProgramData\checkmk\agent\check_mk.user.yml den Wert des Parameters encrypted auf no setzen.

In den 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 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.

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:

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.

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:

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:

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.

Jedes Plugin kann in unterschiedlichen Modi ausgeführt werden. Dabei stehen die folgenden Optionen zur Eingabe in der Konfigurationsdatei zur Verfügung. Der jeweils fett gedruckte Wert ist der Standardwert:

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

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.

In den Checkmk Enterprise Editions können die mitgelieferten Plugins über die Agentenbäckerei konfiguriert werden. Diese sorgt sowohl für die Installation des Plugins selbst als auch für die korrekte Erstellung der Konfigurationsdatei, falls eine notwendig sein sollte.

Jedes Plugin wird über eine Agentenregel konfiguriert. Sie finden die passenden Regelsätze in Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Agent Plugins:

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.

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 über verschiedene Konfigurationsdateien gesteuert.

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.