Wir nutzen Cookies, um Ihnen eine optimale Nutzung dieser Webseite zu ermöglichen. Mehr Informationen finden Sie im Datenschutzhinweis. Wir nehmen an, dass Sie damit einverstanden sind, falls Sie diese Webseite weiter besuchen.

Ihre Cookie-Einstellungen
Ihre Einstellungen wurden aktualisiert.
Damit die Änderungen wirksam werden, löschen Sie bitte Ihre Browser-Cookies und den Cache und laden dann die Seite neu.

Windows überwachen

Checkmk Manual

Suche im Handbuch

Dieser Artikel ist noch nicht fertig und nur ein Entwurf!

1. Einleitung

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 hat gegenüber einen Überwachung mit WMI oder SNMP etliche Vorteile, denn er ist:

  • minimalistisch, denn er begnügt sich mit minimalen Ressourcen an RAM, CPU und Netzwerk.
  • sicher: denn er liest keine Daten aus dem Netzwerk. Dadurch wird jeglicher externe Zugriff auf das System unterbunden.
  • umfassend, denn er hat Zugriff auf wichtige Daten, die per WMI oder SNMP nicht erreichbar sind.
  • leicht erweiterbar, denn Sie können Erweiterungen in einer beliebigen Programmier- oder Skriptsprache schreiben.
  • offen, denn obwohl der Agent als ausführbare Datei ausgeliefert wird, haben Sie jederzeit Zugriff auf den Quellcode und können den Agenten daher prinzipiell auch selbst kompilieren und haben jederzeit Einsicht in die Funktionalität. Es wird kein unbekannter Code verwendet.

Die Installation und Einrichtung des Agenten ist sehr einfach und mit wenigen Schritten erledigt, denn dieser braucht für seine Funktion zum Beispiel keine zusätzlichen Bibliotheken. Zudem wird er mit einer Grundkonfiguration ausgeliefert, welche für die meisten Anwendungsfälle ausreicht.

Im Betrieb besteht der Agent aus einem Windows-Dienst, welcher das mitgelieferte Programm – den Agent – startet. Dieser sammelt bei einem Aufruf Daten zu dem lokalen System und stellt diese dem Monitoring, wie bei anderen Agenten auch, über Port 6556 zur Verfügung.

In der  Checkmk Enterprise Edition können Sie den Agenten mithilfe der automatischen Agenten-Updates automatisch zentral updaten und konfigurieren. 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.

Neu ist ab 1.6.0, dass der Agent komplett überarbeitet wurde. Dieser Artikel bezieht sich daher hauptsächlich auf den aktuellen Agenten. Der alte verhält sich grundsätzlich äquivalent zu dem neuen. Die Unterschiede werden weiter unten in einem eigenen Abschnitt beschrieben. Dort finden Sie auch Informationen zu der Migration, falls Sie auf Ihren Systemen noch den alten Agenten installiert haben.

Aus Kompatibilitätsgründen wird Windows XP, bzw. Widows Server 2003 nur noch von dem alten Agenten unterstützt. Dieser liegt jeder Installation von Checkmk als check_mk_agent_legacy.msi bei. Alle Versionen danach werden von dem neuen Agenten abgedeckt. Wichtig: Checkmk unterstützt derzeit offiziell keine anderen Versionen, wie zum Beispie Windows Embedded.

2. Installation des Agenten

2.1. Verschiedene Möglichkeiten

Checkmk bietet Ihnen für die Installation des Windows-Agenten verschiedene Wege – von der manuellen Installation der Einzelteile bis hin zum vollautomatischen Deployment. Manche davon stehen nur in der  Checkmk Enterprise Edition zur Vefügung:

Methode Beschreibung CRE CEE
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
Automatisches Updaten Das Paket aus der Agentenbäckerei wird erstmalig von Hand oder per Skript installiert und von da an automatisch aktualisiert. X

2.2. Installation per MSI-Paket

Unabhängig davon, ob Sie die MSI-Pakete über die Agentenbäckerei erstellen lassen, oder auf jedem Host manuell konfigurieren: Sie benötigen zuerst die Installationsdatei. Diese finden sie in WATO unter Monitoring Agents. Falls Sie die  Checkmk Enterprise Edition und eine Version einsetzen, die älter als 1.4.0 ist, gehen Sie vorher noch den Umweg über den Knopf Unpackaged agents bzw. Agent files:

