Betriebsreihe: Observability für Agenten mit Traces statt Transkripten

Observability für KI-Agenten ist verteiltes Tracing mit ein paar zusätzlichen Attributen. Ein einzelner Agentenlauf ist ein Baum aus Arbeit: ein Plan, mehrere Modellaufrufe, Tool-Aufrufe, Übergaben und Freigaben. Erfassen Sie jedes als Span, hängen Sie Tokens, Kosten und Policy-Entscheidungen als Attribute an, und Sie können die Fragen des Betriebs beantworten: Was ist passiert, wie lange hat es gedauert, was hat es gekostet und warum hat der Agent das getan. Chat-Transkripte allein können das nicht, denn sie zeigen das Gespräch, aber nicht Zeiten, Fehler und die Entscheidungen drumherum.

Dieser Beitrag gehört zur Betriebsreihe, die Agenten als Dienste behandelt, die man betreibt, und nicht als Demos, die man ansieht.

Warum Transkripte nicht reichen

Ein Transkript ist nützlich, um zu lesen, was ein Modell gesagt hat. Als Betriebswerkzeug hat es Lücken:

• Es hat keine Zeitangaben. Ob ein langsamer Lauf auf das Modell, ein Tool oder eine menschliche Freigabe gewartet hat, lässt sich nicht erkennen.
• Es lässt sich schwer aggregieren. Fehlgeschlagene Tool-Aufrufe über tausend Läufe zu zählen heißt, Freitext zu parsen.
• Es vermischt Sensibles und Strukturelles. Prompts und Ausgaben enthalten oft personenbezogene oder vertrauliche Daten, während die Struktur für das Monitoring aus Metadaten besteht.
• Es verbindet keine Systeme. Ruft ein Agent einen Dienst mit eigenen Logs auf, verknüpft nichts beides.

Traces lösen jedes dieser Probleme. Sie haben eine Dauer pro Schritt, typisierte Attribute, die sich abfragen lassen, und eine Trace-ID, die mit der Anfrage mitreisen kann.

Ein Agentenlauf als Trace

Ordnen Sie die Teile eines Laufs Spans zu:

Teil des Laufs	Span	Nützliche Attribute
Der ganze Lauf	Root-Span agent.run	Run-ID, Agentenname, Version, Ergebnis
Planung	agent.plan	Anzahl der Schritte, Plangröße
Ein Modellaufruf	model.call	Modell, Ein- und Ausgabe-Tokens, Abschlussgrund, Kosten
Ein Tool-Aufruf	tool.call	Toolname, Status, Dauer, Größe der Argumente
Policy-Prüfung	Event am Tool-Span	Entscheidung (erlauben, ablehnen, Freigabe), Regel-ID
Warten auf einen Menschen	approval.wait	Rolle der Freigebenden, Wartezeit, Ergebnis
Übergabe an einen anderen Agenten	agent.handover	von, an, Vertrags-ID

Lassen Sie Inhalte standardmäßig aus den Attributen heraus. Speichern Sie Größen, Hashes und IDs, und halten Sie den Roh-Prompt und die Ausgabe in einem getrennten, zugriffsgeschützten Speicher, auf den der Trace verweist. So liest nicht jeder, der Dashboards sehen darf, automatisch Kundendaten.

Golden Signals auf Agenten abbilden

Das klassische Vokabular des Monitorings gilt weiter. Das Google-SRE-Buch fasst es in einem Satz zusammen:

The four golden signals of monitoring are latency, traffic, errors, and saturation.

— Site Reliability Engineering, Chapter 6: Monitoring Distributed Systems, Google

Sinngemäß: Latenz, Verkehr, Fehler und Sättigung. Für einen Agentendienst ist eine brauchbare Übersetzung:

• Latenz. Zeit pro Lauf, aufgeteilt in Modellzeit, Tool-Zeit und Wartezeit auf Freigaben. Alarmieren Sie auf Modell und Tools; die Wartezeit auf Freigaben ist eine Geschäftskennzahl, kein Fehler.
• Verkehr. Gestartete Läufe pro Minute, nach Agent und Auslöser.
• Fehler. Fehlgeschlagene Läufe und Tool-Aufrufe, Policy-Ablehnungen und Schemafehler. Zählen Sie auch falsche Antworten, wenn Evals sie erkennen; dazu später ein Beitrag dieser Reihe zu SLOs für Agenten.
• Sättigung. Erreichte Rate Limits, Warteschlangenlänge, parallele Läufe, verbrauchtes Token-Budget.

Ergänzen Sie ein Signal, das klassische Dienste nicht haben: Kosten. Tokens und Geld pro Lauf sind Kennzahlen erster Klasse, und eine Schleife, die das Zehnfache des Üblichen verbraucht, ist ein Vorfall, auch wenn jeder Aufruf gelang. Zu Budgets und Zuordnung siehe Kosten sind eine Aufgabe der Plattform.

