Níveis de registro - Logback - regra geral para atribuir níveis de log

Eu principalmente construo sistemas de grande escala e alta disponibilidade, então minha resposta é inclinada a olhar para ele do ponto de vista do suporte à produção; Dito isto, atribuímos aproximadamente da seguinte forma:

• erro : o sistema está em perigo, os clientes provavelmente estão sendo afetados (ou logo estarão) e a correção provavelmente requer intervenção humana. A regra "2AM" se aplica aqui - se você está de plantão, você quer ser acordado às 2 da manhã se esta condição acontecer? Se sim, registre-o como "erro".

• avisar : ocorreu um evento técnico ou de negócio inesperado, os clientes podem ser afetados, mas provavelmente nenhuma intervenção humana imediata é necessária. As pessoas de plantão não serão chamadas imediatamente, mas a equipe de suporte vai querer rever essas questões o mais rápido possível para entender qual é o impacto. Basicamente, qualquer problema que precise ser rastreado, mas não requer intervenção imediata.

• info : coisas que queremos ver em alto volume, caso precisemos analisar forensemente um problema. Os eventos do ciclo de vida do sistema (início do sistema, parada) vão para aqui. Os eventos do ciclo de vida da "sessão" (login, logout, etc.) vão para aqui. Eventos de limite significativos também devem ser considerados (por exemplo, chamadas de banco de dados, chamadas de API remotas). Exceções comerciais típicas podem ser exibidas aqui (por exemplo, o login falhou devido a credenciais incorretas). Qualquer outro evento que você ache que precisará ver em produção em alto volume será exibido aqui.

• debug : praticamente tudo o que não faz o "info" cortar ... qualquer mensagem que seja útil para rastrear o fluxo através do sistema e isolar questões, especialmente durante as fases de desenvolvimento e QA. Usamos logs de nível "debug" para entrada/saída da maioria dos métodos não-triviais e marcamos eventos e pontos de decisão dentro dos métodos.

• trace : nós não usamos isso com freqüência, mas isso seria para logs extremamente detalhados e potencialmente de alto volume que você normalmente não quer habilitado mesmo durante desenvolvimento normal. Exemplos incluem descarregar uma hierarquia de objetos completa, registrando algum estado durante cada iteração de um loop grande, etc.

Tão ou mais importante do que escolher os níveis de log certos é garantir que os logs sejam significativos e tenham o contexto necessário. Por exemplo, você quase sempre deseja incluir o ID do encadeamento nos registros para poder seguir um único encadeamento, se necessário. Você também pode querer empregar um mecanismo para associar informações corporativas (por exemplo, ID de usuário) ao encadeamento para que ele também seja registrado. Em sua mensagem de log, você deve incluir informações suficientes para garantir que a mensagem possa ser acionada. Um log como "exceção FileNotFound detectada" não é muito útil. Uma mensagem melhor é "Exceção FileNotFound capturada ao tentar abrir o arquivo de configuração: /usr/local/app/somefile.txt. UserId = 12344."

Há também um bom número de guias de log por aí ... por exemplo, aqui está um trecho editado de JCL (Jakarta Commons Logging) :

• erro - Outros erros de tempo de execução ou condições inesperadas. Espere que estes sejam imediatamente visíveis em um console de status.
• warn - Uso de APIs descontinuadas, mau uso da API, 'quase' erros, outras situações de tempo de execução que são indesejáveis ​​ou inesperadas, mas não necessariamente "erradas". Espere que estes sejam imediatamente visíveis em um console de status.
• info - Eventos de tempo de execução interessantes (inicialização/desligamento). Espere que estes sejam imediatamente visíveis em um console, por isso seja conservador e mantenha o mínimo.
• debug - informações detalhadas sobre o fluxo através do sistema. Espere que estes sejam gravados em logs somente.
• trace - informações mais detalhadas. Espere que estes sejam gravados em logs somente.

Minha abordagem, eu acho que vem mais de um desenvolvimento do que um ponto de vista de operações, é:

• Erro significa que a execução de alguma tarefa não pôde ser concluída; um e-mail não pôde ser enviado, uma página não pôde ser renderizada, alguns dados não puderam ser armazenados em um banco de dados, algo assim. Algo definitivamente deu errado.
• Aviso significa que algo inesperado aconteceu, mas que a execução pode continuar, talvez em um modo degradado; um arquivo de configuração estava faltando, mas padrões foram usados, um preço foi calculado como negativo, então ele foi clicado para zero, etc. Algo não está certo, mas ainda não foi erradamente correto - os avisos são freqüentemente um sinal de que haverá um erro muito em breve.
• Info significa que algo normal, mas significativo aconteceu; o sistema foi iniciado, o sistema foi interrompido, o trabalho de atualização do inventário foi executado, etc. Não deve haver uma torrente contínua deles, caso contrário, há muito para ler.
• Debug significa que algo normal e insignificante aconteceu; um novo usuário chegou ao site, uma página foi processada, um pedido foi feito, um preço foi atualizado. Este é o material excluído da informação porque haveria muito disso.
• Trace é algo que eu nunca usei.

Isso também pode ajudar tangencialmente, para entender se um log pedido (a partir do código) em um determinado nível resultará na verdade sendo registrado dado o efetivo nível de log em que uma implantação está configurada. Decida qual nível efetivo do qual você deseja configurar sua implantação a partir das outras respostas aqui e, em seguida, consulte isso para ver se um registro específico pedido do seu código será realmente registrado então ...

Para exemplos :

• "Será que uma linha de código de registro que registra em WARN realmente registra minha implementação configurada com ERROR?" A mesa diz: NÃO.
• "Será que uma linha de código de log que registra em WARN realmente é registrada em minha implantação configurada com DEBUG?" A mesa diz: SIM.

de documentação de log-in:

De uma maneira mais gráfica, aqui está como a regra de seleção funciona. Na tabela a seguir, o cabeçalho vertical mostra o nível do pedido de registro, designado por p, enquanto o cabeçalho horizontal mostra o nível efetivo do registrador, designado por q. A interseção das linhas (solicitação de nível) e colunas (nível efetivo) é o booleano resultante da regra de seleção básica.

Portanto, uma linha de código que solicita o registro só será realmente registrada se o nível de log efetivo de sua implantação for menor ou igual a essa linha de código nível de gravidade solicitado .

Eu respondo a isso vindo de uma arquitetura baseada em componentes, onde uma organização pode estar executando muitos componentes que podem confiar uns nos outros. Durante uma falha de propagação, os níveis de log devem ajudar a identificar quais componentes são afetados e quais são a causa raiz.

• ERROR - Este componente teve uma falha e acredita-se que a causa seja interna (qualquer exceção interna, não tratada, falha de dependência encapsulada ... por exemplo, banco de dados, REST example seria ele recebeu um erro 4xx de uma dependência). Leve-me (mantenedor deste componente) para fora da cama.

• WARN - Este componente teve uma falha que acredita-se ser causada por um componente dependente (o exemplo REST seria um status 5xx de uma dependência). Receba os mantenedores do componente fora da cama.

• INFO - Qualquer outra coisa que queremos obter para um operador. Se você decidir registrar caminhos felizes, recomendamos limitar a 1 mensagem de log por operação significativa (por exemplo, por solicitação HTTP de entrada).

Para todas as mensagens de log, certifique-se de registrar o contexto útil (e priorizar a criação de mensagens legíveis/úteis em vez de ter resmas de "códigos de erro")

• DEBUG (e abaixo) - Não deve ser usado (e certamente não está em produção). Em desenvolvimento eu aconselharia o uso de uma combinação de TDD e Depuração (quando necessário), em oposição a poluir o código com instruções de log. Na produção, o log INFO acima, combinado com outras métricas, deve ser suficiente.

Uma boa maneira de visualizar os níveis de registro acima é imaginar um conjunto de telas de monitoramento para cada componente. Quando tudo estiver funcionando bem, eles são verdes, se um componente registra um AVISO, ele ficará laranja (âmbar) se algo registrar um ERRO, então ele ficará vermelho.

No caso de um incidente, você deve ter um componente (causa raiz) vermelho e todos os componentes afetados devem ficar laranja/âmbar.

Não é diferente para outras respostas, meu framework tem quase os mesmos níveis:

1. Erro: erros lógicos críticos no aplicativo, como um tempo limite de conexão do banco de dados. Coisas que exigem correção de bugs no futuro próximo
2. Avisar: problemas não violentos, mas coisas para se prestar atenção. Como uma página solicitada não encontrada
3. Info: usado na primeira linha de funções/métodos, para mostrar um procedimento que foi chamado ou uma etapa passada ok, como uma consulta de inserção feita
4. log: informações lógicas, como resultado de uma instrução if
5. debug: conteúdo variável relevante para ser visto permanentemente