Introdução

Em um mundo onde dado é o novo petróleo, a habilidade de extrair informações valiosas de um mar de dados é crucial. No contexto da observabilidade em arquiteturas de software, os logs estruturados desempenham um papel central. Eles não são apenas ferramentas para trace, debug ou monitoramento, mas também uma mina de ouro para insights de negócios.

Já são 10 anos desde o lançamento do primeiro post sobre Logs Estruturados e 8 anos desde o lançamento do Enterprise Application Log, é hora de abrir a caixa de pandora!

A Importância dos Logs Estruturados

Logs estruturados são mais do que registros cronológicos de eventos em um sistema. Eles são enriquecidos com dados contextuais que expressam a operação, quem executou, onde executou e tudo mais que puder ser usado mais tarde, excluindo apenas dados que não podem estar no log, geralmente por questões legais e de compliance.

Ao contrário dos logs tradicionais, em texto não estruturado, os logs estruturados são formatados de maneira a facilitar análises e consultas futuras, indiscriminadamente!

Fundamentos de Logs Estruturados

Definição e Formato

Logs estruturados são caracterizados pelo seu formato, geralmente JSON ou XML, onde cada elemento do log é um par chave-valor.

Esta estrutura permite maior dinamismo e fácil manipulação, além de serem compatíveis com praticamente todos os serviços.

Diferente dos logs em texto, onde produzimos uma mensagem em texto com base no que se presume ser importante para notificar, nos logs estruturados enviamos o máximo de dados que podemos, para possibilitar que se usem esses dados no futuro para produzir métricas pelos mais variados insights.

Seu log pode ser data source do seu BI técnico.

Benefícios para a Observabilidade

A observabilidade, capacidade de entender o que está acontecendo dentro de um sistema pela análise de seus outputs, é amplamente beneficiada pelos logs estruturados.

Os dados adicionais enviados para a infraestrutura de log fornecem uma visão clara e profunda do funcionamento interno do sistema, facilitando a identificação de problemas e o entendimento do comportamento do sistema e do usuário.

Quanto mais dados são entregues para a infraestrutura de logs, mais métricas conseguimos produzir, com uma granularidade maior.

Integrando Dados de Negócio em Logs Estruturados

Enriquecimento de Logs

Um ponto a se ressaltar é que quando pensamos em logs estruturados, estamos preocupados em dizer exatamente o que está acontecendo com o maior número de dados de contexto possível.

Ao invés de discutirmos o que é bom colocar ou não no log, a partir de um problema ou caso, colocamos tudo que pudermos, pois não sabemos que problema pode dar, quando pode dar e quanto será útil.

Ou seja, deliberadamente estamos ignorando os limites de uma modelagem ou uma análise, e colocamos tudo que for possível e descrever o contexto de execução:

• dados recebidos do usuário
• parâmetros recebidos dos métodos
• dados obtidos do banco
• dados de configuração
• informações sobre o ambiente e servidores
• tudo que fizer sentido puder influenciar análises futuras.

O enriquecimento de logs envolve a inclusão de metadados relevantes para o negócio, como:

• IDs de transação
• informações de usuário (não somente seu ID)
• dados de geolocalização
• valores monetários
• junto com informações técnicas como métricas de desempenho, identificação do container ou pod, do cluster, e da região/DataCenter.

Estes dados adicionais transformam habilitam capacidades analíticas como nunca pudemos presenciar e ver no passado.

Correlação de Eventos Técnicos e de Negócio

Com dados de negócio integrados, é possível correlacionar eventos técnicos com eventos de negócio.

Esta correlação ajuda a entender como problemas técnicos afetam diretamente os resultados do negócio.

Em contrapartida, na direção oposta, essa abordagem também permite identificar como o volume de operações de um determinado caso de uso afeta a aplicação.

Enquanto de um lado é possível dizer quando um erro ou uma lentidão causa impacto financeiro, conseguimos medir o impacto de uma correção.
Em um cenário de pagamentos, por exemplo, conseguimos medir que um tipo específico de meio de pagamento impacta o ecossistema em etapas específicas, e proativamente sabemos que merecem atenção.

