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.
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 u met ondersteuning moet delen (indien nodig)
Vermeld het volgende wanneer u contact opneemt met ondersteuning:
Getroffen organisatie-ID's (belangrijk)
Getroffen endpoints, zoals Chat Completions of Responses (belangrijk)
Getroffen modellen (belangrijk)
Of dit Fast-modus of schaalniveau betreft (belangrijk)
Tijdsperioden 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 u verstrekt
Vermeld indien beschikbaar ook:
Project-ID dat aan de verzoeken is gekoppeld
Of verzoeken met gegevensresidentie zijn getroffen, en welke
Beschrijvingen van de trends die u waarneemt
Vermeld per type probleem het volgende:
Fouten: Het geschatte percentage verzoeken dat mislukt of een fout oplevert, responscodes, foutmeldingen en hoelang het duurde om de foutrespons te ontvangen.
Latentie: Welke percentielen zijn getroffen (P50 / P90 / P95 / P99), hoe hoog deze zijn ten opzichte van het uitgangsniveau van de klant, en voorbeelden van trage verzoeken met tijdstempels voor verzending en ontvangst.
Beide: Schermafbeeldingen of een tabel met fout- of latentiegegevens, plus een uitleg van hoe u hebt vastgesteld dat de 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.
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.