Reliability and Routing22. Juni 2026Big Y

AI API Observability-Logs: Was bei Modell-Routing-Incidents erfasst werden sollte

Nutzen Sie AI API Observability-Logs, um Modell-Routing-Incidents mit Request-IDs, Routen, Retries, Fallback, Tokens, Latenz, Kosten und datenschutzsicheren Metadaten zu debuggen.

AI-API-Observability ist das, was es einem Engineering-Team ermöglicht, einen Routing-Vorfall bei einem Modell nachzuvollziehen, ohne zu raten. Ein Nutzer meldet ein Timeout, ein Fallback-Modell antwortet anders, ein Provider liefert 429 zurück, oder die Ausgaben steigen nach einem Upstream-Wechsel sprunghaft an. Die Vorfallsanalyse braucht mehr als nur einen rohen Prompt und einen Statuscode. Sie braucht einen Logeintrag, der die Anfrage, die Route, die Retry-Kette, das ausgewählte Modell, das Latenzprofil, die Nutzung, die Kosten und die Datenschutzkontrollen rund um die gespeicherten Daten zeigt.

Dieser Leitfaden ist eine Checkliste auf Feldebene für AI-API-Observability-Logs bei Routing-Vorfällen. Er richtet sich an Teams, die ein AI-Gateway, einen Multi-Provider-Router oder eine Kompatibilitätsschicht verwenden, bei der eine Anwendungsanfrage mehrere mögliche Upstream-Pfade durchlaufen kann. Das Ziel ist nicht, jeden Prompt für immer zu speichern. Das Ziel ist, genügend Metadaten zu behalten, um zu belegen, was passiert ist, während sensible Eingaben, Ausgaben, Tool-Argumente und Kundenkennungen unter Kontrolle bleiben.

Flatkey passt zu diesem Problem, weil der öffentliche Produkttext einen API-Schlüssel, eine OpenAI-kompatible Base-URL unter https://router.flatkey.ai/v1, einheitliche Abrechnung und ein Dashboard für Schlüssel, Nutzung und Routing in den Mittelpunkt stellt. Flatkey verweist außerdem auf automatisches Umschalten und Load Balancing über Upstream-Konten hinweg. Das sind nützliche Zuverlässigkeitsfunktionen, aber nur dann, wenn die Logs eine Routing-Frage im Nachhinein beantworten können.

AI-API-Observability beginnt mit Fragen zum Incident

Bevor Sie Felder auswählen, definieren Sie die Fragen, die der Incident Commander beantworten muss. Für das Modell-Routing sollte AI-API-Observability diese Fragen aus einem einzelnen Request-Datensatz oder einem korrelierten Trace beantwortbar machen:

Welche Anwendung, Umgebung, welches Team, welcher Schlüssel, welcher Workflow und welcher kundensichere Owner hat die Anfrage gesendet?
Welche Endpunktfamilie, welches angeforderte Modell, welche Route-Policy und welche Fallback-Regel galten zum Zeitpunkt der Anfrage?
Welcher Anbieter, welches Modell, welches Upstream-Konto oder welche Route hat die Antwort tatsächlich bereitgestellt?
Wurde die Anfrage erneut versucht, umgeleitet, gedrosselt, in die Warteschlange gestellt, blockiert oder abgebrochen?
Welcher Statuscode, welche Anbieter-Fehlerklasse, welcher Rate-Limit-Header, welches Timeout oder welches Stream-Ereignis hat das Ergebnis verändert?
Wie viele Input-, Output-, Cache- und Reasoning-Tokens wurden gezählt, und was hat die Route gekostet?
Haben Datenschutzkontrollen Roh-Payloads, redigierte Payloads, nur Metadaten oder keinen Logeintrag gespeichert?

Wenn ein Log diese Fragen nicht beantworten kann, wird das Team die Lücke mit Slack-Erinnerungen, Screenshots und Support-Tickets des Anbieters füllen. Das verlangsamt die Behebung und macht zukünftige Route-Änderungen schwerer vertrauenswürdig.

Die Checkliste für das Protokoll eines Model-Routing-Vorfalls

