Java com OpenTelemetry 2.32.0 antecipa o que vai quebrar no 3.0

Java↳Java42 conteúdosNovidades do Java 26 (para desenvolvedores)Dev (Back & Front) · mar 2026Visual Studio Code para Java: o guia completo (dicas, configuração e extensões)Dev (Back & Front) · out 2025Quarkus: Modernizando a linguagem Java para a era da nuvemDev (Back & Front) · nov 2020Ver tudo em Dev (Back & Front) → recebeu a versão 2.32.0 do agente OpenTelemetry como candidata ao 3.0, previsto para outubro de 2026. O objetivo é claro. A versão permite testar mudanças de convenção, captura e instrumentação antes que elas virem padrão.

As convenções semânticas de banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → e de código entram como padrões estáveis. Além disso, a mensageria, por sua vez, adota convenções mais recentes que seguem experimentais.

Portanto, alguns comportamentos ainda podem mudar antes do lançamento final.

Jay DeLuca, engenheiro de software sênior da Grafana Labs, descreveu um processo de migração para teste e implantação.

Capture a telemetria atual antes de ligar a prévia Java

A recomendação inicial parece óbvia, ainda assim muita gente pula. Vale registrar a linha de base antes de qualquer mudança.

O caminho envolve manter a flag guarda desligada. Depois, basta ativar a emissão dupla para banco de dados, código e mensageria.

Dessa forma, atributos antigos e novos saem juntos. Contudo, o mesmo vale para métricas onde a emissão dupla funciona.

Existe uma ressalva importante nessa comparação. Conferir apenas o nome do atributo deixa passar erro, já que valores e unidades também mudam.

Os valores mudam, e não apenas os nomes

O exemplo com JDBC e PostgreSQL ilustra bem. Uma conexão com o banco orders no esquema public gera db.name legado como orders.

O novo db.namespace, porém, sai como orders|public.

Outras mudanças seguem a mesma lógica. O valor mssql em db.system vira microsoft.sql_server em db.system.name.

Na frente de código, dois atributos se fundem. code.namespace e code.function viram code.function.name.

A métrica de duração do pool merece atenção especial. A unidade muda de milissegundos para segundos, o que exige converter todos os limiares de alerta.

Vale notar um detalhe adicional. Métricas de pool adotam nomes e unidades novos mesmo com emissão dupla ativada.

Java e Kafka: os relacionamentos de trace mudam de figura

A mensageria salta das convenções v1.24 para v1.43. Os nomes de span mudam bastante.

Antes eram orders publish, orders receive e orders process. Agora saem como send orders, poll orders e process orders.

O antigo atributo messaging.operation se divide em nome e tipo. Um poll de Kafka, por exemplo, tem nome poll e tipo receive.

A relação de parentesco depende da execução no consumidor. Com processamento de mensagem única e contexto propagado, um span ativo da aplicação vira pai do span de processo na prévia.

Nesse caso, o span de processo apenas se liga ao produtor. Já com spans de recebimento ativos e sem span ativo no consumidor, ele vira filho do span de envio no mesmo trace.

O span de poll também muda de natureza. Ele passa de CONSUMER para CLIENT e se liga ao span de envio.

Processamento em lote segue outro modelo. Ele pode se ligar a várias mensagens.

Spans de recebimento continuam opcionais. Ativar essa telemetria, contudo, também liga as métricas de duração de poll.

Agrupamento de endpoint e captura de usuário

Essa parte afeta painéis existentes. Para clientes suportados, server.address descreve o destino configurado, possivelmente uma lista de endpoints de cluster.

Já network.peer.address identifica o endpoint realmente contatado. Consequentemente, o agrupamento no grafo de serviços muda sem qualquer renomeação de atributo.

A captura de identidade de usuário segue opcional, porém com configuração nova. O enduser.id vira user.name.

O enduser.role deixa de ser string separada por vírgula e vira array em user.roles. Já o enduser.scope segue sem substituto.

Java com instrumentações desligadas e Zipkin fora

Três instrumentações vêm desativadas por padrão. São Hibernate, Hystrix e Twilio, que exigem reativação explícita.

Quem mantém extensões enfrenta outro ajuste. A instrumentação invokedynamic vira padrão, o que altera instrumentação e carregamento de classes auxiliares.

O alerta mais urgente envolve exportador. O suporte ao Zipkin foi removido no modo de prévia.

Configurações que ainda usam esse exportador podem falhar na inicialização do agente. A troca para OTLP, portanto, vira requisito.

O roteiro prático de migração

Primeiro, ligue a emissão dupla e colete a linha de base. Depois, compare valores e unidades, e não apenas nomes.

Em seguida, isole as mudanças. Deixe a flag guarda desligada e remova o sufixo de duplicação para separar convenção de padrão.

Além disso, revise alertas e painéis. Unidade em segundos e agrupamento por endpoint alteram resultado sem aviso.

Por fim, teste o Kafka com atenção. A mudança de parentesco entre spans muda bastante a leitura de trace distribuído.

Acompanhe nosso perfil no Instagram!