Mit dem Release von Checkmk 2.0 hat der Anbieter tribe29 sein Nagios-basiertes Werkzeug einer weitreichenden Runderneuerung unterzogen. Der Fokus lag auf der Modernisierung des Dashboards, doch auch die Überwachung von Container- und Cloudumgebungen und die Automatisierungsfunktionen haben deutlich zugelegt. Administratoren profitieren außerdem von verbesserten Visualisierungsmöglichkeiten und der Aufwertung der Programmierschnittstellen.

Da Checkmk 2.0 sehr viele Änderungen gegenüber seinen Vorgängern mitbringt, wollen wir die neuen Features zunächst im Überblick betrachten: In der neu gestalteten Benutzeroberfläche haben Entwickler auch die Navigation und die Dashboard-Erstellung vereinfacht. So lassen sich neben den Haupt-Dashboards weitere aufgabenspezifische Dashboards anlegen. Das ergibt insbesondere bei verteilten Umgebungen Sinn, weil sich beispielsweise Site- oder Service-Daten bündeln lassen. Auch stehen verschiedene neue Dashboard-Elemente wie die Messgeräteansicht zur Verfügung. Eine weitere praktische Funktion: Mit Hilfe von dynamischen Filtern können Sie eigene Dashboard-Vorlagen generieren, die auf Grundlage von spezifischen Filterkriterien die Darstellung auf einen speziellen Service-Typ beschränken.

Neben den rein optischen Verbesserungen verbirgt sich unter der Haube eine Fülle interessanter Details. So baut Checkmk 2.0 insbesondere die Prometheus-Integration aus und integriert nunmehr mit cAdvisor, Node_exporter und kube-state-metrics alle wichtigen Prometheus-Exporter. Beim Cloudmonitoring wurde die Überwachung von ELB, EC2 und RDS verbessert und das Monitoring um AWS-Services wie Glacier, DynamoDB und die Web Application Firewall erweitert. Auch die Microsoft-Azure-Cloud lässt sich mit Checkmk überwachen: Hier ist das Monitoring des Dienstes Active Directory Connect möglich.

Checkmk setzt grundsätzlich eine Linux-Umgebung als Plattform voraus. Alternativ lässt sich die Software als virtuelle und physische Appliance oder als Docker-Container betreiben. Der Installationsprozess auf einem physischen oder virtuellen Linux-Server umfasst vier Schritte: Zunächst sind die notwendigen Systemvoraussetzungen zu erfüllen, anschließend richten Sie die Paketquellen ein und führen den Download des geeigneten Checkmk-Pakets durch. Den Abschluss bildet die eigentliche Installation.

Unsere Vorbereitungen waren schnell erledigt: Zunächst ist wichtig, dass das spätere Monitoringsystem per HTTP und SSH erreichbar ist. Da Checkmk seine Daten im Verzeichnis "/opt/omd" ablegt, sorgten wir für entsprechende Speicherplatzkapazitäten. Weiterhin richteten wir SMTP- und NTP-Dienste ein, damit Checkmk seine Warnungen verschicken kann und für eine korrekte Zeitkonfiguration gesorgt ist.

Die eigentliche Installation gestaltete sich einfach, wir führten sie unter Debian/ Ubuntu durch. Da die Übertragung der Installation per SCP erfolgt, mussten wir zunächst einen OpenSSH-Server installieren. Dann übertrugen wir "Checkmk Raw Edition" für Ubuntu 20.04 (focal fossa) auf das Monitoringsystem. Da alle Pakete mit GnuPG signiert sind, war zur Verifizierung und Überprüfung der Abhängigkeiten das Paket "dpkg-sig" zu installieren. Anschließend luden wir den gültigen Schlüssel herunter und importierten diesen via

Nach der Verifizierung des Checkmk-Pakets ging es an den eigentlichen Installationsvorgang, der lediglich folgendes Kommando umfasste:

Nach der erfolgreichen Installation zeigte uns ein Abschlusstest die Funktionstüchtigkeit der Umgebung. Dazu genügte es, die aktuelle Checkmk-Version abzurufen.

Um Checkmk als Appliance zu installieren, muss diese in die jeweilige Virtualisierungsumgebung importiert und die Inbetriebnahme dort ausgeführt werden. Unabhängig von der Wahl der Installationsmethode lässt sich Checkmk nach dem Zugriff über WATO (Web Administration Tool) konfigurieren.

