Checkmk Conference #6: Wie wir Checkmk entwickeln

Auf unserer Checkmk Konferenz #6 hat unser Chefentwickler Lars Michelsen euch erzählt, an was für Projekten unser Entwicklerteam derzeit arbeitet und auf was wir für euch alles für Verbesserungen mit der Version 2.0 geplant haben. Wir haben euch daher einige wichtigen Aspekte aus seinem Vortrag herausgepickt, die wir euch natürlich nicht vorenthalten wollen.

Ein wichtiger Bestandteil bei der Weiterentwicklung von Checkmk macht die Verbesserung der Nutzererfahrung aus. Die UX ist für uns derart wichtig, dass unser Gründer Mathias Kettner hierzu noch einen detaillierten Vortrag auf der Konferenz gehalten hat und anhand von verschiedenen Tech-Previews auch euch um Feedback geben hat. Dazu wollen wir euch noch einen gesonderten Blogbeitrag erstellen. Stattdessen fokussieren wir uns auf die Punkte, die Lars in seinem Vortrag angerissen hat:

Unter anderem soll die Raw Edition ein modernisiertes Graphing erhalten, welches bereits in der Enterprise Edition eingesetzt wird. Unser Ziel ist es, ein konsistentes System für alle Editionen bereitzustellen. Das heißt, dass die HTML5-Graphen aus der Enterprise Edition das für Visualisierungen in der Raw Edition bisher verwendete Nagios PNP komplett ablösen – jedoch nicht im kompletten Funktionsumfang, wie Lars betonte. So sind etwa individuelle oder kombinierte Graphen weiterhin nur in der Enterprise Edition von Checkmk verfügbar. Der dahinter liegende Umbau ermöglicht nun auch eine Grafana-Integration für die Raw Edition.

Auch in Punkto Analyse von historischen Daten haben wir für die Version 2.0 einige Neuerungen auf der Agenda. Ein paar Funktionen sind teilweise schon in Version 1.6 nutzbar. So gibt es bereits die Möglichkeit, die zukünftige Entwicklung von Metriken vorherzusagen. Das kann dabei helfen, Probleme frühzeitig zu erkennen und Kapazitätsanforderungen vorauszusehen. Diese Funktion lässt sich auch in Reportings einbetten.

Verbessertes Reporting und kontext-sensitive Dashboards

Die Reporting-Möglichkeiten in Checkmk bauen wir mit der Version 2.0 ebenfalls weiter aus. So haben wir geplant, dass die PDF-Reportings nun optional ein Inhaltsverzeichnis und ein Deckblatt enthalten können. Darüber hinaus sollen sich spezifischen Zeiträumen für einzelne Elemente festlegen lassen. Bisher war es nur möglich, dass alle Elemente den gleichen Zeitraum zugewiesen bekamen.

Auch beim Thema Dashboard wird sich einiges tun, etwa neue Visualisierungsformen (Dashlets) oder ein einfacheres Erstellen von Dashboards. Diese sind jetzt kontext-sensitiv und erlauben, die Darstellung von spezifischen Sachverhalten, etwa alle Informationen für Host X. Auch soll es bereits vorgefertigte, intelligente Übersichten geben. Bis 2.0 wollen wir erste Dashboards für bestimmte Applikationen verfügbar machen, neben Checkmk etwa für vSphere, Linux oder Windows.

Ferner arbeitet unser Entwicklerteam an einer sogenannten Tag-Usage-Overview. Über die Ansicht soll der Nutzer auswerten können, wo – also in welchen Ordnern, Hosts oder Regeln – welche Tags und Tag-Gruppen angewendet werden.

Weiterentwicklungen vermeldete Lars auch für das Thema Cloud und Container. Seit der Einführung eines AWS-Monitorings mit dem Release 1.6 haben wir Checkmk um weitere Checks ergänzt, beispielsweise für AWS Glacier oder DynamoDB. Diese sind laut Lars in erster Linie Aufgrund aus Nutzeranfragen heraus entstanden. Im Vergleich zu Microsoft Azure haben wir zuletzt mehr Zeit in die Verbesserung der Überwachung von AWS investiert. Für das Monitoring von Azure haben wir aber mit dem Monitoring der Koppelung von Active Directory eine wichtige Funktion geschaffen, die für das Gros der Azure-Umgebungen relevant ist.

