Linkuri importante
*Tabloul de bord Service Health este disponibil în prezent doar pentru clienții Enterprise API.
Începeți cu valorile implicite corecte
Când deschideți tabloul de bord Service Health, acesta este setat implicit la:
Toate proiectele
Ultimele 30 de zile
Rezoluție orară
Această vizualizare este utilă doar pentru orientare. O depanare relevantă necesită întotdeauna filtrare.
Filtrați înainte de a investiga
Filtrarea corectă este cel mai important pas. Cele mai multe interpretări greșite provin din combinarea modelelor, nivelurilor sau proiectelor.
Filtrați după model (câte unul)
Filtrați întotdeauna la un singur model.
De ce:
Problemele pe modelele cu trafic redus pot fi ascunse de traficul cu volum mai mare
Modelele cu volum mare pot face ca problemele localizate să pară globale
Modelele diferite au obiective de performanță diferite
Notă: selectarea mai multor modele le agregă — nu comută între ele.
Filtrați după nivelul de serviciu
Dacă folosiți mai mult de un nivel (standard, priority, scale), filtrați întotdeauna la nivelul pe care îl investigați.
De ce:
Nivelurile au caracteristici de performanță diferite
Nivelurile priority și scale au SLA-uri definite
Combinarea nivelurilor ascunde performanța nivelurilor plătite
Acest lucru este deosebit de important pentru analiza latenței.
Filtrați după proiect
Implicit, Service Health afișează toate proiectele.
Pentru depanare, filtrați la proiectul sau proiectele în care a fost observată problema.
De ce:
Un singur proiect cu volum mare poate domina indicatorii
Proiectele afectate mai mici pot fi mascate de trafic fără legătură
Lăsați selectat „Toate proiectele” doar dacă credeți că problema afectează într-adevăr întreaga organizație.
Depanarea erorilor
Folosiți vizualizarea HTTP Requests
Pentru a investiga erorile:
Filtrați după model și nivel
Pentru a trece de la Uptime la HTTP Requests, faceți clic pe fila HTTP Requests
Această vizualizare arată numărul total de cereri și numărul de erori după codul de stare HTTP. Măriți până la rezoluția la nivel de minut pentru a identifica vârfuri sau modificări detaliate.
Interpretați ratele de eroare, nu numerele
Unele erori sunt de așteptat în orice sistem de producție. Concentrați-vă pe procentul de erori, nu pe totalurile brute.
Cu cât volumul total este mai mare, cu atât numărul potențial de erori este mai mare, chiar și cu o rată de eroare extrem de mică.
Când erorile lipsesc din Service Health
Dacă vedeți erori pe partea de client, dar nu există date corespunzătoare în Service Health:
Cel mai probabil, cererile nu au ajuns la OpenAI
Problema este de obicei în amonte (timeout-uri, proxy-uri, rețea)
Acest lucru este frecvent în cazul timeout-urilor agresive pe partea de client.
Depanarea latenței
Analiza latenței este cea mai relevantă pentru nivelurile priority și scale, care au SLA-uri definite. Nivelul standard poate afișa variații mai mari ale latenței și nu are latență garantată.
Indicatori cheie
Pentru a vedea fiecare dintre acești indicatori, faceți clic pe fila relevantă:
Viteza tokenurilor
Tokenuri generate pe secundă.
Independent de dimensiunea solicitării.
Timpul cererii
Durata totală a cererii.
Puternic influențată de dimensiunea ieșirii și de raţionament.
Timp până la primul token (TTFT)
Timpul până când este generat primul token.
Puternic influențat de dimensiunea solicitării de intrare necache-uite și de raţionament.
Examinați întotdeauna percentilele P50 / P75 / P95. Mediile pot ascunde impactul asupra utilizatorilor reali.
6. Corelarea latenței cu utilizarea tokenurilor
Service Health arată când s-a schimbat comportamentul. Datele de utilizare ajută la explicarea motivului de ce.
În tabloul de bord Usage, faceți următoarele pentru a vă asigura că analizați datele relevante pentru vizualizarea din tabloul de bord Service Health:
Filtrați la același proiect, model
Grupați după nivel de serviciu dacă este cazul
Concentrați-vă pe tokenurile de ieșire, care afectează cel mai mult latența
Pentru o analiză mai aprofundată, exportați Activity Data și examinați tokenurile per cerere în timp.
7. Ce să trimiteți echipei de suport (dacă este necesar)
Dacă contactați suportul, includeți:
ID-urile organizațiilor afectate (acest lucru este important)
Punctele finale afectate (Chat Completions, Responses etc.) (acest lucru este important)
Modelele afectate (acest lucru este important)
Este vorba despre nivelul scale sau priority? (acest lucru este important)
Intervalele de timp cu fusul orar pentru latență sau eroare (acest lucru este important)
x-request-id sau X-Client-Request-Id relevant (adesea important; includeți-l dacă este posibil)
Marcaje temporale cu fus orar (sau cel puțin data) pentru cererile furnizate
Latență - dacă oferiți exemple de cereri lente, precizați cât a durat la dvs. În mod ideal, includeți și marcajele temporale pentru momentul în care cererea a fost trimisă și când a fost primită.
Erori - indicați procentul aproximativ al cererilor care au eșuat/au dat eroare, codul/codurile de răspuns, mesajul/mesajele de eroare și cât a durat până ați primit răspunsul de eroare
ID-ul proiectului asociat cererilor
Afectează acest lucru cererile privind rezidența datelor? Dacă da, pe care?
Descrieri ale tendințelor pe care le observați
Erori: % aproximativ al cererilor care eșuează/au erori
Latență: Ce percentile sunt afectate (p50 / p90 / p95 / p99) și cât de ridicate sunt comparativ cu nivelul de bază al clientului
Ambele: Capturi de ecran sau tabel cu date despre erori ori latență (Cum ați stabilit că rata erorilor sau latența este mai mare decât era de așteptat?)
Scenarii comune de depanare
Apar timeout-uri, dar Service Health pare normal
Cauză posibilă: cererile expiră înainte de a ajunge la OpenAI.
Verificați:
Setările de timeout ale clientului sau proxy-ului
Modificări ale rețelei locale sau ale echilibrorului de sarcină
Prezența erorilor 499 în tabloul de bord Service Health (acestea pot apărea ca erori 5xx în propriile dvs. sisteme).
Latența a crescut fără un deployment
Cauză posibilă: Dimensiunea tokenurilor de ieșire sau utilizarea raţionamentului a crescut și/sau traficul s-a mutat între nivelurile de serviciu
Verificați:
Media tokenurilor de ieșire per cerere în tabloul de bord Usage (necesită descărcarea datelor și împărțirea tokenurilor de ieșire la numărul total de cereri).
Percentilele Request Time și TTFT din tabloul de bord Service Health.
Nivelul Priority sau Scale pare lent
Cauză posibilă: indicatorii sunt combinați între niveluri (ceea ce înseamnă că traficul de nivel standard maschează performanța nivelurilor plătite)
Verificați:
Filtrele sunt restrânse la un singur nivel și model
Comparația vitezei tokenurilor între niveluri
Creștere bruscă a erorilor 5XX
Cauză probabilă: eșecuri tranzitorii care afectează un procent mic din trafic.
Verificați:
Procentul ratei de eroare
Dacă volumul de trafic s-a schimbat în același timp
Problema afectează doar un singur proiect
Cauză probabilă: configurație sau model de utilizare specific proiectului.
Verificați:
Filtrarea la nivel de proiect
Comparația cu proiectele neafectate
Concluzii finale
Filtrați după model, nivel și, unde este relevant, proiect înainte de a interpreta indicatorii
Folosiți percentile, nu medii, pentru analiza latenței
Rate mici de eroare sunt de așteptat
Datele lipsă indică de obicei probleme în amonte
Datele de utilizare pot ajuta la explicarea motivului pentru care s-a schimbat latența; Service Health ajută la a arăta când