Zuletzt aktualisiert: 22.10.2026 · Lesezeit: 9-13 Minuten
Was ist OpenTelemetry? Kurz gesagt: der offene, herstellerunabhängige Standard, um Metriken, Logs und Traces zu erfassen, zu verarbeiten und an ein Backend deiner Wahl zu senden.
Wer sich mit dem Thema Monitoring oder Observability befasst, stößt früher oder später (eher früher) auf das Thema OpenTelemetry. Hierbei kommt es immer wieder zu unterschiedlichen Ansichten und Meinungen, was sich denn wirklich dahinter verbirgt. Mit diesem Artikel versuche ich einen Überblick über das Thema zu verschaffen.
Die wichtigsten Punkte in 30 Sekunden
- OpenTelemetry (OTel) ist ein herstellerunabhängiges Open-Source-Framework zum Erfassen, Verarbeiten und Exportieren von Telemetriedaten und mittlerweile der de-facto Industriestandard.
- OTel ist kein Backend und kein Visualisierungssystem. Die Daten werden per OTLP (gRPC oder HTTP) an ein kompatibles Backend wie VictoriaMetrics, Grafana LGTM, Elasticsearch oder OpenSearch gesendet.
- Metriken zeigen, dass etwas nicht stimmt, Traces zeigen, wo es passiert, Logs im Idealfall, warum.
- Der OpenTelemetry Collector arbeitet mit Pipelines aus Receivers, Processors und Exporters, ergänzt durch Extensions und Connectors.
- Semantic Conventions sorgen für einheitliche Attributnamen wie
host.nameund machen Daten aus unterschiedlichen Quellen direkt vergleichbar.
Was genau ist OpenTelemetry eigentlich?
OpenTelemetry (OTel) ist ein Open Source, herstellerunabhängiges Framework und Toolkit zum Erfassen, Verarbeiten und Exportieren von Telemetriedaten wie Logs, Traces, Metriken und Profiles. Es ist mittlerweile der de-facto Industriestandard für die erwähnten Anwendungsfälle (Profiles befindet sich aktuell noch im „Entwicklungsstadium“).
OTel bietet SDKs, APIs (für alle gängigen Programmiersprachen) und diverse Tools an, um Telemetriedaten aus Anwendungen zu generieren und in einem einheitlichen Datenformat zur Verfügung zu stellen. Zur Übertragung dieser Telemetriedaten wird das OpenTelemetry Protocol (OTLP) verwendet, implementiert über die Transportprotokolle gRPC und HTTP.
Da es immer wieder zu Missverständnissen kommt: OpenTelemetry ist kein Backend- oder ein Visualisierungssystem.
Anbei ein Beispiel, wie OpenTelemetry verwendet werden kann, hier am Beispiel des OTel Collectors.
OpenTelemetry ist ein Cloud Native Computing Foundation (CNCF) Projekt. Das Projekt verfolgt das Ziel, einen einheitlichen Standard für die Instrumentierung von Anwendungen sowie für die Erfassung und Weiterleitung von Telemetriedaten zu etablieren.
Was genau sind Telemetriedaten?
Um Systeme und Applikationen zu überwachen, werden Telemetriedaten benötigt. Diese werden uns über verschiedene Wege zur Verfügung gestellt bzw. können abgefragt werden. Wichtig dabei ist: Diese Daten stehen nicht einfach so auf magische Art und Weise zur Verfügung, sie müssen durch die Applikation bzw. das System bereit gestellt werden.
Bevor wir anfangen, Daten zu sammeln, sollten wir uns erst bewusst machen, was genau wir überhaupt überwachen/beobachten möchten. Als Grundlage hierzu ein kleiner Überblick über die drei gängigsten Datensignale, die gesammelt werden können, und was sich dahinter verbirgt:
| Signal | Eigenschaft | Zweck |
|---|---|---|
| Metrik | Numerische Messwerte, die zu einem bestimmten Zeitpunkt erfasst werden. | Wie viel, wie oft, etc.? |
| Log | Textbasierte Einträge, die ein Ereignis innerhalb eines Systems beschreiben, versehen mit einem Zeitstempel wann es auftrat. | Was ist passiert? |
| Trace | Aufzeichnung des vollständigen Wegs, den eine Anfrage durch ein verteiltes System nimmt – aufgeteilt in einzelne Schritte, sogenannte Spans. | Wo ist es passiert? |
Metriken
Metriken sagen uns, dass etwas mit unserem System nicht stimmt, aber nicht warum. Die Messwerte der Metriken werden über sogenannte Messinstrumente erfasst, die Art des Instruments bestimmt, wie gemessen wird. Anbei eine kurze Erklärung zu den gängigsten Typen:
| Art | Beschreibung |
|---|---|
| Counter | Zählt nur aufwärts, z. B. die Gesamtanzahl eingegangener HTTP-Anfragen. |
| Gauge | Misst einen aktuellen Wert zum Zeitpunkt der Abfrage, z.B. die aktuelle CPU-Aulastung. |
| Histogram | Aggregiert Messwerte clientseitig, z. B. um die Verteilung von Antwortzeiten auszuwerten. |
Traces
Zeigt uns eine Metrik z. B. eine hohe Latenz für unseren Webservice an, wissen wir zwar, dass dieser nicht wie vorgesehen funktioniert, aber noch nicht warum. Hierbei helfen uns dann Traces: Diese zeigen uns, an welcher Stelle die Latenz auf dem Weg durch mehrere Services (Datenbanken, APIs, Frontend usw.) entsteht.
Dazu folgt ein Trace der einzelnen Anfrage vom Anfangspunkt bis zur finalen Antwort und zeichnet dabei auf seinem Weg die benötigte Zeit pro Service auf.
Ein Trace ist in kleinere Einheiten unterteilt, sogenannte Spans. Jeder Span stellt eine Operation dar: HTTP Request Handling, Datenbankabfrage, Aufruf eines anderen Services usw. Die Darstellung erfolgt dann hierarchisch aufgebaut, ein übergeordneter Span kann mehrere untergeordnete Spans enthalten.
Logs
Logs zeigen uns im Idealfall, warum etwas nicht funktioniert. Ein Logeintrag zeigt ein bestimmtes Event zu einem spezifischem Zeitpunkt.
Wie sammele bzw. verarbeite ich Telemetriedaten mit OpenTelemetry?
Im nächsten Schritt möchten wir die festgelegten Telemetriedaten sammeln und an ein beliebiges Backend (VictoriaMetrics, Grafana LGTM, Elasticsearch, OpenSearch usw.) senden. Dazu verwenden wir den OpenTelemetry Collector (otelcol).
OpenTelemetry Collector installieren
Der otelcol kann über verschiedene Wege installiert werden:
- Source
- Docker
- Kubernetes
- Binarys (Linux, macOS, Windows)
Die Installation am Beispiel auf einem Debian System ist schnell erfolgt, da DEB Pakete zur Verfügung stehen. Bei der Paketinstallation wird auch gleich ein systemd Service angelegt.
Der Collector liegt in zwei Versionen vor, einmal Standard und in der Contrib Variante. In der Standardvariante sind nur einige gängige Receiver, Exporter, Extensions, Processors, Connectors sowie Provider (mehr dazu weiter unten) enthalten, während in der Contribvariante bereits alle verfügbaren integriert sind. Grundsätzlich lassen sich auch einzelne Module integrieren, um es uns einfach zu machen, wählen wir in unserem Beispiel aber die Contrib Variante.
sudo apt-get update
sudo apt-get -y install wget
wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.158.0/otelcol-contrib_0.158.0_linux_amd64.deb
sudo dpkg -i otelcol-contrib_0.158.0_linux_amd64.debNach der Installation kann mit der Konfiguration des Collectors begonnen werden, die Konfigurationsdatei liegt unter:
/etc/otelcol-contribAufbau der Collector-Konfiguration
Die Konfigurationsdatei kann aus folgenden Pipelinekomponenten bestehen:
| Komponente | Zweck |
|---|---|
| Receivers | Sammeln von Telemetriedaten von verschiedenen Quellen und Formaten |
| Processors | Transformieren, filtern oder ergänzen von Telemetriedaten |
| Exporters | Senden von Telemetriedaten an ein Backend |
| Connectors | Zum verbinden von zwei Pipelines, agiert als Exporter und Receiver |
| Extensions | Stellt zusätzliche Funktionen bereit, wie etwa Authenfizierung |
Anbei erstellen wir eine beispielhafte Konfiguration, um Metriken und Logfiles von einem Linux-System an ein VictoriaMetrics/VictoriaLogs-Backend mit Authentifizierung über vmauth zu senden.
Die Datei liegt Standardmäßig unter /etc/otelcol-contrib/config.yaml
Receivers
Wir beginnen mit dem Receivers Block für die Telemetriedaten unseres Hostystems. Hier wird definiert, was wir sammeln möchten und aus welcher Quelle. Am Beispiel der Hostmetrics gibt es zu jedem Scraper (CPU, Disk, …) vordefinierte Standardmetriken, die geliefert werden. Zusätzlich gibt es dann noch diverse optionale Metriken, diese müssen explizit definiert werden. Welche das sind finden wir unter folgendem Link. Weitere Receiver findet ihr hier.
---
receivers:
hostmetrics:
root_path: /hostfs
collection_interval: 10s
scrapers:
cpu:
metrics:
system.cpu.utilization:
enabled: true
system.cpu.logical.count:
enabled: true
disk:
load:
filesystem:
exclude_mount_points:
match_type: regexp
mount_points:
- '/hostfs/proc.*'
- '/hostfs/sys.*'
memory:
metrics:
system.memory.utilization:
enabled: true
system.memory.limit:
enabled: true
network:
paging:
metrics:
system.paging.usage:
enabled: true
processes:
process:
mute_process_exe_error: true
mute_process_io_error: true
mute_process_user_error: true
system:
metrics:
system.uptime:
enabled: trueAls nächstes widmen wir uns dem Receiver für unsere Logfiles, diese holen wir uns aus dem Journald des Hostsytem. Auch hier gibt es wieder diverse Konfigurationsparameter. Es lässt sich z.B. konfigurieren, welche systemd Units uns interessieren, es macht ja nicht unbedingt Sinn das komplette Journald in unser Backend zu schreiben.
Hierbei ist noch zu beachten, dass der otelcol-contrib Lesezugriff auf das journald benötigt.
journald:
directory: /var/log/journal
priority: info
start_at: endProcessors: Resource Detection
Nun haben wir definiert, welche Telemetriedaten wir empfangen und weiterverarbeitet haben möchten, der nächste Schritt folgt dann mit den Processors. Hier könnten wir den Telemetriedaten noch weitere Attribute wie Labels usw. mitgeben, weitere Infos dazu findet ihr hier. In unserem einfachen Beispiel verwenden wir nur den Resource Detection Processor.
Der Resource Detection Processer erkennt die Metadaten unseres Hostsystems und „wandelt“ diese Informationen in die OpenTelemetry Resource Semantic Conventions um. Warum das gut und wichtig ist, findest du unter folgendem Absatz.
processors:
resourcedetection:
detectors: [system]
system:
hostname_sources: ["os", "dns"]Extensions und Exporters
Damit haben wir alles Telemetriespezifische definiert. Als vorletzten Schritt definieren wir noch die Extensions und Exporters.
Extensions sind optionale Komponenten, die nicht direkt mit der Verarberbeitung von Telemetriedaten zu tun haben, wir verwenden Sie in unserem Beispiel Basicauth um uns am Backend authentifizieren zu können, weitere Erweiterungen findet ihr hier.
Exporter senden unsere gesammelten Telemetriedaten an das Backend oder andere Ziele, da wir in unserem Beispiel VictoriaMetrics bzw. VictoriaLogs verwenden und diese Backends nativ OTLP „sprechen“, verwenden wir den otlp_http Exporter, weitere sind hier gelistet. Zum einen definieren wir in diesem Block die Endpoints für Logs und Metriken, übergeben noch einen Header, der VictoriaLogs sagt, wo sich das Message-Feld in den Logfiles befindet, und zuletzt noch die Parameter zur Authentifizierung am Backend.
extensions:
basicauth:
client_auth:
username: xxx
password: xxx
exporters:
otlp_http:
metrics_endpoint: http://localhost:8427/opentelemetry/v1/metrics
logs_endpoint: http://localhost:8427/insert/opentelemetry/v1/logs
headers:
VL-Msg-Field: "body,MESSAGE"
auth:
authenticator: basicauthOpenTelemetry in deiner Umgebung einführen?
Unsere Consultants unterstützen dich bei Konzeption, Collector-Setup und der Anbindung an dein Observability-Backend.
Beratung anfragen →
Service-Block: die Pipeline
Abschließend haben wir noch den Service Block, in diesem wird definiert wie die erstellten Blöcke zusammenhängen, die sogenannte Pipeline.
service:
extensions: [basicauth]
pipelines:
metrics:
receivers: [hostmetrics]
processors: [resourcedetection]
exporters: [otlp_http]
logs:
receivers: [journald]
processors: [resourcedetection]
exporters: [otlp_http]Am Beispiel der Metriken sagt diese Konfiguration: Nutze den Receiver hostmetrics gebe die Daten an den Processor resourcedetection weiter und zuletzt an den Exporter otlp_http. Extensions gehören keiner Pipeline an, können aber als „Hilfsdienste“ genutzt werden, im Exporters Block hatten wir ja die basicauth verwendet um uns am Backend zu authentifizieren. Haben wir Blöcke in der Konfiguration definiert, aber nicht in einer Pipeline verwendet, werden diese ignoriert.
Gestartet wird der otelcol mit:
sudo systemctl start otelcol-contrib.serviceWird die Konfiguration verändert, muss der Service neugestartet werden. Die Änderungen werden per default Settings nicht automatisch übernommen, dies machen wir mit:
sudo systemctl restart otelcol-contrib.serviceFür das Troubleshooting können wir uns die Logeinträge im journald ansehen:
sudo journalctl -u otelcol-contribWerden weitere Informationen benötigt, lässt sich der debug Modus des otelcol aktivieren, in dem wir einen Debug Exporter erstellen und entsprechend der Pipeline hinzufügen. Der Exporter wird wie folgt definiert:
exporters:
debug:
verbosity: detailedOpenTelemetry Semantic Convetions
Mit den Semantic Conventions werden Standards für einheitliche Bezeichnungen von verschiedenen Telemetriedaten geschaffen. Das bedeutet: Während es nicht unüblich war, dass Tool A für z. B. den Hostname eines Systems ein Attribut „hostname“ verwendete, verwendete Tool B dafür „host“ und zuletzt dann noch Tool C „instance“. In der Arbeit mit diesen Daten bedeutete das, dass ich alle drei möglichen Varianten in einer Datenabfrage in Betracht ziehen musste und es ein riesiger Aufwand war, Daten, die eigentlich dasselbe mitteilen, miteinander vergleichen zu können. Durch den Einsatz der OpenTelemetry Semantic Convention wird daraus ein einheitliches „host.name“, egal ob es sich beispielsweise um Logs, Traces oder Metriken handelt.
Fazit
OpenTelemetry schafft etwas, das in der Observability-Welt lange gefehlt hat: einen herstellerunabhängigen Standard für die Erfassung, Verarbeitung und den Transport von Telemetriedaten.
Der Collector zeigt diesen Ansatz in der Praxis. Daten werden an einer Stelle empfangen, verarbeitet und an ein beliebiges, kompatibles Backend weitergeleitet. Mit Einsatz der Semantic Conventions können wir sicherstellen, dass Telemetriedaten aus unterschiedlichen Quellen und Sprachen einheitlich benannt und damit direkt vergleichbar sind, was einen großen Vorteil in unserer täglichen Arbeit bietet.
OpenTelemetry ist kein fertiges Monitoring- oder Observability System, sondern eine grundlegende Basis dafür. Ich bin der Meinung: Wer heute auf OpenTelemetry setzt, investiert nicht in ein einzelnes Tool, sondern in den offenen Standard für Observability. Breit unterstützt, zukunftsfähig und unabhängig von einzelnen Herstellern.
Hast du Fragen oder benötigst du Hilfe, bei Themen Rund um OpenTelemetry, Monitoring oder Observability? Wir begleiten dich bei jedem Schritt, von der Konzeption bis zur erfolgreichen Umsetzung. Melde dich gerne bei unserem Team für eine unverbindliche Beratung!
