Checkmk 2.0 wurde vor kurzem veröffentlicht und enthält bereits viele der auf dieser Seite genannten Verbesserungen.
Die Roadmap wird in den nächsten Wochen aktualisiert.
In Arbeit
Wir haben Checkmk in den vergangenen Jahren um zahlreiche nützliche Funktionen erweitert. Dadurch ist die Monitoring-Lösung gleichzeitig komplexer geworden. Dieses Jahr haben wir daher ein UX-Projekt mit dem Ziel gestartet, die einfache und intuitive Navigation in Checkmk zu verbessern.
Unser Ziel ist es, die Flexibilität von Checkmk beizubehalten, aber die Lernkurve für neue und "gelegentliche" Nutzer zu beschleuningen.
Wir arbeiten daher an:
- Neue Navigation
- Sidebar
- Seitenspezifische Kontext-Schaltflächen
- Breadcrumb Navigation
- Leistungsstarke Suchfunktion
- Klarheit
- Vereinfachte Seiten/Formulare
- Klare Namensgebung
- Frisches Design und Symbole
- Allgemeine vs. erweiterte Benutzereinstellungen
Unser Ziel ist es, für alle Editionen ein einheitliches Look-and-feel zu gewährleisten. Das bedeutet, dass die HTML5-Graphen der Enterprise Edition die bisher in der Raw Edition für Visualisierung verwendeten PNP4Nagios ersetzen werden – allerdings nicht mit dem vollen Funktionsumfang.
So sind beispielsweise einzelne oder kombinierte Graphen weiterhin nur in der Enterprise Edition von Checkmk verfügbar.
Die technische Umstellung ermöglicht darüber hinaus eine Grafana-Integration in der Raw Edition.
Wir erstellen außerdem neue Formen der Visualisierung (Elemente) und arbeiten daran, die Erstellung von Dashboards zu vereinfachen. Diese sollen künftig auch kontextensitiv sein und die Darstellung von speziellen Fakten ermöglichen, etwa alle Informationen für Host X.
Bei den neuen Elementen handelt es sich unter anderem um einzelne Metriken, Säulen- und Streudiagramme.
Ihr Monitoring hostet ein Meer an wertvollen Daten. Das Verständnis von historischen Leistungsdaten ist der Schlüssel für die Prognose künftiger Trends. Daher implementieren wir eine Funktion zur Analyse dieser historischen Daten in Checkmk.
Eine separate Funktion für erweiterte Vorhersagen und für ein Kapazitäts-Management wird ebenfalls direkt in Checkmk verfügbar sein. Sie soll helfen, Probleme frühzeitig zu erkennen und den Kapazitätsbedarf vorauszusehen. Diese Funktion soll sich auch in Berichte einbetten lassen.
Netzwerk-Monitoring ist schon immer eine Kernkompetenz von Checkmk, wobei der Schwerpunkt auf der Überwachung der Netzwerkleistung, verschiedener Metriken, Port-Zuständen und Alarmierungen liegt. Wir verfügen bereits über eine breite Palette an Plugins für die Netzwerküberwachung.
Mit einer Partnerschaft mit ntop, einem führenden Anbieter für die Network-Flow-Analyse, bauen wir unser Angebot nun weiter aus.
Wir sind dabei, eine tiefe Integration zwischen ntop und Checkmk aufzubauen. Sie soll eine tiefere Ursachenanalyse und Analyse des Network Flows und eine tiefgehende Leistungsüberwachung ermöglichen. Zudem soll sie bei der Erkennung von Bedrohungen untersützen.
Wir bauen eine integrierte Sichtweise für DevOps- und InfraOps-Teams auf, sodass sie gemeinsam Probleme schneller verhindern und beheben können.
Wir entwickeln eine Integration der Top-Exporter von Prometheus für das Monitoring von Kubernetes und unterstützen die Ausführung und Überwachung von kundenspezifischen PromQL-Abfragen direkt von Checkmk aus.
Wir verbessern die bestehende Integration mit Grafana, die die Enterprise Editionen von Checkmk ab Version 1.6 unterstützen.
Darüber hinaus wollen wir die Grafana-Integration auch für die Checkmk Raw Edition verfügbar machen.
Wir arbeiten aktuell an neuen Checkmkplugins und verbessern bestehende Checkmkplugins für viele Systeme und Anwendungen.
Applikations-Monitoring:
Graylog, Elasticsearch, RabbitMQ, Redis, MongoDB, MySQL, Couchbase, Oracle, Jira, Jenkins, JMX, Apache, SAP, Zerto, Kapersky und mehr...
Infrastruktur-Monitoring:
Huawei, tp-link, PulseSecure, BeyondTrust, Cisco, Arista, Aruba, Entersekt, Dell EMC ECS, ScaleIO, HPE, NetApp, Fujitsu, QNAP, Ceph, Nutanix, Proxmox, VMware und mehr...
Um unser breites Angebot an bestehenden Alarmierungsoptionen zu vervollständigen, bauen wir aktuell noch Integrationen für Cisco WebEx Teams.
Die Skalierbarkeit weiter voranzutreiben ist unser Leitgedanke hinter den aktuellen Leistungsverbesserungen, an denen wir arbeiten.
Zur Zeit übernehmen sogenannte Helper-Prozesse sowohl die Berechnung der Prüfergebnisse als auch die Erfassung der rohen Überwachungsdaten. Der RAM-intensive Helper-Prozess der Prüfung muss dabei oft auf Netzwerk-I/Os warten, was die Skalierbarkeit der Helfer begrenzt.
Um die Abhängigkeit von Netzwerk-I/Os zu reduzieren, haben wir den Helper-PRozess zweigeteilt. Fetcher-Prozesse sollen künftig die rohen Überwachungsdaten einsammeln. Ein Checker-Prozess wertet anschließend die gesammelten Daten aus. Durch die Teilung des Helper-Prozesses wollen wir es Unternehmen ermöglichen, die Überwachung mit Checkmk weiter zu skalieren, indem sie mit unserer Software ihre vorhandenen Hardware-Ressourcen wesentlich effizienter und mit verbesserter Leistung nutzen können.
Neben der Skalierung haben wir auch den Workflow um die Aktivierung von Änderungen (Active Changes) überarbeitet. Bisher hat Checkmk bei jeder Aktivierung die gesamte Konfiguration in einen Snapshot verpackt, synchronisiert und an den gewünschten Überwachungsstandorten wieder ausgepackt.
In Zukunft wollen wir diesen Prozess beschleunigen, indem Checkmk die Konfiguration bei der Aktivierung von Änderungen inkrementell synchronisiert.
Für den Anwender ändert sich an der Oberfläche nichts – "unter der der Haube" synchronisiert Checkmk nur einen Bruchteil der bisherigen Daten, da es künftig nur die tatsächlich vorgenommenen Änderungen überträgt.
Wir entwickeln eine neue REST-API, um alle derzeit in Checkmk verfügbaren Funktionen abzudecken – sei es über die GUI oder die Kommandozeile. Wir verfolgen dabei das Ziel, die neue API für den Anwender so einfach wie möglich zu gestalten.
Das bedeutet, dass auch weniger erfahrene Benutzer ihre Werte aus der API abrufen können, etwa durch leicht verständliche Fehlermeldungen, eine vollständige Dokumentation der API und einer API, deren Verhalten leicht zu verstehen ist.
Die neue Schnittstelle wird JSON untersützen. Wir verwenden auch die aktuelle OpenAPI-Spezifikationen OpenAPI 3.0 (OAS 3.0) zur Beschreibung unserer API. Die API basiert ebenfalls auf HTTP/1.1 und wird das dritte Level des Richardson-Maturity-Modells erfüllen.
Mit der Einführung mehrerer APIs wollen wir außerdem die Entwicklung weiter standardisieren und vereinfachen:
- Check-API
- Inventory-API
- Bakery-API
Insbesondere die Entwicklung von Checkmkplugins wollen wir dadurch vereinfachen. Und zwar nicht nur für uns, sondern auch für Anwender, die eigene Integrationen erstellen.
Der Agenten-Updater der zentralen Monitoring-Site musste für die Aktualisierung von Agenten bisher immer direkt mit jedem Agenten kommunizieren können.
In segmentierten Netzwerken ist dies möglicherweise nicht realisierbar. In großen Umgebungen führt dies zudem zu einer unnötigen Belastung des Netzwerks.
Verteilte Agenten-Aktualisierungen ermöglichen künftig einen Roll-out von Agenten-Updates von entfernten Standorten aus. Gleichzeitig ermöglichen wir dadurch den Einsatz in segmentierten Netzwerken und helfen dabei, Bandbreite einzusparen.
Die beliebte Labels- und Tags-Funktion wird erweitert. Labels werden nicht nur aus Kubernetes- und Cloud-Umgebungen importiert, sondern auch direkt von Checkmk erkannt und gesetzt.
Über die Labels lassen sich beispielsweise Ansichten für bestimmte Host-Typen, Betriebssystemfamilien und bestimmte Versionen oder benutzerdefinierte Labels filtern.
Es wird außerdem möglich sein, Benachrichtigungsbedingungen auf der Grundlage dieser Lables zu definieren.
Wir planen SAML für Single Sign-On zu unterstützen.
Geplant
Mit Checkmk 2.0 haben wir bereits wesentliche Oberflächenkonzepte in Checkmk neu gestaltet. Wir planen, die Konsistenz weiter zu verbessern und wollen intuitive Benutzeroberflächen über das gesamte Produkt hinweg gewährleisten.
In diesem Zusammenhang planen wir die Verbesserung folgender Arbeitsabläufe:
- Aktivieren von Änderungen,
- Service-Discovery,
- Verwaltung von Hosts und Ordnern
- und vieles mehr ..
Eine gute Benutzererfahrung basiert auf einer schnellen Benutzeroberfläche. Daher planen wir, die Ladezeiten für ausgewählte Statusansichten und Regelkonfigurationsseiten zu optimieren.
Die Erstellung von Dashboards soll so einfach und intuitiv wie möglich sein. Wir planen, unsere derzeitigen Bemühungen auch in Zukunft fortzusetzen, um die Nutzbarkeit des Dashboardings zu verbessern, zum Beispiel:
- Einfaches Umschalten zwischen Visualisierungsoptionen "on-the-fly" ermöglichen.
- Hinzufügen einer Vorschauoption beim Erstellen von Dashlets.
Um die Erstellung von nützlichen und einfach zu verstehenden Dashboards zu unterstützen, werden wir weitere Visualisierungsoptionen hinzufügen, etwa:
- Karten, Heatmaps, Waben-Karten etc.
- Alternative Optionen für Zeitserien-Metriken
Wir planen auch vorgefertigte Dashboards für spezifische Anwendungen wie beispielsweise Kubernetes, AWS, Azure, Linux, Windows, vSphere oder Oracle.
Wir planen die Verbesserung unserer Grafana-Integrationen. Geplant ist beispielsweise:
- Das Bereitstellen eines Standard-Checkmk-Dashboards, inklusive Tactical Overview,
- die Ermöglichung dynamischer Dashboards durch Unterstützung von Variablen,
- das Exportieren von Annotationen (Kommentare, Ausfallzeiten etc.) und
- das Exportieren von in Checkmk erstellten Ansichten nach Grafana.
Wir planen außerdem, unsere bestehende Integration mit InfluxDB zu verberssern, um einen besseren Export von Metrikdaten zu ermöglichen.
- Ersetzen des Exports über Graphite durch eine direkte InfluxDB-Verbindung, um mehr Exportfunktionen zu ermöglichen.
- Der Export von zusätzlichen Informationen, beispielsweise Labels.
Wir haben vor, die Leistung bei der Aktivierung von Änderungen für sehr große Konfigurationen und bei einer großen Anzahl an Konfigurationsbenutzern zu erhöhen.
Dazu ziehen wir mehrere Konzepte in Betracht, etwa die Aktivierung von Änderungen für einzelne Ordner statt für die gesamte Konfiguration.
Dies wird auch die Fähigkeit von Checkmk zur Überwachung dynamischer Infrastrukturen verbessern und die Automatisierung von Checkmk weiter vorantreiben.
Das Kubernetes-Monitoring mit Checkmk soll so einfach wie möglich sein. Wir planen daher, das Setup zu automatisieren, indem wir:
- Die Installation automatisieren (YAML-Konfigurationen, Helm-Charts, Docker-Registry).
- Die ersten Schritte des Monitorings automatisieren, also die Service-Discovery oder das Aktivieren von Änderungen.
Wir planen, den Start des Kubernetes-Monitoring zu vereinfachen, indem wir:
- Die Nutzbarkeit des Kubernetes-Monitoring verbessern, etwa mit optimierten Standardeinstellungen, Schwellwerten und Kontextinformationen, und
- vorgefertigte und dynamische Kubernetes-Dashboards für verschiedene Benutzergruppen bereitstellen, etwa Cluster-Administratoren.
Außerdem wollen wir unseren Ansatz anpassen, um sicherzustellen, dass Checkmk immer die neuesten Versionen von Kubernetes unterstützt.
Checkmk lässt sich bereits in der Cloud betreiben und bietet ein Monitoring der meisten Cloud-Dienste.
Wir planen, dies noch weiter auszubauen und eine Cloud-native Bereitstellung von Checkmk zu ermöglichen, indem wir die Installation von Checkmk direkt über den AWS- oder Azure-Marktplatz ermöglichen.
Um die Benutzerfreundlichkeit des Checkmk-Agenten in der Cloud und in dynamischen Umgebungen zu verbessern, planen wir, Agenten zu erlauben, sich selbst am Monitoring-Server zu registrieren. Außerdem wollen wir einen Standard für das Pushen von Agentendaten an den Checkmk-Server einführen.
Ähnlich wie bei AWS und Azure wollen wir auch für die Google Cloud einen Spezialagenten bereitstellen, der:
- für eine dynamische Konfiguration vorbereitet ist und
- Checks für Standard-Dienste umfasst, etwa:
- Cloud-Storage,
- Compute Engine,
- Cloud-SQL und
- Cloud-Load-Balancing.
Zusätzliche Checks sind auf Basis von Feature-Anfragen möglich.
Wir wollen außerdem das Monitoring für AWS als auch für Azure erweitern, insbesondere im Bereich Datenbanken.
Wir planen zudem, die Netzwerküberwachung für Cloud-Dienste zu erweitern, da Netzwerke in der Cloud immer wichtiger wird.
"Blackbox"-Dienste erhöhen die Bedeutung des Testens aus Anwendersicht: Synthetic-Monitoring (aka E2E). Wir planen, mit Checkmk eine Standardlösung für ein Synthetic-Monitoring bereitzustellen. Dies wollen wir entweder durch die Integration einer anderen Lösung oder durch die Bereitstellung der benötigten Anleitungen realisieren.
Redfish hat sich als neuer Standard für das Management von Servern etabliert. Wir planen daher die Bereistellung eines Special Agents und Check-Plugins für ein herstellerunabhängiges Server-Monitoring.
Wir planen unser Windows-Monitoring durch die Verbesserung von existierenden Check-Plugins aber auch durch die Bereitstellung von neuen Plugins zu verbessern, etwa für Biz Talk, Sharepoint, MS Exchange, DHCP, Active Directory oder File-Server.
Dadurch reduzieren wir die Notwendigkeit, für ein tiefgreifendes Windows-Monitoring auf andere Systeme zu wechseln.
2FA ist eine gute Methode für Anmeldeverfahren. Es gibt mehrere Möglichkeiten, wie sich eine 2FA durchführen lässt, etwa hardwarebasiert mit Yubikey oder softwarebasiert mit Google Authenticator.
Wir planen derzeit, der GUI eine optionale 2FA hinzuzufügen, die U2F mit einem lokalen Checkmk-Validierungs-Server unterstützt.
Wir ziehen außerdem in Erwägung, die Verbindung zu anderen Validierungs-Servern zu ermöglichen.
Mit der Einführung der REST-API in Checkmk 2.0 haben wir den Funktionsumfang der bestehenden API zum Teil erweitert. Unser Ziel ist es jetzt, die neue REST-API zu vervollständigen, sodass sich alles über eine API ausführen lässt.
Mit Checkmk 2.0 haben wir bereits mehrere Plugin-APIs eingeführt, etwa die Check-API, Bakery-API oder DCD-API.
Ein weiteres Ziel von uns ist es, das Angebot an Plugin-APIs weiter auszubauen, indem wir etwa GUI-Erweiterungen über eine Plugin-API ermöglichen.
In Erwägung
Die Business-Intelligence-Funktion von Checkmk ist eine leistungsstarke Möglichkeit, Geschäftsprozesse zu überwachen, indem sie Ihr Monitoring auf einer höheren Ebene aggregiert.
Die aktuelle Methode, dies über Regeln zu realisieren, ermöglicht es, diese Aggregationen problemlos über Ihr gesamtes Monitoring hinweg zu konfigurieren.
Ein weiterer möglicher Ansatz, den wir erwägen, wäre die Erstellung von Aggregationen per Drag & Drop.
Wir planen zudem, das Layout von Standardbenachrichtigungen und Berichten zu verbessern.
Ermittlung von Abhängigkeiten (Dependencies) anhand von Informationen aus physischen und virtuellen Netzwerken und Anwendungskonfigurationen, etwa vSphere, Oracle oder Kubernetes, und Visualisierung dieser Abhängigkeiten.
Dies soll dabei helfen:
- Probleme schneller zu lösen,
- Probleme im Vorfeld zu verhindern und
- unnötige Alarmierungen zu reduzieren.
Wir ziehen eine automatische Korrelation von Metriken in Erwägung, um Systeme zu finden, die ein ähnliches atypisches Verhalten aufweisen, und leistungsstarke Visualisierungen erzeugen, die Anomalien auf intelligente Weise hervorheben und große Datenmengen heranziehen, um Ursachen schneller zu finden.
Verteiltes Tracing über Micro-Services, Hosts und Container hinweg durch die Integration der wichtigsten APM-Tools, etwa Jaeger.
Wir erwägen die Unterstützung von OpenMetrics, ein Cloud-natives und extrem skalierbares Protokoll für Applikationen zur Offenlegung ihrer Daten.
Wir denken außerdem über die Erweiterung des JMX-Monitorings nach, um eine tiefgreifende Überwachung von Java-Application-Servern zu ermöglichen.
Aufbauend auf dem starken Fundament, die wichtigsten Prometheus-Exporters integrieren zu können und PromQL-Abfragen nativ in Checkmk auszuführen, denken wir darüber nach, diese Integration weiter zu verbessern. Geplant sind zum Beispiel:
- Die Integration von weiteren Prometheus-Exportern sowie
- eine direkte Verbindung zu Prometheus-Exportern.
Wir erwägen, unserer Monitoring-Kapazitäten um Tools zu erweitern, die im Kubernetes-Ökosystem üblich sind.
- Verbesserung der Überwachung für in Kubernetes typische Schnittstellen und Toolchains, etwa CSI, CNI, nginx, Cassandra oder Kafka.
- Tiefere Integration in das Kubernetes-Ökosystem mit beispielsweise Istio.
Mögliche Punkte sind:
- Erweiterte Visualisierung von Netzwerktopologien und Erkennung von Netzwerktopologien über ntop, LLDP und mehr.
- Verbessertes Monitoring für virtuelle Netzwerke in Virtualisierungsplattformen.
- Verbesserte Überwachung von Netzwerkhardware, einschließlich Support-Infos von Herstellern (zum Beispiel PSIRT-Advisories) und Unterstützung von Monitoring-APIs für Netzwerkgeräte, etwa Streaming-Telemetry.
