可观测性平台迁移实践：从供应商依赖到自主掌控的经验教训

如何通过一次复杂的大规模可观测性平台迁移，转向内部可观测性平台，获得更好的工具、更一致的数据，并从根本上重塑开发者体验。

可观测性，是指通过指标、日志和链路追踪等数据，了解应用程序的性能与可靠性状态。对任何一家公司的基础设施团队而言，可观测性都是最重要的能力之一。没有一个可靠、成本可控且易于使用的可观测性平台，企业就很难帮助工程师有效评估、支撑和提升应用系统的可靠性。

和许多同类公司一样，我们最初也将可观测性能力交给外部供应商来提供。但随着公司规模不断扩大，我们的需求逐渐与供应商的商业激励产生了偏差。供应商通常按照数据摄入量收费，这导致我们的成本持续上升；但摄入更多数据，并不一定意味着能够更快获得洞察，也不一定能缩短平均检测时间（MTTD）或平均修复时间（MTTR）。

更重要的是，由于无法清晰了解可观测性数据的实际使用情况，我们在改进内部监控工作流、优化可观测性支出方面都受到很大限制。

为了达成目标，我们启动了一项复杂的可观测性迁移计划，几乎重构了指标基础设施的各个关键部分。这是一项极具挑战的工程工作：我们需要替换检测、采集、存储和可视化系统，将原本由第三方供应商托管的可观测性平台，迁移到一个基于开源可观测性技术构建的内部定制化方案上。

这次转型让我们能够全面掌控指标的采集、存储和查询。通过这个项目，我们借助自动化工具，将海量数据迁移到新的体系中，覆盖约 1000 个服务、3 亿条时间序列、3100 个仪表盘，以及超过 30 万条告警。

如此规模的迁移当然并不容易。但由于旧体系在数据处理和使用洞察方面存在诸多限制，我们已经别无选择。

虽然不存在一套放之四海而皆准的大规模系统迁移指南，但我们仍然从这次具体实践中总结出了一些经验，希望能对其他团队有所帮助。本文会先介绍一种看似简单、但最终被证明存在缺陷的迁移方式，再详细说明我们最终采用的成功策略。

我们大约在五年前开始规划这次迁移，并在实施过程中持续调整方案。这段经历让我们积累了宝贵经验，也让我们更清楚地理解了大规模可观测性迁移中的最佳实践与常见陷阱。

迁移 v1：看似合理，但代价很高的做法

第一天就攀登珠穆朗玛峰

在进行大规模迁移时，一个常见策略是优先迁移规模最大、影响最大的服务。提前解决最大的挑战，似乎可以帮助项目团队迅速展示显著成果，增强大家对新基础设施的信心，并向更广泛的团队和利益相关方证明迁移策略可行。

一个引人注目的成功案例，通常也能为后续推广奠定基调。

基于这种思路，我们最初倾向于选择一个复杂服务作为首批迁移对象。例如，这个服务可能存在数据稀疏问题，或者它的指标输出方式与新系统标准并不匹配。我们的设想是：通过迁移这种复杂服务，可以尽早暴露新旧系统之间的差异，并设计出能够模拟旧系统行为的解决方案，从而确保仪表盘和告警在迁移前后看起来基本一致。

但按照这种策略，团队会花费大量时间，只为了让第一个服务顺利运行起来。在这个过程中，可能会出现误报、新旧系统之间仪表盘表现不一致，以及需要大量培训才能让首批用户接受新系统等问题。所有这些成本，都是为了向公司证明这次迁移值得推进。

事实证明，这并不是最好的起点。

同样的行李，更稀薄的空气

系统迁移时，确保用户平稳过渡非常重要。因为对他们来说，迁移本身已经意味着大量变化。

即使旧系统中存在一些本可以修复的缺陷、不准确的查询，或者不理想的仪表盘和告警模式，也需要采用更有策略的方法处理。例如，不要试图在第一次迁移时，一口气解决现有仪表盘和告警中的所有历史问题。

更合理的做法，是先专注于完成向新系统的整体迁移。等所有用户都迁移到统一平台之后，再在第二阶段处理仪表盘和告警的改进问题。

用户真正希望首先完成的，是顺利迁移到新系统。如果迁移过程本身已经充满摩擦，就不应该再通过改变查询语义或重写监控逻辑来进一步增加难度。

文档说明了一切，前提是用户愿意认真读完

为了帮助用户顺利采用新系统，尤其是一个变化较大的系统，提供关于新查询语言和新界面的完整文档当然非常重要。同时，也需要提供充分培训，确保用户能够熟练使用新平台。

理论上，即使是不常使用可观测性平台的用户，也需要熟悉查询语言。它的重要性并不亚于学习任何一门编程语言。掌握这些知识，再结合文档和培训材料，在事件发生时快速诊断问题尤其关键。

