O Caminho do Sicredi para adoção do Opentelemetry
Prefere ler em inglês? Clique aqui. 🇺🇸
Escrito por Gilberto Lupatini, Henrique Luis Schmidt e Igorestevanjasinski
Nos últimos anos, Sicredi vem passando por uma transformação digital e um crescimento exponencial. Como resultado disso, a migração de sistemas legados para uma arquitetura voltada para microsserviços foi um processo natural, porém com isso observabilidade se tornou indispensável.
Quando iniciamos nossa jornada de observabilidade, tínhamos como objetivos a padronização dos sinais de telemetria, o aumento da correlação e do contexto entre serviços, e principalmente, a geração de dados de telemetria de qualidade. Escolher o OpenTelemetry para atender a esses objetivos não foi apenas óbvio, como foi uma decisão estratégica.
Na Sicredi, já tínhamos estabelecido uma boa cultura em torno de métricas, utilizando principalmente Prometheus e Influx. Por isso, o primeiro sinal que decidimos padronizar foram os Traces. No entanto, ao longo do caminho, percebemos que fazer rastreamento distribuído sem a padronização adequada de bibliotecas, backend e convenções semânticas seria difícil. Assim, alinhar-se a um framework específico de observabilidade, como o OpenTelemetry, tornou-se essencial.
Escolhendo o caminho mais difícil
Nosso primeiro desafio foi padronizar a instrumentação entre os serviços. Por isso, ao invés de adotarmos a abordagem comum de instrumentação automática por meio de agentes, optamos pelo caminho “mais difícil” da instrumentação manual. Essa decisão não visou apenas fornecer uma solução ou ferramenta aos times, mas também fomentar uma cultura de responsabilidade em observabilidade, permitindo que os times tivessem maior controle sobre seus sistemas.
Um dos nossos desafios foi unificar as soluções existentes de métricas e traces, que acumularam três versões de bibliotecas e protocolos, incluindo Spring Cloud Sleuth, Zipkin e OpenTracing. Dada a descontinuação do OpenTracing e a migração do Sleuth para o Micrometer Tracing, acreditamos que era hora de considerar uma substituição que pudesse abranger todas as outras bibliotecas e configurações.
Como operamos principalmente com Java e Spring Boot, criamos uma biblioteca interna de observabilidade. Esta biblioteca ajuda os desenvolvedores a instrumentar seus aplicativos configurando a API e o SDK Opentelemetry, simplificando as interações com sinais e atributos de telemetria. Considerando o cenário heterogêneo de soluções e diferentes versões de JDK e SpringBoot, criar uma biblioteca que agilizaria a substituição parecia a melhor abordagem. Na verdade, provou ser eficaz na padronização de configurações e na abstração de detalhes de infraestrutura.
A versão inicial da nossa biblioteca substituiu todas as dependências existentes e configurações necessárias nos arquivos de configuração do Spring. Inicialmente, mantivemos a compatibilidade com o protocolo Zipkin para facilitar a migração de projetos e infraestrutura. Na segunda versão, também adotamos o protocolo OTLP com HTTP para transmissão do sinal.
À medida que mais equipes adotaram nossa biblioteca de observabilidade, expandimos o suporte para incluir outras bibliotecas e estruturas de instrumentação, como Kafka, MongoDB e JDBC. Embora nem todos os projetos tenham sido migrados ainda, estamos ativamente trabalhando para resolver isso. Estamos considerando inclusive a implementação de atualizações automáticas do código, um tema que abordaremos mais detalhadamente no futuro.
O canivete suíço
Opentelemetry nos permite enviar dados de telemetria para nossos backends diretamente de nossos microsserviços usando o SDK, o uso coletor do Opentelemetry nos permite controlar o volume, transformar e adicionar dados de maneira centralizada e escalonável.
Na primeira fase, nosso objetivo com o coletor era controlar o volume de dados exportados de nossa aplicação para o backend usando técnicas como amostragem baseada em probabilidade e também adicionar atributos em nossos spans para diferenciar a telemetria provinda de diferentes locais, por exemplo, uma aplicação que emite telemetria através do nosso datacenter on-premises e uma aplicação hospedado em um provedor de nuvem.
Após esta etapa, a cultura de utilizar de rastreamento distribuído para solucionar problemas e entender o comportamento do sistema começou a crescer no Sicredi. Assim, na segunda fase, nosso foco mudou de armazenar uma grande quantidade de dados, para otimizar a armazenagem dos dados com maior valor agregado. Isso foi necessário pois, percebemos que mais dados não tornam necessariamente nossos sistemas mais observáveis; em vez disso, os dados corretos podem se perder em um mar de milhares de spans gerados por segundo. Com isso em mente, decidimos mudar nossa estratégia de amostragem, de Head-based sampling para Tail-Based sampling.
O Tail Sampling é uma técnica de amostragem que permite analisar traces com base em políticas específicas, esperando que o trace esteja completo antes de decidir se ele será exportado para um backend. Essa metodologia foi um divisor de águas para nós, pois nos possibilitou estabelecer políticas baseadas em latência, erros ou atributos específicos de spans. Além disso, continuamos utilizando uma taxa de amostragem baseada em probabilidade, o que nos permite reter uma pequena porcentagem dos traces, considerando o volume total. Essa abordagem nos permitiu fornecer os dados certos para os desenvolvedores, enquanto controlamos o volume de dados exportados.
Próximos passos
Escalando a instrumentação
Embora tenhamos inicialmente implementado a instrumentação manual, os desafios de escalabilidade e as diversas prioridades entre as equipes nos levaram a considerar a instrumentação automática. Utilizando o operador e a injeção de agentes do Opentelemetry, podemos automatizar esse processo, o que se alinha bem com as linguagens de programação em nossa stack de tecnologia. Apesar do risco de sobrecarga de instrumentação, o operador oferece técnicas eficazes de mitigação.
Essa abordagem dupla oferece vantagens significativas: a instrumentação manual continua valiosa por sua flexibilidade na personalização dos sinais de observabilidade. No entanto, equipes que não dispõem de tempo ou que estão satisfeitas com os sinais fornecidos pela instrumentação automática podem dispensar a configuração manual, simplificando seu processo de desenvolvimento.
Correlação
Uma evolução chave para nós é gerar todos os principais sinais de telemetria no formato OTLP. Um dos nossos próximos objetivos é produzir traces, métricas e logs com metadados uniformes, facilitando a correlação entre esses sinais. O operador Opentelemetry pode nos auxiliar significativamente na realização deste objetivo
Já observamos os benefícios de correlacionar traces e logs. Agora, pretendemos aprimorar isso incorporando exemplars e outras técnicas de correlação, adicionando um contexto mais rico aos nossos dados de telemetria. Isso permitirá que nossas equipes identifiquem e resolvam problemas em seus sistemas de forma mais eficaz.
Game Day
O Opentelemetry contribuiu significativamente para cultivar uma cultura de observabilidade dentro da nossa organização, mas ainda há espaço para crescimento. Uma ideia promissora é organizar “Game Days” para entender melhor a dinâmica das equipes durante a resposta a incidentes. Esses exercícios podem revelar como os times utilizam os sinais de telemetria para identificar e resolver problemas. Um exemplo notável de um Game Day bem-sucedido é destacado em um post do Skyscanner na página do Opentelemetry. Os insights dessas sessões podem ser inestimáveis para personalizar o treinamento de desenvolvedores, profissionais de DevOps e outros membros da equipe, com base em seu desempenho e estratégias empregadas durante essas simulações.
É evidente que Opentelemetry tem sido um fator de extrema importância em nossa jornada de observabilidade e, à medida que o projeto evolui, nós também progrediremos.
