大规模指标平台迁移到 OpenTelemetry 反映了哪些趋势

大规模指标平台迁移到 OpenTelemetry，反映的并不只是“换一个采集器”。从 Atlassian 工程师公布的案例看，真正明显的趋势有五个：迁移优先保持应用接口稳定，Collector 从通用代理变成分层平台运行时，旧协议与 OTLP 长期共存，指标路由与聚合继续承担成本控制，发布方式则越来越像核心基础设施的渐进替换。

官方案例：https://www.cncf.io/blog/2026/09/17/opentelemetry-everywhere-migrating-a-metrics-platform-at-scale/

这次案例最值得注意的不是“全面改用 OpenTelemetry”这句话，而是迁移团队刻意没有要求所有业务先改 SDK。他们保留应用已经依赖的 StatsD 接口，把组织级改造收缩成平台团队可控制的后端替换。

公开案例的规模为什么有代表性

CNCF 在 2026 年 9 月发布了 Atlassian 工程师的迁移文章。原指标管道长期建立在 gostatsd 上，覆盖约 10 万台主机和 14 个区域，目标服务等级为 99.95%。旧系统本身并非失效，而是面临协议与生态的变化：gostatsd 以 UDP 为主，不覆盖 traces 和 logs，而越来越多上游开始产生 OpenTelemetry 数据。

我读这个案例时最有感触的一点，是它没有把“旧系统稳定”与“应该继续保留”画等号。基础设施运行多年、大家很少注意它，往往说明可靠；但当社区能力持续向另一套标准聚合，内部团队继续自行补齐协议、处理器、重试和后端适配，长期成本会越来越高。

这些数字来自案例作者的生产环境，不应直接外推为其他公司的收益承诺。它们的价值在于说明：OpenTelemetry 已经进入“如何替换大规模现有管道”的阶段，而不只是新项目里的埋点选项。

这次迁移不是把 SDK 一次性换掉

迁移的核心策略是保持应用侧契约：服务仍然可以向原地址发送 StatsD UDP 指标，平台内部则逐层替换成定制的 OpenTelemetry Collector 分布。同时，收集层新增 OTLP receiver，让新服务能够原生发送 OTel 指标。

这种做法把两个风险拆开了：平台团队先证明新管道能承受生产流量，业务团队随后再决定何时把 instrumentation 迁到 OpenTelemetry SDK。与要求数千个服务同步改代码相比，兼容接口把爆炸半径限制在少数平台组件中。

案例里的收集层复用了已有 tracing sidecar，把 metrics 合并进去。作者报告，在其成本最高的一类服务中，平均每个服务节省约 3.9% CPU，换算到舰队规模，sidecar 成本约下降 30%。这再次说明，统一采集并不只是协议整洁，也可能减少重复代理和重复资源预留。

Collector 正从代理变成平台运行时

我以前容易把 Collector 想成“收进来再转出去”的通用代理。这次案例呈现的是另一种形态：每个阶段都有面向自身任务构建的 Collector 分布。

• 收集层：兼容 StatsD，同时接收 OTLP，承接业务服务的入口契约；
• 接入层：负责把同一时间序列稳定路由到相同聚合器；
• 聚合层：执行 delta 指标聚合，压缩需要落地的数据量；
• 转发层：使用上游 exporters 向多个后端分发，并复用队列、重试和背压能力。

这反映出平台工程的一种变化：过去为每个阶段维护独立服务，现在更倾向于在同一组件模型里组合 receiver、processor、connector 和 exporter。新增能力变成“开发或配置组件”，而不是再创建一套服务骨架、部署方式和运维模型。

但“统一到 Collector”不等于“所有环境使用一份万能配置”。大规模场景仍需要不同的分布、资源限制、权限与故障域。通用组件提供的是共同运行模型，不是抹平所有业务约束。

规模化指标平台仍然要解决状态与热点

OpenTelemetry 提供标准，并不会自动消除指标平台的分布式系统难题。案例中，聚合是有状态的，同一时间序列的数据点必须进入相同聚合器。旧路由按“服务、环境”做哈希，大服务会把流量集中到少数分片，形成热点。

