OpenLLMetry: LLM-Tracing als OpenTelemetry-Instrumentierung

Welche Lücke OpenLLMetry schließt und für wen

Ein LLM-Aufruf ist aus Sicht klassischer Anwendungsüberwachung ein HTTP-Request an einen fremden Dienst. Latenz, Statuscode und Fehlerrate lassen sich damit messen. Was fehlt, ist der Inhalt: welches Modell geantwortet hat, wie viele Tokens abgerechnet wurden, welcher Prompt zu einer Antwort geführt hat. Genau diese Ebene adressiert OpenLLMetry. Das Projekt beschreibt sich selbst als Satz von Erweiterungen auf OpenTelemetry, der LLM-Anbieter und Vektor-Datenbanken instrumentiert. Adressat sind damit nicht Data-Science-Teams, die ein Notebook debuggen, sondern Plattform- und Backend-Teams, die eine Anwendung im Betrieb halten und bereits eine Telemetrie-Pipeline besitzen. Der Hinweis im README, dass sich die eigenen semantischen Konventionen inzwischen im OpenTelemetry-Projekt wiederfinden, ist für diese Zielgruppe das eigentliche Argument: Die Attributnamen für LLM-Aufrufe werden nicht nur von einem Anbieter definiert.

Instrumentierung statt eigener Collector

Der Mechanismus ist bewusst unspektakulär. OpenLLMetry ersetzt keine Telemetrie-Infrastruktur, es hängt sich in bestehende Aufrufe ein und erzeugt Spans, die dem OpenTelemetry-Datenmodell folgen. Das README unterscheidet zwei Nutzungswege. Der erste ist das Traceloop SDK, das die verbreiteten Instrumentierungen bündelt und über einen einzelnen Initialisierungsaufruf aktiviert. Der zweite ist die direkte Verwendung einzelner Instrumentierungspakete, etwa opentelemetry-instrumentation-openai, wenn OpenTelemetry im Projekt schon verdrahtet ist. Der Datenfluss bleibt in beiden Fällen gleich: Die Anwendung erzeugt Spans, ein Exporter schickt sie per OTLP an ein Ziel, das Ziel speichert und visualisiert. OpenLLMetry fügt also eine Schicht zwischen Bibliotheksaufruf und Span hinzu, keine Komponente auf dem Transportweg. Wer einen Collector betreibt, der Sampling, Filterung oder Weiterleitung übernimmt, kann diese Regeln unverändert weiterverwenden. Das ist der Grund, warum die Liste der unterstützten Ziele im README so lang ist: Sie besteht überwiegend aus Systemen, die OTLP ohnehin sprechen.

Installation und die zwei Zeilen, die den Unterschied machen

Der Einstieg ist im README knapp dokumentiert. Zuerst pip install traceloop-sdk, dann im Code from traceloop.sdk import Traceloop und Traceloop.init(). Für lokale Entwicklung nennt das README explizit Traceloop.init(disable_batch=True), damit Spans sofort sichtbar werden statt im Batch gepuffert zu bleiben. Dieser Parameter ist mehr als ein Komfortschalter. Im Batch-Modus verlässt die Anwendung den Prozess möglicherweise, bevor der Puffer geleert ist, und Spans gehen verloren. Wer ohne Collector und ohne konfigurierten Exporter startet, sollte außerdem damit rechnen, dass die Bibliothek ihre Daten irgendwohin senden will; die Zielkonfiguration läuft über die üblichen OpenTelemetry-Umgebungsvariablen beziehungsweise die im SDK gesetzten Endpunkte. Das README verweist für die Details auf die Dokumentationsseite zur Einrichtung, statt die Variablen selbst zu nennen. Diese Seite ist damit die erste Quelle, die man vor einem Rollout lesen sollte, nicht das Repository.

Was instrumentiert wird und wo die Grenze verläuft

Das README zählt Anbieter und Vektor-Datenbanken auf: Aleph Alpha, Anthropic, Bedrock von AWS, Chroma, Pinecone, Qdrant, Weaviate und weitere. Die Aussage ist nicht, dass jeder Aufruf automatisch sinnvoll beschrieben wird. Eine Instrumentierung erzeugt Spans für die Aufrufe, die sie erkennt. Läuft der Verkehr über einen selbstgebauten Wrapper, eine interne Abstraktionsschicht oder ein Gateway, das die Anbieter-Bibliothek ersetzt, greift die Instrumentierung möglicherweise ins Leere. Das ist kein Fehler des Projekts, sondern die übliche Grenze bibliotheksbasierter Instrumentierung. Ein zweiter Punkt betrifft den Inhalt der Spans. Prompt- und Antwortdaten sind personenbezogen oder geschäftskritisch, sobald echte Nutzereingaben verarbeitet werden. Ob diese Inhalte als Attribute mitgeschickt werden, lässt sich über die Konfiguration steuern, aber das README nennt die entsprechenden Schalter nicht. Wer OpenLLMetry in einer regulierten Umgebung einsetzt, muss diese Frage vor dem ersten Produktivlauf klären, nicht danach.

Betriebskosten und der Umgang mit Prompt-Daten