In Packaged Agents finden die benötigte Datei check_mk_agent.msi. Laden Sie diese Datei auf den Host und starten Sie die Installation. Prinzipiell müssen Sie nur dem Menü folgen und die Lizenzbedingungen der GNU GENERAL PUBLIC LICENSE lesen und zustimmen. In dem Menüpunkt Destination Folder können Sie einen alternativen Pfad bestimmen, in dem der Agent installiert werden soll. Andernfalls wird er in unter dem Standardpfad %ProgramFiles(x86)%\check_mk\ installiert. Dieser Pfad wird aus Kompatibilitätsgründen benutzt und ist unabhängig davon, ob der Agent auf ein 32- oder 64-Bit Betriebssystem installiert wird. Die Installationsroutine wählt automatisch den richtigen Agenten aus.

Nach der Installation wird der Agent sofort als Windowsdienst gestartet und ist für die Überwachung des Systems bereit.

Unbeaufsichtigte Installation

Windows bietet über msiexec die Möglichkeit, Installationen von MSI-Paketen automatisiert durchzu­führen. 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 unter dem Standardpfad installiert und ebenfalls sofort als Windowsdienst gestartet. Diese Methode eignet sich also hervorragend zum automatischen Ausrollen des Agenten auf viele Hosts.

Windows Firewall

In einigen Fällen kann Checkmk nicht auf einen Windows-Host zugreifen, obwohl das Paket richtig installiert wurde und der Service auch läuft (siehe auch im Abschnitt über die Fehlerdiagnose). In solchen Fällen kann die Firewall das Problem sein. Leider kann der Agent selbst nicht testen, ob er von außen erreichbar ist. Prüfen Sie das daher und setzen Sie gegebenenfalls eine Firewallregel für den Agenten in der Windows Firewall with Advanced Security ( WF.msc ). 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="Check_MK" ^
More?  description="Monitoring" dir=in localport=6556 protocol=tcp action=allow ^
More?  program="%ProgramFiles(x86)%\checkmk\service\check_mk_agent.exe" ^
More?  profile=private,domain enable=yes
OK.

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

2.3. Installation mit der Agent-Bakery

Die  Checkmk Enterprise Edition verfügt auch für den Agenten unter Windows die Möglichkeit, diesen über die Agent-Bakery individuell über die Weboberfläche des WATO-Moduls zu konfigurieren. eine ausführliche Beschreibung finden Sie im allgemeinen Kapitel über die Agenten. Die Installation des gebackenen MSI-Pakets geschieht dann wieder genau, wie oben beschrieben.

2.4. Automatisches Updaten

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

3. Architektur des Agenten

Verzeichnisse des Agenten

Der Agent gliedert sich in zwei Bereiche des Dateisystems auf:

  • C:\Program Files (x86)\check_mk\service\: Hier werden programmspezifische Dateien installiert. Anpassungen sind hier nicht nötig.
  • C:\ProgramData\checkmk\agent\: Hier werden hostspezifische Dateien gespeichert. Das Verhalten des Agenten wird hier konfiguriert und Plugins, Logs, etc. werden ebenfalls unterhalb dieses Verzeichnisses abgelegt. Hinweis: Normalerweise ist dieses Verzeichnis vom System als unsichtbar markiert.

Die Konfigurationsdateien des Agenten

Für die Konfiguration des Agenten liest dieser nacheinander und hierarchisch drei Dateien ein:

  1. C:\Program Files (x86)\checkmk\service\check_mk.yml: Hier ist die Standardkonfiguration hinterlegt. Diese dürfen Sie nicht ändern.
  2. C:\ProgramData\checkmk\agent\bakery\check_mk.bakery.yml: Diese Datei wird von der Agentenbäckerei erstellt und überschreibt gegebenfalls einen Standardwert aus der vorherigen Datei.
  3. C:\ProgramData\checkmk\agent\check_mk.user.yml: In dieser Datei können Sie von Hand individuelle Anpassungen vornehmen, um eine Einstellung oder eine Erweiterung auf einem Host zu testen. Diese Datei wird nach der Konfiguration aus der Bakery eingelesen und überschreibt diese gegebenfalls.

