Eu respondo isso vindo de uma arquitetura baseada em componentes, em que uma organização pode estar executando muitos componentes que podem confiar um no outro. Durante uma falha de propagação, os níveis de log devem ajudar a identificar quais componentes são afetados e quais são as causas principais.
ERRO - Este componente teve uma falha e acredita-se que a causa seja interna (qualquer exceção interna, não tratada, falha da dependência encapsulada ... por exemplo, banco de dados, exemplo REST, seria um exemplo de erro 4xx de uma dependência). Tire-me (mantenedor deste componente) da cama.
AVISO - Este componente teve uma falha que se acredita ser causada por um componente dependente (o exemplo REST seria um status 5xx de uma dependência). Tire os mantenedores desse componente da cama.
INFO - Qualquer outra coisa que queremos chegar a um operador. Se você decidir registrar caminhos felizes, recomendo limitar a 1 mensagem de log por operação significativa (por exemplo, por solicitação http recebida).
Para todas as mensagens de log, certifique-se de registrar o contexto útil (e priorize tornar as mensagens legíveis / úteis por humanos, em vez de ter resmas de "códigos de erro")
- DEBUG (e abaixo) - Não deve ser usado (e certamente não na produção). No desenvolvimento, eu recomendaria o uso de uma combinação de TDD e Depuração (quando necessário), em vez de poluir o código com instruções de log. Na produção, o registro 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 registrar um AVISO, ele ficará laranja (âmbar) se algo registrar um ERRO, ele ficará vermelho.
No caso de um incidente, o componente (causa raiz) deve ficar vermelho e todos os componentes afetados devem ficar laranja / âmbar.