Skip to main content
Um problema agrupa ocorrências de erro que compartilham um fingerprint. Leia o resumo do grupo e uma ocorrência antes de mudar o status, a prioridade ou o responsável. Uma mudança de status, de prioridade ou de responsável registra uma decisão da equipe. Ela não conserta o software nem reescreve os eventos capturados. Instale a CLI do LogBrew e execute logbrew login antes de começar.

​
Problemas e ocorrências

Uma lista de problemas retorna um resumo do grupo, não um evento completo. Leia estes campos antes de abrir o detalhe: A contagem de ocorrências não é uma contagem de usuários afetados. As contagens e os horários valem para o escopo retornado, não para todo o histórico de erros. Um filtro --since ou --until limita as ocorrências que o LogBrew conta. Quando você informar uma contagem, informe também os filtros que a produziram.

​
Valores de status

archived se chamava ignored. Os dois nomes selecionam os mesmos problemas, e os dois são aceitos na entrada. logbrew read, logbrew issues e as versões 2 e 3 da API mostram archived. A versão 1 da API (a padrão), o fluxo de acompanhamento ao vivo e a resposta de investigação de problemas mostram ignored. O painel mostra os status como Não resolvido, Resolvido e Arquivado. O status vale para o problema inteiro, não para uma ocorrência. A gravidade mostra a urgência, e o status registra a decisão. Mantenha os dois separados. Um problema critical pode ficar resolved depois de uma correção verificada. Um problema archived mantém a gravidade capturada. O LogBrew não reabre automaticamente um problema resolvido. Quando chega uma nova ocorrência depois da resolução, a investigação informa lifecycle.effective_status como regressed. O status continua resolved até que uma pessoa reabra o problema.

​
Prioridade

A prioridade define a ordem em que a equipe faz a triagem dos problemas: Todo problema tem uma prioridade. Se ninguém a definir, ela segue a gravidade do problema: error e critical são high, warning é medium e info é low. Quando uma regra de problema muda a gravidade, a prioridade segue triage.effective_severity. Nesse caso, priority_source é derived. Quando uma pessoa define a prioridade, ela fica fixa e priority_source é manual. Para listar os problemas que devem ser examinados primeiro:

​
Atribua problemas

Atribua um problema para mostrar quem é responsável pelo próximo passo. Um problema tem 0 ou 1 responsável: uma conta ou uma equipe.
1

Descubra quem pode ser responsável

assignees traz todas as contas que podem ler o projeto, com user_id, name e email. teams traz todas as equipes da organização do projeto, com team_id, slug e name. Não é possível atribuir um problema a uma conta que não pode ler o projeto nem a uma equipe de outra organização.
2

Atribua o problema

Use me em vez de um ID de usuário para atribuir o problema a você. Use logbrew issues unassign "<issue_id>" --json para remover o responsável. Adicione --project para mudar até 100 problemas de um projeto.
3

Leia os seus problemas

Use --assignee my_teams para ver os problemas das suas equipes, --assignee "team:<team_id>" para ver os de uma equipe e --assignee none para encontrar os problemas sem responsável.
Para atribuir problemas, você precisa de permissão para gerenciar problemas no projeto. A mesma permissão permite mudar o status, a prioridade, as regras de dono e as regras de problemas e de logs. Proprietários e administradores da organização criam as equipes e escolhem os membros. Fazer parte de uma equipe não dá acesso a nenhum projeto. Quando um membro perde o acesso ao projeto, os problemas atribuídos a ele ficam sem responsável. Quando uma equipe é excluída, os problemas atribuídos a ela também ficam sem responsável. Esses problemas aparecem nas leituras com --assignee none. Se o membro recuperar o acesso, os problemas voltam a mostrar esse membro, a menos que alguém tenha mudado ou removido o responsável nesse meio-tempo.

​
Descubra o dono de um problema