Wie Sie vielleicht schon an der Dateiendung der Konfigurationsdateien erkannt haben, wird als Konfigurationsformat YAML verwendet. Wir haben uns entschieden, ab Version 1.6.0 dieses Format zu verwenden, das es damit einfacher möglich ist, strukturierte Daten zu konfigurieren, als mit dem klassischen INI-Format.

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.

4. Installation des alten Agenten

4.1. Warum ein zweiter Agent?

In früheren Versionen von Checkmk hatte der Agent eine andere Architektur. Diese hat sehr lange gut funktioniert und wurde erst ab 1.6.0 durch eine neue abgelöst, um alte Enden abzuschneiden, die Konfiguration zu vereinfachen und letztendlich auch, um bessere Werkzeuge an der Hand zu haben, um zum Beispiel Konfigurationsfehlern besser auf die Spur zu kommen.

Der alte Agent ist aus Kompatibilitätsgründen in Checkmk noch enthalten, da nur dieser alte Plattformen wie Windows XP und Windows 2003 zuverlässig überwachen kann. Diese beiden Systeme werden von dem neuen Agenten nicht mehr unterstützt. Zusätzlich soll der alte Agent die Migration zu dem aktuellen komfortabler gestalten. Dieser ist nach wie vor mit Checkmk kompatibel, dass dass ein Update Ihres Checkmk-Servers auf Version 1.6.0 nicht automatisch auch ein Update der Agenten erfordert.

4.2. Besonderheiten des Agenten bis Version 1.5.0

Der alte Windows-Agent hat folgende Unterschiede:

  • Unterschiedliche Nutzung der Verzeichnisse. Im alten Agenten ist das Installationsverzeichnis und das Konfigurationsverzeichnis dasselbe. Es wird ausschließlich das Verzeichnis C:\Program Files (x86)\check_mk\ genutzt.
  • Dadurch werden die verfügbaren Plugins nicht automatisch mit installiert, sondern müssen individuell vom Checkmk-Server runtergeladen und korrekt abgelegt werden.
  • Die Konfiguration wird im alten Agenten in einer Initialisierungsdatei (check_mk.ini) festgehalten. Die Standardkonfiguration und die Agentenbäckerei nutzen die identische Datei. Lokale Anpassungen können über die Datei check_mk.user.ini vorgenommen werden, die sich im gleichen Verzeichnis befinden muss.
  • Die Möglichkeiten tiefer in den Agenten einzusteigen sind stark eingeschränkt.

4.3. Migration zu dem neuen Standardagenten

Die Installation des aktuellen Agenten geschieht im Zweifel als zusätzliches Programm.. Dabei wird eine vorhandene Installation des alten Agenten als Referenz herangezogen und dessen Konfiguration in das YAML-Format des aktuellen Agenten übersetzt. Da der alte Agent normalerweise nicht deinstalliert wird, sondern lediglich der Service gestoppt und deaktiviert, können Sie die Konvertierung nach der Installation in den neu erstellten YAML-Dateien nachvollziehen.

Wenn Sie sich sicher sind, dass die Konvertierung korrekt funktioniert, können Sie auch bei der Installtion den alten Agenten automatisch deinstallieren.In diesem Fall, haben Sie danach keine weitere Arbeit - aber auch nicht mehr die Möglichkeit die Plugins oder Konfiguration des alten Agenten anzusehen.

5. Test und Fehlerdiagnose

5.1. Prüfen der Konfiguration

Um zu prüfen, ob die Konfiguration so eingelesen wurde, wie Sie das erwarten, können Sie den Agenten mit der Option showconfig aufrufen. 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, kann die Ausgabe auch auf eine bestimmten Teil eingeschränkt werden. Hier wird zum Beispiel geprüft, ob die Sektion ps korrekt geprüft wird:

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 Konfigurations­dateien von dem Agenten zusammengeführt und benutzt werden. Fehler sind somit sofort sichtbar.

5.2. Den Agenten testen

