Logs
No projeto que trabalhava, desenvolvemos uma auditoria para registrar a comunicação com os serviços externos, alertas sobre inconsistências nos dados e erros.
Queríamos prover qualidade na investigação de erros. Nós deveríamos fazer o sistema “falar” sobre esses erros de maneira rastreável para que encontrássemos a raiz dos problemas o mais rápido possível e resolvêssemos quando fosse a hora.
Logging
Foi um pouco complicado pesquisar sobre o assunto. Usar como palavra-chave log, logfile, até mesmo logging, não me trouxeram boas fontes na área.
Logging, de acordo com os primeiros resultados do Google.
Figura mostrando uma floresta com arvores cortadas.
Com ajuda, me deparei com o termo logging estruturado. Essa sim foi uma boa palavra-chave.
Se você é uma desenvolvedora ou desenvolvedor, e reparar, logs fazem parte do nosso dia-a-dia, desde aqueles que geramos em nossos sistemas, desde aqueles que interpretamos de sistemas de terceiros.
E aqui vai uma definição que acredito se aplicar, e vem de um textodo Gregory Szorc, engenheiro da Mozilla:
“(Logs são) um fluxo de mensagens distintas geradas a partir da execução de um programa.”
Logs geralmente são guardados em simples arquivos de texto, como .npm-log do NPM. e também são mostrados em terminais/consoles.
Linguagens de programação proveem uma maneira de criarmos log.
Em Python temos o logger, no Javascript console.log. A simples chamada de um print() do Python ou system.out.println() do Java informando o que está ocorrendo já é um log.
As linguagens e frameworks geralmente possuem módulos, libs que abstraem o trabalho de criar logs, como log4j para Java.
Logging Estruturado
Pessoa vs Máquina
Deve-se pensar na distinção de quem irá consumir seus logs.
Um pessoa é capaz de ler um conjunto de palavras que lhe sejam legíveis (levando em consideração idioma, conhecimento, contexto). Mas nem sempre o que é entendível para uma pessoa, um programa irá entender.
De acordo com Gregory Szorc, a informação desestruturada (puramente texto) é um problema quando queremos que uma máquina leia e interprete logs.
Digamos que vamos imprimir essa mensagem de log:
Roselma successfully logged in
Log desestruturado
logger.info(username + " successfully logged in")E dessa mensagem queremos pegar as informações para guardar em uma tabela de banco, por exemplo:
for (let line of log) {
if (line.endsWith("successfully logged in")) {
// Find username.
let spaceIndex = line.indexOf(" ");
let username = line.substr(0, spaceIndex - 1); // Do something interesting.
} else if (line.indexOf(...)) {
//
}
}
Com log estruturado
Imprimindo…
logger.info("successful_login", who=username)Obtendo os dados desse log:
for (let line of log) {
let [time, level, action, fields] = JSON.parse(line) if (action == "successful_login") {
let who = fields.who; // Do something interesting.
} else if (action == "XXX") {
// ...
}
}
Do primeiro para o segundo código nota-se maneiras diferentes de obter as informações. Na primeira, temos que lidar com uma pura string e se utilizar de métodos que lidem com a subtração e procura de conteúdo. Já na segunda somente lidamos com uma linha formada de campos e ler o que cada um traz.
Quando falamos de logging estruturado, precisamos que os dados de uma mensagem de log sejam guardados em estruturas bem definidas.
Eu posso ter a mensagem de log guardada da seguinte maneira:
[1354317157.034534, "INFO", "sucessful_login", {"who": "Roselma"}]O logging estruturado irá ocorrer de diferentes maneiras, dependendo da linguagem e/ou framework utilizado.
Ora, mas por que logging estruturado?
Bem, estamos falando aqui do uso de logs para nos dar informação rápida, gerar dados de análise para nossos sistemas. E esse melhor uso da informação, que temos com o log, tem sido alcançado usando soluções que automatizam o processo de interpretação humana.
Por fim, máquinas precisam ler nossos logs para nos dar informação otimizada sobre nossos sistemas.
Imagine que é possível que a cada mensagem de erro crítico, um sistema lhe envie uma mensagem de email avisando com detalhes o que aconteceu.
Um passo muito importante para alcançar/facilitar isso é o logging estruturado.
O que logar?
Gregory Szorc lista o que ele acredita que sejam as situações onde logs são usados:
Tem muita discussão na rede acerca do que deve ser logado ou não. Algumas pessoas pregam que você só deve logar exceções,outras que você deve logar tudo (paramêtros das funções, funcionalidade, etc), mas com moderação.
Para mim, além das dicas do Szorc, log tem que ter contexto. Muito mais que ter um stack trace, tem muito valor você colocar mais informação no seu log, como uma simples mensagem do tipo “Verificando dados do usuário 134” que mostram o que tipo de atividade o programa estava fazendo quando a exceção aconteceu e o dado a ser manipulado.
E logs não só necessários quando o programa lança erros, mas também quando tudo vai bem no código. Afinal, tudo está bem em um momento e no outro não. Criar uma “timeline” do que acontece no seu sistema ajudará bastante na resolução de problemas, principalmente em produção. E os problemas podem se manifestar sem exceções em logs, como uma soma errada do total de uma nota em um site de e-commerce.
No final a estrutura dos seus logs dependerão da natureza do seu sistema, tecnologias/frameworks e do que você espera que será útil saber para monitorar o seu funcionamento.
E para finalizar uma lista de ferramentas que ajudam com o manuseio de logs no Stackshare.
Links
3 Ways to Make Sense of Errors & Logging
