Link importanti
Dashboard Service Health (attualmente disponibile solo per i clienti API Enterprise)
Inizia con le impostazioni predefinite corrette
Quando apri il dashboard Service Health, le impostazioni predefinite sono:
Tutti i progetti
Ultimi 30 giorni
Risoluzione oraria
Questa vista è utile solo per orientarsi. Una risoluzione dei problemi significativa richiede sempre l’applicazione di filtri.
Filtra prima di indagare
Il filtro corretto è il passaggio più importante. La maggior parte delle interpretazioni errate deriva dalla combinazione di modelli, livelli o progetti.
Filtra per modello (uno alla volta)
Filtra sempre su un singolo modello.
Perché:
I problemi sui modelli a basso traffico possono essere nascosti dal traffico a volume più elevato
I modelli ad alto volume possono far sembrare globali i problemi localizzati
Modelli diversi hanno obiettivi di prestazioni diversi
Nota: selezionare più modelli li aggrega; non passa dall’uno all’altro.
Filtra per livello di servizio
Se usi più di un livello (standard, Priority, Scale), filtra sempre in base al livello che stai indagando.
Perché:
I livelli hanno caratteristiche di prestazioni diverse
I livelli Priority e Scale hanno SLA definiti
Mescolare i livelli oscura le prestazioni del livello a pagamento
Questo è particolarmente importante per l’analisi della latenza.
Filtra per progetto
Per impostazione predefinita, Service Health mostra tutti i progetti.
Per la risoluzione dei problemi, filtra in base ai progetti in cui è stato osservato il problema.
Perché:
Un singolo progetto ad alto volume può dominare le metriche.
I progetti più piccoli interessati possono essere mascherati da traffico non correlato.
Lascia selezionato "Tutti i progetti" solo se ritieni che il problema riguardi davvero l’intera organizzazione.
Risoluzione degli errori
Usa la vista Richieste HTTP
Per indagare sugli errori:
Filtra per modello e livello di servizio.
Apri la scheda Richieste HTTP invece della scheda Tempo di attività.
Questa vista mostra le richieste totali e il numero di errori per codice di stato HTTP. Ingrandisci fino alla risoluzione al minuto per identificare picchi o cambiamenti granulari.
Interpreta i tassi di errore, non i conteggi
Alcuni errori sono previsti in qualsiasi sistema di produzione. Concentrati sulla percentuale di errori, non sui totali grezzi.
Maggiore è il volume totale, maggiore è il numero potenziale di errori anche con un tasso di errore estremamente basso.
Quando gli errori mancano da Service Health
Se vedi errori lato client ma nessun dato corrispondente in Service Health:
Le richieste probabilmente non hanno raggiunto OpenAI.
Il problema è di solito a monte (timeout, proxy, rete).
Questo è comune con timeout aggressivi lato client.
Risoluzione dei problemi di latenza
L’analisi della latenza è più significativa nei livelli Priority e Scale, che hanno SLA definiti. Il livello standard può mostrare una variazione di latenza più ampia e non ha latenza garantita.
Metriche chiave
Per visualizzare ciascuna metrica, fai clic sulla scheda pertinente:
Velocità dei token: token generati al secondo; indipendente dalle dimensioni del prompt.
Tempo della richiesta: durata totale della richiesta; fortemente influenzata dalle dimensioni dell’output e dal ragionamento.
Tempo al primo token (TTFT): tempo fino alla generazione del primo token; fortemente influenzato dalle dimensioni del prompt di input non memorizzato nella cache e dal ragionamento.
Esamina sempre i percentili P50 / P75 / P95. Le medie possono nascondere l’impatto sugli utenti reali.
6. Correlare la latenza con l’uso dei token
Service Health mostra quando è cambiato il comportamento. I dati di utilizzo aiutano a spiegare il perché.
Nel dashboard Usage, esegui le seguenti operazioni per assicurarti di visualizzare i dati pertinenti alla tua vista nel dashboard Service Health:
Filtra sullo stesso progetto e modello.
Raggruppa per livello di servizio, se applicabile.
Concentrati sui token di output, che influenzano maggiormente la latenza.
Per un’analisi più approfondita, esporta i dati attività ed esamina i token per richiesta nel tempo.
7. Cosa condividere con il supporto (se necessario)
Se contatti il supporto, includi:
ID delle organizzazioni interessate (importante)
Endpoint interessati, come Chat Completions o Responses (importante)
Modelli interessati (importante)
Se si tratta del livello Scale o Priority (importante)
Intervalli di tempo con fuso orario per latenza o errori (importante)
x-request-id o X-Client-Request-Id pertinenti, se disponibili
Timestamp con fuso orario, o almeno la data, per le richieste che fornisci
Se disponibili, includi anche:
ID progetto relativo alle richieste
Se le richieste di residenza dei dati sono interessate, e quali
Descrizioni delle tendenze che stai osservando
Per il tipo di problema, includi:
Errori: percentuale approssimativa di richieste non riuscite o con errore, codici di risposta, messaggi di errore e tempo necessario per ricevere la risposta di errore.
Latenza: quali percentili sono interessati (P50 / P90 / P95 / P99), quanto sono elevati rispetto al baseline del cliente ed esempi di richieste lente con timestamp di invio e ricezione.
Entrambi: screenshot o una tabella di dati su errori o latenza, più il modo in cui hai determinato che i tassi di errore o la latenza erano più alti del previsto.
Scenari comuni di risoluzione dei problemi
Si verificano timeout ma Service Health sembra normale
Possibile causa: le richieste vanno in timeout prima di raggiungere OpenAI.
Controlla:
Impostazioni di timeout del client o del proxy
Modifiche alla rete locale o al bilanciatore del carico
Presenza di errori 499 nel dashboard Service Health (nei tuoi sistemi possono apparire come errori 5xx).
La latenza è aumentata senza una distribuzione
Possibile causa: le dimensioni dei token di output o l’uso del ragionamento sono aumentati e/o il traffico si è spostato tra livelli di servizio.
Controlla:
Token di output medi per richiesta nel dashboard Usage (richiede di scaricare i dati e dividere i token di output per il totale delle richieste).
Percentili di Request Time e TTFT nel dashboard Service Health.
Il livello Priority o Scale Tier appare lento
Possibile causa: le metriche sono mescolate tra livelli, quindi il traffico del livello standard maschera le prestazioni del livello a pagamento.
Controlla:
I filtri sono limitati a un singolo livello e modello.
Confronto della velocità dei token tra livelli.
Picco di errori 5XX
Causa probabile: errori temporanei che interessano una piccola percentuale del traffico.
Controlla:
Percentuale del tasso di errore
Se il volume di traffico è cambiato nello stesso momento
Il problema interessa un solo progetto
Causa probabile: configurazione o modello di utilizzo specifico del progetto.
Controlla:
Filtro a livello di progetto
Confronto con progetti non interessati
Conclusioni finali
Filtra per modello, livello e progetto, ove pertinente, prima di interpretare le metriche.
Usa i percentili, non le medie, per l’analisi della latenza.
Sono attesi piccoli tassi di errore.
I dati mancanti di solito indicano problemi a monte.
I dati di utilizzo possono aiutare a spiegare il perché la latenza è cambiata; Service Health mostra quando è cambiato il comportamento.