Wichtige Links
*Das Service-Health-Dashboard ist derzeit nur für Enterprise-API-Kund:innen verfügbar.
Mit den richtigen Standardeinstellungen beginnen
Wenn Sie das Service-Health-Dashboard öffnen, ist standardmäßig Folgendes ausgewählt:
Alle Projekte
Letzte 30 Tage
Stündliche Auflösung
Diese Ansicht dient nur zur Orientierung. Für eine aussagekräftige Fehlerbehebung ist immer eine Filterung erforderlich.
Vor der Untersuchung filtern
Die korrekte Filterung ist der wichtigste Schritt. Die meisten Fehlinterpretationen entstehen durch das Vermischen von Modellen, Tiers oder Projekten.
Nach Modell filtern (jeweils nur eins)
Filtern Sie immer auf ein einzelnes Modell.
Warum:
Probleme bei Modellen mit wenig Traffic können durch Traffic mit höherem Volumen verdeckt werden
Modelle mit hohem Volumen können lokale Probleme global erscheinen lassen
Verschiedene Modelle haben unterschiedliche Leistungsziele
Hinweis: Wenn Sie mehrere Modelle auswählen, werden diese aggregiert – es wird nicht zwischen ihnen umgeschaltet.
Nach Service-Tier filtern
Wenn Sie mehr als ein Tier verwenden (Standard, Priority, Scale), filtern Sie immer auf das Tier, das Sie untersuchen.
Warum:
Tiers haben unterschiedliche Leistungsmerkmale
Priority- und Scale-Tiers haben definierte SLAs
Das Vermischen von Tiers verschleiert die Leistung kostenpflichtiger Tiers
Das ist besonders wichtig für die Latenzanalyse.
Nach Projekt filtern
Standardmäßig zeigt Service Health alle Projekte an.
Filtern Sie zur Fehlerbehebung auf das Projekt bzw. die Projekte, bei denen das Problem beobachtet wurde.
Warum:
Ein einzelnes Projekt mit hohem Volumen kann Metriken dominieren
Kleinere betroffene Projekte können durch nicht zusammenhängenden Traffic verdeckt werden
Lassen Sie nur dann „Alle Projekte“ ausgewählt, wenn Sie glauben, dass das Problem tatsächlich die gesamte Organisation betrifft.
Fehlerbehebung bei Fehlern
Die Ansicht „HTTP Requests“ verwenden
So untersuchen Sie Fehler:
Nach Modell und Tier filtern
Um von „Uptime“ zu „HTTP Requests“ zu wechseln, klicken Sie auf den Tab „HTTP Requests“
Diese Ansicht zeigt Gesamtanfragen und Fehleranzahlen nach HTTP-Statuscode. Zoomen Sie auf eine Auflösung auf Minutenebene, um feinkörnige Spitzen oder Änderungen zu identifizieren.
Fehlerraten interpretieren, nicht Anzahlen
Einige Fehler sind in jedem Produktionssystem zu erwarten. Konzentrieren Sie sich auf den prozentualen Fehleranteil, nicht auf rohe Gesamtzahlen.
Je höher Ihr Gesamtvolumen, desto höher die potenzielle Anzahl an Fehlern – selbst bei einer extrem niedrigen Fehlerrate.
Wenn Fehler in Service Health fehlen
Wenn Sie clientseitige Fehler sehen, aber keine entsprechenden Daten in Service Health:
Haben Anfragen OpenAI wahrscheinlich nicht erreicht
Liegt das Problem in der Regel vorgelagert (Time-outs, Proxys, Netzwerk)
Das ist bei aggressiven clientseitigen Time-outs häufig der Fall.
Fehlerbehebung bei Latenz
Die Latenzanalyse ist auf Priority- und Scale-Tiers am aussagekräftigsten, da diese definierte SLAs haben. Das Standard-Tier kann eine größere Latenzvariation zeigen und hat keine garantierte Latenz.
Wichtige Metriken
Um jede dieser Metriken anzuzeigen, klicken Sie auf den entsprechenden Tab:
Token Velocity
Pro Sekunde generierte Token.
Unabhängig von der Prompt-Größe.
Request Time
Gesamtdauer der Anfrage.
Stark beeinflusst von Ausgabegröße und Reasoning.
Time to First Token (TTFT)
Zeit bis zur Generierung des ersten Tokens.
Stark beeinflusst von der Größe des nicht gecachten Eingabe-Prompts und von Reasoning.
Prüfen Sie immer die Perzentile P50 / P75 / P95. Durchschnittswerte können die Auswirkungen auf echte Nutzer:innen verschleiern.
6. Latenz mit Token-Nutzung korrelieren
Service Health zeigt, wann sich das Verhalten geändert hat. Usage-Daten helfen zu erklären, warum.
Führen Sie im Usage-Dashboard Folgendes durch, um sicherzustellen, dass Sie sich die für Ihre Ansicht im Service-Health-Dashboard relevanten Daten ansehen:
Nach demselben Projekt und Modell filtern
Falls zutreffend, nach Service-Tier gruppieren
Konzentrieren Sie sich auf Output-Token, da diese die Latenz am stärksten beeinflussen
Für eine tiefergehende Analyse exportieren Sie Activity Data und untersuchen die Token pro Anfrage im Zeitverlauf.
7. Was Sie mit dem Support teilen sollten (falls nötig)
Wenn Sie den Support kontaktieren, geben Sie Folgendes an:
Betroffene Org-IDs (das ist wichtig)
Betroffene Endpunkte (Chat Completions, Responses usw.) (das ist wichtig)
Betroffene Modelle (das ist wichtig)
Handelt es sich um ein Scale- oder Priority-Tier? (das ist wichtig)
Zeiträume mit Zeitzone für Latenz oder Fehler (das ist wichtig)
Relevante x-request-id oder X-Client-Request-Id (oft wichtig; wenn möglich angeben)
Zeitstempel mit Zeitzone (oder zumindest das Datum) der angegebenen Anfragen
Latenz – wenn Sie Beispiele für langsame Anfragen teilen, geben Sie an, wie lange es auf Ihrer Seite gedauert hat. Idealerweise geben Sie auch die Zeitstempel dafür an, wann die Anfrage gesendet und wann sie empfangen wurde.
Fehler – bitte teilen Sie den ungefähren Prozentsatz fehlgeschlagener/fehlerhafter Anfragen, Antwortcode(s), Fehlermeldung(en) und wie lange es bis zur Fehlerantwort gedauert hat
Projekt-ID im Zusammenhang mit den Anfragen
Beeinflusst dies Anfragen zur Datenresidenz? Wenn ja, welche?
Beschreibungen der Trends, die Sie beobachten
Fehler: Ungefährer % der fehlgeschlagenen/fehlerhaften Anfragen
Latenz: Welche Perzentile betroffen sind (p50 / p90 / p95 / p99) und wie hoch sie im Vergleich zur Baseline der Kund:innen sind
Beides: Screenshots oder Tabelle mit Fehler- oder Latenzdaten (Wie haben Sie festgestellt, dass Fehlerraten oder Latenz höher als erwartet sind?)
Häufige Fehlerbehebungsszenarien
Time-outs treten auf, aber Service Health sieht normal aus
Mögliche Ursache: Anfragen laufen ab, bevor sie OpenAI erreichen.
Prüfen Sie:
Client- oder Proxy-Time-out-Einstellungen
Änderungen im lokalen Netzwerk oder Load Balancer
Ob im Service-Health-Dashboard 499-Fehler vorhanden sind (diese können in Ihren eigenen Systemen als 5xx-Fehler erscheinen).
Latenz ohne Deployment gestiegen
Mögliche Ursache: Die Größe der Output-Token oder die Nutzung von Reasoning hat zugenommen und\oder der Traffic hat sich zwischen Service-Tiers verlagert
Prüfen Sie:
Durchschnittliche Output-Token pro Anfrage im Usage-Dashboard (erfordert das Herunterladen von Daten und das Dividieren der Output-Token durch die Gesamtzahl der Anfragen).
Perzentile für Request Time und TTFT im Service-Health-Dashboard.
Priority- oder Scale-Tier scheint langsam
Mögliche Ursache: Metriken werden über Tiers hinweg vermischt (d. h. Traffic auf dem Standard-Tier verdeckt die Leistung kostenpflichtiger Tiers)
Prüfen Sie:
Filter sind auf ein einzelnes Tier und Modell beschränkt
Vergleich der Token Velocity zwischen Tiers
Spitze bei 5XX-Fehlern
Wahrscheinliche Ursache: Vorübergehende Ausfälle, die einen kleinen Prozentsatz des Traffics betreffen.
Prüfen Sie:
Prozentuale Fehlerrate
Ob sich das Traffic-Volumen gleichzeitig verändert hat
Problem betrifft nur ein Projekt
Wahrscheinliche Ursache: Projektspezifische Konfiguration oder Nutzungsmuster.
Prüfen Sie:
Filterung auf Projektebene
Vergleich mit nicht betroffenen Projekten
Wichtigste Erkenntnisse zum Schluss
Vor der Interpretation von Metriken nach Modell, Tier und, wo relevant, Projekt filtern
Für die Latenzanalyse Perzentile statt Durchschnittswerte verwenden
Kleine Fehlerraten sind zu erwarten
Fehlende Daten deuten in der Regel auf vorgelagerte Probleme hin
Usage-Daten können helfen zu erklären, warum sich die Latenz geändert hat; Service Health hilft zu zeigen, wann