1. Einleitung
Bislang speicherte Checkmk Metriken in Round Robin Databases (kurz RRDs), Informationen zu Ereignissen (events) in SQLite-Dateien und Inventardaten in JSON-Dateien. Allen gemeinsam ist, dass es sich um relativ simple, dateibasierte Formate handelt, deren Größe und Performance sehr gut vorhersehbar sind, und die für die Kernaufgaben genügend Flexibilität mitbringen.
Allerdings erfüllen gerade RRDs nicht mehr alle Anforderungen eines modernen Monitoring-Systems mit vielen dynamischen Objekten. So ist zwar die Abfrage einer Metrik über einen definierten Zeitraum leicht möglich, aber komplexere Abfragen wie beispielsweise die Identifikation von Zeitspannen, in denen mehrere Metriken Anomalien aufwiesen, erfordern es, große Datenmengen herauszuziehen und separat zu verarbeiten. Zudem war der in Checkmk 2.4.0 beschrittene Weg, OpenTelemetry-Daten auf "klassischem" Weg über einen Spezialagenten in Checkmk verfügbar zu machen, mit einem gewissen Overhead an Umwandlungs- und Kopiervorgängen behaftet.
Aus diesen Gründen fiel für Checkmk 2.5.0 die Entscheidung, zunächst für OpenTelemetry-Daten eine spaltenbasierte (column based) Datenbank als Metrik-Backend zu verwenden. Die Wahl fiel hier auf ClickHouse, da die Weitergabe vom OpenTelemetry Collector zur Datenbank sehr effizient vonstatten geht. Spaltenbasierte Datenbanken liefern eine sehr gute Performance wenn viele Werte einer Metrik ausgelesen werden sollen – ein typischer Anwendungsfall hierfür ist beispielsweise die Erzeugung von Graphen aus Metriken.
In Checkmk 2.5.0 kommt das Metrik-Backend nur für OpenTelemetry-Metriken zum Einsatz. Für künftige Versionen behalten wir uns vor, das Metrik-Backend auch für weitere Monitoring-Daten ergänzend zu RRDs zu nutzen. Wo RRDs ihren Zweck zufriedenstellend erfüllen, wird Checkmk diese auch in Zukunft verwenden.
2. Einrichtung
Beachten Sie, dass jegliche Verarbeitung von OpenTelemetry-Metriken ein aktiviertes Metrik-Backend voraussetzt. Lediglich die Weiterleitung von OpenTelemetry-Logs an die Event Console kommt ohne aus.
Die Aktivierung führen Sie in den globalen Einstellungen (Setup > General > Global settings > Site management > Metric backend) durch. Sofern nicht abweichend festgelegt, verwendet Checkmk drei scheinbar zufällige hohe Ports — für die Einlieferung von Daten durch den OpenTelemetry Collector, die Abfrage von Daten und eine Web-GUI als SQL-Konsole. Die verwendeten Ports werden dabei aus dem Namen der Instanz errechnet, sind also für gleich benannte Checkmk-Instanzen immer dieselben drei.
Auf die Web-GUI als SQL-Konsole können Sie verzichten. Allerdings kann diese bei Tests hilfreich sein, daher empfehlen wir, diese zumindest solange beizubehalten, bis Sie alle Tests abgeschlossen haben.
2.1. Verteiltes Monitoring
Derzeit sind keine Weiterleitungsmechanismen im verteilten Monitoring vorgesehen. Wenn Sie also OpenTelemetry-Metriken an OpenTelemetry Collectors und damit Metrik-Backends von Remote-Instanzen schicken, können diese Metriken nur dort als Insellösung eingesehen werden.
Für kommende Versionen von Checkmk evaluieren wir daher die Möglichkeit einer zentralen Instanz des Metrik-Backends und die Verwendung eines verteilten ClickHouse-Clusters. Details können Sie rechtzeitig der Roadmap-Dokumentation entnehmen.
In Checkmk 2.5.0 dürfte daher die Verwendung von OpenTelemetry Collector und Metrik-Backend alleine auf der Zentralinstanz der pragmatischste Ansatz sein. Sollte dieser Ansatz aus Gründen der Netzwerksegmentierung nicht sinnvoll sein, können Sie OpenTelemetry Collectors und Metrik-Backends als Insellösung auch auf Remote-Instanzen betreiben. Beachten Sie, dass in diesem Fall nur Daten, die den Weg über den Spezialagenten nehmen, im verteilten Monitoring genutzt werden können. Die Verwendung von benutzerdefinierten Graphen ist nur an deren Quelle möglich.
2.2. Fehlersuche
Ob Daten eingehen und diese mit erwarteten Metadaten gespeichert werden, können Sie in der SQL-Konsole von ClickHouse überprüfen.
Hier sind die Tabellen checkmk.metrics_samples_* meist diejenigen, in denen Sie stöbern werden wollen.
3. Berechnungsgrundlagen für die Lizenzierung
3.1. Custom Metrics
Eine Custom Metric entspricht der Zeitreihe von Daten, die über Service Name, Metric Name (in der Terminologie des Metrik-Backends, respektive des OpenTelemetry Collectors) sowie weitere Attribute identifiziert werden. Die aktuelle Zahl der Custom Metrics können Sie jederzeit über den Service OMD otel25 metric backend im Selbst-Monitoring Ihrer Checkmk-Instanz einsehen.
Die abrechnungsrelevante Anzahl der Custom Metrics wird alle 20 Minuten ermittelt. Nur Custom Metrics, die innerhalb dieses 20-Minuten-Intervalls Updates erhalten haben, fließen dabei in die Zählung ein. Einmal pro Tag wird ein Durchschnitt dieser Zahl über alle 20-Minuten-Intervalle der vergangenen 24 Stunden gebildet. Hiervon wird wiederum am Monatsende der Monatsdurchschnitt gebildet.
3.2. Frequenz eingehender Daten
Die Frequenz eingehender Daten wird bei Checkmk Ultimate derzeit nur durch Ihre Hardware, Einstellungen wie das Speicherlimit des Konnektors und die Netzwerkanbindung des Checkmk-Servers limitiert.
3.3. Vorhaltedauer
Die Vorhaltedauer von Telemetriedaten ist auf 14 Tage beschränkt. Dieser Wert ist derzeit in Checkmk nicht konfigurierbar. Wenn Änderungen an Konfigurationsdateien vorgenommen werden, behalten wir uns vor, keinen Support zu leisten.