Fontos hivatkozások
Szolgáltatásállapot-irányítópult (jelenleg csak Enterprise API-ügyfelek számára érhető el)
Kezdje a megfelelő alapértelmezésekkel
Amikor megnyitja a Service Health irányítópultot, az alapértelmezés szerint ezt mutatja:
Minden projekt
Az elmúlt 30 nap
Óránkénti felbontás
Ez a nézet csak tájékozódásra hasznos. Az érdemi hibaelhárításhoz mindig szűrés szükséges.
Szűrés a vizsgálat előtt
A helyes szűrés a legfontosabb lépés. A legtöbb félreértelmezés modellek, szintek vagy projektek keveréséből adódik.
Szűrés modell szerint (egyszerre egyre)
Mindig egyetlen modellre szűrjön.
Miért:
Az alacsony forgalmú modellek problémáit elfedheti a nagyobb volumenű forgalom
A nagy volumenű modellek miatt a helyi problémák globálisnak tűnhetnek
A különböző modelleknek eltérő teljesítménycéljaik vannak
Megjegyzés: több modell kiválasztása összesíti őket — nem vált közöttük.
Szűrés Szolgáltatási szint szerint
Ha több szintet használ (normál, Gyors mód – korábban elsőbbségi feldolgozás –, Skálázási szint), mindig szűrjön arra a szintre, amelyet vizsgál.
Miért?
A szintek teljesítményjellemzői eltérőek
A Gyors módhoz és a Skálázási szinthez meghatározott SLA tartozik
A szintek adatainak keverése elfedi a fizetős szint teljesítményét
Ez különösen fontos a késleltetés elemzésekor.
A meglévő modelleknél a Gyors mód forgalma továbbra is „priority” megjelöléssel jelenik meg a Használat irányítópulton.
Szűrés projekt szerint
Alapértelmezés szerint a Service Health minden projektet megjelenít.
Hibaelhárításhoz szűrjön arra a projektre vagy projektekre, ahol a problémát észlelték.
Miért:
Egyetlen nagy volumenű projekt dominálhatja a metrikákat.
A kisebb érintett projekteket elfedheti a nem kapcsolódó forgalom.
Csak akkor hagyja kiválasztva a „Minden projekt” lehetőséget, ha úgy véli, hogy a probléma valóban az egész szervezetet érinti.
Hibák elhárítása
A HTTP-kérések nézet használata
Hibák vizsgálatához:
Szűrjön modell és szolgáltatási szint szerint.
Nyissa meg a HTTP Requests lapot az Uptime lap helyett.
Ez a nézet a kérések teljes számát és a hibaszámokat mutatja HTTP-állapotkód szerint. Nagyítson percszintű felbontásra a részletes kiugrások vagy változások azonosításához.
Hibaarányokat értelmezzen, ne darabszámokat
Bármely éles rendszerben várhatók hibák. A nyers összesítések helyett a hibák százalékos arányára összpontosítson.
Minél nagyobb a teljes volumene, annál nagyobb lehet a hibák száma még rendkívül alacsony hibaarány mellett is.
Amikor a hibák hiányoznak a Service Healthből
Ha ügyféloldali hibákat lát, de nincs megfelelő adat a Service Healthben:
A kérések valószínűleg nem érték el az OpenAI-t.
A probléma általában upstream oldalon van (időtúllépések, proxyk, hálózatkezelés).
Ez gyakori agresszív ügyféloldali időtúllépések esetén.
Késleltetési problémák elhárítása
A késleltetés elemzése a meghatározott SLA-val rendelkező Gyors mód és Skálázási szint esetében a leghasznosabb. A normál szinten nagyobb lehet a késleltetés ingadozása, és nincs garantált késleltetési érték.
Fő metrikák
Az egyes metrikák megtekintéséhez kattintson a megfelelő lapra:
Tokensebesség: Másodpercenként generált tokenek; független az utasítás méretétől.
Kérés időtartama: A kérés teljes időtartama; erősen befolyásolja a kimenet mérete és az érvelés.
Első tokenig eltelt idő (TTFT): Az első token generálásáig eltelt idő; erősen befolyásolja a nem gyorsítótárazott bemeneti utasítás mérete és az érvelés.
Mindig tekintse át a P50 / P75 / P95 percentiliseket. Az átlagok elfedhetik a valós felhasználói hatást.
6. A késleltetés korrelálása a tokenhasználattal
A Service Health megmutatja, mikor változott a viselkedés. A használati adatok segítenek megmagyarázni, miért.
A Használati irányítópulton tegye a következőket, hogy biztosan a Service Health irányítópulton látható nézethez releváns adatokat nézze:
Szűrjön ugyanarra a projektre és modellre.
Csoportosítson szolgáltatási szint szerint, ha alkalmazható.
Összpontosítson a kimeneti tokenekre, amelyek a leginkább befolyásolják a késleltetést.
Mélyebb elemzéshez exportálja az Activity Data adatokat, és vizsgálja meg a kérésenkénti tokeneket időben.
7. Mit osszon meg az ügyfélszolgálattal (ha szükséges)
Ha kapcsolatba lép az ügyfélszolgálattal, adja meg a következőket:
Érintett szervezeti azonosítók (fontos)
Érintett végpontok, például Chat Completions vagy Responses (fontos)
Érintett modellek (fontos)
A Gyors mód vagy a Skálázási szint érintett-e (fontos)
A késleltetések vagy hibák időtartományai, időzónával együtt (fontos)
A kapcsolódó x-request-id vagy X-Client-Request-Id, ha rendelkezésre áll
A megadott kérések időbélyegei időzónával együtt, vagy legalább a dátumuk
Ha rendelkezésre állnak, adja meg ezeket is:
A kérésekhez kapcsolódó projektazonosító
Érintettek-e az adatok tárolási helyére vonatkozó kérések, és ha igen, melyek
A tapasztalt tendenciák leírása
A probléma típusától függően adja meg a következőket:
Hibák: A sikertelen vagy hibát eredményező kérések hozzávetőleges százalékos aránya, a válaszkódok, a hibaüzenetek, valamint az, hogy mennyi idő alatt érkezett meg a hibaválasz.
Késleltetés: Mely percentilisek érintettek (P50 / P90 / P95 / P99), mennyivel magasabbak az ügyfélnél megszokott alapszintnél, valamint példák lassú kérésekre a küldés és fogadás időbélyegével.
Mindkettő: Képernyőképek vagy táblázat a hiba- vagy késleltetési adatokról, továbbá annak ismertetése, hogyan állapította meg, hogy a hibaarány vagy a késleltetés magasabb a vártnál.
Gyakori hibaelhárítási forgatókönyvek
Időtúllépések történnek, de a Service Health normálisnak tűnik
Lehetséges ok: a kérések időtúllépés miatt megszakadnak, mielőtt elérnék az OpenAI-t.
Ellenőrizze:
Ügyfél- vagy proxyoldali időtúllépési beállítások
Helyi hálózati vagy terheléselosztói változások
499-es hibák jelenléte a Service Health irányítópulton (ezek a saját rendszereiben 5xx hibaként jelenhetnek meg).
A késleltetés telepítés nélkül nőtt
Lehetséges ok: nőtt a kimeneti tokenek mérete vagy az érvelés használata, illetve a forgalom a szolgáltatási szintek között eltolódott.
Ellenőrizze:
Kérésenkénti átlagos kimeneti tokenek a Használati irányítópulton (az adatok letöltése, majd a kimeneti tokenek összes kéréssel való elosztása szükséges).
A Request Time és TTFT percentilisek a Service Health irányítópulton.
A Gyors mód vagy a Skálázási szint lassúnak tűnik
Lehetséges ok: a mérőszámok különböző szintekről származnak, így a normál szint forgalma elfedi a fizetős szint teljesítményét.
Ellenőrizze a következőket:
A szűrők egyetlen szintre és modellre vannak korlátozva.
A tokenek feldolgozási sebességének összehasonlítása a szintek között.
5XX hibák hirtelen megugrása
Valószínű ok: átmeneti hibák, amelyek a forgalom kis százalékát érintik.
Ellenőrizze:
Hibaarány százaléka
Változott-e ugyanakkor a forgalom volumene
A probléma csak egy projektet érint
Valószínű ok: projektspecifikus konfiguráció vagy használati minta.
Ellenőrizze:
Projektszintű szűrés
Összehasonlítás a nem érintett projektekkel
Végső tanulságok
A metrikák értelmezése előtt szükség szerint szűrjön modellre, szintre és projektre.
Késleltetéselemzéshez percentiliseket használjon, ne átlagokat.
Kis hibaarányok várhatók.
A hiányzó adatok általában upstream problémákra utalnak.
A használati adatok segíthetnek megmagyarázni, miért változott a késleltetés; a Service Health azt mutatja, mikor változott a viselkedés.