A Odisséia de Observabilidade de Sofia: loga tudo e mais um pouco

No mundo caótico do desenvolvimento de software, ter o mínimo de visibilidade das coisas é como navegar em águas desconhecidas. Mas aqui, Sofia está de volta com uma missão épica: transformar o cenário de observabilidade da equipe Fast Payment em algo espetacular. Este time de sua empresa, alimentado por Java, está mergulhado em um oceano de logs, negligenciando por muito tempo sua responsabilidade em observar seus serviços e estruturas. Por anos, confiaram em uma única instância EC2 na AWS com um Elasticsearch, servindo como o epicentro para toda a equipe.

O serviço Fast Payment é o coração pulsante da empresa, tornando as transações de pagamentos dos clientes uma realidade. No entanto, havia um problema: o serviço estava sobrecarregado e cada vez que quebrava, a recuperação era uma verdadeira tortura, causando prejuízo financeiro para a empresa.

Prepare-se para embarcar em uma jornada fascinante, acompanhando a história de Sofia e sua parceira em observabilidade, Lauren. Juntas, elas vão encarar os desafios assustadores que assombram a equipe Fast Payment. Junte-se a nós nesta aventura para desvendar como superaram os obstáculos e tornaram observabilidade em um aliado poderoso.

Logs Que Não Acabam

Fast Payment, um aplicativo Java, era verboso quando se tratava de logs. Sua abordagem era simples — loga tudo, o tempo todo. O resultado? Caos. A equipe se viu afogada em uma chuva de logs, com alertas girando como uma cascata turbulenta. A situação deixou Sofia desanimada. “Como é que deixaram chegar nesse ponto?”. Mas ela compreendia a situação da equipe. A pressão implacável para cumprir prazos e entregar resultados frequentemente resultava nesse descuido para com coisas básicas como segurança, observabilidade, escalabilidade, etc.

Mas Sofia não estava sozinha nessa treta.

Lauren, uma engenheira de confiabilidade veterana em observabilidade com uma boa experiência em Java, tem uma ideia:

“Dá pra fazer, mas vamos precisar do apoio da galera de cima, afinal, essa solução não se limita apenas ao time de Fast Payment, mas sim para toda a empresa. Vai dar trampo.”

Ela ajusta os óculos enquanto pensa e sorri. “Padronização, mana, padronização.” diz Lauren.

“De cima?” pergunta Sofia.

“Gestores, mulher. Galera da diretoria, aqueles-que-não-batem-ponto” responde Lauren.

Ela sabia que, sem o apoio da alta administração, elas não seriam capazes de transmitir essa ideia de padronização dos logs. Não há evangelização ou mesmo uma padronização sequer sem o apoio da diretoria. Então, ela preparou uma apresentação e conversou com eles sobre a importância de atuar nisso agora.

Hora De Pôr A Mão Na Massa

Na primeira conversa com o tech-lead do time Fast Payment, Marcelo, Sofia começa a listar as atividades enquanto Lauren faz algumas perguntas a ele.

“Como vocês recebem notificações? Como funcionam seus alertas?” pergunta ela.

“Bem, temos as notificações dos alertas mais críticos no Slack, o problema é que é verboso demais, tipo, excessivamente. Quando tem algo rolando, o canal do Slack não consegue lidar com o volume e trava, então sabemos que algo está realmente errado.” diz Marcelo.

“Caraca...” Sofia parecia surpresa. Lauren olhou para ela e disse com um sorriso no rosto: “Primeira vez?”

“Bem, vamos começar então, temos muito a fazer e a maior parte depende apenas de vocês.” Sofia disse, afastando o cabelo do rosto. “Vamos disponibilizar à vocês o acesso a nossa nova estrutura do Loki, e então apoiamos na instrumentação do Opentelemetry.” diz Sofia se levantando. “Mas não vamos pedir para vocês moverem o tráfego de logs de imediato, vamos fazer isso depois da reestruturação, que falaremos mais pra frente.” comenta ela.

“Legal, já estávamos instrumentando o Fast Payment com Opentelemetry em desenvolvimento e homologação, acho que pra produção não teremos problemas.” diz Marcelo empolgado. “Aliás, souberam que vamos ter um workshop de Opentelemetry com os times de tech? Bem legal a iniciativa e espero que possamos deixar tudo redondo em todos os serviços.”

“Sofia deu um help grande com esse workshop, mérito dela. Espero que a galera não leve isso como uma coisa pontual, mas sim algo contínuo.” diz Lauren coçando a cabeça.

Ok, estão dando início aos trabalhos, mas espera aí... O que diabos é Loki e Opentelemetry?

Grafana Loki

Loki é um sistema de agregação de logs, horizontalmente escalável, altamente disponível e multi-inquilino, inspirado no Prometheus. Ele foi projetado para ser muito econômico e fácil de operar. Loki não indexa o conteúdo dos logs, mas sim um conjunto de rótulos para cada fluxo de log.

