Link importanti
*La Dashboard Service Health è attualmente disponibile solo per i clienti Enterprise API.
Inizia con le impostazioni predefinite corrette
Quando apri la dashboard Service Health, per impostazione predefinita mostra:
Tutti i progetti
Ultimi 30 giorni
Risoluzione oraria
Questa vista è utile solo per orientarsi. Per una risoluzione significativa dei problemi è sempre necessario filtrare.
Filtra prima di analizzare
Il filtraggio corretto è il passaggio più importante. La maggior parte delle interpretazioni errate deriva dal mescolare modelli, tier o progetti.
Filtra per modello (uno alla volta)
Filtra sempre su un solo modello.
Perché:
I problemi sui modelli con poco traffico possono essere nascosti dal traffico di volume superiore
I modelli ad alto volume possono far sembrare globali problemi localizzati
Modelli diversi hanno obiettivi di prestazione diversi
Nota: selezionare più modelli li aggrega, non consente di passare dall’uno all’altro.
Filtra per tier di servizio
Se utilizzi più di un tier (standard, priority, scale), filtra sempre sul tier che stai analizzando.
Perché:
I tier hanno caratteristiche prestazionali diverse
I tier priority e scale hanno SLA definiti
Mescolare i tier oscura le prestazioni dei tier 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 sul/i progetto/i in cui è stato osservato il problema.
Perché:
Un singolo progetto ad alto volume può dominare le metriche
I progetti interessati più piccoli possono essere mascherati da traffico non correlato
Lascia selezionato "Tutti i progetti" solo se ritieni che il problema riguardi davvero tutta l’organizzazione.
Risoluzione degli errori
Usa la vista Richieste HTTP
Per analizzare gli errori:
Filtra per modello e tier
Per passare da Uptime a Richieste HTTP, fai clic sulla scheda Richieste HTTP
Questa vista mostra il totale delle richieste e il numero di errori per codice di stato HTTP. Esegui lo zoom fino alla risoluzione al minuto per identificare picchi o cambiamenti granulari.
Interpreta i tassi di errore, non i conteggi
Alcuni errori sono attesi in qualsiasi sistema di produzione. Concentrati sulla percentuale di errori, non sui totali grezzi.
Maggiore è il volume totale, maggiore è il potenziale numero di errori anche con un tasso di errore estremamente basso.
Quando gli errori mancano in Service Health
Se vedi errori lato client ma nessun dato corrispondente in Service Health:
È probabile che le richieste non abbiano raggiunto OpenAI
Il problema di solito è a monte (timeout, proxy, rete)
Questo è comune con timeout lato client aggressivi.
Risoluzione dei problemi di latenza
L’analisi della latenza è più significativa nei tier priority e scale, che hanno SLA definiti. Il tier standard può mostrare una variazione di latenza più ampia e non ha latenza garantita.
Metriche chiave
Per visualizzare ciascuna di queste metriche, fai clic sulla scheda pertinente:
Velocità dei token
Token generati al secondo.
Indipendente dalla dimensione del prompt.
Tempo di richiesta
Durata totale della richiesta.
Fortemente influenzato dalla dimensione dell’output e dal ragionamento.
Tempo al primo token (TTFT)
Tempo fino alla generazione del primo token.
Fortemente influenzato dalla dimensione del prompt di input non in cache e dal ragionamento.
Controlla sempre i percentili P50 / P75 / P95. Le medie possono nascondere l’impatto sugli utenti reali.
6. Correlare la latenza con l’utilizzo dei token
Service Health mostra quando il comportamento è cambiato. I dati di utilizzo aiutano a spiegare perché.
Nella dashboard Usage, esegui quanto segue per assicurarti di guardare i dati pertinenti alla tua vista nella Dashboard Service Health:
Filtra sullo stesso progetto, modello
Raggruppa per tier di servizio se applicabile
Concentrati sui token di output, che influiscono maggiormente sulla latenza
Per un’analisi più approfondita, esporta Activity Data ed esamina i token per richiesta nel tempo.
7. Cosa condividere con il supporto (se necessario)
Se contatti il supporto, includi:
ID org interessati (importante)
Endpoint interessati (Chat Completions, Responses, ecc.) (importante)
Modelli interessati (importante)
È sul tier scale o priority? (importante)
Intervalli di tempo con fuso orario per latenza o errore (importante)
x-request-id o X-Client-Request-Id pertinenti (spesso importanti; includili se possibile)
Timestamp con fuso orario (o almeno la data) delle richieste fornite
Latenza - se condividi esempi di richieste lente, indica quanto tempo ha richiesto dal tuo lato. Idealmente includi anche i timestamp di invio e ricezione della richiesta.
Errori - condividi la percentuale approssimativa di richieste non riuscite/in errore, i codici di risposta, i messaggi di errore e quanto tempo è servito per ricevere la risposta di errore
ID progetto relativo alle richieste
Questo sta influendo sulle richieste di residenza dei dati? Se sì, quali?
Descrizioni delle tendenze che stai osservando
Errori: % approssimativa di richieste non riuscite/in errore
Latenza: quali percentili sono interessati (p50 / p90 / p95 / p99) e quanto sono alti rispetto al valore di riferimento del cliente
Entrambi: screenshot o tabella dei dati di errore o latenza (Come hai determinato che i tassi di errore o la latenza sono 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 load balancer
Presenza di errori 499 nella dashboard Service Health (potrebbero apparire come errori 5xx nei tuoi sistemi).
La latenza è aumentata senza un deployment
Possibile causa: sono aumentati la dimensione dei token di output o l’uso del ragionamento e\or il traffico si è spostato tra i tier di servizio
Controlla:
Token di output medi per richiesta nella dashboard Usage (richiede il download dei dati e la divisione dei token di output per il totale delle richieste).
Percentili di Tempo di richiesta e TTFT nella dashboard Service Health.
Il tier Priority o Scale sembra lento
Possibile causa: le metriche sono mescolate tra i tier (ossia il traffico del tier standard maschera le prestazioni dei tier a pagamento)
Controlla:
I filtri sono limitati a un solo tier e modello
Confronto della velocità dei token tra i tier
Picco di errori 5XX
Causa probabile: errori transitori che interessano una piccola percentuale di 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:
Filtraggio a livello di progetto
Confronto con progetti non interessati
Punti chiave finali
Filtra per modello, tier e, dove pertinente, progetto prima di interpretare le metriche
Usa i percentili, non le medie, per l’analisi della latenza
Tassi di errore bassi sono attesi
I dati mancanti di solito indicano problemi a monte
I dati di utilizzo possono aiutare a spiegare perché la latenza è cambiata; Service Health aiuta a mostrare quando