Ligações importantes
*O Painel Service Health está atualmente disponível apenas para clientes Enterprise API.
Comece com as predefinições certas
Quando abre o painel Service Health, este assume por predefinição:
Todos os projetos
Últimos 30 dias
Resolução horária
Esta vista é útil apenas para orientação. Uma resolução de problemas eficaz exige sempre filtragem.
Filtre antes de investigar
A filtragem correta é o passo mais importante. A maioria das interpretações incorretas resulta da mistura de modelos, tiers ou projetos.
Filtrar por modelo (um de cada vez)
Filtre sempre para um único modelo.
Porquê:
Problemas em modelos com pouco tráfego podem ficar ocultos por tráfego de maior volume
Modelos de grande volume podem fazer com que problemas localizados pareçam globais
Modelos diferentes têm objetivos de desempenho diferentes
Nota: selecionar vários modelos agrega-os — não alterna entre eles.
Filtrar por tier de serviço
Se usar mais do que um tier (standard, priority, scale), filtre sempre para o tier que está a investigar.
Porquê:
Os tiers têm características de desempenho diferentes
Os tiers priority e scale têm SLAs definidos
Misturar tiers obscurece o desempenho do tier pago
Isto é especialmente importante para a análise de latência.
Filtrar por projeto
Por predefinição, o Service Health mostra todos os projetos.
Para resolução de problemas, filtre para o(s) projeto(s) onde o problema foi observado.
Porquê:
Um único projeto com grande volume pode dominar as métricas
Projetos afetados mais pequenos podem ser mascarados por tráfego não relacionado
Deixe “Todos os projetos” selecionado apenas se acreditar que o problema afeta realmente toda a organização.
Resolução de erros
Use a vista HTTP Requests
Para investigar erros:
Filtre por modelo e tier
Para mudar de Uptime para HTTP Requests, clique no separador HTTP Requests
Esta vista mostra o total de pedidos e a contagem de erros por código de estado HTTP. Aproxime até à resolução ao minuto para identificar picos ou alterações granulares.
Interprete taxas de erro, não contagens
Alguns erros são expectáveis em qualquer sistema de produção. Foque-se na percentagem de erros, não nos totais brutos.
Quanto maior for o seu volume total, maior será o número potencial de erros, mesmo com uma taxa de erro extremamente baixa.
Quando os erros não aparecem no Service Health
Se vir erros no lado do cliente mas sem dados correspondentes no Service Health:
É provável que os pedidos não tenham chegado à OpenAI
O problema costuma estar a montante (timeouts, proxies, rede)
Isto é comum com timeouts agressivos no lado do cliente.
Resolução de problemas de latência
A análise de latência é mais significativa nos tiers priority e scale, que têm SLAs definidos. O tier standard pode apresentar maior variação de latência e não tem latência garantida.
Métricas principais
Para ver cada uma destas métricas, clique no separador relevante:
Velocidade de tokens
Tokens gerados por segundo.
Independente do tamanho do prompt.
Tempo do pedido
Duração total do pedido.
Fortemente afetado pelo tamanho do output e pelo raciocínio.
Tempo até ao primeiro token (TTFT)
Tempo até o primeiro token ser gerado.
Fortemente afetado pelo tamanho do prompt de entrada não colocado em cache e pelo raciocínio.
Reveja sempre os percentis P50 / P75 / P95. As médias podem ocultar o impacto nos utilizadores reais.
6. Correlacionar a latência com a utilização de tokens
O Service Health mostra quando o comportamento mudou. Os dados de Usage ajudam a explicar porquê.
No painel Usage, faça o seguinte para garantir que está a ver os dados relevantes para a sua vista no Painel Service Health:
Filtre para o mesmo projeto, modelo
Agrupe por tier de serviço se aplicável
Foque-se nos tokens de output, que afetam mais fortemente a latência
Para uma análise mais aprofundada, exporte os Activity Data e examine os tokens por pedido ao longo do tempo.
7. O que partilhar com o suporte (se necessário)
Se contactar o suporte, inclua:
IDs da organização afetados (isto é importante)
Endpoints afetados (Chat Completions, Responses, etc.) (isto é importante)
Modelos afetados (isto é importante)
Isto é no tier scale ou priority? (isto é importante)
Intervalos de tempo com fuso horário para latência ou erro (isto é importante)
x-request-id ou X-Client-Request-Id relevantes (muitas vezes importantes; inclua se possível)
Timestamps com fuso horário (ou pelo menos a data) dos pedidos fornecidos
Latência - se partilhar exemplos de pedidos lentos, indique quanto tempo demorou do seu lado. Idealmente, inclua também os timestamps de quando o pedido foi enviado e de quando foi recebido.
Erros - partilhe a percentagem aproximada de pedidos com falha/erro, código(s) de resposta, mensagem(ns) de erro e quanto tempo demorou a receber a resposta de erro
ID do projeto relacionado com os pedidos
Isto está a afetar pedidos de residência de dados? Em caso afirmativo, quais?
Descrições das tendências que está a observar
Erros: % aproximada de pedidos com falha/erro
Latência: quais os percentis afetados (p50 / p90 / p95 / p99) e quão altos estão em comparação com o valor de referência do cliente
Ambos: capturas de ecrã ou tabela de dados de erro ou latência (Como determinou que as taxas de erro ou a latência são mais altas do que o esperado?)
Cenários comuns de resolução de problemas
Ocorrem timeouts mas o Service Health parece normal
Causa possível: os pedidos estão a expirar antes de chegarem à OpenAI.
Verifique:
Definições de timeout do cliente ou proxy
Alterações na rede local ou no balanceador de carga
Presença de erros 499 no painel Service Health (estes podem aparecer como erros 5xx nos seus próprios sistemas).
A latência aumentou sem uma implementação
Causa possível: o tamanho do token de output ou a utilização de raciocínio aumentou e\ou o tráfego mudou entre tiers de serviço
Verifique:
Média de tokens de output por pedido no painel Usage (requer descarregar dados e dividir os tokens de output pelo total de pedidos).
Percentis de Request Time e TTFT no painel Service Health.
O tier Priority ou Scale parece lento
Causa possível: as métricas estão misturadas entre tiers (ou seja, o tráfego do tier standard está a mascarar o desempenho do tier pago)
Verifique:
Os filtros estão restringidos a um único tier e modelo
Comparação da velocidade de tokens entre tiers
Pico de erros 5XX
Causa provável: falhas transitórias a afetar uma pequena percentagem do tráfego.
Verifique:
Percentagem da taxa de erro
Se o volume de tráfego mudou ao mesmo tempo
O problema afeta apenas um projeto
Causa provável: configuração ou padrão de utilização específico do projeto.
Verifique:
Filtragem ao nível do projeto
Comparação com projetos não afetados
Conclusões finais
Filtre por modelo, tier e, quando relevante, projeto antes de interpretar métricas
Use percentis, não médias, para a análise de latência
Taxas de erro pequenas são expectáveis
Dados em falta normalmente indicam problemas a montante
Os dados de Usage podem ajudar a explicar porquê a latência mudou; o Service Health ajuda a mostrar quando