Como se diz na comunidade, é como o Prometheus, só que pra logs.

Fonte: https://grafana.com/oss/loki/

OpenTelemetry

OpenTelemetry é um framework e conjunto de ferramentas de observabilidade projetado para criar e gerenciar dados de telemetria, como traces, métricas e logs. Crucialmente, o OpenTelemetry é independente de fornecedores e ferramentas, o que significa que pode ser utilizado com uma ampla variedade de backends de observabilidade, incluindo ferramentas de código aberto como Jaeger e Prometheus, assim como soluções comerciais. OpenTelemetry é um projeto da Cloud Native Computing Foundation (CNCF).

Fonte: https://opentelemetry.io/docs/what-is-opentelemetry/

Navegando no Labirinto dos Níveis de Log

Para entendermos um pouco mais sobre a estrutura de um log, vamos falar sobre a hierarquia dos níveis de log. Esses níveis formam a espinha dorsal de um sistema de log organizado, permitindo que os desenvolvedores classifiquem mensagens de log com base em sua importância e gravidade. Os principais níveis de log incluem:

• Debug: Este nível atua como uma lupa, fornecendo detalhes intricados essenciais para solução de problemas profundos.
• Info: É o nível da “visão geral”, lançando luz sobre o que acontece na aplicação, incluindo atividades do usuário e eventos do sistema.
• Warning: Sinaliza preocupações potenciais que exigem atenção, como lentidão do sistema ou eventos não críticos.
• Error: Neste nível, você mergulha em problemas reais dentro da aplicação, incluindo informações sobre exceções e pistas vitais para identificar o problema.
• Fatal/Critical: Reservado para os erros mais graves que podem parar abruptamente a aplicação.

Impondo Ordem ao Caos com Logs Estruturados

Entrar no fascinante universo dos logs estruturados é como abrir a porta para a ordem em meio ao caos do registro de eventos e mensagens de um sistema. Imagine-o como uma biblioteca meticulosamente organizada, onde desenvolvedores podem encontrar rapidamente informações cruciais para a saúde do sistema. Agora, vamos explorar não apenas a importância, mas também os segredos por trás da eficácia dos logs estruturados.

Essa abordagem estruturada oferece:

• Organização Aprimorada: Logs estruturados categorizam de forma organizada os dados de log, facilitando a navegação e a localização de informações específicas.
• Análise Simplificada de Logs: Logs estruturados simplificam o processo de análise de dados de log, permitindo uma resolução mais rápida de problemas e detecção de padrões.

A organização aprimorada que os logs estruturados proporcionam é o primeiro passo para uma observação mais eficiente do sistema. Eles categorizam de maneira organizada os dados de log, facilitando a navegação e a localização de informações específicas. Essa abordagem traz não apenas ordem, mas também a capacidade de simplificar a análise de dados, acelerando a resolução de problemas e a detecção de padrões.

Lauren compartilha algumas dicas valiosas para elevar ainda mais a eficácia dos logs estruturados:

Dicas de Logs Estruturados

• Melhore a legibilidade incluindo contexto adicional, como timestamps, informações do serviço, detalhes do usuário e informações de solicitação nos logs estruturados.
• Personalize o formato dos dados utilizando JSON (uma sugestão) para clareza e organização.
• Evite logar listas ou arrays; eles sobrecarregam seus logs.
• Evite concatenar strings em seus logs para simplificar a análise das entradas de mensagens.
• Priorize a segurança não logando dados de usuário não sanitizados. Mascare ou oculte informações sensíveis.

Aqui temos um exemplo de uma entrada de log estruturado:

{ "@t": "2024-01-13T00:18:19.4832423F", "@mt": "{@Result}", "@l": "Error", "Result": { "Action": "USER_UPDATE", "Success": false, "Login": "dogao-do-seu-quincas" } }

“Então, como sabemos se temos tudo o que queremos na mensagem?” perguntou Marcelo.

“Bem, na minha opinião, quando você é capaz de não registrar nenhum info, e registrar apenas erros e outras anomalias, você está no caminho certo. Como estamos implementando Opentelemetry, não ficamos limitados a ver apenas logs, mas métricas e tracing também, então o registro pode ser exclusivo para erros/anomalias,” responde Lauren. “Vocês conseguem ter muito mais visibilidade do que imaginam com métricas e traces. A ideia é não depender de logs apenas.” Sofia complementa sorrindo.

“Então é assim que a aplicação vai expor métricas para o Prometheus, certo?” perguntou Marcelo. “Exatamente, mas não vamos criar métricas para tudo, isso não faz sentido. A parte importante é criar métricas dos fluxos importantes da aplicação, como transações, transações com erro e assim por diante.” acrescentou Lauren.