Es gibt unter Windows verschiedene Möglichkeiten, den Agenten auf seine Funktion zu testen. Mit der Option help bekommen Sie eine Übersicht, welche Diagnosemöglichkeiten der Agent im Einzelnen bietet. Die wichtigsten sollen hier vorgestellt werden.

Lokal testen

Mit der Option test können Sie den Agenten direkt lokal ausführen und sofort sehen, ob eine Ausgabe fehlerfrei erzeugt werden kann. Aus Platzgründen werden hier nur die ersten Zeilen als Beispiel gelistet:

C:\Program Files x86\checkmk\service> .\check_mk_agent.exe test
<<<check_mk>>>
Version: 1.6.0b8
BuildDate: Sep  4 2019
AgentOS: windows
Hostname: MSEDGEWIN10
Architecture: 64bit
WorkingDirectory: C:\Program Files (x86)\checkmk\service

Auf ähnliche Weise können Sie auch die Real-Time-Checks mit dem testen und sehen, ob die Werte in einer vertretbaren Zeit ausgegeben werden können. Beachten Sie, dass diese Option auf einen Startsignal wartet und sich auch erst beendet, wenn Sie das Signal dazu geben:

C:\Program Files x86\checkmk\service> .\check_mk_agent.exe rt
Press any key to START testing Realtime Sections
Realtime kick from '127.0.0.1' mem:true df:true winperf:true
df: Processed [1] drives
<<<df:sep(9)>>>
Windows_10      NTFS    41940988        21548916        20392072        52%     C:\
<<<mem>>>
MemTotal:      4193844 kB
MemFree:       2150888 kB
SwapTotal:     1441792 kB
SwapFree:      685112 kB
PageTotal:     5635636 kB
PageFree:      2836000 kB
VirtualTotal:  137438953344 kB
VirtualFree:   137434635112 kB
<<<winperf_processor>>>
1567626718.01 238 10000000
3 instances: 0 1 _Total
-232 247981250000 247822031250 247901640625 100nsec_timer_inv
-96 26199531250 28962031250 27580781250 100nsec_timer
-94 11261562500 8653750000 9957656250 100nsec_timer
-90 29692411 30441622 60134033 counter
458 97343750 817968750 457656250 100nsec_timer
460 230000000 653750000 441875000 100nsec_timer
1096 740994 1492053 2233047 counter
1098 0 0 0 rawcount
1508 241094017545 241103467681 241098742613 100nsec_timer
1510 241094017545 241103467681 241098742613 100nsec_timer
1512 0 0 0 100nsec_timer
1514 0 0 0 100nsec_timer
1516 21353597 22183421 43537018 bulk_count
1518 0 0 0 bulk_count
1520 0 0 0 bulk_count
Press any key to STOP testing Realtime Sections

Testen vom Monitoringserver aus

Wenn ein Problem nicht lokal vorhanden ist, haben Sie mit der Option -io eine weitere Möglichkeit, den Agenten auch von außen zu prüfen. Diese Option startet den Agenten kurzfristig als Service und protokolliert dann jede Verbindung, die von außen zu diesem Service hergestellt wird. Auf diese Weise können sie prüfen, ob eine Anfrage auch wirklich den Host erreicht. Bitte beachten Sie, dass der Windows-Service des Agenten nicht laufen darf, damit dieser Test funktioniert. Stoppen Sie daher vorher den Service und führen Sie danach den Test durch:

C:\Program Files x86\checkmk\service> .\check_mk_agent.exe check -io
testing 10 seconds
Starting IO ipv6:false, used port:6556
Connected from '192.168.42.1' ipv6 :false -> queue
Put on queue, size is [1]
Found connection on queue, in queue left[0]
Connected from '192.168.42.1' ipv6:false <- queue
No data to send
Shutting down IO...
Stopping execution
Exiting process queue
cma::world::ExternalPort::ioThreadProc:  terminated from outside
IO ends...

Mögliche Fehler werden ebenfalls in diesem Test protokolliert, so dass Sie bei einem Fehlerfall besser herausfinden können, wo die Ursache des Problems zu suchen ist.

5.3. Weitere Debugmöglichkeiten

Der Agent bietet über die bereits beschriebenen Optionen noch weitere Möglichkeiten viele Details über das konkrete Verhalten des Agenten herauszufinden. 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.

