OpenTelemetry hat sich in den vergangenen Jahren als De-facto-Standard für die Instrumentierung verteilter Systeme etabliert. Wer Microservices, Serverless-Funktionen oder komplexe API-Chains betreibt, nutzt OTel für Traces, Metriken und Logs – und sendet diese an Backends wie Grafana Tempo, Jaeger, Honeycomb oder Elastic APM.
Doch mit der raschen Verbreitung von LLM-basierten Anwendungen entsteht ein neues Instrumentierungsproblem: Wie misst man ein System, dessen wichtigste Operationen nicht mehr klassische Funktionsaufrufe sind, sondern Sprachmodell-Anfragen mit variablen Eingaben, nicht-deterministischen Ausgaben und komplexen Agenten-Workflows? OpenTelemetry gibt darauf inzwischen strukturierte Antworten – und ein wachsendes Ökosystem macht die Umsetzung zunehmend praktisch.
Warum klassische APM-Konzepte bei LLMs nicht ausreichen
Ein klassischer HTTP-Request hat eine klare Struktur: Eingabe, Verarbeitung, Ausgabe, Latenz, Fehlercode. Für ein LLM-basiertes System ist das deutlich komplexer. Ein einziger User-Prompt kann mehrere Modell-Aufrufe auslösen, Tool-Calls triggern, externe APIs ansprechen, Retrieval-Operationen über eine Vektordatenbank durchführen und schließlich eine strukturierte oder unstrukturierte Antwort zurückliefern. Jeder dieser Schritte hat eigene Latenzkennzahlen, eigene Fehlertypen und eigene Kostenimplikationen.
Hinzu kommt die Tokens-Dimension: Anders als Bytes bei klassischen Requests sind Tokens bei LLMs die eigentliche Kostengröße. Ein Trace, der nicht erfasst, wie viele Input- und Output-Tokens pro Aufruf verbraucht wurden, liefert ein unvollständiges Bild und macht eine sinnvolle Kostensteuerung unmöglich.
OpenTelemetry Semantic Conventions für LLMs
Die OpenTelemetry-Community hat begonnen, semantische Konventionen speziell für KI- und LLM-Systeme zu definieren. Diese Konventionen sind noch in der Experimental-Phase, aber bereits praxistauglich und werden aktiv von den wichtigsten Instrumentierungsbibliotheken umgesetzt. Sie definieren, welche Attribute ein Span tragen soll, wenn er einen LLM-Aufruf repräsentiert:
gen_ai.system– der verwendete KI-Anbieter (z. B.openai,anthropic,google_vertex_ai)gen_ai.request.model– das angeforderte Modellgen_ai.response.model– das tatsächlich verwendete Modell (kann abweichen)gen_ai.usage.input_tokens/gen_ai.usage.output_tokens– Token-Verbrauchgen_ai.operation.name– Art der Operation (chat,text_completion,embeddings)gen_ai.request.temperature– verwendete Temperatureinstellung
Diese standardisierten Attribute erlauben es, LLM-Calls systemübergreifend vergleichbar zu machen – unabhängig davon, ob das System GPT-4o, Claude oder ein lokal gehostetes Open-Source-Modell verwendet.
Agenten-Traces: Mehrschichtige Workflows sichtbar machen
Für einfache LLM-Calls reicht ein einzelner Span. Für Agenten-Workflows – also Systeme, die mehrere Tool-Calls, Retrieval-Schritte, Sub-Agenten und Entscheidungsschleifen enthalten – braucht es verschachtelte Spans. OpenTelemetry bietet dafür die Standard-Mechanik: Parent-Spans mit Child-Spans, die den Gesamtworkflow sauber abbilden.
Ein typischer Agenten-Trace in einem modernen KI-System könnte so aussehen:
- Root Span:
agent.run– Gesamtworkflow, enthält alle Kind-Spans - Child Span:
llm.call– initiale Anfrage an das Sprachmodell - Child Span:
tool.call.search– Vektordatenbankabfrage für Kontext-Retrieval - Child Span:
tool.call.api– externer API-Call zur Datenbeschaffung - Child Span:
llm.call– abschließende Synthese der gesammelten Informationen
Diese Struktur macht es möglich, auf einen Blick zu sehen, wo ein langsamer Agentendurchlauf tatsächlich Zeit verliert: Liegt es am Modell-Aufruf selbst, an der Vektordatenbankabfrage oder am externen API-Timeout? Ohne diese Transparenz sind KI-Systeme in der Produktion kaum reproduzierbar zu optimieren.
Praktische Implementierung: Einstieg mit Bibliotheken
Für Teams, die OpenTelemetry für LLM-Systeme einführen wollen, gibt es inzwischen gute Einstiegspunkte. Bibliotheken wie OpenLLMetry (Traceloop), OpenInference (Arize AI) und das offizielle OTel-SDK bieten Auto-Instrumentierung für die gängigen LLM-Frameworks (LangChain, LlamaIndex, Autogen, CrewAI, das Anthropic SDK). Der typische Setup-Aufwand liegt bei unter einem Arbeitstag für ein funktionierendes Basis-Setup.
Die grundlegenden Schritte:
- OTel-SDK initialisieren mit einem OTLP-Exporter, der auf das gewünschte Backend zeigt (Grafana Tempo, Honeycomb, Jaeger etc.)
- Auto-Instrumentierung aktivieren – LangChain-Traces werden dann automatisch mit korrekten Gen-AI-Attributen versehen
- Custom Spans für eigene Logik – Bereiche ohne automatische Instrumentierung (eigene Retrieval-Logik, Caching-Layer, Business-Logik) manuell mit Spans versehen
- Token-Metriken aggregieren – monatliche Kosten können direkt aus den aggregierten Trace-Daten abgeleitet werden, ohne Umweg über Billing-APIs
Was man messen sollte – und was nicht
Nicht jede Metrik ist gleich wertvoll. Die wichtigsten Key Performance Indicators für LLM-Systeme in der Produktion sind:
- Time to First Token (TTFT) – besonders relevant für Streaming-Anwendungen und interaktive Assistenten
- Total-Latenz pro Agenten-Run – Gesamtdauer eines vollständigen Agenten-Workflows
- Token-Effizienz – Output-Tokens im Verhältnis zu Input-Tokens als indirekter Qualitätsindikator
- Error Rate – Rate fehlgeschlagener LLM-Calls, Tool-Call-Fehler, Timeouts und Rate-Limit-Treffer
- Kosten pro Anfrage – aus Token-Verbrauch direkt kalkulierbar, ermöglicht frühzeitige Budgetprognosen
Was man nicht unkritisch in Produktionstraces speichern sollte: die vollständigen Prompt-Texte und Modellantworten als Raw-Data. Das ist ein Datenschutzproblem und in regulierten Umgebungen oft unzulässig. Stattdessen: Prompt-Template-IDs, Variablenkeys und Antwortklassifizierungen – keine sensiblen Rohdaten.
Observability für KI-Systeme bei FreshCore-Umgebungen
Für Teams, die KI-gestützte Automatisierungen betreiben, ergibt sich eine natürliche Integration: Wenn ein KI-Agent auf Monitoring-Signale reagiert – zum Beispiel einen Heartbeat-Ausfall analysiert und einen Runbook-Schritt ausführt – sollte dieser Agenten-Lauf als Trace erfasst werden. So entsteht ein vollständiges Bild: vom ursprünglichen Monitoring-Alarm über die Agenten-Entscheidung bis zur ausgeführten Aktion und dem Ergebnis.
Diese Ende-zu-Ende-Sichtbarkeit ist der Unterschied zwischen einem KI-System, das man versteht, und einem, dem man vertrauen muss. Für produktive Umgebungen ist nur ersteres akzeptabel.
Fazit: Observability für KI ist keine Kür
KI-Systeme in der Produktion zu betreiben ohne Observability-Daten ist wie ein Flugzeug ohne Instrumentenpanel zu fliegen: Es funktioniert, bis etwas schiefgeht. OpenTelemetry liefert das gemeinsame Framework, um LLM-Calls, Agenten-Workflows und Tool-Integrationen mit denselben Werkzeugen zu beobachten, die Teams bereits für klassische Backend-Systeme einsetzen.
Der Mehrwert liegt dabei nicht nur in der Fehleranalyse, sondern auch in der Kostensteuerung und der kontinuierlichen Qualitätsverbesserung. Wer weiß, welche Agenten-Pfade am häufigsten genutzt werden und welche am meisten kosten, kann gezielt optimieren – und damit aus KI-Experimenten echte, produktionsreife Systeme machen.
Quellen: OpenTelemetry Semantic Conventions for Generative AI (opentelemetry.io), OpenLLMetry by Traceloop (GitHub), Arize AI OpenInference Specification, CNCF Observability TAG Whitepaper.
