Observability für AI Agents: Tracing, Metriken, Logs und Evals

AI Agent Observability macht das Innenleben eines autonomen Agenten sichtbar: über Tracing (Spans über Reasoning- und Tool-Calls), Metriken (Latenz, Token, Kosten, Erfolgsrate), strukturierte Logs und kontinuierliche Evals. Sie beantwortet, warum ein Agent so entschieden hat, und ist die Voraussetzung, um Multi-Step-Agenten in Produktion überhaupt debuggen, absichern und auditieren zu können.

Anders als ein klassischer Webservice trifft ein Agent nicht eine Anfrage-Antwort-Entscheidung, sondern durchläuft pro Aufgabe mehrere Reasoning-Runden mit zwischengeschalteten Werkzeug-Aufrufen. Genau diese Mehrstufigkeit macht herkömmliches Monitoring blind: Ein HTTP-200 sagt nichts darüber, ob das richtige Tool mit den richtigen Argumenten aufgerufen wurde oder ob das Modell auf halbem Weg falsch abgebogen ist.

Die drei Kernpunkte vorab:

• Observability für Agenten besteht aus vier Säulen. Tracing, Metriken, Logs und Evals. Sie greifen ineinander: Der Trace liefert den Pfad, Metriken liefern die Aggregation, Logs liefern den Kontext, Evals liefern das Qualitätsurteil.
• Ohne Tracing sind Agenten un-debugbar. Nur ein hierarchischer Trace über alle Reasoning- und Tool-Call-Spans zeigt, an welchem Schritt eine mehrstufige Kette gebrochen ist.
• Datenresidenz ist Pflicht-Kriterium. Da Traces Prompts und Antworten, also potenziell Kundendaten, enthalten, ist das Observability-Backend für DACH-B2B selbst ein Compliance-Objekt (Langfuse self-hosted in der EU, Datadog EU, Honeycomb EU).

Warum Agenten ohne Tracing un-debugbar sind

Ein Agent ist nicht-deterministisch. Dieselbe Anfrage kann zu unterschiedlichen Tool-Aufrufen, unterschiedlich vielen Reasoning-Runden und unterschiedlichen Ergebnissen führen. Wenn ein Lauf scheitert oder eine fachlich falsche Antwort produziert, gibt es ohne Tracing keine belastbare Möglichkeit, die Ursache zu isolieren. Mögliche Fehlerquellen in einer einzigen Anfrage:

• Das LLM hat falsch reasoniert und ein unpassendes Tool gewählt.
• Das Tool wurde mit fehlerhaften Argumenten aufgerufen.
• Der Retrieval-Schritt (RAG) hat die falschen Dokumente gezogen.
• Ein Guardrail- oder PII-Filter hat eingegriffen und den Kontext verändert.
• Eine Modellversion hat sich serverseitig geändert (managed APIs aktualisieren Modelle nach dem Zeitplan des Anbieters).

Ein flaches Output-Log unterscheidet diese Fälle nicht. Tracing macht jeden dieser Schritte als eigenen, zeitlich und kausal eingeordneten Span sichtbar. Damit verschiebt sich Debugging von „Raten anhand des Endergebnisses" zu „den konkreten Span finden, der gebrochen ist". Architektonisch gilt dasselbe: Service-Meshes liefern Observability auf Netzwerkebene, und Agenten-Stacks aus vielen Microservices (Orchestrator, Tool-Server, Memory-Store, Vector-DB, Retrieval-Service, Guardrail-Service) sind nur mit einer durchgängigen Observability-Schicht beherrschbar.

Die vier Säulen der Agenten-Observability

Tracing: Spans über Reasoning und Tool-Calls

Ein Trace bildet eine komplette Agenten-Anfrage als Baum ab. Der Root-Span umfasst die gesamte Anfrage; darunter hängen verschachtelte Spans für jeden LLM-Aufruf, jeden Tool-Call, jeden Retrieval-Schritt und jede Guardrail-Prüfung. Jeder Span trägt Ein- und Ausgaben sowie Attribute wie Modellname, Prompt- und Completion-Tokens, Latenz und, abgeleitet, Kosten. Diese hierarchische Struktur ist der entscheidende Unterschied zum klassischen, flachen Request-Log.

Metriken: Latenz, Token, Kosten, Erfolgsrate

Metriken aggregieren über viele Traces hinweg. Vier Signale bilden den Kern:

