OpenTelemetry-Metriken überwachen

Zunächst müssen Sie bei gestoppter Instanz den Kollektor aktivieren. Dies erledigen Sie als Instanzbenutzer auf der Kommandozeile mit omd config im textbasierten Konfigurationsmenü:

Wechseln Sie hier zu Addons und aktivieren Sie OPENTELEMETRY_COLLECTOR:

Den Port für das Selbst-Monitoring des Kollektors müssen Sie nicht abändern, er wird auch bei Nutzung mehrerer Instanzen auf den nächsten freien Port ab 14317 eingestellt.

Starten Sie nach Aktivierung des Kollektors die Instanz wieder mit omd start.

Rufen Sie Setup > Hosts > OpenTelemetry collector (experimental) auf und starten Sie mit dem Knopf Add OpenTelemetry collector configuration die Einrichtung eines neuen Kollektors:

In den General properties vergeben Sie eine ID und einen Titel für den neuen Kollektor. Für Site restriction müssen Sie wenigstens einen Eintrag von der linken auf die rechte Seite verschieben. Im obigen Screenshot ist die lokale Instanz mysite die einzig verfügbare.

Damit automatisch Hosts erstellt werden, richten Sie eine neue OpenTelemetry-Verbindung mit der dynamischen Host-Konfiguration 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-Konfiguration erledigen Sie unter Setup > Hosts > Dynamic host management > Add connection:

Im Kasten Connection properties nehmen Sie die folgenden Einstellungen vor:

Sichern Sie die neue Verbindung mit Save.

Damit auch Checkmk-Services erzeugt werden, muss wenigstens eine Konfiguration des OpenTelemetry-Spezialagenten erstellt werden. Die benötigte Regel finden Sie unter Setup > Agents > Other integrations > OpenTelemetry (experimental):

Im Kasten OpenTelemetry (experimental) entscheiden Sie, ob Sie den OpenTelemetry-Kollektor selbst überwachen wollen — über den Port, der bei der Aktivierung des Kollektors angezeigt wurde.

In der Bedingung der Regel ist es naheliegend, den Spezialagenten dem Ordner zuzuordnen, in dem die Hosts automatisch erstellt werden — im Beispiel ist das der Ordner OpenTelemetryTest.

Sichern Sie die Regel mit Save.

Nachdem somit die drei Komponenten Kollektor, dynamische Host-Verwaltung und Spezialagent fertig konfiguriert sind, sollten Sie nun die ausstehenden Änderungen aktivieren.

Vermutlich werden Sie den OpenTelemetry-Kollektor für Checkmk deshalb aufsetzen wollen, weil in Ihrer IT-Umgebung schon irgendwo irgendetwas irgendwelche OpenTelemetry-Metriken erzeugt.

Ist das noch nicht der Fall, oder wenn Sie die in diesem Artikel beschriebene beispielhafte Einrichtung schnell ausprobieren wollen, können Sie dies tun mit der in unserem GitHub-Repository bereitgestellten Beispielapplikation „Hello metric“, die in einer virtuellen Python-Umgebung ausgeführt wird.

Von dem Zeitpunkt des Sendens der ersten Daten über die Erzeugung des Hosts, der Service-Erkennung bis zur Sichtbarkeit im Monitoring vergehen etwa zwei bis drei Minuten. Der folgende Screenshot zeigt die Services der „Hello metric“-Beispielapplikation:

Der Host-Name hello-metric wird aus dem Service-Namen generiert, der dem Kommando opentelemetry-instrument als Option mitgegeben wurde — genau so, wie es in der Konfiguration des OpenTelemetry-Kollektors festgelegt wurde. Der Service-Name OTel metric hellolevel in Checkmk wird aus dem Namen der Metrik erzeugt, wobei der Präfix OTel metric vom Spezialagenten hinzugefügt wird.

Wenn Sie bei der Konfiguration des Spezialagenten die Option Monitor the collector aktivieren, also die Selbstüberwachung des Kollektors, werden beim Host eine Reihe zusätzlicher Services erstellt.

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.

Im Monitoring wird nach einigen Minuten der Host dice-server erscheinen mit dem Service OTel metric dice.rolls. Diese hat sechs Graphen, Value_1__Per_Sec bis Value_6__Per_Sec, welche den Raten der bisher gewürfelten Zahlen eins bis sechs entspricht. Hintergrund der Umwandlung ist, dass die OpenTelemetry-Metriken Zähler (Counter) verwenden, welche nur zunehmen können – ein Datentyp, der in Checkmk nicht vorgesehen ist. Für eine übersichtlichere Darstellung erfolgt daher in Checkmk die Umwandlung unter Berücksichtigung der Zeitkomponente.

Der Screenshot zeigt einen dieser Graphen, dem das sekündliche Aufrufen von /rolldice innerhalb des Überwachungszeitraums zugrunde liegt.

Für die Services können Sie Schwellwerte und mehr festlegen mit der Regel Setup > Services > Service monitoring rules > OpenTelemetry (experimental). Hier haben Sie die Möglichkeit, Regeln für einzelne oder alle Metriken eines Services festzulegen. Der Beispiel-Screenshot zeigt die Auswahl des oben bereits gezeigten Zählers für Würfe mit der Zahl 5. Namen bekannter Metriken sind über die Liste beziehungsweise als Vorschlag während des Tippens zugänglich. Noch unbekannte Metriken, bei denen Sie wissen, dass sie erscheinen werden, können Sie als Freitext eintragen.

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.