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 je meer dan één niveau gebruikt (standaard, prioriteit, schaal), filter dan altijd op het niveau dat je onderzoekt.
Waarom:
Niveaus hebben verschillende prestatiekenmerken
Voor prioriteits- en schaalniveaus gelden gedefinieerde SLA's
Door niveaus te mengen worden prestaties van betaalde niveaus minder zichtbaar
Dit is vooral belangrijk voor latentieanalyse.
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.
Problemen met latentie oplossen
Latentieanalyse is het zinvolst op prioriteitsniveau en schaalniveau, waarvoor gedefinieerde SLA's gelden. Het standaardniveau kan meer latentievariatie vertonen en heeft 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.
6. Latentie correleren met tokengebruik
Service Health laat zien wanneer gedrag is veranderd. Gebruiksgegevens helpen verklaren waarom.
Doe in het gebruiksdashboard het volgende om ervoor te zorgen dat je kijkt naar de gegevens die relevant zijn voor je weergave in het Service Health-dashboard:
Filter op hetzelfde project en model.
Groepeer op serviceniveau, indien van toepassing.
Richt je op outputtokens, die de latentie het sterkst beïnvloeden.
Exporteer voor een diepere analyse activiteitsgegevens en onderzoek tokens per verzoek in de tijd.
7. Wat je met support deelt (indien nodig)
Als je contact opneemt met support, vermeld dan:
Getroffen organisatie-id's (belangrijk)
Getroffen endpoints, zoals Chat Completions of Responses (belangrijk)
Getroffen modellen (belangrijk)
Of dit op schaal- of prioriteitsniveau is (belangrijk)
Tijdbereiken met tijdzone voor latentie of fouten (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 verstrekt
Voeg, indien beschikbaar, ook toe:
Project-ID met betrekking tot de verzoeken
Of verzoeken voor gegevensresidentie zijn getroffen, en welke
Beschrijvingen van de trends die je ziet
Vermeld voor het type probleem:
Fouten: geschat percentage mislukte verzoeken of verzoeken met fouten, responscodes, foutmeldingen en hoe lang het duurde om de foutrespons te ontvangen.
Latentie: welke percentielen zijn getroffen (P50 / P90 / P95 / P99), hoe hoog ze zijn vergeleken met de baseline van de klant, en voorbeelden van trage verzoeken met tijdstempels voor verzenden en ontvangen.
Beide: screenshots of een tabel met fout- of latentiegegevens, plus hoe je hebt bepaald dat foutpercentages of latentie hoger waren 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.
Prioriteits- of schaalniveau lijkt traag
Mogelijke oorzaak: statistieken zijn gemengd tussen niveaus, waardoor verkeer op standaardniveau de prestaties van betaalde niveaus maskeert.
Controleer:
Filters zijn beperkt tot één niveau en model.
Vergelijking van 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.