Professionelles Netzwerkmonitoring darf sich nicht nur auf die Erfassung von relevanten Netzwerkkomponenten beschränken, sondern muss auch den Traffic im Netzwerk beobachten. Checkmk 2.0 integriert ntop zum Network-Flow-Monitoring, allerdings erst ab der Enterprise-Variante. Von Vorteil ist dabei, dass Sie der Aufbereitung exakt entnehmen können, wer was, wann und wo im Netzwerk macht und wo sich mögliche Engpässe oder Anomalien auftun. Neben den Basisinformationen zu den jeweiligen Hosts zeigte uns die Software Details zu Packets, Ports, Peers, Applikationen und Flows. Die Flow-Daten fanden wir im sogenannten Flow-Dashboard und das Top-Talkers-Dashboard zeigte uns in Echtzeit, welche Hosts den meisten Netzwerkverkehr verursachen.

Die Integration von ntop in Checkmk 2.0 ist dabei keineswegs mit einer Verschmelzung beider Tools gleichzusetzen – im Gegenteil. Checkmk und ntop laufen meist als unabhängige Systeme auf unterschiedlichen Servern und Checkmk kommuniziert via REST-API mit ntop. In der Praxis gestaltete sich das Zusammenspiel einfach, da wir dafür lediglich die ntop-Verbindungsparameter angeben mussten.

 Im Menü "Network Statistics" tauchte dann automatisch der ntop-Eintrag auf und wir sahen mit einem Klick auf "Ntop Hosts" die gewünschten Traffic-Daten. Als vorteilhaft erweist sich dabei der Umstand, dass sich etwaige Alarme im übergeordneten Alarm-Dialog finden. Besonders einfach gestaltete sich die Identifikation der Netzwerkressourcen, die den meisten Traffic verursachen. Auch hier lieferte Checkmk eine grafische Auswertung, was die Beurteilung der Netzwerkbelastung mit wenigen Blicken erlaubt.

Einen weiteren Pluspunkt von Checkmk stellt das optimierte Netzwerkschnittstellen- und Switch-Port-Monitoring dar. Mit der neuen Version haben die Entwickler die Regelsätze für die Discovery-Prozesse erweitert. So ließen sich im Test einzelne oder gruppierte Schnittstellen mit einem Regelsatz kombinieren. Diese Aufgabe gliederte sich in drei Teile: die Konfiguration der Discovery-Aktionen einzelner Interfaces, die Konfiguration von Interface-Gruppen und die Definition des Geltungsbereichs von Regeln.

An diesem Beispiel zeigt sich, dass Checkmk verschiedene Detailverbesserungen erfahren hat, die sich nicht auf den ersten, sondern auf den zweiten Blick erschließen. Checkmk 2.0 erlaubt es, alle Schnittstellen abzugleichen. Dies kann beispielsweise zur Vereinfachung von Regeln dienen, bei denen Admins alle Schnittstellenporttypen und -zustände auswählen.

In Anlehnung an die Nagios-Plug-in-Plattform stehen über "Checkmk Exchange" knapp 400 Erweiterungen zur Verfügung. Neben verschiedenen Sprachpakten finden sich dort beispielsweise ein Plug-in für Benachrichtigungen per Telegram, verschiedene Statistiken, ein MikroTik-Router-Plug-in und eines für die Überwachung des Intrusion-Prevention-Systems Fail2ban. Die beliebteste Erweiterung dient der Prüfung von SSL-Zertifikaten. Besonders komfortabel gestaltet sich das Verteilen von Agenten mit der verbesserten "Agent Bakery". Checkmk 2.0 erlaubt das verteilte Agenten-Update in segmentierten Netzwerken. So konnten wir im Test exakt bestimmen, ob, und wenn ja, wann genau welche Updates verteilt wurden.

Die administrative Arbeit vereinfacht sich weiter dank der Unterstützung lokaler Dateien, denn damit gestaltet sich das Ausrollen benutzerdefinierter Plug-ins einfacher. Für Linux-Agenten lässt sich ein konfigurierbarer Netzwerkdienst (systemd oder xinetd) einrichten. In der Praxis profitieren IT-Verantwortliche außerdem von der API für die dynamische Konfiguration, die das Erstellen von individuellen Connectoren erlaubt. Kleiner Wermutstropfen: Diese Funktionalitäten sind lediglich in der Enterprise-Edition verfügbar.

Mit Checkmk 2.0 wurde auch die Funktionalität der Windows-Agenten verbessert und plattformübergreifende Agent-Plug-ins erfahren eine bessere Unterstützung. Außerdem gehören die falschen Virenalarme der Vergangenheit an und auch die manuelle Anpassung der Windows-Firewall ist obsolet.

Für ein Plus an Automatisierung implementiert Checkmk 2.0 eine neue Anwendungsprogrammierschnittstelle, die Checkmk-REST-API. Diese erlaubt die Automatisierung von Aufgaben, die üblicherweise über die GUI erfolgen, per Kommandozeile oder Skript mit HTTP-Anfragen an den Checkmk-Server.

