OpenTelemetry Makes Kubernetes Attributes Processor Stable as Observability Schema Matures

TL;DR · AI 摘要
OpenTelemetry的Kubernetes Attributes Processor升级至v1.0.0,提升可观测性数据稳定性。
核心要点
- Kubernetes Attributes Processor已稳定支持日志、指标和跟踪数据
- 语义约定更新导致属性名变更(如container.image.tag→container.image.tags)
- 迁移期间支持新旧约定共存过渡
结构提纲
按章节快速跳转。
- §引言
OpenTelemetry宣布Kubernetes Attributes Processor达到v1.0.0稳定版本
- ·核心机制
处理器通过注入Kubernetes元数据增强可观测性数据
满足测试、基准、文档和遥测的稳定性标准
采用v1.42.0语义约定导致属性名变更
- ›迁移影响
需更新仪表板、查询规则等依赖旧属性名的系统
- ·过渡方案
提供特性门控支持新旧约定并行过渡
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- OpenTelemetry稳定性升级
- Kubernetes Attributes Processor
- v1.0.0稳定版本
- 语义约定更新
- 迁移过渡方案
- 影响范围
- 属性名变更
- 下游系统适配
金句 / Highlights
值得收藏与分享的关键句。
Kubernetes Attributes Processor已稳定支持日志、指标和跟踪数据
属性名变更示例:container.image.tag→container.image.tags
迁移期间可通过特性门控同时输出新旧约定数据
OpenTelemetry 将 Kubernetes 属性处理器升级至 v1.0.0,可观测性模式日趋成熟 - InfoQ
InfoQ 首页 News OpenTelemetry 将 Kubernetes 属性处理器升级至 v1.0.0,可观测性模式日趋成熟
DevOps
InfoQ 认证高绩效团队计划(在线,11月17日):为团队构建更清晰的运营模型。
OpenTelemetry 将 Kubernetes 属性处理器升级至 v1.0.0,可观测性模式日趋成熟
2026年10月6日 3分钟阅读
作者:
- Craig Risi
#### 关注我们
Youtube
232K 粉丝
26K 粉丝
新
RSS
19K 读者
X
57.1k 粉丝
21K 点赞
Bluesky
收听本文 -
0:00
音频准备就绪
您的浏览器不支持音频元素。
正常
1.25x
1.5x
喜欢
新下拉阅读列表
- 阅读列表
OpenTelemetry 将其 Kubernetes 属性处理器升级至 v1.0.0 版本,标志着在使 Kubernetes 遥测数据在可观测性管道中更加可预测和稳定方面迈出重要一步。该处理器通过添加 Kubernetes 元数据来丰富日志、指标和追踪数据,其毕业认证意味着该组件现在满足 OpenTelemetry 在测试、基准测试、文档和遥测方面的稳定性要求。它还为将处理器重新分发到自身 Collector 分发版或二进制文件中的组织提供 API 稳定性保障。
这一里程碑具有重要意义,因为 Kubernetes 属性处理器在许多 OpenTelemetry 部署中处于关键位置。它能够发现 Kubernetes 资源,并将遥测数据与诸如 Pod、命名空间、节点和工作负载等元数据相关联,从而将原本通用的遥测数据转化为可通过 Kubernetes 上下文进行查询和关联的数据。目前该处理器对日志、指标和追踪数据已实现稳定,但性能分析功能仍在开发中。
升级至 v1.0.0 版本并非完全向后兼容。该处理器的稳定版本采用了更新的 OpenTelemetry Kubernetes 语义约定,这些约定本身在 2026 年 6 月 Semantic Conventions v1.42.0 版本中达到稳定状态。OpenTelemetry 表示,这一变更需要 Collector 团队与 Kubernetes 语义约定特别兴趣小组(SIG)之间密切协作,因为处理器的稳定化也要求其依赖的遥测约定实现稳定。
因此多个属性名称发生变更。例如,container.image.tag 变为 container.image.tags,而 Kubernetes 标签和注解属性从复数形式如 k8s.pod.labels 和 k8s.pod.annotations 改为单数形式 k8s.pod.label 和 k8s.pod.annotation。节点和命名空间的标签及注解也适用相同变更规则。
这对可观测性团队而言,迁移工作的重要性远超过简单升级 Collector 组件版本。任何引用旧属性名称的仪表板、告警、记录规则、查询、数据管道和下游集成可能都需要更新。OpenTelemetry 提供了特性门控功能,允许在迁移期间同时输出旧版和新版约定,为用户提供了在完全依赖稳定模式前完成过渡的途径。
处理器的毕业是 OpenTelemetry 更广泛的 "Stable by Default" 工作的一部分。Collector SIG 从 2025 年底开始关注高使用率组件的稳定性,通过社区反馈和 Collector 调查识别出对用户稳定性与可靠性至关重要的组件。随后 Kubernetes Attributes Processor 经历了正式的毕业流程,涵盖代码所有权、测试、基准测试、文档和遥测稳定性等多个领域。
这项工作也体现了可观测性标准的一个重要特性:组件无法在孤立状态下实现稳定性。如果处理器的元数据需要保持稳定的语义,才能确保其生成的遥测数据在时间上保持一致性。因此 OpenTelemetry 将处理器的毕业与 Kubernetes 语义约定工作进行了协调,后者在 3 月达到候选发布状态,并于 6 月正式稳定。
稳定性不会改变处理器的操作特性。它仍会为监控的 Pod 维护一个内存中的 Kubernetes 元数据缓存,这意味着在较大环境中内存消耗可能变得显著,尤其是在未使用过滤功能限制收集元数据时。OpenTelemetry 的文档也指出了与主机网络 Pod 和 Sidecar 部署相关的限制。
该项目还发布了涵盖 Kubernetes 工作负载 CPU 和内存行为的基准测试。这对将 Collector 视为生产平台组成部分而非单纯遥测转发组件的组织尤为重要:Kubernetes 元数据丰富功能将成为另一个需要理解并管理资源消耗的工作负载。
OpenTelemetry 的方法与特定供应商的 Kubernetes 可观测性代理之间也存在重要差异。例如,Datadog 在其 OpenTelemetry Collector 的 Datadog 发行版中提供了 infraattributes 处理器,该处理器从 Datadog Node Agent 和 Cluster Agent 获取 Kubernetes 元数据,而不是让每个 Collector 直接查询 Kubernetes API。Datadog 认为这可以减少 API 负载,并在大规模环境中提供更一致的标签。
OpenTelemetry Kubernetes Attributes Processor 采用更中立的供应商方法:它通过 Kubernetes API 直接发现 Kubernetes 资源,并使用项目的标准语义约定来丰富日志、指标和追踪。因此区别不在于 Kubernetes 元数据能否附加到遥测数据上,而在于元数据丰富过程发生的位置、元数据发现层的归属以及生成的遥测数据在可观测性后端之间的可移植性。
作者信息部分主容器
关于作者
章节标题
每个作者的主容器
#### Craig Risi
显示更多
显示更少
#### 本内容属于 DevOps 主题
##### 相关主题:
- DevOps
- Kubernetes
- OpenTelemetry
- 可观测性
- 相关编辑内容
- 相关赞助商
- 相关赞助商 2026 年 10 月 8 日,东部时间下午 12 点 当 AI 加速开发时,您的 CI 管道能否跟上?由 Datadog 的软件交付产品营销经理 Eric Metaj 和 CI/CD 优化产品经理 Rohin Chandra 呈现
InfoQ 新闻通讯
每周五发送 InfoQ 上一周内容的摘要。加入超过 25 万名高级开发者的社区。查看示例
我们保护您的隐私。 /think