Pular para o conteúdo principal
Use esta página quando a telemetria estiver ausente, incompleta ou ampla demais. Confira primeiro o acesso. Depois, mantenha fixos o projeto, o serviço, a versão, o ambiente e o período enquanto procura a causa.
Adicione --json em fluxos com agentes. Uma verificação com falha retorna um campo next estável.

​
Começar pelas verificações rápidas

​
Recuperar a primeira telemetria ausente

Execute estes comandos somente leitura antes de mudar a configuração do SDK:
logbrew doctor verifica o acesso à API, a autenticação, o projeto, a chave de ingestão, a configuração, a telemetria e a visibilidade dos logs. Ele não muda o projeto. Leia o status geral e cada verificação no relatório do doctor. O código de saída 0 não significa que todas as verificações passaram. O relatório também pode ter o status auth_invalid, project_missing, api_unreachable ou check_failed. O relatório do doctor mostra o próximo passo para cada um. Um projeto ready ainda pode não ter logs, porque cada tipo de sinal é separado. A verificação logs pode ser empty ou unavailable. Uma leitura de logs com falha não é um resultado vazio.

​
Enviar um sinal de teste seguro

Envie um log de teste com uma mensagem única pelo SDK instalado. Não inclua token, dados de usuário nem corpo de requisição. Anote o ID do projeto, o serviço, o ambiente, a versão implantada, o horário de início em UTC e a versão do SDK. Aguarde a entrega e depois leia um período curto no mesmo projeto. Não envie mais sinais de teste enquanto a entrega estiver pendente.

​
Encontrar logs ausentes

Leia primeiro um escopo pequeno e exato:
Confira estes itens na ordem:
  1. O ID do projeto pertence à aplicação que enviou o sinal.
  2. O serviço, a versão e o ambiente correspondem exatamente, incluindo maiúsculas, minúsculas e espaços.
  3. O período inclui o horário do sinal. O LogBrew retorna os horários dos sinais em UTC. --until é um limite superior exclusivo.
  4. Nenhum filtro de busca ou de gravidade esconde o sinal.
  5. A aplicação enviou o tipo de sinal que você está lendo. Um log não cria um problema nem um trace.
Se o sinal ainda estiver faltando, remova um filtro por vez:
  1. Mantenha o projeto e amplie o período.
  2. Remova o filtro de versão.
  3. Remova o filtro de ambiente.
  4. Remova o filtro de serviço.
  5. Remova os filtros de busca e de gravidade.
Pare quando o sinal aparecer. O último filtro que você removeu não corresponde à configuração da aplicação. Não leia todos os projetos em vez do projeto configurado. Uma página de resultados não é um total. Com --pagination cursor, continue com o next_cursor retornado e mantenha os mesmos filtros. Consulte Paginação por cursor.

​
Conferir a tela do painel

O painel mostra um snapshot de cada lista. Na tela de logs, ative Ao vivo para adicionar novos logs conforme eles chegam. As outras telas não se atualizam ao vivo. Recarregue a página para obter um novo snapshot. Um snapshot desatualizado é diferente de um resultado vazio. O LogBrew armazena só a telemetria que a aplicação envia. Remova credenciais, corpos de requisição, valores de consulta e dados pessoais antes da entrega. Use Controlar dados capturados para conferir a seleção de campos.

​
Conferir problemas e traces

Use um ID de problema ou de trace que o LogBrew retornou. Nunca invente um.
--status aceita unresolved, resolved e archived. ignored seleciona os mesmos problemas que archived. O status do problema e o status do trace são diferentes. Os valores de status do trace not_linked, not_found e unavailable têm significados diferentes. Consulte Investigar um problema para ver cada valor. Leia o problema e os logs dele antes de resolver, arquivar ou reabrir esse problema.

​
Tratar erros da CLI e da API

No modo JSON, um erro da CLI contém ok, error, message e next:
Quando a API retorna um erro, error é api_error. O erro também tem status (o status HTTP), api_code (o code da API), api_error e api_next. Em um erro rate_limited, ele também tem retry_after_seconds. A CLI não faz novas tentativas automaticamente. Consulte Erros da API para ver cada código de erro.

​
Proteger uma conta comprometida

Se outra pessoa puder ter um token de acesso da conta, um token de atualização ou um cookie de sessão, saia da conta em todos os clientes do LogBrew. Siga o procedimento de saída global da conta. Uma pessoa precisa aprovar essa ação. logbrew logout e a saída pelo navegador encerram só um cliente, então não são suficientes. A saída global da conta também encerra todas as conexões MCP aprovadas antes dela. Depois que ela der certo, apague as credenciais locais do LogBrew em cada cliente e entre de novo a partir de um cliente confiável. Aprove clientes MCP de novo só depois de confiar neles. Se a resposta se perder, não informe que todos os clientes saíram da conta e não repita a requisição automaticamente. A saída global da conta não faz a rotação das chaves de ingestão dos projetos. Se uma chave de ingestão foi exposta, faça a rotação da chave de ingestão.

​
Manter a solução de problemas segura

Use uma credencial de acesso da conta nas leituras da CLI. Use uma credencial de ingestão restrita ao projeto só para escritas do SDK. Não coloque tokens, cabeçalhos de autorização, logs brutos, dados de clientes, corpos de requisição, caminhos locais ou código-fonte em um comando, chat ou relato de suporte. Antes de fazer um relato, repita uma leitura com o menor escopo que ainda falha. Anote o comando sem os valores das credenciais, o código de erro, o ID do projeto e os valores dos filtros. Se as verificações não resolverem a falha, abra Relatar um problema.

​
Páginas relacionadas

Início rápido

Envie e leia o primeiro sinal seguro.

Guia da CLI

Use filtros exatos e saída JSON.

Investigar um problema

Leia as evidências do problema antes de mudar o status.

Erros da API

Recupere-se de cada código de erro.