OpenTelemetry em 2023

• O OpenTelemetry, que começou em 2019 com a fusão do OpenTracing e do OpenCensus, consolidou-se em quatro anos como um padrão de observabilidade que abrange traces, métricas e logs
• Sua estrutura central se divide em especificação e implementações, oferecendo ao mesmo tempo o critério de compatibilidade entre vendors e as ferramentas reais de instrumentação e coleta
• Na especificação do OTEL, tracing se estabilizou em 2020, métricas em 2021 e logs em 2023, fazendo com que todos os sinais estejam stable, embora o suporte a logs ainda varie entre os SDKs
• OTLP e o Collector são a base para enviar e processar dados de observabilidade em um formato comum, e agentes de vendors como Grafana e Datadog também implementam isso
• O OTEL ampliou seu escopo para Collector, Semantic Conventions, OpAMP, OTTL e Demo, expandindo-se como uma base comum de observabilidade neutra em relação a vendors

---

A posição atual do OpenTelemetry

• OpenTelemetry, abreviado como OTEL, começou em 2019 com a união do OpenTracing e do OpenCensus
• No início, era um projeto centrado em tracing, mas após a fusão seu escopo se ampliou para toda a observabilidade
• O objetivo é ajudar organizações a fornecer telemetria de alta qualidade, universal e portátil
• Após quatro anos, o OTEL passou a contar com a seguinte base
  • padrões estáveis para métricas, logs e traces
  • um Collector capaz de receber, processar e exportar telemetria em qualquer ambiente
  • SDKs que suportam instrumentação de código nas principais linguagens
  • padrões adicionais relacionados a Semantic Conventions e gerenciamento de agentes
• Atualmente, o OTEL é o projeto mais ativo da CNCF depois do Kubernetes, com contribuidores distribuídos entre os principais vendors de observabilidade, e seu protocolo foi adotado de forma quase universal entre provedores de observabilidade

A estrutura do OTEL dividida entre especificação e implementações

• O OTEL é composto principalmente por especificação (specification) e implementações (implementation)
• A especificação define como capturar, coletar, processar e exportar telemetria
  • Ela funciona como um padrão comum que vendors precisam seguir para serem compatíveis com o OTEL
• As implementações são bibliotecas cliente e ferramentas que lidam com dados de telemetria
  • É a parte com a qual o usuário final tem contato direto ao instrumentar código
• A estabilidade do projeto normalmente é indicada por sinal
  • No OTEL, sinal significa um tipo de dado de telemetria, como métricas, logs e traces
• Os principais subprojetos são os seguintes
  • OpenTelemetry Specification
  • OpenTelemetry SDKs
  • OpenTelemetry Protocol
  • OpenTelemetry Collector
  • Open Agent Management Protocol
  • OpenTelemetry Semantic Conventions

OpenTelemetry Specification 1.24.0

• OpenTelemetry Specification é a base do OTEL e fornece a API, o SDK e o modelo de dados que sustentam os demais padrões do OTEL
• A estabilização ocorreu por sinal
  • setembro de 2020: tracing stable
  • novembro de 2021: métricas stable
  • abril de 2023: logs stable
• Atualmente, a especificação do OTEL está stable em todos os sinais
• Como o sinal de logs só se estabilizou em 2023, muitos SDKs do OTEL ainda não oferecem suporte a logs

OpenTelemetry SDK e instrumentação automática

• O OTEL SDK fornece instrumentação no lado do cliente com base na especificação do OTEL
• Em cada SDK por linguagem, o nível de maturidade existe separadamente para os sinais de métricas, logs e traces
• Alguns SDKs suportam instrumentação automática (auto instrumentation) dependendo da linguagem de programação
  • Instrumentação automática é a forma pela qual o SDK injeta sinais, principalmente traces, automaticamente no código da aplicação, reduzindo a carga da instrumentação manual
• Em linguagens compiladas como go e rust, a instrumentação automática não funciona
• Ainda assim, fora do SDK é possível obter injeção automática de traces com ferramentas baseadas em eBPF ou service mesh

OTLP 1.0 e o padrão de transporte de dados

• OTLP é um protocolo de transporte comum para enviar dados de observabilidade
• Existem duas formas oficiais de transporte
  • HTTP e Protocol Buffers
  • gRPC
• Essa especificação é considerada stable e pode ser implementada por qualquer serviço que receba, processe e exporte dados do OTEL
• O OTLP é implementado pelo OpenTelemetry Collector, e agentes de vendors de observabilidade como Grafana e Datadog também o implementam

OpenTelemetry Collector 0.83.0

• O OTEL Collector é um agente neutro em relação a vendors que coleta, transforma e envia dados de observabilidade
• O Collector é composto pelos seguintes elementos
  • receivers: recebem dados de várias fontes nos modos push/pull
  • processors: transformam, filtram, enriquecem e derivam dados em trânsito
  • exporters: enviam dados para destinos downstream
  • connectors: funcionam como receiver e exporter ao mesmo tempo, conectando vários pipelines
  • pipelines: cadeias formadas por receiver, zero ou mais processors e exporter
  • extensions: fornecem funções fora do processamento de telemetria, como basic auth e health check
• Juntos, esses componentes operam como um pipeline de observabilidade, permitindo coletar telemetria de qualquer origem, processá-la em trânsito e enviá-la ao destino desejado
• O Collector se divide em dois projetos
  • otel-collector: inclui apenas os componentes centrais do Collector e contém principalmente a lógica diretamente relacionada ao processamento de dados OTLP
  • otel-collector-contrib: é um conjunto integrado que inclui exporters e receivers para a maioria dos provedores de observabilidade
• No momento da escrita, o otel-collector-contrib inclui 91 receivers, 48 exporters e 24 processors
• Recomenda-se que o usuário final use o OpenTelemetry Collector Builder para criar uma build customizada do otel-collector-contrib contendo apenas os componentes necessários
• Vendors como AWS e Splunk também oferecem suas próprias distribuições do OTEL

OpAMP e o gerenciamento remoto de agentes

• OpAMP é um protocolo de rede para gerenciamento remoto de agentes
• É um padrão relativamente novo, adicionado ao OTEL em 2022, que oferece uma forma neutra em relação a vendors de controlar um conjunto de agentes
• O alvo do gerenciamento pode ser uma instância do otel-collector ou um agente proprietário de vendor que implemente OpAMP
• Com o OpAMP, é possível habilitar os seguintes recursos
  • distribuição dinâmica de configuração
  • atualização de agentes
  • gerenciamento de credenciais
• Atualmente, a implementação em Go da especificação OpAMP está em andamento

Semantic Conventions e projetos adicionais

• As OTEL Semantic Conventions definem um conjunto comum de atributos usado em dados de observabilidade
• O escopo de aplicação inclui recursos de nuvem, bancos de dados, exceções e sistemas
• As Semantic Conventions são usadas pelos SDKs do OTEL e, nos SDKs com suporte a instrumentação automática, são aplicadas automaticamente
• Uma semântica comum permite correlacionar diferentes sinais entre si
• Outros componentes importantes do OTEL também existem separadamente
  • OpenTelemetry Transformation Language (OTTL): uma linguagem comum de transformação para telemetria, com desempenho e flexibilidade, projetada e implementada no otel-collector-contrib
  • OTEL Demo: um site de compras baseado em microsserviços que demonstra os recursos do OTEL e a maioria dos SDKs de linguagem

As mudanças em quatro anos

• O OTEL evoluiu da fusão de especificações concorrentes de tracing para um padrão da indústria de observabilidade
• Os últimos quatro anos foram um período de construção de uma base comum entre vendors e ferramentas

[GN⁺]

Opiniões no Hacker News

• Há dois problemas com o OpenTelemetry

  1. Sua identidade não é clara. Fica ambíguo se é um padrão semântico, um protocolo, uma fachada, uma biblioteca ou que camada de abstração ele oferece, e a resposta parece ser quase “tudo isso”
  2. Parece que ninguém do lado do OpenTelemetry de fato instrumentou uma biblioteca. Também não há recomendações sobre como quem instrumenta deve usar métricas, traces e logs, ou se deve usar os três ou apenas um. Perguntei há 2 anos, mas não recebi resposta: https://github.com/open-telemetry/opentelemetry-specificatio...
  • Concordo. É como receber uma pia e uma casa anexada a ela de uma vez só, então a documentação acaba ficando rasa e confusa
    De forma parecida, eu queria implementar um heartbeat simples para entender o uso em um app desktop, mas, considerando o nome do projeto, foi surpreendentemente quase impossível. Como houve pouca reação às perguntas, desisti completamente dos planos com OpenTelemetry: https://github.com/open-telemetry/community/discussions/1598, https://github.com/open-telemetry/semantic-conventions/issue...
  • Concordo. Algumas coisas que o OpenTelemetry recomenda são impossíveis com o SDK real
    Por exemplo, não dá para definir buckets perto do local onde se define um histograma. É preciso passar para algum lugar como um exportador global uma lista de “overrides” que mapeia nomes de histogramas para buckets. Se houver uma biblioteca emitindo métricas, isso fica muito bagunçado: https://github.com/open-telemetry/opentelemetry-go/issues/38...
  • São boas perguntas, mas não acho que sejam muito importantes. Esse tipo de pergunta é difícil de responder com clareza na área de observabilidade, seja no OpenTelemetry ou em outro sistema proprietário
    Mesmo olhando os sites das empresas líderes de observabilidade, os textos sobre instrumentação customizada têm umas 4 páginas e cobrem apenas o básico. O OTel não está particularmente atrasado; a resposta, em geral, é algo como “depende da situação”. Com mais experiência acumulada, dá para resolver esses pontos que são confusos para iniciantes
  • O necessário era algo como manter 3 arquivos de esquema JSON
  • A terceira pergunta é se há extensibilidade

• Gosto muito do OpenTelemetry e quero rastrear quase todos os spans. Se tivesse usado algum fornecedor, teria ido à falência por causa do custo
  Adicionei OpenTelemetry com quase nenhum esforço usando instrumentação automática em Java, e envio para um ClickHouse auto-hospedado, armazenando mais de 700 milhões de spans por dia em uma EC2 de 100 dólares: https://clickhouse.com/blog/how-we-used-clickhouse-to-store-...

  • Em um pequeno projeto pessoal, estou enviando traces/logs/métricas para o ClickHouse via SigNoz. São cerca de 400 mil a 800 mil spans por dia (https://i.imgur.com/s0J6Mzo.png); em uma única t4g.small, a CPU costuma ficar em 11% e o IOPS em 4%
    Com retenção de traces por 1 mês, signoz_index_v2 tem 26,9 milhões de linhas e 17.06GiB, trace_log tem 123 milhões de linhas e 2.64GiB, e samples_v2 tem 949 milhões de linhas e cerca de 345MiB, com boa taxa de compressão. Se eu usasse uma máquina ClickHouse com a configuração recomendada, teria reduzido o tempo de tuning, mas mesmo assim funciona bem
    As desvantagens são que o IOPS do pequeno disco sc1 é por volta de 4, então o ClickHouse leva uns 5 minutos para iniciar, e a UI do SigNoz tem funcionalidades suficientes, mas é difícil esperar o mesmo nível de polish do Datadog
  • É preciso definir uma taxa de amostragem, mas garantir que todos os erros sejam enviados
    No meu emprego anterior, coletávamos apenas 5% dos traces sem erro
  • Realisticamente, a maioria não quer operar seu próprio armazenamento ClickHouse, e nem todo engenheiro lida com SQL de forma tão eficiente quanto com código. Ainda assim, é uma configuração bem legal
  • Também é legal o fato de ter exigido pouco esforço de configuração. É a combinação instrumentação automática em Java + exportador ClickHouse + plugin ClickHouse do Grafana

• Fiquei bastante decepcionado com o OpenTelemetry. Pela minha experiência, é um amontoado confuso e superprojetado, e a experiência básica de uso é muito hostil ao usuário
  Ele se promove como um formato universal de tracing/métricas/logs e como um conjunto de bibliotecas plug-and-play com adaptadores para tudo o que é necessário, mas, na prática, é mais próximo de um conjunto de bibliotecas inacabadas, em que muitos detalhes de implementação interna vazam, a qualidade dos adaptadores é ruim e não há tantos recursos assim

  • Concordo. Toda vez que uso o SDK, sinto que preciso pensar de uma forma ortogonal ao senso comum. Nada se comporta como eu espero, tudo tem três camadas de abstrações desnecessárias, e é preciso entrar pela porta dos fundos
    Muitos recursos vêm com ressalvas do tipo quando, onde, quanto, em que fase da lua, quando Júpiter está visível no céu e qual deve ser o tamanho da string para que funcionem
    Ainda assim, se você ignorar as APIs vazadas do SDK e os recursos implementados pela metade, a promessa de substituibilidade é cumprida em alguma medida. Antes do OTel, tudo era uma stack proprietária, mas agora dá para conectar outro backend de logging a um SDK padrão e esperar que funcione em geral. É pior do que uma stack verticalmente integrada, mas, do ponto de vista de arquitetura, é uma vitória parcial, porque permite competição e evolução por partes sem precisar trocar toda a stack de observabilidade
  • Passei pela mesma dor, mas alternativas que dizem ser melhores por terem uma especificação OpenAPI também não são muito melhores quando você as usa: https://github.com/openzipkin/zipkin-api-example
    O exemplo só mostra como analisar a especificação OpenAPI (https://github.com/openzipkin/zipkin-api/blob/master/zipkin2...) com uma ferramenta swagger, gerar automaticamente código de cola em Go e então registrar traces chamando uma função gerada automaticamente
    Não havia documentação nem outros exemplos, então fiquei me perguntando se alguém realmente usa essa abordagem, e no fim acabei usando diretamente a API do serviço (https://zipkin.io/zipkin-api/#/) por chamadas REST. O OTel é doloroso, mas as alternativas não são melhores. Como medir SLOs e SLIs está ficando cada vez mais importante, espero que essa área receba mais atenção
  • Nesse caso, fico curioso se dá para recomendar uma alternativa ou se é melhor simplesmente aguentar o OTel
  • Seria bom ouvir experiências concretas e sugestões de melhoria

• As bibliotecas oficiais do OTel ainda não funcionam bem no front-end web. Por exemplo, no estado padrão não há como associar erros a source maps
  O coletor para navegador web distribuído pelo projeto OTel usa Zone.js para interceptar como contexto quase tudo no navegador. Se você já usou Angular moderno, sabe que Zone.js às vezes pode ser bem doloroso e pode mexer em globais, criando comportamentos difíceis de prever
  Também não conheço um padrão OTel para coisas como session replay. Muitas plataformas de telemetria, como Sentry, Rollbar e DataDog, dão suporte a isso. As equipes de backend parecem gostar bastante, e eu gosto da característica dos spans de atravessarem fronteiras, permitindo acompanhar o sistema inteiro com uma tag única. Dito isso, o payload gerado às vezes é muito verboso, e algumas plataformas de logging são mais compactas. Na prática, não senti isso como um grande problema

  • Em ambientes com Promise nativa e async/await, parece que atualmente não há uma forma de implementar corretamente algo como Zone.js
    Também tentei instrumentar diretamente, mas era propenso a erros e verboso. O navegador realmente precisa de algo como https://nodejs.org/api/async_context.html#class-asynclocalst...
  • Na maioria das plataformas, o Otel pareceu mais um ponto de partida para criar uma boa biblioteca de instrumentação
    No nosso pacote, adicionamos session replay, rastreamento de exceções aprimorado etc. sobre a implementação do SDK de navegador Otel/Splunk. Infelizmente, essas coisas estão longe de vir prontas por padrão. Ainda assim, acho que poder conectar sessões de front-end a traces/logs de backend mudou bastante a experiência do desenvolvedor: https://www.hyperdx.io/blog/browser-based-distributed-tracin...
  • Esta documentação do Otel também vale a pena ver: https://opentelemetry.io/docs/instrumentation/js/getting-sta...
    Não resolve completamente o problema, mas serve como ponto de partida
  • O Real User Monitoring, instrumentação de front-end da DataDog, também não é visivelmente polido. Tem a delicadeza de mexer com blocos Duplo
    Fico curioso se alguém já conseguiu sequer começar com tracing no front-end
  • Fico curioso se você já viu o Grafana Faro. Dá para configurá-lo para enviar ao Grafana Agent, e o Grafana Agent é open source e pode armazenar traces em outro lugar

• Alguns colegas e eu tivemos uma ideia meio maluca de que não precisaríamos mais de logs. Em vez de mensagens de log, bastaria anexar eventos de span: https://opentelemetry.io/docs/instrumentation/ruby/manual/#a...
  Depois, registraríamos em log apenas o título do span e o link para o respectivo span no Jaeger. Só testei em projetos pessoais, mas pareceu bem bom; só gostaria que a UI do Jaeger desse suporte melhor a esse tipo de uso
  Na verdade, esses colegas até fizeram uma palestra sobre o tema. Se você estiver perto de Hannover, na Alemanha, procure por “Nie wieder Log-Files!” em https://javaforumnord.de/2023/programm/

  • Dependendo do quanto o projeto é greenfield, talvez você nem precise de eventos de span, a menos que só precise do timestamp de uma determinada operação e não da sua duração
    Usar spans para todas as operações significativas é parecido com usar logs estruturados mais poderosos. É difícil em muitos sistemas que precisam manter os logs existentes junto, mas, se for greenfield o suficiente, eu recomendo
  • Eu também pensei nessa abordagem, mas gosto do fato de que dá para ter uma noção geral do que está acontecendo com ferramentas simples
    Para usar traces, muita coisa precisa funcionar corretamente. Ou talvez eu ainda não tenha experiência suficiente e as ferramentas me assustem
  • Essa era a ideia do projeto Veneur da Stripe. Tratar spans, logs e métricas no mesmo formato e fazer rollup “automaticamente” da cardinalidade conforme necessário
    Quando vi a apresentação há alguns anos, achei legal, mas imaginei que seria muito difícil convencer desenvolvedores que não são SREs: https://github.com/stripe/veneur
  • Você nem precisa enviar os traces para algum lugar. Pode mantê-los dentro do processo e criar uma API sobre esses dados de trace em memória
  • Estamos dizendo a mesma coisa na empresa. Faz bastante sentido, e acho que dá para praticamente eliminar os logs

• O OpenTelemetry é um projeto movido por marketing, projetado de forma ingênua e ineficiente por comitê, e parece ter como principal objetivo permitir que CTOs da Fortune X00 marquem uma caixinha em documentos de roadmap estratégico
  Não é algo que alguém com escolha deva usar

  • Os outros comentários nesta thread são em geral favoráveis ou muito positivos; eu gostaria de ouvir com mais detalhes o que exatamente é ruim
  • Como fundador da highlight.io, do ponto de vista de consumidor, vi muito valor no OTEL. Usamos para expandir o suporte a linguagens para vários clientes, e a comunidade foi muito receptiva
    Aqui está um exemplo de mudança que enviamos: https://github.com/open-telemetry/opentelemetry-js/pull/4049
    Gostaria que você compartilhasse os motivos pelos quais acha que ninguém deveria usar
  • Acho que essa avaliação não está correta. Parece mais algo como “softwares open source emitem métricas do Prometheus e traces do Jaeger, e nós queremos vender um produto proprietário que seja uma alternativa a isso, sem ter que enviar patches para todos os projetos”
    A Datadog de fato alocou muita gente para adicionar suporte à Datadog em projetos OSS. Entrar em codebases desconhecidas é uma habilidade poderosa, então talvez tenha sido uma boa experiência no começo da carreira
    O OTel faz projetos open source usarem uma camada de abstração, permitindo que usuários comprem em vez de fazerem self-hosting. Não adoro isso, mas, para serviços operados por pessoas de fora da empresa, agora eu provavelmente consideraria OTel. Porque, se algum usuário quiser usar Datadog, não estaremos atrapalhando
    Quando usei o OTel bem no início, fiquei decepcionado porque a API em Go era muito ineficiente. Para incrementar um contador era necessário um context.Context, e as abstrações também vazavam, como não haver uma forma de configurar buckets de histograma ao exportar para Prometheus. Imagino que isso já tenha sido corrigido
  • É duro demais. Acho que o modelo de dados é um avanço na direção certa
    O processador também é bem capaz, e o conjunto contrib de receivers e exporters é, em geral, bom. Não estou dizendo que é a melhor solução — depende do caso de uso —, mas uma crítica tão forte não me parece justificável. Para referência, faço parte da equipe de mantenedores do fluent-bit
  • É ótimo poder fazer os serviços falarem OTLP e simplificar a configuração da aplicação para enviar dados ao coletor OTEL
    Do ponto de vista operacional, dá para impor filtragem centralmente sobre qualquer observabilidade que os desenvolvedores adicionem ao código, e também basta haver um único ponto de entrada central com o qual a aplicação conversa
    Como tudo exporta OTLP, quando quiser migrar para um novo backend basta alterar um arquivo YAML, sem precisar reescrever a aplicação para dar suporte a um novo backend de logs. Mesmo com suas falhas, eu continuaria usando OTEL 10 vezes em 10, em vez de voltar ao jeito antigo de usar bibliotecas de log específicas de cada fornecedor

• Eu realmente odeio o popup de assinatura desse blog. Não há um botão x, então não fica nada claro que dá para fechá-lo sem fornecer o e-mail
  Abaixo do botão de assinar há um “continue reading” muito pouco intuitivo; eu não imaginei que aquilo fosse funcionar, e clicar fora também não fechava. Esse tipo de coisa precisa melhorar
  Sobre OpenTelemetry, há muito tempo quero testar se ele oferece todos os recursos necessários para enviar dados ao Datadog. Mas, se além das funções básicas ainda for preciso usar o agente da Datadog, isso significa mais uma coisa para gerenciar e ensinar, então fico em dúvida
  Tenho curiosidade para saber se alguém já integrou de fato com a Datadog. O objetivo não é necessariamente continuar preso à Datadog, mas como hoje muitos dos nossos alertas e logs estão lá, se migrarmos primeiro para OpenTelemetry, em teoria poderemos mudar para outra coisa depois

  • Esse popup é um recurso do medium.com. Concordo que é muito irritante
  • Pessoalmente, achei a enquete pior. Ela pediu minha opinião, cliquei em uma opção e fui recompensado com uma tela cheia de criação de conta
    Apertei voltar e acabei voltando para o HN

• Fico me perguntando se ainda existe algum front-end que não corroa significativamente o fluxo de receita em termos de custos de pessoal, infraestrutura e licenças
  Recebendo mais de 2.000 requisições por segundo, só manter logs já é caro

  • Se ainda não fazem isso, recomendo amostragem de traces. O Datadog APM não me impressionou, porque não tem uma configuração barata
    Rodamos nossa própria stack Jaeger com amostragem de 0,1%, e o custo é desprezível em comparação com o Datadog APM
    Para métricas e logs, amostragem não é muito útil, então não há uma boa resposta. Se a margem bruta da Datadog é de 80%, no máximo 20% do que você paga é custo de infraestrutura; e, se o custo de mão de obra for menor que esses 80%, dá para reduzir muito os gastos operando por conta própria uma stack open source. Mesmo usando Datadog, fazemos a cada 3 meses um projeto para reduzir o uso, então, de qualquer forma, é algo que precisa ser cuidado continuamente
  • A resposta é amostragem. Basta amostrar 1% das requisições bem-sucedidas e coletar todos os erros
    O custo também é um problema, mas você pode se surpreender com o quanto a observabilidade pesa no serviço mais do que se imagina. Usa bastante CPU
  • É preciso definir o critério de “significativamente”. Na empresa anterior, roteávamos traces para o Cassandra e os armazenávamos em um domínio do AWS Elasticsearch, visualizando com o Jaeger
    Também escrevi algumas consultas do Elasticsearch para criar relatórios básicos que encontrassem queries lentas. Seguindo tutoriais de OTEL/Jaeger, é uma configuração bem padrão
    Os traces ficavam na casa de algumas centenas por segundo, e coletávamos tudo sem downsampling. A retenção podia ser configurada para 7 dias e, quando saí, quase não havia otimização real. Acho que o custo mensal ficava na faixa de dezenas a centenas de dólares
    É possível definir o comportamento do amostrador de tracing por variáveis de ambiente configuráveis no contêiner. Veja OTEL_TRACES_SAMPLER na documentação: https://opentelemetry.io/docs/specs/otel/configuration/sdk-e...
  • A maioria dos fornecedores de observabilidade agora oferece suporte a OTEL. O projeto OSS do qual participo também dá suporte à coleta OTEL: https://github.com/grafana/tempo/
  • Não sei por que isso está recebendo downvotes. Também passamos pela mesma dor, só que em uma escala de 500 mil requisições por segundo
    Atualmente usamos Datadog, mas todo mundo sabe que é caro demais

• A maior parte desta thread fala sobre enviar métricas/logs via OpenTelemetry para jobs de collectors auto-hospedados
  Usar uma biblioteca padrão, compatível com várias ferramentas de collector como ClickHouse, já é útil por si só, mas outro benefício é que a especificação permite propagar IDs de trace através das fronteiras do sistema
  Se você e suas dependências implementarem a especificação OpenTelemetry, poderá obter spans que mostram em detalhes o que aconteceu ao longo do percurso. Por exemplo, dá para saber se o carregamento de uma página demorou porque o banco de dados precisou carregar uma página do disco, ou se um span do plano de metadados de um serviço de nuvem foi a causa da alta latência

• Estou muito satisfeito com o avanço do OpenTelemetry. Alguns anos atrás, quando forcei sua adoção, os desenvolvedores hesitaram dizendo que era algo novo e desconhecido; mas, quando olhei de novo há um ano, o OpenTelemetry já estava por toda parte nos nossos sistemas, e os fornecedores de logs/rastreabilidade que usamos também estavam migrando para ele