Belangrijke links
*Het Service Health-dashboard is momenteel alleen beschikbaar voor Enterprise API-klanten.
Begin met de juiste standaarden
Wanneer je het Service Health-dashboard opent, staat het standaard op:
Alle projecten
Afgelopen 30 dagen
Resolutie per uur
Deze weergave is alleen nuttig ter oriëntatie. Zinvolle probleemoplossing vereist altijd filtering.
Filter voordat je onderzoekt
Correct filteren is de belangrijkste stap. De meeste misinterpretaties ontstaan door modellen, tiers of projecten te combineren.
Filter op model (één tegelijk)
Filter altijd op één model.
Waarom:
Problemen bij modellen met weinig verkeer kunnen worden verborgen door verkeer met een hoger volume
Modellen met een hoog volume kunnen lokale problemen wereldwijd doen lijken
Verschillende modellen hebben verschillende prestatiedoelen
Opmerking: als je meerdere modellen selecteert, worden ze samengevoegd — er wordt niet tussen gewisseld.
Filter op servicetier
Als je meer dan één tier gebruikt (standard, priority, scale), filter dan altijd op de tier die je onderzoekt.
Waarom:
Tiers hebben verschillende prestatiekenmerken
Priority- en scale-tiers hebben gedefinieerde SLA's
Het combineren van tiers verbergt de prestaties van betaalde tiers
Dit is vooral belangrijk voor latentieanalyse.
Filter op project
Standaard toont Service Health alle projecten.
Filter voor probleemoplossing op het project of de projecten waar het probleem is waargenomen.
Waarom:
Eén project met een hoog volume kan de metrics domineren
Kleinere getroffen projecten kunnen worden gemaskeerd door niet-gerelateerd verkeer
Laat alleen "Alle projecten" geselecteerd als je denkt dat het probleem echt organisatiebreed is.
Problemen met fouten oplossen
Gebruik de HTTP Requests-weergave
Om fouten te onderzoeken:
Filter op model en tier
Klik op het tabblad HTTP Requests om van Uptime naar HTTP Requests te schakelen
Deze weergave toont het totale aantal verzoeken en het aantal fouten per HTTP-statuscode. Zoom in naar een resolutie op minuutniveau om gedetailleerde pieken of veranderingen te identificeren.
Interpreteer foutpercentages, geen aantallen
Sommige fouten zijn te verwachten in elk productiesysteem. Focus op het percentage fouten, niet op ruwe totalen.
Hoe groter je totale volume, hoe groter het potentiële aantal fouten, zelfs bij een uiterst laag foutpercentage.
Wanneer fouten ontbreken in Service Health
Als je client-side fouten ziet maar geen overeenkomstige data in Service Health:
Hebben verzoeken OpenAI waarschijnlijk niet bereikt
Bevindt het probleem zich meestal upstream (timeouts, proxies, netwerken)
Dit komt vaak voor bij agressieve client-side timeouts.
Problemen met latentie oplossen
Latentieanalyse is het meest zinvol op priority- en scale-tiers, die gedefinieerde SLA's hebben. De standard-tier kan grotere latentievariatie vertonen en heeft geen gegarandeerde latentie.
Belangrijke metrics
Klik op het relevante tabblad om elk van deze metrics te bekijken:
Tokensnelheid
Tokens die per seconde worden gegenereerd.
Onafhankelijk van de promptgrootte.
Request Time
Totale duur van het verzoek.
Sterk beïnvloed door outputgrootte en redenering.
Time to First Token (TTFT)
Tijd totdat de eerste token wordt gegenereerd.
Sterk beïnvloed door de grootte van de niet-gecachete invoerprompt en redenering.
Controleer altijd de P50- / P75- / P95-percentielen. Gemiddelden kunnen de impact op echte gebruikers verbergen.
6. Latentie correleren met tokengebruik
Service Health laat zien wanneer gedrag veranderde. Usage-data helpt te verklaren waarom.
Doe in het Usage-dashboard het volgende om ervoor te zorgen dat je kijkt naar de data die relevant is voor je weergave in het Service Health-dashboard:
Filter op hetzelfde project, model
Groepeer op servicetier indien van toepassing
Focus op outputtokens, die de meeste invloed hebben op latentie
Exporteer voor een diepere analyse Activity Data en bekijk tokens per verzoek in de tijd.
7. Wat je met Support moet delen (indien nodig)
Als je contact opneemt met support, voeg dan het volgende toe:
Betrokken Org ID's (dit is belangrijk)
Betrokken endpoints (Chat Completions, Responses, enz.) (dit is belangrijk)
Betrokken modellen (dit is belangrijk)
Gaat het om de scale- of priority-tier? (dit is belangrijk)
Tijdsbereiken met tijdzone voor latentie of fouten (dit is belangrijk)
Relevante x-request-id of X-Client-Request-Id (vaak belangrijk; voeg toe indien mogelijk)
Tijdstempels met tijdzone (of op zijn minst de datum) van de opgegeven verzoeken
Latentie - als je voorbeelden van trage verzoeken deelt, geef dan aan hoe lang het aan jouw kant duurde. Idealiter voeg je ook de tijdstempels toe van wanneer het verzoek is verzonden en wanneer het is ontvangen.
Fouten - deel het geschatte percentage mislukte/foutgevende verzoeken, responsecode(s), foutmelding(en) en hoe lang het duurde voordat je de foutrespons kreeg
Project-id gekoppeld aan verzoeken
Heeft dit invloed op verzoeken met gegevensresidentie? Zo ja, welke?
Beschrijvingen van de trends die je ziet
Fouten: Geschat % mislukte/foutgevende verzoeken
Latentie: Welke percentielen worden beïnvloed (p50 / p90 / p95 / p99), en hoe hoog ze zijn vergeleken met de baseline van de klant
Beide: Screenshots of een tabel met fout- of latentiedata (Hoe heb je vastgesteld dat foutpercentages of latentie hoger zijn dan verwacht?)
Veelvoorkomende scenario's voor probleemoplossing
Timeouts treden op maar Service Health ziet er normaal uit
Mogelijke oorzaak: verzoeken verlopen door een time-out voordat ze OpenAI bereiken.
Controleer:
Timeoutinstellingen van client of proxy
Wijzigingen in lokaal netwerk of load balancer
De aanwezigheid van 499-fouten in het Service Health-dashboard (deze kunnen in je eigen systemen als 5xx-fouten verschijnen).
Latentie nam toe zonder een deployment
Mogelijke oorzaak: de grootte van outputtokens of het gebruik van redenering nam toe en\of verkeer verschoof tussen servicetiers
Controleer:
Gemiddeld aantal outputtokens per verzoek in het Usage-dashboard (vereist het downloaden van data en het delen van outputtokens door het totale aantal verzoeken).
Request Time- en TTFT-percentielen in het Service Health-dashboard.
Priority- of scale-tier lijkt traag
Mogelijke oorzaak: metrics zijn gemengd over tiers heen (wat betekent dat verkeer van de standard-tier de prestaties van betaalde tiers maskeert)
Controleer:
Filters zijn beperkt tot één tier en model
Vergelijking van tokensnelheid tussen tiers
Piek in 5XX-fouten
Waarschijnlijke oorzaak: tijdelijke storingen die een klein percentage van het verkeer beïnvloeden.
Controleer:
Foutpercentage
Of het verkeersvolume tegelijk veranderde
Probleem treft slechts één project
Waarschijnlijke oorzaak: projectspecifieke configuratie of gebruikspatroon.
Controleer:
Filtering op projectniveau
Vergelijking met niet-getroffen projecten
Belangrijkste conclusies
Filter op model, tier en waar relevant project voordat je metrics interpreteert
Gebruik percentielen, geen gemiddelden, voor latentieanalyse
Kleine foutpercentages zijn te verwachten
Ontbrekende data duidt meestal op upstream-problemen
Usage-data kan helpen verklaren waarom latentie veranderde; Service Health helpt te tonen wanneer