Mit Checkmk 2.0 treiben wir auch die Automatisierung von Checkmk weiter voran und erleichtern zudem die Entwicklung von eigenen Plugins für das Monitoring mit Checkmk. So wird die neue Check-API es Anwendern künftig einfacher machen, eigene Plugins zu entwickeln und zu warten. Die ebenfalls neue REST-API soll zudem die Automatisierungsmöglichkeiten verbessern. Sie umfasst bereits große Teile der aktuellen Web-API, ermöglicht nun aber auch die Automatisierung von operativen Monitoring-Aufgaben, etwa das Setzen von geplanten Downtimes. Aber auch die Agent Bakery erhält mit der neuen Produktversion neue Funktionen dazu.

Neue Check-API vereinfacht die Entwicklung von eigenen Plugins

Künftig wird auch die Entwicklung von Checkplugins deutlich einfacher werden. Dies war notwendig, da die bestehende Plugin-API gewachsen und zudem nicht Top-down-designed ist. Dies hat immer wieder zu Problemen bei der Entwicklung geführt, da im Detail Inkonsistenzen entstanden sind und implizites Wissen benötigt wurde.

Daher haben wir beschlossen, von Grund auf eine neue Check-API zu entwickeln, zu der man in der Oberfläche von Checkmk die Referenz der aktuell verwendeten Version einsehen kann. Ein begleitender Handbuchartikel soll zudem den Einstieg in die Programmierung mit der neuen Check-API erleichtern.

Mit Checkmk 2.0 bestehen die Checkplugins aus Python-Modulen, der Import der Plugins ist zudem versioniert und genau durch die API definiert. Für den Anwender soll es somit einfacher sein, Plugins zu schreiben, separate Checks durchzuführen, Python-IDEs zu nutzen sowie den eigenen Code zu testen. Zudem bringt die neue API viele weitere kleinere Verbesserungen mit sich, darunter beispielsweise eine Cluster-Compatibility.

Durch den Wechsel von Python 2 auf Python 3 empfehlen wir, selbst programmierte Plugins vor der Migration auf die neue API zu überprüfen. Zwar sollte die Auto-Migration in den meisten Fällen problemlos funktionieren, jedoch kann es passieren, dass Sie Ihr Plugin möglicherweise anpassen müssen. Im Werk #10601 können Sie mögliche Gründe für ein Fehlschlagen der Auto-Migration nachlesen. In unserem Blog finden Sie zudem eine ausführliche Anleitung für die Migration von eigenen Plugins auf die neue Check-API.

Neue REST-API automatisiert die Konfiguration von Checkmk

Um das Monitoring mit Checkmk weiter zu automatisieren, haben wir außerdem eine neue REST-API entwickelt, welche die Konfiguration von Checkmk deutlich vereinfachen wird. Bei der Entwicklung der neuen REST-API haben wir uns bewährten Methoden bedient. So basiert die Schnittstelle auf HTTP/1.1 und JSON als Transportformat, ist mit der OpenAPI-3.x-Spezifikation formalisiert, basiert auf dem Level 3 des Richardson-Maturity-Modells und beinhaltet eine automatisierte Dokumentation.

Ferner bietet die neue REST-API bessere Funktionen als die bisherigen APIs, beispielsweise bei der Abfrage des Host- und Service-Status oder Durchführung von operativen Aufgaben, etwa eine Problemquittierung unter anderem für einzelne Services oder für alle Hosts einer Host-Gruppe. Auch das Erstellen von geplanten Downtimes lässt sich mit der neuen API problemlos umsetzen. Sie ermöglicht jetzt außerdem, die komplette Konfiguration und Abfrage der Business Intelligence von Checkmk.

Die REST-API bietet an vielen Stellen bereits deutlich mehr Funktionalität als die derzeitigen APIs. Jedoch bildet sie noch nicht die komplette Funktionalität der bisherigen Schnittstellen ab. Unser Ziel ist es jedoch, die derzeitigen Web-API durch die REST-API komplett abzulösen, sobald sie ihre komplette Funktionalität abbildet.

Im Handbuch gibt es weitere Details zur REST-API.

Upgrade für die Agent Bakery

Mit der Einführung von Checkmk 2.0 wird auch die Agent Bakery der Checkmk Enterprise Edition neue Funktionen erhalten. Das häufige Backen und Signieren von Agenten lässt sich ab der neuen Version in einem Schritt durchführen. Die Bakery weiß außerdem genauer, welche Pakete sie neu backen muss und kann so den Erstellungsprozess beschleunigen. Zudem unterstützt sie jetzt lokal angepasste Plugins und kann Änderungen an Daten zuverlässig erkennen. Neu ist außerdem, dass die Agent Bakery Pakete für neue Hosts automatisch bäckt – allerdings noch nicht signiert.

Wir haben zudem den Workflow der Bakery in verteilten oder in streng segmentierten Umgebungen optimiert. Nun ist die Bakery in der Lage, Agenten von Remote-Sites zu verteilen. Das bedeutet, dass die Agent-Updater nicht mehr alle mit der zentralen Site kommunizieren, sondern lediglich mit ihrer zuständigen Remote-Site, sodass sie Bandbreite einsparen. Die Konfiguration der gebackenen Agenten verbleibt jedoch auf der zentralen Site.

Ebenso haben wir neben der Check-API die Bakery-API weiterentwickelt, um das Bauen von Bakery-Plugins zu vereinfachen. Die Agent Bakery bietet nun Wahlfreiheit durch die Konfiguration der Verwendung von systemd oder xinetd für den Linux-Agenten. Sie kann somit je nach verwendeten Daemon besser auf das zu überwachende System eingehen und zudem erkennen, ob Python 2 oder Python 3 verfügbar ist.

Weitere Informationen rund um Checkmk 2.0

Lesen Sie auch die anderen Blogartikel zu den neuen Funktionen von Checkmk 2.0:

Weitere Informationen rund um Checkmk 2.0 finden Sie auch im Checkmk-Forum, im Checkmk-Handbuch auf unserem YouTube-Kanal.


Related Articles

Verteiltes Monitoring: Remote-Sites in Checkmk anbinden
Verteiltes Monitoring: Remote-Sites in Checkmk anbinden
Das verteilte Monitoring oder auch Distributed Monitoring mit Checkmk besteht aus einer zentralen Instanz bzw. Central Site und mindestens einer…
Checkmk in Kubernetes aufsetzen
Checkmk in Kubernetes aufsetzen
Das Aufsetzen von Checkmk in Kubernetes ist mit der inzwischen verfügbaren Checkmk-Container-Registry und den vordefinierten Manifesten für das…
Entwicklung von Checkmk 2.0: Die Entstehung der neuen UX
Entwicklung von Checkmk 2.0: Die Entstehung der neuen UX
Diesen März haben wir mit Checkmk 2.0 das größte Major Release in der Geschichte von tribe29 veröffentlicht. Noch nie haben wir in einer neuen Version…