Checkmk Conference #6: The Road to 2.0 and beyond

Der letzte Vortrag auf der Checkmk Konferenz #6 gehörte auch dieses Jahr wieder Lars Michelsen, der als unser Chefentwickler den Teilnehmern einen Überblick über die bisherige Umsetzung der auf der Konferenz vorgestellten Neuerungen in Checkmk gab und unsere Roadmap bis Checkmk 2.0 und darüber hinaus darlegte.

Für Checkmk 2.0, das wir in einer stabilen Version im Herbst releasen wollen, liegen wir nach Meinung unseres Chefentwicklers gut im Zeitplan – auch wenn wir gerade jetzt nach der Konferenz noch viel zu tun haben, wie er anmerkte. Vor allem beim Thema neuer User Experience (UX), das Projekt, das Mathias Kettner in seinem Vortrag vorgestellt hat, müssen wir die erarbeiteten Konzepte noch intern ausprobieren und testen, damit diese noch in die Version 2.0 einfließen können, erzählte Lars.

Weiter sind wir bereits bei der Prometheus-Integration, die bereits im veröffentlichten Feature Pack 2 für die Version 1.6 enthalten ist. Hier freuen wir uns über euer Feedback, etwa wie die Integration von Prometheus in Checkmk geklappt hat und welche Einsatzszenarien ihr damit abbildet. Denn nur mit eurem Feedback können wir Checkmk weiterhin an euren Bedürfnissen weiterentwickeln, betonte Lars.

Bei der ntop-Integration ist zwar der Großteil der Implementierung erledigt, jedoch müssen wir das Styling noch besser in das Checkmk-Look-and-Feel integrieren, wie Lars erklärte. Auch das Alerting ist derzeit noch nicht in Gänze fertig.

Bezüglich der Automatisierbarkeit und Erweiterbarkeit von Checkmk zog Lars in seinem Vortrag ebenfalls ein positives Fazit. So müssen wir für die die Check-API und die verwandten Programmier-APIs, etwa Inventory-API, Bakery-API etc., lediglich noch einige Details für die Implementierung klären. Daher rechnet er damit, dass die grundsätzlichen Arbeiten an der API in den nächsten Wochen abgeschlossen sind und wir mit der Migration der Plugins beginnen können.

Bei der REST-API sind wir hingegen noch nicht so weit. Hier haben wir zwar den technologischen Grundstock gewählt und einige wichtige API-Calls umgesetzt, allerdings müssen wir noch einige API-Calls einbauen, damit wir bis zur 2.0 bereits ein sinnvolles Feature-Set anbieten können. Unser Ziel ist es, die meisten Use Cases der bestehenden Web-API mit der neuen REST-API abbilden zu können

Tiefgreifende Änderungen müssen sorgfältig umgesetzt werden

Bei der Performance nehmen wir laut Lars zum Teil fundamentale Änderungen an Kernkomponenten vor. So handelt es sich beispielsweise beim Umbau der Helper-Prozesse um einen gravierenden Eingriff in die Helper-Architektur, die dementsprechend sorgfältig ausgeführt sein muss. Aktuell sind wir noch dabei, viel umzubauen und zu testen, wie Lars berichtete. Er rechnet aber damit, dass wir bald mit der Anbindung an den Micro Core beginnen und im Mai oder Juni abwägen können, ob die Neuerungen die erwartete Leistungssteigerung auch gewährleisten.

Auch beim Thema Activate Changes haben wir die Vorarbeiten fast abgeschlossen, sodass wir in Bälde eine inkrementelle Synchronisation der Konfiguration im Distributed Monitoring einbauen können.

Bereits Vollzug hat Lars bezüglich der für die Version 2.0 geplanten neuen Checks vermelden können. Hier haben wir bereits alle für die neue Version geplanten Checks implementiert. In den kommenden Wochen bis zur Veröffentlichung von Checkmk 2.0 können jedoch noch verschiedene Checks, die durch Kundenaufträge entstehen, hinzukommen.

Die Rückkehr des Innovation Release

