Ein Platform-Engineer öffnet am Montagmorgen sein Dashboard, und darauf laufen vierzig Linien. Vierzig Dienste in Go, Java, .NET, Node.js und Python, verteilt über drei Kubernetes-Cluster. Kein Dienst wurde für Tracing umgebaut, kein SDK nachgezogen, kein Deployment-Skript angepasst. Die Latenzen, Fehlerraten und Abhängigkeiten sind trotzdem da, weil auf jedem Knoten ein Agent im Linux-Kernel sitzt und mitliest, was die Anwendungen über das Netzwerk austauschen. Dieses Werkzeug hat jetzt Version 1.0.0 erreicht: die OpenTelemetry eBPF Instrumentation, kurz OBI.
Die Ankündigung aus dem OpenTelemetry-Projekt bleibt nüchtern. Von einem Wendepunkt ist dort nicht die Rede, sondern von Vorhersehbarkeit: Man soll wissen, was ein Upgrade mit sich bringt und wie man weiterkommt, wenn sich etwas ändert. OBI sammelt Metriken und Traces über Dienste, Sprachen und Frameworks hinweg, ohne dass Quellcode angefasst werden muss. Den Einstieg bilden Anfrageraten, Fehler, Latenz und Abhängigkeiten zwischen Diensten; tiefer gehende Einsicht kommt später dazu. Die Reihenfolge ist bewusst gewählt: erst der Überblick, dann die Details.
eBPF als Beobachter am Werkszaun
Um zu verstehen, was OBI tut, hilft ein Bild: eine Werkshalle, in der niemand etwas umbauen darf. Die Maschinen laufen, die Bänder laufen, und am Zaun steht ein Beobachter mit einem Notizblock. Er betritt die Halle nicht, er schraubt nichts auf, er notiert nur, was an der Rampe ankommt und was wieder hinausgeht. eBPF besteht aus kleinen Programmen, die an fest definierten Stellen im Linux-Kernel laufen, ohne dass ein Kernelmodul nachgeladen oder der Kernel neu gebaut werden muss. Bevor so ein Programm starten darf, prüft ein Verifier, dass es nicht aus dem Ruder laufen kann. Deshalb hat sich eBPF in produktionsnahen Umgebungen durchgesetzt.
Aus dieser Position sieht der Beobachter Systemaufrufe und Netzwerkverkehr. Er weiß, wann eine Verbindung aufgebaut wird, wie lange eine Antwort braucht und welcher Aufruf mit einem Fehler endet. Was er nicht sieht, ist das Innere der Halle, also die Geschäftslogik einer Anwendung: welcher Codezweig genommen wurde, welche Datenbankabfrage im Hintergrund lief, welcher Nutzer die Anfrage ausgelöst hat. Deshalb kombiniert OBI eBPF mit sprachspezifischer Instrumentierung. Für verbreitete Runtimes liest sie zusätzlich mit, was innerhalb des Prozesses passiert, und verknüpft die einzelnen Abschnitte zu einem Trace. Der Kontext wird über die üblichen Header weitergereicht, sodass aus vielen Einzelbeobachtungen eine Kette über mehrere Dienste wird. So entstehen verteilte Traces: Der Beobachter am Zaun muss nicht in jede Halle hinein, um den Weg einer Bestellung durch das gesamte Werk nachzuzeichnen.
Was Version 1.0 zusichert: Config v2, Schema und Migration
Der wichtigste Unterschied zwischen einer Vorschauversion und 1.0 ist nicht ein Feature, sondern eine Zusage. OBI 1.0 dokumentiert, welche Schnittstellen für Konfiguration und Deployment stabil bleiben, darunter Config v2, das dazugehörige generierte Schema, die dokumentierten Deployment-Schnittstellen und die unterstützten Umgebungen. Für die Telemetrie selbst fällt die Zusage differenzierter aus. OBI erzeugt eine Mischung aus Telemetrie, die stabilen semantischen Konventionen folgt, und solcher, deren Konventionen sich noch entwickeln. Die zweite Gruppe darf sich ändern; bei der ersten werden Fehler korrigiert, wenn das tatsächliche Verhalten nicht zur Konvention passt.
Damit dieser Wandel handhabbar bleibt, beschreibt OBI seine Telemetrie in einer Weaver-kompatiblen Schema-Registry. OpenTelemetry Weaver dient dazu, Telemetrie zu definieren, gegen die vorgesehenen Konventionen zu prüfen und reviewbar zu machen. Veröffentlichte Schemata beschreiben Transformationen zwischen Versionen, soweit sich diese abbilden lassen; wo zusätzliches Handeln nötig ist, erklären Release Notes und Migrationshinweise den Weg. Für Teams, die Dashboards, Alarme und Verarbeitungspipelines betreiben, heißt das: Man kann ein Upgrade planen, statt es zu erleiden. Wer schon dabei ist, sollte die Migration auf Config v2 ernst nehmen. Sie ist seit v0.11.0 verfügbar und bringt das Kommando obi config validate sowie obi config migrate mit. Config v1 bleibt aus Gründen der Rückwärtskompatibilität nutzbar, ist aber eingefroren und bekommt weder Fehlerkorrekturen noch neue Funktionen. Ein Blick auf Konfiguration, die über Umgebungsvariablen gesetzt wird, lohnt sich zusätzlich, und ein Canary-Deployment mit Vergleich der Telemetrie ist billiger als ein Rollback im Feiertagsfenster. Wer OBI in einen Collector einbettet, sollte außerdem beachten, dass der Receiver eine eigene v0-Reihe hat, deren Versionsstand separat zu prüfen ist.
Mehr Protokolle, mehr Abhängigkeiten im Blick
Über die Releases hinweg ist die Abdeckung gewachsen. Dazu kamen unter anderem MQTT, NATS, AMQP 1.0, MSSQL, Couchbase, Memcached und Aerospike. Für gemischte Technologie-Stacks bedeutet das: Datenbank- und Messaging-Aktivität lassen sich über denselben Instrumentierungsansatz beobachten, statt für jedes System ein eigenes Werkzeug zu betreiben. Die Support-Matrix dokumentiert dabei nicht nur die Abdeckung, sondern auch, inwiefern Trace-Kontext über das jeweilige Protokoll weitergereicht werden kann und wo Grenzen liegen. Diese Einschränkungen offen zu benennen ist wichtiger, als die Liste der Protokolle zu verlängern.
Verbessert wurde auch die Behandlung von HTTP/2 und gRPC. Bestehende Verbindungen, gemultiplexte Ströme und der Kontext einzelner Streams waren lange eine Fehlerquelle, weil ein einzelner TCP-Zusammenhang viele logische Anfragen trägt. Wer hier vorher unplausible Latenzen gesehen hat, sollte erneut prüfen. Dazu kommt die Routenerkennung für Django, FastAPI, Flask, Rails, .NET und mehrere PHP-Frameworks. Route-Templates sind kein Detail, sondern der Unterschied zwischen einem brauchbaren Dashboard und einer Metrik-Sammlung, in der jede einzelne URL mit Query-Parameter zu einer eigenen Zeitreihe wird. Der Beobachter am Zaun notiert jetzt also nicht mehr jede Lieferscheinnummer, sondern die Art der Lieferung.
Runtime-Metriken, Trace-Log-Korrelation und GenAI-Telemetrie
Jenseits des Netzwerks erfasst OBI inzwischen Laufzeitmetriken für Go, Java, .NET, Node.js und Python, ergänzt um Netzwerkmessungen wie TCP-Retransmissions und fehlgeschlagene Verbindungen. Die Runtime-Metriken gelten weiterhin als experimentell, ihre Verfügbarkeit hängt von der Runtime und den aktivierten Funktionen ab. Wer sie in Alarmen verwendet, sollte das wissen. Hinzu kommt die Verknüpfung von Traces und Logs: Unterstützte Anwendungslogs lassen sich mit Trace-Kontext anreichern, sodass man vom Pfad einer Anfrage zu den zugehörigen Logzeilen kommt, statt sie manuell über Zeitstempel zu suchen. Ein Durchlauf von Mattia Meleleo zeigt diese zero-code trace-log correlation über zwei Dienste hinweg und erklärt, wie man sie einschaltet.
Auch der Bereich KI-Anwendungen ist abgedeckt: Modell-Provider, Embeddings, Reranking, Vektor-Retrieval und MCP-Interaktionen, inklusive Tool-Aufrufen, OpenAI-kompatiblen Gateways und nativer Ollama-Unterstützung. Damit lassen sich Abhängigkeiten von KI-Diensten im selben Bild betrachten wie der Rest einer Anwendung. Die Einschränkung: Eine detaillierte Extraktion von Nutzlasten erfordert explizite Payload-Capture- und Feature-Konfiguration. Sie ist nicht automatisch für jedes Deployment aktiv, denn Payloads können personenbezogene Daten enthalten. Wo die automatische Beobachtung nicht reicht, bleibt eigener Code gefragt: OBI kann application-authored Spans über die OpenTelemetry Go Trace API und Auto-SDK-Konfigurationen erfassen, für Node.js gibt es zusätzlich eine opt-in-Möglichkeit zur manuellen Span-Erfassung ohne registriertes SDK. Beides unterliegt dokumentierten Runtime-Anforderungen.
Von Beyla zu 1.0: wie der Einstieg gelingt
OBI begann mit der Spende von Grafana Beyla an OpenTelemetry und erreichte über die Zusammenarbeit mehrerer Organisationen und der breiteren Community die erste Alpha-Version. Die Ankündigung nennt Beiträge, ohne die der Schritt auf 1.0 nicht möglich gewesen wäre: Nikola Grcevski und Mario Macias für das Instrumentierungsfundament sowie Runtime-Unterstützung, Service Discovery und Konfiguration, Nimrod Avni für Schema-Generierung, Collector-Integration und die Weaver-Validierung, Mattia Meleleo für Trace-Log-Korrelation und Go-Instrumentierung, Rafael Roquetto für die eBPF-Infrastruktur und Parser-Härtung, Giuseppe Ognibene für Netzwerk-Observability und Runtime-Metriken, Stephen Lang für CI, Integrationstests und ARM-Abdeckung sowie Marc Tudurí und Haibin Zhang für Protokoll- und GenAI-Abdeckung. Ein nicht kleiner Teil der Arbeit war unspektakulär: Parser härten, Lebenszyklen und Exportverhalten korrigieren, Puffer-Sicherheit, Trace-Parent-Beziehungen, dazu signierte Artefakte, Checksummen und Software Bills of Materials.
Für einen Einstieg empfiehlt das Projekt einen repräsentativen Dienst auf einem unterstützten Linux-Host oder in einem Kubernetes-Cluster. Man exportiert die Daten in einen OpenTelemetry Collector oder ein kompatibles Backend, prüft Metriken und Traces und erweitert von dort aus. Wer mehr braucht als das, was automatisch sichtbar ist, greift weiterhin zu Language Agents und manueller Instrumentierung. Das ist keine Schwäche, sondern eine Arbeitsteilung: Der Beobachter am Zaun liefert die Grundlage, die Anwendung selbst liefert die Details. Für 2027 sammelt das Projekt nun Themen, und der Weg dafür ist offen: ein bestehendes Issue um den eigenen Anwendungsfall ergänzen, ein Feature-Request öffnen oder die Idee in ein SIG-eBPF-Instrumentation-Meeting mitbringen.
Was das konkret bedeutet
Ein 1.0 ist in der Observability-Welt vor allem eine Zusage für den nächsten Upgrade. Wer OBI produktiv einsetzt, bekommt Planbarkeit: eine eingefrorene alte Konfiguration, eine dokumentierte neue, prüfbare Telemetrie-Schemata und ein Migrationspfad, der auch dann erklärt wird, wenn er nicht automatisch gangbar ist. Neuankömmlinge bekommen einen Einstieg in Linux-Monitoring ohne monatelanges Umbauen der Anwendungen. In beiden Fällen bleibt die Grenze dieselbe wie beim Beobachter am Werkszaun: Man sieht den Verkehr und die Ränder der Anwendung sehr genau, das Innere der Halle erst mit zusätzlicher Instrumentierung. Wer diese Grenze kennt, kann gezielt entscheiden, wo zusätzliche Instrumentierung nötig ist – und welches Protokoll, welche Runtime oder welche Funktion als Nächstes fehlt.
Quelle: opentelemetry.io
