In Arbeit
Checkmk lässt sich bereits in der Cloud bereitstellen und erlaubt zudem ein Monitoring für die meisten Cloud-Services.
Wir planen, noch einen Schritt weiter zu gehen und die Cloud-native Bereitstellung von Checkmk zu ermöglichen, indem wir die Installation von Checkmk direkt über den AWS-Marktplatz einrichten.
Um die Benutzerfreundlichkeit des Checkmk-Agenten in der Cloud und in dynamischen Umgebungen zu verbessern, planen wir, dass sich Agenten selbst beim Monitoring-Server registrieren können. Außerdem werden wir einen Standard für die Übertragung der Agentendaten an den Checkmk-Server einführen.
Alle vom Linux- und Windows-Agenten gesendeten Daten sollen verschlüsselt und komprimiert werden, um den Datenschutz zu wahren und Bandbreitenkosten über öffentliche Netzwerke möglichst gering zu halten.
Wir arbeiten an einem neuen Check für AWS Lambda Serverless Computing.
Komplett überarbeitetes Kubernetes-Monitoring für die Überwachung von Clustern und sämtlichen Nodes. Darüber hinaus ist das verbesserte Kubernetes-Monitoring einfach einzurichten und zu konfigurieren.
Das neue Dashlet-Element zeigt die Event-Statistiken in einer Hexagon-Ansicht an.
Das neue Dashlet-Element zeigt die Host- und Service-Status an und bietet zahlreiche individuelle Anpassungsmöglichkeiten.
Wir wollen die neue Checkmk-2.0-Benutzeroberfläche im Hinblick auf Konsistenz und optimale Benutzerfreundlichkeit weiter vereinfachen.
Wir arbeiten an der Vereinfachung des Workflows für die Service Discovery sowie an der Verbesserung der entsprechenden Ansicht für eine übersichtlichere Darstellung der Informationen.
Geplant ist ein umfangreiches Dashboard für alle Metriken eines Linux-Servers.
Der durch die Agent Bakery erstellte Windows-Agent soll signiert werden, um ein besseres Ausrollen in hochsicheren Windows-Umgebungen zu ermöglichen.
Mit der Einführung der REST-API in Zuge von Checkmk 2.0 haben wir im Vergleich zu den bestehenden APIs den Funktionsumfang erweitert. Unser Ziel ist jedoch die Vollständigkeit der neuen REST-API: Alles soll künftig über eine API gemacht werden.
Signifikante Verbesserungen für den MS-SQL-Check sind geplant.
Wir haben signifikante Verbesserungen für den Check für SAP HANA geplant.
Wir haben signifikante Verbesserungen für den Check MS Internet Information Service geplant.
Der AIX-Agent wird für eine deutlich bessere Leistung optimiert.
Wir arbeiten an signifikanten Verbesserungen des Checks für Cisco ASA.
Wir arbeiten an einem nativen Export von Messdaten zu InfluxDB.
Wir wollen die bestehende Grafana-Integration verbessern, die wir ursprünglich mit Checkmk 1.6 ausgeliefert haben.
Außerdem wird die Grafana-Integration in Zukunft Grafana 8 unterstützen.
Wir arbeiten an einer Integration von Datadog.
Geplant
Für das Monitoring von AWS sind neue Checks geplant für:
- AWS Elastic Container Service (ECS)
- AWS Health für die Region des Kunden
- AWS Route 53
- AWS ElasticCache for Redis
Für das Monitoring von Microsoft Azure sind neue Checks geplant für:
- Azure Health für die Region des Kunden
- Azure Load Balancer
- Azure Database MySQL und PostgreSQL
- Azure Traffic Manager
Wir planen ein Kubernetes-spezifisches Applikations-Dashboard.
Das neue Dashlet-Element zeigt Informationen aus der Inventory an, etwa die Anzahl der CPU-Kerne oder den Arbeitsspeicher, etc.
Vereinfachung der Art und Weise, wie Ansichten und Dashboards ihre Parameter erhalten.
Vereinfachung des Workflows zum Aktivieren von Änderungen (Activate Changes), vor allem für kleine Änderungen, etwa lokal in einem Ordner.
Wir planen ein umfangreiches Dashboard für die Darstellung aller Metriken eines Windows-Servers.
Wir planen ein umfangreiches Dashboard für die Darstellung aller Metriken eines vSphere-Clusters.
Wir wollen die Performance für das Übernehmen von Änderungen in sehr großen Konfigurationen oder mit einer großen Anzahl an Konfigurationsnutzern verbessern.
Dazu ziehen wir verschiedene Konzepte in Betracht, etwa das Aktivieren von Änderungen in einzelnen Ordnern statt für die gesamte Konfiguration.
Wir planen für Single Sign-On die Unterstützung von SAML.
Wir planen zudem einen neuen Check für die Access Points von Meraki.
In Erwägung
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, mit dem Metriken für Applikationen offengelegt werden können.
Wir planen für das Monitoring der Google Cloud Platform, einen Spezialagenten ähnlich wie die Agenten für AWS und Azure zu entwickeln:
- Ausgelegt für dynamische Konfiguration
- Checks für Standard-Services, wie:
- Cloud-Speicher
- Compute-Engine
- Cloud-SQL
- Cloud Load Balancing
Zusätzliche Checks sind auf der Grundlage von Feature Requests möglich.
Wir denken über die Erweiterung des JMX-Monitorings nach, um eine tiefgreifende Überwachung von Java-Application-Servern zu ermöglichen.
"Blackbox"-Services erhöhen die Bedeutung von Tests aus der Nutzerperspektive: Das sogenannte Synthetic-Monitoring (auch bekannt als E2E-Monitoring).
Wir planen, eine Standardlösung für ein Synthetic-Monitoring mit Checkmk bereitzustellen: Entweder durch die Integration mit einer anderen Lösung oder durch die Bereitstellung von passenden Anleitungen.
Redfish hat sich als Standard für das Server-Management etabliert. Wir planen, einen Spezialagenten und ein Checkplugin für ein herstellerunabhängiges Server-Monitoring zu entwickeln.
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.
