A Odisséia de Observabilidade de Sofia: enfim OpenTelemetry

No saguão do elevador do escritório

porta do elevador se abre

Lauren sai do elevador com fone de ouvido escutando música alta e cantarolando

• "Scotty doesn't know, Scotty doesn't know, So don't tell Scotty..." e dá de cara com Sofia. "Oh, eaí. Achei que íamos almoçar".

• "São 10 e pouca ainda... e que música é essa aí?" pergunta Sofia confusa.

• "Shame, kids these days don't know that Scotty doesn't know..." murmura Lauren "Pop rock anos 2000, te mando playlist depois, ma diz aí, o que a Martinha queria contigo?"

• "Cé não imagina, ela me pediu pra atualizar nosso guia interno sobre observabilidade da empresa. Ainda pediu pra escrever o que diabos é opentelemetry que estão falando tanto por aí" diz Sofia dando de ombros

• "Ué, tá atualizado... se bem que o que tem de Opentelemetry lá atualmente são só links pra documentação oficial e as coisas que a galera BR da comunidade publica. Dá uma atualizada e cria aquelas analogias malucas que você faz, tá bom demais. Se precisar de ajuda, me avisa." diz Lauren, indo em direção à saída.

• "Claro, te vejo no almoço! VR caiu e tu me deve!" grita Sofia enquanto a porta do elevador se fecha.

Ela chega em sua estação de trabalho e abre a página de documentação interna sobre observabilidade da empresa e começa a pensar no que escrever.

• "Hmmm como é que vou explicar opentelemetry pra que não fique maçante e também não pareça um folheto de pré-escola?" pensa ela. "Ok, vamos lá...".

O que é?

Para entendermos o que é OpenTelemetry (ou OTel), vamos supor que você saiba o que são logging, tracing e metrics. E, não menos importante, que saiba o que é observabilidade, ou o conceito de observabilidade em sistemas de software, que envolve coletar e analisar dados de telemetria para obter insights sobre o comportamento de um sistema.

OpenTelemetry, também conhecido como OTel, é um framework de observabilidade de código aberto e neutro em relação a fornecedores, usado para instrumentar, gerar, coletar e exportar dados de telemetria, como traces, métricas e logs.

Como um padrão da indústria, o OpenTelemetry é suportado por dezenas de fornecedores de observabilidade, integrado por muitas bibliotecas, serviços e aplicações, e adotado por inúmeros usuários finais.

Ok.

Calma.

Vamos explicar de novo.

Imagine que você é o piloto de um avião e precisa entender tudo o que está acontecendo dentro dele durante o voo. No entanto, você não consegue ver o que está acontecendo diretamente porque está na cabine, então você precisa de instrumentos especiais para coletar informações sobre a altitude, a velocidade, a direção e assim por diante.

Agora, pense no OpenTelemetry como esses instrumentos especiais para o seu avião, mas para o seu software. Ele ajuda as pessoas desenvolvedoras a coletar dados sobre como o software está funcionando em tempo real, como quem está usando, onde estão os problemas e como melhorar seu desempenho. Assim como os instrumentos no avião ajudam o piloto a entender o que está acontecendo durante o voo, o OpenTelemetry ajuda as pessoas desenvolvedoras a entender o que está acontecendo dentro de suas aplicações enquanto elas estão em execução.

Utilizando recursos como semantic conventions, por exemplo, fica muito mais fácil compreender padrões sobre como reportar os dados. Não importa se você está pilotando um avião monomotor ou um 747, há padrões sobre como os painéis são feitos e quais instrumentos estão disponíveis para você.

A questão é: há um padrão.

Qual o propósito?

O OpenTelemetry oferece um padrão único, de código aberto, e um conjunto de tecnologias para capturar e exportar métricas, traces e logs de suas aplicações e infraestrutura nativas de nuvem. As aplicações nativas de nuvem modernas são distribuídas, o que torna complicada a captura e exportação de dados de telemetria. Um dos principais objetivos do OpenTelemetry é que você consiga instrumentar facilmente suas aplicações ou sistemas, não importa a linguagem, infraestrutura ou ambiente de execução que eles usem.

De onde veio?

O OpenTelemetry (OTel) é um projeto que junta as bases de código do OpenTracing e do OpenCensus, dois projetos anteriores criados para lidar com a falta de um padrão sobre como instrumentar código e enviar dados de telemetria para um backend de observabilidade. Os dois projetos se fundiram em 2019 para formar o OTel, que oferece uma única superfície de integração para rastreamento de telemetria distribuída de ponta a ponta.

E a tal da instrumentação?

Por motivos de "o artigo ficaria gigantesco e maçante", vamos usar um guia ultra-simples de instrumentação em Python diretamente do blog da CNCF:

https://www.cncf.io/blog/2022/04/22/opentelemetry-and-python-a-complete-instrumentation-guide/. Kudos James Blackwood-Sewell.

