Wichtige Links
Service-Health-Dashboard (derzeit nur für Enterprise-API-Kund:innen verfügbar)
Mit den richtigen Standardeinstellungen beginnen
Wenn du das Service-Health-Dashboard öffnest, sind standardmäßig ausgewählt:
Alle Projekte
Letzte 30 Tage
Stündliche Auflösung
Diese Ansicht dient nur zur Orientierung. Für sinnvolle Fehlerbehebung ist Filtern immer erforderlich.
Vor der Untersuchung filtern
Korrektes Filtern ist der wichtigste Schritt. Die meisten Fehlinterpretationen entstehen, wenn Modelle, Stufen oder Projekte vermischt werden.
Nach Modell filtern (jeweils eines)
Filtere immer auf ein einzelnes Modell.
Warum:
Probleme bei Modellen mit wenig Traffic können durch Traffic mit höherem Volumen verborgen werden
Modelle mit hohem Volumen können lokale Probleme global erscheinen lassen
Verschiedene Modelle haben unterschiedliche Leistungsziele
Hinweis: Wenn du mehrere Modelle auswählst, werden sie aggregiert – es wird nicht zwischen ihnen gewechselt.
Nach Servicestufe filtern
Wenn du mehr als eine Stufe nutzt (Standard, Priority, Scale), filtere immer auf die Stufe, die du untersuchst.
Warum:
Stufen haben unterschiedliche Leistungsmerkmale
Für Priority- und Scale-Stufen gelten definierte SLAs
Das Vermischen von Stufen verschleiert die Leistung bezahlter Stufen
Das ist besonders wichtig für die Latenzanalyse.
Nach Projekt filtern
Standardmäßig zeigt Service Health alle Projekte an.
Filtere bei der Fehlerbehebung auf die Projekte, in denen das Problem beobachtet wurde.
Warum:
Ein einzelnes Projekt mit hohem Volumen kann Metriken dominieren.
Kleinere betroffene Projekte können durch nicht zugehörigen Traffic verdeckt werden.
Lass „Alle Projekte“ nur ausgewählt, wenn du davon ausgehst, dass das Problem wirklich die gesamte Organisation betrifft.
Fehlerbehebung
HTTP-Anfragenansicht verwenden
So untersuchst du Fehler:
Nach Modell und Servicestufe filtern.
Öffne den Tab HTTP-Anfragen statt des Tabs Verfügbarkeit.
Diese Ansicht zeigt die Gesamtzahl der Anfragen und die Fehlerzahlen nach HTTP-Statuscode. Zoome auf Minutenauflösung, um feingranulare Spitzen oder Änderungen zu erkennen.
Fehlerraten interpretieren, nicht absolute Zahlen
In jedem Produktionssystem sind einige Fehler zu erwarten. Konzentriere dich auf den Fehler-prozentsatz, nicht auf Rohsummen.
Je größer dein Gesamtvolumen ist, desto höher kann die Zahl der Fehler selbst bei einer extrem niedrigen Fehlerrate sein.
Wenn Fehler in Service Health fehlen
Wenn du clientseitige Fehler siehst, aber keine entsprechenden Daten in Service Health:
Die Anfragen haben OpenAI wahrscheinlich nicht erreicht.
Das Problem liegt meist vorgelagert (Timeouts, Proxys, Netzwerk).
Das kommt häufig bei aggressiven clientseitigen Timeouts vor.
Latenz beheben
Eine Latenzanalyse ist am aussagekräftigsten für Priority- und Scale-Stufen, für die definierte SLAs gelten. Die Standardstufe kann größere Latenzschwankungen aufweisen und bietet keine garantierte Latenz.
Wichtige Metriken
Um die einzelnen Metriken anzuzeigen, klicke auf den entsprechenden Tab:
Token-Geschwindigkeit: Pro Sekunde generierte Token; unabhängig von der Prompt-Größe.
Anfragezeit: Gesamtdauer der Anfrage; stark von Ausgabegröße und Reasoning beeinflusst.
Time to First Token (TTFT): Zeit bis zur Generierung des ersten Tokens; stark beeinflusst von der Größe des nicht gecachten Eingabe-Prompts und vom Reasoning.
Prüfe immer die Perzentile P50 / P75 / P95. Durchschnittswerte können die tatsächlichen Auswirkungen auf Nutzer:innen verschleiern.
6. Latenz mit Token-Nutzung korrelieren
Service Health zeigt, wann sich das Verhalten geändert hat. Nutzungsdaten helfen zu erklären, warum.
Gehe im Nutzungs-Dashboard wie folgt vor, um sicherzustellen, dass du die Daten betrachtest, die für deine Ansicht im Service-Health-Dashboard relevant sind:
Filtere auf dasselbe Projekt und Modell.
Gruppiere nach Servicestufe, falls zutreffend.
Konzentriere dich auf Ausgabe-Token, da sie die Latenz am stärksten beeinflussen.
Exportiere für eine tiefere Analyse Aktivitätsdaten und untersuche die Token pro Anfrage im Zeitverlauf.
7. Was du bei Bedarf mit dem Support teilen solltest
Wenn du den Support kontaktierst, füge Folgendes hinzu:
Betroffene Org IDs (wichtig)
Betroffene Endpunkte, z. B. Chat Completions oder Responses (wichtig)
Betroffene Modelle (wichtig)
Ob dies die Scale- oder Priority-Stufe betrifft (wichtig)
Zeiträume mit Zeitzone für Latenz oder Fehler (wichtig)
Relevante x-request-id oder X-Client-Request-Id, falls verfügbar
Zeitstempel mit Zeitzone oder mindestens das Datum für die von dir bereitgestellten Anfragen
Falls verfügbar, füge außerdem Folgendes hinzu:
Projekt-ID im Zusammenhang mit den Anfragen
Ob Anfragen mit Datenresidenz betroffen sind und welche
Beschreibungen der Trends, die du siehst
Gib für die Problemart Folgendes an:
Fehler: Ungefährer Prozentsatz fehlgeschlagener oder fehlerhafter Anfragen, Antwortcodes, Fehlermeldungen und wie lange es dauerte, bis die Fehlerantwort einging.
Latenz: Welche Perzentile betroffen sind (P50 / P90 / P95 / P99), wie hoch sie im Vergleich zur Baseline der Kund:innen sind, sowie Beispiele für langsame Anfragen mit Sende- und Empfangszeitstempeln.
Beides: Screenshots oder eine Tabelle mit Fehler- oder Latenzdaten sowie eine Erklärung, wie du festgestellt hast, dass Fehlerraten oder Latenz höher als erwartet waren.
Häufige Fehlerbehebungsszenarien
Timeouts treten auf, aber Service Health sieht normal aus
Mögliche Ursache: Anfragen laufen in einen Timeout, bevor sie OpenAI erreichen.
Prüfe:
Timeout-Einstellungen von Client oder Proxy
Änderungen am lokalen Netzwerk oder Load Balancer
Vorhandensein von 499-Fehlern im Service-Health-Dashboard (diese können in deinen eigenen Systemen als 5xx-Fehler erscheinen).
Latenz ohne Deployment gestiegen
Mögliche Ursache: Die Größe der Ausgabe-Token oder die Reasoning-Nutzung ist gestiegen und/oder der Traffic hat sich zwischen Servicestufen verschoben.
Prüfe:
Durchschnittliche Ausgabe-Token pro Anfrage im Nutzungs-Dashboard (erfordert das Herunterladen der Daten und das Teilen der Ausgabe-Token durch die Gesamtzahl der Anfragen).
Perzentile für Anfragezeit und TTFT im Service-Health-Dashboard.
Priority Tier oder Scale Tier wirkt langsam
Mögliche Ursache: Metriken werden über mehrere Stufen hinweg vermischt. Dadurch verdeckt Traffic der Standardstufe die Leistung der bezahlten Stufe.
Prüfe:
Die Filter sind auf eine einzelne Stufe und ein einzelnes Modell beschränkt.
Vergleich der Token-Geschwindigkeit zwischen Stufen.
Anstieg der 5XX-Fehler
Wahrscheinliche Ursache: Vorübergehende Ausfälle betreffen einen kleinen Prozentsatz des Traffics.
Prüfe:
Fehlerrate in Prozent
Ob sich das Traffic-Volumen gleichzeitig geändert hat
Problem betrifft nur ein Projekt
Wahrscheinliche Ursache: projektspezifische Konfiguration oder Nutzungsmuster.
Prüfe:
Filterung auf Projektebene
Vergleich mit nicht betroffenen Projekten
Wichtigste Erkenntnisse
Filtere vor der Interpretation von Metriken nach Modell, Stufe und Projekt, sofern relevant.
Verwende für Latenzanalysen Perzentile, keine Durchschnittswerte.
Niedrige Fehlerraten sind zu erwarten.
Fehlende Daten deuten meist auf vorgelagerte Probleme hin.
Nutzungsdaten können erklären, warum sich die Latenz geändert hat; Service Health zeigt, wann sich das Verhalten geändert hat.