6. Einbinden von klassischen Checkplugins

6.1. Grundsätzliche Konfiguration

Unter Windows, können Sie weiterhin ihre Nagios-basierten Plugins auf einem Host ausführen, falls es dazu noch kein Pendant in Checkmk geben sollte. Der Mechanismus dafür ist recht simpel: Sie nutzen dafür das MRPE-Feature von Checkmk, welches sich analog zu dem NRPE von Nagios verhält.

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:

C:\ProgramData\CheckMK\Agent/check_mk.user.yml
mrpe:
  enabled: no

Die Ausführzeit 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 wahren, können Sie die maximale Laufzeit der MRPE-Plugins begrenzen. Der hier gezeigte Wert ist auch gleichzeitig der Standardwert in Sekunden. Passen Sie ihn also nur an, wenn Sie ein kürzeres oder längeres Intervall festlegen möchten:

C:\ProgramData\CheckMK\Agent/check_mk.user.yml
mrpe:
  # enabled: yes
  timeout: 60

6.2. Plugins über MRPE ausführen

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:

C:\ProgramData\CheckMK\Agent/check_mk.user.yml
mrpe:
  config:
    - check = MyServiceName 'C:\ProgramData\CheckMK\Agent\mrpe\my_check_plugin.bat' -w 10 -c 20 MyParameter

Die Datei ebenfalls in dem Verzeichnis des Agenten abzulegen ist keine Voraussetzung, auch wenn es sich anbietet, um alle an einem gemeinsamen Ort abzulegen. In dieser Beispielkonfiguration sehen Sie nun folgende Elemente der relevanten Zeile:

Element Beschreibung
MyServiceName Der Servicename, wie er in Checkmk angezeigt werden soll
'C:\ProgramData\CheckMK\Agent\mrpe\my_check_plugin.bat' Das Skript oder Programm, welches aufgerufen werden soll. Da Pfade und Dateinamen unter Windows Leerzeichen enthalten dürfen, markieren die Klammern die Zusammengehörigkeit des Ausdrucks.
-w 10 -c 20 Diesem Skript wurden Optionen übergeben. In diesem Fall ein Schwellwert von 10 für WARN und ein Schwellwert von 20 für CRIT.
MyParameter Dem Skript wurde zuletzt noch ein Parameter übergeben, welches nicht zu einer bestimmten Option gehört.

Nachdem Sie das MRPE-Plugin eingerichet haben, ist es direkt und ohne Neustart des Agenten aktiv und wird der Ausgabe hinzugefügt. In der Serviceerkennung werden Sie nun ihren neuen Service automatisch finden:

6.3. 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 in der Weboberfläche definieren. Benutzen Sie dazu den Regelsatz Monitoring Agents ➳ Generic Options ➳ Execute MRPE Checks. Der notwendige Eintrag wird dann automatisch in der Konfigurationsdatei der Bakery erzeugt.

7. Erweitern um Agenten-Plugins

7.1. Was sind Plugins?

Der Standardagent enthält eine ganze Reihe von Sektionen, welche Überwachungsdaten für diverse Checkplugins liefern und dann von der Serviceerkennung automatisch gefunden und als Services ausgegeben werden. Dazu gehören vor allem die wichtigen Überwachungen des Betriebssystems.

Darüber hinaus gibt es die Möglichkeitm den Agenten um Agentenplugins zu erweitern. Das sind kleine Skripten oder Programme, die vom Agenten aufgerufen werden und diesen um weitere Sektionen mit zusätzlichen Monitoringdaten erweitern. Das Checkmk-Projekt liefert hier bereits eine ganze Reihe solcher Plugins mit aus, welche – wenn sie korrekt installiert und konfiguriert sind -- in der Serviceerkkennung ebenfalls automatisch in neue Services münden.

Warum sind diese Plugins nicht einfach in den Standardagenten fest integriert? Für jedes der Plugins gibt es einen der folgenden Gründe:

  • Das Plugin kann seine Daten nur über interne Ports holen, die der Standardagent nicht bereitstellt.
  • Das Plugin benötigt ohnehin eine Konfiguration, ohne die es nicht funktionieren würde (Beispiel: mk_oracle.ps1).
  • Das Plugin ist so speziell, dass es von en meisten Anwendern nicht benötigt wird (Beispiel: citrix_licenses.vbs).