O resultado lista os donos sugeridos, do mais provável ao menos provável, e um suggested_assignee. Cada dono tem um source: inputs conta os caminhos de frames da stack, os módulos, o template de rota, as tags e as regras que o LogBrew verificou. Se a lista vier vazia e inputs não mostrar caminhos, o problema não tem evidências para comparar. Isso não quer dizer que ele não tem dono. Escreva as regras de dono em um arquivo de texto, uma regra por linha:
Um padrão path corresponde ao final do caminho de um frame da stack. Assim, src/payments/** encontra frames em qualquer diretório de implantação. * corresponde a qualquer texto. Os donos são e-mails de contas ou #team-slug. A última regra que corresponde vem primeiro. Depois envie as regras, um arquivo CODEOWNERS do GitHub ou os dois:
No CODEOWNERS, um e-mail indica uma conta, e @org/team-slug indica a equipe com esse slug. Regras que citam uma conta sem acesso ao projeto ou uma equipe desconhecida falham com 422. Donos do CODEOWNERS que não correspondem a ninguém aparecem em unresolved_owners. Um arquivo vazio apaga o texto correspondente.

​
Leia o histórico do problema

O histórico lista cada mudança de status, de prioridade, de responsável e de regra de gravidade, da mais recente para a mais antiga, com a conta que fez a mudança. Ele termina com first_seen. Uma conta que perdeu o acesso ao projeto aparece só com o ID. Use --limit e os valores de next_cursor para ler mais.

​
Leia a sua caixa de entrada

A caixa de entrada lista os problemas que outras pessoas atribuíram a você ou às suas equipes, do mais recente para o mais antigo. unread conta as atribuições feitas depois da sua marca de leitura. logbrew inbox read move a marca de leitura para agora. O LogBrew não envia e-mail sobre essas atribuições. A caixa de entrada mostra só os projetos que você pode ler agora.

​
Fluxo recomendado

1

Liste os problemas não resolvidos em um escopo

Mantenha os mesmos filtros nas próximas leituras da lista. Um resultado vazio significa que nenhum problema corresponde a esse escopo. Ele não prova que o projeto não tem erros. Copie o ID exato do problema, não o título.
2

Leia o detalhe do problema

Confirme que o projeto retornado é o correto antes de continuar. As leituras retornam um snapshot. Leia o problema de novo antes de mudar o status.
3

Investigue uma ocorrência

As leituras de detalhe e de investigação não usam os filtros da lista. Compare subject.project_id, event.occurred_at, a versão e o ambiente com o seu escopo. A ocorrência recomendada pode ser mais antiga que a mais recente. Siga Investigar um problema para revisar todas as evidências.
4

Siga as evidências de trace só quando estiverem disponíveis

Leia o trace somente quando correlations.trace.status for available. Use o ID de trace da resposta. Nunca invente um.
A leitura do trace não tem filtro de tempo. Se o status for not_linked, continue com as evidências do problema.
5

Verifique a implantação candidata

Use a ocorrência investigada como referência. Pegue o ID da implantação nas evidências de implantação ou no seu processo de lançamento de versões.
A ausência de recorrência no período de observação não prova uma correção permanente. Se status for insufficient_traffic ou unavailable, mantenha o problema unresolved. Siga a próxima ação retornada.
6

Mude o status, a prioridade ou o responsável

Execute um único comando. Esses comandos não pedem confirmação, então confira o ID do problema antes.
Sem --project, cada comando recebe 1 ID de problema. Confira o código de saída e os campos status, priority e assignee retornados. Se o resultado não vier, leia o problema de novo antes da próxima mudança.Scripts mais antigos podem usar logbrew set issue "<issue_id>" resolved e os atalhos resolve, ignore e reopen. ignore define archived.

​
Mude muitos problemas de uma vez

Adicione --project para mudar até 100 problemas de um projeto com um só comando:
O comando aplica a mesma mudança a todos os problemas. Cada ID de problema pode aparecer uma única vez. A CLI rejeita mais de 100 IDs ou um ID repetido antes de enviar uma requisição. O resultado tem 1 item para cada problema, na ordem do comando: Cada item tem issue_id, outcome e issue. issue é o problema atual, ou null para not_found. Você pode executar o mesmo comando de novo depois de uma falha de rede. Os problemas que já mudaram mostram unchanged. Para mais de 100 problemas, execute mais comandos. Para um resultado not_found, copie o ID de novo de uma lista de problemas desse projeto. Veja Atualizar problemas em lote para conhecer a requisição da API.

​
Escolha o próximo status

  • Mantenha unresolved quando a falha estiver ativa ou a correção não estiver verificada. Um trace ausente não é motivo para arquivar um problema.
  • Defina resolved depois que a equipe aceitar as evidências da correção. Uma correção proposta não é evidência.
  • Defina archived para uma condição aceita ou para um sinal que só vem de testes. A decisão vale para todas as ocorrências do problema. O comando não tem campo de motivo, então anote o motivo no registro de trabalho da equipe.
  • Reabra com unresolved quando chegar uma nova ocorrência depois da resolução. lifecycle.regression.first_reappeared_occurrence identifica essa ocorrência. Compare essa ocorrência com a que foi usada na resolução. Não crie outro problema.

​
Repasse a investigação

Passe à próxima pessoa referências, não um despejo de eventos brutos:
  • ID, status, prioridade, responsável e gravidade do problema.
  • Projeto, serviço, ambiente e versão.
  • Horário da primeira ocorrência, horário da última ocorrência e contagem de ocorrências.
  • ID da ocorrência selecionada e occurrence_selection.reason.
  • fix.status, cause.status e a provenance de cada um.
  • Status e ID do trace, se estiverem disponíveis.
  • Status da reprodução e evidências ausentes.
  • Resultado da verificação da implantação candidata.
  • A próxima ação que a resposta retornou.
Marque como propostas as causas e as correções sugeridas.

​
Corrija erros da CLI

Confira o código de saída do processo antes de interpretar a saída. Em caso de sucesso, o JSON vai para a saída padrão. Um erro de análise do comando sai com o código 2. Um erro de execução sai com o código 1. Os erros em JSON vão para o erro padrão e contêm ok: false, error, message e next. Mostre next como orientação. Não execute esse comando automaticamente. Por exemplo, logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json não tem --project. O comando sai com o código 2 antes de qualquer requisição, com o erro invalid_issue_command. Quando a API rejeita uma requisição, error é api_error. Leia status para saber o status HTTP e api_code para saber o código de erro da API. Uma resposta com falha não prova que a mudança de status, de prioridade ou de responsável não teve efeito. Leia o problema antes de tentar de novo.

​
O que torna um problema útil

  • Um título claro e uma mensagem legível.
  • Um fingerprint estável.
  • Frames da pilha, quando disponíveis.
  • Contexto de versão, ambiente e serviço.
  • Contexto de trace, quando capturado com a ocorrência.
  • Atributos pequenos e relevantes, não payloads completos.
Veja a referência da API de telemetria para conhecer os filtros de lista e os contratos de resposta.