Wann man dazu greift
- Mehrere Komponenten zu einer Antwort beitragen.
- Fehlerursachen und Latenzen analysiert werden müssen.
- Produktionsbetrieb kontinuierliches Monitoring erfordert.
/pattern/distributed-tracing/
Agentenläufe, Tool-Aufrufe und Teilprozesse werden als zusammenhängende End-to-End-Traces sichtbar gemacht. Der herstellerübergreifende Standard sind die OpenTelemetry-GenAI-Semantikkonventionen (gen_ai.*-Span-Attribute), sodass ein einmal instrumentierter Lauf über Observability-Backends hinweg portabel ist; eine übliche Sampling-Strategie behält alle Fehler-Traces und nur einen kleinen Bruchteil der erfolgreichen.
In der PraxisEin mehrstufiger Recherche-Agent emittiert OpenTelemetry-Spans für jeden Tool-Aufruf und Sub-Agenten-Aufruf, sodass ein Bereitschaftsingenieur genau feststellen kann, welcher Abrufschritt eine P99-Latenzspitze verursacht hat.
Wann man dazu greift
Wann es nach hinten losgeht
Die Abwägung
Tiefe Diagnosefähigkeit wird auf Kosten von Telemetrie- und Datenschutzverwaltungsaufwand erreicht. In Produktion unverzichtbar.
Jeder Schritt sendet einen Span in einen durchgehenden Trace.
Jeder LLM-Aufruf schreibt seinen vollständigen Prompt und die Antwort in den Trace. Speicherkosten explodieren und die Trace-Ansicht wird unbrauchbar.
Lösung · Vollständige Payloads bei 1 % samplen. Für den Rest nur Token-Anzahl, Latenz und Modellname protokollieren. Prompts bei Bedarf zusammenfassen.
Der Agent übergibt eine Trace-ID an ein Tool, aber das Tool ruft einen anderen Dienst auf, der eine eigene ID generiert. Der verteilte Trace bricht ab.
Lösung · Trace-Kontext über Standard-Header (z. B. W3C traceparent) weitergeben. Tools ablehnen, die die Trace-ID nicht weiterleiten.
Weitermachen
Patterns, Frameworks und Seiten durchsuchen.