LLM Observability in Produktion: So überwachen Sie KI-Anwendungen, RAG-Pipelines und Agenten

LLM Observability macht jeden Modellaufruf in Ihrer Anwendung messbar und nachvollziehbar: was hineinging, was herauskam, wie lange es dauerte, wie viele Tokens verbraucht wurden, was es kostete und ob die Antwort überhaupt brauchbar war. Klassisches Application Monitoring meldet Ihnen, dass ein Endpunkt in 1,8 Sekunden mit HTTP 200 geantwortet hat. Es sagt Ihnen nicht, dass die Antwort halluziniert war, dass der Retrieval-Schritt die falschen Dokumente geliefert hat oder dass ein Agent elfmal dasselbe Tool aufgerufen hat, bevor er aufgab.

Dieser Leitfaden ist eine praxisnahe Vorlage für Teams, die KI-Anwendungen in Produktion überwachen wollen. Er zeigt, welche Signale Sie erfassen sollten, wie Sie LLM-Aufrufe, RAG-Pipelines und Tool-Aufrufe von Agenten mit OpenTelemetry tracen, wie Sie Qualitätssignale und Guardrails ergänzen, welche Dashboards und Alerts sich lohnen und wie Token-Kosten planbar bleiben. Am Ende finden Sie eine Checkliste zum Kopieren und eine Metrik-Tabelle als Ausgangspunkt für Ihr Alerting. Falls Sie neu im Thema sind, erklärt unser Grundlagenartikel Was ist LLM Observability? zunächst die Begriffe.

Warum LLM-Anwendungen eigene Observability brauchen

Eine LLM-Funktion verhält sich in vier Punkten anders als ein typischer Microservice, und jeder davon verändert, was Sie beobachten müssen:

• Nicht-deterministische Ausgaben: Dieselbe Eingabe kann unterschiedliche Antworten erzeugen. Eine erfolgreiche Antwort ist nicht automatisch eine richtige, deshalb brauchen Sie neben Statuscodes auch Qualitätssignale.
• Nutzungsabhängige Kosten pro Anfrage: Jeder Aufruf wird nach Input- und Output-Tokens abgerechnet. Eine Prompt-Änderung, ein größeres Kontextfenster oder ein Agent in einer Schleife kann die Rechnung vervielfachen, ohne dass ein einziger Fehler auftritt.
• Externe Abhängigkeiten mit eigenen Grenzen: Die meisten Teams nutzen gehostete Modell-APIs mit Rate Limits, Kontingenten, regionalen Ausfällen und stillen Modell-Updates. Ihre Zuverlässigkeit hängt an einem Anbieter, den Sie nicht steuern.
• Mehrstufige Abläufe: Eine einzige Nutzerfrage kann einen Embedding-Aufruf, eine Vektorsuche, ein Re-Ranking, mehrere Modellaufrufe und eine Kette von Tool-Aufrufen auslösen. Ohne Tracing sehen Sie nicht, welcher Schritt langsam, teuer oder falsch war.

Die gute Nachricht: Sie brauchen kein separates KI-Silo. Am nützlichsten ist ein Setup, das LLM-Aufrufe als vollwertige Spans und Metriken in derselben Telemetrie-Pipeline behandelt wie den Rest Ihres Stacks. So verfolgen Sie eine langsame Chatbot-Antwort vom Browser über Ihre API bis zum Modellanbieter und zurück.

Was Sie von jedem LLM-Aufruf erfassen sollten

Beginnen Sie mit einem einheitlichen Datensatz pro Modellaufruf. Diese Felder sind in der Praxis entscheidend:

Prompts und Antworten, mit Datenschutzkontrollen

Prompt- und Antwortinhalte sind die wertvollsten und zugleich sensibelsten Daten, die Sie erfassen. Für die Fehlersuche bei schlechten Antworten sind sie unverzichtbar, enthalten aber häufig personenbezogene Daten, Geschäftsgeheimnisse oder interne Dokumente. Behandeln Sie die Erfassung von Inhalten als bewusste Entscheidung: In Entwicklung und Staging vollständig, in Produktion entweder gesampelt, mit maskierten personenbezogenen Daten oder in einem separaten Speicher mit kürzerer Datenaufbewahrung und strengeren Zugriffsrechten. Die GenAI-Konventionen von OpenTelemetry spiegeln das wider: Attribute mit Nachrichteninhalten sind Opt-in und werden standardmäßig nicht aufgezeichnet.

