Pular para o conteúdo principal

Logs

Log bem feito, log formoso, log bonito...

Logs são rastros ou pistas que deixamos, tanto para entendimento do que está acontecendo durante a execução de uma aplicação, quanto o que ocasionou um bug em um determinado momento.
É possível se beneficiar dos logs em várias etapas da aplicação: desenvolvimento, testes, manutenção e monitoramento.

1. Separados em níveis​

Os logs são separados em níveis de severidade e/ou importância. O Log4j que é a abstração da dependência de logger que utilizamos, possui os seguintes níveis por padrão:

  • TRACE: tipicamente mais detalhado/verboso.
  • DEBUG: para capturar detalhes de eventos relevantes que sejam úteis para resolução de problemas/bugs, mais indicado para ambientes de teste e desenvolvimento.
  • INFO: usado para registrar eventos que indicam o funcionamento normal da aplicação.
  • WARN: usado para registrar possíveis problemas na aplicação. Podem não serem críticos, porém deverão ser investigados.
  • ERROR: registrar erros inesperados que acontecem durante a operação da aplicação. Na maioria dos casos, o erro deverá ser resolvido/tratado o mais rápido possível para evitar maiores problemas ou interrupções de serviços e funcionalidades.

2. Configuráveis​

Os logs podem ser configurados para registrar a partir de um nível para cima. Sendo registrado o nível configurado e todos acima de maior severidade/importância.
Uma aplicação no ambiente de desenvolvimento deve rodar em DEBUG ou TRACE. Uma aplicação em ambiente de testes em INFO. Já uma aplicação em produção deve rodar em ERROR ou WARN.

3. Padrão escolhido​

  • FacesUtil.printAllFacesMessages(): para validações, notificando em tela;
  • Logger.error(): para produção;
  • Logger.debug(): para desenvolvimento e teste;
  • FacesUtil.addOperacaoNaoRealizada(): para notificar em tela que não foi possível realizar a operação desejada.

Exemplo:

try {
      calculoAlvaraFacade.enviarDispensaLicenciamento(cadastroEconomicoFacade.getSistemaFacade()
          .getExercicioCorrente(), selecionado);
} catch (ValidacaoException ve) {
      FacesUtil.printAllFacesMessages(ve);
} catch (Exception e) {
      logger.error("Erro ao enviar Dispensa de Licenciamento para redesim. {}", e.getMessage());
      logger.debug("Detalhes do erro ao enviar Dispensa de Licenciamento para redesim. ", e);
      FacesUtil.addOperacaoNaoRealizada("Não foi possível enviar a dispensa de licenciamento do BCM para RedeSim. Detalhes: " + e.getMessage());
}

4. Detalhes​

1. FacesUtil.printAllFacesMessages()

  • Deverá conter em cada exception de validação uma mensagem descritiva amigável ao usuário. E que o auxilie a alcançar o resultado desejado. Exemplos: indicando quais dados estão faltando, quais cadastros necessários não foi fornecido ou pelo menos a entender o porquê não é possível efetuar tal operação.

2. Logger.error()

  • Deverá possuir uma mensagem em que seja possível identificar em qual operação e em qual tela ocorreu o erro;
  • Passar a mensagem da Exception, e.getMessage(), como parâmetro para ser substituído no binding {} da mensagem;

3. Logger.debug()

  • Deverá possuir uma mensagem semelhante ao do Logger.error();
  • Passar a Exception, e, como parâmetro.

4. FacesUtil.addOperacaoNaoRealizada()

  • Por ser um erro inesperado, a mensagem será semelhante ao Logger.error() porém de tom mais voltado ao usuário.
  • A mensagem poderá ser concatenada com o e.getMessage();
  • Desta forma o usuário conseguirá entender que houve um erro inesperado e consiga passar para o suporte qual erro ocorreu, ou tirar um printscreen para maior detalhamento do chamado que será aberto para correção.