Neben den inhaltlichen Themen ging Lars auch auf die Änderungen in unserem Release-Zyklus ein, den neuen Feature Packs. Damit wollen wir nützliche Funktionen, die wir bereits fertiggestellt haben, für alle Checkmk-Nutzer in einer stabilen Version verfügbar machen. Die Features liefern wir als MKPs aus, die in Checkmk standardmäßig deaktiviert sind. In der Enterprise Edition lassen sich die gewünschten Funktionen über die WATO aktivieren oder deaktivieren. Anwender der Raw Edition aktivieren die Features über die CLI.

Darüber hinaus sprach Lars auch über unsere Innovation Releases. Diese haben wir in der Vergangenheit genutzt, um große Features noch während der Entwicklung für unsere Nutzer testbar zu machen. Wie Lars weiter erklärte, sind diese Innovation Releases für uns ein gutes Hilfsmittel, um bereits vor der Beta-Phase ein Feedback der Checkmk-User zu bekommen und ihnen gleichzeitig eine Preview auf kommende Funktionen zu geben. Für die Version 2.0 haben wir ein Innovation Release fest eingeplant.

Bereits jetzt haben wir zwei Feature Packs für Checkmk 1.6 vorgestellt. Ob wir noch ein Drittes releasen, ist derzeit jedoch noch unklar. „Je nachdem was sich inhaltlich an Funktionen anbieten, kann es auch noch ein drittes Feature Pack für die Version 1.6 im Sommer geben“, sagte Lars. Fest steht jedoch, dass wir im frühen Sommer mit den Innovation Releases für Checkmk 2.0 anfangen wollen. Dies bedeutet für uns, dass wir zu diesem Zeitpunkt bereits einen Großteil der Funktionen umgesetzt, aber noch keinen Feature Freeze durchgeführt haben. Das ermöglicht es uns, in dieser Phase bei Bedarf noch Funktionen hinzuzufügen.

Der Feature Freeze für Version 2.0 ist dann für den Spätsommer geplant, um anschließend intensiv in das Testing gehen zu können. Da wir mit der Python-3-Migration, der Einführung des neuen UX-Designs sowie der neuen REST-API, der neuen Check-API und der Helper-Umstellung am Micro Core zahlreiche großflächige Änderungen an Checkmk vornehmen, wollen wir das Testing mit der 2.0 deutlich ausgeprägter gestalten als bei vergangenen Versionen, um die gewohnte Qualität sicherzustellen, betonte Lars.

Hierzu benötigen wir jedoch auch euch, die Community. Lars erneuerte an dieser Stelle die Bitte an die Teilnehmer und Checkmk-Nutzer, von den Testmöglichkeiten Gebrauch zu machen und uns ihr Feedback zukommen zu lassen. Wann wir mit den verschiedenen Testphasen starten, werden wir euch dann über unsere verschiedenen Kanäle mitteilen.

Checkmk 2.1

Im Rahmen des Vortrags hat Lars auch einen Ausblick darauf gegeben, was wir bereits für die Version 2.1 für Ideen und Pläne haben. Ein wichtiges Thema ist auch nach 2.0 weiterhin die Verbesserung der User Experience. Zwar erhält diese mit der Version 2.0 ein Redesign der wichtigsten Workflows und Elemente in Checkmk, der nächste Schritt wird es laut Lars jedoch sein, die Detail-Dialoge und -Ansichten für die Nutzer konsistenter und intuitiver zu gestalten. Ebenso wollen wir das bereits mit der 2.0 angefangene Optimieren des Dashboardings und Reportings weiter fortsetzen.

Ein weiterer Punkt ist der Ausbau des Monitorings von Cloud-Umgebungen. Hier haben wir zuletzt die Anbindungen für Azure und AWS bereitgestellt. Künftig soll die Anbindung der Google Cloud Platform (GCP) hinzukommen. Sie soll – wie wir es bereits bei Azure und AWS handhaben – über einen Special Agent erfolgen und das Monitoring der wichtigsten Dienste zu ermöglichen. Auch bezüglich Azure und AWS wollen wir basierend auf den Bedürfnissen der Community unser bisheriges Portfolio ausbauen.

