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 mer än en nivå (standard, Snabbläge (tidigare Priority processing), Skalningsnivå) ska du alltid filtrera på den nivå som du undersöker.
Varför:
Nivåerna har olika prestandaegenskaper
Snabbläge och Skalningsnivå har fastställda SLA:er
Om nivåerna blandas döljs betalnivåns prestanda
Detta är särskilt viktigt vid analys av svarstider.
För befintliga modeller visas trafik från Snabbläge fortfarande som priority på instrumentpanelen Usage.
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öka svarstider
Analys av svarstider är mest relevant för nivåerna Snabbläge och Skalningsnivå, som har fastställda SLA:er. Standardnivån kan ha större variation i svarstiderna och saknar garanterade svarstider.
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 skicka till supporten (vid behov)
Om du kontaktar supporten ska du ange:
Berörda organisations-ID:n (viktigt)
Berörda slutpunkter, till exempel Chat Completions eller Responses (viktigt)
Berörda modeller (viktigt)
Om detta gäller Snabbläge eller Skalningsnivå (viktigt)
Tidsintervall och tidszon för svarstider eller fel (viktigt)
Relevanta x-request-id eller X-Client-Request-Id, om tillgängliga
Tidsstämplar med tidszon, eller åtminstone datum, för de begäranden du skickar in
Ange även följande om det är tillgängligt:
Projekt-ID för begärandena
Om begäranden med datahemvist påverkas och i så fall vilka
Beskrivningar av de trender du ser
Ange följande beroende på typen av problem:
Fel: Ungefärlig andel misslyckade begäranden eller begäranden som resulterar i fel, svarskoder, felmeddelanden och hur lång tid det tog att få felsvaret.
Svarstid: 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 begäranden med tidsstämplar för sändning och mottagning.
Båda: Skärmbilder eller en tabell med fel- eller svarstidsdata samt hur du fastställde att felfrekvensen eller svarstiden 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.
Snabbläge eller Skalningsnivå verkar långsamt
Möjlig orsak: mätvärden från olika nivåer har blandats, vilket innebär att trafiken på standardnivån döljer betalnivåns prestanda.
Kontrollera att:
Filtren är begränsade till en enda nivå och modell.
Jämförelse av tokenhastighet mellan nivåerna.
Ö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.