Token-Verbrauch und Kosten

Erfassen Sie pro Aufruf Input-Tokens, Output-Tokens und, sofern der Anbieter sie meldet, gecachte Tokens. Die Kosten leiten Sie aus einer Preistabelle ab, die Sie gemeinsam mit Ihrem Code versionieren, denn Preise ändern sich. Ergänzen Sie fachlichen Kontext wie Funktion, Mandant oder Team, damit Sie die Frage „Welche Funktion kostet wie viel pro Tag?“ ohne Tabellenkalkulation beantworten können.

Latenz, einschließlich Time to First Token

Bei gestreamten Antworten ist die Gesamtdauer nur die halbe Wahrheit. Nutzer empfinden die Time to First Token (TTFT) als Reaktionsgeschwindigkeit, während die Zeit pro Output-Token bestimmt, wie schnell sich die Antwort aufbaut. Erfassen Sie beides als Histogramm, zusammen mit der Gesamtdauer, und arbeiten Sie mit Perzentilen statt mit Durchschnittswerten.

Fehler, Rate Limits und Retries

Unterscheiden Sie Fehlertypen: Rate-Limit-Antworten, ausgeschöpfte Kontingente, Timeouts, Ablehnungen durch Inhaltsfilter, ungültige Anfragen und Serverfehler beim Anbieter erfordern jeweils eine andere Reaktion. Halten Sie Retries und Fallbacks explizit fest. Eine Anfrage, die im dritten Versuch mit einem Ersatzmodell gelang, ist kein sauberer Erfolg.

Modell- und Anbieterversionen

Erfassen Sie Anbieter, angefragtes Modell und die Modellversion, die der Anbieter in der Antwort tatsächlich zurückmeldet. Beides ist nicht immer identisch, und stille Modell-Updates gehören zu den häufigsten Ursachen für Qualitätsänderungen, die niemand erklären kann. Ergänzen Sie außerdem die Version Ihres Prompt-Templates, damit Sie Regressionen mit Prompt-Deployments in Verbindung bringen können.

LLM-Aufrufe, RAG-Pipelines und Agenten mit OpenTelemetry tracen

OpenTelemetry ist die naheliegende Grundlage für AI Observability, weil Sie Modellaufrufe mit denselben SDKs, derselben Context Propagation und denselben Collectors instrumentieren, die Sie bereits für Ihre Services nutzen. Jeder Modellaufruf wird zu einem Span im Trace der Nutzeranfrage.

GenAI Semantic Conventions: aktueller Stand

OpenTelemetry definiert Semantic Conventions für generative KI, mit Spans, Metriken und Events für Modellaufrufe, Agenten und Tools. Stand Oktober 2026 verweist die Dokumentation auf opentelemetry.io auf ein eigenes Repository für die GenAI Semantic Conventions, und die Konventionen dort tragen den Status Development. Namen und Attribute können sich also noch ändern. Nutzen Sie sie trotzdem, denn sie sind das beste gemeinsame Vokabular, das es gibt. Pinnen Sie aber die Versionen Ihrer Instrumentierungsbibliotheken und rechnen Sie bei Upgrades mit umbenannten Attributen.

Diese Attribute sollten Sie einheitlich verwenden:

• gen_ai.operation.name für die Art der Operation, etwa Chat, Embeddings, Retrieval, invoke_agent oder execute_tool
• gen_ai.provider.name, gen_ai.request.model und gen_ai.response.model für Anbieter und Modell
• gen_ai.usage.input_tokens und gen_ai.usage.output_tokens für Token-Zahlen
• gen_ai.response.finish_reasons und error.type für Ergebnis und Fehler
• Opt-in-Inhaltsattribute wie gen_ai.input.messages und gen_ai.output.messages, nur wenn Ihre Datenschutzregeln es zulassen

Die Konventionen definieren außerdem Metriken wie gen_ai.client.operation.duration und für Modellserver gen_ai.server.time_to_first_token. Prüfen Sie die aktuelle Spezifikation, bevor Sie Dashboards auf exakte Metriknamen aufbauen.

Eine RAG-Pipeline tracen