Der offensichtlichste Kostentreiber ist die Datenmenge. Ein LLM-Aufruf erzeugt nicht einen Span, sondern je nach Verschachtelung mehrere, und jeder trägt Attribute, die länger sind als ein HTTP-Statuscode. Das verändert Sampling-Entscheidungen: Ein Sampling, das bei klassischen Requests sinnvoll war, kann bei LLM-Spans zu teuer oder zu grob werden. OpenLLMetry liefert dafür keine eigene Lösung, es verlässt sich auf die Mechanismen von OpenTelemetry. Das ist konsistent mit dem Ansatz, verschiebt die Verantwortung aber vollständig zum Betreiber. Konkret heißt das: Wer die Instrumentierung aktiviert, sollte vorher wissen, welcher Collector die Spans empfängt, welche Sampling-Regel dort greift und wie lange die Daten im Backend aufbewahrt werden. Diese drei Fragen sind nicht Teil des Repositorys, sie entscheiden aber darüber, ob der Einsatz tragfähig ist.

Alternative: ein LLM-spezifisches Tracing-SDK

Der naheliegende Gegenentwurf sind Tracing-Bibliotheken, die nicht auf OpenTelemetry aufsetzen, sondern eine eigene Datenstruktur mit eigenen Konventionen für Ketten, Prompts und Evaluationen mitbringen. Der Unterschied liegt nicht in der Anzahl der Funktionen, sondern im Integrationspunkt. Ein solches SDK sendet an das Backend seines Anbieters und bringt dessen Auswertungsoberfläche mit; OpenLLMetry sendet OTLP an ein Ziel der Wahl und überlässt die Oberfläche dem bestehenden Werkzeug. Für ein Team, das noch keine Observability-Plattform hat, ist der erste Weg kürzer: Installation, API-Key, fertige Ansicht. Für ein Team mit Collector, Dashboards und Alerting-Regeln ist der zweite Weg der einzige, der keine zweite Datenhaltung erzeugt. Die Entscheidung fällt damit nicht über die Instrumentierung, sondern über die Frage, ob LLM-Telemetrie im selben System wie die übrige Anwendungstelemetrie liegen soll.

Wartung, Versionierung und Lizenz

Die Release-Historie zeigt eine hohe Taktung: 0.62.1 im Juni, 0.62.2 und 0.62.3 im August desselben Jahres. Solche Sprünge sind normal für Projekte, die vielen sich bewegenden Anbieter-SDKs hinterherinstrumentieren. Sie bedeuten aber auch, dass die Version gepinnt werden sollte. Ein ungeprüftes Upgrade kann Spans verändern, weil ein Anbieter seine Bibliothek angepasst hat. Wer OpenLLMetry einsetzt, braucht einen Test, der die erwarteten Span-Namen und Attribute prüft, sonst fällt eine stille Änderung erst auf, wenn Dashboards leer bleiben. Das Projekt steht unter Apache-2.0, was die kommerzielle Nutzung und Modifikation erlaubt und keine Copyleft-Pflichten für die eigene Anwendung erzeugt. Die Lizenzangabe im README bestätigt das; verbindlich ist der Text in der Datei LICENSE. Ein Hinweis zu den Anbieternamen: OpenLLMetry ist ein Projekt von Traceloop, das parallel ein eigenes kommerzielles Backend anbietet. Die Instrumentierungen sind davon getrennt nutzbar, aber die Produktpflege und die offene Bibliothek teilen sich denselben Maintainer.

Bevor die erste Zeile Instrumentierungscode läuft

Die praktische Prüfliste ergibt sich aus dem Repository selbst. Erstens: Steht der verwendete Anbieter oder die Vektor-Datenbank in der Liste der unterstützten Integrationen? Fehlt er, ist der Nutzen auf die generische OpenTelemetry-Instrumentierung beschränkt. Zweitens: Existiert ein OTLP-Endpunkt, und ist geklärt, welche Sampling-Regel dort für LLM-Spans gilt? Drittens: Ist entschieden, ob Prompt-Inhalte die Anwendung verlassen dürfen? Das README beantwortet die dritte Frage nicht, und die Dokumentationsseiten sind die einzige Stelle, an der die Konfigurationsschalter zu finden sein dürften. Der lokale Test mit disable_batch=True ist der schnellste Weg, um zu sehen, welche Spans tatsächlich entstehen, bevor eine Pipeline dauerhaft mit ihnen belastet wird.

Redaktionelles Fazit

Sinnvoll ist OpenLLMetry für Teams, die bereits einen OTel-Collector oder ein OTLP-fähiges Backend betreiben und LLM-Aufrufe in dieselbe Pipeline einspeisen wollen, statt ein zweites Monitoring-System daneben zu stellen. Wer kein OTLP-Ziel hat, sollte zuerst prüfen, ob der eigene Anbieter in der Liste der Integrationen auftaucht und ob das Backend mit der Attributmenge umgehen kann, die instrumentierte Prompts erzeugen. Vor dem Rollout würde ich die installierte Instrumentierung lokal mit Traceloop.init(disable_batch=True) gegen einen Collector laufen lassen und im ersten Schritt nur die Spans prüfen, die tatsächlich ankommen. Kleine Teams ohne dedizierte Plattformrolle sollten mit dem SDK warten, bis ein OTLP-Endpunkt existiert, an den die Daten gehen können.

Offizielle Quellen

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. traceloop/openllmetry on GitHub