Warum Sie Tracing auf dem Gateway benötigen

Wenn ein LLM-Aufruf langsam, teuer oder fehlerhaft ist, müssen Sie nachvollziehen können, was tatsächlich passiert ist. Hat ein Guardrail den Prompt redigiert? Wie lange hat das Modell im Vergleich zum Netzwerk benötigt? Was hat das Gateway an den Provider gesendet? Request-Logging und Tracing auf dem AI Gateway beantworten diese Fragen für jeden Aufruf.

Da jeder Request ohnehin über das Gateway läuft, erhalten Sie diese Transparenz, ohne jede Anwendung manuell instrumentieren zu müssen.

Steuerung der Protokollierung

DieDokumentation zum Request-Logging ermöglicht es Ihnen zu steuern, welche Requests protokolliert werden. Die einfachste Methode ist die Steuerung pro Request über den Header X-TFY-LOGGING-CONFIG mit einem stringifizierten JSON-Wert. Setzen Sie „enabled“ auf „true“, um den Request zu protokollieren, oder auf „false“, um ihn zu überspringen.

Ein wichtiger Hinweis: Der Wert dieses Headers ist ein stringifiziertes JSON und kein rohes JSON-Objekt, da die meisten SDKs Header als Strings serialisieren. Die älteren globalen Logging-Modi werden durch eine regelbasierte Logging-Konfigurationersetzt, mit der Sie das Logging pro Subjekt, Modell oder Metadaten steuern und sensible Werte redigieren können.

Request-Logs anzeigen

Um protokollierte Requests in der Benutzeroberfläche zu sehen, gehen Sie zu „AI Gateway“, dann zu „Monitor“ und schließlich zu „Requests“. Dort finden Sie eine Liste aller protokollierten Aufrufe, die Sie öffnen können, um einen einzelnen Request im Detail zu untersuchen.

Traces und Spans erklärt

DieTracing-Dokumentation beschreibt ein Trace als den vollständigen Lebenszyklus eines Requests, während er die Dienste durchläuft, die mit dem LLM interagieren. Normalerweise entspricht ein Trace einem einzelnen API-Aufruf einer Anwendung.

Ein Span ist eine einzelne Arbeitseinheit innerhalb dieses Traces, wie etwa ein Funktionsaufruf, ein HTTP-Request oder eine Modell-Inferenz. Ein Trace ist ein Baum aus Spans mit Eltern-Kind-Beziehungen, wobei ein Kind-Span normalerweise durch seinen Eltern-Span ausgelöst wird. TrueFoundry stellt ein OpenTelemetry-Collector-Backend bereit, das diese Traces speichert, sowie eine Benutzeroberfläche zum Abfragen und Analysieren. Es kann Traces von jedem OpenTelemetry-kompatiblen SDK empfangen.

Can you explain why your last slow request was slow?

We will open a live trace on your traffic and walk the span tree with you.

Book a demo

Einen einzelnen Trace lesen

‍

DieDokumentation zur Trace-Inspektion Gehen wir ein reales Beispiel durch: eine Chat-Vervollständigung mit einem Guardrail zur PII-Schwärzung, erfasst als fünf Spans, die eine Hierarchie bilden.

‍

• ChatCompletion-Span (Wurzel) repräsentiert den gesamten Lebenszyklus der Anfrage aus Sicht des Clients. Im Beispiel dauert dies etwa 7 Sekunden und enthält Token-Metriken, Kosten sowie Ein- und Ausgabedaten.
• Guardrail-Span ist ein Kindelement der Wurzel und repräsentiert die Verarbeitung der PII-Schwärzung, die weniger als eine halbe Sekunde dauert.
• Guardrail-Netzwerkaufruf-Span ist der eigentliche HTTP-Aufruf an den Guardrail-Dienst, inklusive HTTP-Methode und Statuscode.
• Modell-Span ist ein Geschwisterelement des Guardrail-Spans und repräsentiert die Modellinferenz, die den Großteil der Anfragedauer in Anspruch nimmt.
• Modell-Netzwerkaufruf-Span ist der eigentliche HTTP-Aufruf an den Anbieter, zum Beispiel ein POST-Request an den Chat-Completions-Endpunkt des Anbieters.

‍

Im selben Beispiel ist die Eingabe sichtbar von einem Namen in einen Platzhalter geschwärzt, was zeigt, dass der PII-Guardrail innerhalb des Traces durchgängig funktioniert.

‍

Ein Chat-Completions-Trace, der die Guardrail-, Modell- und ausgehenden Netzwerk-Spans zeigt.

‍

Vom einzelnen Trace zu flottenweiten Metriken

‍

Einzelne Traces dienen dem Debugging. Für Trends aggregiert das Analytics-Dashboard dieselben Daten. Die Reiter umfassen Übersicht, Modell-Metriken, MCP-Metriken, Guardrail-Metriken, Routing-Metriken und Cache-Metriken.

‍

Modellmetriken können nach Modellen, virtuellen Modellen, Benutzern, virtuellen Konten, Teams oder Metadaten gruppiert werden. Die Latenzansichten schlüsseln die Anfragelatenz, die Zeit bis zum ersten Token, die Latenz zwischen den Token sowie die Zeit pro ausgegebenem Token auf. Zusammen mit den Traces pro Anfrage erhalten Sie so sowohl das Mikroskop als auch das Dashboard.

‍

Modellmetriken im Analytics-Dashboard, gruppierbar nach Team, Benutzer, Modell und mehr.

‍