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.
Analysera sambandet mellan latens och tokenanvändning
Tjänststatus visar när beteendet ändrades. Användningsdata hjälper till att förklara varför.
Gör följande i instrumentpanelen Användning för att säkerställa att du tittar på data som är relevanta för din vy i instrumentpanelen Tjänststatus:
Filtrera på samma projekt och modell.
Gruppera efter servicenivå, om tillämpligt.
Fokusera på utdatatoken, som påverkar latensen mest.
För en djupare analys kan du exportera aktivitetsdata och undersöka antalet token per begäran över tid.
Uppgifter att dela med supporten vid behov
Om du kontaktar supporten, inkludera:
Berörda organisations-ID:n (viktigt)
Berörda slutpunkter, till exempel Chat Completions eller Responses (viktigt)
Berörda modeller (viktigt)
Servicenivån som används för de berörda förfrågningarna, till exempel Standard, Snabbläge eller Skalningsnivå (viktigt)
Tidsintervall med tidszon för svarstidsproblem 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 förfrågningar du anger
Inkludera även följande, om tillgängligt:
Projekt-ID kopplat till förfrågningarna
Om förfrågningar med krav på datahemvist påverkas och i så fall vilka, inklusive avsedd region för datahemvist och det regionala API-värdnamn som används
Beskrivningar av de mönster du ser
För aktuell information om vilka modeller och slutpunkter som stöds i olika regioner, se: Datakontroller på OpenAI-plattformen.
Dela konfigurations- och felinformation där känsliga uppgifter har tagits bort. Ta bort API-nycklar, autentiseringsuppgifter, prompter och annat känsligt kundinnehåll från exempel och skärmbilder.
Beroende på typ av problem, inkludera:
Fel: Ungefärlig andel förfrågningar som misslyckas eller ger fel, uttryckt i procent, samt 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 värdena är jämfört med kundens normala nivå och exempel på långsamma förfrågningar med tidsstämplar för när de skickades och när svaren togs emot.
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.