Die folgende Tabelle ist das zentrale AI-API-Observability-Asset für diesen Artikel. Verwenden Sie sie als Implementierungs-Checkliste für LLM-API-Logs, Gateway-Logs oder Ereignisse im Data Warehouse.

Feldgruppe	Zu erfassende Felder	Warum es bei einem Routing-Vorfall wichtig ist	Datenschutzhinweis
Korrelations-IDs	Anwendungs-Anfrage-ID, `X-Client-Request-Id`, Anbieter-`x-request-id`, W3C `traceparent`, Gateway-Log-ID, Ereignis-ID.	Verbindet den für den Nutzer sichtbaren Fehler, die Gateway-Entscheidung, die Anbieteranfrage, den Trace-Span und das Support-Ticket.	Verwenden Sie undurchsichtige IDs. Kodieren Sie keine E-Mail, IP, Mandantenname oder Prompt-Text in Trace-Felder.
Mandant und Eigentümer	Projekt, Umgebung, API-Key-ID oder Hash, Team, Workflow, kundenfähige Konto-ID, Kostenstelle.	Zeigt, wer betroffen war und wer für Kontingent, Kosten und Behebung verantwortlich ist.	Bevorzugen Sie stabile interne IDs statt roher Kundennamen oder Benutzer-E-Mails.
Angeforderte Route	Endpoint-Familie, angefordertes Modell, Anbieterpräferenz, Routing-Richtlinie, Fallback-Richtlinie, Modell-Alias-Version, Katalog-/Preisversionsstand.	Rekonstruiert, was der Client angefordert hat und was der Router in diesem Moment tun durfte.	Halten Sie Prompts aus dem Route-Objekt heraus, es sei denn, ein separat freigegebener Debug-Modus ist aktiv.
Ausgewählte Route	Endgültiger Anbieter, endgültiges Modell, Upstream-Konto oder Kanal, falls relevant Region, Grund der Routing-Entscheidung, Richtlinienregel-ID.	Belegt, ob das primäre Modell die Antwort geliefert hat oder ein Fallback-Pfad Verhalten oder Kosten verändert hat.	Kontoidentifikatoren sollten interne Verweise sein, keine Anbieter-Geheimnisse oder vollständigen Zugangsdaten.
Retry- und Fallback-Kette	Versuchsindex, Retry-Anzahl, vorheriger Anbieter/Modell, Fehlerklasse, Statuscode, Fallback-Ziel, Endergebnis.	Verhindert blinde Retries und zeigt, ob die Failover-Leiter wie vorgesehen funktioniert hat.	Speichern Sie Fehlerklasse und sichere Auszüge. Vermeiden Sie das Speichern vollständiger Anbieter-Fehlerkörper, wenn diese Prompt-Inhalte wiedergeben können.
Latenz und Streaming	Anfrage-Startzeit, Gateway-Dauer, Anbieterdauer, Zeit bis zum ersten Token/Chunk, Stream gestartet, Stream abgeschlossen, Abbruchgrund, Client-Verbindungsabbruch.	Trennt Anbieter-Latenz, Routing-Zeit des Gateways, Streaming-Stall und clientseitige Kündigung.	Streaming-Chunks sind Inhalt. Protokollieren Sie standardmäßig nur Zeitmetadaten und Inhalte nur unter einem gesteuerten Debug-Modus.
Nutzung und Kosten	Eingabe-Tokens, Ausgabe-Tokens, zwischengespeicherte Tokens, Reasoning-Tokens, Bild-/Video-Einheiten, falls relevant, Anfrageanzahl, Position, geschätzte oder endgültige Kosten.	Erklärt die Budgetauswirkung, wenn ein Fallback den Traffic zu einem anderen Anbieter, Modell oder Servicetier verschiebt.	Für normale Dashboards nach Schlüssel, Workflow und Team aggregieren; Ansichten pro Benutzer einschränken.
Antwortform	Abschlussgrund, Tool-Call-IDs/-Namen, Ausgabetyp, Antwortstatus, Trunkierung oder unvollständige Details, Servicestufe.	Zeigt, ob das Modell normal gestoppt hat, ein Tool aufgerufen hat, ein Limit erreicht hat oder eine unvollständige Antwort zurückgegeben hat.	Tool-Argumente und Tool-Ergebnisse können sensible Daten enthalten. Speichern Sie standardmäßig IDs und Namen.
Fehler und Rate-Limits	HTTP-Status, Anbieter-Fehlercode, Timeout-Klasse, Retry-After, verbleibende/Limit/Reset-Request-Header, verbleibende/Limit/Reset-Token-Header.	Unterscheidet fehlerhafte Anfragen, Auth-Fehler, Anbieter-Vorfälle, Kontingent-Erschöpfung und Rate-Limit-Stürme.	Normalisieren Sie Anbieterfehler in sichere Klassen, bevor Sie sie in breitere Analysetools einspeisen.
Governance und Aufbewahrung	DLP-Aktion, Richtlinien-ID, Modus der Inhaltsprotokollierung, Redaktions-Flag, Payload-Hash, Aufbewahrungsklasse, Löschberechtigung.	Ermöglicht es Sicherheit und Compliance zu verifizieren, warum Inhalte gespeichert, redigiert, blockiert oder ausgeschlossen wurden.	Standardmäßig nur Metadaten protokollieren, wenn Rohinhalte für einen definierten Support- oder Audit-Workflow nicht erforderlich sind.