A partir desse conteúdo, vemos um guia simples de instrumentação em uma aplicação Python, para que possamos aprender como as coisas funcionam. E, mais no final do conteúdo, temos a menção da auto-instrumentação. Ainda assusta o quão rápido as coisas estão evoluindo quando falamos de OpenTelemetry.

Como seria um diagrama com OpenTelemetry?

1. Instrumentação: O processo começa com a instrumentação do código da aplicação. Isso envolve a inclusão de bibliotecas ou agentes do OpenTelemetry no código-fonte da aplicação para que ela possa gerar e coletar dados de telemetria, como métricas, logs e traces.

2. Coleta de dados: Uma vez que a aplicação está instrumentada, ela começa a gerar dados de telemetria durante sua execução. Por exemplo, métricas são registradas conforme eventos relevantes ocorrem, logs são gerados para registrar informações específicas e traces são capturados para acompanhar o fluxo das transações através da aplicação.

3. Collector: Os dados de telemetria gerados pela aplicação são enviados para o Collector do OpenTelemetry. O Collector é responsável por receber, processar e encaminhar os dados para os destinos desejados, como sistemas de armazenamento de longo prazo (Prometheus etc.) ou plataformas de observabilidade (New Relic, Grafana Cloud, Datadog...).

4. Armazenamento: Por fim, os dados de telemetria são armazenados no banco de dados desejado ou sistema de armazenamento configurado. Isso permite que os dados sejam acessados posteriormente para análise, visualização, geração de relatórios e monitoramento contínuo do desempenho da aplicação.

• "Eaí, como tá indo?" Lauren chega perguntando enquanto toma um energético.

• "Tá andando. Percebi que não tem como ser simples explicando OpenTelemetry, não dá pra falar de um ponto sem falar de outro e outro. Que você tá tomando? Vish, esse negócio vai te dar um treco qualquer hora." comenta Sofia.

• "Antes isso do que participar de mais uma reunião de orçamento da área" resmunga Lauren.

• "Vida de techlead é isso aí" responde Sofia. "Vou escrever mais um pouco sobre SDKs e Exporters e finalizo aqui, chega, quer se aprofundar vai acompanhar o Dose de Telemetria."

• "Fechou, terminando me avisa que vamos almoçar, esse energético já tá me dando azia..." resmunga Lauren mais uma vez.

• "Yes ma'am!" responde Sofia.

Falamos sobre o que é OpenTelemetry, seu propósito e de onde veio. Agora vamos falar sobre alguns de seus componentes que ainda não citamos.

SDKs & Exporters

No contexto do OpenTelemetry, os SDKs (Software Development Kits) são conjuntos de ferramentas e bibliotecas que permitem às pessoas desenvolvedoras instrumentar suas aplicações para a coleta de dados de telemetria, como métricas, logs e traces. Esses SDKs são projetados para diferentes linguagens e fornecem uma API consistente e fácil de usar para integrar a instrumentação diretamente no código das aplicações. Tecnicamente, a instrumentação é feita com a OpenTelemetry API. O SDK define o comportamento de como os dados são capturados e reportados (span processors, exporters etc. são parte do SDK).

Eles incluem funcionalidades para capturar eventos relevantes, registrar informações específicas e rastrear o fluxo das transações através da aplicação, garantindo que os dados necessários para monitoramento e análise sejam coletados de forma eficaz.

Por outro lado, os Exporters enviam os dados para um backend, seja ele de código aberto ou comercial, com base nas especificações do usuário. O receiver define como os dados são coletados, seja enviando para o Collector em intervalos regulares ou buscando-os apenas quando consultados. O processor realiza operações intermediárias que preparam os dados para exportação, como agrupamento e adição de metadados.

Mas Sofia, consigo instalar isso daí no meu serviço Java?

Sim.

E no meu .NET bonitão aqui?

Também.

Com o crescimento (acelerado) do projeto, mais e mais linguagens e diversas automações estão sendo criadas e atualizadas pelos colaboradores. A ideia é deixar tudo cada vez mais simples, prático e rápido, da instrumentação à visualização dos dados. Para que as pessoas usuárias continuem usando seus diversos serviços para visualização, o OpenTelemetry é vendor neutral.

• "Medíocre, mas serve." diz Lauren olhando com desdém para a documentação.

• "Medíocre!?" grita Sofia. "Tô aqui escrevendo esse negócio desde cedo pra receber um 'medíocre', te contar viu..." reclama ela.

• "É zueira haha. Vamo logo que a fome bateu e eu pago." diz Lauren se levantando da cadeira e indo em direção à saída do escritório.

Fontes:

• https://opentelemetry.io/docs/

• https://dosedetelemetria.com/

• https://cloud.google.com/learn/what-is-opentelemetry?hl=pt-br

• https://www.cncf.io/blog/2022/04/22/opentelemetry-and-python-a-complete-instrumentation-guide/

Agradecimentos ao Juraci Paixão Kröhling pela revisão.

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.