Atlassian 完成大规模指标管道向 OpenTelemetry 的平滑迁移，CPU 消耗降低约 30%

一句话结论

Atlassian 通过保留 StatsD 接口并重构后端流程，将指标平台迁移至 OpenTelemetry，实现全集群资源消耗降低约 30% 且不影响生产告警。

关键要点

• 迁移覆盖 14 个区域的约 10 万个主机，现有服务 SLO 保持 99.95% 不受影响
• 每分钟接收 48 亿个数据点，聚合后实际存储约 2.2 亿个，减少约 96%
• 指标整合至追踪 sidecar 后，每个资源消耗最大的微服务平均节省 3.9% CPU
• 使用 OpenTelemetry contrib 负载均衡导出器通过流 ID 哈希分片，解决原 Nomad 代理热点副本问题
• 无状态 metrics-gateway 系统取代定制化转发服务，添加新目标仅需修改配置

背景与事实

软件公司 Atlassian 在 CNCF 博客上发布了一篇详细的技术文章，分享了其从内部指标系统 gostatsd 迁移至 OpenTelemetry（OTel）的完整经验。此次迁移并非简单的组件替换，而是对整个指标平台的内部运行机制进行了重构。Atlassian 的指标平台规模庞大，从 14 个不同区域的约 10 万个主机中接收数据。鉴于现有服务的 SLO 高达 99.95%，团队面临的核心挑战是在不影响生产环境告警指标的前提下完成迁移，这要求任何故障都必须在极短时间内被发现并修复。

在解释迁移动机时，Atlassian 工程师 Iris Grace Endozo、Farzad Vazirnia 和 Albert Kerr 指出，虽然 gostatsd 多年来运行稳定，但其仅支持 UDP 协议的设计存在明显局限，无法处理追踪（Tracing）或日志（Logging）信息。随着越来越多的服务开始生成 OpenTelemetry 数据，继续使用 gostatsd 意味着 Atlassian 不得不重复开发 OpenTelemetry Collector 社区正在快速迭代的功能，这将带来巨大的维护成本和生态割裂风险。因此，团队决定将指标平台的核心管道重构为基于 OpenTelemetry Collector 的架构。

在迁移策略上，Atlassian 采取了一种“兼容层”方法。团队没有要求将数千个服务立即从 StatsD 客户端迁移到 OpenTelemetry SDK，而是保留了现有的 StatsD-over-UDP 接口，并重构了接口背后的所有处理逻辑。这种策略将原本需要在全组织范围内开展的、涉及应用代码修改的复杂迁移，转变为由平台团队主导的基础设施升级。Atlassian 为此推出了专为数据采集、摄入、聚合和转发设计的 Collector 发行版，该平台被划分为四个阶段，使工程师可以独立修改其中的一部分，而不影响其他部分。

在数据采集层面，Atlassian 用其追踪团队已在使用的 Collector 发行版替换了 gostatsd sidecar。应用程序继续将 StatsD 数据包发送到同一地址，而新增的 OTLP 接收器允许新服务直接发送 OpenTelemetry 指标。对于无法运行 sidecar 的无服务器工作负载，OpenTelemetry 的 Lambda 扩展保留了原有的接口兼容性。在摄入层，团队解决了指标聚合的状态性问题。原有的 Nomad 代理通过将每个服务和环境哈希映射到特定分片，导致规模最大的服务集中在少数几个繁忙的副本上，形成热点。新系统使用 OpenTelemetry contrib 负载均衡导出器，通过流 ID 进行哈希分片，既保证了单个时间序列的数据不会分散到不同节点，又将大服务的负载均匀分布到整个副本池中。

影响分析

对于中文开发者与从业者而言，Atlassian 的这次迁移实践提供了一个极具参考价值的大规模可观测性基础设施升级范本。首先，它证明了在不中断业务连续性的前提下，重构核心监控管道是可行的，关键在于保留旧接口并逐步替换后端逻辑，而非强制应用层配合改动。其次，该案例展示了 OpenTelemetry Collector 在高性能指标聚合场景下的实际表现，特别是其通过流 ID 路由解决数据热点问题的机制，这对国内正在建设大规模微服务监控平台的团队具有直接的工程借鉴意义。

然而，这也意味着技术团队需要具备处理有状态聚合器扩展性的能力。Atlassian 案例中提到的“手动配置”依赖和聚合层扩展性限制，表明 OpenTelemetry 在超大规模指标场景下并非即插即用的完美方案，仍需针对性开发自定义处理器（如 Atlassian 开源的增量聚合处理器）。开发者在规划迁移时，不能仅依赖开源社区标准组件，需评估自身数据规模并准备相应的定制开发资源。此外，Atlassian 将 sidecar 资源消耗降低约 30% 的成果，提示了通过整合指标与追踪 sidecar 可显著优化微服务架构中的资源效率，这对成本敏感的云原生架构设计具有直接的经济价值参考。

适用边界

Atlassian 的迁移方法论主要适用于拥有成熟内部指标平台、且希望向 OpenTelemetry 生态收敛的大型科技企业。其核心前提是存在足够规模的工程团队来支撑自定义 Collector 发行版的开发与维护，以及处理有状态聚合器的复杂性。对于中小型企业，若缺乏开发自定义聚合处理器和负载均衡导出的能力，直接套用此方案可能会因有状态聚合层的扩展性瓶颈而遭遇性能退化。此外，该方法论假设业务方愿意接受平台团队主导的底层变更，若组织内存在强推应用代码标准化迁移的文化，这种保留 StatsD 接口的兼容策略可能不被视为最佳实践，反而可能延缓应用层向纯 OpenTelemetry SDK 的演进。对于数据规模远小于 Atlassian（如每分钟数据点少于 1 亿）的场景，引入如此复杂的四层架构和自定义处理器可能带来不必要的维护复杂度，更简单的方案或许更为合适。

孤本观察

Atlassian 的选择揭示了一个关键现实：在超大规模可观测性场景中，“保留旧接口”往往是比“强制应用迁移”更低风险且更高效的策略，因为基础设施层面的重构速度远超应用层面的协调成本。其将指标侧车与追踪侧车整合从而节省 3.9% CPU 的做法，也暗示了未来可观测性数据平面趋向于“统一采集入口、差异化后端处理”的架构演进方向。

来源：InfoQ 中文 AI