Was ist Tracing-Sampling, und wann kann es einen Fehler in einem KI-Workflow verbergen?

Beim Trace-Sampling werden nur ausgewählte Request-Traces behalten. Dadurch werden Speicher- und Verarbeitungsaufwand reduziert, allerdings besteht das Risiko, dass genau der Workflow-Pfad verloren geht, der für die Diagnose benötigt wird.

Eine lokale KI-Anfrage kann ein Gateway, einen Modell-Router, einen Vektorsuchdienst, eine Tool-Sandbox und eine Hausautomatisierungsbrücke durchlaufen und dabei pro Interaktion zahlreiche Spans erzeugen. Jeden Pfad dauerhaft aufzuzeichnen ist kostspielig. Beim Sampling wird entschieden, welche vollständigen Traces oder Teilerfassungen erhalten bleiben. Der Zeitpunkt und die Kriterien dieser Entscheidung bestimmen jedoch, ob ein seltener Timeout, ein verweigerter Tool-Aufruf oder ein stiller Fallback sichtbar bleibt.

Trace-Sampling wählt Request-Verläufe aus, nicht einzelne Fakten

Ein Trace stellt eine Anfrage als zusammengehörige Spans über mehrere Dienste hinweg dar. Beim Sampling wird anhand einer Wahrscheinlichkeit, von Attributen oder einer Richtlinie entschieden, ob dieser Request-Verlauf aufgezeichnet oder exportiert wird. Metriken und Logs können weiterhin vorhanden sein, doch sie können denselben kausalen Pfad nicht rekonstruieren, sofern sie nicht kompatible Bezeichner enthalten.

Die Dokumentation zu Sampling-Konzepten unterscheidet zwischen Head-Sampling, das nahe am Beginn einer Anfrage entschieden wird, und Tail-Sampling, das erst erfolgt, nachdem die meisten Spans eingegangen sind. Head-Sampling ist einfach und kostengünstig, während Tail-Sampling Traces anhand der endgültigen Latenz, des Fehlerstatus oder von Attributen behalten kann, die erst später erkannt werden.

Sampling verändert daher die diagnostische Abdeckung und nicht das Verhalten der Anwendung. Eine Anfrage kann unabhängig davon, ob ihr Trace behalten wird, identisch erfolgreich abgeschlossen werden oder fehlschlagen. Nach dem Ereignis sieht der Betreiber jedoch eine andere Beweislage. Dieser Unterschied bleibt auch bei späteren Tests im Haushalt sichtbar.

Head-Entscheidungen können einen später auftretenden Fehler nicht erkennen

Eine auf dem Root-Span getroffene Wahrscheinlichkeitsentscheidung kann nicht wissen, dass der abschließende Tool-Aufruf später einen Timeout verursacht oder ein nachgelagerter Dienst einen Fehler zurückgibt. Wird die Anfrage am Anfang verworfen, sind möglicherweise alle späteren Spans nicht verfügbar, obwohl das Ereignis betrieblich wichtig ist.

Ein Beispiel für Tail-basierte Aufbewahrung in OpenTelemetry beschreibt, wie fehlgeschlagene Aktivitäten mit einem Tail-orientierten Ansatz behalten werden. Es veranschaulicht den zentralen Vorteil: Die Entscheidung kann das abgeschlossene Ergebnis verwenden, statt die Bedeutung anhand von Attributen zu erraten, die zu Beginn vorhanden waren.

Head-Sampling eignet sich weiterhin für allgemeine Performance-Trends, wenn die Raten stabil sind und Bezeichner konsistent weitergegeben werden. Riskant wird es, wenn Fehler selten auftreten, sich auf eine Route mit geringem Anfragevolumen konzentrieren oder erst nach mehreren Agentenschritten erkennbar sind.

Tail-Richtlinien bringen Zustand, Verzögerungen und eigene blinde Flecken mit sich

Tail-Sampling puffert Spans, bis ein Entscheidungsfenster geschlossen wird, gruppiert sie nach Trace-ID und wendet geordnete Richtlinien an. Spät eintreffende Spans, eine aufgeteilte Weiterleitung, Neustarts des Collectors, Speicherdruck oder ein kürzeres Fenster als der Workflow können dazu führen, dass der Sampler nur einen unvollständigen Trace erhält.

Die Anforderungen an den Collector weisen darauf hin, dass alle Spans eines Traces dieselbe Collector-Instanz erreichen müssen und dass ausstehende Spans Speicher belegen. Diese Anforderungen sind auf einem kleinen Heimserver wichtig, auf dem der Observability-Prozess mit der Inferenz um den Arbeitsspeicher konkurriert.

Die Fehlergrenze entsteht bei einem Workflow, dessen entscheidender Fehler-Span eintrifft, nachdem der Sampler seine Entscheidung getroffen hat, einen anderen Collector erreicht oder das von der Richtlinie verwendete Statusattribut nicht enthält. Tail-Sampling verbessert die Auswahl nur dann, wenn auch die Zusammensetzung des Traces zuverlässig bleibt.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Führe einen Test zur Abdeckung bekannter Fehler-Traces durch

Erstelle kontrollierte Workflows, die am Router, Retrieval-Dienst, Modellserver, in der Tool-Sandbox und beim abschließenden Aufruf der Hausautomatisierung fehlschlagen. Weise eine Test-Korrelations-ID zu, dokumentiere die erwartete Span-Sequenz und wiederhole jeden Fehler ausreichend oft, um die konfigurierten Wahrscheinlichkeits- und Tail-Richtlinien zu testen.

Verwende die Service-Map im End-to-End-Tracing, um zu überprüfen, dass jeder beibehaltene Fehler-Trace seinen Root-Span, die Zwischenaufrufe, den abschließenden Fehler und die relevanten Richtlinienattribute enthält. Zähle fehlgeschlagene Anfragen zusätzlich in einer nicht gesampelten Metrik, damit fehlende Traces erkannt und nicht fälschlicherweise als ausbleibende Fehler interpretiert werden.

Der Test ist nur dann bestanden, wenn kritische Fehler mit der erforderlichen Rate behalten werden und unvollständige Traces ausdrücklich messbar sind. Verwende Regeln für eine immer erfolgende Aufzeichnung nur bei besonders wichtigen Fehlerklassen, begrenze den Pufferspeicher und teste Neustarts des Collectors sowie Bedingungen mit spät eintreffenden Spans, bevor du dich bei der Rekonstruktion von Vorfällen auf Traces verlässt.