![]() |
Die hier vorgestellte Funktionalität ist ein Technical Preview, also die Vorschau auf ein neues Feature, das bis auf weiteres Wandel und Erweiterung unterworfen sein wird. Während dieser Phase ist es möglich, dass Funktionalität nicht nur hinzugefügt, sondern auch so umgebaut wird, dass bereits vorhandene Konfiguration obsolet wird und Sie diese neu erstellen müssen. Wir bitten dafür um Verständnis. |
1. Einleitung
Ab Checkmk 2.4.0 können Sie ab
Checkmk Cloud, d. h. in Checkmk Cloud und Checkmk MSP, OpenTelemetry-Metriken empfangen und im Monitoring verarbeiten.
Hierfür bringt Checkmk einen OpenTelemetry-Kollektor mit.
Dieser unterstützt die Transportprotokolle gRPC und HTTP(S) als Empfänger in einer Push-Konfiguration.
Zudem kann er als Scraper Daten von Prometheus-Endpunkten einsammeln (Pull-Konfiguration).
Basierend auf den erkannten OpenTelemetry-Services können mit der dynamischen Host-Verwaltung Hosts automatisch erzeugt werden. Diesen Hosts werden dann von einem Spezialagenten OpenTelemetry-Metriken als Checkmk-Services zugeordnet.
Kurz zusammengefasst: Drei Komponenten (Kollektor, dynamische Host-Verwaltung und Spezialagent) müssen zusammenspielen, bevor Services erkannt und Metriken erzeugt werden können. Sie sollten daher zuerst diese drei Komponenten konfigurieren und erst zum Abschluss die ausstehenden Änderungen aktivieren.
![]() |
Dieser Artikel beschreibt den Stand der OpenTelemetry-Integration bei Veröffentlichung von Checkmk 2.4.0p10. Wir arbeiten weiterhin daran, danach vorgenommene Änderungen der Patch-Releases einzupflegen. Bitte beachten Sie die OpenTelemetry betreffenden Werks, um den aktuellen Stand der von Ihnen verwendeten Checkmk-Version zu erfahren. |
2. Einrichtung
2.1. OpenTelemetry-Kollektor aktivieren
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ü:
OMD[mysite]:~$ omd config
Wechseln Sie hier zu Addons
und aktivieren Sie OPENTELEMETRY_COLLECTOR
:
┌──────────────────────────Addons─────────────────────────────┐ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ MKEVENTD on │ │ │ │ MKEVENTD_SNMPTRAP off │ │ │ │ MKEVENTD_SYSLOG off │ │ │ │ MKEVENTD_SYSLOG_TCP off │ │ │ │ OPENTELEMETRY_COLLECTOR on │ │ │ │ OPENTELEMETRY_COLLECTOR_SELF_MONITORING_PORT 14317 │ │ │ │ TRACE_RECEIVE off │ │ │ │ TRACE_SEND off │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────────┤ │ < Change > <Main menu> │ └─────────────────────────────────────────────────────────────┘
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
.
2.2. OpenTelemetry-Kollektor einrichten
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.

