Atlassian 迁移指标平台至 OpenTelemetry：保留 StatsD-UDP 接口实现零应用改造

Atlassian 将承载 10 万台主机指标的平台从 gostatsd 迁移至 OpenTelemetry，保留 StatsD-UDP 兼容接口，仅重构后端处理逻辑，在保障 99.95% SLO 前提下避免全量应用改造。

兼容层设计使平台迁移与业务 SDK 升级解耦；UDP 接口复用显著降低服务侧改造成本；统一采用 OpenTelemetry 可收敛追踪、日志与指标采集栈。

适合平台工程师、可观测性架构师、SRE 阅读

软件公司 Atlassian 发布了一篇关于从 gostatsd 迁移至 OpenTelemetry 的经验分享。这次迁移替换了其指标平台的内部运行机制。该平台从 14 个区域的约 10 万个主机接收数据。现有服务的 SLO 为 99.95%，因此，团队必须在不影响生产环境告警所用指标的情况下完成平台迁移。

在 CNCF 的一篇博文中，Iris Grace Endozo、Farzad Vazirnia 和 Albert Kerr 解释道，虽然 gostatsd 多年来运行稳定，但其仅支持 UDP 的设计无法处理追踪或日志信息。此外，越来越多的服务开始生成 OpenTelemetry 数据。如果继续使用 gostatsd，那么 Atlassian 将不得不重复开发 OpenTelemetry Collector 社区正在开发的功能。

该团队没有要求将数千个服务立即从 StatsD 客户端迁移到 OpenTelemetry SDK。他们保留了现有的 StatsD-over-UDP 接口，并重构了其背后的处理流程。作者表示，这一做法将原本需要在全组织范围开展的应用程序迁移，转变为由平台团队主导的迁移。

我们保留了接口，并重构了其背后的一切逻辑，从而将一次全组织范围的迁移转变成了平台团队主导的迁移。 Iris Grace Endozo、Farzad Vazirnia 和 Albert Kerr，Atlassian

Atlassian 推出了专为数据采集、摄入、聚合和转发而设计的 Collector 发行版。这一设计贴合 Collector 的管道模型：其中接收器接收数据，处理器对数据进行修改，而导出器则将数据发送至一个或多个目标。该公司将平台划分为四个阶段，使工程师可以只修改其中的一部分，而不替换其他部分。

在数据采集方面，Atlassian 用其追踪团队已经在使用的 Collector 发行版替换了 gostatsd sidecar。应用程序继续将 StatsD 数据包发送到同一地址，而 OTLP 接收器则允许新服务发送 OpenTelemetry 指标。将指标整合到追踪 sidecar 中，平均可以为 Atlassian 每个资源消耗最大的微服务节省 3.9% 的 CPU 资源。该团队估计，整个服务集群的 sidecar 资源消耗因此降低了约 30%。OpenTelemetry 的 Lambda 扩展为无法运行 sidecar 的无服务器工作负载保留了原有的接口。

摄入层则面临着另一个问题，因为指标聚合是有状态的。每个时序数据点都必须到达同一个聚合器。Atlassian 原有的 Nomad 代理会将每个服务和环境通过哈希映射到一个分片，这导致规模最大的服务都集中在少数几个繁忙的副本上。新系统使用 OpenTelemetry contrib 负载均衡导出器，通过流 ID 进行哈希分片，既可以保证单个时间序列的数据不会分散，又能将大服务的负载分布到整个副本池中。根据 Atlassian 的报告，CPU 负载分布更加均衡，热点分片数量减少，而且非高峰时段的扩展性也得到了改善。

聚合处理使数据量大幅减少。该平台每分钟接收约 48 亿个数据点，实际存储约 2.2 亿个，减少了约 96%。鉴于上游组件未能按照 Atlassian 的要求对增量指标进行聚合，该公司开发并开源了自己的聚合处理器。在使用经过调整的架构处理相同的流量时，CPU 占用量大约仅为原来的一半。

小范围的测试和基准测试远远不够；只有持续不断地在生产环境中进行性能分析，我们才能真正地知道该在哪里进行优化。 Iris Grace Endozo、Farzad Vazirnia 和 Albert Kerr，Atlassian

该迁移指南侧重于运维实践。Atlassian 首先从开发和预发布工作负载入手，挑选了能够从中获益的早期采用者，随后通过 1%、10%、50% 和 100% 这几个阶段逐步扩大部署范围。该团队还建议，要在新旧系统并行运行期间保持原来熟悉的运维工作流，并在生产负载下进行性能分析，而非依赖小规模的基准测试。Atlassian 表示，在他们的指标集群中，gostatsd 聚合和 nomad 约占 CPU 请求量的 38%，其中 nomad 单项就占用了全部资源的约 13%。将它们移除便可以完成端到端的 OpenTelemetry 管道构建。下一步计划是将应用程序的代码监控方案从 StatsD、DogStatsD 和供应商客户端迁移到 OpenTelemetry SDK。

在最后阶段，Atlassian 用一个名为 metrics-gateway 的无状态 Collector 分布式系统取代了原有的定制化转发服务。现在，上游导出器将数据分发到包括 SignalFx 和 S3 在内的各个目标，而 Collector 则提供重试、排队和反压功能。作者表示，现在只需要更改配置就可以添加一个新目标，而不用启动一个独立的集成项目。

这种方法与 Airbnb 最近开展的 OpenTelemetry 指标迁移略有不同。Airbnb 采用了来自共享指标库的双路上报机制，并选择了 VictoriaMetrics 的 vmagent 进行流式聚合，最终实现了每秒处理超过 1 亿个样本的性能。而 Atlassian 则保留了 StatsD 端点，同时迁移了其下游的数据管道。这两个项目都将应用程序的迁移与核心基础设施的替换分开了。

InfoQ 此前关于 Skyscanner 全面改造可观测性的报道描述了另一种路径。Skyscanner 将监控代码和传输机制在 OpenTelemetry 上做了标准化，并在随后通过更新一个通用库将 300 多个微服务迁移到了这个平台。Atlassian 的兼容层针对的是这样一种环境：在其中立即重新部署监控代码将是一个耗时更长且风险更高的项目。

在一份翻译过来的会议报告中，GREE 监控基础设施负责人 Iwahori 认为 Atlassian 的方法是经过了“深思熟虑的”。Iwahori 特别认可其流 ID 路由和自定义增量聚合处理器的设计，但对于有状态聚合层，他提出了一个扩展性方面的实际问题。报告称，Atlassian 的回答表明，这一部分依赖于手动配置。

原文链接：https://www.infoq.com/news/2026/09/atlassian-opentelemetry/