7.2. Manuelle Installation von Plugins

Checkmk liefert wie bereits erwähnt eine ganze Reihe an Plugins für Windows mit. Sie finden diese auf dem überwachten Host in dem Installationsverzeichnis des Agenten. Dort werden alle verfügbaren Plugins immer direkt mit dem Agenten abgelegt, damit Sie auch direkt zur Verfügung stehen: C:\Program Files (x86)\check_mk_service\plugins. Alternativ finden Sie die Plugins auch auf dem Checkmk-Server selbst unter local/share/check_mk/agents/windows/plugins. Auch über die Downloadseite der Agenten im WATO (wie am Anfang des Artikels beschrieben) sind diese im Kasten Windows Agent - Plugins verfügbar:

Zu allen von uns mitglieferten Agentenplugins gibt es auch passende Checkplugins, welche die erhobenen Daten auswerten und Services erzeugen können. Sie müssen also nichts zusätzlich auf dem Checkmk-Server installieren.

Wichtig: Werfen sie einen Blick in ein Agentenplugin, bevor Sie es auf einem Host installieren. Oft finden Sie dort wichtige Hinweise zu der korrekten Verwendung.

Die eigentliche Installation ist dann einfach. Kopieren Sie das gewünschte Plugin entweder vom Checkmk-Server oder aus dem Installationsverzeichnis nach C:\ProgramData\CheckMK\Agent\plugins. Wenn das Plugin in diesem 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.

7.3. Konfiguration der Plugins

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 ohne weitere Schritte. Sie haben verschiedene Quellen, um an Informationen zu kommen:

  • Die Dokumentation der zugehörgen Checkplugins im WATO-Modul Check plugins
  • Kommentare im Plugin selbst (oft sehr hilfreich!)
  • Einen passenden Artikel in diesem Handbuch (z. B. über das Überwachen von Oracle)

7.4. Ausführung eines speziellen Plugins anpassen

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

Option Wert Beschreibung
pattern '@user\*.ps1' 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 Installations-, oder aus dem Datenverzeichnis ausgeführt werden soll.
run yes/no Bestimmt, ob die Ausführung eines Plugins unterdrückt werden soll.
async yes/no Führt ein Plugin asynchron aus und legt die Daten in einer Datei ab. Bei synchroner Ausführung wird die Ausgabe direkt an den Agenten übergeben.
timeout 120 Setzt die maximale Ausführzeit. Danach wird das Plugin beendet, auch wenn keine Ausgabe gekommen ist.
cache_age 3600 Legt in Sekunden fest, wie lange eine Ausgabe gültig ist. Wenn async aktiviert ist, wird automatisch ein Cache von ??? Sekunden angelegt.
retry_count 3 Die Anzahl, wie oft ein Plugin fehlschlagen darf, bevor eine Ausgabe aus dem Cache verworfen wird.
description 'Text' Hier können Sie einen freien Text eintragen, der den Logs angefügt werden soll.

7.5. Plugins über die Bakery installieren

Die von Checkmk mitglieferten Plugins können über die Agent Bakery konfiguriert werden. Diese sorgt sowohl für die Installation des Plugins selbst, als auch für die korrekte Erstellung der Konfigurationsdatei, falls eine notwendig sein sollte.

Jedes Plugin wird über eine Agentenregel konfiguriert. Sie finden die passenden Regelsätze in Monitoring agentes ➳ Agent plugins:

7.6. Plugins von Hand ausführen

Da Agentenplugins ausführbare Programme sind, können Sie diese zu Test- und Diagnosezwecken auch von Hand ausführen. Es gibt allerdings Plugins, welche bestimmte vom Agenten 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.

8. Absicherung

8.1. Vorüberlegung

Wie auch bei dem Linux-Agent muss auch der Agent für Windows sicher sein.Aus dem Grund gelten hier auch die gleichen Grundgedanken, wie unter Linux. Auch unter Windows liest der Agent keinerlei Daten vom Netzwerk, so dass ein Angreifer über den Überwachungsport 6556 niemals Befehle oder Skripte einschleusen kann.

