OpenLLMetry: LLM-Tracing über OpenTelemetry 2026

Constantin, Pexon Consulting | 7 Min. Lesezeit | 25.07.2026

TL;DR

OpenLLMetry instrumentiert eure LLM-Calls über den offenen OpenTelemetry-Standard, vendor-neutral und ohne Lock-in. Der Haken: Es liefert nur die Instrumentierung, kein Backend. Wir bei Pexon zeigen, wann sich der Standard gegen jede All-in-One-Insellösung durchsetzt und bauen die produktionsreife Anbindung als 6-Wochen-Pilot.

Warum LLM-Tracing so oft zur Insellösung verkommt

Jedes zweite GenAI-Team, das wir sehen, hat dasselbe Muster: Ein Feature geht in den POC, jemand klickt schnell ein Observability-SDK dazu, und plötzlich hängt die komplette Nachvollziehbarkeit an einem einzigen Anbieter. Die Prompts, die Token-Kosten, die Latenzen, die Traces liegen in einem Format, das nur dieses eine Tool versteht.

Das rächt sich spätestens, wenn ihr das Modell wechselt, den Anbieter neu ausschreibt oder Compliance verlangt, dass Telemetrie im eigenen Stack landet. Dann migriert ihr nicht nur Code, sondern die gesamte Beobachtbarkeit, und das mitten im Betrieb, wenn niemand Zeit für ein solches Umbauprojekt hat. Die Kosten dafür tauchen in keinem POC-Budget auf, weil sie erst später und dann umso härter zuschlagen.

Unsere klare Position: LLM-Observability gehört nicht in eine proprietäre Insel. Sie gehört auf denselben offenen Standard, auf dem euer restliches Platform Engineering ohnehin schon läuft. Genau hier setzt OpenLLMetry an.

Was OpenLLMetry ist und wie es funktioniert

OpenLLMetry ist ein quelloffenes Projekt von Traceloop unter Apache-2.0-Lizenz (laut GitHub über 7.000 Sterne, aktuelle Version 0.60.0 vom April 2026). Es ist kein neues Observability-Tool, sondern eine Sammlung von OpenTelemetry-Instrumentierungen: für LLM-Anbieter, Vektor-Datenbanken und die gängigen Frameworks.

Der Kern-Trick: OpenLLMetry hängt sich in eure bestehenden Bibliotheks-Calls und emittiert standardkonforme OTel-Spans mit Prompt, Completion, Token-Zählung und Latenz. Weil das reines OpenTelemetry ist, fließen die Traces in dasselbe Backend wie eure App-Telemetrie.

# Installation (nach Angaben des Projekts): pip install traceloop-sdk
from traceloop.sdk import Traceloop

# Einmal initialisieren - Traces gehen an das konfigurierte OTel-Backend,
# gesteuert über die Standard-Umgebungsvariable OTEL_EXPORTER_OTLP_ENDPOINT.
# Wichtig: OpenLLMetry selbst hat KEIN Dashboard - das Backend muss stehen.
Traceloop.init(app_name="pexon_rag_service")

# Ab hier werden LLM- und Vektor-DB-Calls automatisch als Spans erfasst,
# ohne dass ihr jeden Aufruf von Hand instrumentieren müsst.

Für eine saubere Einordnung im Gesamtbild lohnt der Blick auf den Aufbau eines belastbaren AI-Engineering-Stacks – OpenLLMetry ist dort die Verkabelungsschicht, nicht das Ziel.

Die Falle: OpenLLMetry hat kein eigenes Backend

Das ist der Punkt, an dem die meisten Teams stolpern. OpenLLMetry liefert die Instrumentierung, sonst nichts. Es gibt kein mitgeliefertes Dashboard, keine Speicherung, keine Suche über eure Traces. Die Spans müssen irgendwohin, und dieses Irgendwohin müsst ihr selbst stellen.

In der Praxis heißt das: Ihr braucht ein OTel-kompatibles Backend. Das kann Datadog oder Grafana Tempo sein, wenn ihr eure Observability-Landschaft konsolidieren wollt. Oder ein LLM-spezialisiertes Backend, wenn ihr Prompt-Level-Analysen und Evaluierungen braucht.

