1. Einleitung
In 
Checkmk Ultimate
können Sie OpenTelemetry-Metriken empfangen und im Monitoring verarbeiten.
Hierfür bringt Checkmk einen OpenTelemetry Collector mit.
Dieser unterstützt den Empfang von OTLP-Daten über die Transportprotokolle GRPC und HTTP(S) (Push-Konfiguration).
Zudem kann er als Scraper Daten von Prometheus-Endpunkten einsammeln (Pull-Konfiguration).
Die Unterstützung der Datentypen (Signals) von OpenTelemetry ist wie folgt:
Metriken unterstützt Checkmk sehr umfangreich, diese können flexibel bestehenden Objekten im Monitoring zugeordnet werden oder eigene Objekte erzeugen.
Logs werden teilweise unterstützt – sie können an die Event Console weitergeleitet und dort verarbeitet werden.
Traces werden derzeit von Checkmk nicht unterstützt.
 |
Dieser Artikel beschreibt den Stand der OpenTelemetry-Integration bei Veröffentlichung von Checkmk 2.5.0b4. Wir arbeiten weiterhin daran, danach vorgenommene Änderungen einzupflegen. Bitte beachten Sie die OpenTelemetry betreffenden Werks, um den aktuellen Stand der von Ihnen verwendeten Checkmk-Version zu erfahren. |
2. Einrichtung
Bevor Sie den OpenTelemetry Collector aktivieren, sollten Sie eine oder beide der folgenden Komponenten bereits aktiviert haben, um Fehler zu vermeiden:
Das Metrik-Backend, wenn Sie OpenTelemetry Metriken im Monitoring abbilden wollen
Die Event Console mit Syslog-Empfänger, wenn Sie OpenTelemetry Logs verarbeiten wollen
Die Aktivierung nehmen Sie für beide in den globalen Einstellungen (Global settings) vor. In beiden Fällen genügen die Grundeinstellungen für den Erstgebrauch.
2.1. OpenTelemetry Collector aktivieren
Für die Verarbeitung der OpenTelemetry-Daten müssen Sie in den globalen Einstellungen (Global settings > Telemetry) den Kollektor aktivieren. Ebenfalls in den globalen Einstellungen können Sie das Memory Limit für den Kollektor festlegen. So stellen Sie sicher, dass zu große Mengen eingehender Daten nur den OpenTelemetry Collector, aber nicht Ihr gesamtes Checkmk-System überlasten.
Nach dem Speichern der Einstellungen wird der Kollektor automatisch gestartet.
2.2. OpenTelemetry Collector (passiv) einrichten
Die Einrichtung des Kollektors nehmen Sie unter Setup > Telemetry > OpenTelemetry Collector vor, wenn der Kollektor sich passiv verhalten und Daten empfangen soll. Mit dem Knopf Add OpenTelemetry Collector configuration starten Sie die Einrichtung eines Kollektors. In den General properties vergeben Sie den Namen des Kollektors.
In den Eigenschaften des Kollektors müssen Sie mindestens einen der beiden Push-Endpunkte (über GRPC oder HTTP) einrichten. Dort definieren Sie dann verwendete IP-Adressen und Ports. Zusätzlich legen Sie fest, ob Authentifizierung und Verschlüsselung aktiviert werden. Beachten Sie: Wenn Sie Basic authentication aktivieren, muss TLS-Verschlüsselung aktiviert sein, da sonst Benutzername und Passwort unverschlüsselt übertragen werden und leicht abzuschnorcheln sind.
|
In vielen Fällen werden OpenTelemetry-Daten sendende Applikationen die Kommunikation mit TLS verschlüsselten Kollektoren verweigern, wenn das verwendete Zertifikat nicht den Host-Namen enthält, über den die Sender zu kommunizieren versuchen. In den Global settings haben Sie die Möglichkeit, mit Site certificate subject alternative names alle Host-Namen zu setzen, für welche das Serverzertifikat gültig sein soll. |
Logs zur Event Console schicken
OpenTelemetry bietet auch Möglichkeiten, Log-Meldungen zu übertragen. Der Kollektor kann diese im Syslog-Format an beliebige Anwendungen weitergeben, die Syslog-Meldungen entgegennehmen können. Das ermöglicht in Checkmk die Verarbeitung von OpenTelemetry-Logs durch die Event Console. Diese Funktion können Sie mit der Checkbox Send log messages to event console aktivieren.
Unbedingt erforderlich ist ein Resource attribute for host name lookup.
Im einfachsten Fall ist dies service.name, also der Name des OpenTelemetry Services, der in vielen Fällen gut auf Checkmk-Hosts abgebildet werden kann.
Mit Save sichern Sie den Kollektor.
2.3. Prometheus Scraper (aktiv) einrichten
Soll sich der Kollektor aktiv verhalten – also Prometheus-Endpunkte abfragen –, verwenden Sie Setup > Telemetry > Prometheus scraper. Mit dem Knopf Add Prometheus scraper configuration starten Sie die Einrichtung eines neuen Scrapers.
Der hier vergebene Job name wird vom OpenTelemetry Collector zum Attribut service.name umgewandelt.
In vielen Fällen wollen Sie diesen später zu einem Host-Namen zuordnen.
Die weiteren Parameter geben den Zugriff auf den Scraping-Endpunkt an:
Zum Beispiel führt ein unter http://198.51.100.252:9100/metrics erreichbarer Endpunkt zur Einstellung von IP address or host name auf 198.51.100.252, Port auf 9100 und Metrics path auf /metrics.
Beim unverschlüsselten HTTP ist das Häkchen bei Encrypt communication with TLS leer zu lassen.
3. Testdaten an den Kollektor senden
Vermutlich werden Sie den OpenTelemetry Collector für Checkmk deshalb aufsetzen wollen, weil in Ihrer IT-Umgebung schon irgendwo irgendetwas irgendwelche OpenTelemetry-Metriken erzeugt. Falls dies (noch) nicht der Fall ist, oder Sie einfach die Einrichtung auf einem Testsystem ausprobieren wollen, stellen wir in diesem Kapitel zwei schnell eingerichtete Beispielapplikationen vor. Mit dem bis hier erreichten Einrichtungsstand landen die empfangenen Daten im Metrik-Backend – wo Sie sich beispielsweise in der SQL-Konsole davon überzeugen können, dass Daten ankommen. In den weiteren Schritten können Sie die Daten direkt im Monitoring nutzen.
Die allereinfachste Beispielanwendung stellen wir in unserem GitHub-Repository als „Hello metric“ bereit. Sie wird in einer virtuellen Python-Umgebung ausgeführt und erzeugt einen OpenTelemetry-Service mit einer OpenTelemetry-Metrik. Hinweise zu benötigten Python-Modulen und dem Start finden Sie mit im Repository.
Ganz ähnlich wie „Hello metric“ funktioniert auch die auf der OpenTelemetry-Website vorgestellte Beispielapplikation „Dice Roll“.
Diese Beispielapplikation ist in vielen Aspekten praxisnäher als „Hello metric“.
So verschickt „Dice Roll“ bei jedem Aufruf des Applikationsservers (und nur dann!) OpenTelemetry-Metriken und führt den Datentyp „Counter“ ein.
Sie können die für das „Hello metric“-Beispiel erzeugte virtuelle Python-Umgebung nutzen, um auch das „Dice Roll“-Beispiel auszuprobieren.
Allerdings müssen Sie dazu zusätzlich noch das Python-Modul flask installieren (pip install flask) und die Datei app.py in der um Metriken erweiterten Variante erstellen, wie es in dieser Anleitung beschrieben ist.
Im folgenden Aufruf ersetzen Sie dann den Checkmk-Server als Ziel (hier 198.51.100.42 mit GRPC-Port 4317):
Ihr Flask-Server ist jetzt bereit und kann unter dem gewählten Port (hier: 8080) erreicht werden, um pro Aufruf einen Würfelwurf auszuführen.
Sie sehen die Würfeldaten zum Beispiel als Ausgabe von curl -v http://localhost:8080/rolldice.
Jeder Würfelwurf, den Sie so auslösen, wird als ein Datenpunkt an Checkmk übertragen.
4. OpenTelemetry-Daten im Monitoring
Es gibt drei wesentliche Möglichkeiten, die eingehenden Daten im Monitoring zu nutzen. Dieses Kapitel stellt diese drei Möglichkeiten vor. Der Umfang der erzeugten Services und sichtbaren Metriken, aber auch die Flexibilität und die Systemlast unterscheiden sich bei allen Methoden. Aus diesem Grund ist es wichtig, sich bei jedem Anwendungsfall für die passende Monitoring-Methode zu entscheiden.
Die benutzerdefinierten Graphen (custom graphs) visualisieren Daten auf direktem Weg aus dem Metrik-Backend in Dashboards – ohne Umweg über Services und sogar ohne Beteiligung des Monitoring-Kerns. Aus benutzerdefinierten Graphen können Sie direkt Regeln für den im folgenden Punkt vorgestellten Spezialagenten erstellen.
Ein Spezialagent für ausgewählte Metriken ist dann sinnvoll, wenn Sie einige per OpenTelemetry empfangene Datenpunkte vorhandenen oder extra angelegten Hosts zuordnen wollen und eine Möglichkeit suchen, Daten aus unterschiedlichen Quellen den Hosts zuzuordnen, zu denen sie organisatorisch oder technisch gehören. Der Overhead dieser Methode ist etwas höher, was meist dadurch wett gemacht wird, dass ein geringerer Umfang an Daten abgefragt wird.
Der Weg über die dynamische Host-Verwaltung ist ideal, wenn die exakte Abbildung von OpenTelemetry-Services auf Checkmk-Hosts und von OpenTelemetry-Metriken auf Checkmk-Services möglich ist. Da ein spezieller Fetcher zum Einsatz kommt und Daten daher einen sehr direkten Weg nehmen, ist dieser Ansatz sehr effizient.
4.1. Benutzerdefinierte Graphen erstellen
Unter Customize > Custom graphs haben Sie die Möglichkeit, einen benutzerdefinierten Graphen zu erstellen. Die Erstellung unterscheidet sich an einigen Stellen etwas von Graphen, die aus in RRDs hinterlegten Metriken erstellt werden. Näheres zeigt der Artikel zu Messwerten und Graphing.
Wenn Sie die im Graphen dargestellten OpenTelemetry-Datenpunkte über die verfügbaren Filter nach Attributen hinreichend eingeschränkt haben, können Sie über das Export-Symbol die erstellten Filter als Filter für einen Spezialagenten exportieren, den wir im folgenden Abschnitt vorstellen.
Die zwei auffälligsten Unterschiede zwischen benutzerdefinierten Graphen, die aus RRDs und solchen, die aus dem Metrik-Backend erstellt werden, sind:
Die Auflösung: bei RRDs wird in der Regel nach zwei Tagen die Auflösung auf zehn Minuten reduziert, im Metrik-Backend findet dagegen keine Änderung der Auflösung statt.
Die Vorhaltedauer: bei RRDs ist die Vorhaltedauer in der Regel vier Jahre (einstellbar), beim Metrik-Backend zwei Wochen (derzeit ohne Modifikationsmöglichkeit)
4.2. Benutzerdefinierte Metriken (custom queries) beliebigen Hosts zuordnen
Alternativ zur Methode über Customize > Custom graphs können Sie unter Setup > Agents > Other integrations > Metric backend (custom query) den Spezialagenten konfigurieren, der einzelne Metriken aus dem Metrik-Backend als Checkmk-Services verfügbar macht. Unter diesem Menüpunkt können Sie auch aus benutzerdefinierten Graphen erzeugte Konfigurationen für den Spezialagenten für Modifikationen aufrufen — in den benutzerdefinierten Graphen ist lediglich das Erstellen neuer Konfigurationen möglich. Eine benutzerdefinierte Metrik können Sie beliebigen Hosts zuordnen.
|
Aus benutzerdefinierten Graphen erstellte benutzerdefinierte Metriken sind auf eine OpenTelemetry-Metrik als Quelle limitiert. Falls Sie mehrere OpenTelemetry-Metriken als Quelle benötigen, müssen Sie in die in diesem Abschnitt vorgestellten Regeln zur Konfiguration des Spezialagenten verwenden, um weitere hinzuzufügen. Wenn Sie aus benutzerdefinierten Graphen mehrere Regeln für Spezialagenten erstellen, wird nur die jeweils erste matchende ausgeführt. |
Da die vom Spezialagenten erzeugten Metriken den „klassischen“ Weg über Monitoring-Kern und RRDs gehen, sind diese nicht von den Einschränkungen im verteilten Monitoring betroffen. Bei der Benennung haben Sie weit reichende Möglichkeiten, so können Sie Freitext mit verschiedenen Makros wie dem ursprünglichen OpenTelemetry-Metriknamen kombinieren.
Schwellwerte anpassen
Um diesen selbst definierten Services Schwellwerte zuzuordnen, können Sie über Setup > Services > Service monitoring rules > Metric backend (custom query) Regeln erstellen. Die Zuweisung entspricht der gängigen Konvention: Sie können obere und untere Schwellwerte für WARN und CRIT definieren. Auch die Bedingungen für Hosts und das Matching von Service-Namen entsprechen dem, was Sie von anderen Stellen in Checkmk kennen.
4.3. Dynamische Host-Verwaltung einrichten
Damit automatisch Hosts erstellt werden, richten Sie eine neue OpenTelemetry-Verbindung mit der dynamischen Host-Verwaltung ein. Vorbereitend empfehlen wir (zumindest für die ersten Tests) einen eigenen Ordner zu erstellen, in dem Sie die automatisch erzeugten OpenTelemetry-Hosts ablegen lassen.
Die Einrichtung der neuen Verbindung für die dynamische Host-Verwaltung erledigen Sie unter Setup > Hosts > Dynamic host management > Add connection:
Im Kasten Connection properties nehmen Sie wenigstens die folgenden Einstellungen vor:
Setzen Sie Connector type auf OpenTelemetry data - Metric backend.
Anschließend legen Sie die Attribute filters fest, anhand derer Sie eine Vorauswahl treffen, wofür Hosts angelegt werden. Diese können leer bleiben. Lediglich für Resource attribute for hostname lookup ist ein Wert einzutragen.
Als Zielordner für die neuen Hosts (Create hosts in) wird im Beispiel der Ordner
OpenTelemetryTestverwendet.Wählen Sie die Host attributes to set entsprechend Ihrer Systemumgebung aus. Meist werden die aus Resource attributes erzeugten Hosts virtuelle sein, die nur im Kontext von OpenTelemetry genutzt werden. Sie können folglich im Regelfall als Monitoring-Agenten ausschließlich Spezialagenten verwenden (Configured API integrations, no Checkmk agent) und die Einstellungen für IP-Adressen auf No IP belassen.
Da in dynamischen Umgebungen mitunter viele Hosts entstehen (und vergehen) können, sollten Sie sinnvolle Werte für die Haltedauer verschwundener Hosts und die Maximalzahl der durch diese dynamische OpenTelemetry-Verbindung vorgehaltenen Hosts setzen.
Für die anderen Parameter finden Sie mehr Informationen im Artikel zur dynamischen Host-Verwaltung.
Sichern Sie die neue Verbindung mit Save und aktivieren Sie die Änderungen.
Sobald die Einrichtung der dynamischen Host-Verwaltung abgeschlossen ist, Sie die Änderungen aktiviert haben und auch OpenTelemetry-Daten eingehen, tauchen ganz von selbst Hosts mit den erwarteten Services auf. Die Konfiguration eines Spezialagenten ist nicht mehr erforderlich: Statt der langen Verarbeitungskette mit Spezialagenten und Check-Plugin fragen jetzt spezielle Fetcher das Metrik-Backend ab und geben Checkmk-Metriken und Service-Zustände direkt an den Monitoring-Kern weiter.
Schwellwerte anpassen
Für die Services können Sie Schwellwerte und mehr festlegen mit der Regel Setup > Services > Service monitoring rules > OpenTelemetry.
Hier haben Sie die Möglichkeit, Regeln für einzelne oder alle Metriken eines Services festzulegen.
An dieser Stelle sind die Konfigurationsmöglichkeiten deutlich größer als bei per Custom query erstellten benutzerdefinierten Metriken.
Der Beispiel-Screenshot zeigt die Auswahl des oben bereits gezeigten Zählers für die OpenTelemetry-Metrik dice.rolls.
Je nachdem, welchen Datentyp der OpenTelemetry-Datenpunkt liefert, kann es sinnvoll sein, Raten berechnen zu lassen. Bei Zählern – wie für verworfene Netzwerkpakete – ist dies sinnvoll. Liefern mehrere Quellen Daten, die ein und demselben Checkmk-Service zugeordnet sind, können Sie darüber hinaus festlegen, ob eine Aggregierung (beispielsweise Summe oder Durchschnitt) vorgenommen werden soll oder schlicht die jüngsten, größten oder kleinsten Datenpunkte eines Intervalls dominieren.