Wird das überwachte System über eine unsichere (Internet-)Verbindung abgefragt, werden zusätzliche Maßnahmen notwendig. So verfügt der Agent über eine optionale eingebaute Verschlüsselung. Auf neueren Windows-Versionen ist zusätzlich natives SSH möglich, so dass eine Verschlüsselung über die gesamte Verbindungsdauer gewährleistet werden kann, wie man das unter Linux bereits kennt.

Diese und andere Methoden der Absicherung werden im Folgenden näher beschrieben.

8.2. Beschränkung des Zugriffs über IP-Adressen

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:

C:\ProgrammData\CheckMK\Agent\check_mk.user.yml
global:
  only_from: 127.0.0.1/32 192.168.42.73/32

Wie in dem Beispiel gut zu sehen, 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 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 den Regelsatz Monitoring agents ➳ Rules ➳ Generic options ➳ Restrict agent access via IP address per WATO konfigurieren.

Natürlich kann ein Angreifer sehr leicht seine IP-Adresse fälschen und so eine Verbindung zum Agenten bekommen. Aber dann ist es sehr wahrscheinlich, dass er die Antwort nicht bekommt – weil diese zum echten Monitoringserver geht. Oder er bekommt sie tatsächlich, aber der CMK-Server bekommt keinerlei Daten und wird sehr bald einen Fehler melden.

8.3. Aufruf über SSH

Neuere Versionen von Windows haben eine native Unterstützung für SSH. 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.

Beachten Sie, dass Sie den Windowsdienst danach stoppen können und auch eine eventuell eingerichtete Firewallregel damit obsolet ist.

8.4. Eingebaute Verschlüsselung

Ab Version 1.4.0 von Checkmk kann der Windows-Agent (und auch das Linux-Pendant) seine Daten ohne Zusatzmittel selbst verschlüsseln. Dies ist streng genommen kein Ersatz für eine Zugangskontrolle. Da aber ein Angreifer ja keine Befehle senden und mit verschlüsselten Ausgabedaten nichts anfangen kann, kommt es einer solchen schon sehr nahe.

Der Aufwand für die Verwendung der Verschlüsselung und die nötige zusätzliche CPU-Last sind beide geringer, als bei der oben beschriebenen Methode mit SSH, welche wir aber nach wie vor bei der Übertragung über das Internet empfehlen.

Die Verschlüsselung braucht natürlich sowohl auf dem Agenten als auch auf dem Server eine passende Konfiguration. Diese kann entweder von Hand erstellt werden ( Checkmk Raw Edition) oder mit der Agentenbäckerei ( Checkmk Enterprise Edition).

Aufsetzen ohne Bakery

Auch ohne Agentenbäckerei geht der erste Schritt über WATO: Anlegen einer Regel im Regelsatz Host & Service Parameters ➳ Access to agents ➳ Encryption. Die Regel soll auf alle Hosts greifen, für die Sie Verschlüsselung einsetzen möchten. SNMP-Hosts ignorieren diese Einstellung, daher müssen Sie sie nicht explizit ausschließen.

Wichtig ist die Einstellung für Encryption for agent. Solange Sie die Regel auf dem Default Disable lassen, bleibt natürlich alles beim Alten. Sie haben also die Wahl zwischen:

  • Enable: Verschlüsselung wird aktiviert, aber Daten von Agenten ohne Verschlüsselung werden weiter akzeptiert.
  • Enforce: Verschlüsselung wird aktiviert, nur noch verschlüsselte Daten werden akzeptiert.

Sinnvoll ist es, zunächst mit Enable zu beginnen. Sobald Sie meinen, dass alle Agenten auf Verschlüsselung umgestellt sind, stellen Sie auf Enforce, um dadurch Hosts zu finden, die noch Daten im Klartext senden.

Die Verschlüsselung funktioniert mit einem gemeinsamen Passwort, das Sie hier angeben und sowohl auf dem Checkmk-Server als in der Konfiguration des Agenten im Klartext gespeichert werden muss („Shared secret“). Wählen Sie ein zufälliges Passwort aus und halten Sie es parat für den zweiten Schritt: die Konfiguration des Agenten.

Auf dem Windows-Server fügen Sie nun das Passwort der Konfiguration des Agenten hinzu. Auch diese kommen in den globalen Optionen rein:

