本文详细介绍了使用Prometheus、OpenTelemetry和Fluent Bit等开放标准，分步迁移可观测性平台的指南。强调增量迁移、双轨运行验证和逐步切换，以降低风险并确保持续可见性。
译自：Observability platform migration guide: Prometheus, OpenTelemetry, and Fluent Bit
作者：Katie Greenley
可观测性平台迁移通常不简单。您仍然需要在风险（避免中断值班）、范围（不要试图一次性迁移所有内容）和组织变革（让团队验证并采用新工作流程）之间取得平衡。本文旨在分享在准备使用开放标准工具进行迁移时，使其变得可管理的常见模式。
我们将重点关注那些指标、追踪和日志已通过Prometheus、OpenTelemetry (OTLP) 和 Fluent Bit 等开源和开放标准工具流动的迁移场景。在这些环境中，您通常可以通过重新路由管道、只迁移最重要的仪表板和警报，以及双轨运行直到您信任切换来完成迁移。
“开放标准可以简化迁移路径，但实现开放标准本身可能就是一场迁移浪潮。”
如果您的环境目前没有开放标准工具，那么还有一个额外的步骤：重新部署工具。当您使用专有代理、SDK或封闭式摄取格式时，迁移平台通常意味着在所有服务中替换工具——这项工作可能需要数周甚至数月，具体取决于集群规模、发布频率和覆盖要求。换句话说，开放标准可以简化迁移路径，但实现开放标准本身可能就是一场迁移浪潮。
接下来，我们将逐步介绍团队用来安全迁移并在此过程中保持可见性完好的最可靠模式。
如何使用开源工具进行迁移
规划：定义“成功”的含义
在开始迁移之前，请记录三件事：
- 第一波迁移涉及哪些服务（理想情况下，首先是影响较小的服务）？
- 哪些团队拥有这些服务，并将负责验证和批准？
- 哪些仪表板和警报对于日常运营来说是不可或缺的；其他一切都是次要的。
这份文档将成为您跨团队工作优先级排序的指引。
迁移步骤
步骤1：优先处理真正重要的内容
在您清点所有内容之前，请确定您真正需要迁移的内容。
创建重点清单：
- 识别值班工程师在事件中实际使用的仪表板，站点可靠性工程师 (SRE) 在服务水平目标 (SLO) 审查中参考的仪表板，或领导层在每周会议中依赖的仪表板。通常，您会剩下10-20个仪表板。
- 记录那些会在夜间呼叫某人、出现在操作手册中或保护收入关键服务的警报。通常，您会剩下20-50个警报。
将这些视为第一阶段的迁移成果。其他一切都可以等待。
对于每个仪表板和警报，请记录：
- 它在您当前平台中的位置（URL、文件夹、所有者）。
- 哪些团队拥有并依赖它。
- 任何已知的问题（“这个警报噪音很大”，“我们忽略那个面板”），以便正确的人员在迁移期间进行验证和批准。
了解哪些数据真正驱动决策至关重要。团队经常发现他们正在付费存储大量无人使用的遥测数据。
步骤2：盘点您的遥测数据
未映射的内容无法迁移。对于在范围内的服务，请记录遥测数据的来源以及它如何流经您现有的开源基础设施。
- 指标：您的Prometheus设置是如何配置的？记录哪些服务由Prometheus服务器直接抓取，哪些服务使用导出器（节点、Kubernetes、数据库、云）。映射指标如何到达您当前的平台——您是使用原生的远程写入、多个远程写入端点，还是Prometheus实例之间的联邦？
- 追踪：审查您的OpenTelemetry工具。哪些服务使用OpenTelemetry SDK，哪些使用自动工具？映射从已部署工具的服务通过OpenTelemetry Collectors到您当前后端的数据流。记录您的收集器管道中的任何处理器、采样器或转换。
- 日志：记录您的Fluent Bit配置。日志是从哪里收集的，以及当前使用了哪些输出插件？如果您正在使用集中式日志管道或路由器，请了解数据如何流经该架构。
“了解您当前的数据路由，这样您就可以自信地将新后端添加为并行目的地，而不会中断现有流程。”
这里的目标是了解您当前的数据路由，这样您就可以自信地将新后端添加为并行目的地，而不会中断现有流程。
步骤3：将新后端添加为第二个目的地
与其彻底拆除现有平台，不如将新后端作为部分服务的影子目的地。保持两个系统同时运行，以确保您的团队在整个迁移过程中保持可见性。此外，在完全切换之前，您需要在新的可观测性平台中拥有足够的历史数据。历史数据的量因公司而异，应作为关键考虑因素。
指标
如果您正在使用Prometheus远程写入，请添加第二个指向新后端的远程写入端点（或首先重新指向非关键服务）。如果您使用Prometheus服务器进行抓取，可以重新配置它们以写入新后端，或者使用远程写入或联邦来镜像抓取的数据。
如果您的新平台与Prometheus兼容，这主要是连接工作；您正在将现有流量重定向到不同的端点，而不是重建您的管道。
追踪
使用OpenTelemetry Collector，添加一个额外的导出器管道，将追踪并行发送到新后端（OpenTelemetry Protocol → 新后端）。尽可能保持配置与现有追踪管道相似，以便在双轨运行期间进行直接比较。
原生支持OpenTelemetry Protocol (OTLP) 的平台使这变得简单；您可以重复使用您已经信任的OpenTelemetry导出器和处理器。
日志
如果使用Fluent Bit，添加另一个输出，将日志发送到新后端的摄取端点。如果您已经有集中式日志管道或路由器，可以从那里分流，而不是修改每个应用程序Pod。
步骤4：转换查询和仪表板
首先关注核心查询
大多数专有平台要么使用类似PromQL的语言，要么在Prometheus风格的时序和标签上运行自己的DSL。您的新后端应提供PromQL兼容性或明确的映射。
从80%的用例开始：
-
简单时序：带有过滤器的单个指标，例如
`{env="prod", service="api"`} -
基本聚合：
`sum`, `avg`, `max`, `histogram_quantile` -
标签 → 标签映射：
`env:prod`→ `{env="prod"}`
只有在这些内容稳固后，再处理：
- 跨指标运算
- 连接和多序列表达式
- 供应商特定或“魔术”函数
只重建关键仪表板
使用步骤3中的优先级列表作为范围。
对于每个仪表板：
- 从您的平台导出仪表板定义（JSON/YAML/Terraform/等）。
- 使用翻译后的查询和等效的面板类型（时间序列、表格、单一统计）在新后端中重新创建它。
- 保留布局和名称，以便值班工程师在事件期间无需重新学习肌肉记忆。
为避免一次性工作，为每种服务类型（API、作业、数据管道）定义一些黄金模板，并使用标签/变量（服务、环境、区域）对其进行参数化以供重用。
结果：您最重要的仪表板和查询在新后端中表现相同，对依赖它们的人来说惊喜最小。
步骤5：迁移警报而不丢失覆盖范围
警报是风险所在——请谨慎处理。大多数平台将警报表示为查询、评估窗口和通知目标。
翻译查询以实现行为对等
重用步骤4的工作。对于每个警报，翻译描述条件的PromQL查询（或等效查询）。映射阈值和窗口。如果旧警报规定“如果5分钟内 > 80 则触发”，请确保新规则使用范围向量或警报窗口表达相同的逻辑。
在此阶段，您的目标是行为对等，而不是重新设计。
初期保持路由简单
将现有的Slack/PagerDuty/电子邮件目的地映射到新后端中等效的通道。尽可能模仿当前行为，以便团队可以一对一地比较警报。在双轨运行稳定后，再推迟路由或升级的重新设计。
从必备警报开始。一旦这些警报稳定并 cleanly 双轨运行，您就可以决定哪些优先级较低的警报值得迁移。
步骤6：双轨运行并验证
此时，在范围内的服务将相同的遥测数据发送到两个后端，并且您的关键仪表板和警报在新系统中也存在。现在您将在实际条件下进行验证。
保持当前平台作为主要事实来源。鼓励值班工程师在新旧仪表板旁边打开新的仪表板。当警报触发时，检查新后端中相应的警报是否也触发，并比较时间线和严重程度。这个验证阶段至关重要。正确评估一个可观测性供应商意味着确认它在真实的生产条件下运行良好，而不仅仅是测试场景。
在此阶段，您主要检查以下内容：
- 差距：在旧系统中触发但在新系统中未触发的警报
- 额外噪音：在新系统中更频繁触发或相关性较低的警报
- 用户体验问题：在压力下难以查找或解释的面板
将问题记录在共享文档或工单队列中，以便系统地修复它们。双轨运行足够长的时间，以观察一些真实的事件，而不仅仅是合成测试。一旦这些事件在新后端中感觉平淡无奇，并且所有者团队已对该波次进行验证和批准，您就可以继续前进了。
步骤7：逐步切换到新系统
一旦团队感到舒适，更新操作手册和文档，使链接和截图指向新后端。将新UI设为值班轮换的默认视图，将旧平台视为备份。
接下来，关闭旧系统中的警报：
- 首先在那里静默或降级信息性警报。
- 在几次干净的事件之后，禁用寻呼警报，这样您就不会因为同一个问题而被呼叫两次。
- 最后，减少然后停止对已完全迁移服务的摄取。
许多团队会将旧后端保持在只读模式一段定义好的历史窗口，然后在其中包含的数据不再需要时将其退役。届时，新平台将是您的操作事实来源。
使用开放标准构建您的可观测性基础
在本文中，我们逐步介绍了从一个可观测性平台迁移到下一个平台的核心步骤——无需进行有风险的“彻底替换”。该方法是循序渐进的：定义“成功”的含义，只优先处理真正重要的仪表板和警报，映射您的遥测流，将新后端添加为并行目的地，翻译必要内容，双轨运行以在真实生产条件下进行验证，然后逐步转移流量和所有权。
在Chronosphere，我们还构建了内部工具来帮助自动化此过程的关键部分——从而使迁移更快、更可重复，并减少对工程团队的干扰。当您与Chronosphere合作时，您将获得简化的迁移体验以及定制的入职服务，以帮助规划批次、验证对等性并自信地完成切换。最重要的是，Chronosphere旨在与您已经使用的开放生态系统协同工作。我们完全兼容OpenTelemetry、Prometheus和其他开放标准——因此您可以保留现有的工具和管道，同时按照自己的方式实现后端现代化。