OpenTelemetry-Konventionen nutzen, Lock-in vermeiden

Agenten-Frameworks und Observability-Anbieter erfinden jeweils eigene Attributnamen. Dann hängen Dashboards, Alarme und Exporte an einem Produkt. Das OpenTelemetry-Projekt wirbt aus genau diesem Grund für gemeinsame Benennung:

establish standards around the shape of the telemetry generated by agent apps to avoid lock-in

— AI Agent Observability - Evolving Standards and Best Practices, OpenTelemetry

Die Arbeit des Projekts zu generativer KI legt fest, wie diese Form für Modellaufrufe aussieht:

For generative AI, these conventions streamline monitoring, troubleshooting, and optimizing AI models by standardizing attributes such as model parameters, response metadata, and token usage.

— OpenTelemetry for Generative AI, OpenTelemetry

Praktische Hinweise:

1. OpenTelemetry-Spans senden aus der Agenten-Laufzeit und, wo vorhanden, die GenAI-Attributnamen für Modellaufrufe und Token-Verbrauch nutzen. Prüfen Sie die aktuellen Semantic Conventions, bevor Sie Namen festlegen; der Bereich entwickelt sich weiter.
2. Eigene Attribute mit Namensraum (zum Beispiel agent.run.id, policy.decision) für das, was der Standard nicht abdeckt, und dokumentieren.
3. Über einen Collector exportieren. Die Anwendung sendet an einen OpenTelemetry Collector, und der Collector entscheidet über das Ziel. Ein Wechsel des Backends erfordert dann keine Änderung an den Agenten.
4. Kontext weitergeben. Den Trace-Kontext an Tools und andere Dienste durchreichen, damit deren Spans demselben Trace angehören.

Eine minimale Konfiguration für die Collector-Seite:

receivers:
  otlp:
    protocols:
      http: {}
processors:
  batch: {}
  attributes/redact:
    actions:
      - key: gen_ai.prompt
        action: delete
exporters:
  otlphttp:
    endpoint: https://telemetry.example.org
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [attributes/redact, batch]
      exporters: [otlphttp]

Der Redaction-Prozessor im Collector ist ein Sicherheitsnetz und kein Ersatz dafür, Inhalte gar nicht erst zu senden.

Worauf man alarmieren sollte

Beginnen Sie mit wenigen Alarmen, die bei jemandem ankommen, der handeln kann:

• Fehlerrate der Läufe eines Agenten über einem Schwellwert in 15 Minuten.
• p95-Latenz eines Tools über dem Normalwert.
• Kosten pro Lauf über einem Vielfachen des gleitenden Medians oder ein Budget, das schneller verbraucht wird als geplant.
• Ein Anstieg der Policy-Ablehnungen, der auf einen falsch konfigurierten Agenten oder einen Missbrauchsversuch hindeuten kann. Siehe Policy entscheidet, Audit belegt.
• Freigaben, die länger als vereinbart warten.

Verknüpfen Sie jeden Alarm mit einem Runbook und mit einer Abfrage, die die betroffenen Traces zeigt. Den größeren Punkt, dass daran nichts Besonderes ist, macht Agentenbetrieb ist einfach Betrieb.

Grenzen

Traces zeigen, was der Agent getan hat, nicht ob es richtig war. Kombinieren Sie sie mit Evals und stichprobenartiger menschlicher Prüfung. Auch Sampling ist ein Kompromiss: Behalten Sie jeden fehlgeschlagenen oder teuren Lauf und nehmen Sie von den gesunden Stichproben. Und seien Sie ehrlich, was Ihre Konventionen abdecken; Semantic Conventions für Agenten reifen noch, rechnen Sie also damit, Attributnamen im Lauf der Zeit anzupassen.

Das Wichtigste in Kürze

• Modellieren Sie einen Agentenlauf als Trace: Spans für Plan, Modellaufrufe, Tool-Aufrufe, Freigaben und Übergaben.
• Legen Sie Tokens, Kosten und Policy-Entscheidungen als Attribute an die Spans; Rohinhalte gehören nicht dorthin.
• Übersetzen Sie die vier Golden Signals und ergänzen Sie Kosten als fünftes.
• Nutzen Sie OpenTelemetry und einen Collector, um Backend-Lock-in zu vermeiden.
• Alarmieren Sie auf Fehler, Sättigung, Kosten und Policy-Ablehnungen, jeweils mit Runbook.

Quellen

• OpenTelemetry: AI Agent Observability - Evolving Standards and Best Practices
• OpenTelemetry: OpenTelemetry for Generative AI
• Google: Site Reliability Engineering, Chapter 6: Monitoring Distributed Systems