Důležité odkazy
Řídicí panel stavu služby (aktuálně dostupný jen zákazníkům Enterprise API)
Začněte se správnými výchozími hodnotami
Když otevřete řídicí panel stavu služby, výchozí nastavení je:
Všechny projekty
Posledních 30 dní
Hodinové rozlišení
Toto zobrazení je užitečné jen pro orientaci. Smysluplné řešení potíží vždy vyžaduje filtrování.
Před zkoumáním filtrujte
Správné filtrování je nejdůležitější krok. Většina chybných interpretací vzniká smícháním modelů, úrovní nebo projektů.
Filtrujte podle modelu (vždy po jednom)
Vždy filtrujte na jeden model.
Proč:
Problémy u modelů s nízkým provozem může skrýt provoz s vyšším objemem
Modely s vysokým objemem mohou způsobit, že lokální problémy vypadají jako globální
Různé modely mají různé výkonnostní cíle
Poznámka: výběr více modelů je agreguje — nepřepíná mezi nimi.
Filtrujte podle úrovně služeb
Pokud používáte více než jednu úroveň (standardní, prioritní, škálování), vždy filtrujte na úroveň, kterou zkoumáte.
Proč:
Úrovně mají odlišné výkonnostní charakteristiky
Prioritní úroveň a úroveň škálování mají definované smlouvy SLA
Smíchání úrovní zakrývá výkon placené úrovně
To je obzvlášť důležité pro analýzu latence.
Filtrujte podle projektu
Ve výchozím nastavení Service Health zobrazuje všechny projekty.
Při řešení potíží filtrujte na projekty, ve kterých byl problém pozorován.
Proč:
Jeden projekt s vysokým objemem může dominovat metrikám.
Menší ovlivněné projekty může zakrýt nesouvisející provoz.
Možnost „Všechny projekty“ nechte vybranou jen tehdy, pokud se domníváte, že problém skutečně zasahuje celou organizaci.
Řešení potíží s chybami
Použijte zobrazení požadavků HTTP
Chcete-li prozkoumat chyby:
Filtrujte podle modelu a úrovně služeb.
Otevřete kartu HTTP Requests místo karty Uptime.
Toto zobrazení ukazuje celkový počet požadavků a počty chyb podle stavového kódu HTTP. Přibližte zobrazení na minutové rozlišení, abyste identifikovali podrobné špičky nebo změny.
Interpretujte míry chyb, ne počty
V každém produkčním systému se očekávají určité chyby. Zaměřte se na procento chyb, ne na hrubé součty.
Čím větší je celkový objem, tím větší může být počet chyb i při extrémně nízké chybovosti.
Když ve Service Health chybí chyby
Pokud vidíte chyby na straně klienta, ale žádná odpovídající data ve Service Health:
Požadavky se pravděpodobně nedostaly k OpenAI.
Problém je obvykle upstream (časové limity, proxy servery, síť).
To je běžné u agresivních časových limitů na straně klienta.
Řešení potíží s latencí
Analýza latence má největší smysl na prioritní úrovni a úrovni škálování, které mají definované smlouvy SLA. Standardní úroveň může vykazovat větší variabilitu latence a nemá garantovanou latenci.
Klíčové metriky
Každou metriku zobrazíte kliknutím na příslušnou kartu:
Rychlost tokenů: Tokeny generované za sekundu; nezávisí na velikosti promptu.
Doba požadavku: Celková doba trvání požadavku; výrazně ji ovlivňuje velikost výstupu a uvažování.
Čas do prvního tokenu (TTFT): Doba do vygenerování prvního tokenu; výrazně ji ovlivňuje velikost neuloženého vstupního promptu v mezipaměti a uvažování.
Vždy kontrolujte percentily P50 / P75 / P95. Průměry mohou skrývat dopad na skutečné uživatele.
6. Korelace latence s využitím tokenů
Service Health ukazuje, kdy se chování změnilo. Data o využití pomáhají vysvětlit, proč.
V řídicím panelu využití proveďte následující kroky, abyste měli jistotu, že se díváte na data relevantní pro vaše zobrazení v řídicím panelu Service Health:
Filtrujte na stejný projekt a model.
Seskupte podle úrovně služeb, pokud je to relevantní.
Zaměřte se na výstupní tokeny, které latenci ovlivňují nejvýrazněji.
Pro hlubší analýzu exportujte Activity Data a zkoumejte tokeny na požadavek v průběhu času.
7. Co sdílet s podporou (v případě potřeby)
Pokud kontaktujete podporu, uveďte:
Ovlivněná ID organizací (důležité)
Ovlivněné koncové body, například Chat Completions nebo Responses (důležité)
Ovlivněné modely (důležité)
Zda jde o úroveň škálování nebo prioritní úroveň (důležité)
Časová období s časovým pásmem pro latenci nebo chyby (důležité)
Relevantní x-request-id nebo X-Client-Request-Id, pokud je k dispozici
Časová razítka s časovým pásmem, nebo alespoň datum, pro požadavky, které poskytnete
Pokud jsou k dispozici, uveďte také:
ID projektu související s požadavky
Zda jsou ovlivněny požadavky na datovou rezidenci a které z nich
Popisy trendů, které pozorujete
U typu problému uveďte:
Chyby: Přibližné procento selhávajících nebo chybových požadavků, kódy odpovědí, chybové zprávy a jak dlouho trvalo obdržení chybové odpovědi.
Latence: Které percentily jsou ovlivněny (P50 / P90 / P95 / P99), jak vysoké jsou ve srovnání se základní úrovní zákazníka a příklady pomalých požadavků s časovými razítky odeslání a přijetí.
Obojí: Snímky obrazovky nebo tabulka dat o chybách či latenci a také jak jste určili, že míry chyb nebo latence byly vyšší, než se očekávalo.
Běžné scénáře řešení potíží
Dochází k časovým limitům, ale Service Health vypadá normálně
Možná příčina: požadavky překračují časový limit ještě před dosažením OpenAI.
Zkontrolujte:
Nastavení časových limitů klienta nebo proxy serveru
Změny v místní síti nebo nástroji pro vyrovnávání zátěže
Přítomnost chyb 499 v řídicím panelu Service Health (ve vašich vlastních systémech se mohou zobrazovat jako chyby 5xx).
Latence se zvýšila bez nasazení
Možná příčina: zvýšila se velikost výstupu v tokenech nebo využití uvažování a/nebo se provoz přesunul mezi úrovněmi služeb.
Zkontrolujte:
Průměrný počet výstupních tokenů na požadavek v řídicím panelu využití (vyžaduje stažení dat a vydělení výstupních tokenů celkovým počtem požadavků).
Percentily Request Time a TTFT v řídicím panelu stavu služby.
Prioritní úroveň nebo úroveň škálování působí pomalu
Možná příčina: metriky jsou smíchané napříč úrovněmi, takže provoz standardní úrovně zakrývá výkon placené úrovně.
Zkontrolujte:
Filtry jsou omezeny na jednu úroveň a jeden model.
Porovnání rychlosti tokenů mezi úrovněmi.
Nárůst chyb 5XX
Pravděpodobná příčina: přechodné výpadky ovlivňující malé procento provozu.
Zkontrolujte:
Procento chybovosti
Zda se současně změnil objem provozu
Problém ovlivňuje jen jeden projekt
Pravděpodobná příčina: konfigurace nebo vzor využití specifický pro projekt.
Zkontrolujte:
Filtrování na úrovni projektu
Porovnání s neovlivněnými projekty
Závěrečná shrnutí
Před interpretací metrik filtrujte podle modelu, úrovně a projektu, pokud je to relevantní.
Pro analýzu latence používejte percentily, ne průměry.
Nízké míry chyb jsou očekávané.
Chybějící data obvykle ukazují na problémy upstream.
Data o využití mohou pomoci vysvětlit, proč se latence změnila; Service Health ukazuje, kdy se chování změnilo.