OpenTelemetry 无处不在：大规模迁移指标平台
内容提要
Atlassian将运行近十年的gostatsd指标管道迁移至OpenTelemetry Collector，保留StatsD接口，仅重建采集、接收、聚合、转发四个后端阶段。迁移后每服务CPU降低约3.9%，聚合层CPU减半，并开源了增量聚合处理器。下一步推动用户改用OTel SDK。
延伸解读
迁移策略：接口不变，后端重建
Atlassian 没有要求所有团队立即改用 OTel SDK，而是保留 StatsD over UDP 接口，仅重建采集、接收、聚合、转发四个后端阶段。这样将组织级迁移转化为平台团队内部工作，避免服务团队重新插桩。采集端同时支持 StatsD 和 OTLP，使迁移期间新旧数据源可并行，降低了业务中断风险。
聚合层优化：从热分片到均匀分布
聚合是有状态的，同一时间序列必须路由到同一分片。原有基于服务哈希的路由导致大服务所在分片过热。改用 contrib 的 loadbalancingexporter 按 streamID 哈希后，单个大服务的序列均匀分散到整个池，同时保证每个序列仍固定落在同一分片。效果是分片 CPU 分布变平，自动扩缩容带宽更紧，可真正在低谷缩容，并减少热分片告警。
成本收益：CPU 降低与资源释放
迁移后每服务 CPU 平均降低约 3.9%，聚合层 CPU 减半。聚合阶段将每分钟约 48 亿数据点降至约 2.2 亿，减少约 96%。此外，gostatsd 聚合器和 nomad 合计占指标集群 CPU 请求的约 38%，其中 nomad 单独占约 13% 总资源。移除这些组件可释放显著资源，是迁移的重要经济动机。
实施建议：渐进式与生产环境验证
Atlassian 建议选择受益最大且愿意配合的早期采用者，从开发、测试环境及痛点最深的服务开始。持续在生产环境进行性能分析，因为组件真实开销只在生产负载下显现。保持新旧系统操作原语一致，降低并行运维负担。采用渐进式发布，按 1%→10%→50%→100% 逐步放量，在低成本环境暴露问题，避免影响关键路径。
Q&A
Atlassian 为什么决定将指标管道从 gostatsd 迁移到 OpenTelemetry？
因为社区持续向 OpenTelemetry 收敛，越来越多的数据源发出 OTel 数据而 gostatsd 不支持；gostatsd 仅支持 UDP，没有 traces 和 logs 方案，且 OTel Collector 社区的新功能需要手动重建才能保持同步，继续维护旧管道将无法跟上发展。
迁移过程中如何避免对 Atlassian 内部服务造成大规模影响？
保留服务所有者看到的 StatsD over UDP 接口不变，仅重建采集、接收、聚合、转发四个后端阶段，将组织级迁移转变为平台团队迁移；同时让采集端同时支持 StatsD 和 OTLP，服务无需更换 SDK 即可开始迁移。
迁移后 Atlassian 的指标管道在性能和成本上有哪些具体收益？
每服务 CPU 平均降低约 3.9%，在昂贵的 Micros 服务上 sidecar 成本降低约 30%；聚合层 CPU 减半；每分片 CPU 分布均匀，自动扩缩容更紧凑，可真正在非高峰缩容；移除 gostatsd 聚合器和 nomad 可释放约 38% 的 CPU 请求。
Atlassian 在聚合阶段如何处理 48 亿数据点并实现 96% 的削减？
他们编写并开源了 delta 聚合处理器（atlassian-labs），因为大多数指标是 delta 时序且上游没有按用户期望的方式聚合 delta；该处理器将每分钟约 48 亿数据点聚合为约 2.2 亿，减少约 96%。
Atlassian 如何解决聚合层因服务负载不均导致的热分片问题？
原先使用内部代理 nomad 按 (service, environment) 哈希分片，但服务负载长尾导致热分片；改用 contrib loadbalancingexporter 按 streamID（单个时间序列标识）哈希，使大服务均匀分散到池中，同时保证同一序列始终落在同一分片，从而消除热分片。
Atlassian 在迁移过程中总结了哪些经验教训？
选择早期采用者：找受益最大且愿意迭代的团队，从开发和预发环境及痛点最大的服务开始；持续在生产环境 profiling：真实成本和行为只在生产负载下显现；匹配运维工作流：新旧系统并行数月甚至数年，保持操作原语一致；渐进式发布：从低环境和非关键服务开始，按 1% → 10% → 50% → 100% 逐步推进。
迁移完成后，Atlassian 下一步的计划是什么？
下一步是左移：将指标插桩迁移到 OpenTelemetry SDK，摆脱多年来使用的供应商和内部客户端（Datadog/DogStatsD、StatsD 库）；同时进一步探索 OpenTelemetry 生态以解决大规模可观测性问题，并随着使用和规模增长回馈社区。
