Atlassian 把 10 万台主机的指标管道搬上 OpenTelemetry：接口不动，引擎全换
Atlassian 在 CNCF 博客完整复盘了持续数年的指标管道迁移：保留 StatsD 接口不变，把采集、接入、聚合、转发四个环节全部换成 OpenTelemetry Collector，侧车成本降约 30%，聚合层 CPU 约减半，并开源了自研的 delta 聚合处理器。
作者：核流编辑 · 栏目：资源
跑了近十年的指标管道怎么整体换成 OpenTelemetry？Atlassian 的工程师在 CNCF 博客完整复盘了这场持续数年的迁移实战。他们维护的 gostatsd 管道覆盖约 10 万台主机、14 个区域，多年保持 99.95% 的 SLO。倒不是旧系统彻底坏了，而是整个云原生生态都在向 OpenTelemetry 靠拢，旧管道无论如何接不住 OTel 格式的遥测数据，重构势在必行。 接口不动、引擎全换，一场组织级迁移缩回平台内部 指标管道本质是一份两头签约的隐形合约：业务团队只认准一行约定——「把 StatsD 报文用 UDP 发到指定地址，指标就能在监控面板落库」。至于报文发出后怎么路由、怎么聚合再落到长期存储，多数业务团队既不关心也不想折腾。Atlassian 抓住了这个关键分界点：死守上游协议不动，把下游链路全部重写，硬生生把一场涉及全公司业务方的“组织级协同大迁移”，缩编成了平台团队内部的静默替换。 他们在采集、接入、聚合、转发四个阶段各部署了一个定制分发的 OpenTelemetry Collector，每个环节均可独立演进与灰度。在采集端，Agent 同时支持 StatsD 与 OTLP 两种协议，业务方零改动即可平滑过渡。与此同时，平台顺手将指标侧车与既有的链路追踪侧车合二为一，不仅消除了一套常驻进程的冗余开销，还让单服务平均省下约 3.9% CPU，侧车总资源成本直接砍掉约 30%。 自研 Delta 聚合开源，48 亿数据点削减 96% 把数据接进来只是第一步，聚合层的计算风暴才是真正的成本黑洞。在高峰期，Atlassian 的指标管道每分钟要涌入约 48 亿个数据点，如果全部直冲存储层，任何后端的吞吐与钱包都难以承受。通过接入层引入 streamID 哈希分片消除热点后，他们将重心放在了聚合削峰上。 平台团队自研了一套 Delta 聚合处理器（目前已开源在 atlassian-labs 旗下），在边缘聚合后，每分钟 48 亿点最终只有约 2.2 亿落库，体积直接削减 96%。在旧架构里，gostatsd 聚合器加上 nomad 路由代理合计占用了整个指标集群 CPU 请求的 38%，这一波重构直接让聚合层整体 CPU 消耗缩水近半，给基础设施省下了真金白银。 从 1% 到 100% 渐进发布，同行能抄的几条工程作业 梳理这场跨越数万节点的平滑升级，Atlassian 给出的几条工程经验相当接地气： 挑对早期采用者：先上开发与预发环境，找那些最迫切需要新特性、同时对偶发抖动容忍度最高的团队共建； 在线上持续做真实 Profiling：基准测试测不出诡异边界，许多组件的内存泄漏和 CPU 尖峰只有在真实生产环境的重载压榨下才会现形； 保持操作原语一致：迁移过渡期必须允许新旧两套并跑，但对业务方的配置规范和运维口径要保持一致，避免让工程师心智分裂； 分级推进放量：严格按照 1% → 10% → 50% → 100% 的阶梯推进，越早把边界问题暴露在低配比阶段，止损代价就越低。 对于那些同样在自建可观测体系中苦苦挣扎、被旧协议与历史包袱捆住脚踝的平台团队来说，Atlassian 的思路提供了一个绝佳样本：不必逼着全公司业务方推倒重写 SDK，先用兼容代理稳住接口，再从边缘到核心逐步替换引擎。OpenTelemetry Collector 本身作为 Go 编写的中立实现，一套二进制支持 traces、metrics 与 logs，开箱即用 Prometheus 与 Jaeger，数据层走 OTLP v1.10.0 稳定版。官方仓库提供了完整构建文档，照着这套解耦节奏推进，迁移规模再大也有路可循。 参考资料 CNCF Blog：OpenTelemetry everywhere: Migrating a metrics platform at scale GitHub：OpenTelemetry Collector