1. Einleitung
In 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 zusammen spielen, 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.
 |
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. |
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 configWechseln 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.
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.namewird 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.
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
OpenTelemetryTestverwendet.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 dynamische 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,
|
Nur OpenTelemetry-Metriken, die exakt einen Datenpunkt enthalten, werden als ein Service mit exakt einer Metrik in Checkmk dargestellt. |
Ganz ähnlich wie „Hello metric“ funktioniert auch die auf der OpenTelemetry-Website vorgestellte Beispielapplikation „Dice Roll“.
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 8080Im Monitoring wird nach einigen Minuten der Host dice-server erscheinen mit dem Service OTel metric dice.rolls.
In der „Dice Roll“-Beispiel-Applikation ist die Metrik dice.rolls jedoch verschachtelt und erzeugt daher lediglich einen informativen Service, der immer OK bleibt.
Erstellen Sie statt einer verschachtelten zwei „flache“ Metriken, um zwei Services in Checkmk zu erhalten.
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).
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. |
|
Temporäres Verzeichnis, in dem aggregierte Daten des Kollektors für die Auswertung durch den Spezialagenten abgelegt werden. |