Checkmk Conference #7 - Tag 2: Ein Blick auf Checkmk 2.1

Nachdem wir am ersten Tag der Checkmk Conference #7 über den aktuellen Status von Checkmk 2.0 gesprochen haben, stand am zweiten Konferenztag die Weiterentwicklung von Checkmk im Fokus. Traditionell haben die Teilnehmer während der Vorträge immer wieder die Möglichkeit, Einfluss auf die Entwicklung von Checkmk zu nehmen, indem sie über mögliche Änderungen, Funktionen, Erweiterungen etc. abstimmen.

Den Auftakt des Vortragprogramms des zweiten Tages machten Simon Meggle von Elabit und Jens Dunkelberg von der Abraxas Informatik AG, die in ihrer Tech Session über das End-to-End-Monitoring mit Checkmk mithilfe des Plugins Robotmk sprachen. Simon hat Robotmk als Brücke zwischen dem Robot Framework und Checkmk entwickelt. Auf diese Weise ist es möglich, die Ergebnisse von Robot Framework, ein Open-Source-basiertes Tool für automatisierte Tests von Applikationen, in Checkmk zu integrieren. Dadurch erweitert Robotmk das IT-Monitoring von Checkmk um ein End-to-End-Monitoring, also der Überwachung der User-Experience bei der Interaktion mit der IT-Infrastruktur.

Laut Simon ist Checkmk ideal, um die IT-Infrastruktur zu testen und damit zu gewährleisten, dass darauf laufenden Applikationen, etwa ein Web-Shop, auch funktionieren. Wie sich die Nutzung des Web-Shops jedoch für den Anwender gestaltet, lasse sich mit Checkmk nicht überwachen. Dies könne aber das Open-Source-Tool Robot Framework mit seinen automatisierten Tests. Durch die Integration von Robot Framework in Checkmk ist es laut Simon nun möglich, die Sicht des Anwenders auch in Checkmk zu überwachen.

Die Abraxas Informatik AG verwendet das Robotmk-Plugin bereits für das End-to-End-Monitoring von Applikationen in Schweizer Behörden. Jens berichtete den Teilnehmern, wie Robotmk in der Praxis funktioniert und welche Möglichkeiten es bietet.

In der Tech Session hat Simon aber auch einen Blick auf weitere Funktionalitäten des Plugins gegeben, etwa dem Extrahieren von Metriken, sodass Checkmk die Performance einer Applikation anzeigen kann. Da das Robot Framework nur ausgibt, ob ein Test erfolgreich oder fehlgeschlagen ist, aber nicht den Status und die Performance der Applikation, ist dies eine sinnvolle Erweiterung.

UX wird weiter optimiert

tribe29-Gründer Mathias Kettner stellte in der ersten Präsentation des Tages auf der Main Stage die geplanten Änderungen für die Benutzeroberfläche von Checkmk vor. Mit der Einführung von Version 2.0 hat Checkmk eine komplett neu überarbeitete Benutzeroberfläche und Navigation erhalten. Derzeit arbeitet das Entwicklerteam unter anderem an weiteren Verbesserungen der neuen UX.

Die mit Checkmk 2.0 eingeführten vier neuen Dashboard-Elemente sollen mit dem kommenden Feature Pack um vier weitere Dashlets erweitert werden. Sie sollen unter anderem anzeigen, ob der Host- oder Service-Status OK, WARN oder CRIT ist oder wie viele Hosts oder Services OK, WARN oder CRIT sind. Weiter geplant sind ein Event-Statistik-Hexagon sowie ein Inventory-Dashlet, das Informationen aus der Inventory anzeigt, beispielsweise die Anzahl der vorhandenen CPU-Cores.

Abstimmen konnten die Teilnehmer über ein Doughnut-Element als Alternative zur Tacho-Anzeige oder eine Zeitreihe als Säulendiagramm mit Drill-Down-Funktion. Mathias stellte außerdem mögliche Erweiterungen des Host-Hexagons, etwa zum Clustering, oder das Einbetten einer Karte im Dashboard vor.

Weitere Pläne bei der Weiterentwicklung der UX sind laut Mathias die Implementierung von applikationsspezifischen Dashboards, etwa für Linux- und Windows-Server oder vSphere-Umgebungen. Die Dashboards sollen Out-of-the-Box die wichtigsten Metriken beinhalten und so einen guten Überblick bieten.

