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.
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. Welche Angaben der Support benötigt (falls erforderlich)
Wenn du den Support kontaktierst, gib Folgendes an:
Betroffene Organisations-IDs (wichtig)
Betroffene Endpunkte wie Chat Completions oder Responses (wichtig)
Betroffene Modelle (wichtig)
Ob der Schnellmodus oder Scale Tier betroffen ist (wichtig)
Zeiträume mit Zeitzone für Latenzen oder Fehler (wichtig)
Relevante x-request-id oder X-Client-Request-Id, falls verfügbar
Zeitstempel mit Zeitzone oder zumindest das Datum für die von dir bereitgestellten Anfragen
Falls verfügbar, gib außerdem Folgendes an:
Projekt-ID zu den Anfragen
Ob Anfragen mit Datenresidenz betroffen sind und welche
Beschreibungen der beobachteten Entwicklungen
Gib je nach Problemtyp Folgendes an:
Fehler: Ungefährer Anteil fehlgeschlagener oder fehlerhafter Anfragen, Antwortcodes, Fehlermeldungen und Dauer bis zum Erhalt der Fehlerantwort.
Latenz: Betroffene Perzentile (P50/P90/P95/P99), ihre Höhe im Vergleich zum Ausgangsniveau des Kundenunternehmens sowie Beispiele für langsame Anfragen mit Sende- und Empfangszeitstempeln.
Beides: Screenshots oder eine Tabelle mit Fehler- oder Latenzdaten sowie eine Erläuterung, wie du festgestellt hast, dass Fehlerraten oder Latenzen 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.