Vigtige links
Service Health-dashboard (i øjeblikket kun tilgængeligt for Enterprise API-kunder)
Start med de rigtige standardindstillinger
Når du åbner Service Health-dashboardet, er standardindstillingerne:
Alle projekter
Seneste 30 dage
Timebaseret opløsning
Denne visning er kun nyttig til orientering. Meningsfuld fejlfinding kræver altid filtrering.
Filtrér før undersøgelse
Korrekt filtrering er det vigtigste trin. De fleste fejlfortolkninger skyldes blanding af modeller, niveauer eller projekter.
Filtrér efter model (én ad gangen)
Filtrér altid til en enkelt model.
Hvorfor:
Problemer på modeller med lav trafik kan skjules af trafik med højere volumen
Modeller med høj volumen kan få lokale problemer til at se globale ud
Forskellige modeller har forskellige præstationsmål
Bemærk: Hvis du vælger flere modeller, samles de – der skiftes ikke mellem dem.
Filtrér efter serviceniveau
Hvis du bruger mere end ét niveau (standard, Hurtig tilstand (tidligere Prioriteret behandling), Skaleringsniveau), skal du altid filtrere efter det niveau, du undersøger.
Hvorfor:
Niveauerne har forskellige ydelseskarakteristika
Hurtig tilstand og Skaleringsniveau har fastlagte SLA'er
Hvis niveauerne blandes, skjules ydelsen på betalingsniveauet
Det er især vigtigt ved analyse af latenstid.
For eksisterende modeller vises trafik i Hurtig tilstand stadig som prioriteret på dashboardet Forbrug.
Filtrér efter projekt
Som standard viser Service Health alle projekter.
Ved fejlfinding skal du filtrere til det eller de projekter, hvor problemet blev observeret.
Hvorfor:
Et enkelt projekt med høj volumen kan dominere målingerne.
Mindre berørte projekter kan skjules af urelateret trafik.
Lad kun »Alle projekter« være valgt, hvis du mener, at problemet virkelig omfatter hele organisationen.
Fejlfinding af fejl
Brug visningen HTTP-anmodninger
Sådan undersøger du fejl:
Filtrér efter model og serviceniveau.
Åbn fanen HTTP-anmodninger i stedet for fanen Oppetid.
Denne visning viser det samlede antal anmodninger og fejltællinger efter HTTP-statuskode. Zoom til minutopløsning for at identificere detaljerede stigninger eller ændringer.
Fortolk fejlrater, ikke antal
Nogle fejl kan forventes i ethvert produktionssystem. Fokuser på fejlprocenten, ikke rå totaler.
Jo større dit samlede volumen er, desto større er det mulige antal fejl, selv med en ekstremt lav fejlrate.
Når fejl mangler i Service Health
Hvis du ser fejl på klientsiden, men ingen tilsvarende data i Service Health:
Anmodningerne nåede sandsynligvis ikke OpenAI.
Problemet er normalt upstream (timeouts, proxyer, netværk).
Dette er almindeligt ved aggressive timeouts på klientsiden.
Fejlfinding af latenstid
Analyse af latenstid giver mest mening for Hurtig tilstand og Skaleringsniveau, som har fastlagte SLA'er. Standardniveauet kan have større variation i latenstiden og garanterer ikke en bestemt latenstid.
Nøgletal
Klik på den relevante fane for at se hver måling:
Tokenhastighed: Tokens genereret pr. sekund; uafhængigt af promptens størrelse.
Anmodningstid: Samlet varighed af anmodningen; påvirkes stærkt af outputstørrelse og ræsonnering.
Tid til første token (TTFT): Tid, indtil den første token genereres; påvirkes stærkt af størrelsen på ikke-cachelagrede inputprompts og ræsonnering.
Gennemgå altid P50-/P75-/P95-percentiler. Gennemsnit kan skjule påvirkningen for reelle brugere.
Sammenhængen mellem latenstid og tokenforbrug
Tjenestestatus viser, hvornår adfærden ændrede sig. Forbrugsdata hjælper med at forklare hvorfor.
Gør følgende i forbrugsdashboardet for at sikre, at du ser på data, der er relevante for din visning i dashboardet for tjenestestatus:
Filtrér efter samme projekt og model.
Gruppér efter serviceniveau, hvis det er relevant.
Fokusér på outputtoken, som har størst indflydelse på latenstiden.
Hvis du vil analysere nærmere, kan du eksportere aktivitetsdata og undersøge antallet af token pr. anmodning over tid.
Oplysninger til support, hvis du får brug for hjælp
Hvis du kontakter support, skal du medtage:
Berørte organisations-id'er (vigtigt)
Berørte endpoints, f.eks. Chat Completions eller Responses (vigtigt)
Berørte modeller (vigtigt)
Om problemet opstår i Hurtig tilstand eller på Skaleringsniveau (vigtigt)
Tidsrum med tidszone for latenstidsproblemer eller fejl (vigtigt)
Relevante x-request-id eller X-Client-Request-Id, hvis de er tilgængelige
Tidsstempler med tidszone eller som minimum datoen for de anmodninger, du angiver
Medtag også følgende, hvis oplysningerne er tilgængelige:
Projekt-id for de pågældende anmodninger
Om anmodninger med krav om dataresidens er berørt, og i så fald hvilke
Beskrivelser af de tendenser, du ser
Afhængigt af problemtypen skal du medtage:
Fejl: Den omtrentlige procentdel af anmodninger, der mislykkes eller returnerer fejl, svarkoder, fejlmeddelelser, og hvor lang tid der gik, før fejlsvaret blev modtaget.
Latenstid: Hvilke percentiler der er påvirket (P50 / P90 / P95 / P99), hvor høje de er i forhold til kundens normale niveau, samt eksempler på langsomme anmodninger med tidsstempler for afsendelse og modtagelse.
Begge: Skærmbilleder eller en tabel med fejl- eller latenstidsdata samt en beskrivelse af, hvordan du konstaterede, at fejlraten eller latenstiden var højere end forventet.
Almindelige fejlfindingsscenarier
Timeouts opstår, men Service Health ser normal ud
Mulig årsag: anmodninger får timeout, før de når OpenAI.
Tjek:
Timeoutindstillinger for klient eller proxy
Ændringer i lokalt netværk eller load balancer
Forekomst af 499-fejl i Service Health-dashboardet (disse kan vises som 5xx-fejl i dine egne systemer).
Latenstiden steg uden en udrulning
Mulig årsag: størrelsen på output-tokens eller brugen af ræsonnering steg, og/eller trafikken flyttede mellem serviceniveauer.
Tjek:
Gennemsnitligt antal output-tokens pr. anmodning i Forbrugsdashboardet (kræver download af data og division af output-tokens med samlede anmodninger).
Anmodningstid- og TTFT-percentiler i Service Health-dashboardet.
Hurtig tilstand eller Skaleringsniveau virker langsomt
Mulig årsag: Målinger fra forskellige niveauer er blandet sammen, så trafik på standardniveauet skjuler ydelsen på betalingsniveauet.
Kontrollér:
Filtrene er begrænset til ét niveau og én model.
Sammenligning af tokenhastighed mellem niveauer.
Stigning i 5XX-fejl
Sandsynlig årsag: forbigående fejl, der påvirker en lille procentdel af trafikken.
Tjek:
Procentvis fejlrate
Om trafikvolumen ændrede sig samtidig
Problemet påvirker kun ét projekt
Sandsynlig årsag: projektspecifik konfiguration eller brugsmønster.
Tjek:
Filtrering på projektniveau
Sammenligning med upåvirkede projekter
Afsluttende hovedpunkter
Filtrér efter model, niveau og projekt, hvor det er relevant, før du fortolker målinger.
Brug percentiler, ikke gennemsnit, til latenstidsanalyse.
Små fejlrater er forventelige.
Manglende data indikerer normalt upstream-problemer.
Forbrugsdata kan hjælpe med at forklare, hvorfor latenstiden ændrede sig; Service Health viser, hvornår adfærden ændrede sig.