Das Monitoring von Kubernetes funktioniert nach Meinung von Lars bereits gut. Des Weiteren haben wir die Funktionalität unseres Kubernetes-Monitoring um weitere Checks ergänzt, etwa durch einen Check für Ingress-Objekte sowie ein Inventory-Plugin. Checkmk ist somit in der Lage, für Jobs in Kubernetes-Clustern ebenfalls Inventory-Daten zu ermitteln und via eines Checks den Status auszuwerten. Beim Monitoring von Kubernetes-Umgebungen mit Checkmk spielt auch die Integration von Prometheus eine Rolle – hierzu liefern wir euch bald detaillierte Informationen nach.

Ein wesentlicher Bestandteil der Cloud- und Containeranbindung in Checkmk ist der Dynamic Configuration Daemon (DCD). Er sorgt dafür, dass Checkmk Konfigurationsänderungen automatisch übernimmt. Auf diese Weise erkennt Checkmk etwa flüchtige Elemente in dynamischen Infrastrukturen und entfernt diese nach ihrem Ableben automatisch wieder. Auch hier hat unsere Entwicklungsabteilung Hand angelegt und die Verarbeitung von Piggyback-Daten in Checkmk optimiert, etwa durch die freie Konfiguration der Lebensdauer von Daten. Ferner ist es möglich den DCD um eigene Connectoren für die Ankoppelung von eigenen Datenquellen, etwa einer CMDB, zu erweitern. Um dies noch weiter zu erleichtern, planen wir, die DCD-Plugin-API zu dokumentieren und zu verbessern.

Mehr Optionen für die Analyse von Netzwerkproblemen

Neben dem Monitoring von Servern spielt auch das Netzwerk-Monitoring für die unsere Checkmk-Nutzer eine große Rolle. Hier wollen wir als tribe29 künftig noch bessere Möglichkeiten bieten, wenn es um die Analyse von Netzwerkproblemen geht. Mit Version 2.0 wird Checkmk dank der Integration mit ntop die Möglichkeit bieten, Network Flows zu analysieren.

Außerdem haben wir bereits eine Reihe an neuen Checks vorgestellt, etwa für das Monitoring von VPN-Verbindungen, das laut Lars aufgrund der aktuellen Entwicklungen rund um Covid-19 und der Zunahme der Heimarbeit zunehmend gefragt ist. Aber auch für verschiedene Hersteller haben wir zuletzt einige neue Check- und Inventory-Plugins ergänzt.

Bezüglich der Automatisierung innerhalb von Checkmk hat Lars auf der Konferenz ebenfalls einiges erzählt: So soll die Agent Bakery künftig besser mit segmentierten Netzwerken umgehen können, um so Bandbreite zu sparen. Diese Funktion setzt die Distributed Agent Bakery um. Neu ist hierbei, dass nicht alle Agent-Updater mit der zentralen Agentenbäckerei kommunizieren, sondern zunächst mit ihrer jeweiligen lokalen Site sprechen. Agenten, die in der Remote Site nicht vorhanden sind, werden von der zentralen Site geholt und lokal gecacht, wenn es sinnvoll erscheint. Darüber hinaus haben wir nun Bakelets als allgemeines Konzept implementiert, um die automatische Verteilung von angepassten Daten zu unterstützen. Bisher waren Anpassungen an angebaute Plugins nur über die Bakery verteilbar, wenn ein Bakelet das unterstützt hat. Bei den Notification-Plugins ist neben dem bereits verfügbaren Plugin für Cisco Webex Teams zeitnah auch ein weiteres für Microsoft Teams in der Mache.

Mit dem Austausch der bisherigen Web-API durch eine REST-API hat Lars in seinem Vortrag auch ein weiteres großes Projekt unseres Entwicklungsteams in diesem Jahr angeschnitten. Hier sei der technische Grundstock bereits vorhanden, den wir nun auch mit Leben füllen wollen. Einen tieferen Einblick in die neue REST-API gab es am zweiten Konferenztag durch Checkmk-Entwickler Christoph Rauch.

