Frameworks de Logging
Primeiros passos com Commons Logging e Log4j
Aprenda a usar as bibliotecas de logging mais populares do mercado e como elas podem facilitar a vida dos administradores de redes e do desenvolvedor de aplicações
O uso de logging é considerado obrigatório hoje em aplicações corporativas. Sem ele, os administradores de rede e outros profissionais responsáveis pela manutenção do ambiente de produção ficam “cegos” quando ocorrem problemas de performance e de segurança, ou simples bugs nas aplicações. São os logs do sistema operacional, servidores de aplicações, frameworks, e do código de negócio em si que fornecem as principais informações necessárias para a identificação de problemas e suas soluções.
Mas não são apenas os administradores e técnicos de suporte que se beneficiam de aplicações desenvolvidas com atenção à geração de logs. Os desenvolvedores também ganham muito, especialmente em ambientes multithreaded como containers web e EJB, em que a eficácia de depuradores é limitada pela incapacidade de um único desenvolvedor simular eventos concorrentes. Na verdade, alguns desenvolvedores mais experientes chegam até a considerar que os depuradores são dispensáveis, se houver uma boa infra-estrutura de logging.
A partir da versão 1.4, o próprio JSE passou a incluir uma API de logging. Mas o mercado Java em geral acabou adotando duas bibliotecas livres para logging: o Jakarta Commons Logging e o log4j, ambos da Apache. O quadro “Log4j x Java SE Logging API” apresenta uma comparação entre os recursos dessas duas APIs, explicando os motivos da preferência do mercado pela solução livre no lugar da oficial.
Neste artigo são apresentados os fundamentos do logging, incluindo boas práticas de como usá-lo dentro de aplicações e bibliotecas. São vistos também a configuração e a utilização das bibliotecas Log4j e Commons Logging.
Conceitos de logging
Um log, em termos gerais, é um registro de acontecimentos ou de atividades. Em se tratando de computadores, um log é um registro gerado por um serviço ou aplicativo específico (às vezes pelo próprio sistema operacional) e que tem vários usos, por exemplo:
l Havendo suspeita de acesso indevido aos dados, um log de acessos pode ser consultado para verificar que usuários estiveram ativos e quais arquivos foram acessados durante o período em que teria ocorrido um incidente.
l Se um usuário reclama que não consegue abrir uma dada página de um website, o administrador pode verificar no log do servidor ou container se aparece alguma mensagem de erro, por exemplo indicando a indisponibilidade do banco de dados.
l Quando um servidor de rede não inicia, o seu log pode ser consultado para verificar em que momento da inicialização o processo foi abortado, indicando assim a localização de um possível erro de configuração.
l Se um servidor web gera um log com todos os acessos a página, este log pode ser processado para gerar uma relação das páginas mais visitadas dentro do site.
Essas situações sugerem que um log deva ser algo permanente, salvo em um arquivo ou banco de dados, e que será arquivado para consulta no futuro. Eis um exemplo típico de arquivo de log, no caso um trecho do arquivo catalina.out gerado pelo Tomcat em sua instalação padrão:
13/03/2006 14:35:08 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
13/03/2006 14:35:08 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1312 ms
13/03/2006 14:35:09 org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
13/03/2006 14:35:09 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5.9
13/03/2006 14:35:09 org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
13/03/2006 14:35:13 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
13/03/2006 14:35:13 org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
13/03/2006 14:35:13 org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/36 config=null
13/03/2006 14:35:13 org.apache.catalina.storeconfig.StoreLoader load
INFO: Find registry server-registry.xml at classpath resource
13/03/2006 14:35:13 org.apache.catalina.startup.Catalina start
INFO: Server startup in 4845 ms
Observe neste trecho a ordem de inicialização dos componentes internos do Tomcat, e em que momento ele passou a aceitar conexões TCP, em quais portas. Um bom log é criado pressupondo que seu leitor tem conhecimento interno sobre a arquitetura do software que o gerou. Ele fornece informações para profissionais de informática, não para o usuário final.
Pode-se observar pelo exemplo que um arquivo de log, mesmo quando armazenado como um arquivo texto puro, segue uma estrutura bem-definida[1]. No exemplo, cada duas linhas formam um registro de log. A primeira linha contém a data e hora em que o registro foi gerado, e a segunda contém um indicador de severidade (também chamado de nível de log), além de um texto específico ao registro: a mensagem de log.
As mensagens de log devem conter informações sobre eventos normais da aplicação[2], como início e término, acesso por um usuário regular ou erros de senha, e também sobre eventos inesperados, como erros de conexão de rede, falta de memória e exceções Java.
Chama-se de logging à atividade de geração registros de log. E de “framework de logging” (logging framework) à biblioteca ou o componente utilizado por uma aplicação para a realização dessa atividade.
A importância do logging
Muitos tipos de problemas podem não se manifestar em um ambiente de testes mais controlado. Então a geração de logs deve ser parte da aplicação no ambiente de produção, e não apenas de uma versão especial para testes. É importante notar que a necessidade de se gerar logs a partir da aplicação não é eliminada nem compensada pelo uso de outras ferramentas de desenvolvimento (como depuradores passo-a-passo e testes de unidade) – nem pelo uso de ferramentas para monitoração do ambiente, como medidores de performance.
Por outro lado, a geração constante de logs muito detalhados pode ter impacto significativo na performance do ambiente como um todo, pois pode gerar uso excessivo de rede, espaço em disco ou processador. Um arquivo de log pode crescer rapidamente, até o ponto de esgotar o espaço em disco no computador. Pode também conter tantas informações, com grau de detalhe tão minucioso, que se torna difícil extrair alguma informação realmente útil num contexto particular, como uma falha de segurança.
Dadas todas essas considerações, a geração de logs não pode ser realizada sem planejamento e gerenciamento. Os profissionais que fazem uso dos logs precisam ter controle sobre a forma como os logs são gerados, ou mesmo ter a opção de não gerar log nenhum.
Frameworks de logging
A prática de se chamar System.out.println dentro de uma aplicação gráfica ou web, para exibir informações de depuração, é uma forma primitiva de logging. Entretanto, não é uma forma eficaz, porque:
l Não permite salvar com facilidade o resultado em um arquivo ou outro meio persistente.
...
