Viktiga länkar
Service Health-instrumentpanelen (för närvarande endast tillgänglig för Enterprise API-kunder)
Börja med rätt standardinställningar
När du öppnar Service Health-instrumentpanelen är standardinställningarna:
Alla projekt
Senaste 30 dagarna
Timupplösning
Den här vyn är endast användbar för orientering. Meningsfull felsökning kräver alltid filtrering.
Filtrera innan du undersöker
Korrekt filtrering är det viktigaste steget. De flesta feltolkningar beror på att modeller, nivåer eller projekt blandas.
Filtrera efter modell (en i taget)
Filtrera alltid till en enda modell.
Varför:
Problem på modeller med låg trafik kan döljas av trafik med högre volym
Modeller med hög volym kan få lokala problem att se globala ut
Olika modeller har olika prestandamål
Obs! Om du väljer flera modeller aggregeras de – du växlar inte mellan dem.
Filtrera efter servicenivå
Om du använder fler än en nivå (standard, prioritet, skalning) ska du alltid filtrera till den nivå du undersöker.
Varför:
Nivåer har olika prestandaegenskaper
Prioritets- och skalningsnivåer har definierade SLA:er
Att blanda nivåer döljer prestanda på betalda nivåer
Detta är särskilt viktigt för latensanalys.
Filtrera efter projekt
Som standard visar Service Health alla projekt.
Vid felsökning filtrerar du till de projekt där problemet observerades.
Varför:
Ett enskilt projekt med hög volym kan dominera mätvärdena.
Mindre påverkade projekt kan döljas av orelaterad trafik.
Låt endast "Alla projekt" vara valt om du tror att problemet verkligen gäller hela organisationen.
Felsökning av fel
Använd vyn HTTP-förfrågningar
Så här undersöker du fel:
Filtrera efter modell och servicenivå.
Öppna fliken HTTP-förfrågningar i stället för fliken Drifttid.
Den här vyn visar totalt antal förfrågningar och felantal per HTTP-statuskod. Zooma till upplösning på minutnivå för att identifiera detaljerade toppar eller ändringar.
Tolka felfrekvenser, inte antal
Vissa fel är förväntade i alla produktionssystem. Fokusera på felprocent, inte råa totalsummor.
Ju större din totala volym är, desto större kan antalet fel bli även med en extremt låg felfrekvens.
När fel saknas i Service Health
Om du ser fel på klientsidan men inga motsvarande data i Service Health:
Förfrågningarna nådde sannolikt inte OpenAI.
Problemet finns vanligtvis uppströms (tidsgränser, proxyservrar, nätverk).
Detta är vanligt med aggressiva tidsgränser på klientsidan.
Felsökning av latens
Latensanalys är mest meningsfull på prioritetsnivåer och skalningsnivåer, som har definierade SLA:er. Standardnivån kan uppvisa större latensvariation och har ingen garanterad latens.
Viktiga mätvärden
Om du vill visa varje mätvärde klickar du på relevant flik:
Tokenhastighet: Token som genereras per sekund, oberoende av promptstorlek.
Förfrågningstid: Total förfrågningslängd, påverkas starkt av utdatastorlek och resonemang.
Tid till första token (TTFT): Tid tills den första token genereras, påverkas starkt av ocachad indatapromptstorlek och resonemang.
Granska alltid P50-/P75-/P95-percentiler. Medelvärden kan dölja påverkan på verkliga användare.
6. Korrelera latens med tokenanvändning
Service Health visar när beteendet ändrades. Användningsdata hjälper till att förklara varför.
Gör följande i användningsinstrumentpanelen för att säkerställa att du tittar på de data som är relevanta för din vy i Service Health-instrumentpanelen:
Filtrera till samma projekt och modell.
Gruppera efter servicenivå, om tillämpligt.
Fokusera på utgående token, som påverkar latensen mest.
För djupare analys exporterar du aktivitetsdata och granskar token per förfrågan över tid.
7. Vad du ska dela med supporten (vid behov)
Om du kontaktar supporten ska du inkludera:
Påverkade organisations-ID:n (viktigt)
Påverkade slutpunkter, till exempel Chat Completions eller Responses (viktigt)
Påverkade modeller (viktigt)
Om detta gäller skalnings- eller prioritetsnivån (viktigt)
Tidsintervall med tidszon för latens eller fel (viktigt)
Relevant x-request-id eller X-Client-Request-Id, om tillgängligt
Tidsstämplar med tidszon, eller åtminstone datumet, för de förfrågningar du tillhandahåller
Om tillgängligt, inkludera även:
Projekt-ID relaterat till förfrågningarna
Om förfrågningar med datahemvist påverkas, och vilka
Beskrivningar av de trender du ser
För typen av problem inkluderar du:
Fel: Ungefärlig procentandel av misslyckade förfrågningar eller förfrågningar med fel, svarskoder, felmeddelanden och hur lång tid det tog att få felsvaret.
Latens: Vilka percentiler som påverkas (P50/P90/P95/P99), hur höga de är jämfört med kundens baslinje, samt exempel på långsamma förfrågningar med tidsstämplar för sändning och mottagning.
Båda: Skärmbilder eller en tabell med fel- eller latensdata, samt hur du fastställde att felfrekvenser eller latens var högre än förväntat.
Vanliga felsökningsscenarier
Tidsgränser nås men Service Health ser normalt ut
Möjlig orsak: förfrågningarna når tidsgränsen innan de når OpenAI.
Kontrollera:
Inställningar för tidsgränser i klient eller proxy
Ändringar i lokalt nätverk eller lastbalanserare
Förekomst av 499-fel i Service Health-instrumentpanelen (dessa kan visas som 5xx-fel i dina egna system).
Latensen ökade utan en driftsättning
Möjlig orsak: storleken på utgående token eller användningen av resonemang ökade och/eller trafiken flyttades mellan servicenivåer.
Kontrollera:
Genomsnittligt antal utgående token per förfrågan i användningsinstrumentpanelen (kräver att data hämtas och att utgående token divideras med totalt antal förfrågningar).
Percentiler för förfrågningstid och TTFT i Service Health-instrumentpanelen.
Prioritets- eller skalningsnivån verkar långsam
Möjlig orsak: mätvärden blandas mellan nivåer, vilket innebär att trafik på standardnivå döljer prestanda på betald nivå.
Kontrollera:
Filtren är begränsade till en enda nivå och modell.
Jämförelse av tokenhastighet mellan nivåer.
Ökning av 5XX-fel
Sannolik orsak: tillfälliga fel som påverkar en liten procentandel av trafiken.
Kontrollera:
Procentuell felfrekvens
Om trafikvolymen ändrades samtidigt
Problemet påverkar bara ett projekt
Sannolik orsak: projektspecifik konfiguration eller användningsmönster.
Kontrollera:
Filtrering på projektnivå
Jämförelse med opåverkade projekt
Slutsatser
Filtrera efter modell, nivå och projekt där det är relevant innan du tolkar mätvärden.
Använd percentiler, inte medelvärden, för latensanalys.
Små felfrekvenser är förväntade.
Saknade data tyder vanligtvis på problem uppströms.
Användningsdata kan hjälpa till att förklara varför latensen ändrades; Service Health visar när beteendet ändrades.