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 egynél több szintet használ (standard, prioritási, skálázási), mindig arra a szintre szűrjön, amelyet vizsgál.
Miért:
A szintek eltérő teljesítményjellemzőkkel rendelkeznek
A prioritási és skálázási szintek meghatározott SLA-kkal rendelkeznek
A szintek keverése elfedi a fizetős szint teljesítményét
Ez különösen fontos a késleltetéselemzésnél.
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és elhárítása
A késleltetéselemzés a meghatározott SLA-kkal rendelkező prioritási és skálázási szinteken a legértelmesebb. A standard szint nagyobb késleltetési ingadozást mutathat, és nincs garantált késleltetése.
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:
Érintett szervezeti azonosítók (fontos)
Érintett végpontok, például Chat Completions vagy Responses (fontos)
Érintett modellek (fontos)
Hogy ez Skálázási vagy prioritási szinten történik-e (fontos)
Időtartományok időzónával a késleltetéshez vagy hibákhoz (fontos)
Releváns x-request-id vagy X-Client-Request-Id, ha rendelkezésre áll
Időbélyegek időzónával, vagy legalább a dátum a megadott kérésekhez
Ha rendelkezésre áll, ezt is adja meg:
A kérésekhez kapcsolódó projektazonosító
Érintettek-e az adatok tárolási helyére vonatkozó kérések, és melyek azok
Az Ön által látott trendek leírása
A probléma típusához adja meg:
Hibák: A sikertelen vagy hibát adó kérések hozzávetőleges százaléka, válaszkódok, hibaüzenetek, valamint hogy mennyi ideig tartott a hibaválasz megérkezése.
Késleltetés: Mely percentilisek érintettek (P50 / P90 / P95 / P99), mennyivel magasabbak az ügyfél alapértékéhez képest, valamint lassú kérések példái küldési és fogadási időbélyegekkel.
Mindkettő: Képernyőképek vagy táblázat hiba- vagy késleltetési adatokról, valamint hogyan állapította meg, hogy a hibaarányok vagy a késleltetés a vártnál magasabbak voltak.
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 prioritási vagy Skálázási szint lassúnak tűnik
Lehetséges ok: a metrikák több szint adatait keverik, így a standard szintű forgalom elfedi a fizetős szint teljesítményét.
Ellenőrizze:
A szűrők egyetlen szintre és modellre vannak korlátozva.
Tokensebesség ö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.