Um texto bem direto sobre Open Telemetry
Olá!
No texto de hoje, vou resumir alguns conceitos e o estado atual das bibliotecas estado da arte em telemetria open source.
Conceitos fundamentais
Observabilidade nada mais é do que a capacidade de entender e monitorar o comportamento interno de um sistema em execução. Isso é alcançado por meio de diferentes ferramentas e práticas, incluindo logs, métricas de negócio e tracing.
Os logs são registros de eventos relevantes que ocorrem no sistema e são cruciais para a resolução de problemas e análises posteriores. No entanto, manter logs por um período excessivo pode ter custos associados, então é importante determinar a duração ideal de retenção. Nas empresas que trabalhei, geralmente de 1 a 3 meses era o suficiente para a maioria dos casos.
Métricas de negócio são indicadores vitais que fornecem informações sobre o desempenho do sistema e variam por domínio de negócio. Ex: um serviço de pedidos pode estar no ar funcionando corretamente, mas, estar com uma quantidade alta de pedidos sendo cancelados porque o provider de pagamentos caiu (cenário muito comum, inclusive).
Tracing, por sua vez, permite rastrear a execução de uma solicitação através de múltiplos componentes distribuídos, identificando onde ocorreu um erro específico no código.
Os blocos de execução em tracing são denominados Spans e sua análise ajuda a identificar hotspots e problemas de desempenho.
Para ilustrar melhor, repare na imagem abaixo. Na parte da esquerda da imagem, é representado um fluxo de chamadas entre sistemas. Um evento ocorre no sistema A, que por sua vez, faz uma chamada para o sistema B, que chama os sistemas C e D. Após o retorno do sistema B para o sistema A, o mesmo chama o sistema E.
Apesar de parecer complexo, esse é um cenário comum quando lidamos com sistemas distribuídos.
Juntando esses dados de telemetria em um lugar só, temos a representação visual a direita da imagem.
Em uma ferramenta de Aplication Performance Monitoring (APM), como Datadog e NewRelic, você veria algo como isso:
Open Telemetry
O OpenTelemetry (OTEL) é um framework que padroniza a instrumentação de aplicações para coleta de dados. Ele é opinativo sobre vários pontos, como tracing e logs. Porém, a grande sacada é a ausência de vendor lock-in. Ou seja, você não precisa ficar amarrado(a) a uma aplicação de APM senão quiser, dá para usar opções abertas como o Jaeger ou o Prometheus.
Os componentes do OTEL incluem uma especificação para dados, SDKs e APIs para instrumentação, um collector para coletar dados e um pipeline para transformação e envio desses dados a algum destino, seja on-premise ou cloud.
A imagem abaixo ilustra os principais componentes:
Em todas as etapas, é possível customizar a operação para que opere da forma que o seu ecossistema demanda.
A grosso modo, temos o seguinte modos de operação possíveis:
Sem collector: onde as bibliotecas do OTEL se comunicam diretamente com os fornecedores de serviços. Ex: sua aplicação bate direto na API do Datadog.
Collector Agent: atua como intermediário entre a aplicação e os fornecedores. Na prática, é um sidecar que fica rodando junto com os containers da sua aplicação. É possível usar o próprio agent do vendor (exemplo do Datadog) ou até mesmo usar a alternativa open source, chamada Zipkin.
Collector Server: Recebe dados das aplicações e os encaminha para um pipeline de processamento antes de exportar para os fornecedores. Basicamente, é muito similar a processos de analytics/mapReduce, no qual dados de série temporais são tratados e agrupados antes de irem parar nos seus destinos finais.
Instrumentação
Esse conceito se refere a configuração na aplicação em si, que pode ser automática (caso a linguagem suporte isso), ou manual, onde os dados de telemetria precisam ser mandados de forma explicita pela pessoa desenvolvedora.
No momento que escrevo esse artigo (março de 2024), o estado atual de linguagens e features suportadas pela OTEL são os seguintes:
Linguagens como C# e Java possuem suporte ao modo automático devido a possibilidade de obter informações do runtime da VM na qual elas rodam. Geralmente, o suporte de ferramentas de monitoramento acaba sendo mais simples nesse tipo de ecossistema. Nos demais, você sempre acaba tendo que fazer uma ou outra instrumentação manual.
Por fim, caso você queira acompanhar o desenvolvimento do projeto, esse é o repositório oficial.
Se você quiser mudar os destinos dos dados de telemetria para algo específico para o seu ambiente, vale dar uma olhada nos repos para ver se já não existe uma implementação de collector específica para o seu cenário, ao invés de desenvolver integrações. Isso está disponível nesse repo aqui.
Espero que esse texto tenha sido útil para você de alguma forma.
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