“Podíamos fazer um workshop instrumentando alguma aplicação com Opentelemetry para todos os times assistirem, o que vocês acham?” pergunta Marcelo, empolgado. “Vocês mesmos podiam fazer essa apresentação, ué, Fast Payment é um ótimo case de sucesso.” retruca Sofia. “Touché” diz Lauren sorrindo. “Pode crer, vou falar com a galera haha” Marcelo responde sem jeito.

Migrando Alertas de Logs para Métricas

Aprimorar a observabilidade significava fazer uma mudança significativa: transferir alertas de logs para métricas. Essa transformação revolucionou a maneira como a equipe detectava e respondia a problemas. Os benefícios eram claros:

• Precisão: Métricas são indicadores precisos da saúde e do desempenho do sistema, permitindo uma detecção precisa de problemas.
• Redução de Ruídos: Alertas baseados em métricas diminuíram o ruído do sistema, permitindo que a equipe se concentrasse em alertas acionáveis com limites bem definidos.
• Monitoramento em Tempo Real: As métricas ofereceram monitoramento em tempo real, capacitando a equipe a resolver problemas conforme eles ocorriam.

“Não menos importante, métricas são mais baratas do que logs” comenta Sofia.

“Pois é, vai ajudar bastante no médio e longo prazo” responde Marcelo.

“Sem falar que, com logs e métricas em um único serviço de visualização, aka Grafana, é uma experiência do car*&¨%” diz Lauren. “Quando vocês implementarem tracing, vai ficar ó chef's kiss” complementa ela.

Finalmentes

“Só pra fechar, deixa ver o que fizemos” diz Marcelo:

• Desligamos o Elasticsearch ✓
• Estruturamos e organizamos os logs de todo o Fast Payment ✓
• Instrumentamos o Fast Payment com Opentelemetry ✓
• Logs estão estruturados e com níveis organizados ✓
• Desligamos nosso canal de alertas do Slack; agora usamos alertas via AlertManager (Prometheus) ✓
• Passamos a olhar mais para métricas do que para logs ✓

“Muito bom, show de bola. Posso dar uma merecida folga para minha equipe e deixar o trabalho de plantão para o time de operações. Obrigado, pessoal!” disse Marcelo.

“Por nada, espero que vocês possam dar um descanso para aqueles alertas no Slack,” respondeu Lauren. “Ainda assim, há muito espaço para melhorias, podemos conversar quando puderem sobre Opentelemetry, a comunidade tá muito acelerada com a ferramenta” disse Sofia.

Com sua jornada de observabilidade em pleno vapor, o time do Fast Payment, orientado por Sofia e Lauren, estava no caminho certo para criar um sistema mais eficiente e prático. Trampos inacabáveis estavam à frente, mas o caminho para a excelência em observabilidade não parecia tão assustador quanto antes. Era uma jornada cheia de promessas, graças à dedicação de Sofia, Lauren e de toda a equipe do Fast Payment.

Observações Finais

Tradução com adaptações do artigo original: https://medium.com/@letathenasleep/sofias-observability-odyssey-bad-log-day-91a3fc95249a

Glossário

• EC2: O Amazon Elastic Compute Cloud (Amazon EC2) é um serviço da web que disponibiliza capacidade computacional segura e redimensionável na nuvem. O EC2 oferece muitas opções que permitem criar e executar praticamente qualquer aplicação.
• Slack: O Slack é um app de mensagens para empresas que conecta as pessoas às informações de que elas precisam. Reunindo pessoas para trabalhar como uma equipe unificada, o Slack transforma a forma como as organizações se comunicam.
• JSON: O JSON é um formato de dados leve e de fácil leitura utilizado para troca de informações entre sistemas computacionais. Ele é frequentemente usado para transmitir dados entre um servidor e um cliente em aplicações web e móveis, embora também seja utilizado em diversos outros contextos.

Fontes

• https://grafana.com/blog/2022/05/04/how-to-capture-spring-boot-metrics-with-the-opentelemetry-java-instrumentation-agent/
• https://prometheus.github.io/client_java/getting-started/quickstart/?source=post_page-----91a3fc95249a--------------------------------
• https://medium.com/@func25/logging-best-practices-proven-techniques-for-services-b772eaedbe3f
• https://talktotheduck.dev/logging-best-practices-mdc-ingestion-and-scale?source=post_page-----91a3fc95249a----------------------------

O que é "A Odisséia de Observabilidade de Sofia"?

Adso Castro escreve sobre Observabilidade e SRE contando histórias pessoais e não tão pessoais assim, utilizando personagens fictícios na trama. A ideia é abordar assuntos complexos do mundo de Cloud Native de uma forma mais amigável. As histórias giram em torno das personagens Sofia e sua amiga e colega de equipe, Lauren.