他们改用 contrib loadbalancingexporter，按代表单条时间序列身份的 streamID 路由。这样，一个大型服务包含的众多时间序列可以分散到多个聚合器，同时单条时间序列仍保持稳定归属。这里体现的趋势不是简单“使用开源组件”，而是路由粒度从服务级向数据流级移动。

聚合层同样保留了企业自己的差异化逻辑。由于上游没有按预期聚合 delta temporality，团队编写并开源了自定义 delta aggregation processor。公开案例称，在相同流量下，聚合层 CPU 约降到原来一半。标准化与定制化并不冲突：标准组件负责通用生命周期，企业只在真正独特的语义处开发扩展。

大规模迁移显出的五个趋势

一、标准化从埋点 API 延伸到整条管道

OpenTelemetry 早期常被讨论为统一 SDK 与协议，如今重点已经扩展到 Collector、组件治理和跨后端分发。CNCF 在 2026 年确认 OpenTelemetry 达到毕业项目阶段，也说明其生产采用、治理、安全、API 稳定性和文档已经经过更高成熟度评估。对大型组织而言，选择 OTel 越来越像平台标准决策，而不是单个团队的库选型。

二、兼容接口比强推一次性迁移更重要

旧 StatsD 客户端可以继续工作，新服务可以使用 OTLP。协议共存不是妥协失败，而是把组织迁移节奏与平台改造节奏解耦。保留入口契约，能够让平台团队先建立容量、稳定性和回滚信心。

三、可观测性平台越来越重视成本治理

每分钟数十亿数据点如果原样落地，任何开放标准都会变得昂贵。案例中的 delta 聚合把输入压缩到约 4.6%，同时在接入端更均匀地分配负载。另一个值得关注的成本点是指标基数：OpenTelemetry 官方近期也强调，SDK 基数限制保护进程内存，但溢出后按属性过滤或分组可能低估结果。迁移时不能只验证“总量还在”，还要验证 SLO、告警和分组查询是否保持语义。

四、后端正在与采集和处理层解耦

案例把内部转发器换成无状态 Collector 分布，并通过 exporters 向 SignalFx、S3 等后端扇出。增加目标后端更接近配置变更，而不是重新开发集成项目。这种解耦降低供应商切换成本，也让同一份遥测数据可以按合规、实时查询和归档需求分发。

五、生产迁移依赖持续画像与渐进发布

作者特别强调生产持续画像：组件在真实负载下的成本与行为，未必能由小规模基准测试提前揭示。他们从开发和预发布环境、最愿意配合的服务开始，再按比例逐步扩大。对核心指标管道来说，这比“测试通过后全量”更接近可执行的发布策略。

企业落地时先把边界和审计补齐

如果把案例经验转成企业加固动作，我会先列清六类边界。它们不是 OpenTelemetry 的默认保证，而是平台团队需要自己完成的生产设计。

尤其要避免把“Collector 能连接多个后端”理解成默认安全。接收端口、exporter 凭据、配置分发和调试接口都需要最小权限；日志中也不应记录完整敏感属性。平台迁移成功的标准，不只是新数据能到达后端，还包括旧告警不失真、异常可定位、配置变更可追溯、每个阶段都有明确回滚点。

哪些团队适合参考这条路线

这条路线最适合已经有稳定旧指标协议、服务数量多、无法统一窗口改 SDK，同时又希望逐步接入 OTLP 的组织。它也适合自研采集与转发服务越来越多、平台团队持续重复实现队列、重试、背压和多后端适配的场景。

如果团队规模很小、没有历史协议负担，直接使用原生 OTel SDK 与标准 Collector 配置可能更简单。反过来，如果现有指标的命名、基数和聚合语义都没有治理，先换采集器也不会自动解决数据质量问题。迁移路线应该由契约和风险决定，而不是由“是否采用热门标准”决定。

总结

Atlassian 的公开案例说明，OpenTelemetry 正从统一遥测 API 演进为大型可观测性平台的共同运行底座。大规模迁移的关键不是让所有应用同时重写埋点，而是保留旧接口、增加 OTLP、按收集到转发的层次逐步替换，继续解决流级路由、delta 聚合、基数、背压和多后端等现实问题。更深层的趋势是：标准化让平台团队减少重复造轮子，但容量、成本、安全、审计和渐进发布仍然决定迁移能否真正进入生产。