Antes de debugar, tente logar - Um panorama do Log4J

Não pretendo, com este post, advogar contra o processo de depuração. Muitos erros só são resolvidos com uma boa debugada no código, não tem jeito. O objetivo aqui é incentivar a arte de logar. Logar em diversos níveis e em diversos pontos do seu projeto/sistema/API.

Você não precisa acreditar em mim. Acredite em todas as bibliotecas que você utiliza, que emitem mensagens para te auxiliar o tempo todo. Não seria bom que quem usa suas bibliotecas e/ou APIs pudessem ter a seu dispor o mesmo nível de auxílio?

Meu primeiro exemplo vem de um caso prático que passei. Estava passando por problemas no VRaptor (para quem não conhece, o VRaptor é um framework Java MVC que te auxilia magnificamente na construção de controllers, lidando muito bem com a camada Web e permitindo até a construção de serviços REST), e percebia que o debug não estava me dando as informações necessárias para resolver meu problema. Foi quando mexi no arquivo de configuração do Log4J e aumentei o nível de log do framework. Pronto! Rapidamente, as informações que precisava foram registradas no arquivo de log e eu consegui avançar e resolver o maldito bug.

Não perca tempo tentando construir seu próprio logger. Já temos muitos esforços prontos e disponíveis. Então, o ideal é não tentar reinventar a roda e utilizar um framework já pronto. No backend, tecnologia Java, o Log4J reina absoluto como o framework de log mais conhecido e utilizado. Sua performance é preparada para altos níveis de log, então não fique com medo de adicionar uma chamada ao log. Fique sim, atento, ao nível de log que você utilizará. O Log4J (e diversos outros frameworks Java) utilizam uma hierarquia de níveis para controlar quais mensagens serão adicionadas ao log. Eis os níveis e seus significados semânticos:

• OFF - indica que nenhuma mensagem de log será adicionada.
• FATAL - erros fatais em sua biblioteca ou sistema.
• ERROR - outros tipos de erros (não fatais).
• WARN - avisos sobre uso de métodos deprecated, uso errôneo da API, e outras mensagens que não indicam erro mas devem ser avisadas para o usuário da biblioteca/sistema.
• INFO - mensagens que são interessantes para o usuário, como conexões, inicializações e outras similares.
• DEBUG - neste nível devem entrar mensagens que ajudarão o usuário de sua biblioteca ou sistema a resolver algum tipo de problema que ele esteja atravessando - valores de variáveis internas, tratamento de parâmetros passados, coisas desse tipo. Você, como construtor da biblioteca, vai saber o que será importante logar nesse nível.
• TRACE - este nível deve trazer detalhes internos da biblioteca que ajudariam você a resolver algum problema. Imagine que nem sempre você poderá ter acesso ao ambiente de produção, então habilitar o log neste nível deve lhe fornecer informações detalhadas que te permitam agir.
• ALL - nível que engloba todos os outros níveis.

Esses níveis funcionam de forma cumulativa. Se você definir o nível de seu log para WARN, por exemplo, todas as mensagens com nível igual ou inferior a WARN serão incluídas, e assim por diante. Temos a seguinte comparação entre os níveis: ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF.

Quando você está construindo um sistema que vai utilizar o Log4J como ferramenta de log, você configura com um arquivo XML ou um arquivo properties; eu, particularmente, prefiro o properties e é o que vou utilizar como exemplo.

Um dos conceitos importantes ao configurar o log é o Appender. Um Appender é uma classe (que estende uma interface do Log4J) que vai entregar as mensagens de log geradas pela sua biblioteca ou sistema para o seu destino. Você pode ter diversos destinos configurados, ou seja, você irá enviar suas mensagens de log para diversos destinos: o console, um arquivo texto, um banco de dados, etc.

Um exemplo rápido de um arquivo properties de configuração do Log4J seria este:

log4j.rootLogger=DEBUG, consoleAppender, fileAppender

log4j.appender.consoleAppender=org.apache.log4j.ConsoleAppender

log4j.appender.consoleAppender.layout=org.apache.log4j.PatternLayout

log4j.appender.consoleAppender.layout.ConversionPattern=[%t] %-5p %c %x - %m%n

log4j.appender.fileAppender=org.apache.log4j.RollingFileAppender

log4j.appender.fileAppender.layout=org.apache.log4j.PatternLayout

log4j.appender.fileAppender.layout.ConversionPattern=[%t] %-5p %c %x - %m%n

log4j.appender.fileAppender.File=biblioteca_x.log

Neste exemplo, temos dois Appenders: consoleAppender e fileAppender. Ou seja, nossas mensagens de log serão enviadas para o console e para um arquivo. E o nível de log escolhido foi DEBUG (um nível alto; todas as mensagens dos níveis DEBUG, INFO, WARN, ERROR e FATAL serão incluídas). No exemplo também podemos ver o nome do arquivo de log (biblioteca_x.log), uma estratégia de rolagem dos arquivos (geralmente a estratégia é um arquivo por dia) e também o formato das mensagens - aquele formato indicado no ConversionPattern.

Beleza, muito legal tudo isso que eu falei, mas você não utiliza Java no backend. Tranquilo, o Log4J foi portado para outras tecnologias/linguagens. Temos o Log4C (para a linguagem C), Log4JS (para o Javascript, inclusive disponível no NodeJS), Log4Net (para o framwork .Net), Log4PHP (para a linguagem PHP) e muitos outros.

Este post vai ter continuação. No próximo post desta série, detalho um pouco mais o funcionamento do Log4J. Um abração e até o próximo post!!