Eine weitere mögliche Neuerung, die Mathias vorstellte, sind optionale Mini-Dashboards, die in der Host-View eingebettet sind. Sie sollen nützliche Zusatzinformationen zum jeweiligen Host liefern. Großen Anklang unter den Teilnehmern fand zudem die Idee, dass Checkmk-Nutzer selbst erstellte Dashboards als MKP-Datei über das Exchange teilen können. Positiv nahmen die Zuschauer auch die Überlegung auf, dass sich Dashboards über eine URL teilen lassen, etwa zur Anzeige auf einem Wallscreen.

Neben der Verbesserung des Dashboardings in Checkmk, soll jedoch auch die Nutzung von einzelnen Seiten in Checkmk besser werden. Dies beinhaltet zunächst eine klarere Strukturierung der am meisten genutzten Seiten sowie die Vereinfachung der dazugehörigen Workflows. Eine Option, die Mathias zeigte, sind zum Beispiel Popup-Fenster mit Aktionsvorschlägen.

Der Druck auf den Knopf Activate Changes erzeugt dann zum Beispiel ein Popup, das anzeigt, wo welche Änderungen gemacht werden. Ferner hat ein Popup den Vorteil, dass sich die Änderungen aktivieren lassen, ohne die aktuelle Seite verlassen zu müssen. Eine weitere Überlegung ist, dass Checkmk anschließend nächste Schritte vorschlägt, etwa den Wechsel zur Host-Ansicht. Eine weitere Möglichkeit zur Vereinfachung von Workflows wäre, dass Checkmk beim Hinzufügen eines Hosts nach der Eingabe der IP oder der DNS überprüft, welche Protokolle oder Agenten auf dem System laufen und anschließend eine Standardkonfiguration für den Host vorschlägt.

Ein weiteres Thema, auf das Mathias in seinem Vortrag einging, war die Überarbeitung der Ordnerstruktur. Mit einem neuen Ordner-Management soll vor allem die Übersicht in großen Umgebungen mit vielen Ordnern besser werden. Eine Überlegung ist etwa die Darstellung der Ordner in einer Tabellenansicht. Nach dem Klick auf einen Ordner lässt sich dann einsehen, welche Unterordner und/oder Hosts sich darin befinden und welche Attribute sowie Regeln für den Ordner gelten. Die Pläne zum neuen Ordner-Management fanden unter den Teilnehmern großen Anklang.

Monitoring aus der Cloud mit Checkmk

Ein weiteres großes Thema bei der Weiterentwicklung von Checkmk ist der Ausbau des bestehenden Hybrid-Cloud-Monitorings. In seinem Vortrag stellte Product Manager Thomas Lippert die vier Bereiche vor, die derzeit im Fokus stehen. Dies ist die Verbesserung der Cloud-nativen Erfahrung durch ein einfacheres Aufsetzen von Checkmk in der Cloud sowie eine einfachere Konfiguration, sodass sich On-Premises-Assets leichter von der Cloud aus überwachen lassen. Ferner arbeitet tribe29 an einer besseren Handhabung von dynamischen Workloads sowie den Ausbau der durch Checkmk überwachbaren Cloud-Services.

Künftig soll es möglich sein, Checkmk über den Marketplace von AWS und später auch direkt in Microsoft Azure zu beziehen. Das Checkmk-Image lasse sich so in wenigen Minuten als EC2-Instanz in der Cloud aufsetzen. Die Lizenzierung könne für AWS über Bring-your-own-Licence oder über die Plattformlizenzierung erfolgen. Die Monitoring-Instanz ist außerdem bereits für eine sichere Cloud-Nutzung vorkonfiguriert, betonte Thomas.

Nach der Konfiguration soll es mit Checkmk möglich sein, sowohl Cloud- als auch On-Premises-Assets aus der Cloud heraus zu überwachen. Dafür ist es jedoch notwendig, dass wir die Richtung ändern, in der der Agent die Daten überträgt, erklärte Thomas. Der hierfür entwickelte „Push-Agent“ soll die Monitoring-Daten einsammeln und anschließend an den Monitoring-Server übermitteln, um Firewall-Probleme zu vermeiden. Die Übertragung der Daten in die Cloud wird via TLS verschlüsselt. Außerdem komprimiert Checkmk die Daten, um die Kosten für den Datentransfer in der Cloud möglichst gering zu halten. Für mehr Datensparsamkeit soll zudem die Standard-Rate für den „Data Push“ reduziert werden.

