Consegui fazer o OpenTelemetry funcionar, mas por que foi tão complicado?

• OpenTelemetry (OTel) é um framework e conjunto de ferramentas de observabilidade
• As ferramentas existentes incluem Prometheus (métricas), Logstash (logs) e OpenTracing (rastreamento distribuído)
• O OTel padroniza três sinais — métricas, logs e rastreamentos — e fornece OpenTelemetry Protocol (OTLP), OpenTelemetry Collector e SDKs para várias linguagens
  • Atende a todos os jargões da moda: open source, independente de fornecedor, independente de linguagem, distribuído, zero-code etc.

Problemas do OTel

• Logs e métricas são semelhantes às ferramentas existentes, então podem ser integrados com facilidade. Dá para migrar para OTel apenas adicionando configuração
• A dificuldade está em implementar rastreamento
  • Context Propagation: necessário para transmitir informações da requisição entre sistemas distribuídos
    • A unidade de requisição é dividida em Trace e Span
    • Exemplo: clique no botão “Comprar” → Frontend → Backend → relação entre os serviços de Payment/Shipping representada como spans
  • Como o OTel oferece suporte:
    • Fornece vários padrões de Context Propagation (ex.: b3, W3C Trace Context)
  • O OTel precisa suportar vários padrões
    • Ao migrar do OpenTracing existente para OTel, ocorrem conflitos inesperados
    • O Lightbend Telemetry oferece suporte a logs e métricas do OpenTelemetry, mas não a rastreamento.

Problema de conflito entre APIs

Problema de integração entre Spring e Akka

• Spring: usado para bootstrap da aplicação e gerenciamento de configuração
• Akka: usado para event sourcing, agendamento, clustering etc.
• Problema:
  • Ao usar OTel, as APIs de rastreamento do Spring e do Akka não interagem entre si
  • Não conseguem compartilhar o mesmo Trace ID → resultado de rastreamento incorreto

Solução: OpenTracing Shim

• Ferramenta que converte um OTel Tracer em um OpenTracing Tracer
• Problema:
  • O Lightbend Telemetry do Akka não consegue se adequar à implementação do OpenTracing
  • Jaeger e OTel exigem SpanContext diferentes, gerando conflito

Processo de resolução

Integração manual entre OTel e OpenTracing

• Conversão manual do OTel Context em Jaeger SpanContext:
  • Inserir o contexto do OTel em um Java Map
  • Extrair esse mapa no Jaeger SpanContext e configurá-lo manualmente
• Exemplo de código:

  var otelContext = new HashMap<>();  
  GlobalOpenTelemetry.get().getPropagators().getTextMapPropagator()  
      .inject(Context.current(), otelContext, (carrier, key, value) -> carrier.put(key, value));  
  var openTracingContext = new TextMapCodec(false).extract(new TextMapAdapter(otelContext));  
  GlobalExtendedTracer.get().local().activateContext(openTracingContext);  
  

• Resultado:
  • Sucesso na integração dos dados de rastreamento entre Spring e Akka
  • Os traces entre fronteiras HTTP passaram a se conectar corretamente

Conclusão

Causa da complexidade

• Tentativa de integrar duas bibliotecas de rastreamento diferentes
• Os padrões fornecidos pelo OpenTelemetry são úteis, mas há possibilidade de conflito com ferramentas existentes

Valor do OpenTelemetry

• O OpenTelemetry desempenha um papel importante na padronização da observabilidade
• É um projeto open source complexo, mas poderoso

Próximos desafios

• É necessário verificar se o Trace Context do Akka está sendo propagado corretamente entre threads
• Testes adicionais e feedback são essenciais para melhorar o projeto

[GN⁺]

Comentários no Hacker News

• Enquanto aprendia e fazia o port de Otel, parecia que eu tinha voltado ao mundo Java. Explorar o código dava uma sensação de EnterpriseFizzBuzz, e a capacidade de descoberta era praticamente inexistente. No NodeJS, o uso de CPU era cerca de 4 vezes maior do que com StatsD, e isso foi reduzido com agregação própria. OTEL é hostil a linguagens que usam um processo por núcleo. É melhor usar Prometheus.

• O Otel pode parecer complexo por causa dos SDKs, agentes e APIs oferecidos por vários fornecedores de observabilidade. OpenTelemetry acabou sendo adotado como padrão, e elogio a Grafana por ter adotado OpenTelemetry. O preço da Datadog saiu do controle na faixa entre empresas de médio porte e grandes empresas. A documentação poderia ser melhor, e os documentos de onboarding diferem entre linguagens de programação. Criei um pacote para começar rapidamente com OpenTelemetry na stack NodeJS/Typescript e um exemplo de stack Grafana.

• Eu queria suporte a logs, tracing e métricas no desenvolvimento local, mas não queria rodar várias imagens Docker. A equipe do .NET lançou o .NET Aspire, e ele permite visualizar tudo facilmente na stack local de desenvolvimento. Ao fazer deploy em k8s, basta apontar o endpoint do OTEL para o agente da DataDog e tudo funciona. Evito as bibliotecas e SDKs proprietários de tracing da DataDog e uso OTEL.

• OpenTelemetry pode ser complexo dependendo da necessidade. Nossa equipe usa de forma simples e escolhe com cuidado o que observar por meio de instrumentação manual. Usamos dois backends: um serviço terceirizado barato e uma instalação do Jaeger para desenvolvimento local.

• Ao usar Otel em Python, é melhor usar o cliente do Logfire. O cliente feito pela equipe do Pydantic é muito melhor e mais simples do que a biblioteca oficial do Otel.

• Muitos frameworks web cuidam automaticamente da maior parte da instrumentação. Se você usar opentelemetry-js e hospedar por conta própria algo como o Signoz, dá para obter muitos dados em menos de uma hora.

• Para facilitar a adoção do OpenTelemetry, iniciei um projeto open source que pode ser executado com um único comando.

• Em Python, se você usar a stack padrão, dá para rastrear tudo automaticamente com apenas alguns imports. Otel é complexo porque foi projetado para empresas que vendem software compatível com Otel.

• OpenTelemetry começou com tracing, mas é melhor deixar métricas e logs para soluções especializadas. A tentativa de colocar tudo sob o mesmo guarda-chuva parece um problema de "abstração vazando". Bancos de dados SQL também conseguem fazer tudo ao mesmo tempo, mas isso não significa que devam.