IDs erfassen, bevor Sie den Anbieter debuggen

Die erste Aufgabe von KI-API-Observability ist die Korrelation. Die API-Referenz von OpenAI empfiehlt, Request-IDs in der Produktion zu protokollieren, und dokumentiert sowohl vom Anbieter generierte x-request-id-Werte als auch vom Aufrufer übergebene X-Client-Request-Id-Werte. Letzteres ist wichtig, wenn ein Timeout oder ein Netzwerkausfall verhindert, dass Ihr Client die Response-Header des Anbieters empfängt.

Für ein Gateway fügen Sie eine weitere Ebene hinzu: eine Gateway-Request-ID, die internen Retries und Fallbacks übersteht. Wenn eine Benutzeranfrage zuerst Anbieter A, dann Anbieter B und schließlich ein Backup-Modell versucht, sollte die Gateway-ID alle Versuche miteinander verknüpfen. Die Provider-Request-ID sollte versuchsspezifisch bleiben. Die Trace-ID sollte diesen KI-Aufruf mit dem Rest der Anwendungsanfrage verknüpfen.

Der W3C Trace Context definiert traceparent und tracestate für die Weitergabe von verteiltem Trace-Kontext über Dienste hinweg. Verwenden Sie diese Header für die Trace-Korrelation, nicht für die Kundenidentität. Der W3C-Abschnitt zum Datenschutz ist eindeutig: Tracing-Felder dürfen keine personenbezogenen oder anderweitig sensiblen Informationen enthalten.

Protokollieren Sie angeforderte Route und ausgewählte Route getrennt

Ein häufiger Fehler beim AI-Gateway-Monitoring besteht darin, nur den endgültigen Anbieter und das Modell zu protokollieren. Dadurch geht der wichtigste Routing-Nachweis verloren: was der Client angefordert hat und was die Policy vor der Entscheidung des Gateways erlaubt hat.

Halten Sie diese beiden Objekte getrennt:

Angeforderte Route: Endpunktfamilie, angefordertes Modell oder Alias, Routing-Richtlinie, Anbieterpräferenz, Fallback-Richtlinie, Katalogversion, Preisversionsstand und Anforderungsmodus wie Streaming oder Batch.
Ausgewählte Route: endgültiger Anbieter, endgültiges Modell, Upstream-Konto oder -Kanal, Region sofern relevant, Grund für die Routing-Entscheidung und ID der Richtlinienregel.

Diese Trennung ist wichtig, wenn eine Fallback-Antwort gültig, aber überraschend ist. Wenn die angeforderte Route chat/completions mit aktiviertem Streaming war und die ausgewählte Route nach einem Timeout auf ein anderes Modell umschwenkte, kann die Incident-Analyse sowohl den vorgesehenen als auch den tatsächlichen Pfad sehen. Außerdem hilft sie der Finanzabteilung zu verstehen, warum die Nutzung unter einem anderen Modell oder Posten erschien.

