Belangrijke links
Service Health-dashboard (momenteel alleen beschikbaar voor Enterprise API-klanten)
Begin met de juiste standaardinstellingen
Wanneer je het Service Health-dashboard opent, staat dit standaard ingesteld op:
Alle projecten
Laatste 30 dagen
Uurresolutie
Deze weergave is alleen nuttig voor oriëntatie. Zinvolle probleemoplossing vereist altijd filtering.
Filter voordat je onderzoekt
Correct filteren is de belangrijkste stap. De meeste verkeerde interpretaties ontstaan door het combineren van modellen, niveaus of projecten.
Filteren op model (één tegelijk)
Filter altijd op één model.
Waarom:
Problemen bij modellen met weinig verkeer kunnen worden verborgen door verkeer met hoger volume
Modellen met hoog volume kunnen lokale problemen globaal laten lijken
Verschillende modellen hebben verschillende prestatiedoelen
Opmerking: als je meerdere modellen selecteert, worden ze samengevoegd; er wordt niet tussen gewisseld.
Filteren op serviceniveau
Als u meerdere niveaus gebruikt (standaard, Fast-modus (voorheen prioriteitsverwerking), schaalniveau), filter dan altijd op het niveau dat u onderzoekt.
Waarom:
Niveaus hebben verschillende prestatiekenmerken
Voor Fast-modus en schaalniveau zijn SLA's vastgelegd
Het combineren van niveaus verhult de prestaties van betaalde niveaus
Dit is vooral belangrijk bij latentieanalyses.
In het Usage-dashboard wordt verkeer in Fast-modus voor bestaande modellen nog steeds als priority weergegeven.
Filteren op project
Standaard toont Service Health alle projecten.
Filter voor probleemoplossing op de project(en) waar het probleem is waargenomen.
Waarom:
Eén project met hoog volume kan statistieken domineren.
Kleinere getroffen projecten kunnen worden gemaskeerd door niet-gerelateerd verkeer.
Laat “Alle projecten” alleen geselecteerd als je denkt dat het probleem echt de hele organisatie treft.
Problemen met fouten oplossen
Gebruik de weergave HTTP-verzoeken
Om fouten te onderzoeken:
Filter op model en serviceniveau.
Open het tabblad HTTP-verzoeken in plaats van het tabblad Uptime.
Deze weergave toont het totale aantal verzoeken en foutaantallen per HTTP-statuscode. Zoom in tot resolutie op minuutniveau om gedetailleerde pieken of veranderingen te identificeren.
Interpreteer foutpercentages, geen aantallen
In elk productiesysteem zijn sommige fouten te verwachten. Richt je op het percentage fouten, niet op ruwe totalen.
Hoe groter je totale volume, hoe groter het mogelijke aantal fouten, zelfs bij een extreem laag foutpercentage.
Wanneer fouten ontbreken in Service Health
Als je fouten aan clientzijde ziet, maar geen bijbehorende gegevens in Service Health:
Verzoeken hebben OpenAI waarschijnlijk niet bereikt.
Het probleem zit meestal upstream (time-outs, proxy's, netwerk).
Dit komt vaak voor bij agressieve time-outs aan clientzijde.
Latentieproblemen oplossen
Latentieanalyse is het meest zinvol voor de niveaus Fast-modus en schaalniveau, waarvoor SLA's zijn vastgelegd. Het standaardniveau kan grotere latentieverschillen vertonen en biedt geen gegarandeerde latentie.
Kernstatistieken
Klik op het relevante tabblad om elke statistiek te bekijken:
Tokensnelheid: tokens die per seconde worden gegenereerd; onafhankelijk van de promptgrootte.
Verzoektijd: totale duur van het verzoek; sterk beïnvloed door outputgrootte en redenering.
Tijd tot eerste token (TTFT): tijd totdat het eerste token wordt gegenereerd; sterk beïnvloed door de grootte van de niet-gecachete invoerprompt en redenering.
Bekijk altijd de P50-/P75-/P95-percentielen. Gemiddelden kunnen impact op echte gebruikers verbergen.
Latentie koppelen aan tokengebruik
Dienststatus laat zien wanneer het gedrag veranderde. Gebruiksgegevens helpen verklaren waarom.
Doe het volgende in het gebruiksdashboard om ervoor te zorgen dat je de gegevens bekijkt die aansluiten op je weergave in het dashboard voor dienststatus:
Filter op hetzelfde project en model.
Groepeer op serviceniveau, indien van toepassing.
Richt je op uitvoertokens, die de grootste invloed op de latentie hebben.
Exporteer voor een diepgaandere analyse de activiteitsgegevens en bekijk hoe het aantal tokens per verzoek zich in de loop van de tijd ontwikkelt.
Wat je met support deelt (indien nodig)
Als je contact opneemt met support, vermeld dan:
ID's van getroffen organisaties (belangrijk)
Getroffen eindpunten, zoals Chat Completions of Responses (belangrijk)
Getroffen modellen (belangrijk)
Of dit in de Fast-modus of op het schaalniveau gebeurt (belangrijk)
Tijdsperioden met tijdzone waarin latentieproblemen of fouten optreden (belangrijk)
Relevante x-request-id of X-Client-Request-Id, indien beschikbaar
Tijdstempels met tijdzone, of ten minste de datum, voor de verzoeken die je aanlevert
Vermeld indien beschikbaar ook:
De project-ID die bij de verzoeken hoort
Of verzoeken met gegevensresidentie worden getroffen, en welke
Beschrijvingen van de trends die je ziet
Vermeld afhankelijk van het type probleem het volgende:
Fouten: Het geschatte percentage verzoeken dat mislukt of een fout oplevert, de responscodes, de foutmeldingen en hoelang het duurde voordat de foutrespons werd ontvangen.
Latentie: Welke percentielen worden getroffen (P50 / P90 / P95 / P99), hoe hoog ze zijn ten opzichte van de gebruikelijke waarden van de klant en voorbeelden van trage verzoeken met tijdstempels voor verzending en ontvangst.
Beide: Schermafbeeldingen of een tabel met fout- of latentiegegevens, plus hoe je hebt vastgesteld dat het foutpercentage of de latentie hoger was dan verwacht.
Veelvoorkomende scenario's voor probleemoplossing
Time-outs treden op, maar Service Health lijkt normaal
Mogelijke oorzaak: verzoeken verlopen met een time-out voordat ze OpenAI bereiken.
Controleer:
Time-outinstellingen van client of proxy
Wijzigingen in lokaal netwerk of load balancer
Aanwezigheid van 499-fouten in het Service Health-dashboard (deze kunnen in je eigen systemen verschijnen als 5xx-fouten).
Latentie nam toe zonder deployment
Mogelijke oorzaak: de grootte van outputtokens of het gebruik van redenering is toegenomen en/of verkeer is verschoven tussen serviceniveaus.
Controleer:
Gemiddeld aantal outputtokens per verzoek in het gebruiksdashboard (hiervoor moet je gegevens downloaden en outputtokens delen door het totale aantal verzoeken).
Percentielen voor verzoektijd en TTFT in het Service Health-dashboard.
Fast-modus of schaalniveau lijkt traag
Mogelijke oorzaak: statistieken van verschillende niveaus zijn gecombineerd, waardoor verkeer op het standaardniveau de prestaties van betaalde niveaus verhult.
Controleer het volgende:
Filters zijn beperkt tot één niveau en model.
Vergelijking van de tokensnelheid tussen niveaus.
Piek in 5XX-fouten
Waarschijnlijke oorzaak: tijdelijke storingen die een klein percentage van het verkeer beïnvloeden.
Controleer:
Foutpercentage
Of het verkeersvolume tegelijk is gewijzigd
Probleem treft slechts één project
Waarschijnlijke oorzaak: projectspecifieke configuratie of gebruikspatroon.
Controleer:
Filtering op projectniveau
Vergelijking met niet-getroffen projecten
Belangrijkste conclusies
Filter waar relevant op model, niveau en project voordat je statistieken interpreteert.
Gebruik percentielen, geen gemiddelden, voor latentieanalyse.
Kleine foutpercentages zijn te verwachten.
Ontbrekende gegevens wijzen meestal op upstream-problemen.
Gebruiksgegevens kunnen helpen verklaren waarom latentie is veranderd; Service Health laat zien wanneer gedrag is veranderd.