O ouro está nos dados

Em 10 anos a principal pergunta que escuto é:

O que logar? Quando logar?

Eu digo: Tudo! Sempre que um evento de negócio ocorrer.

Por exemplo: em um e-commerce, o valor total do carrinho, a forma de pagamento, o ID ou nome da integração de pagamento, são dados importantes a se colocar no log estruturado durante uma operação de pagamento ou fechamento de pedido.

Falhas nessas etapas podem ser identificadas de forma mais rápida se sabemos que apenas uma bandeira é afetada, ou se sabemos que apenas uma forma de pagamento está com falhas.

Outra informação que poderiam ser úteis são: País, Estado e Cidade do cliente que está fazendo a compra. Dessa forma conseguimos até plotar em um mapa, podendo facilita a entender quando clientes de uma determinada região estão sofrendo com alguma variação estatística da qual mereça atenção. Nesse caso, de fechamento de compra, temos essa informação no endereço de entrega da compra ou ainda podemos obter a partir do IP do cliente.

E se você questionar a informação sobre o endereço de entrega, ao poder não representar o lugar de acesso, lembre-se isso não tem tanta relevância estatística. Na massiva maior parte dos casos será preciso.

Um dado desse como cidade, região, país, é fundamental quando temos problemas de roteamento ou dns envolvendo mudanças ou evoluções que demandem reconfiguração de DNS ou adição de CDN (que demanda configuração de dns).

Onde logar? Em que camada?

Vou tomar como base o modelo do hexagonal architecture para falar sobre isso.

Está vendo a linha em vermelho chamada Application Core?

É aqui que logamos, mais especificamente no Application Services ou Command Handlers.

Então imagine uma operação do usuário vindo de Admin GUI há seleções do usuário enviadas para o Application Core.

Começamos a preencher o contexto do log com os dados de ambiente (pod, cluster, container, processo, classe, método).

Em seguida adicionamos o que puder (do ponto de vista legal) que tenha vindo da Admin GUI.

Nós não logamos ainda, ainda estamos preenchendo contexto enquanto executamos.

Em geral, obtemos dados do banco, armazenamos alguns desses dados no contexto também (o que for relevante e não veio da GUI).

Executamos a operação e adicionamos o tempo total de execução do método.

Em caso de falha, adicionamos a exception (exception completa, com stack trace por favor), de preferência Exception.ToString().

A propriedade Message da exception é a propriedade de menor relevância, em uma exception.

Type e StackTrace são muito mais significativas do que o Message em si.

Portanto nunca log apenas Exception.Message.

Logue Exception.ToString() ou as propriedades separadamente (tipo, stack trace e mensagem, essa é a prioridade por relevância).

Caso haja um resultado, logamos alguma informação, que possa ser útil (quantidade de registros, talvez).

Ao final da execução enviamos apenas 1 entrada de log com tudo.

Fazemos o mesmo com os fluxos que vêm de filas, de UI, de cli, de API etc.

Mas nós vamos reinventar o BI?

Em certa medida, sim, e outra não.

O BI atende ao negócio e, portanto, o tempo de vida dos dados no BI são de interesse do negócio.

Os logs estruturados servem ao time técnico, ao time que gerencia a aplicação, oferecendo insight em tempo real sobre o comportamento da aplicação.

Quando falamos de milhares de pedidos diários, gerar essas métricas é importante para conseguirmos diagnosticar, ainda no âmbito da aplicação, comportamentos que antes apenas equipes de BI e Negócio conseguiriam identificar, muito provavelmente com delay.

Ter informações sobre a instância, o servidor, o cluster, o datacenter também são importantes para podermos entender se um problema é localizado em um nó, em um datacenter ou é global.

Com informações simples como essas é possível medir a quantidade de vendas e o volume transacionado com sucesso apenas olhando os logs em um dashboard como grafana ou kibana.

