Dôležité odkazy
Informačný panel stavu služby (momentálne dostupný iba pre podnikových zákazníkov API)
Začnite so správnymi predvolenými nastaveniami
Keď otvoríte informačný panel Service Health, predvolene zobrazuje:
Všetky projekty
Posledných 30 dní
Hodinové rozlíšenie
Toto zobrazenie je užitočné iba na orientáciu. Zmysluplné riešenie problémov vždy vyžaduje filtrovanie.
Filtrujte pred vyšetrovaním
Správne filtrovanie je najdôležitejší krok. Väčšina nesprávnych interpretácií vzniká miešaním modelov, úrovní alebo projektov.
Filtrovať podľa modelu (po jednom)
Vždy filtrujte na jeden model.
Prečo:
Problémy pri modeloch s nízkou prevádzkou môže skryť prevádzka s vyšším objemom
Modely s vysokým objemom môžu spôsobiť, že lokálne problémy vyzerajú ako globálne
Rôzne modely majú rôzne výkonnostné ciele
Poznámka: výber viacerých modelov ich agreguje – neprepína medzi nimi.
Filtrovať podľa úrovne služby
Ak používate viac ako jednu úroveň (štandardnú, prioritnú, úroveň škálovania), vždy filtrujte na úroveň, ktorú skúmate.
Prečo:
Úrovne majú rôzne výkonnostné charakteristiky
Prioritné úrovne a úrovne škálovania majú definované SLA
Miešanie úrovní zakrýva výkon platenej úrovne
Je to obzvlášť dôležité pri analýze latencie.
Filtrovať podľa projektu
Service Health predvolene zobrazuje všetky projekty.
Pri riešení problémov filtrujte na projekt(y), v ktorých bol problém pozorovaný.
Prečo:
Jeden projekt s vysokým objemom môže dominovať metrikám.
Menšie ovplyvnené projekty môžu byť zakryté nesúvisiacou prevádzkou.
Výber „Všetky projekty“ nechajte iba vtedy, ak sa domnievate, že problém sa skutočne týka celej organizácie.
Riešenie problémov s chybami
Použite zobrazenie požiadaviek HTTP
Na preskúmanie chýb:
Filtrujte podľa modelu a úrovne služby.
Otvorte kartu Požiadavky HTTP namiesto karty Dostupnosť.
Toto zobrazenie ukazuje celkový počet požiadaviek a počty chýb podľa stavového kódu HTTP. Priblížte zobrazenie na rozlíšenie po minútach, aby ste identifikovali podrobné špičky alebo zmeny.
Interpretujte mieru chýb, nie počty
V každom produkčnom systéme sa niektoré chyby očakávajú. Zamerajte sa na percento chýb, nie na hrubé súčty.
Čím väčší je váš celkový objem, tým väčší môže byť počet chýb aj pri mimoriadne nízkej miere chýb.
Keď v Service Health chýbajú chyby
Ak vidíte chyby na strane klienta, ale v Service Health nie sú žiadne zodpovedajúce údaje:
Požiadavky pravdepodobne nedorazili do OpenAI.
Problém je zvyčajne upstream (časové limity, proxy servery, sieťové pripojenie).
Je to bežné pri agresívnych časových limitoch na strane klienta.
Riešenie problémov s latenciou
Analýza latencie má najväčší význam na prioritnej úrovni a úrovni škálovania, ktoré majú definované SLA. Štandardná úroveň môže vykazovať väčšie rozdiely v latencii a nemá garantovanú latenciu.
Kľúčové metriky
Ak chcete zobraziť jednotlivé metriky, kliknite na príslušnú kartu:
Rýchlosť tokenov: tokeny generované za sekundu; nezávisí od veľkosti príkazu.
Čas požiadavky: celkové trvanie požiadavky; výrazne ho ovplyvňuje veľkosť výstupu a uvažovanie.
Čas do prvého tokenu (TTFT): čas, kým sa vygeneruje prvý token; výrazne ho ovplyvňuje veľkosť neuloženého vstupného príkazu a uvažovanie.
Vždy kontrolujte percentily P50 / P75 / P95. Priemery môžu skryť vplyv na skutočných používateľov.
6. Korelácia latencie s používaním tokenov
Service Health ukazuje, kedy sa správanie zmenilo. Údaje o používaní pomáhajú vysvetliť, prečo.
V informačnom paneli používania urobte nasledovné, aby ste sa uistili, že sa pozeráte na údaje relevantné pre vaše zobrazenie v informačnom paneli Service Health:
Filtrujte na rovnaký projekt a model.
Zoskupte podľa úrovne služby, ak je to relevantné.
Zamerajte sa na výstupné tokeny, ktoré najvýraznejšie ovplyvňujú latenciu.
Na hlbšiu analýzu exportujte údaje o aktivite a skúmajte počet tokenov na požiadavku v priebehu času.
7. Čo zdieľať s podporou (ak je to potrebné)
Ak kontaktujete podporu, uveďte:
Ovplyvnené ID organizácií (dôležité)
Ovplyvnené koncové body, napríklad Chat Completions alebo Responses (dôležité)
Ovplyvnené modely (dôležité)
Či ide o úroveň škálovania alebo prioritnú úroveň (dôležité)
Časové rozsahy s časovým pásmom pre latenciu alebo chyby (dôležité)
Relevantné x-request-id alebo X-Client-Request-Id, ak sú k dispozícii
Časové pečiatky s časovým pásmom, alebo aspoň dátum, pre požiadavky, ktoré poskytujete
Ak sú k dispozícii, zahrňte aj:
ID projektu súvisiace s požiadavkami
Či sú ovplyvnené požiadavky na rezidenciu údajov a ktoré
Opisy trendov, ktoré pozorujete
Pre typ problému uveďte:
Chyby: približné percento zlyhávajúcich alebo chybových požiadaviek, kódy odpovedí, chybové hlásenia a ako dlho trvalo prijatie chybovej odpovede.
Latencia: ktoré percentily sú ovplyvnené (P50 / P90 / P95 / P99), aké vysoké sú v porovnaní so základnou hodnotou zákazníka, a príklady pomalých požiadaviek s časovými pečiatkami odoslania a prijatia.
Oboje: snímky obrazovky alebo tabuľku údajov o chybách alebo latencii a tiež ako ste určili, že miera chýb alebo latencia boli vyššie, než sa očakávalo.
Bežné scenáre riešenia problémov
Vyskytujú sa časové limity, ale Service Health vyzerá normálne
Možná príčina: požiadavky prekračujú časový limit skôr, než dorazia do OpenAI.
Skontrolujte:
Nastavenia časového limitu klienta alebo proxy servera
Zmeny v lokálnej sieti alebo vyvažovači záťaže
Prítomnosť chýb 499 v informačnom paneli Service Health (vo vašich vlastných systémoch sa môžu zobrazovať ako chyby 5xx).
Latencia sa zvýšila bez nasadenia
Možná príčina: zvýšila sa veľkosť výstupných tokenov alebo používanie uvažovania a/alebo sa prevádzka presunula medzi úrovňami služby.
Skontrolujte:
Priemerný počet výstupných tokenov na požiadavku v informačnom paneli používania (vyžaduje stiahnutie údajov a vydelenie výstupných tokenov celkovým počtom požiadaviek).
Percentily Času požiadavky a TTFT v informačnom paneli Service Health.
Prioritná úroveň alebo úroveň škálovania sa zdá pomalá
Možná príčina: metriky sú zmiešané naprieč úrovňami, takže prevádzka štandardnej úrovne zakrýva výkon platenej úrovne.
Skontrolujte:
Filtre sú obmedzené na jednu úroveň a model.
Porovnanie rýchlosti tokenov medzi úrovňami.
Nárast chýb 5XX
Pravdepodobná príčina: dočasné zlyhania ovplyvňujúce malé percento prevádzky.
Skontrolujte:
Percento chybovosti
Či sa v rovnakom čase zmenil objem prevádzky
Problém ovplyvňuje iba jeden projekt
Pravdepodobná príčina: konfigurácia alebo vzor používania špecifický pre projekt.
Skontrolujte:
Filtrovanie na úrovni projektu
Porovnanie s neovplyvnenými projektmi
Záverečné odporúčania
Pred interpretáciou metrík filtrujte podľa modelu, úrovne a projektu, ak je to relevantné.
Pri analýze latencie používajte percentily, nie priemery.
Malé miery chýb sú očakávané.
Chýbajúce údaje zvyčajne naznačujú upstream problémy.
Údaje o používaní môžu pomôcť vysvetliť, prečo sa latencia zmenila; Service Health ukazuje, kedy sa správanie zmenilo.