Darüber hinaus arbeiten wir an der Überarbeitung der bisherigen Check-API. Da es sich hierbei laut Lars um die wichtigste Plugin-API der Monitoring-Software handelt, stand hier zunächst die Erstellung eines guten Konzepts auf der Agenda. Wie die neue Check-API aussehen soll, erläuterte Entwickler Moritz Kiemer ebenfalls am zweiten Veranstaltungstag. Wir werden euch die Informationen hierzu sowie zur REST-API bald auch hier im Blog vorstellen.

Bessere Performance in Checkmk

Da wir weltweit zahlreiche Enterprise-Kunden haben und auch mehr als die Hälfte der m DAX gelisteten Unternehmen auf Checkmk beim Monitoring ihrer IT-Infrastruktur setzen, ist für uns die Skalierbarkeit der Lösung ein absolutes Muss. Derzeit muss man die Helper-Prozesse immer mit dem vorhandenen Arbeitsspeicher in Einklang bringen, da die RAM-intensiven Checkmk-Helper häufig auf Netzwerk-I/Os warten.

Um die Abhängigkeit vom Arbeitsspeicher zu vermindern, hat unsere Entwicklung den Helper-Prozess nun zweigeteilt. Fetcher-Prozesse sollen ab Version 2.0 die Monitoring-Rohdaten einsammeln. Dafür benötigen sie laut Lars nur eine geringe Menge an Arbeitsspeicher. Ferner sind sie in der Lage, auf Network-I/Os zu warten. Auch das setzen eines Timeout-Fensters für eine Abfrage ist möglich. Durch die RAM-schonenden Prozesse lassen sich auf dem System große Mengen an Fetcher-Prozessen parallel ausführen, erklärte Lars.

Anschließend wertet ein freier Checker-Prozess die gesammelten Daten aus. Sie entsprechen den heutigen Helper-Prozessen, nur ohne Kommunikation, sind CPU-gebunden und sollen nicht mehr Arbeitsspeicher als bisher verbrauchen. Da sie zudem nicht mehr in Warteschleifen blockiert sind, können sie die gesammelten Rohdaten direkt berechnen. Durch die Trennung des Helper-Prozesses ermöglichen wir es Unternehmen, das Monitoring mit Checkmk weiter zu skalieren, indem unsere Software die vorhandenen Hardwareressourcen deutlich effizienter und performanter nutzt.

Neben der Skalierung haben wir auch am Workflow zur Aktivierung von Änderungen gearbeitet. Bisher hat Checkmk bei jeder Aktivierung die gesamte Konfiguration in einen Snapshot verpackt, diesen synchronisiert und auf den gewünschten Monitoring Sites wieder entpackt. Künftig beschleunigen wir diesen Prozess, indem Checkmk bei der Aktivierung von Änderungen eine inkrementelle Synchronisierung der Konfiguration vornimmt. Für den Nutzer ändert sich dadurch an der Oberfläche nichts. Unter der Haube synchronisiert Checkmk nur einen Bruchteil der bisherigen Daten, da es nur die gemachten Änderungen übermittelt.

Zum Abschluss gab Lars noch einen Einblick in den aktuellen Status der Python-3-Migration von Checkmk. Hier sind unsere Entwickler bereits auf einem guten Weg, um das nicht mehr supportete Python 2.7 abzulösen. Da Python 3 jedoch nicht abwärtskompatibel ist, müssen unsere Entwickler die mehr als 760.000 Zeilen Code in Checkmk von Python 2.7 auf Python 3 umprogrammieren. „Es ist also nicht mit der Änderung von fünf Zeilen Code getan“, scherzte Lars über den Arbeitsaufwand der Migration. Die Checkmk Base, die Check-Plugins sowie viele weitere Module haben die Checkmk-Entwickler jedoch bereits migriert. Zudem bauen wir alle neuen Special Agents bereits auf Python 3. Ältere Agenten gilt es jedoch noch zu migrieren. Bei der GUI haben unsere Entwickler ebenfalls die ersten Vorbereitungen abgeschlossen. Wir sind zuversichtlich, dass wir bis zu 2.0 die Migration komplett abgeschlossen haben.

Wie wir uns genau die Integration der Network Flow Analyse von ntop vorstellen, wollen wir euch bald in unserem nächsten Blog erklären.