Für On-Premises-Geräte auf denen keine Agenteninstallation möglich ist, etwa für SNMP-Devices, ist die Einführung eines lokalen SNMP-Proxys in der Netzwerkumgebung geplant. Dieser „Checkmk Light“-Proxy übernimmt die aktive Überwachung der SNMP-Komponenten, inklusive der Verarbeitung von SNMP-Traps. Anschließend übermittelt der SNMP-Proxy die aggregierten Ergebnisse in die Cloud.

Um dynamische Workloads in der Cloud zu überwachen, sollen diese sich selbst bei Checkmk registrieren können. Anschließend fügt Checkmk diese automatisch dem Monitoring hinzu. Basierend auf der Konfiguration, Labels und Anwendungsregeln weist Checkmk diese Hosts einem Ordner zu und wendet die auf die Ordner festgelegten Regeln an. Die Services des Hosts werden automatisch erkannt.

Darüber hinaus wird auch das Monitoring von Cloud-Services weiter ausgebaut. Für AWS sind dies möglicherweise AuroraDB, DocumentDB, SQS und Lambda. Ferner stimmten die Teilnehmer außerdem für die Option ab, AWS ECS, AWS Health oder AWS Route 52 mit Checkmk überwachen zu können.

Für Azure soll das Monitoring auf die Services Database for PostgreSQL/MySQL, CosmosDB, Service Bus und Load Balancer erweitert werden. Die Teilnehmer wünschten sich zudem ein Monitoring für die Dienste Service Health und Traffic Manager.

Integrationen, Automation und Security für die hybride IT-Welt

Der Alltag in Unternehmen mit großen IT-Infrastrukturen wird mittlerweile überwiegend von dynamischen und umfangreichen Workloads bestimmt. Um diese Anforderungen zu stemmen, sind sie zunehmend auf eine Automatisierung ihrer IT angewiesen. Dies wird jedoch häufig durch die breite Palette an genutzten Tools erschwert – sei es generell für das Monitoring, etwa mit Checkmk, oder spezieller Tools für Applikationen, Cluster oder Kubernetes. Gleichzeitig haben die medienwirksamen Sicherheitszwischenfälle das Bewusstsein für IT-Security und Produktsicherheit in den Unternehmen geschärft, wie Head of Development Lars Michelsen in seinem Vortrag „Integrations, Automation and Security“ erläuterte.

Dies sei der Grund, warum tribe29 bei der Weiterentwicklung von Checkmk weiterhin den Fokus auf die Integration von Observability-Tools und Enterprise-IT, auf die Automatisierung des Monitorings und auf die Produktsicherheit legen wird, wie Lars erläuterte.

Bei der Integration von anderen Tools gibt es laut Lars zwei Möglichkeiten: Das Exportieren von Monitoring-Daten in ein anderes Tool, wie es Checkmk beispielsweise bereits mit Grafana ermöglicht, oder die Integration von Daten anderer Tools in Checkmk, wie es mit der neuen Schnittstelle zu DataDog geplant ist. Bereits heute integriert Checkmk Daten von Tools wie ntop, Prometheus, Grafana oder InfluxDB. Für Checkmk 2.1 steht die Überarbeitung von bestehenden Integrationen, etwa für Grafana oder InflixDB, aber auch die Schaffung von neuen Schnittstellen auf der Roadmap.

Grafana: Die Grafana-Integration soll modernisiert und auf die neue Grafana-API angepasst werden. Außerdem soll das Data-Source-Plugin künftig im Grafana-Store verfügbar sein, um die Installation zu vereinfachen. Zu den neuen Funktionen gehört unter anderem die Authentifizierung durch den Grafana-Server, Annotations und eventuell die Übermittlung von Variablen.