Nossa missão é entender
como o código que colocamos em produção
como a arquitetura que escolhemos
impacta o negócio
em real time

Também é possível entender quando uma anomalia acontece, como a bandeira de um cartão não sendo usado por muito tempo, denotando algum problema com a bandeira, que descobrimos antes dos clientes reportarem.

Se serve para entendermos o que há de caótico, também nos permite entender como resolvemos problemas. Imagine poder mostrar quanto de faturamento a mais seu código gerou? Ou como uma implementação melhorou os indicadores?

Com uma foto baseada no tempo, conseguimos medir isso com clareza.

Casos de Uso e Benefícios

Detecção de Problemas

Com a inclusão de dados de negócio, é mais fácil identificar padrões que indiquem problemas, como um aumento na taxa de erros após uma nova implementação.

Também conseguimos entender melhor quais dados produziram tal problema, seja resultante de uma seleção do usuário ou uma configuração.

Análise de Desempenho

Dados de negócio nos logs permitem analisar o desempenho do sistema em relação a métricas comerciais, como tempos de resposta durante picos de vendas.

Também nos permite entender o impacto do volume de operações na performance de queries e como a aplicação está performando diante da demanda de escala.

É possível perceber como configurações de cache podem ser otimizadas, com mais tempo ou menos tempo, entregando resultados mais eficientes.

Insights de Negócios

Os logs podem revelar insights sobre o comportamento do usuário, padrões de compra e mais, oferecendo uma base valiosa para decisões estratégicas.

Imagine entender quanto seu caso de uso, recém divulgado está sendo usado.

Quantos usuários utilizam um serviço de comunicação ou chat embarcado na plataforma.

Implementação Prática

Escolhendo o Formato de Log

O primeiro passo é definir um formato de log que suporte a estruturação desejada. JSON é uma escolha popular devido à sua legibilidade e facilidade de uso, além de ocupar menos espaço que o XML.

Coleta de Dados

Os dados devem ser coletados de maneira consistente e confiável. É importante garantir que os logs capturem todos os eventos relevantes, sem comprometer o desempenho do sistema.

Enriquecimento dos Logs

O processo de enriquecimento deve ser automatizado para garantir que os dados de negócio sejam consistentemente anexados aos logs.

Isso pode ser feito através de middlewares ou serviços de logging.

Uma fração do que colocamos nos logs são variáveis de ambiente, que propagamos para informar para o log de qual Nó do Cluster Kubernetes (ou docker) ou de que POD (ou container) e de que DataCenter estamos enviando o log.

Armazenamento e Análise

Os logs devem ser armazenados de forma segura e eficiente, preferencialmente em um sistema que suporte consultas rápidas e análise de dados.

Ferramentas como ElasticSearch são comumente usadas para este fim.

Monitoramento e Alertas

A implementação deve incluir sistemas de monitoramento e alertas baseados em logs, permitindo a rápida detecção e resposta a problemas identificados.

Desafios e Melhores Práticas

Gerenciamento de Volume de Dados

Logs estruturados podem gerar um grande volume de dados. É crucial implementar estratégias de gerenciamento, como a rotação de logs e a definição de políticas de retenção.

Aqui está a resposta para você que questionou sobre a diferença entre o BI e o Log. O tempo de vida em geral é muito menor nos logs.

Armazenamos por Horas, Dias, Semanas, no máximo poucos Meses, raramente teremos anos de Logs.

Segurança e Privacidade

É vital garantir que os dados sensíveis sejam manuseados com cuidado, cumprindo regulamentações de privacidade como o GDPR.

Teste e Validação

Os sistemas de logs devem ser regularmente testados e validados para garantir que estão capturando e registrando informações precisas.

Conclusão

Logs estruturados enriquecidos com dados de negócio são uma ferramenta poderosa para qualquer organização.

Eles não apenas melhoram a observabilidade e a capacidade de resposta a problemas, mas também oferecem insights valiosos para a tomada de decisões de negócios.

Implementá-los requer cuidado e planejamento, mas os benefícios justificam o esforço.