但实践中，我们也意识到：不能假设用户一定会主动花大量时间阅读文档，更不能假设他们会在压力很大的故障排查场景中，临时掌握一套新的查询语言。

这也促使我们重新思考迁移策略。

可观测性迁移 v2：从可控目标开始

先设定一个可以实现的目标

选择一个与目标系统高度契合的服务作为首批迁移对象，可以显著减少复杂迁移中常见的干扰和噪音。

如果你的首要目标，是向团队和公司证明迁移的价值，例如降低成本、提升功能或改善体验，那么选择一个易于管理、收益明确的服务就至关重要。

这样的选择可以帮助团队：

• 验证新的存储引擎是否能够处理所需规模，并观察它在真实事件中的表现；
• 提供翻译工具，将现有仪表盘和告警迁移到新系统；
• 投入建设面向用户的文档、教育和培训材料；
• 先向一小部分用户推出新的可视化工具，让他们有时间适应新体验，同时让团队收集用户体验方面的反馈，再进行大规模推广。

成功迁移一个相对简单的服务，可以实现两个目标。

首先，它向项目团队证明：这次迁移在技术和运营层面都是可行的。其次，通过缩小范围并与用户密切合作，它也能帮助团队向公司验证整体迁移策略。

对于这类横跨目标设定、需求拆解、研发排期、开发测试、发布上线和知识沉淀的大规模技术迁移项目，团队也需要有稳定的研发管理体系支撑。例如，PingCode 这类智能化研发管理工具，可以帮助团队把迁移目标、任务推进、研发流程、Wiki 经验沉淀和工具链数据流转串联起来，让复杂迁移不只是依赖个人经验，而是以更自动化、数据化的方式持续推进。

更换供应商通常也意味着需要更换可视化工具，因此这也是尽早发现用户体验差异的好机会。首批用户提供的反馈，对于后续将新工具推广到整个组织非常关键。

迁移查询意图，而不只是翻译查询语句

任何长期运行的指标监控系统，最终都会在不同仪表盘中积累大量不一致的延迟、错误率和其他指标计算方式。

在一个高度开放的可观测性环境中，这几乎不可避免。某些指标计算方式可能本身就是错误的。例如，把本应计算 p95 的结果做了平均，或者把总延迟简单相加。用户很容易构建出有缺陷的查询。如果没有相应保护机制，这些查询结果就可能被当作事实使用。

迁移给了团队一次重新介入工作流的机会。这不是要简单抹掉或重置用户已有的模式，而是要理解他们最初想表达的意图，并将这些意图映射到更标准、更推荐的查询方式上。

[图：将延迟告警表达式重写为 Prometheus 直方图查询。]

基于这一点，我们调整了翻译系统的设计方向：与其做一对一的查询翻译，不如重点理解查询背后的意图。

例如，如果一个查询中包含 p95 计算，我们会忽略叠加在其上的额外聚合，而是返回该指标对应的标准直方图查询。这样做的目标，是帮助用户得到更准确、更一致的结果，而不是机械复刻旧系统中的错误模式。

在实践中，这要求我们引入一个专用的元数据引擎。

在 Prometheus 中，指标类型通常会根据命名约定推断。例如，_total 后缀通常表示计数器。但由于我们选择保留现有指标名称，以避免代码和可观测性数据之间出现不一致，因此仅靠命名规则已经不再可靠。

为了解决这个问题，我们直接在翻译层构建了一个元数据引擎。它会定期扫描所有已知指标，并利用内部标签，例如 otel_metric_type，构建和维护从指标到类型的可靠映射。

这项改变上线后，我们更有信心相信，各个团队能够以准确、一致的方式理解应用程序性能。

PromQL 学习门槛：新的查询语言会让人望而生畏

用户需要时间，才能摆脱在旧系统中形成的使用习惯，这是可以理解的。在某些情况下，新系统创建查询的便利程度，也可能暂时不如旧系统。

在迁移过程中，我们使用翻译工具来缓解用户对新查询语言不熟悉的问题。这个工具可以将给定查询映射到新系统中，帮助用户自助完成迁移。

但是迁移完成后，我们并不希望长期保留新旧查询语言之间的过渡层。因为这会减慢，甚至阻碍用户真正适应新语言。

我们选择 PromQL 作为新系统的查询语言，因此可以直接受益于成熟的生态系统，以及一个文档完善、被广泛理解和使用的查询语言。

为了进一步降低使用门槛，我们将这项能力与内部人工智能工具结合起来，为每个指标提供丰富的语义元数据。例如，这个指标是计数器还是直方图，它的单位是什么，适合使用哪种查询方式。

