周三凌晨，一条版本号悄悄跳了：OpenTelemetry 的 Kubernetes Attribute Processor 升到1.0.0。对天天在 Collector 配置里翻属性名的人来说，这不是一次普通的版本更新，而是一次要动手改仪表盘的信号。
这个处理器在可观测性管道里的位置很关键。它负责发现 Kubernetes 资源，把遥测数据和 Pod、命名空间、节点、工作负载这些元数据关联起来，让原本通用的日志、指标、追踪数据变成能按 K8s 上下文查询和关联的数据。目前它在日志、指标、追踪三方面都已趋于稳定，性能分析功能还在开发当中。
正式发布意味着它满足了 OpenTelemetry 在测试、基准测试、文档和遥测方面的稳定性要求。对那些把它打包进自家 Collector 发行版或二进制文件再分发的组织，还多了一层 API 稳定性保障。
改名清单，先看这几条
v1.0.0 并非完全向后兼容。稳定版采用了更新的 OpenTelemetry Kubernetes 语义约定，而这些约定本身在 Semantic Conventions v1.42.0 中才正式稳定下来。OpenTelemetry 表示，这需要 Collector 和 Kubernetes Semantic Conventions SIG 之间密切协调，因为处理器要稳定，它所依赖的遥测数据语义约定也得先稳定。
于是多个属性名称发生了变化：
- container.image.tag 变为 container.image.tags
- k8s.pod.labels 和 k8s.pod.annotations 等复数形式，改成 k8s.pod.label 和 k8s.pod.annotation
- 节点和命名空间的标签及注解也做了相应变更
对可观测性团队来说，这次迁移远不止改个 Collector 组件版本号。引用了旧属性名的仪表盘、告警、记录规则、查询、数据管道和下游集成，可能都得跟着更新。OpenTelemetry 提供了功能闸门（feature gates），允许迁移期间同时按新旧两种规范输出，在完全依赖稳定模式之前留了一条过渡路径。
稳定不是一个人的事
这次毕业是 OpenTelemetry “默认稳定（Stable by Default）”工作的一部分。Collector 特别兴趣小组（SIG）自 2025 年末开始关注高使用率组件的稳定性，通过社区反馈和 Collector 调查，识别出对用户而言稳定性和可靠性尤为重要的组件。随后，Kubernetes Attributes Processor 走了一个正式的毕业流程，覆盖代码所有权、测试、基准测试、文档以及遥测稳定性。
这件事也说明了一个可观测性标准的特征：一个组件仅凭自身不一定能达到稳定状态。要确保处理器生成的遥测数据在时间上保持一致，其元数据就必须具备稳定的语义。所以 OpenTelemetry 把处理器的毕业和 Kubernetes 语义约定工作做了协调，后者在 3 月份达到发布候选状态，6 月正式发布稳定版本。
稳定性不会改变处理器的运营特性。它会为监控的 Pod 维护一个 Kubernetes 元数据内存缓存，这意味着在大型环境中内存消耗可能变得相当可观，特别是在没用过滤功能限制收集的元数据时。文档还指出了与使用主机网络的 Pod 以及 Sidecar 部署相关的限制。
项目同时发布了涵盖 Kubernetes 工作负载中 CPU 和内存行为的基准测试结果。对把 Collector 当作生产平台组成部分、而非单纯遥测转发组件的组织来说，这一点很关键：Kubernetes 元数据扩充处理本身已经成为另一项工作负载，资源消耗需要被理解和管理。
和特定于供应商的 Kubernetes 可观测性代理相比，做法也有差异。比如 Datadog 在其 OpenTelemetry Collector 的 Datadog 分发中提供了基础设施属性处理器，从 Datadog Node Agent 和 Cluster Agent 获取 Kubernetes 元数据，而不是让每个 Collector 直接查询 Kubernetes API。Datadog 认为这样可以减轻 API 负载，并在大规模部署时提供更一致的标签处理。
OpenTelemetry 的 Kubernetes Attributes Processor 走的是更中立的路线：通过 Kubernetes API 直接发现资源，用项目标准语义约定扩充日志、指标和追踪信息。区别不在于能不能把 Kubernetes 元数据附加到遥测数据上，而在于数据增强发生在何处、元数据发现层由谁负责，以及生成的遥测数据在不同可观测性后端之间的可移植性如何。
升级之前，先把引用旧属性名的查询和告警翻一遍，再决定功能闸门开多久。
热门跟贴