Viktige lenker
*Service Health-dashbordet er for øyeblikket bare tilgjengelig for Enterprise API-kunder.
Start med riktige standardinnstillinger
Når du åpner Service Health-dashbordet, er standardvalgene:
Alle prosjekter
Siste 30 dager
Timesoppløsning
Denne visningen er bare nyttig for orientering. Meningsfull feilsøking krever alltid filtrering.
Filtrer før du undersøker
Riktig filtrering er det viktigste trinnet. De fleste feiltolkninger kommer av å blande modeller, nivåer eller prosjekter.
Filtrer etter modell (én om gangen)
Filtrer alltid til én enkelt modell.
Hvorfor:
Problemer på modeller med lav trafikk kan skjules av trafikk med høyere volum
Modeller med høyt volum kan få lokale problemer til å se globale ut
Ulike modeller har ulike ytelsesmål
Merk: Hvis du velger flere modeller, aggregeres de – det bytter ikke mellom dem.
Filtrer etter tjenestenivå
Hvis du bruker mer enn ett nivå (standard, priority, scale), må du alltid filtrere til nivået du undersøker.
Hvorfor:
Nivåer har ulike ytelsesegenskaper
Priority- og scale-nivåer har definerte SLA-er
Blanding av nivåer skjuler ytelsen på betalte nivåer
Dette er spesielt viktig for latensanalyse.
Filtrer etter prosjekt
Som standard viser Service Health alle prosjekter.
For feilsøking bør du filtrere til prosjektet/prosjektene der problemet ble observert.
Hvorfor:
Ett enkelt prosjekt med høyt volum kan dominere måltallene
Mindre berørte prosjekter kan bli skjult av urelatert trafikk
La bare "Alle prosjekter" være valgt hvis du tror problemet faktisk gjelder hele organisasjonen.
Feilsøking av feil
Bruk visningen for HTTP-forespørsler
Slik undersøker du feil:
Filtrer etter modell og nivå
For å bytte fra Uptime til HTTP Requests klikker du på fanen HTTP Requests
Denne visningen viser totale forespørsler og antall feil etter HTTP-statuskode. Zoom til minuttoppløsning for å identifisere detaljerte topper eller endringer.
Tolk feilrater, ikke antall
Noen feil er forventet i ethvert produksjonssystem. Fokuser på feil i prosent, ikke rå totaler.
Jo større totalvolum du har, desto større er det potensielle antallet feil selv med en ekstremt lav feilrate.
Når feil mangler i Service Health
Hvis du ser feil på klientsiden, men ingen tilsvarende data i Service Health:
Forespørsler nådde sannsynligvis ikke OpenAI
Problemet er vanligvis oppstrøms (tidsavbrudd, proxier, nettverk)
Dette er vanlig med aggressive tidsavbrudd på klientsiden.
Feilsøking av latens
Latensanalyse er mest meningsfull på priority- og scale-nivåer, som har definerte SLA-er. Standardnivået kan vise større variasjon i latens og har ikke garantert latens.
Nøkkelmåltall
For å vise hvert av disse måltallene klikker du på den relevante fanen:
Tokenhastighet
Token generert per sekund.
Uavhengig av promptstørrelse.
Forespørselstid
Total varighet for forespørselen.
Påvirkes sterkt av størrelsen på output og resonnering.
Tid til første token (TTFT)
Tid til det første tokenet genereres.
Påvirkes sterkt av størrelsen på ukachet input-prompt og resonnering.
Se alltid på persentilene P50 / P75 / P95. Gjennomsnitt kan skjule påvirkningen på reelle brukere.
6. Koble latens til tokenbruk
Service Health viser når atferden endret seg. Usage-data hjelper med å forklare hvorfor.
I Usage-dashbordet gjør du følgende for å sikre at du ser på dataene som er relevante for visningen i Service Health-dashbordet:
Filtrer til samme prosjekt, modell
Grupper etter tjenestenivå hvis aktuelt
Fokuser på output-token, som påvirker latens mest
For dypere analyse eksporterer du aktivitetsdata og undersøker token per forespørsel over tid.
7. Hva du bør dele med support (ved behov)
Hvis du kontakter support, ta med:
Berørte organisasjons-ID-er (dette er viktig)
Berørte endepunkter (Chat Completions, Responses osv.) (dette er viktig)
Berørte modeller (dette er viktig)
Er dette på scale- eller priority-nivå? (dette er viktig)
Tidsintervaller med tidssone for latens eller feil (dette er viktig)
Relevant x-request-id eller X-Client-Request-Id (ofte viktig; inkluder hvis mulig)
Tidsstempler med tidssone (eller i det minste datoen) for forespørslene som oppgis
Latens - hvis du deler eksempler på trege forespørsler, del hvor lang tid det tok hos deg. Inkluder helst også tidsstemplene for når forespørselen ble sendt og når den ble mottatt.
Feil - del omtrentlig prosentandel av forespørsler som feiler, responskode(r), feilmelding(er) og hvor lang tid det tok å få feilresponsen
Prosjekt-id knyttet til forespørsler
Påvirker dette forespørsler om dataresidens? Hvis ja, hvilke?
Beskrivelser av trendene du ser
Feil: Omtrentlig % av forespørsler som feiler
Latens: Hvilke persentiler som er berørt (p50 / p90 / p95 / p99), og hvor mye høyere de er sammenlignet med kundens basisnivå
Begge: Skjermbilder eller tabell over feil- eller latensdata (Hvordan avgjorde du at feilratene eller latensen er høyere enn forventet?)
Vanlige feilsøkingsscenarier
Tidsavbrudd oppstår, men Service Health ser normal ut
Mulig årsak: forespørsler får tidsavbrudd før de når OpenAI.
Sjekk:
Innstillinger for tidsavbrudd i klient eller proxy
Endringer i lokalt nettverk eller lastbalanserer
Om det finnes 499-feil i Service Health-dashbordet (disse kan vises som 5xx-feil i dine egne systemer).
Latensen økte uten en utrulling
Mulig årsak: Størrelsen på output-token eller bruk av resonnering økte og\eller trafikken flyttet seg mellom tjenestenivåer
Sjekk:
Gjennomsnittlig antall output-token per forespørsel i Usage-dashbordet (krever nedlasting av data og at output-token deles på totalt antall forespørsler).
Persentiler for Request Time og TTFT i Service Health-dashbordet.
Priority- eller Scale-nivå virker tregt
Mulig årsak: måltall er blandet på tvers av nivåer (det betyr at trafikk på standardnivå skjuler ytelsen på betalte nivåer)
Sjekk:
Filtre er begrenset til ett enkelt nivå og én modell
Sammenligning av tokenhastighet mellom nivåer
Topp i 5XX-feil
Sannsynlig årsak: forbigående feil som påvirker en liten prosentandel av trafikken.
Sjekk:
Feilrate i prosent
Om trafikkvolumet endret seg samtidig
Problemet påvirker bare ett prosjekt
Sannsynlig årsak: prosjektspesifikk konfigurasjon eller bruksmønster.
Sjekk:
Filtrering på prosjektnivå
Sammenligning med prosjekter som ikke er berørt
Viktige oppsummeringer
Filtrer etter modell, nivå og, der det er relevant, prosjekt før du tolker måltall
Bruk persentiler, ikke gjennomsnitt, for latensanalyse
Små feilrater er forventet
Manglende data indikerer vanligvis oppstrømsproblemer
Usage-data kan bidra til å forklare hvorfor latensen endret seg; Service Health hjelper med å vise når