Bei Retrieval-Augmented Generation erhält jede Stufe einen eigenen Span: Embedding der Anfrage, Vektorsuche, Re-Ranking, Zusammenbau des Prompts und der finale Modellaufruf. Am Retrieval-Span erfassen Sie die Zahl der gefundenen Dokumente, die Datenquelle und die Latenz, außerdem Dokument-IDs statt vollständiger Texte. Meldet ein Nutzer eine falsche Antwort, zeigt dieser Trace, ob das Problem im Retrieval (falscher Kontext) oder in der Generierung (richtiger Kontext, falsche Antwort) lag. Beides beheben Sie an völlig unterschiedlichen Stellen.

Agenten und Tool-Aufrufe tracen

Agenten arbeiten in Schleifen: planen, Tool aufrufen, Ergebnis lesen, neu entscheiden. Bilden Sie jeden Agentenlauf als Eltern-Span ab und jeden Modellaufruf sowie jede Tool-Ausführung als Kind-Span. Erfassen Sie Tool-Name, Ergebnis und Zahl der Iterationen. So werden außer Kontrolle geratene Agenten sofort sichtbar: Ein Trace mit vierzig Tool-Aufrufen und einem Timeout erzählt mehr als jede Logzeile.

Sampling und Datenvolumen

LLM-Traces sind vergleichsweise selten, aber wertvoll und groß, besonders mit Inhaltsattributen. Entscheiden Sie das Sampling bewusst: Behalten Sie alle Traces mit Fehlern, hohen Kosten oder negativem Feedback und sampeln Sie den Rest. Tail-based Sampling im OpenTelemetry Collector eignet sich dafür gut. Wie Sie solche Regeln konfigurieren, zeigt unser Leitfaden zu Tail-based Sampling.

Qualitätssignale: Evals, Halluzinationsprüfungen und Nutzerfeedback

Betriebsmetriken zeigen, dass die Funktion läuft. Qualitätssignale zeigen, ob sie nützt. Kombinieren Sie drei Quellen:

• Offline-Evals: ein fester Testsatz repräsentativer Fragen mit erwarteten Antworten oder Bewertungskriterien, der bei jeder Prompt- oder Modelländerung vor dem Release läuft. Behandeln Sie sinkende Eval-Werte wie einen fehlgeschlagenen Test.
• Online-Evals: automatische Prüfungen auf einer Stichprobe des Produktionsverkehrs, etwa Groundedness gegenüber dem abgerufenen Kontext, Relevanz der Antwort, Formatprüfung oder eine Bewertung per LLM-as-Judge. Speichern Sie den Wert als Attribut oder Event am ursprünglichen Trace, damit Sie von einer schlechten Bewertung direkt zur Anfrage springen können.
• Nutzerfeedback: Daumen hoch oder runter, Korrekturen, erneutes Generieren, kopierte Antworten und abgebrochene Sitzungen. Implizite Signale sind oft ehrlicher als explizite Bewertungen.

Bei Halluzinationsprüfungen ist Vorsicht angebracht: Keine automatische Prüfung erkennt jede erfundene Antwort. Groundedness-Werte gegenüber dem abgerufenen Kontext sind für RAG-Anwendungen ein brauchbarer Indikator, sollten aber eine Prüfung auslösen und nicht ersetzen. Beobachten Sie den Verlauf über die Zeit und pro Prompt-Version, statt sich auf einen einzelnen Schwellenwert zu verlassen.

Guardrails und personenbezogene Daten: beobachten, ohne neues Risiko zu schaffen

Prompts schreiben Nutzer, und Nutzer fügen alles ein: E-Mail-Adressen, Vertragstexte, Gesundheitsdaten, Zugangstoken. Wer Prompts unbedacht erfasst, macht sein Observability-Backend zur am schlechtesten geschützten Kopie seiner sensibelsten Daten. Drei Maßnahmen helfen:

1. Vor der Speicherung maskieren: Erkennen und maskieren Sie personenbezogene Daten in der Telemetrie-Pipeline, bevor sie das Backend erreichen, und nicht erst nachträglich in der Oberfläche.
2. Inhalte von Metadaten trennen: Tokens, Latenz, Modell und Fehler dürfen breit verfügbar sein. Den Zugriff auf Prompt- und Antwortinhalte beschränken Sie auf die Personen, die ihn für die Fehlersuche brauchen.
3. Die Guardrails selbst beobachten: Protokollieren Sie, wann Eingabe- oder Ausgabefilter eine Anfrage blockieren, umschreiben oder markieren, und welche Regel gegriffen hat. Ein plötzlicher Anstieg blockierter Prompts kann auf Missbrauch, einen Prompt-Injection-Versuch oder einen falsch konfigurierten Filter hindeuten.