Flatkey-Kunden sollten denselben Bewertungsansatz anwenden. Beginnen Sie mit der Checkliste der Anforderungen an das AI-API-Gateway und nutzen Sie dann das Playbook für Load Balancing und Failover, um festzulegen, welche Route-Änderungen zulässig sind, bevor Sie die Protokolle prüfen.

Wiederholungs- und Fallback-Kette erfassen

Wiederholungen sind der Punkt, an dem unvollständige Protokolle teuer werden. Wenn die einzigen gespeicherten Felder der endgültige Status und das endgültige Modell sind, kann das Team nicht erkennen, ob eine Anfrage beim ersten Versuch erfolgreich war, nach einem Wiederholungsversuch oder erst nach fünf Versuchen über verschiedene Anbieter hinweg. AI API Observability auf Incident-Niveau behandelt Wiederholung und Fallback als eine Kette.

Jeder Versuch sollte enthalten:

Versuchsindex und übergeordnete Gateway-Anfrage-ID.
Anbieter, Modell, Upstream-Konto und Endpunktfamilie für diesen Versuch.
Startzeit, Dauer, Timeout-Klasse und Streaming-Status.
Statuscode, Anbieter-Fehlerklasse, Anbieter-Anfrage-ID und Metadaten zum Ratenlimit.
Fallback-Ziel und Entscheidungsgrund, wenn der Versuch die Kette nicht beendet.

Diese Kette verhindert, dass das Gateway echte Fehlermodi verschleiert. Eine fehlerhaft formatierte Anfrage sollte geschlossen fehlschlagen, nicht zwischen Anbietern wechseln. Ein Anbieter-500 könnte einen Wiederholungsversuch rechtfertigen. Ein Kontingentlimit könnte zu einem freigegebenen Upstream-Konto wechseln. Eine für den Kunden sichtbare Modellabweichung könnte einen kontrollierten Fehler statt eines stillen Fallbacks erfordern.

Messung der Latenz für Streams, nicht nur für abgeschlossene Calls

Streaming-Antworten brauchen mehr als nur die Gesamtdauer. Die Observability-Dokumentation von Vercel's AI Gateway hebt die Zeit bis zum ersten Token, die Anforderungsdauer, Token-Zahlen und Ausgaben als Gateway-Metriken hervor. Die GenAI-Semantic-Conventions von OpenTelemetry umfassen gen_ai.response.time_to_first_chunk und gen_ai.request.stream. Diese Felder sind nützlich, weil viele Routing-Vorfälle Streaming-Vorfälle sind: Der Provider hat die Anfrage angenommen, der erste Chunk kam spät, der Stream blieb hängen oder der Client hat die Verbindung getrennt.

Protokolliere mindestens die Startzeit der Anfrage, die Gateway-Dauer, die Provider-Dauer, die Zeit bis zum ersten Token oder Chunk, das Flag für Stream gestartet, das Flag für Stream abgeschlossen, den Abbruchgrund und den Status der Client-Trennung. Für nicht-streamende Antworten können dieselben Felder null oder false bleiben. So bleibt ein einheitliches Schema über Chat Completions, Responses und provider-spezifische Endpunktfamilien hinweg erhalten.

Speichere Stream-Chunks standardmäßig nicht. Stream-Chunks sind Antwortinhalte, und Antwortinhalte können Benutzerdaten, abgerufenen Kontext, Tool-Ergebnisse oder regulierte Informationen enthalten. Für die normale AI-API-Observability reichen Timing-Metadaten in der Regel aus, um einen Hänger zu diagnostizieren.

Verknüpfen Sie Nutzung und Kosten mit der Routenentscheidung

Nutzung und Kosten sind Incident-Felder, nicht nur Finance-Felder. Die Beispiele der Responses API von OpenAI umfassen Eingabe-, Ausgabe-, zwischengespeicherte, Reasoning- und gesamte Token-Nutzung. Der Usage-Endpunkt der OpenAI-Organisation unterstützt Gruppierungen nach Projekt, Benutzer, API-Schlüssel, Modell, Batch und Service-Tier; der Costs-Endpunkt unterstützt Gruppierungen nach Projekt, Position und API-Schlüssel. Die Dokumentation des AI Gateway von Vercel beschreibt ähnlich Anforderungszusammenfassungen nach Projekt und API-Schlüssel, Token-Zahlen, P75-Dauer, P75 TTFT und Kosten.

