Důležité odkazy
*Panel Service Health je aktuálně dostupný pouze zákazníkům Enterprise API.
Začněte se správným výchozím nastavením
Když otevřete panel Service Health, 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í problémů vždy vyžaduje filtrování.
Než začnete zkoumat, nejprve filtrujte
Správné filtrování je nejdůležitější krok. Většina chybných interpretací vzniká mícháním modelů, úrovní nebo projektů.
Filtrujte podle modelu (vždy jen jednoho)
Vždy filtrujte na jeden model.
Proč:
Problémy u modelů s nízkým provozem mohou být skryté kvůli modelům s vyšším objemem provozu
Modely s vysokým objemem provozu mohou způsobit, že lokální problémy vypadají jako globální
Různé modely mají různé cíle výkonu
Poznámka: výběr více modelů je agreguje — nepřepíná mezi nimi.
Filtrujte podle úrovně služby
Pokud používáte více než jednu úroveň (standard, priority, scale), vždy filtrujte na úroveň, kterou zkoumáte.
Proč:
Úrovně mají odlišné výkonnostní charakteristiky
Úrovně priority a scale mají definované SLA
Míchání úrovní zakrývá výkon placených úrovní
To je obzvlášť důležité při analýze latence.
Filtrujte podle projektu
Ve výchozím nastavení Service Health zobrazuje všechny projekty.
Při řešení problémů filtrujte na projekt(y), kde byl problém zaznamenán.
Proč:
Jeden projekt s vysokým objemem provozu může dominovat metrikám
Menší zasažené projekty mohou být překryté nesouvisejícím provozem
Možnost „Všechny projekty“ ponechte vybranou jen tehdy, pokud se domníváte, že se problém skutečně týká celé organizace.
Řešení chyb
Použijte zobrazení HTTP Requests
Pro zkoumání chyb:
Filtrujte podle modelu a úrovně
Chcete-li přepnout z Uptime na HTTP Requests, klikněte na kartu HTTP Requests
Toto zobrazení ukazuje celkový počet požadavků a počty chyb podle stavového kódu HTTP. Přibližte na minutové rozlišení, abyste identifikovali detailní špičky nebo změny.
Vyhodnocujte míru chyb, ne počty
Některé chyby jsou očekávatelné v každém produkčním systému. Zaměřte se na procento chyb, ne na hrubé počty.
Čím větší je váš celkový objem, tím větší může být i počet chyb, i při extrémně nízké chybovosti.
Když chyby v Service Health chybí
Pokud vidíte chyby na straně klienta, ale v Service Health pro ně neexistují odpovídající data:
Požadavky se pravděpodobně k OpenAI vůbec nedostaly
Problém je obvykle upstream (timeouty, proxy, síťová vrstva)
To je běžné u agresivních timeoutů na straně klienta.
Řešení problémů s latencí
Analýza latence je nejpřínosnější u úrovní priority a scale, které mají definované SLA. Úroveň standard může vykazovat větší kolísání latence a nemá garantovanou latenci.
Klíčové metriky
Každou z těchto metrik zobrazíte kliknutím na příslušnou kartu:
Rychlost tokenů
Počet tokenů vygenerovaných za sekundu.
Nezávislé na velikosti promptu.
Doba požadavku
Celková doba trvání požadavku.
Silně ovlivněná velikostí výstupu a uvažováním.
Čas do prvního tokenu (TTFT)
Doba do vygenerování prvního tokenu.
Silně ovlivněná velikostí necachovaného vstupního promptu a uvažováním.
Vždy kontrolujte percentily P50 / P75 / P95. Průměry mohou skrýt 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č.
Na panelu Usage proveďte následující kroky, abyste měli jistotu, že se díváte na data relevantní k vašemu zobrazení v panelu Service Health:
Filtrujte na stejný projekt, model
Seskupte podle úrovně služby , pokud je to relevantní
Zaměřte se na výstupní tokeny, které mají na latenci nejsilnější vliv
Pro hlubší analýzu exportujte Activity Data a sledujte vývoj počtu tokenů na požadavek v čase.
7. Co sdílet s podporou (je-li to potřeba)
Pokud podporu kontaktujete, zahrňte:
ID dotčených organizací (to je důležité)
Dotčené koncové body (Chat Completions, Responses atd.) (to je důležité)
Dotčené modely (to je důležité)
Týká se to úrovně scale nebo priority? (to je důležité)
Časové rozsahy s časovým pásmem pro latenci nebo chyby (to je důležité)
Relevantní x-request-id nebo X-Client-Request-Id (často důležité; pokud možno přiložte)
Časová razítka s časovým pásmem (nebo alespoň datum) u poskytnutých požadavků
Latence - pokud sdílíte příklady pomalých požadavků, uveďte, jak dlouho to trvalo na vaší straně. Ideálně zahrňte také časová razítka, kdy byl požadavek odeslán a kdy byl přijat.
Chyby - uveďte přibližné procento selhávajících/chybových požadavků, kódy odpovědí, chybové zprávy a jak dlouho trvalo získat chybovou odpověď
ID projektu související s požadavky
Týká se to požadavků na datovou rezidenci? Pokud ano, kterých?
Popisy trendů, které pozorujete
Chyby: Přibližné % selhávajících/chybových požadavků
Latence: Které percentily jsou ovlivněny (p50 / p90 / p95 / p99) a o kolik jsou vyšší oproti baseline zákazníka
Obojí: Snímky obrazovky nebo tabulka s daty o chybách či latenci (Jak jste určili, že jsou chybovost nebo latence vyšší, než se očekávalo?)
Běžné scénáře řešení problémů
Dochází k timeoutům, ale Service Health vypadá normálně
Možná příčina: požadavky vyprší ještě předtím, než se dostanou k OpenAI.
Zkontrolujte:
Nastavení timeoutu klienta nebo proxy
Změny v místní síti nebo load balanceru
Přítomnost chyb 499 v panelu Service Health (ve vašich vlastních systémech se mohou zobrazovat jako chyby 5xx).
Latence se zvýšila bez nasazení nové verze
Možná příčina: zvětšila se velikost výstupních tokenů nebo využití uvažování a\nebo se provoz přesunul mezi úrovněmi služby
Zkontrolujte:
Průměrný počet výstupních tokenů na požadavek v panelu Usage (vyžaduje stažení dat a vydělení počtu výstupních tokenů celkovým počtem požadavků).
Percentily Request Time a TTFT v panelu Service Health.
Úroveň Priority nebo Scale se jeví jako pomalá
Možná příčina: metriky jsou smíchané napříč úrovněmi (to znamená, že provoz standardní úrovně maskuje výkon placené úrovně)
Zkontrolujte:
Filtry jsou omezené na jednu úroveň a jeden model
Porovnání rychlosti tokenů mezi úrovněmi
Nárůst chyb 5XX
Pravděpodobná příčina: přechodná selhání ovlivňující malé procento provozu.
Zkontrolujte:
Procento chybovosti
Zda se ve stejnou dobu změnil objem provozu
Problém ovlivňuje jen jeden projekt
Pravděpodobná příčina: konfigurace projektu nebo způsob využití specifický pro daný projekt.
Zkontrolujte:
Filtrování na úrovni projektu
Porovnání s neovlivněnými projekty
Závěrečná doporučení
Před interpretací metrik filtrujte podle modelu, úrovně a tam, kde je to relevantní, i podle projektu
Pro analýzu latence používejte percentily, ne průměry
Malá chybovost je očekávatelná
Chybějící data obvykle ukazují na upstream problémy
Data o využití mohou pomoci vysvětlit, proč se latence změnila; Service Health pomáhá ukázat, kdy