Dashboards und Alerts für KI-Funktionen

Bauen Sie ein Dashboard pro KI-Funktion, nicht pro Modell. Ein Product Owner will wissen, ob der Support-Assistent gesund ist, nicht wie sich ein bestimmter Modell-Endpunkt verhält. Bewährt hat sich ein Aufbau mit Traffic, Fehlerrate nach Typ, Latenz-Perzentilen inklusive TTFT, Tokens und Kosten pro Anfrage, Eval-Werten und Feedback-Quote. Schlüsseln Sie nach Modell- und Prompt-Version auf und achten Sie auf die Kardinalität: Nutzer-IDs oder Prompt-Texte gehören niemals in Metrik-Labels.

Die folgende Tabelle ist ein Ausgangspunkt für Ihr Alerting. Die Schwellenwerte sind Beispiele und müssen an Ihren Traffic und Ihre Baselines angepasst werden.

Metrik	Warum sie wichtig ist	Typischer Alert (Beispiel)
Fehlerrate nach Fehlertyp	Trennt eigene Bugs von Anbieterausfällen und Filterablehnungen	Fehlerrate über 5 % für 10 Minuten bei einer nutzerseitigen Funktion
Rate-Limit- und Kontingent-Antworten	Frühes Zeichen, dass der Traffic die Anbietergrenzen übersteigt	Anhaltende Rate-Limit-Antworten über 5 Minuten
Time to First Token (p95)	Bestimmt die gefühlte Reaktionszeit gestreamter Antworten	p95-TTFT über dem Doppelten der 7-Tage-Baseline für 15 Minuten
Gesamtdauer (p95, p99)	Erkennt langsames Retrieval, lange Ausgaben und Agentenschleifen	p99 über dem Timeout-Budget der Anfrage
Tokens pro Anfrage	Zeigt aufgeblähte Prompts, wachsenden Kontext und ausufernde Ausgaben	Median der Input-Tokens nach einem Deployment um mehr als 30 % gestiegen
Kosten pro Stunde und Funktion	Schützt das Budget vor Schleifen und Missbrauch	Stündliche Kosten über Prognose oder Tagesbudget zu 80 % verbraucht
Agenten-Iterationen pro Lauf	Erkennt Schleifen und Tools, die nie erfolgreich sind	Mehr als 2 % der Läufe erreichen das Iterationslimit
Retrieval-Trefferzahl und -Latenz	Leeres oder langsames Retrieval führt zu schlechten Antworten	Anteil der Retrievals ohne Treffer über der Baseline
Online-Eval-Wert	Qualitätsverluste erzeugen keine Fehler	Gleitender Groundedness-Wert fällt unter die Release-Schwelle
Quote negativen Feedbacks	Das direkteste Signal für sichtbare Qualität	Quote verdoppelt sich gegenüber der Vorwoche
Blockierquote der Guardrails	Hinweis auf Missbrauch, Prompt Injection oder Fehlkonfiguration	Blockierquote über dem Dreifachen der Baseline für 30 Minuten

Fassen Sie die wichtigsten Signale nach Möglichkeit in Service Level Objectives, zum Beispiel „99 % der Antworten des Support-Assistenten beginnen innerhalb von 2 Sekunden zu streamen“, und alarmieren Sie auf die Burn Rate statt auf statische Schwellen. So bleibt die Rufbereitschaft für KI-Funktionen konsistent mit Ihrem übrigen SLO-Monitoring.

Kostenkontrolle für LLM-Workloads

Token-Kosten wachsen mit Nutzung, Prompt-Länge und Ausgabelänge und werden deshalb leicht unterschätzt. Observability macht aus der monatlichen Überraschung eine Kennzahl, auf die Sie reagieren können:

• Kosten zuordnen: Versehen Sie jeden Aufruf mit Funktion, Team und Mandant und berichten Sie Kosten pro Anfrage und pro erfolgreichem Ergebnis, nicht nur als Gesamtsumme.
• Prompt-Wachstum beobachten: System-Prompts, Few-Shot-Beispiele und abgerufener Kontext wachsen mit der Zeit. Verfolgen Sie die Input-Tokens pro Anfrage je Prompt-Version.
• Caching und kleinere Modelle gezielt einsetzen: Messen Sie Cache-Trefferquoten und vergleichen Sie Qualität und Kosten, wenn Sie einfache Anfragen an kleinere Modelle leiten. Ohne Eval-Werte neben den Kosten wissen Sie nicht, ob das günstigere Modell gut genug ist.
• Agenten begrenzen: Setzen Sie Iterationslimits und Token-Budgets pro Lauf und alarmieren Sie, wenn Läufe sie erreichen.
• Auch die Telemetriekosten steuern: Inhaltsattribute machen Traces groß. Filtern, kürzen und sampeln Sie in der Pipeline vor der Speicherung.

Checkliste für LLM Observability

Übernehmen Sie diese Checkliste in Ihren Rollout-Plan oder Ihr Architektur-Review:

Checkliste LLM Observability

Instrumentierung
[ ] Jeder Modellaufruf ist ein Span im Trace der Nutzeranfrage
[ ] Anbieter, angefragtes und geantwortetes Modell sind erfasst
[ ] Version des Prompt-Templates an jedem Aufruf erfasst
[ ] Input-, Output- und gecachte Tokens pro Aufruf erfasst
[ ] Kosten aus einer versionierten Preistabelle abgeleitet
[ ] TTFT, Zeit pro Output-Token und Gesamtdauer als Histogramm
[ ] Fehlertyp, Retries und Fallbacks explizit erfasst
[ ] RAG-Stufen (Embedding, Retrieval, Re-Ranking, Generierung) mit eigenen Spans
[ ] Agentenläufe als Eltern-Span, Tool-Aufrufe als Kind-Spans
[ ] Versionen der GenAI Semantic Conventions gepinnt und dokumentiert

Datenschutz und Guardrails
[ ] Regeln zur Inhaltserfassung mit dem Datenschutz abgestimmt
[ ] Personenbezogene Daten in der Pipeline vor der Speicherung maskiert
[ ] Inhalte mit kürzerer Aufbewahrung und eingeschränktem Zugriff
[ ] Guardrail-Entscheidungen mit auslösender Regel protokolliert

Qualität
[ ] Offline-Evals laufen bei jeder Prompt- oder Modelländerung
[ ] Online-Evals bewerten eine Stichprobe des Produktionsverkehrs
[ ] Eval-Werte und Nutzerfeedback mit Trace-IDs verknüpft

Betrieb
[ ] Ein Dashboard pro KI-Funktion, nach Modell- und Prompt-Version aufgeschlüsselt
[ ] Alerts auf Fehler, Rate Limits, TTFT, Kosten und Agentenschleifen
[ ] Mindestens ein SLO für Latenz oder Verfügbarkeit der Funktion
[ ] Tagesbudget für Kosten mit Alert bei 80 %
[ ] Sampling behält alle fehlerhaften, teuren und negativ bewerteten Traces
[ ] Runbook für Anbieterausfall und Rate Limiting (Ersatzmodell)

Wie Obseria unterstützt

Obseria ist eine OpenTelemetry-native Observability-Plattform. LLM-Spans und -Metriken aus Standard-Instrumentierungsbibliotheken landen deshalb in denselben Traces wie Ihre Services, Datenbanken und Frontends. AI Observability in Obseria umfasst Modellaufrufe, Token-Verbrauch, Kosten und Latenz pro Funktion. Der Rest der Plattform liefert SLOs, Alerting und Incident Management für KI-Funktionen an derselben Stelle wie für alles andere.

• Die Obseria Pipeline maskiert personenbezogene Daten, kürzt Inhalte und sampelt vor der Speicherung, mit Datenhaltung in der EU.
• Obseria Intelligence und der KI-SRE-Agent korrelieren Latenz- oder Fehlerspitzen bei LLM-Aufrufen mit Deployments, Anbieterproblemen und Infrastrukturänderungen, jeweils mit Belegen.
• Über den MCP-Server können Ihre eigenen KI-Assistenten Telemetrie, Traces und Incidents direkt abfragen.

Wenn Sie Ihre eigenen Modellaufrufe durchgängig getraced sehen möchten, starten Sie eine kostenlose Testphase und verbinden Sie Ihre bestehende OpenTelemetry-Instrumentierung.