São muitas as alternativas para que os logs sejam criados. A captura de registro de logs devem ser desenhada para atender um equilíbrio que todos registros sejam sucintos e minimamente didáticos para solução de um problema. É obrigatório que toda uma aplicação seja coberta por registros de log de erros, isso garante o mínimo do mínimo.
Para informações pertinentes e relevantes um registro de log deve ser composto pelos seguintes propriedades:
Data Evento
Essa data refere ao momento do registro do Log, de preferência com fuso horário ajustado para a audiência.
Aplicação
Nome da aplicação que está gerando a mensagem de log.
Nível
Todo log deve pertencer obrigatoriamente a um nível, é fundamental o entendimento desses níveis, porque alguns não são aplicados em todos ambientes.
TRACE: Esse nível deve ser utilizado para rastrear algo pontual em produção e nunca devem ficar habilitados definitivamente em produção.
DEBUG: Nesse nível pode ser logado qualquer coisa durante o desenvolvimento, porque esse tipo só será registrado em ambiente de desenvolvimento.
INFO: Os logs desse nível devem basicamente rastrear pontos de fluxo do aplicativo.
NOTICE: Todos esses logs serão criados para monitoramentos em produção.
WARN: Neste nível são os logs de alertas (monitoramento) para potenciais problemas que podem gerar erros, como falta de espaço, lentidão. Porém não causam a interrupção da execução do aplicativo.
ERROR: Todas as condições de erro gerados dentro do programa, quando um fluxo fluxo de execução é interrompido devido a uma falha.
FATAL: Os logs neste nível devem ser utilizados para acionar contingências, pois descrevem um aplicativo irrecuperável ou falha do sistema que requer atenção imediata.
Categoria
Todos os logs devem conter obrigatoriamente uma categoria, essa categoria deve ser utilizada para agruparem logs dentro do mesmo contexto, que facilitem a extração dentro de um comportamento. Outro fator importante, é utilizar um nível hierárquico respeitando o princípio simples de responsabilidade.
Mensagem
As mensagens devem ser escritas em inglês, isso se deve ao fato das ferramentas de análise de logs estarem preparadas para analisar palavras e frases associados ao idioma inglês, além de evitar problemas com acentuação que ocorre muito no idioma português.
O conteúdo da mensagem devem ser ricos no sentido que ofereçam informações que auxiliem no entendimento do logs, muitas vezes quem estará interpretando a mensagem não necessariamente tem o conhecimento do negócio.
Sempre adicione contexto as mensagens, todo registro de log deve conter por si só, todas as referências necessárias para auxiliar no entendimento da sua geração.
A grande maioria dos logs atualmente são analisado por ferramentas de monitoria, e lembrando que essas leituras são feitas por máquinas, é importante que o conteúdo das mensagens sejam acessíveis a humano e máquina, logo é importante normatizar os dados para facilitar o entendimento de ambos, uma forma é elegante é tipificar através do formato JSON o conteúdo.
Nenhuma informação sensitiva devem ser armazenadas em nenhum nível de logs, seja nome do cliente, número de documento, senhas, tokens, ou seja, nenhum dados que possa identificar ou expor informações. Os logs não passam por nenhum tipo de validação de conteúdo, por conta que as informações são muito genéricas, logo é sua responsabilidade não armazenar informações que ferem as leis (LGPD).
Regra de ouro para definir o que registrar numa mensagem de log?
Simplesmente pense em algo que alguém terá de lê-lo um dia ou mais tarde. Mais importante, é pensar em quem vai ler essas linhas, pois isso define o conteúdo, contexto, categoria e nível da mensagem.
Usuário
Essa informação diz a respeito do usuário que está utilizando a aplicação no momento do log, seja um colaborador ou até mesmo um processo automatizado.
Ambiente
Deve sempre identificar o ambiente em que log foi gerado (Desenvolvimento, Homologação, Pré-Produção, Produção, ...)
Outro ponto importante, é a centralização dos logs, pois permitirá aumentar a segurança e praticidade, sendo que os logs centralizados ficam mais fácil para fazermos consultas em busca de erros e análise e controlar a permissão de acesso.
Lembre-se também de criar uma regra de retenção, porque os logs contém uma volumetria muito alto e se não for criado essa política, com o tempo muitas informações não mais necessárias estarão aumentando o tempo de consulta e dificultando a localização de dados relevantes.
E ainda, cada vez que um código for refatorado é importante criar mensagens de log. Procure manter uma sincronia entre os comentários e o registro de log, porque não há nada pior ao solucionar problemas para obter mensagens irrelevantes que não têm relação com o código processado.
Marcelo Goberto de Azevedo
Arquiteto na GFT Brasil