Wer eine echte All-in-One-Alternative sucht, bei der Instrumentierung und Dashboard aus einer Hand kommen, sollte sich parallel Opik als LLM-Observability-Plattform ansehen. Der teurere Weg ist, das erst nach dem Rollout zu merken und dann ein Backend nachzurüsten, während die Traces schon ins Leere laufen.

Standard schlägt Insellösung: wann OpenLLMetry die richtige Wahl ist

Die Entscheidung ist keine Glaubensfrage, sondern hängt an eurem Reifegrad. Wir raten zu OpenLLMetry plus eigenem OTel-Backend, wenn ihr bereits eine Observability-Kultur habt: Wenn Grafana, Datadog oder ein OTel-Collector im Haus laufen, ist es fachlich falsch, für LLMs eine zweite, isolierte Welt aufzumachen. Dann gewinnt der Standard.

Zur All-in-One-Plattform greift, wer heute noch keine Observability-Basis hat und schnell Prompt-Level-Sichtbarkeit braucht, ohne erst ein Backend zu betreiben. Das ist legitim, kostet aber Flexibilität, sobald ihr wachst.

Der eigentliche Hebel liegt in der Governance. Weil OpenLLMetry OpenTelemetry spricht, könnt ihr Telemetrie-Regeln zentral durchsetzen: welche Felder maskiert werden, wie lange Prompts gespeichert bleiben, wer sie sehen darf. Eine proprietäre Insel gibt euch diese Kontrolle selten in der Tiefe. Für regulierte Umgebungen ist das der entscheidende Unterschied, und der Grund, warum wir Standard vor Komfort stellen.

Der Vollständigkeit halber: OpenLLMetry ist quelloffen und öffentlich einsehbar unter github.com/traceloop/openllmetry – prüft Instrumentierungs-Abdeckung und Release-Stand dort direkt, bevor ihr euch festlegt.

Häufig gestellte Fragen

Braucht OpenLLMetry zwingend ein separates Backend?

Ja. OpenLLMetry ist reine Instrumentierung und bringt weder Dashboard noch Speicherung mit. Die erzeugten OpenTelemetry-Spans müssen an ein OTel-kompatibles Backend wie Datadog, Grafana Tempo oder ein LLM-spezialisiertes Ziel gesendet werden. Ohne dieses Backend seht ihr eure Traces nicht.

Was kostet der Einsatz von OpenLLMetry?

Die Bibliothek selbst ist unter Apache-2.0 kostenlos und ohne Lizenzgebühr nutzbar. Die realen Kosten entstehen im Backend und Betrieb: Speicherung, Rechenzeit und Pflege. Wer ein bestehendes OTel-Backend hat, zahlt fast nichts extra, wer eins aufbauen muss, sollte diesen Aufwand von Anfang an einplanen.

Worin unterscheidet sich OpenLLMetry von einer All-in-One-Plattform?

OpenLLMetry ist vendor-neutrale Instrumentierung auf OpenTelemetry-Basis, ohne Anbieterbindung, aber ohne eigenes Backend. Eine All-in-One-Plattform bringt Instrumentierung und Dashboard zusammen, bindet euch aber an ihr Format. Der Kompromiss ist Flexibilität gegen anfänglichen Komfort.

Erzeugt OpenLLMetry Lock-in?

Nein, das ist gerade sein Kernargument. Weil es standardkonforme OpenTelemetry-Daten erzeugt, könnt ihr das Backend jederzeit wechseln, ohne die Instrumentierung anzufassen. Der Lock-in-Punkt verschiebt sich weg vom Anbieter hin zu einer bewussten, austauschbaren Backend-Entscheidung.

Passt OpenLLMetry in eine bestehende Observability-Landschaft?

Genau dafür ist es gemacht. Wenn ihr bereits einen OpenTelemetry-Collector oder ein OTel-fähiges Backend betreibt, fügt sich OpenLLMetry ohne parallele Insel-Infrastruktur ein. LLM-Traces landen dann im selben System wie eure übrige Anwendungstelemetrie.

Nächster Schritt

Wenn ihr entscheiden wollt, ob der offene Standard oder eine Plattform besser zu eurem Stack passt, sprecht mit uns über eure konkrete Observability-Landschaft.

Verwandte Themen