Für AI-API-Observability sollten Sie Nutzung und Kosten möglichst auf Versuchsebene erfassen und immer auf Ebene der endgültigen Anfrage. Ein Fallback kann operativ korrekt und finanziell überraschend sein. Ohne Modell, Route, Nutzung und Kosten im selben Ereignis sieht Finance möglicherweise einen Kostensprung, bevor Engineering ihn erklären kann.

Die öffentlichen Preisangaben und die Startseiten-Texte von Flatkey verweisen auf klare Preise, einheitliche Abrechnung, Nutzungsanalysen und ein Dashboard für Schlüssel, Nutzung und Routing. Ein für diese Aufgabe gespeicherter Preis-Snapshot vom 18. Juni 2026 lieferte 638 Modellzeilen, 23 Anbieter und Endpunktfamilien einschließlich OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, Gemini generateContent, Bildgenerierung und OpenAI-Video. Behandeln Sie diese Zählwerte als datierten Nachweis und prüfen Sie dann die Live-Preisseite und die Dashboard-Datensätze für die konkreten Modelle in Ihrem Workflow.

Metadatenbasiertes Logging standardmäßig verwenden

Rohe Prompts und Antworten sind leistungsstarke Debugging-Tools, aber sie sind auch riskante Logs. Die Logging-Dokumentation von Cloudflares AI Gateway ist ein nützliches Referenzmuster: Sie beschreibt Request-Logs mit Prompt, Antwort, Provider, Zeitstempel, Status, Token-Nutzung, Kosten, Dauer und User-Agent und dokumentiert außerdem einen Header, der die Speicherung des rohen Request- und Response-Contents unterdrücken kann, während Metadaten wie Token-Anzahlen, Modell, Provider, Statuscode, Kosten und Dauer erhalten bleiben.

Das ist die richtige Standardhaltung für LLM-API-Logs: Erfassen Sie standardmäßig Metadaten und verlangen Sie dann einen expliziten Debug-Modus oder einen Support-Workflow, bevor rohe Inhalte gespeichert werden. Die semantischen Konventionen von OpenTelemetry GenAI kennzeichnen Eingabemeldungen, Ausgabemeldungen, Systemanweisungen, Tool-Call-Argumente und Tool-Call-Ergebnisse als Felder, die sensible Informationen enthalten können. Ihre Logging-Richtlinie sollte dies widerspiegeln.

Eine praktische Richtlinie hat vier Modi:

Kein Log: für Anfragen verwendet, die über die flüchtige Verarbeitung hinaus nicht aufbewahrt werden dürfen.
Nur Metadaten: Route, IDs, Latenz, Status, Nutzung, Kosten und Redaktionsflags.
Reduzierte Nutzlast: ausgewählte Request-/Response-Felder nach Entfernung von PII und Geheimnissen.
Rohdaten-Nutzlast: kurzlebige, zugriffsgeschützte Debug-Aufzeichnung für einen bestimmten Vorfall oder einen vom Kunden genehmigten Supportfall.

Beispielereignis eines Routing-Logs

Diese Vorlage ist absichtlich metadata-first. Passen Sie die Namen an Ihr Logging-System an, aber behalten Sie die Trennung zwischen angeforderter Route, ausgewählter Route, Versuchen, Nutzung, Kosten und Datenschutzkontrollen bei.