• Latenz, End-to-End und pro Tool-Call-Runde. Zwischen den Azure-Regionen Germany West Central (Frankfurt) und East US misst Microsoft einen Median von 94 ms Round-Trip (Azure-Latenzstatistik, Stand Juli 2026). Ein Agent in Frankfurt, der eine API in US-Ost aufruft, zahlt diese Zeit bei jedem Aufruf. Bei mehreren Tool-Runden summiert sie sich.
• Token (Prompt und Completion) je Span als Grundlage der Kostenattribution.
• Kosten pro Anfrage, pro Team und pro Use-Case.
• Erfolgsrate, der Anteil korrekt abgeschlossener Aufgaben.

Logs: strukturierter Kontext

Strukturierte Logs ergänzen Spans um Detailkontext: Tool-Rohantworten, Retry-Versuche, Guardrail-Auslösungen, abgeschnittene Kontexte. Wichtig ist die Korrelation: Jeder Log-Eintrag sollte über die Trace-ID einem konkreten Span zuordenbar sein, sonst entsteht wieder ein blinder Fleck.

Evals: Qualität als Teil von Observability

Evals sind das Signal, das reines Tracing nicht liefert: die systematische Bewertung der Ausgabequalität. Bewertet werden typischerweise Erfolgsrate, Tool-Call-Korrektheit (wurde das richtige Tool mit den richtigen Argumenten aufgerufen?) und Antwortqualität, per Heuristik, per Referenz-Datensatz oder per „LLM-as-a-Judge“. Entscheidend für regulierte Kontexte: Evals und Prompt-Versionen werden im Gateway oder in der Observability-Plattform gegen fixierte Modellversionen getaggt. So lässt sich jedes Qualitätsurteil einer konkreten Modell- und Prompt-Version zuordnen. Ist ein Agent nach dem AI Act als Hochrisiko-System eingestuft, erleichtert diese Zuordnung die geforderten Nachweise, etwa zu Genauigkeit und Robustheit nach Art. 15 und zu den Validierungs- und Testverfahren, die die technische Dokumentation nach Art. 11 und Anhang IV enthalten muss.

Signal-zu-Tool-Matrix

Die folgende Tabelle ordnet jedes Observability-Signal seiner Mess-Größe und einem typischen Tool zu (Stand 2026).

Der LLM-Observability-Stack: Tools im Überblick

Für den Observability-Layer kommen vor allem diese Werkzeuge in Frage (Stand 2026):

• LangSmith, die Tracing- und Eval-Plattform aus dem LangChain-/LangGraph-Umfeld, als Managed-Service. Stark, wenn der Agent ohnehin auf diesem Framework aufsetzt. Bei einem Managed-Dienst prüfst du vorab, wo die Traces gespeichert werden.
• Langfuse, Open Source und laut Self-Hosting-Doku auf eigener Infrastruktur betreibbar, also in der EU self-hostbar (eigenes Rechenzentrum oder EU-Region). Das passt zu regulierten Architekturen mit kundenkontrollierter Observability ebenso wie zu schlanken Cloud-Setups, die Traces DSGVO-konform in der EU halten.
• Arize Phoenix, Observability und Evaluation unter der Elastic License 2.0, kostenlos self-hostbar und damit eine Alternative zu Langfuse.
• OpenTelemetry für LLMs / OpenInference, der herstellerneutrale Trace-Standard. Über die GenAI Semantic Conventions instrumentiert, bleibt das Backend austauschbar: ein wichtiges Argument gegen Lock-in. TGI von Hugging Face etwa exportierte bereits OpenTelemetry-Traces und Prometheus-Metriken, bevor das Projekt in den Maintenance-Modus ging.
• Datadog EU / Honeycomb EU, etablierte APM-Backends mit EU-Region: Datadog betreibt die Site EU1 in Deutschland, Honeycomb speichert Daten je nach gewählter US- oder EU-Region. Beide sind der Managed-Weg, wenn Daten in der EU bleiben sollen.

Ein wichtiger architektonischer Punkt: Das AI-Gateway (LiteLLM, Portkey, Kong) ist oft schon Träger von Teilen der Observability. Gateways übernehmen typischerweise Multi-Provider-Failover, virtuelles Key-Management, Team-Budgets, Observability, Guardrails und PII-Redaction. In der Praxis attribuiert das Gateway Token und Kosten, während die Tracing-Plattform den Reasoning-Pfad und die Evals hält: beides zusammen ergibt das vollständige Bild.

Beispiel-Trace: Ein Agenten-Lauf, aufgeschlüsselt