InfluxDB: Geplant ist, dass es mit der neuen Checkmk-Version möglich ist, den Export von vertrauenswürdigen Metriken zu InfluxDB auszubauen. Derzeit nutzt Checkmk hierzu noch die alte auf UDP-basierte Carbon-Verbindung. Der Datenexport soll jedoch künftig auf die native API von InfluxDB umgestellt werden, um HTTP(S) für die Übertragung verwenden zu können. Dadurch ist es laut Lars auch möglich, zusätzliche Metadaten wie Schwellwerte, Status, Labels oder Tags zu übermitteln. Welche Metriken man an InfluxDB exportieren will, soll sich zudem über Regeln konfigurieren lassen. Auch sei es dann möglich, dieses Prinzip auf ähnliche Systeme wie Splunk oder Elastic auszuweiten.

DataDog: Die neu geschaffene Schnittstelle zu DataDog soll es Unternehmen, die neben Checkmk auch DataDog einsetzen, ermöglichen, Monitoring-Daten aus DataDog, etwa Status und Events, zu integrieren und diese anschließend ganz normal in Checkmk zu verwalten, um zum Beispiel Alarme und Benachrichtigungen zu erhalten. Auch hier soll es möglich sein, festzulegen, welche Daten Checkmk von DataDog integrieren soll, um so nur die relevanten Daten in Checkmk vorliegen zu haben.

Bezüglich der weiteren Automatisierung des Monitorings mit Checkmk arbeiten unsere Entwickler derzeit an dem Ziel, einen kompletten Deployment- und Konfigurations-Zirkel mit Checkmk abzubilden. So soll es möglich sein, ein Checkmk-Monitoring bis zu einem gewissen Grad automatisch aufzusetzen, die Feinabstimmung erfolgt anschließend weiterhin manuell. Für die Abläufe nach dem Aufsetzen der Instanz spielt laut Lars vor allem die mit Version 2.0 eingeführte neue REST-API eine große Rolle. Derzeit sind Rulesets noch nicht in der API abgebildet, dies soll aber ab Version 2.1 möglich sein. Zudem ist auch das automatische Anbinden von Remote-Sites geplant. Außerdem steht laut Lars das Hinzufügen einer Abstraktionsschicht auf der REST-API auf der Roadmap. Dadurch soll es einfacher werden, zusätzliche APIs auf die REST-API aufzusetzen, um beispielsweise API-Calls zum Ausführen von bestimmten Aktionen durchzuführen, etwa das Erstellen eines Hosts oder die Ausführung von bestimmten Funktionen.

Für mehr Sicherheit ist eine Verschlüsselung der durch die Agenten übertragenen Daten geplant. So soll der geplante Push Agent standardmäßig über eine TLS-Verschlüsselung verfügen. Die aktuell optionale symmetrische Verschlüsselung der Pull-Agenten wird ab 2.1 standardmäßig über TLS laufen. Laut Lars ist bei der Einführung von Sicherheitsfunktionen jedoch immer auch ein Spagat zwischen Sicherheit und Nutzbarkeit. Ziel sei es aber, trotz höherer Sicherheit den Aufwand und die Komplexität von Checkmk weiterhin einfach zu halten. Nutzer der Enterprise Edition sollen für das Deployment beispielsweise die Agentenbäckerei verwenden und nur ein zusätzliches Bakery Plugin konfigurieren müssen. Der manuelle Aufwand für Nutzer der Raw Edition wird jedoch durch die neuen Sicherheitsfunktionen leicht zunehmen.

Da viele Unternehmen zentrale Authentifizierungslösungen wie SSO oder 2FA im Einsatz haben, wollen wir diese auch für Checkmk verfügbar machen. Mit 2.0 ist Checkmk zum Beispiel bereits für die Verwendung von SAML vorbereitet, eine Anbindung von Azure AD könnte ein weiteres Beispiel für die Anbindung solcher zentralen Lösungen sein.

Kubernetes-Monitoring – Durchblick im Datendschungel

An einem Thema, das bereits auf den Konferenzen der letzten Jahre immer eine Rolle gespielt hat, kamen wir auch auf der diesjährigen Konferenz nicht vorbei: dem Kubernetes-Monitoring. Dies ist, wie Martin Hirschvogel in seinem Vortrag betonte, vor allem dem wachsenden Einsatz von Containern in Produktionsumgebungen geschuldet. Sie werden meistens via Kubernetes orchestriert. Diese Entwicklung führt dazu, dass gleichzeitig die Anforderungen an das Monitoring der IT-Infrastrukturen steigen. Schließlich gilt es neben den klassischen IT-Komponenten auch die wachsende Zahl an Containern, Cluster, Pods, etc. zu monitoren.