{
  "gateway_request_id": "gw_01jz_route_abc",
  "app_request_id": "req_9a7c",
  "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
  "client_request_id": "7c2c1b3a-4b55-4e36-bd47-8d1c2e2f2e11",
  "owner": {
    "project": "checkout-ai",
    "environment": "production",
    "api_key_id": "key_hash_6f12",
    "team": "platform",
    "workflow": "customer-chat"
  },
  "requested_route": {
    "endpoint_family": "chat_completions",
    "model": "primary-chat-model",
    "stream": true,
    "route_policy_id": "chat-prod-v8",
    "fallback_policy_id": "chat-prod-safe-fallback-v3",
    "catalog_version": "2026-06-18"
  },
  "selected_route": {
    "provider": "provider_b",
    "model": "backup-chat-model",
    "upstream_account": "acct_pool_2",
    "decision_reason": "primary_timeout",
    "policy_rule_id": "fallback_on_timeout_once"
  },
  "attempts": [
    {
      "index": 1,
      "provider": "provider_a",
      "model": "primary-chat-model",
      "provider_request_id": "req_provider_a_123",
      "status_code": 504,
      "error_class": "timeout",
      "duration_ms": 12000,
      "fallback_target": "provider_b"
    },
    {
      "index": 2,
      "provider": "provider_b",
      "model": "backup-chat-model",
      "provider_request_id": "req_provider_b_456",
      "status_code": 200,
      "duration_ms": 2400,
      "time_to_first_chunk_ms": 620,
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "input_tokens": 1284,
    "output_tokens": 312,
    "cached_input_tokens": 0,
    "reasoning_output_tokens": 0
  },
  "cost": {
    "currency": "usd",
    "estimated_amount": 0.0048,
    "line_item": "backup-chat-model"
  },
  "privacy": {
    "content_logging_mode": "metadata_only",
    "payload_redacted": true,
    "retention_class": "30_day_incident_metadata"
  }
}

Die Feldnamen sind Beispiele, kein Flatkey-API-Vertrag. Verwenden Sie sie, um zu testen, ob Ihr Gateway, Ihr Data Warehouse und Ihre Incident-Tools Routing-Fragen beantworten können, ohne den Rohinhalt zu benötigen.

Ein 10-Minuten-Triage-Workflow

Wenn ein Modell-Routing-Incident beginnt, sollte der AI API observability-Workflow kurz genug sein, damit der On-Call Engineer ihn unter Druck ausführen kann:

Die korrelierte Anfrage finden: nach App-Request-ID, Gateway-Request-ID, benutzerseitiger Fehler-ID, Provider-Request-ID oder Trace-ID suchen.
Angeforderte und ausgewählte Routen vergleichen: das angeforderte Modell, die Routenrichtlinie, die Fallback-Regel, den finalen Provider und das finale Modell bestätigen.
Die Attempt-Kette lesen: den ersten Fehler, die Anzahl der Wiederholungen, das Fallback-Ziel und das Endergebnis identifizieren.
Rate-Limit- und Quota-Kontext prüfen: verbleibende, Limit- und Reset-Header inspizieren, wenn Provider 429 oder Token-Druck zurückgeben.
Latenz von Streaming trennen: Gateway-Dauer, Provider-Dauer, Zeit bis zum ersten Chunk, Stream-Ende und Client-Disconnect vergleichen.
Nutzung und Kosten abgleichen: Token-Zählungen, Service-Tier, Kostenposition und Team-/Key-Zugehörigkeit prüfen.
Privacy-Modus prüfen: bestätigen, ob das Log nur Metadaten enthält, redigiert, roh oder absichtlich ausgelassen ist.
Die Routenaktion festlegen: die Richtlinie zurücksetzen, eine Route deaktivieren, das Traffic-Gewicht senken, das Kontingent erhöhen, Hintergrundarbeit in die Warteschlange stellen oder bei geschlossenem System fehlschlagen lassen.

Nach dem Incident dieselben Schritte in eine Dashboard-Ansicht überführen. Die schnellsten Reviews gelingen, wenn Engineering, Support und Finance denselben Event-Shape prüfen können.

Wie Flatkey in die AI-API-Observability passt

Flatkey ist für Teams positioniert, die einen API-Schlüssel, einen kompatiblen Router-Endpunkt, klare Preise, einheitliche Abrechnung und ein Dashboard für Schlüssel, Nutzung und Routing wünschen. Für diesen Artikel ist der relevante Nachweisweg praktisch: Richten Sie einen Staging-Client auf https://router.flatkey.ai/v1, senden Sie Anfragen über einen Nicht-Produktionsschlüssel, lösen Sie, wo möglich, einen kontrollierten Fehler aus, und bestätigen Sie, welche Nutzungs-, Routing-, Fehler- und Kostendatensätze im Dashboard erscheinen.

Verwenden Sie per-key AI usage tracking, um Staging-, Produktions-, Kunden- und Workflow-Traffic zu trennen. Verwenden Sie AI API quota management, damit Fallback nicht das gemeinsame Budget aufbraucht. Verwenden Sie AI API cost attribution by team, wenn Routing-Änderungen einen Verantwortlichen aus dem Finanzbereich benötigen.

Der CTA ist einfach: Wenn Ihr Team AI API observability hinter einem einzigen Schlüssel testen möchte, holen Sie sich einen Schlüssel, führen Sie eine Staging-Route über Flatkey aus und prüfen Sie, ob die Logs die oben genannten Incident-Fragen beantworten, bevor Sie sich in der Produktion auf automatisches Umschalten verlassen.

Häufig gestellte Fragen

Was ist AI API Observability?

AI API Observability ist die Fähigkeit, den Modell-API-Datenverkehr über Request-IDs, Traces, Modelle, Provider, Routing-Entscheidungen, Wiederholungen, Fallback, Nutzung, Kosten, Latenz, Fehler und Datenschutzkontrollen hinweg zu untersuchen. Bei Routing-Vorfällen sollte sie sowohl erklären, was der Client angefordert hat, als auch, was das Gateway tatsächlich ausgewählt hat.

Was sollten LLM-API-Logs erfassen?

LLM-API-Logs sollten Korrelations-IDs, Owner-Metadaten, die angeforderte Route, die ausgewählte Route, die Retry-Kette, Latenz, Streaming-Status, Token-Nutzung, Kosten, Abschlussgrund, Fehlerklasse, Rate-Limit-Kontext und den Content-Logging-Modus erfassen. Roh-Prompts und -Ausgaben sollten optional, zugriffsbeschränkt und nach Möglichkeit maskiert sein.

Warum sollten angefordertes Modell und Antwortmodell getrennt geloggt werden?

Das angeforderte Modell zeigt die Absicht des Clients. Das Antwortmodell zeigt, was die Anfrage tatsächlich bedient hat. In einem Fallback-Vorfall können diese abweichen. Beide zu protokollieren ist entscheidend für Qualitätsprüfung, Kostenabgleich und die Kommunikation mit dem Support.

Wie helfen Request-IDs dem Support des Providers?

Provider-Request-IDs identifizieren den nachgelagerten API-Aufruf. Eine vom Aufrufer bereitgestellte Request-ID kann helfen, wenn ein Timeout verhindert, dass der Response-Header Ihren Client erreicht. Bewahren Sie beide IDs im Incident-Datensatz auf, zusammen mit der Gateway-Request-ID und der Trace-ID.

Sollte das Monitoring eines AI Gateways rohe Prompts speichern?

Nicht standardmäßig. AI Gateway Monitoring benötigt in der Regel zuerst Metadaten: Route, Modell, Status, Dauer, Nutzung, Kosten und Datenschutzmodus. Speichern Sie rohe Prompts oder Antworten nur im Rahmen eines definierten Debug-, Support- oder Audit-Workflows mit Aufbewahrungs- und Zugriffskontrollen.

Verwendete Quellen

Abschließende Prüfung, bevor Sie das Routing ändern

Bevor Sie dem automatischen Fallback vertrauen, machen Sie AI API-Beobachtbarkeit zu einem Teil des Release-Gates. Bestätigen Sie die Routing-Richtlinie, die Retry-Stufe, die Token- und Kostenfelder, Rate-Limit-Header, Streaming-Zeitstempel, Provider-Request-IDs, den Privacy-Modus und die Aufbewahrungsklasse. Führen Sie dann einen kontrollierten Vorfall in der Staging-Umgebung durch und überprüfen Sie, dass die Logs das Ergebnis ohne Zugriff auf rohe Prompts erklären können.

Flatkey reduziert die Integrationsfläche auf einen Schlüssel und eine kompatible Basis-URL. Um diese Zuverlässigkeitsebene mit Ihrem eigenen Traffic zu bewerten, erhalten Sie einen Schlüssel, führen Sie einen Staging-Workflow aus und prüfen Sie die Routing-, Nutzungs-, Kosten- und Fehlerdatensätze, die Ihr Team bei einem echten Vorfall benötigt.