Atlassian 围绕 OpenTelemetry Collector 重建了其指标平台，但在初期没有要求服务团队改变指标发送方式。公司没有先移除旧管道，再重新配置数千项服务，而是保留了基于 UDP 的 StatsD 接口，并逐步替换其背后的聚合、处理和路由层。
在过去的大部分十年中，该平台一直依赖 gostatsd。这是一款由 Atlassian 开发的开源 StatsD 应用，既作为主机上的边车代理运行，也作为另一端的聚合层运行。根据服务级别目标，该平台处理来自约 10 万台主机的指标，这些主机分布在 14 个区域，目标可用性为 99.95%，并要求保持较低延迟。
更换引擎，同时保持契约不变
Atlassian 的团队认为，在更改基础设施之前，先重新配置每项服务以使用 OpenTelemetry SDK 将是一个持续多年的过程，并可能导致依赖这些数据的告警丢失。因此，平台接口与内部组件被分离：服务继续使用同一地址并以 StatsD 格式通信，而内部层则逐步替换为定制的 OpenTelemetry Collector 发行版。
该设计采用四个独立阶段：采集、接收、聚合和路由。采集层还能够同时接收 StatsD 和 OTLP。这样，无需强制团队更换客户端库即可开始迁移，同时也为原生使用 OpenTelemetry 创建的指标打开了通道。
实际发生了哪些变化？
在采集阶段，原先的 gostatsd 边车代理被 OpenTelemetry Collector 发行版替换；该发行版此前已由跟踪团队使用，同时应用仍保持原有行为。这样，指标和跟踪便可合并到一个边车代理中，而不必在每台主机上运行两个代理。
Atlassian 表示，在成本最高的 Micros 服务中，此次合并使每项服务的 CPU 使用量平均降低了约 3.9%，相当于整个集群的边车代理成本降低了约 30%。此外，公司还添加了 OTLP 接收器，使采集层能够接收 OpenTelemetry 指标并直接转发。
在接收阶段，核心问题与时间序列状态有关。属于同一时间序列的每个数据点都必须发送到同一个聚合器。旧系统通过一个名为 nomad 的内部代理，采用基于服务和环境二元组的分片方式。但服务规模的差异导致一些聚合器过热，而另一些使用率很低。
Atlassian 使用 OpenTelemetry 仓库中的 loadbalancingexporter 组件解决了这一问题，并按照 streamID（即单个时间序列的身份）进行分片。该方法能够将大型服务的数据分配到多个聚合器，同时让同一条时间序列始终留在同一个聚合器上。因此，聚合器之间的 CPU 分布更加均衡，自动扩展能力得到改善，高负载告警也有所减少。
在聚合层降低数据量和成本
聚合层每分钟处理约 48 亿个数据点，但只存储约 2.2 亿个数据点，降幅约为 96%。由于大多数指标使用 delta temporality，而此前的组件没有按照用户预期的方式聚合这些差值，Atlassian 开发了一个专用处理器，用于聚合指标增量，并以 atlassian-labs 名义将其开源。
迁移之后，聚合层所需的 CPU 大约只有此前的一半。来源将这一改进归因于多个因素，包括不再解析 gostatsd 格式、更好的负载分配，以及受益于 OpenTelemetry 社区的改进。
在最后阶段，一个定制的内部路由器被无状态的 Collector 发行版替换，公司将其命名为 metrics-gateway。该发行版依赖 upstream 导出器，支持向 SignalFx 和 S3 等多个目标发送数据，并具备重试、队列和背压控制能力。根据公布的设计，新增目标将变成配置变更，而不再是独立的集成项目。
渐进式迁移的经验
- 从合适的团队开始：Atlassian 选择了开发和测试环境，以及受相关问题影响最严重的服务，以便在敏感度较低的范围内获得早期反馈。
- 持续监控生产环境：在生产负载下进行 profiling，揭示了组件的行为和成本，而小规模测试或人工基准测试无法提供这些信息。
- 保持运营对称性：由于迁移可能在并行运行两套系统的情况下持续数月或数年，公司建议尽可能保留共用的工具和运营流程。
- 分阶段扩大范围：部署过程采用渐进式比例，从 1% 开始，然后扩大到 10% 和 50%，最终达到 100%；同时先在敏感度较低的服务中测试问题，再处理关键路径。
为什么这种方法很重要？
这次实践表明，在基础设施中采用新标准，并不一定要求所有使用方同时更改接口。保持外部契约不变，将迁移从涉及所有团队的组织性项目，转变为由基础设施平台主导的项目，同时逐步为 OTLP 和 OpenTelemetry 组件提供使用空间。
Atlassian 指出，gostatsd 和 nomad 合计约占指标集群 CPU 请求量的 38%，其中 nomad 单独约占总资源的 13%。因此，迁移的影响不仅在于统一工具，还在于移除成本高昂的定制组件，并减少需要内部维护的部件数量。
不过，这并不意味着服务 instrumenting 层面的迁移已经完成。公司提到的下一步是将 instrumenting 工具本身迁移到 OpenTelemetry SDK，并逐步放弃仍在使用的 Datadog 和 DogStatsD 客户端以及内部 StatsD 库。此外，这里提供的性能结果和数字描述的是 Atlassian 在其自身环境中的实践，并不保证相同数值会在每种监控架构中重现。