Eu estava escrevendo sobre logs estruturados, em especial sobre o Enterprise Application Log, e resolvi quebrar meus argumentos em frações menores para poder isolar as ideias.
Aqui hoje quero falar sobre o que um bom log deve ter.
Nos primeiros anos de 2010, a evolução na gestão de logs começou a tomar forma. Começávamos a abandonar logs em strings, para passamos a adotarmos logs estruturados. Agora os logs continham muitos metadados que descreviam mais do que um stack trace, uma mensagem e um tipo. Essa é uma inovação cujos efeitos ainda hoje permeiam a maneira como lidamos com nossos logs.
Minha história se cruza com a dos logs estruturados quando por mais de uma vez me vi diante da dificuldade de reproduzir erros muito específicos. Eu tinha os logs, tinha o stack trace, mas não conseguia reproduzir o cenário que produzisse tal comportamento.
As boas práticas serviam apenas para saber que havia um erro, qual erro. Mas não serviam de nada na hora de identificar o cenário exótico para reproduzir o evento que resultou em erro.
Logs devem contar histórias
Se você já me viu falando de Logs ou Exceptions, sabe que tanto as exceptions, quantos os logs são super bem vindos.
Talvez deva ter me escutado falar de que os logs devem contar histórias.
Que histórias os logs devem contar?
A história que busco em um log é:
No dia 23/JUN/23, às 02:27 UTM-3, Luiz Carlos Faria, publicou um post, com o título “Quais dados, logs estruturados precisam ter?” de slug “quais-dados-logs-estruturados-precisam-ter”, no wordpress, no container XPTO, , hospedado no servidor oragon01 na Hetzner Alemanha, com as tags “Log“ o resultado foi sucesso, a publicação durou 5 segundos.
Onde?
Quem?
Qual aplicação, componente, operação?
Fez o quê?
Com quais parâmetros?
Qual o resultado?
Com qual consumo de recursos?
Em quanto tempo?
Queremos esse log em texto, como o exemplo acima?
Não!
Queremos uma estrutura JSON com todos os campos apenas.
Logs precisam dizer como reproduzir o erro
Mesmo que esbarremos em uma exception lançada por nós mesmos, eu quero saber porque ocorreu.
Até porque, em uma aplicação sem bugs, exceptions não precisam ser lançadas nunca.
Mas estão lá no código esperando o vacilo do dev para serem lançadas.
É como um policial que não deixa o pior acontecer.
E 99.9% do tempo, ele está ali só para não deixar sem proteção.
Exceptions devem ser tratadas assim.
Talvez eu precise usar uma massa de dados específica, talvez eu tenha de solicitar informações sobre o ambiente que a aplicação estava rodando, talvez eu tenha de pedir para ver dados de produção, mesmo que mascarados.
Esse dilema, exige que os logs sejam mais do que uma grande string com uma mensagem de texto, eles precisam de metadados que permitam filtros e agrupamentos.
Assim os logs que descrevo são produzidos em formato JSON e possuem:
- Informações sobre o Ambiente
- Em que container ou pod
- Em que nó ou servidor
- Qual Configuração (dev/prd/etc)
- A Aplicação/Serviço
- Qual foi o serviço ou aplicação
- Em que executável
- Em qual versão
- A operação
- Qual o método que gerou o erro.
- Contexto
- Quais os parâmetros (ou o parâmetro inteiro, ou Id’s significativos)
- Qual usuário executou
- Em que momento executou.
Com essas informações você ganha a capacidade de identificar padrões que nunca foi capaz de identificar antes.
Mas para quê?
- É possível correlacionar um erro a um ID de Cliente.
- Identificar que um determinado erro começou a ocorrer a partir de uma versão específica. Ou identificar que não é um erro novo, é um erro antigo, que se arrastava de forma invisível.
- Identificar que todos os erros de um determinado tipo estão ligados a uma massa de dados específica de um cliente ou usuário específico.
- Correlacionar um erro a um POD, Nó ou Cluster específico.
E por fim, descobrir quais são os dados necessários para reproduzir o problema.
Mas qual o objetivo?
Essa busca é por eficiência, por conseguir responder proativamente, rapidamente aos mais variados tipos de erros.
Ao conter esses dados, é possível reproduzir erros e simplificar o processo de troubleshooting.
No final do dia estamos reagindo mais rápido e de forma mais assertiva, com efetividade nas nossas atividades. Temos capacidade de sair do achismo e reduzir o processo de descoberta do cenário de testes.
Muito bom esse conteúdo. Os detalhes e porquês dessa organização é a parte mais valiosa. Orbigado por compartilhar e gostaria de ler mais conteúdos como esse 🙂