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.
Wir arbeiten an einem neuen Check für AWS Lambda Serverless Computing.
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.
Wir arbeiten an signifikanten Verbesserungen des Checks für Cisco ASA.
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
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 vSphere-Clusters.
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.