OpenTelemetry promoveu seu Kubernetes Attributes Processor para v1.0.0, marcando um passo importante na padronização e previsibilidade da telemetria Kubernetes em pipelines de observabilidade. O processador enriquece logs, métricas e traces com metadados do Kubernetes, e sua estabilização significa que o componente atende aos requisitos de OpenTelemetry em testes, benchmarking, documentação e telemetria. Também fornece estabilidade de API para organizações que redistribuem o processador em suas próprias distribuições ou binários do Collector.
Esse marco é importante porque o Kubernetes Attributes Processor ocupa um ponto-chave em muitas implementações de OpenTelemetry. Ele descobre recursos Kubernetes e associa telemetria com metadados como pods, namespaces, nós e workloads, transformando telemetria genérica em dados que podem ser consultados e correlacionados por contexto Kubernetes. O processador está estável para logs, métricas e traces, embora perfis ainda estejam em desenvolvimento.
Compatibilidade e mudanças de atributos
A migração para v1.0.0 não é totalmente compatível com versões anteriores. O lançamento estável do processador adota as novas convenções semânticas Kubernetes do OpenTelemetry, que atingiram status estável na versão 1.42.0 de Semantic Conventions em junho de 2026. OpenTelemetry afirma que isso exigiu coordenação próxima entre o Collector e os SIGs (Grupos de Interesse Especial) de Semantic Conventions, pois estabilizar o processador também exigiu estabilizar as convenções nas quais sua telemetria depende.
Vários nomes de atributos mudam como resultado. Por exemplo, container.image.tag torna-se container.image.tags, enquanto atributos de labels e anotações Kubernetes migram de formas plurais como k8s.pod.labels e k8s.pod.annotations para k8s.pod.label e k8s.pod.annotation. Mudanças equivalentes se aplicam aos labels e anotações de nó e namespace.
Isso torna a migração mais significativa para equipes de observabilidade do que simplesmente alterar uma versão de componente do Collector. Dashboards, alertas, regras de gravação, consultas, pipelines de dados e integrações downstream que referenciam os nomes de atributos antigos podem precisar de atualização. OpenTelemetry fornece feature gates que permitem que as convenções antigas e novas sejam emitidas durante o período de migração, dando aos usuários uma forma de fazer a transição antes de depender exclusivamente do schema estável.
Estabilidade por padrão
A estabilização do processador faz parte do trabalho mais amplo de "Stable by Default" do OpenTelemetry. O Collector SIG começou a se concentrar na estabilidade de componentes muito usados no final de 2025, usando feedback da comunidade e pesquisas de Collector para identificar componentes onde estabilidade e confiabilidade eram particularmente importantes para usuários. O Kubernetes Attributes Processor passou subsequentemente por um processo formal de estabilização cobrindo propriedade de código, testes, benchmarking, documentação e telemetria estável.
O trabalho também ilustra uma característica importante de padrões de observabilidade: um componente não pode necessariamente se tornar estável isoladamente. Os metadados do processador precisam ter semântica estável se a telemetria produzida por ele for permanecer consistente ao longo do tempo. OpenTelemetry coordenou a estabilização do processador com o trabalho de convenções semânticas Kubernetes, que atingiu status de candidato a lançamento em março antes de se tornar estável em junho.
Características operacionais e benchmarks
A estabilidade não altera as características operacionais do processador. Ele mantém um cache na memória de metadados Kubernetes para os pods que monitora, significando que o consumo de memória pode se tornar significativo em ambientes maiores, particularmente quando filtragem não é usada para limitar os metadados sendo coletados. A documentação do OpenTelemetry também identifica limitações em torno de pods com rede do host e implantações de sidecar.
O projeto também publicou benchmarks cobrindo comportamento de CPU e memória em workloads Kubernetes. Isso importa para organizações que tratam o Collector como parte de sua plataforma de produção em vez de simplesmente um componente de encaminhamento de telemetria: o enriquecimento de metadados Kubernetes se torna outro workload cujo consumo de recursos precisa ser compreendido e gerenciado.
Abordagem versus soluções vendor-specific
Há diferenças importantes entre a abordagem OpenTelemetry e agentes Kubernetes de observabilidade específicos de fornecedores. Datadog, por exemplo, fornece um processador infraattributes em sua Datadog Distribution do OpenTelemetry Collector que obtém metadados Kubernetes do Node Agent e Cluster Agent da Datadog em vez de ter cada Collector consultando a API Kubernetes diretamente. Datadog argumenta que isso pode reduzir carga de API e fornecer tagging mais consistente em escala.
O Kubernetes Attributes Processor do OpenTelemetry adota uma abordagem mais agnóstica de fornecedor: ele descobre recursos Kubernetes diretamente através da API Kubernetes e enriquece logs, métricas e traces usando as convenções semânticas padrão do projeto. A distinção portanto é menos sobre se metadados Kubernetes podem ser anexados a telemetria e mais sobre onde esse enriquecimento ocorre, quem possui a camada de descoberta de metadados, e quão portável a telemetria resultante permanece em diferentes backends de observabilidade.
