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.
Filtrare per Livello di servizio
Se utilizzi più livelli (standard, Modalità rapida, precedentemente Elaborazione prioritaria, e Scale Tier), filtra sempre in base al livello che stai esaminando.
Perché:
I livelli hanno caratteristiche prestazionali diverse
La Modalità rapida e Scale Tier prevedono SLA definiti
L'aggregazione dei livelli nasconde le prestazioni dei livelli a pagamento
Questo è particolarmente importante per l'analisi della latenza.
Per i modelli esistenti, il traffico della Modalità rapida è ancora indicato come prioritario nella dashboard Utilizzo.
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 per i livelli Modalità rapida e Scale Tier, che prevedono SLA definiti. Il livello standard può presentare una maggiore variabilità della latenza e non offre garanzie in merito.
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.
Correlare la latenza con l’utilizzo dei token
La dashboard Stato del servizio mostra quando è cambiato il comportamento. I dati di utilizzo aiutano a capire perché.
Nella dashboard Utilizzo, segui questi passaggi per assicurarti di consultare i dati corrispondenti alla vista selezionata nella dashboard Stato del servizio:
Filtra per lo stesso progetto e modello.
Raggruppa per Livello di servizio, se applicabile.
Concentrati sui token di output, che incidono maggiormente sulla latenza.
Per un’analisi più approfondita, esporta i dati delle attività ed esamina l’andamento dei token per richiesta nel tempo.
Cosa condividere con l’assistenza (se necessario)
Se contatti l’assistenza, includi:
Gli ID delle organizzazioni interessate (importante)
Gli endpoint interessati, come Chat Completions o Responses (importante)
I modelli interessati (importante)
Se il problema si verifica in Modalità rapida o con Scale Tier (importante)
Gli intervalli di tempo in cui si verificano latenza o errori, con il fuso orario (importante)
I valori x-request-id o X-Client-Request-Id pertinenti, se disponibili
I timestamp con il fuso orario, o almeno la data, delle richieste che fornisci
Se disponibili, includi anche:
L’ID del progetto associato alle richieste
Se il problema riguarda richieste soggette a requisiti di residenza dei dati e, in tal caso, quali
Una descrizione delle tendenze che osservi
In base al tipo di problema, includi:
Errori: la percentuale approssimativa di richieste non riuscite o che restituiscono un errore, i codici di risposta, i messaggi di errore e il tempo trascorso prima di ricevere la risposta di errore.
Latenza: quali percentili sono interessati (P50 / P90 / P95 / P99), di quanto superano i valori di riferimento del cliente ed esempi di richieste lente con i timestamp di invio e ricezione.
Entrambi: screenshot o una tabella con i dati relativi agli errori o alla latenza, oltre al metodo usato per stabilire che i tassi di errore o la latenza erano superiori alle attese.
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.
La Modalità rapida o Scale Tier sembra lenta
Possibile causa: le metriche aggregano livelli diversi, quindi il traffico del livello standard nasconde le prestazioni dei livelli a pagamento.
Verifica:
I filtri sono limitati a un singolo livello e modello.
Confronto della velocità dei token tra i 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.