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.
Wir planen auch Dashboards, die auf bestimmte Anwendungen zugeschnitten sind – zusätzlich zu Checkmk selbst für vSphere, Linux oder Windows.
Bei den neuen Elementen handelt es sich unter anderem um einzelne Metriken, Säulen- und Streudiagramme.
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.
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.
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 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
- Microsoft Teams
Geplant
Der erste Schritt unseres UX-Redesigns besteht darin, die am häufigsten verwendeten Workflows neu zu gestalten und die gesamte Navigation zu überarbeiten.
Wir planen, die Konsistenz zu verbessern und intuitive Benutzeroberflächen über das gesamte Produkte hinweg sicherzustellen.
Die Erstellung von Dashboards soll so einfach und intutiv wie möglich sein.
Wir planen unsere, unsere derzeitigen Bemühungen auch in Zukunft fortzusetzen, um die Nutzbarkeit des Dashboardings zu verbessern.
Wir planen auch vorgefertigte Dashbaords für spezifische Anwendungen.
Wir wollen die Aktivierung von Änderungen (Activate Changes) in sehr großen Konfigurationen mit einer großen Anzal an konfigurierten Nutzern beschleunigen.
Wir ziehen dazu verschiedene Konzepte in Betracht, etwa die Aktivierung von Änderungen für einzelne Ordnern anstatt für die gesamte Konfiguration.
Wir wollen außerdem die standardmäßigen Alarmierungs- und die Report-Layouts verbessern.
Mit der Möglichkeit, die wichtigsten Prometheus-Exporter integrieren und PromQL-Abfragen nativ in Checkmk ausführen zu können, haben wir ein starkes Fundament gelegt. Das wollen wir mit weiteren Integrationen verbessern.
Das wollen wir durch die Einbindung von weiteren Prometheus-Exportern sowie einer direkten Verbindung zu Prometheus-Exportern ermöglichen.
Mit dem Aufbau des Technologie-Stacks und den Bereitstellung der ersten Funktionen ist unser nächstes Ziel, die neue REST-API zu vervollständigen. Alles soll dann über eine API ausführbar sein.
Wir planen zudem einen Special Agent, ähnlich wie es ihn bereits für AWS und Azure gibt:
- Ready-built für eine dynamische Konfiguration
- Checks für Standard-Services
- Cloud-Speicher
- Compute Engine
- Cloud-SQL
- Cloud Load Balancing
Zusätzliche Checks sind auf Grundlage von Feature-Wünschen möglich.
Wir wollen darüber hinaus unser Montitoring für AWS als auch für Microsoft Azure ausbauen.
Neben der Verbesserung des Prozesses zur Aktivierung von Änderungen (Activate Changes) denken wir auch über Verbesserungen für Systeme mit einer großen Benutzeranzahl nach.
Zudem wollen wir die Leistung unserer Netzwerk-Scans für sehr große Netzwerkumgebungen verbessern.
2FA ist eine gute Praxis für Anmeldeverfahren. Es gibt mehrere Möglichkeiten, wie man eine 2FA ausführen kann:
- Hardware (etwa Yubikey)
- Software (etwa Google-Authentifikator)
Wir planen derzeit dem GUI, das U2F unterstützt, mit einem lokalen Validierungs-Server von Checkmk eine optionale 2FA hinzuzufügen.
Wir erwägen zudem, die Verbindung zu anderen Validierungs-Servern zu ermöglichen.
Wir planen, SAML für Single Sign-On zu unterstützen.
Der Alarmierungs-Spooler leitet optional Alarmierungen von entfernten an zentrale Standorte zur Zustellung weiter. Wir denken darüber nach, für diesen Kommunikationskanal eine Ende-zu-Ende-Verschlüsselung zu implementieren.
Wir erwägen, die Integrationen um das Windows-Ökosystem herum zu erweitertn, etwa um ein Office365-Monitoring.
Wir denken darüber nach, die JMX-Überwachung zu erweitern. Auf diese Weise wollen wir eine tiefgehende Überwachung von Java-Application-Servern ermöglichen.
Wir wollen außerdem unser Kubernetes-Monitoring weiter ausbauen, insbesondere um Aspekte der Benutzerfreundlichkeit mit vorgefertigten Dashboards.
Wir planen, DataDog als Datenquelle für Checkmk zu integrieren.
Kubernetes wird der Schlüssel dazu sein, VMware vSphere 7 deutlich dynamischer zu machen und die Welten von DevOps und Ops einander näher zu bringen.
Software-Anbieter werden ihre Software verstärkt in Containern ausliefern, die Ops implementieren und überwachen muss.
Dies verändert die Funktionsweise moderner Hypervisoren. Wir wollen dafür sorgen, dass unsere vSphere-Integration weiterhin branchenführend ist.
In Erwägung
Wir denken über die Vereinfachung des Deployments von Checkmk in der Cloud mit Standard-Images sowie neuen Mechanismen für einen stärkeren Cloud-nativen Überwachungsansatz nach, etwa Push-Mechanisman für Agenten, Selbstregistrierung.
Verteiltes Tracing über Mikro-Services, Hosts und Container durch Integration der wichtigsten APM-Werkzreuge, etwa Jaeger.
Durch die Integration der wichtigsten Tools für Synthetic-Monitoring erwägen wir, tiefe Einblicke in die End-to-End-Performance von Anwendungen zu ermöglichen, unabhängig davon, wo die Anwendungen ausgeführt werden.
Zu unseren Überlegungen zum Netzwerk-Monitoring zählen:
- Erweiterte Visualisierung von Netzwerktopologien und die Entdeckung von Netzwerktopologien über ntop, LLDP und mehr.
- Verbessertes Monitoring von virtuellen Netzwerken in Virtualisierungsplattformen.
- Verbesserte Überwachung von Netzwerk-Hardware, einschließlich Support-Informationen von Herstellern, etwa PSIRT-Ratgeber), und Unterstützung für Überwachungs-APIs für Netzwerkgeräte, etwa Streaming-Telemetrie.
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 und/oder zu verhindern sowie unnötige Alarmierungen zu reduzieren.
Unter Checkmk Analytics verstehen wir die automatische Korrelation von Metriken, um Systeme zu finden, die ein ähnliches atypisches Verhalten zeigen. Ferner sollen sie leistungsstarke Visualisierungen bieten, die Anomalien auf intelligente Weise hervorheben und große Datenmengen nutzen, um die Ursachen schneller zu finden.
Die Business-Intelligence-Funktion von Checkmk ist eine leistungsstarke Möglichkeit zur Überwachung von Geschäftsprozessen, indem sie deren Monitoring auf einer höheren Ebene aggregiert.
Die derzeitige Methode, dies über Regeln zu tun, ermöglicht eine einfache Konfiguration dieser Aggregation über eine gesamte Monitoring-Umgebung hinweg.
Ein weiterer Ansatz, den wir in Erwägung ziehen, wäre die Erstellung von Aggregationen per Drag & Drop.