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 mehrere Servicestufen nutzt (Standard, Schnellmodus, früher Priority Processing, oder Scale Tier), filtere immer nach der Servicestufe, die du untersuchst.
Warum:
Servicestufen weisen unterschiedliche Leistungsmerkmale auf
Für den Schnellmodus und Scale Tier gelten definierte SLAs
Das Vermischen von Servicestufen verschleiert die Leistung kostenpflichtiger Servicestufen
Dies ist für Latenzanalysen besonders wichtig.
Bei bestehenden Modellen wird Datenverkehr im Schnellmodus im Nutzungsdashboard weiterhin als „priority“ angezeigt.
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.
Fehlerbehebung bei Latenzproblemen
Latenzanalysen sind beim Schnellmodus und bei Scale Tier besonders aussagekräftig, da für diese Servicestufen definierte SLAs gelten. Bei der Standardstufe kann die Latenz stärker schwanken. Eine bestimmte Latenz wird nicht garantiert.
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.
Latenz und Token-Nutzung in Beziehung setzen
Service Health zeigt, wann sich das Verhalten geändert hat. Nutzungsdaten helfen zu erklären, warum.
Gehe im Nutzungsdashboard wie folgt vor, damit du die Daten siehst, die zu deiner Ansicht im Service Health Dashboard passen:
Filtere nach demselben Projekt und Modell.
Gruppiere nach Servicestufe, falls zutreffend.
Konzentriere dich auf die Ausgabe-Token, da sie die Latenz am stärksten beeinflussen.
Für eine genauere Analyse kannst du die Aktivitätsdaten exportieren und die Token-Anzahl pro Anfrage im Zeitverlauf untersuchen.
Welche Informationen der Support bei Bedarf benötigt
Wenn du den Support kontaktierst, gib Folgendes an:
IDs der betroffenen Organisationen (wichtig)
Betroffene Endpunkte, etwa Chat Completions oder Responses (wichtig)
Betroffene Modelle (wichtig)
Ob das Problem im Schnellmodus oder im Scale Tier auftritt (wichtig)
Zeiträume mit Zeitzone, in denen Latenzprobleme oder Fehler auftreten (wichtig)
Zugehörige x-request-id oder X-Client-Request-Id, falls verfügbar
Zeitstempel mit Zeitzone oder zumindest das Datum der angegebenen Anfragen
Falls verfügbar, ergänze auch:
Die Projekt-ID der Anfragen
Ob Anfragen mit Datenresidenz betroffen sind und welche
Beschreibungen der beobachteten Trends
Gib je nach Art des Problems Folgendes an:
Fehler: Ungefährer Prozentsatz der Anfragen, die fehlschlagen oder Fehler zurückgeben, Antwortcodes, Fehlermeldungen und die Zeit bis zum Empfang der Fehlerantwort.
Latenz: Welche Perzentile betroffen sind (P50 / P90 / P95 / P99), wie hoch die Werte im Vergleich zu deinen üblichen Werten sind sowie Beispiele langsamer 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.
Schnellmodus oder Scale Tier erscheint langsam
Mögliche Ursache: Kennzahlen verschiedener Servicestufen werden vermischt, sodass Datenverkehr der Standardstufe die Leistung der kostenpflichtigen Servicestufe verdeckt.
Prüfe Folgendes:
Die Filter sind auf eine einzige Servicestufe und ein einziges Modell beschränkt.
Vergleich der Token-Geschwindigkeit zwischen Servicestufen.
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.