Links importantes
Painel de integridade do serviço (atualmente disponível apenas para clientes Enterprise API)
Comece com os padrões corretos
Ao abrir o painel de integridade do serviço, os padrões são:
Todos os projetos
Últimos 30 dias
Resolução horária
Essa visualização é útil apenas para orientação. Uma solução de problemas significativa sempre requer filtragem.
Filtre antes de investigar
A filtragem correta é a etapa mais importante. A maioria das interpretações equivocadas vem da mistura de modelos, níveis ou projetos.
Filtre por modelo (um por vez)
Sempre filtre para um único modelo.
Por quê:
Problemas em modelos com baixo tráfego podem ficar ocultos pelo tráfego de maior volume
Modelos de alto volume podem fazer problemas localizados parecerem globais
Modelos diferentes têm metas de desempenho diferentes
Observação: selecionar vários modelos os agrega — não alterna entre eles.
Filtre por nível de serviço
Se você usa mais de um nível (padrão, prioridade, escala), sempre filtre para o nível que está investigando.
Por quê:
Os níveis têm características de desempenho diferentes
Os níveis de prioridade e escala têm SLAs definidos
Misturar níveis obscurece o desempenho do nível pago
Isso é especialmente importante para a análise de latência.
Filtre por projeto
Por padrão, a Integridade do serviço mostra todos os projetos.
Para solucionar problemas, filtre para o(s) projeto(s) em que o problema foi observado.
Por quê:
Um único projeto de alto volume pode dominar as métricas.
Projetos menores afetados podem ser mascarados por tráfego não relacionado.
Só deixe "Todos os projetos" selecionado se acreditar que o problema realmente afeta toda a organização.
Solução de problemas de erros
Use a visualização de solicitações HTTP
Para investigar erros:
Filtre por modelo e nível de serviço.
Abra a guia Solicitações HTTP em vez da guia Uptime.
Essa visualização mostra o total de solicitações e as contagens de erros por código de status HTTP. Amplie para a resolução em nível de minuto para identificar picos ou mudanças granulares.
Interprete taxas de erro, não contagens
Alguns erros são esperados em qualquer sistema de produção. Concentre-se na porcentagem de erros, não nos totais brutos.
Quanto maior o volume total, maior o número potencial de erros, mesmo com uma taxa de erros extremamente baixa.
Quando os erros não aparecem na Integridade do serviço
Se você vir erros no lado do cliente, mas nenhum dado correspondente na Integridade do serviço:
As solicitações provavelmente não chegaram à OpenAI.
O problema geralmente está upstream (tempos limite, proxies, rede).
Isso é comum com tempos limite agressivos no lado do cliente.
Solução de problemas de latência
A análise de latência é mais significativa nos níveis prioridade e escala, que têm SLAs definidos. O nível padrão pode apresentar maior variação de latência e não tem latência garantida.
Métricas principais
Para visualizar cada métrica, clique na guia relevante:
Velocidade de tokens: tokens gerados por segundo; independente do tamanho do prompt.
Tempo da solicitação: duração total da solicitação; fortemente afetada pelo tamanho da saída e pelo raciocínio.
Tempo até o primeiro token (TTFT): tempo até o primeiro token ser gerado; fortemente afetado pelo tamanho do prompt de entrada não armazenado em cache e pelo raciocínio.
Sempre analise os percentis P50 / P75 / P95. Médias podem ocultar o impacto nos usuários reais.
6. Correlacionar latência com uso de tokens
A Integridade do serviço mostra quando o comportamento mudou. Os dados de uso ajudam a explicar por quê.
No painel de uso, faça o seguinte para garantir que você esteja vendo os dados relevantes para sua visualização no Painel de integridade do serviço:
Filtre pelo mesmo projeto e modelo.
Agrupe por nível de serviço, se aplicável.
Concentre-se nos tokens de saída, que são os que afetam mais fortemente a latência.
Para uma análise mais aprofundada, exporte os Dados de atividade e examine os tokens por solicitação ao longo do tempo.
7. O que compartilhar com o suporte (se necessário)
Se você entrar em contato com o suporte, inclua:
IDs da organização impactados (importante)
Endpoints impactados, como Chat Completions ou Responses (importante)
Modelos impactados (importante)
Se isso ocorre no nível de escala ou prioridade (importante)
Intervalos de tempo com fuso horário para latência ou erros (importante)
x-request-id ou X-Client-Request-Id relevante, se disponível
Carimbos de data/hora com fuso horário, ou pelo menos a data, para as solicitações fornecidas
Se disponível, inclua também:
ID do projeto relacionado às solicitações
Se solicitações de residência de dados são impactadas, e quais
Descrições das tendências que você está observando
Para o tipo de problema, inclua:
Erros: porcentagem aproximada de solicitações com falha ou erro, códigos de resposta, mensagens de erro e quanto tempo levou para receber a resposta de erro.
Latência: quais percentis são afetados (P50 / P90 / P95 / P99), quão altos estão em comparação com a linha de base do cliente e exemplos de solicitações lentas com carimbos de data/hora de envio e recebimento.
Ambos: capturas de tela ou uma tabela de dados de erro ou latência, além de como você determinou que as taxas de erro ou a latência estavam acima do esperado.
Cenários comuns de solução de problemas
Ocorrem tempos limite, mas a Integridade do serviço parece normal
Possível causa: as solicitações atingem o tempo limite antes de chegar à OpenAI.
Verifique:
Configurações de tempo limite do cliente ou proxy
Mudanças na rede local ou no balanceador de carga
Presença de erros 499 no painel de integridade do serviço (eles podem aparecer como erros 5xx nos seus próprios sistemas).
A latência aumentou sem uma implantação
Possível causa: o tamanho dos tokens de saída ou o uso de raciocínio aumentou e/ou o tráfego mudou entre níveis de serviço.
Verifique:
Média de tokens de saída por solicitação no painel de uso (exige baixar os dados e dividir os tokens de saída pelo total de solicitações).
Percentis de Tempo da solicitação e TTFT no painel de integridade do serviço.
O nível de prioridade ou de escala parece lento
Possível causa: as métricas estão misturadas entre níveis, o que significa que o tráfego do nível padrão está mascarando o desempenho do nível pago.
Verifique:
Os filtros estão restritos a um único nível e modelo.
Comparação da velocidade de tokens entre níveis.
Aumento súbito de erros 5XX
Causa provável: falhas transitórias que afetam uma pequena porcentagem do tráfego.
Verifique:
Porcentagem da taxa de erros
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 uso específico do projeto.
Verifique:
Filtragem no nível do projeto
Comparação com projetos não afetados
Principais conclusões
Filtre por modelo, nível e projeto quando relevante antes de interpretar métricas.
Use percentis, não médias, para a análise de latência.
Pequenas taxas de erro são esperadas.
Dados ausentes geralmente indicam problemas upstream.
Os dados de uso podem ajudar a explicar por que a latência mudou; a Integridade do serviço mostra quando o comportamento mudou.