Außerdem werden wir die Integration mit Prometheus vertiefen. Mit Checkmk 2.0 sind wir bereits in der Lage, die wichtigsten Exporter zu integrieren. Künftig wollen wir – basierend auf Feature-Anfragen – die Anzahl der Exporter sukzessive ausbauen und darüber hinaus Prometheus Exporter auch direkt an Checkmk anbinden können ohne den Umweg über Prometheus gehen zu müssen.

2.000 Plugins und Zwei-Faktor-Authentifizierung

Ein wichtiges Ziel für 2.1 ist es für uns, die mit 2.0 eingeführte REST-API zu komplettieren, sodass sich alle Funktionalitäten in Checkmk darüber abbilden lassen. Ferner wollen wir auch die begonnen Performance-Verbesserungen vorantreiben. Lars ging in seinem Vortrag außerdem auf die Entwicklung von neuen Plugins ein. Hier ist es unser Ziel, die Wünsche von Kunden und aus der Community weiter umzusetzen.

Bezüglich dem Thema Sicherheit rund um Checkmk gibt es laut Lars Überlegungen, eine Zwei-Faktor-Authentifizierung einzuführen, um den Login zusätzlich abzusichern. Dies kann zum Beispiel so aussehen, dass wir eine optionale Zwei-Faktor-Authentifizierung auf der GUI einbauen, die den U2F-Standard unterstützt. Wir überlegen zudem, ob Checkmk selber einen lokalen Validation-Server bereitstellen soll, auf dem der jeweilige Token für die 2FA registriert ist. Im nächsten Schritt kann dann die Anbindung von unternehmensweiten Validation-Servern eine Möglichkeit sein.

Überwachen von modernen Hypervisoren und E2E-Monitoring

In seinem Vortrag hat Lars auch den Bogen zu größeren Themen gespannt, die wir für die Zukunft ebenfalls auf dem Schirm haben. Dies ist zum Beispiel das Monitoring von modernen Hypervisoren. So wächst die Containerisierungswelt mit der Virtualisierungswelt immer weiter zusammen, wie Lars am Beispiel von VMware vSphere 7 festmacht. Er geht davon aus, dass die anderen gängigen Hypervisoren dieser Entwicklung folgen werden. Mit Checkmk ist zwar das Monitoring von Containerumgebungen sowie von VMware sehr gut möglich, jedoch wollen wir auch die „zusammengewachsenen“ Umgebungen weiterhin optimal überwachen und nützliche Aussagen zu den Zuständen und Zusammenhängen treffen können.

Beim Thema Cloud ist Checkmk bisher in der Lage, die Dinge zu überwachen, die unsere Anwender in der Cloud betreiben. Darüber hinaus wollen wir uns jedoch auch überlegen, wie wir Checkmk selbst in Zukunft besser in der Cloud bereitstellen wollen, etwa in einem Container, in einer VM etc. Eine Überlegung, die Lars skizzierte, ist beispielsweise die Bereitstellung von Standard-Images auf den großen Cloud-Plattformen wie GCP, AWS und Azure, sodass der Nutzer per Knopfdruck eine Checkmk-Instanz auf der Plattform hochfahren kann.

Darüber hinaus ging Lars auf das Thema End-to-End-Monitoring ein, dem wir uns in Zukunft stärker widmen wollen. Angelehnt an das ntop-Modell nannte Lars hier die Möglichkeit, dass wir dafür eine vernünftige Integration bereitstellen, etwa durch Handbuchartikel, How-to-Tutorials oder eine Softwareintegration. Ziel ist es, euch ein End-To-End Monitoring mit Checkmk im Herzen zu ermöglichen.

Mehr Intelligenz und Automatisierung in Checkmk

Außerdem hat Lars einiges zu „Automated Dependencies“ erzählt. So soll das Zusammenführen von Informationen dabei helfen, Abhängigkeiten in der IT aufzuzeigen, um dem Nutzer beispielsweise bei der schnelleren Problemlösung zu helfen.