Seit 2018 ist es mit Checkmk möglich, Kubernetes über die Kubernetes-API zu überwachen. Dies hat den Vorteil, dass sich das Monitoring leicht aufsetzen lässt und man mit den über die API abrufbaren Daten und mit den über den Checkmk-Agenten bereitgestellten Informationen mit Checkmk bereits einen guten Einblick über die Gesundheit seiner Cluster bekommt. Mit der Prometheus-Integration kam zudem eine weitere Option für das Monitoring von Pods und Container hinzu. Vor allem Unternehmen, die bereits Prometheus für ihr Kubernetes-Monitoring verwenden, vermeiden auf diese Weise ein doppeltes Monitoring auf ihrem System. Beide Möglichkeiten werden von den Checkmk-Entwicklern weiter ausgebaut und optimiert.

Denn gerade die hohe Komplexität von Kubernetes führt laut Martin dazu, dass es für Administratoren schwierig ist, bei der Fülle an Daten zu wissen, was die für sie relevanten Informationen sind. Dadurch bestehe die Gefahr, dass der Daten-Overload den Nutzer schnell überfordert. Eine Stärke von Checkmk war und ist es jedoch, aus der Fülle an Daten, stets die wichtigen Informationen bereitzustellen.

Um das Kubernetes-Monitoring zu vereinfachen soll zunächst die Konfiguration und Installation von Checkmk einfacher werden. Dafür stellt tribe29 alle Checkmk-Editionen in der Docker-Registry zur Verfügung. Zudem sollen vordefinierte Manifeste und Helm Charts ein One-Click-Deployment und -Updating ermöglichen. Bereits jetzt sind die Checkmk Enterprise Edition und das Checkmk Trial in der Registry verfügbar.

Auch die Vorbereitung des Kubernetes-Clusters für das Monitoring soll einfacher werden. Dies soll zum einen mit einem neu entwickelten Agenten für Kubernetes sowie über ein Ausrollen via vordefinierten Manifesten und Helm Charts ermöglicht werden. Für eine einfache Konfiguration sind unter anderem Guided-Workflows inklusive eines vorkonfigurierten, dynamischen Setups mit Ordnern geplant. Auch eine robuste Namensgebung für alle Objekte sowie konsistente Labels für Filter, Visualisierung und Alarm stehen auf der Agenda.

Das Monitoring selbst soll letztendlich auch für Nicht-Kubernetes-Profis problemlos möglich sein. Der neue Kubernetes-Agent soll dem User eine sofortige Übersicht über die Gesundheit und die Performance seiner Cluster und deren Komponenten bieten. Ein Debugging von Problemen sei dann zum Beispiel über Drilldowns möglich. Vordefinierte Dashboards sollen dem Nutzer dabei helfen, verschiedene Aspekte und unterschiedlichen Anforderungen in der Kubernetes-Umgebung zu überwachen, etwa die Cluster-, Netzwerk- oder Application-Infrastruktur. Ferner soll jedes dieser vordefinierten Dashboards alle wichtigen Daten für den jeweiligen Anwendungsfall umfassen, sodass auch unerfahrene Nutzer sofort einen guten Überblick über den Zustand ihres Kubernetes-Monitoring erhalten.

Für das Kubernetes-Monitoring mit Checkmk soll künftig auf jedem Worker Node ein Pod mit dem K8s-Agenten vorhanden sein, der die Daten sammelt. Ein zusätzlicher Agent auf dem Cluster ist dafür zuständig, diese Daten zu strukturieren und anschließend als Gateway zum Checkmk-Server zu fungieren.

Die Roadmap für 2.1 und 2.2

Zum Abschluss des zweiten und letzten Tages der Konferenz haben Thomas und Lars noch einmal alle geplanten Änderungen zusammengefasst und erläutert, welche Funktionen es voraussichtlich in Checkmk 2.1 und 2.2. geben soll. Die neue Produktversion 2.1 ist derzeit für Ende 2021 geplant. Vorher soll es aber noch ein Feature Pack für die Version 2.0 geben.

