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, priority, scale), skal du altid filtrere til det niveau, du undersøger.
Hvorfor:
Niveauer har forskellige præstationskarakteristika
Priority- og scale-niveauer har definerede SLA'er
Blanding af niveauer skjuler ydeevnen på betalte niveauer
Dette er især vigtigt for latenstidsanalyse.
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
Latenstidsanalyse er mest meningsfuld på priority- og scale-niveauer, som har definerede SLA'er. Standardniveau kan vise større variation i latenstid og har ikke garanteret 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.
6. Korrelation af latenstid med tokenforbrug
Service Health viser, hvornår adfærden ændrede sig. Forbrugsdata hjælper med at forklare hvorfor.
I Forbrugsdashboardet skal du gøre følgende for at sikre, at du ser på de data, der er relevante for din visning i Service Health-dashboardet:
Filtrér til det samme projekt og den samme model.
Gruppér efter serviceniveau, hvis relevant.
Fokuser på output-tokens, som påvirker latenstiden mest.
Eksportér aktivitetsdata, og undersøg tokens pr. anmodning over tid for en dybere analyse.
7. Hvad du skal dele med support (hvis nødvendigt)
Hvis du kontakter support, skal du inkludere:
Berørte organisations-id'er (vigtigt)
Berørte endepunkter, f.eks. Chat Completions eller Responses (vigtigt)
Berørte modeller (vigtigt)
Om dette er på Skalerings- eller Priority-niveau (vigtigt)
Tidsintervaller med tidszone for latenstid eller fejl (vigtigt)
Relevant x-request-id eller X-Client-Request-Id, hvis tilgængeligt
Tidsstempler med tidszone, eller som minimum datoen, for de anmodninger, du angiver
Hvis tilgængeligt, skal du også inkludere:
Projekt-id relateret til anmodningerne
Om anmodninger om dataresidens er påvirket, og hvilke
Beskrivelser af de tendenser, du ser
For problemtypen skal du inkludere:
Fejl: Omtrentlig procentdel af mislykkede anmodninger eller anmodninger med fejl, svarkoder, fejlmeddelelser og hvor lang tid det tog at modtage fejlsvaret.
Latenstid: Hvilke percentiler der er påvirket (P50/P90/P95/P99), hvor høje de er sammenlignet med kundens baseline, og eksempler på langsomme anmodninger med tidsstempler for afsendelse og modtagelse.
Begge: Skærmbilleder eller en tabel med fejl- eller latenstidsdata samt hvordan du fastslog, at fejlrater eller latenstid 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.
Priority- eller Skaleringsniveau virker langsomt
Mulig årsag: målinger er blandet på tværs af niveauer, så trafik på standardniveau skjuler ydeevnen på betalte niveauer.
Tjek:
Filtre 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.