OpenTelemetry declara estável o processador de atributos do Kubernetes

O OpenTelemetry promoveu o Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps → Attributes Processor, componente do Collector responsável por enriquecer logs, métricas e traces com metadados do Kubernetes, para a versão 1.0.0. O anúncio foi publicado pelo InfoQ em 6 de outubro de 2026 e marca a graduação do processador para o nível de estabilidade mais alto do projeto, com garantias sobre testes, benchmarks, documentação e telemetria.

A estabilidade também passa a cobrir a API do processador, o que importa para empresas que redistribuem o componente dentro de suas próprias distribuições ou binários do Collector. Na prática, isso significa que integrações construídas sobre o processador deixam de correr o risco de quebrar entre versões menores.

O que o processador faz

O Kubernetes Attributes Processor descobre recursos do Kubernetes e associa a telemetria coletada a metadados como pods, namespaces, nós e workloads. É ele quem transforma uma métrica ou um trace genérico em um dado que pode ser filtrado e correlacionado pelo contexto do cluster, em vez de aparecer só como um número solto.

Segundo o InfoQ, o componente já é estável para logs, métricas e traces; o suporte a profiles continua em desenvolvimento. Esse status diferenciado por sinal de telemetria é comum no modelo de graduação do OpenTelemetry, que avalia cada tipo de dado separadamente antes de fechar a estabilidade geral de um componente.

A estabilização não é retrocompatível

A graduação do processador veio junto com a adoção das novas convenções semânticas do Kubernetes, que atingiram status estável na versão 1.42.0 das Semantic Conventions, em junho de 2026. O OpenTelemetry afirma que isso exigiu coordenação próxima entre o SIG do Collector e o SIG de Kubernetes Semantic Conventions, porque não dá para estabilizar o processador sem estabilizar antes o vocabulário de atributos que ele produz.

Essa dependência trouxe mudanças que quebram compatibilidade com pipelines existentes. Alguns nomes de atributos mudaram de formato:

Segundo a fonte, mudanças equivalentes valem para labels e anotações de nós e de namespaces, seguindo a mesma lógica de normalização de plural para singular.

Em resumo: quem referencia esses nomes de atributos em dashboards, alertas, recording rules, queries e pipelines downstream precisa revisar essas integrações antes de migrar para a versão estável, e não apenas atualizar a versão do componente no Collector.

Caminho de migração sem quebrar tudo de uma vez

O OpenTelemetry disponibiliza feature gates que permitem emitir simultaneamente as convenções antiga e nova durante o período de transição. Isso dá às equipes de observabilidade uma janela para atualizar dashboards e alertas de forma gradual, em vez de trocar tudo no mesmo deploy em que o Collector é atualizado.

Para times no Brasil que mantêm Grafana, Prometheus ou backends comerciais alimentados por telemetria do Kubernetes via OpenTelemetry, essa é a parte prática que não pode ser ignorada: a atualização do Collector sozinha não resolve o problema, porque o esquema de dados muda junto.

Por que a estabilização levou tempo

A graduação do processador faz parte de uma frente maior do OpenTelemetry chamada "Stable by Default", que o SIG do Collector começou a priorizar no fim de 2025. O objetivo foi usar feedback da comunidade e pesquisas entre usuários do Collector para identificar quais componentes mais usados em produção precisavam de garantias formais de estabilidade.

O Kubernetes Attributes Processor passou então por um processo formal de graduação que cobriu propriedade de código, testes, benchmarks, documentação e estabilidade de telemetria, segundo o InfoQ. As convenções semânticas de Kubernetes, por sua vez, chegaram a release candidate em março de 2026 antes de virarem estáveis em junho do mesmo ano, o que alinhou o calendário dos dois SIGs.

O que não mudou: custo operacional

Virar estável não altera o comportamento operacional do processador. Ele mantém um cache em memória dos metadados de Kubernetes dos pods monitorados, e esse consumo de memória pode crescer em ambientes grandes, principalmente quando não há filtragem para limitar quais metadados são coletados.

A documentação do OpenTelemetry também lista limitações conhecidas em pods com rede de host (host-networked) e em implantações com sidecar. O projeto publicou benchmarks de CPU e memória cobrindo diferentes cargas de trabalho em Kubernetes, o que importa para quem trata o Collector como parte da plataforma de produção, e não como um mero encaminhador de telemetria: o enriquecimento com metadados de Kubernetes também é um workload que consome recursos e precisa ser dimensionado.

Como isso se compara à abordagem de fornecedores

O InfoQ destaca uma diferença relevante entre a abordagem do OpenTelemetry e a de agentes de observabilidade específicos de fornecedor. A Datadog, por exemplo, oferece um processador infraattributes em sua distribuição do Collector que obtém metadados do Kubernetes a partir do Datadog Node Agent e do Cluster Agent, em vez de cada instância do Collector consultar diretamente a API do Kubernetes. A empresa argumenta que isso reduz a carga sobre a API do cluster e produz tagueamento mais consistente em escala.

O Kubernetes Attributes Processor do OpenTelemetry segue um caminho mais neutro em relação a fornecedor: descobre recursos do Kubernetes diretamente pela API do cluster e enriquece logs, métricas e traces usando as convenções semânticas padrão do projeto. A diferença, segundo o InfoQ, está menos em se é possível anexar metadados de Kubernetes à telemetria e mais em onde esse enriquecimento acontece, quem é dono da camada de descoberta de metadados e quão portável a telemetria resultante permanece entre diferentes backends de observabilidade.

Para equipes que já usam a stack do OpenTelemetry Collector em clusters Kubernetes no Brasil, a estabilização do processador é um sinal de maturidade útil, mas o trabalho real está em auditar quais dashboards, alertas e pipelines dependem dos nomes antigos de atributos antes de desligar os feature gates de compatibilidade.

Fonte: InfoQ