Fontos hivatkozások
*A Service Health irányítópult jelenleg csak az 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 a következőket mutatja:
Összes projekt
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űrjön, mielőtt vizsgálódik
A helyes szűrés a legfontosabb lépés. A legtöbb félreértelmezés abból adódik, hogy modellek, szintek vagy projektek keverednek.
Szűrés modell szerint (egyszerre egy)
Mindig egyetlen modellre szűrjön.
Miért:
Az alacsony forgalmú modelleknél jelentkező problémákat elrejtheti a nagyobb volumenű forgalom
A nagy forgalmú modellek miatt a helyi problémák globálisnak tűnhetnek
A különböző modellek eltérő teljesítménycélokkal rendelkeznek
Megjegyzés: több modell kiválasztása összevonja ő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, priority, scale), mindig arra a szintre szűrjön, amelyet vizsgál.
Miért:
A szintek eltérő teljesítményjellemzőkkel rendelkeznek
A priority és scale szintekhez meghatározott SLA-k tartoznak
A szintek keverése elfedi a fizetős szintek teljesítményét
Ez különösen fontos a késleltetés elemzéséhez.
Szűrés projekt szerint
Alapértelmezés szerint a Service Health az összes projektet mutatja.
Hibaelhárításkor szűrjön arra a projektre vagy projektekre, ahol a probléma megfigyelhető volt.
Miért:
Egyetlen nagy forgalmú projekt uralhatja a mérőszámokat
A kisebb érintett projekteket elfedheti a nem kapcsolódó forgalom
Csak akkor hagyja kijelölve az "Összes projekt" lehetőséget, ha úgy gondolja, hogy a probléma valóban az egész szervezetet érinti.
Hibák elhárítása
Használja a HTTP Requests nézetet
A hibák kivizsgálásához:
Szűrjön modell és szint szerint
Az Uptime nézetről a HTTP Requests nézetre váltáshoz kattintson a HTTP Requests fülre
Ez a nézet a kérelmek teljes számát és a hibák számát mutatja HTTP-állapotkód szerint. Nagyítson perces felbontásra, hogy azonosíthassa a részletes kiugrásokat vagy változásokat.
Hibaarányokat értelmezzen, ne darabszámokat
Bármely éles rendszerben várhatók bizonyos hibák. A nyers összesítések helyett a hibák százalékos arányára összpontosítson.
Minél nagyobb az összforgalom, annál nagyobb lehet a hibák száma még rendkívül alacsony hibaarány mellett is.
Amikor a hibák nem jelennek meg a Service Health felületen
Ha kliensoldali hibákat lát, de a Service Health felületen nincs megfelelő adat:
A kérések valószínűleg nem jutottak el az OpenAI-hoz
A probléma általában feljebb található a láncban (időtúllépések, proxik, hálózat)
Ez gyakori agresszív kliensoldali időtúllépések esetén.
Késleltetés hibaelhárítása
A késleltetés elemzése a priority és scale szinteken a leghasznosabb, mert ezekhez meghatározott SLA-k tartoznak. A standard szinten nagyobb késleltetési ingadozás lehet, és nincs garantált késleltetés.
Fő mérőszámok
Az egyes mérőszámok megjelenítéséhez kattintson a megfelelő fülre:
Token Velocity
Másodpercenként generált tokenek.
Független az utasítás méretétől.
Request Time
A kérés teljes időtartama.
Erősen befolyásolja a kimenet mérete és az érvelés.
Time to First Token (TTFT)
Az első token legenerá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 elrejthetik a valós felhasználói hatást.
6. A késleltetés összekapcsolá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 Usage irányítópulton a következőket tegye meg annak biztosítására, hogy a Service Health irányítópult nézetének megfelelő adatokat lássa:
Szűrjön ugyanarra a projektre és modellre
Csoportosítsa szolgáltatási szint szerint ha alkalmazható
Összpontosítson a kimeneti tokenekre, mert ezek befolyásolják leginkább a késleltetést
Mélyebb elemzéshez exportálja az Activity Data adatokat, és időben vizsgálja meg a kérésenkénti tokenek számát.
7. Mit osszon meg a támogatással (ha szükséges)
Ha mégis kapcsolatba lép a támogatással, adja meg a következőket:
Érintett szervezeti azonosítók (ez fontos)
Érintett végpontok (Chat Completions, Responses stb.) (ez fontos)
Érintett modellek (ez fontos)
Scale vagy priority szintről van szó? (ez fontos)
Időintervallumok időzónával a késleltetéshez vagy hibához (ez fontos)
Kapcsolódó x-request-id vagy X-Client-Request-Id (gyakran fontos; ha lehetséges, adja meg)
A megadott kérések időbélyegei időzónával (vagy legalább a dátummal)
Késleltetés - ha lassú kérések példáit osztja meg, adja meg, mennyi ideig tartott az Ön oldalán. Ideális esetben azt is adja meg, mikor küldték el a kérést, és mikor érkezett meg a válasz.
Hibák - kérjük, adja meg a sikertelen/hibás kérések hozzávetőleges százalékát, a válaszkód(oka)t, a hibaüzenet(ek)et, valamint azt, mennyi idő alatt érkezett meg a hibaválasz
A kérésekhez kapcsolódó projektazonosító
Érint ez adatok tárolási helye kéréseket? Ha igen, melyeket?
A megfigyelt trendek leírása
Hibák: A sikertelen/hibás kérések hozzávetőleges %-a
Késleltetés: Mely percentilisek érintettek (p50 / p90 / p95 / p99), és mennyivel magasabbak az ügyfél alapértékénél
Mindkettő: Képernyőképek vagy táblázat a hiba- vagy késleltetési adatokról (Hogyan állapította meg, hogy a hibaarány vagy a késleltetés a vártnál magasabb?)
Gyakori hibaelhárítási helyzetek
Időtúllépések fordulnak elő, de a Service Health normálisnak tűnik
Lehetséges ok: a kérések időtúllépéssel megszakadnak, mielőtt elérnék az OpenAI-t.
Ellenőrizze:
A kliens vagy proxy időtúllépési beállításait
A helyi hálózat vagy a terheléselosztó változásait
A 499-es hibák jelenlétét 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 meg
Lehetséges ok: nőtt a kimeneti tokenek mérete vagy az érvelés használata, és/vagy a forgalom eltolódott a szolgáltatási szintek között
Ellenőrizze:
Az egy kérésre jutó átlagos kimeneti tokeneket a Usage irányítópulton (ehhez le kell tölteni az adatokat, és el kell osztani a kimeneti tokeneket a kérések teljes számával).
A Request Time és a TTFT percentiliseit a Service Health irányítópulton.
A Priority vagy Scale szint lassúnak tűnik
Lehetséges ok: a mérőszámok keverednek a szintek között (vagyis a standard szintű forgalom elfedi a fizetős szintek teljesítményét)
Ellenőrizze:
A szűrők egyetlen szintre és modellre vannak korlátozva
A tokensebesség összehasonlítását a szintek között
Kiugrás az 5XX hibákban
Valószínű ok: átmeneti hibák, amelyek a forgalom kis százalékát érintik.
Ellenőrizze:
A hibaarány százalékos értékét
Változott-e a forgalom volumene ugyanabban az időben
A probléma csak egy projektet érint
Valószínű ok: projektspecifikus konfiguráció vagy használati minta.
Ellenőrizze:
Projekt szintű szűrést
Összehasonlítást a nem érintett projektekkel
Végső tanulságok
A mérőszámok értelmezése előtt szűrjön modell, szint és ahol releváns projekt szerint
A késleltetés elemzéséhez percentiliseket használjon, ne átlagokat
Kis hibaarányok várhatók
A hiányzó adatok általában feljebb lévő problémákra utalnak
A használati adatok segíthetnek megmagyarázni, miért változott a késleltetés; a Service Health pedig azt mutatja meg, mikor