这些能力结合起来后，智能代理可以在更少人工干预的情况下生成正确的 PromQL 查询，帮助开发者更快理解指标，并更有效地探索数据。这一点在事件调试场景中尤其重要。

[图：一个聊天示例展示如何获取某个 Prometheus 直方图指标的 p95。系统先检查指标信息、确认数据源，再运行 histogram_quantile(0.95, ...) 查询，并给出结果和后续筛选建议。]

因此，用户现在可以在几分钟内完成许多常见任务，例如诊断事件或创建仪表盘。相比过去，这些任务所需时间已经大幅缩短。

告警系统迁移：纠正过时模式的关键时机

随着时间推移，旧系统往往会逐渐被忽视。它的一些功能，或者功能缺失，可能会持续拖累团队生产力。

因此，任何大规模迁移的一个重要价值在于：你可以借此机会重新审视产品的实际使用方式，并发现其他值得改进的地方。

最初，我们对在迁移中引入新概念有些顾虑。但随着首批用户开始使用新系统，我们逐渐意识到，现有告警框架已经非常需要改进。

因此，我们决定提前采用另一个可靠性体验团队在告警编写方面的工作成果，并将其推广为推荐的告警编写体验。

新的告警体验取代了过时系统。它把每一条告警都视为一个开发工作流，而不是一个缺少文档说明的配置文件。

在新框架中，告警以代码形式编写，并提供自动补全、构建器式查询编写辅助、内置回测能力，以及差异比较能力。用户可以在部署之前了解告警在历史上会如何触发，也可以更清晰地分析变更带来的影响。

这与我们最初的策略有所不同。最初，我们希望在大规模迁移阶段尽量保持仪表盘和告警系统不变。但后来我们发现，改进后的告警框架显著提升了迁移成功率。

这一改变帮助用户看到迁移本身的价值，而不仅仅把迁移理解为成本控制或平台掌控。与此同时，新告警系统的集中化特性也简化了流程，减少了整体迁移工作量，降低了用户在迁移任务上需要投入的时间。

结论：可观测性平台迁移如何重塑开发者体验

这次迁移最终远不只是更换存储引擎和部署位置那么简单。

它最初看起来只是一次“系统移植”，但最终演变成我们对可观测性、所有权和开发者体验的一次重新思考。

通过掌控指标从生成到查询的完整生命周期，我们显著提升了系统可靠性。我们从脆弱的手工查询，转向了更规范的模式、更完善的工具，以及可信度更高的告警和仪表盘。

我们在元数据、人工智能工具和现代化编写工作流上的投入，不仅提升了数据准确性，也显著提高了工程师在事件发生时探索问题、分析可能性并做出响应的速度。

同样重要的是，这次迁移重塑了我们与内部用户之间的关系。

当我们不再把核心可观测性问题外包给供应商，就不得不更深入地理解各个团队在真实运营压力下如何使用指标。这种反馈循环极其宝贵，也将继续指导我们下一阶段的投入方向。

自动化在这次迁移中发挥了关键作用，但我们也意识到，单靠自动化是不够的。

如果只是盲目复制现有模式，尤其是那些本身存在缺陷的模式，那么迁移只会把技术债从旧系统搬到新系统。真正产生最大影响的时刻，是我们为了采用更好的默认设置，有意识地打破兼容性，即使这会在短期内带来一些摩擦。

最终，这项工作形成了一套可复制的蓝图。

对于未来的迁移，我们已经更明确地知道，自己真正想要掌控的是什么：工程师编写、阅读和分析数据时所使用的体验与界面。存储引擎和后端系统未来仍然可能发生变化，但确保可观测性可用、可信且可扩展的责任，应该始终牢牢掌握在我们自己手中。

即使对于目前没有迁移需求的团队来说，现在也值得采取一些措施，减少未来可能出现的摩擦。

其中最有效的一点，是掌控交互层，也就是工程师用来探索和处理可观测性数据的前端、编写工具和工作流。

在我们的迁移过程中，我们不仅需要更换后端系统，还必须将每个团队迁移到新的可视化工具和新的告警框架上。这显著增加了切换成本。如果我们此前已经掌控这些交互点，后端迁移就会简单得多，也更容易循序渐进地推进。

每个组织面临的限制都不相同。但我们希望，这些经验教训能够帮助其他团队把大规模迁移看作一次难得的机会，而不只是一个不得不完成的负担。

如果处理得当，迁移不仅可以替换系统，还可以真正改进系统，并最终改善整个组织的可观测性水平。

致谢

我们由衷感谢参与这次迁移的各个团队，感谢他们为项目成功所做出的重要贡献。

感谢可观测性团队在新可观测性系统迁移中发挥的关键作用。

感谢可靠性体验团队开发新的告警框架，为迁移成功提供了重要支持。

最后，也感谢所有参与迁移、提供反馈并帮助新系统落地的同事。