Die REST-API deckt die vollständige Funktionalität ab, die Checkmk über die GUI und über die Kommandozeile bietet. Damit kann sie den Vorläufer, die Web-API, vollständig ersetzen. Entsprechend der REST-Architektur macht sich die API verschiedene Mechanismen wie das Client-Server-Modell, die zustandslose Kommunikation und einheitliche Schnittstellen zunutze. Bei der Implementierung kommt primär das HTTP-Protokoll zum Einsatz. Ressourcen werden per Uniform Resource Identifier (URI) angesprochen und bekannte HTTP-Methoden (GET, POST, PUT, DELETE) sorgen für die gewünschte Aktion. Für die Entwicklung von Automatisierungsskripts stellen die Entwickler eine umfangreiche Dokumentation zur Verfügung. In diesem Kontext müssen wir die ohnehin vorbildliche Dokumentation positiv hervorheben. Die Nutzung von REST gestaltete sich in der Praxis einfach, da wir die Skripte über die Web-GUI ausführten.

An diesem Punkt zeigt sich, dass die Software mit der Zeit geht: Die Automatisierungsfunktionen sind flexibel und leistungsfähig, nach einer kurzen Einar- beitungszeit erlernt und bieten vielfältige Möglichkeiten zur Optimierung von typischen Monitoringprozessen.

Hochfunktionale Umgebungen leiden häufig an einer unbefriedigenden Performance, da sie zu viele Aufgaben gleichzeitig bewältigen. In der Praxis machen neue Funktionen bestehende Anwendungen eher langsamer als schneller. Signifikante Performance-Einbrüche sind üblicherweise der parallelen Ausführung einer hohen Prozesszahl geschuldet. Auch tribe29 ist sich dieser Problematik bewusst und hat daher mit Checkmk 2.0 die Software-Architektur überarbeitet. Ein neues Helper-Modell für den "Checkmk Micro Core" (CMC) verspricht die Reduzierung des Arbeitsspeicherbedarfs bei gleichbleibender Leistungsfähigkeit. Allerdings gelangen nur Kunden der Enterprise-Edition in den Genuss dieser Weiterentwicklung, da die Community-Edition weiter auf dem Nagios-Kern basiert.

Während in Checkmk 1.6 sich der durch einen Helper-Prozess unterstützte Core-Prozess als speicherlastig entpuppte, teilt Version 2.0 den Prozess auf "Fetchers" und "Checkers" auf. Die Aufgaben der Fetcher ist das Einlesen von rohen Monitoringdaten, die beispielsweise von Agenten stammen oder per SNMP in das System gelangen. Hat ein Fetcher alle relevanten Daten erhalten, reicht er diese an den Checkmk-Kern weiter.

Der CMC leitet die Daten an die Checker-Prozesse weiter. Dank des neu gestalteten Verarbeitungsprozesse können die Checker die Daten unmittelbar bearbeiten und für die Ausgabe des Service-Status sorgen. Dieser Umbau hat zur Folge, dass sich die Checker nicht mehr im Leerlauf befinden und daher auch weniger Checker-Prozesse initiiert werden müssen. Das wiederum führt zu einer signifikanten Verringerung der Arbeitsspeicher- und der CPU-Auslastung.

In der Praxis ergeben sich durch die geänderte Software-Architektur positive Effekte auf die Ausführung verschiedener Dienste. Diese machen sich beim Aktivieren von Änderungen in verteilten Monitoringumgebungen mit der inkrementellen Konfig-Sync bemerkbar. Die Aktualisierung der DNS-Einträge von Hosts soll sogar 100-mal schneller sein, die Ladezeiten bis zu sechsmal.

Auch die Regelauswertung durch die Verwendung expliziter Host-Attribute und das Rendern von Graphen mit hoher Datenauflösung sollen jetzt deutlich schneller ablaufen. In unserer eher kleinen Testumgebung konnten wir die Performancegewinne allerdings nicht exakt quantifizieren.

Die Frischzellenkur, die die Checkmk-Entwickler ihrer Monitoringumgebung verpasst haben, war überfällig und hat der Software sehr gutgetan. Im Test zeigte sich, dass sich dank der Runderneuerung der Benutzeroberfläche das gesamte Handling vereinfacht. Die verschiedenen Detailverbesserungen krönen dabei ein rundum gelungenes Produkt. Auch preislich bewegt sich Checkmk 2.0 in einem Segment, das sich kleine und mittlere Unternehmen leisten können. Ein Umstieg lohnt definitiv.