Checkmk 2.1 soll unter anderem als Amazon Machine Image und möglicherweise auch als standardisiertes Image für Azure bereitgestellt werden. Auf diese Weise wollen wir das Monitoring von Cloud-Assets in der Cloud vereinfachen, wie Thomas erklärte. Bestandteil des Releases soll auch der neue Push Agent für Linux- und Windows-Plattformen sein. Ob mit Version 2.1 die Unterstützung für das Monitoring von dynamisch erstellen Workloads bereits möglich sein wird, ist noch nicht absehbar. Außerdem wird das Cloud-Monitoring mit dem nächsten Release auf weitere Services von Azure und AWS ausgebaut. Dabei werden wir auch das Feedback der Teilnehmer der diesjährigen Konferenz berücksichtigen, bekräftigte Thomas.

Für Checkmk 2.2 ist die Erweiterung des Push-Agenten auf weitere Plattformen geplant. Auch soll der On-Premises-Proxy, der zum Beispiel die SNMP-Daten in einer Umgebung einsammelt und in die Cloud übermittelt, dann Bestandteil von Checkmk sein.

Bezüglich des Kubernetes-Monitorings ist für Version 2.1 ein dedizierter Kubernetes-Agent geplant, der die Monitoring-Daten in der Kubernetes-Umgebung einsammelt und sinnvoll aggregiert. Ein Cluster-Dashboard soll zudem einen Überblick über alle wichtigen Metriken geben. Mit Version 2.1 wird Checkmk zunächst Vanilla Kubernetes unterstützen, in der Zukunft sollen aber weitere Distributionen wie EKS oder OpenShift dazukommen.

Für 2.2 sind weitere Standard-Dashboards geplant, etwa dediziert für das Deployment oder für einen Node. Zudem sei eine Überarbeitung der Prometheus-Integration vorgesehen, damit Prometheus die gleichen Daten wie der Kubernetes-Agent an Checkmk übermittelt. Auf diese Weise sollen Nutzer die freie Wahl bei der Datenquelle haben, am Ende jedoch das selbe Resultat erhalten. Weitere Themen auf der Roadmap sind zudem ein Event-Monitoring sowie ein automatisches Setup des Kubernetes-Monitorings.

Für das Dashboarding sollen mit Version 2.1 neue Visualisierungsmöglichkeiten zur Verfügung stehen, etwa Host- und Service-Status, Inventory-Daten etc. Zudem sind applikationsspezifische Dashboards für Linux, Windows und vSphere und die Verbesserung der Funktionalität von kontextsensitiven Dashboards geplant.

Prinzipiell soll mit Checkmk 2.1 auch die Benutzeroberfläche weiter verbessert werden. Das heißt, dass die am häufigsten benutzten Seiten übersichtlicher und verständlicher werden sollen. Gleichzeitig wollen wir die Workflows überarbeiten, etwa für das Aktivieren von Änderungen.

Die bereits erwähnten Änderungen an den Integrationen sind ebenfalls bereits für Version 2.1 vorgesehen. Dies beinhaltet die neue DataDog-Schnittstelle für den Import von Daten in Checkmk, die Überarbeitung der Grafana-Integration, die auf die neue API angepasst wird, sowie die native InfluxDB-Integration.

Darüber hinaus wollen wir Checkmk in mehr Sprachen anbieten. Aktuell gibt es bereits erste Sprachpakete im Exchange. Die erste Übersetzungsversion ist maschinenunterstützt. Für die finale Version sind wir aber auch auf die Zusammenarbeit mit der Community angewiesen.

Im zweiten Teil des Roadmap-Vortrags ging Lars auf Ideen und mögliche Richtungen der langfristigen Checkmk-Entwicklung ein. Hier hatten die Teilnehmer ebenfalls die Möglichkeit, über ihre bevorzugte Richtung abzustimmen. Die vier Hauptthemen hierbei war die Erweiterung des Monitorings von Applikationen, das Log-Management, Erkennung von Abhängigkeiten und Korrelationen sowie das E2E-Monitoring mit Robotmk.

Die Videos der einzelnen Vorträge von der Checkmk Conference #7 finden Sie auf unserem YouTube-Kanal. Die Präsentationen stellen wir für Sie auf unserem Konferenz-Archiv bereit.