C:\ProgrammData\CheckMK\Agent\check_mk.user.yml
global:
  encrypted: yes
  passphrase: MyPassword

Jetzt können Sie folgende Tests machen (siehe dazu auch den Artikel über die Kommandozeile von Checkmk):

  • Ein Aufruf von check_mk_agent auf dem Zielsystem muss wirren Zeichensalat ausgeben.
  • Ein telnet myhost123 6556 vom Checkmk-Server muss den gleichen Zeichensalat ausgeben.
  • Ein cmk -d myshost123 auf dem Checkmk-Server muss die sauberen Klartextdaten anzeigen.

Aufsetzen mit der Bakery

Das Aufsetzen der Verschlüsselung mit der Agentenbäckerei ist sehr einfach. Mit dem Erstellen der gerade beschriebenen Regel sind Sie im Grunde fertig. Sie brauchen nur noch neue Agenten zu backen und zu verteilen. Die Datei /etc/check_mk/encryption.cfg wird automatisch für Sie erzeugt und mit in die Agentenpakete eingebaut.

9. Überwachen von Windows per SNMP

Es gibt ein paar wenige Situationen, in denen eine Überwachung per SNMP zusätzlich zum normalen Agenten sinnvoll sein kann. Und zwar ist das der Fall, wenn entweder eine eigene Anwendungs­software oder ein Hardwareüber­wachungstool des Serverherstellers Überwachungsdaten nur per SNMP liefern und – entweder aufgrund der eingesetzten Windowsversion oder weil es für die Anwendung keine Commandlets gibt – eine Abfrage über Powershell nicht möglich ist.

Setzen Sie in so einem Fall in den Eigenschaften des Hosts im WATO im Kasten DATA SOURCES die Einstellung SNMP auf die geeignete Verbindungsart (snmpv2/3 oder snmpv1). In Versionen älter als 1.5.0 heißt der Kasten Host tags und wird auf Dual: Check_MK Agent + SNMP umgestellt. Services, die sowohl per SNMP als auch per Checkmk-Agent verfügbar sind (z. B. CPU-Auslastung, Dateisysteme, Netzwerkkarten), werden dann automatisch vom Checkmk-Agenten geholt und nicht per SNMP. Damit wird eine Doppeltübertragung automatisch vermieden.

10. Dateien und Verzeichnisse

10.1. Pfade auf dem überwachten Host

Pfad Bedeutung
C:\Program Files (x86)\checkmk\service\ Installationsverzeichnis für die programmspezifischen Dateien. Hier befindet sich auch der eigentliche Agent check_mk_agent.exe
C:\ProgramData\checkmk\agent\ Installationsverzeichnis für die hostspezifischen Dateien. Hier befinden sich Erweiterungen, Logsund Konfigurationsdateien, welche spezifisch für diesen Host gelten.
C:\ProgrammData\checkmk\agent\check_mk.user.yml Konfigurationsänderungen durch den Benutzer werden hier hinterlegt.
C:\ProgrammData\checkmk\agent\bakery\check_mk.bakery.yml Konfigurationsanpassungen durch die Bakery sind hier gespeichert.
C:\ProgrammData\checkmk\agent\plugins Hier werden die Plugins abgelegt, welche automatisch vom Agenten ausgeführt werden sollen.
C:\ProgrammData\checkmk\agent\local Das Verzeichnis für eigene local-Skripten
C:\ProgrammData\checkmk\agent\mrpe MRPE-Erweiterungen können hier gespeichert werden.
C:\ProgrammData\checkmk\agent\backup Nach jeder Änderungen des Checkmk-Agenten-Service wird von der Benutzerkonfiguration hier ein Backup angelegt.

10.2. Pfade auf dem Checkmk-Server

Pfad Bedeutung
local/share/check_mk/agents/custom/ Basisverzeichnis für eigene Dateien, die mit einem gebackenen Agenten mit ausgeliefert werden sollen.
share/check_mk/agents/windows/ Die Agenten und ihre MSI-Pakete sind hier hinterlegt. In diesem Verzeichnis finden Sie auch Konfigurationsbeispiele und alle Plugins für den Agenten.