Checkmk Conference #6: Der verbesserte Windows Agent

Windows gewinnt in der Server-Welt wieder an Popularität. Daher gehört es zu einem guten Monitoring auch dazu, dass es gut mit Windows umgehen kann. Mit einem eigenen Agenten für Windows bieten wir zudem einige Vorteile, gegenüber einer Überwachung über WMI oder SNMP, etwa minimaler Ressourcenverbrauch, Zugriff auf Daten, die sich mit WMI oder SNMP nicht auslesen lassen, sowie die Erstellung von eigenen Erweiterungen.

Mit der Checkmk 1.6 haben wir unseren alten Windows Agenten komplett neu überarbeitet, um einen reibungsloseren Betrieb zu ermöglichen. Dies war notwendig, da der alte Agent an seine Grenzen gestoßen ist. Schließlich hat Mathias Kettner den ersten Windows-Agenten unter Linux gebaut. Als Toolchain bediente sich Mathias damals einer Virtual Box, in der Windows XP lief. Obwohl dieser „erste“ Windows-Agent ziemlich gut funktioniert hat und wir ihn immer weiter entwickelt haben, handelte es sich jedoch im Grunde um eine Implementierung, die auf einer „Low-Level-API“ von Windows aufsetzt, wie Mathias auf der Checkmk Konferenz #5 im letzten Jahr bei der Vorstellung des neuen Agenten berichtete.

Die Linux-basierte Toolchain des alten Windows Agenten bedeutete jedoch einen immer höheren Aufwand für uns beim Debugging sowie beim Programmieren von Erweiterungen. So war es 2019 mit dem Release von Checkmk 1.6 an der Zeit, das Monitoring von Windows-Systemen auf einen neuen Level zu heben und mit den nativen Entwicklungswerkzeugen von Windows arbeiten. Auf diese Weise wollten wir die Arbeit und das Monitoring mit dem neuen Agenten vereinfachen und für die Anwender reibungsloser gestalten.

Rückblickend ist uns das gelungen, da wir seitdem weniger als 80 Support-Tickets und weniger als zehn Bugfixes mit Bezug zum neuen Windows Agenten bearbeiten mussten, wie Product Manager Marcel Arentz und Entwickler Sergey Kipnis in ihrem Vortrag auf der Checkmk Konferenz #6 berichteten.

Vor allem die Migration von Version 1.5 auf 1.6, die Architekturänderungen des Agenten mit 1.6 und die Erzeugung von False-Positives durch den Agent Updater in Antivirusprogrammen auf manchen Systemen machten das Gros der Nutzeranfragen aus, wie Marcel erzählte.

Typische Supportanfragen handelten beispielsweise darum, warum die alte Version nicht bei der Installation des neuen Agenten gelöscht wird. Zudem waren User unsicher, wann sie den alten Agenten deinstallieren sollen und warum Checkmk nicht alle Daten des alten Agenten automatisch gelöscht hat. Während der Installationsprozess des neuen Agenten sich nicht verändert hat, unterscheidet sich hingegen das Entfernen des alten Agenten, erklärte Marcel. Dieser wird nicht standardmäßig deinstalliert, sondern deaktiviert und befindet sich somit weiterhin auf dem System. Auch die alten Originaldaten bleiben erhalten, um den alten Agenten wiederherstellen zu können – falls die die Migration auf den neuen Agenten schiefgeht.

Hat das Update auf den neuen Windows-Agenten geklappt, empfiehlt Marcel die automatische – nicht die manuelle – Deinstallation des alten Agenten über den Uninstaller oder durch das Aktivieren der Checkbox für die Deinstallation im Installer, etwa beim Rollout der verbleibenden Hosts. Eine dritte Option ist das automatische Entfernen durch das Anlegen und Ausführen einer entsprechenden Regel im „Legacy Agent Management“ über die Agent Bakery, wie Marcel weiter ausführte.

Händisch hinzugefügte Daten des alten Agenten, die nicht zum Installer gehören, verbleiben auch nach dessen Deinstallation im Ordner, etwa Plugins oder Konfigurationsdaten. Wenn der Anwender diese nicht mehr benötigt, muss er diese laut Marcel selbstständig löschen. Weitere Informationen zur Migration des Agenten von Version 1.5 zu 1.6 finden sich im Handbuch. Die Unterschiede zwischen 1.5 und 1.6 finden sich im Handbuch des Windows Agents in den Kapiteln 3, 6 und 7.

