Como a CLI funciona
Use texto legível em um terminal. Use--json em scripts e agentes de
programação.
O login da conta é necessário para as leituras da conta. Antes de iniciar um
login, execute logbrew status --json. Uma pessoa precisa concluir a
autorização no navegador. As chaves de ingestão do projeto enviam telemetria.
Elas não substituem o login da conta.
A criação de projetos e de chaves, as mudanças de status, prioridade e
responsável de problemas, as implantações e as atualizações de suporte
alteram dados da conta. Antes de executar uma dessas ações, confirme que a
ação e o alvo estão corretos.
Execute logbrew --help para ver todos os comandos. Adicione --help a um
comando, como logbrew read logs --help, para ver as flags dele. Execute
logbrew help json para ver as regras de JSON.
Ler o relatório do doctor de um projeto
Use um ID de projeto delogbrew projects --json:
status, checks e next. Cada verificação tem check,
status e next. As verificações são api, auth, project,
ingest_key, setup, telemetry e logs.
O código de saída 0 significa que a CLI gravou um relatório. Ele não
significa que o projeto está pronto. Leia o status do relatório e cada
verificação. Uma verificação not_checked não passou.
Quando a leitura do projeto dá certo, a verificação
logs é visible,
empty, unavailable, error ou invalid_response. Essa verificação não
muda o status do relatório. Um resultado de logs vazio não diz nada sobre
outros sinais. Uma leitura com falha não é um resultado vazio.
Use next como orientação de recuperação. Ele não dá permissão para mudar o
estado da conta ou do projeto.
Exemplo: acesso da conta ausente
Sem credenciais da conta, o comando não faz nenhuma requisição à API. Ele grava este relatório na saída padrão e termina com o código0:
state, setup_status ou next_action.
Filtros
--since aceita uma duração, como 24h ou 7d, ou um timestamp RFC 3339.
--until aceita um timestamp RFC 3339. Ele é um horário final exclusivo e
precisa ser posterior a --since. A leitura de um problema pelo ID não
aceita --until.
A gravidade do log é info, warning, error ou critical. O status do
problema é o estado dele no fluxo de trabalho, não a gravidade.
--status ignored é um nome antigo de --status archived. --status open
significa unresolved, e --status closed significa resolved.
--assignee none seleciona problemas sem responsável, e
--assignee my_teams seleciona os problemas das suas equipes. Qualquer outro
valor de --assignee falha com invalid_assignee.
A CLI também aceita estes aliases: --project-id, --env, --service-name,
--trace-id, --distinct-id e --level para --severity. Em scripts
novos, use os nomes da tabela.
Este comando lê os erros de 1 dia:
-- antes do texto:
Selecionar uma ocorrência do problema
Um problema agrupa ocorrências correspondentes. Leia o problema para ver o status, o número de ocorrências e os horários da primeira e da última ocorrência:explain issue ou investigate issue para ver as evidências de uma
ocorrência. Sem --occurrence, o LogBrew seleciona a ocorrência recomendada.
Ela nem sempre é o evento mais recente. Para ler o evento mais recente:
--occurrence também aceita recommended, first ou um ID de ocorrência
que o LogBrew retornou. Esses comandos rejeitam filtros de projeto, versão,
ambiente e tempo. Antes de comparar evidências, leia o timestamp da
ocorrência selecionada. Consulte
Investigar um problema para ver os
campos de evidências.
Mudar o status e a prioridade de problemas
Use 1 ID de problema para mudar 1 problema:archive define archived, resolve define resolved e reopen define
unresolved. A prioridade é high, medium ou low. Uma prioridade que
você define fica fixa. Caso contrário, a prioridade acompanha a gravidade do
problema.
Para mudar mais de 1 problema, adicione --project. Todos os problemas
precisam estar nesse projeto. Um comando muda até 100 problemas:
updated,
unchanged ou not_found. Um problema unchanged já tinha o valor
solicitado. Você pode executar o mesmo comando de novo depois de uma falha de
rede.
Esses comandos não pedem confirmação. Confira antes os IDs dos problemas. As
leituras e mudanças de problemas mostram archived em vez de ignored, além
de priority, priority_source e assignee de cada problema. Consulte a
resposta de problema.
Atribuir problemas
Um problema tem 0 ou 1 responsável: uma conta ou uma equipe. Liste as contas e as equipes às quais você pode atribuir problemas em um projeto:me ou a uma equipe:
--project para mudar até 100 problemas desse projeto, como no
status e na prioridade. Uma conta precisa conseguir ler o projeto, e uma
equipe precisa ser da organização do projeto. Para encontrar os problemas
atribuídos a você ou às suas equipes:
team #<slug> para uma
equipe. Se a conta não tiver nome, ela mostra o endereço de e-mail e depois o
ID do usuário. Um problema sem responsável mostra unassigned.
Donos, histórico e caixa de entrada
issues owners lista os donos sugeridos e as evidências que verificou.
issues ownership set envia arquivos locais de no máximo 128 KiB cada. Um
arquivo vazio apaga o texto correspondente. issues activity e inbox
aceitam --limit de 1 a 200, e --cursor-time com --cursor-id a partir de
next_cursor. Veja
Descubra o dono de um problema.
Definir regras de gravidade
info, warning, error, critical ou source. source
volta a mostrar a gravidade capturada. --ignore oculta os logs
correspondentes da lista padrão de logs. Sem --ignore, a regra mostra esses
logs.
Ler a próxima página
Logs, problemas, ações, métricas e traces aceitam paginação por cursor. Versões não aceitam. Use--pagination cursor na primeira página:
logs e next_cursor. Um next_cursor não nulo tem time e
id. Envie esses valores com --cursor-time e --cursor-id:
next_cursor for null. Use o cursor, e não a contagem de linhas, para
decidir se há mais páginas. A última página pode estar vazia:
issues, actions ou
metrics no lugar de logs.
Acompanhamento ao vivo
logbrew watch --json transmite logs, problemas e ações ao vivo. Adicione
logs, issues ou actions para transmitir um único tipo. tail, follow
e stream são aliases de watch. O watch não aceita traces nem spans.
O watch precisa de --json. Sem essa flag, o comando escreve
watch streams JSON for agents e termina com o código 1.
Os eventos de problemas do watch mostram um problema arquivado como
ignored, sem prioridade. Leia o problema para ver o status e a prioridade
atuais.
O watch aceita só --severity, como --severity error,critical.
logbrew watch actions não aceita --severity. A CLI aplica esse filtro
depois de receber os eventos. Ele não reduz o que o servidor envia. O watch
não tem filtro de projeto, versão, ambiente ou tempo. Para esses filtros, use
um comando read. Depois de uma desconexão temporária, a CLI aguarda e se
reconecta.
Ler resultados e erros
Coloque--json antes ou depois do comando. Leia o código de saída antes de
usar a saída. Não faça parsing da saída legível para pessoas. Ela pode mudar
entre versões da CLI.
A saída de sucesso mantém o formato da resposta da API. Ela pode ser um array
ou um objeto. Sem paginação por cursor, uma leitura de logs retorna um array.
Um array vazio significa que nenhum log corresponde. Isso não é um erro.
Os erros vão para a saída de erro padrão. A exceção é
debug-artifacts --json, que grava os erros na saída padrão. Um erro JSON
tem ok, error, message e next. Use error como o código estável da
falha. Examine next antes de executar o comando que ele sugere.
Por exemplo, logbrew watch traces --json termina com o código 2 e
escreve:
logbrew read logs --limit 0 --json termina com o código 2 e escreve: