--- title: "Finalmente fizeram as pazes. Prometheus e OpenTelemetry agora trabalham juntos sem gambiarra" author: "Gabriela P. Torres" date: "2026-02-20 11:28:00-03" category: "Tecnologia & Desenvolvimento" url: "http://desbugados.scale.press/portal/desbugados/post/2026/02/20/finalmente-fizeram-as-pazes-prometheus-e-opentelemetry-agora-trabalham-juntos-sem-gambiarra/md" --- ## O Cenário do Crime: Por que Prometheus e OpenTelemetry Não se Bicavam? A premissa sempre foi lógica: usar o Prometheus, o padrão ouro para métricas em Kubernetes, e complementá-lo com o OpenTelemetry (OTel) para obter traces distribuídos e logs. O resultado esperado? Uma pilha de observabilidade completa. O resultado real? Um campo minado de incompatibilidades. O bug não era uma opinião, era um fato técnico. A lógica era a seguinte: **SE** você tentasse enviar dados do OpenTelemetry para o Prometheus 2.0, **ENTÃO** você encontraria problemas de formato e nomenclatura, **SENÃO** você teria que usar conversores e adaptadores que adicionavam complexidade e pontos de falha. A raiz do problema residia em duas frentes principais: - **Diferenças de Protocolo:** O OpenTelemetry se comunica nativamente usando o OTLP (OpenTelemetry Protocol). O Prometheus, historicamente, operava em um modelo 'pull' com seu próprio formato de exposição. A comunicação entre eles exigia uma tradução, uma camada extra de processamento. - **Convenções de Nomenclatura:** O Prometheus possuía restrições severas nos caracteres permitidos para nomes de métricas e rótulos. O OpenTelemetry, por outro lado, usa convenções semânticas mais flexíveis. Na prática, isso forçava a "sanitização" dos dados do OTel, uma gambiarra que frequentemente resultava em perda de contexto e dificultava a correlação de sinais. ## A Prova Concreta: O Que o Prometheus 3.0 Trouxe para a Mesa? O lançamento do Prometheus 3.0 não foi apenas uma atualização incremental; foi a evidência que encerrou o caso da incompatibilidade. A nova versão apresentou mudanças fundamentais que servem como provas irrefutáveis da nova aliança. ### Evidência A: Suporte Nativo à Ingestão de OTLP Este é o ponto crucial. Prometheus agora pode receber dados diretamente via OTLP, o "idioma" nativo do OpenTelemetry. **Desbugando:** Isso elimina a necessidade de componentes intermediários, como o OTel Collector com configurações complexas de exportação, apenas para traduzir formatos. A comunicação agora é direta, reduzindo a latência e a complexidade da arquitetura. **ASSERT(complexidade_reduzida) == TRUE.** ### Evidência B: Suporte Total a UTF-8 A segunda peça fundamental do quebra-cabeça. O suporte a UTF-8 permite que nomes de métricas e rótulos no Prometheus contenham pontos, traços e outros símbolos antes proibidos. **Desbugando:** Isso significa que as convenções semânticas do OpenTelemetry para atributos agora são totalmente compatíveis. Um atributo como http.method no OTel não precisa mais ser convertido para http_method no Prometheus. A consistência dos dados é mantida do início ao fim do pipeline. Como afirmou Richard "RichiH" Hartmann, Diretor de Comunidade da Grafana Labs, isso resulta em "menos atrito e menos tirania de escolha" para os usuários. ## O Veredito: "E Daí?" O Que Isso Significa na Prática? A análise forense dos fatos nos leva a um veredito claro: a paz foi selada e os benefícios são práticos e imediatos para equipes de desenvolvimento e SRE. - **Pilha Unificada sem Gambiarras:** Agora é factível e, mais importante, sensato, usar o Coletor OpenTelemetry para receber todos os seus sinais de telemetria (métricas, traces e logs) e encaminhar as métricas nativamente para o Prometheus, sem conversões dolorosas. - **Dados de Alta Fidelidade:** Ao preservar a nomenclatura original, a correlação entre métricas, traces e logs se torna trivial. Você pode investigar um pico em uma métrica e pular para os traces relacionados usando os mesmos rótulos e atributos, sem decodificar nomes de campos. - **Simplificação da Configuração:** Menos componentes móveis na sua arquitetura de observabilidade significam menos coisas para configurar, monitorar e quebrar. ## Sua Caixa de Ferramentas para a Nova Era A conclusão lógica é que o antigo obstáculo entre Prometheus e OpenTelemetry foi removido. A incompatibilidade é um bug corrigido. **Resumo Lógico:** - **Problema:** Incompatibilidade técnica de protocolo (OTLP) e formato (UTF-8) entre Prometheus e OpenTelemetry. - **Causa Raiz:** Limitações nas versões do Prometheus anteriores à 3.0. - **Solução:** O Prometheus 3.0 introduziu suporte nativo a OTLP e UTF-8, resolvendo a causa raiz. **Seu Próximo Passo:** - **Verifique sua Versão:** A primeira ação é verificar a versão do seu Prometheus. Se for anterior à 3.0, planeje o upgrade. Ele é o pré-requisito para essa integração simplificada. - **Repense sua Arquitetura:** Se você usa soluções alternativas para integrar os dois, avalie a migração para uma ingestão nativa via OTLP. A simplificação valerá o esforço. - **Comece do Jeito Certo:** Se você está construindo uma nova pilha de observabilidade, pode projetá-la com confiança usando Prometheus para métricas e OpenTelemetry para a coleta unificada, sabendo que eles agora trabalham juntos, sem tradutores no meio do caminho.