Das folgende Pseudo-Beispiel zeigt, wie ein einzelner Support-Agenten-Lauf als Span-Baum aussieht. Die Zahlen sind illustrativ.

```
TRACE id=ag-7f3c "Kundenanfrage: Rechnung stornieren" gesamt: 4.210 ms | 3.320 Tokens | 0,041 USD
├─ SPAN llm.reason model=gpt-4.x 620 ms | in 540 / out 80 Tok "Plan: Kunde+Rechnung nachschlagen"
├─ SPAN tool.crm_lookup mTLS, in-VPC 180 ms | status=200 args={kunde_id:8842}
├─ SPAN retrieval.vector qdrant-eu 95 ms | 4 Treffer query="Stornorichtlinie B2B"

├─ SPAN llm.reason model=gpt-4.x 710 ms | in 1.980 / out 130 Tok "Storno zulässig, Tool aufrufen"
├─ SPAN tool.invoice_void in-VPC 240 ms | status=200 args={rechnung:RE-2026-0317}
├─ SPAN guardrail.pii redaction 40 ms | 0 Treffer
└─ SPAN llm.compose model=gpt-4.x 2.325 ms| in 380 / out 210 Tok Antworttext an Kunde
EVAL tool_call_correct=PASS | answer_quality=0,92 | getaggt: model=gpt-4.x, prompt=v7
```

Was dieser Trace leistet, das ein Output-Log nicht kann: Wäre die Stornierung fehlgeschlagen, zeigt der Baum sofort, ob tool.invoice_void einen Fehlerstatus lieferte, ob retrieval.vector die falsche Richtlinie zog oder ob der zweite llm.reason-Span falsch entschieden hat. Der größte Latenz-Posten (llm.compose, 2.325 ms) ist unmittelbar als Optimierungskandidat erkennbar. Und die Eval-Zeile bindet das Qualitätsurteil an Modell- und Prompt-Version: die Grundlage für Rollback und Audit.

Bezug zum Monitoring im Sicherheits-Pillar

Tracing ist ein Debugging- und ein Sicherheitssignal. Agenten haben einen ungewöhnlich hohen „Blast Radius“: Ein kompromittierter Agent kann viele Tools aufrufen. Der durchgängige Trace liefert genau das Audit-Log, das diese Angriffsfläche nachvollziehbar macht: welcher Agent hat wann welches Tool mit welcher Identität aufgerufen. Ist ein Agent nach dem AI Act ein Hochrisiko-System, bildet dieser Trace zugleich die technische Grundlage für die automatische Protokollierung von Ereignissen, die Art. 12 verlangt. Der Trace ergänzt die Kontrollen aus dem Sicherheits- und Identitäts-Kontext: Deny-by-default-Egress mit Allowlist und Logging am Gateway, ein Service-Account je Agent-Tool-Paar statt geteilter Accounts sowie die Rückbindung jedes Aufrufs an die Nutzeridentität über eine Token-Exchange-Kette. Observability auf Netzwerkebene über ein Service-Mesh (mTLS, Workload-Identity, Traffic-Shaping) schließt den Kreis. Detaillierte Mess- und Kontrollmuster zu Egress, Identität und Monitoring behandelt der Sicherheits-Pillar; die Observability-Schicht liefert dafür die Telemetrie-Basis. Die konkrete Token-Ökonomie und Kostenmodellierung wiederum ist Gegenstand des FinOps-Pillars.

Für Agenturen und B2B-Entscheider

Für Marketing-Agenturen, die Agenten-Workflows für Kunden bauen, ist Observability das Lieferobjekt, das einen Pilot von einem auditierbaren Produktivsystem trennt: Erst Trace, Eval und EU-konformes Backend machen einen Agenten betreibbar, abrechenbar und gegenüber dem Kunden-Datenschutz vertretbar. Für DACH-B2B-Entscheider gilt: Wähle das Observability-Backend genauso bewusst wie die Cloud-Region: self-hosted Langfuse, Datadog EU oder Honeycomb EU halten Prompts und Antworten im EU-Raum, und herstellerneutrales OpenTelemetry-Tracing schützt vor Lock-in. Blck Alpaca aus Wien konzipiert und betreibt Agenten-Infrastruktur mit dieser Observability-Schicht von Beginn an: inklusive Tracing, Eval-Harness und DSGVO-konformem Backend. Sprich uns an, wenn du einen Agenten aus dem Pilotstatus in einen auditierbaren Produktivbetrieb überführen willst.