Mit der Version 2.0 soll der Windows-Agent zudem weitere Funktionen erhalten, etwa einen nativen Python-Plugin-Support, eine automatische Firewall-Konfiguration, sowie das Ausführen von Plugins mit spezifischen Berechtigungen und eine kontrollierte Deinstallation des Agenten. Wir wollen diese Punkte nun noch etwas vertiefen.

Native Python-Plugin-Support

Die Vorteile der nativen Unterstützung von nativen Python-Plugin-Support lauten unter anderem:

• vereinheitlichte Python-Konditionen auf jedem Windows-Host,
• in Python 3.8 programmierbare Plugins,
• Möglichkeit von Cross-Platform-Plugins,
• gesteigerte Zuverlässigkeit und Leistung sowie
• die Auslieferung von Standard-Plugins, etwa logwatch, agentupdater, etc., ohne Pyinstaller, sodass es keine False-Positives mehr mit dem Antivirus-Programm gibt.

Zentralisierte Firewall-Konfiguration

Eine zentralisierte Firewall-Konfiguration und Administration auf dem Checkmk-Server soll mit 2.0 eine unproblematische Ersteinrichtung über mehrere Hosts hinweg ermöglichen. Dazu konfiguriert der Anwender das gewünschte Installationspaket mit den benötigten Port in der Agent Bakery. Wenn man den Agent anschließend auf dem lokalen Host installiert, passt dieser automatisch die Firewall entsprechend an.

In der Vergangenheit konnte Checkmk in einigen Fällen nicht auf einen Windows-Host zugreifen, da es ein Problem mit der Firewall gab. Um das Problem zu beheben, musste man eine Firewall-Regel für den Agenten in der Windows Firewall setzen. Da sich immer mal wieder Ports ändern und Programme ändern, hilft die zentralisierte Konfiguration der Windows-Firewall dabei, Änderungen problemlos auch zu einem späteren Zeitpunkt anzupassen, wie Sergey erklärte. Administratoren, die diese Funktion nicht benötigen, haben die Möglichkeit, diese Option in der Agent Bakery zu deaktivieren – auch wenn Sergey dies nicht empfiehlt.

Ausführen von Plugins mit spezifischen Berechtigungen

Mit 2.0 wird es außerdem die Möglichkeit geben, dass sich jedes Plugin innerhalb von virtuellen Accounts ausführen lässt. Monitoring von einigen Ressourcen mit nur einem administrativen Account ist äußerst kompliziert oder sogar nicht möglich, wie Sergey anmerkte. Auf der anderen Seite sind Administrationsrechte außerdem nicht im jedem Fall angebracht. Daher wird es mit dem neuen Release zwei neue Optionen geben. Die erste Möglichkeit wird es sein, dass ein lokaler Agent einen spezifischen, temporären und unsichtbaren User hat, der sich für eine lokale Gruppe festlegen lässt. Dieser kann Plugins in dessen Namen ausführen. Diese Methode unterstützt kein Active Directory und benötigt keine Anmeldedaten oder Konfigurationsdateien auf dem Server und Host.

Die zweite Option ermöglicht es, einen User und ein Passwort festzulegen. Hierbei gibt es keine Limitierung der spezifischen Berechtigungen. Sergey betonte an dieser Stelle jedoch ausdrücklich, dass das Passwort in plain text in Checkmk und auf dem Host hinterlegt ist. Typische Anwendungsfälle für diese Option seien beispielsweise das Monitoring von Datenbanken oder Network-Share-Monitoring.

Deinstallation des Agenten

Da wir außerdem öfters Anfragen bekommen haben, wie sich der Agent richtig entfernen lässt, wird es auch hier Verbesserungen mit der Version 2.0 geben. Diese soll künftig alle Dateien und Ordner standardmäßig löschen, die zu einem Agenten gehören. Ferner ist es mit dem neuen Release laut Sergey möglich, alle Daten zu löschen, um eine komplett saubere Installation durchzuführen. Es bestehe auch die Option, keine der alten Daten zu löschen, um bei einem Fehler eine Analyse anzustoßen.

In unserem nächsten Beitrag zur Checkmk Konferenz #6 werden wir euch ein bisschen über unsere Pläne mit euch, der Checkmk Community erzählen!