Derzeit stellen wir uns das Thema als ein Puzzle aus vielen Informationsquellen über Zusammenhänge von Services, Systemen oder einzelnen Anwendungen vor, wie Lars erklärte. Diese Informationen wollen wir in Zukunft zusammenbringen und ein Modell darauf aufbauen, das diese Dependencies sowie ihre Folgen für das Gesamtsystem darstellen kann. Aufgrund dieses Modells mit allen einbezogenen Informationen zu den Abhängigkeiten soll Checkmk anschließend dem Nutzer dabei helfen, die Komplexität der IT leichter zu verstehen und Probleme schneller zu lösen. Kaskadierende Probleme lassen sich somit frühzeitig identifizieren und lösen, bevor sie zum Problem werden. Des Weiteren kann man damit unnötige Alarme vermeiden. Das bekannte Konzept von „Service Dependencies“ aus Nagios wollen wir dabei aber wesentlich weiter denken, da sich insbesondere durch Netzwerkinformationen viele Abhängigkeiten besser erkennen lassen.

Ergänzend dazu wollen wir am Thema „Analytics“ in Checkmk weiterarbeiten. So soll Checkmk einerseits Anomalien automatisch erkennen und dem Nutzer darstellen. Andererseits soll Checkmk bei einer Anomalie eines Services automatisch andere Services mit einem ähnlichen Verhalten anzeigen. Da so eine Korrelation natürlich nicht unbedingt einen kausalen Zusammenhang ergeben muss, macht die Verbindung mit „Dependencies“ solch eine Analytik erst wirklich mächtig. Deshalb sehen wir die beiden Themen „Analytics“ und „Dependencies“ in einem engen Zusammenhang und als komplementär zueinander. Beide Tools zusammen erlauben dem Nutzer bisher ungekannte Einblicke in den Datenschatz des Monitorings und helfen dabei die Ursache von Problemen schneller zu finden.

Weg vom klassischem SNMP-Ansatz?

Ferner sprach Lars über die Bewegung im Netzwerk-Monitoring, vom klassischen SNMP-Ansatz wegzugehen. Bei Checkmk sieht dieser Ansatz so aus, dass es regelmäßige Abfragen (Pollings) an die Geräte stellt, um den aktuellen Zustand zu erfahren. Dies hat den Vorteil, einen definierten Zustand zu einem bestimmten Abfragezeitpunkt zu erhalten. Der Nachteil dabei ist jedoch, dass man durch die Pollings eine kontinuierliche Last auf den Systemen hat. Auch ist unklar, was zwischen den Abfragen auf dem System passiert. Letzteres lässt sich immerhin durch SNMP-Traps lösen, die ereignisbasiert Informationen an das Monitoring-System senden.

Derzeit forcieren einige Hardwarehersteller auf ihren Plattformen die sogenannte Streaming Telemetry. Sie umfasst verschiedene Protokolle und APIs mit dem Ziel, die Vorteile von Polling und einem eventbasierten Monitoring zu vereinen. Ein weiterer Vorteil von Streaming Telemetry ist es, dass die Protokolle die Daten auf moderne Weise aufbereiten, sodass diese in einem sprachneutralen Format vorliegen. Dadurch könnte es beispielsweise für Checkmk möglich sein, schneller an Informationen zu gelangen und so performanter zu werden. Laut Lars werden wir uns auch weiterhin mit solchen Themen befassen, die die Arbeit von und mit Checkmk weiter vereinfachen und verbessern.

In der Summe, so Lars, haben wir damit auch im nächsten Jahr viele Themen auf der Agenda stehen, die wir gemeinsam mit euch angehen wollen. Während des Vortrags habt ihr beispielsweise schon regen Gebrauch davon gemacht, über die Punkte, die Lars angesprochen hat, abzustimmen. Wie immer werden wir die Ergebnisse in die Weiterentwicklung einfließen lassen. Schließlich haben wir noch viel mit Checkmk vor. Ihr könnt gespannt sein!