Linkuri importante
Tabloul de bord Starea serviciului (disponibil în prezent doar pentru clienții Enterprise API)
Începeți cu setările implicite corecte
Când deschideți tabloul de bord Starea serviciului, acesta are implicit:
Toate proiectele
Ultimele 30 de zile
Rezoluție orară
Această vizualizare este utilă doar pentru orientare. Depanarea relevantă necesită întotdeauna filtrare.
Filtrați înainte de investigare
Filtrarea corectă este cel mai important pas. Cele mai multe interpretări greșite provin din amestecarea modelelor, nivelurilor sau proiectelor.
Filtrați după model (pe rând)
Filtrați întotdeauna la un singur model.
De ce:
Problemele de 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ă Nivel serviciu
Dacă utilizați mai mult de un nivel (standard, prioritar, scalare), filtrați întotdeauna la nivelul pe care îl investigați.
De ce:
Nivelurile au caracteristici de performanță diferite
Nivelurile prioritar și de scalare au SLA-uri definite
Amestecarea nivelurilor ascunde performanța nivelului plătit
Acest lucru este deosebit de important pentru analiza latenței.
Filtrați după proiect
În mod implicit, Starea serviciului afișează toate proiectele.
Pentru depanare, filtrați la proiectul/proiectele unde a fost observată problema.
De ce:
Un singur proiect cu volum mare poate domina metricile.
Proiectele afectate mai mici pot fi mascate de trafic neasociat.
Lăsați selectat „Toate proiectele” doar dacă credeți că problema este cu adevărat la nivelul întregii organizații.
Depanarea erorilor
Utilizați vizualizarea Solicitări HTTP
Pentru a investiga erorile:
Filtrați după model și Nivel serviciu.
Deschideți fila Solicitări HTTP în locul filei Timp de funcționare.
Această vizualizare afișează numărul total de solicitări ș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 granulare.
Interpretați ratele de eroare, nu numărul erorilor
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 scăzută.
Când erorile lipsesc din Starea serviciului
Dacă vedeți erori pe partea clientului, dar nu există date corespunzătoare în Starea serviciului:
Solicitările probabil nu au ajuns la OpenAI.
Problema este de obicei în amonte (expirări, proxy-uri, rețelistică).
Acest lucru este frecvent în cazul expirărilor agresive pe partea clientului.
Depanarea latenței
Analiza latenței este cea mai relevantă pe nivelurile prioritar și de scalare, care au SLA-uri definite. Nivelul standard poate afișa variații mai mari ale latenței și nu are latență garantată.
Metrici cheie
Pentru a vedea fiecare metrică, faceți clic pe fila relevantă:
Viteza tokenilor: tokeni generați pe secundă; independentă de dimensiunea solicitării.
Timp solicitare: durata totală a solicitării; puternic afectată 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 afectat de dimensiunea solicitării de intrare nememorate în cache și de raţionament.
Analizați întotdeauna percentilele P50 / P75 / P95. Mediile pot ascunde impactul asupra utilizatorilor reali.
6. Corelarea latenței cu utilizarea tokenilor
Starea serviciului arată când s-a schimbat comportamentul. Datele de utilizare ajută la explicarea motivului.
În tabloul de bord Utilizare, faceți următoarele pentru a vă asigura că priviți datele relevante pentru vizualizarea dvs. din tabloul de bord Starea serviciului:
Filtrați la același proiect și model.
Grupați după Nivel serviciu, dacă se aplică.
Concentrați-vă pe tokenii de ieșire, care afectează cel mai puternic latența.
Pentru o analiză mai aprofundată, exportați Datele de activitate și examinați tokenii per solicitare în timp.
7. Ce să partajați cu asistența (dacă este necesar)
Dacă contactați asistența, includeți:
ID-urile organizațiilor afectate (important)
Punctele finale afectate, cum ar fi Chat Completions sau Responses (important)
Modelele afectate (important)
Dacă acest lucru se întâmplă pe nivelul de scalare sau prioritar (important)
Intervale de timp cu fus orar pentru latență sau erori (important)
x-request-id sau X-Client-Request-Id relevant, dacă este disponibil
Marcaje temporale cu fus orar sau cel puțin data pentru solicitările pe care le furnizați
Dacă sunt disponibile, includeți și:
ID-ul proiectului asociat solicitărilor
Dacă solicitările privind rezidența datelor sunt afectate și care sunt acestea
Descrieri ale tendințelor pe care le observați
Pentru tipul problemei, includeți:
Erori: procentul aproximativ de solicitări care eșuează sau produc erori, codurile de răspuns, mesajele de eroare și cât a durat primirea răspunsului de eroare.
Latență: percentilele afectate (P50 / P90 / P95 / P99), cât de mari sunt comparativ cu referința clientului și exemple de solicitări lente cu marcaje temporale de trimitere și primire.
Ambele: capturi de ecran sau un tabel cu date despre erori sau latență, plus modul în care ați determinat că ratele de eroare sau latența au fost mai mari decât se aștepta.
Scenarii frecvente de depanare
Apar expirări, dar Starea serviciului pare normală
Cauză posibilă: solicitările expiră înainte de a ajunge la OpenAI.
Verificați:
Setările de expirare ale clientului sau proxy-ului
Modificări ale rețelei locale sau ale balansatorului de încărcare
Prezența erorilor 499 în tabloul de bord Starea serviciului (acestea pot apărea ca erori 5xx în propriile dvs. sisteme).
Latența a crescut fără o implementare
Cauză posibilă: dimensiunea tokenilor de ieșire sau utilizarea raţionamentului a crescut și/sau traficul s-a mutat între niveluri de serviciu.
Verificați:
Numărul mediu de tokeni de ieșire per solicitare în tabloul de bord Utilizare (necesită descărcarea datelor și împărțirea tokenilor de ieșire la numărul total de solicitări).
Percentilele Timp solicitare și TTFT în tabloul de bord Starea serviciului.
Nivelul prioritar sau Nivelul de scalare pare lent
Cauză posibilă: metricile sunt combinate între niveluri, ceea ce înseamnă că traficul de nivel standard maschează performanța nivelului plătit.
Verificați:
Filtrele sunt limitate la un singur nivel și model.
Compararea vitezei tokenilor între niveluri.
Creștere bruscă a erorilor 5XX
Cauză probabilă: erori tranzitorii care afectează un procent mic din trafic.
Verificați:
Procentul ratei de eroare
Dacă volumul traficului s-a schimbat în același timp
Problema afectează un singur proiect
Cauză probabilă: configurație sau tipar de utilizare specific proiectului.
Verificați:
Filtrarea la nivel de proiect
Comparația cu proiectele neafectate
Concluzii finale
Filtrați după model, nivel și proiect, unde este relevant, înainte de a interpreta metricile.
Utilizați percentile, nu medii, pentru analiza latenței.
Ratele mici de eroare sunt așteptate.
Datele lipsă indică de obicei probleme în amonte.
Datele de utilizare pot ajuta la explicarea motivului pentru care s-a schimbat latența; Starea serviciului arată când s-a schimbat comportamentul.