Grundeinstellungen
In den Eigenschaften des Kollektors achten Sie auf die folgenden Punkte:
Sie müssen zumindest einen der beiden Push-Endpunkte (über gRPC oder HTTP) oder einen Prometheus-Scraper (Pull) einrichten. Der Screenshot zeigt einen unverschlüsselten, nicht authentifizierten gRPC-Endpunkt auf dem Standard-Port 4317 auf allen IPv4-Adressen (
0.0.0.0
).Erstellen Sie wenigstens ein Feld für die Host name computation. Im Beispiel ist die einfachste Möglichkeit ausgewählt: das per OpenTelemetry empfangene Feld
service.name
wird als Host-Name in Checkmk verwendet. In der Inline-Hilfe finden Sie mehr Informationen zu den Möglichkeiten, wie Sie aus den OpenTelemetry-Daten Host-Namen erstellen lassen können.
![]() |
Ist eine etwas komplexere Erstellung der Host-Namen gewünscht, speichern Sie die Kollektorkonfiguration und aktivieren Änderungen, ohne eine Regel für die Host name computation hinzugefügt zu haben. Sorgen Sie dann dafür, dass Metriken zum Kollektor geschickt werden. Wenn Sie jetzt Regeln für die Host name computation hinzufügen, werden Vorschläge für die verfügbaren Felder angezeigt. |
Logs zur Event Console schicken
OpenTelemetry bietet auch Möglichkeiten, Log-Meldungen zu übertragen. Der Kollektor kann so konfiguriert werden, dass er diese im Syslog-Format an beliebige Anwendungen übertragen kann, die Syslog-Meldungen über TCP entgegennehmen können. Im Kontext von Checkmk ist die Verarbeitung von Log-Meldungen durch die Event Console interessant. Diese Funktion können Sie mit der Checkbox Send log messages to event console aktivieren.
![]() |
Beachten Sie, dass bereits auf Seiten der OpenTelemetry Instrumentation ein sparsamer Versand von Log-Meldungen sichergestellt ist.
Wenn unklar ist, was alles beim Checkmk Server ankommt, aktivieren Sie temporär einen lokalen |
Mit Save sichern Sie den Kollektor.
2.3. Dynamische Host-Konfiguration einrichten
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:
Setzen Sie Connector type auf OpenTelemetry collector data.
Als Zielordner für die neuen Hosts (Create hosts in) wird im Beispiel der Ordner
OpenTelemetryTest
verwendet.Setzen Sie die Host attributes entsprechend Ihrer Systemumgebung.
Sofern Sie sich nicht die Mühe gemacht haben, bei der Einrichtung des OpenTelemetry-Kollektors Namen existierender Hosts zu erzeugen, werden die automatisch erstellten Hosts virtuelle sein, die nur im Kontext von OpenTelemetry genutzt werden. Sie können folglich als Monitoring-Agenten ausschließlich Spezialagenten verwenden (Configured API integrations, no Checkmk agent) und die Einstellungen für IP-Adressen auf No IP belassen.
Durch Aktivieren der Checkbox bei Service discovery legen Sie fest, dass auf den automatisch erzeugten Hosts eine Service-Erkennung durchgeführt wird. Dies führt dann zum gewünschten Ergebnis, wenn der Spezialagent für OpenTelemetry eingerichtet und aktiv ist.
Für die anderen Parameter finden Sie mehr Informationen im Artikel zur dynamischen Host-Konfiguration.
Sichern Sie die neue Verbindung mit Save.
2.4. Spezialagent konfigurieren
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.
2.5. Testdaten an den Kollektor senden
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):
user@host:~$ opentelemetry-instrument \
--traces_exporter console \
--metrics_exporter otlp \
--exporter_otlp_metrics_endpoint http://198.51.100.42:4317 \
--logs_exporter console \
--service_name dice-server \
flask run -p 8080
![]() |
Die bis Checkmk 2.4.0p3 geltende Einschränkung auf exakt einen Datenpunkt ist weggefallen. Wie Checkmk-Metriknamen bei OpenTelemetry-Metriken mit mehreren Datenpunkten generiert werden, beschreibt das Werk #18209. |
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.

2.6. Services anpassen
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.

3. Dateien und Verzeichnisse
Pfad | Bedeutung |
---|---|
|
Hier entstehen OpenTelemetry-Daten. Für jeden Host wird ein Unterverzeichnis erstellt. Die dort erstellten Dateien sind im JSON-Format. |
|
Log-Datei des OpenTelemetry-Kollektors. |
|
Temporäres Verzeichnis, in dem aggregierte Daten des Kollektors für die Auswertung durch den Spezialagenten abgelegt werden. |
|
Temporäres Verzeichnis, in dem von der Vorschlagsfunktion (Listeneinträge und Vorschläge beim Tippen) benötigte Dateien abgelegt werden. |