软件迁移至开源可观测平台更快。核心步骤：重定向数据、转换查询告警、双运行验证。目标：降低成本、增强控制、标准化，实现未来轻松变更。
译自：A Guide to Safe, Incremental Open Source Observability Migration
作者：Marjorie Freeman
当人们听到“软件迁移”或“摆脱专有代理的迁移”时，他们会想到数月复制仪表盘、重写告警、重新部署代理以及高风险切换，其中可能会遗漏关键内容。
现实呢？随着各种开源工具的出现，迁移可能只需数周，而非数月或数年。开源可以帮助你横向转移和过渡。这将使你无需更改应用级插桩，只需进行可管理的查询变更，即可过渡到符合开放标准、厂商管理的可观测性平台，同时保留数据可移植性。
大多数组织已经完成了大部分工作
许多组织已经拥有或正在转向如下架构：
你的采集层已经开放且可移植。只有后端是专有的。
从厂商管理的架构进行迁移
你正在“开源优先、厂商管理”的架构中运行，这意味着你无需重新插桩；你需要重新归宿。
- 重定向你的数据管道到新后端（先在预生产环境，然后是生产环境）。
- 转换团队实际依赖的查询、仪表盘和告警。
- 双运行两个系统，直到你信任新系统，然后逐步减少旧后端。
这并非要重新发明你的插桩；而是要改变你的遥测数据落脚点以及如何查询它。完成这一转变的团队报告称获得了更好的控制和更低的成本。例如，Chronosphere客户报告减少了60%-80%的低价值数据量，同时通过改进的聚合和保留控制保持或提高了可见性。
以下是安全、增量地执行横向转移的实际步骤，让迁移感觉像是下一步，而非一次飞跃。
如何从专有可观测性平台进行迁移
本指南将详细介绍如何迁移到兼容开放标准的平台，而不会中断运营。
规划：明确“成功”的含义
在开始迁移之前，请明确你的目标：
- 你主要想降低成本吗？
- 你想要更好地控制数据保留和聚合吗？
- 你是否想在所有团队中标准化使用 PromQL 和开放 API？
记录三件事：
- 第一波迁移涉及哪些服务（理想情况下，先从影响较小的服务开始）？
- 哪些团队拥有这些服务，并将负责验证和批准？
- 哪些仪表盘和告警是日常运营不可或缺的；其他都是次要的。
这份文档将成为你在跨团队工作中确定优先级的指南针。
迁移步骤
第1步：优先处理真正重要的事项
在清点所有事物之前，先确定你实际需要迁移什么：
创建一份重点列表：
- 值班工程师在事件期间实际使用的10到20个仪表盘，站点可靠性工程师 (SRE) 用于服务水平目标 (SLO) 审查的仪表盘，或领导在每周会议上依赖的仪表盘。
- 晚上会呼叫某人、出现在运行手册中或保护营收关键服务的20到50个告警。
将这些视为第一阶段的迁移工件。其他一切都可以等待。
对于每个仪表盘和告警，记录：
- 它在你当前平台中的位置（URL、文件夹、所有者）。
- 哪些团队拥有并依赖它。
- 任何已知怪癖（“这个告警噪音多”、“我们忽略那个面板”），以便在迁移期间由合适的人员进行验证和批准。
了解哪些数据真正驱动决策至关重要。团队经常发现他们正在付费存储大量无人使用的遥测数据。
第2步：清点你的遥测数据
你无法移动尚未映射的事物。对于范围内的服务，记录遥测数据的来源和流向。
- 指标：它们来自 Prometheus 抓取、导出器（节点、Kubernetes、数据库、云）还是通过 Prometheus 客户端库的自定义指标？它们如何到达你当前的平台（原生远程写入、边车收集器或厂商专用网关）？
- 追踪：服务是否使用 OpenTelemetry SDK 或自动插桩？追踪是否经过OpenTelemetry 收集器或厂商代理？
- 日志：日志如何发送——中央日志管道还是多个边车？
第3步：将新后端添加为第二个目的地
无需完全淘汰你当前的平台，而是将新后端作为部分服务的影子目的地引入。首先在预生产环境中部署此配置以验证行为，然后一旦看起来没问题，就将其提升到生产环境。
你一次性更改的内容越少，验证行为就越容易。
指标
如果你正在使用 Prometheus 远程写入，请添加第二个指向新后端的远程写入端点（或首先重新指向非关键服务）。如果你正在使用 Prometheus 服务器进行抓取，请重新配置它们以写入新后端，或使用远程写入或联邦方式镜像抓取的数据。
如果你的新平台兼容 Prometheus，这主要是布线工作；你正在将现有流量重定向到不同的端点，而不是重建你的管道。
追踪
使用 OpenTelemetry Collector，添加一个额外的导出器管道，并行发送追踪到新后端（OpenTelemetry Protocol → 新后端）。尽量保持配置与你现有的追踪管道相似，以便在双运行期间进行直接比较。
原生支持 OpenTelemetry Protocol (OTLP) 的平台使得这一切变得简单；你只需重复使用你已经信任的 OpenTelemetry 导出器和处理器。
日志
如果使用 Fluent Bit，添加另一个输出，将日志发送到新后端的摄取端点。如果你已经有中央日志管道或路由器，则可以从那里进行扇出，而不是触及每个应用程序 Pod。
一些托管平台提供基于 OSS 组件的中央“遥测管道”服务，让你可以在一个地方管理路由，而不是编辑数十个 DaemonSet 配置。
关注双运行的成本
并行运行旧系统和新系统会暂时增加遥测数据量和成本。远程写入扇出和复制追踪/日志意味着将相同的数据发送到多个目的地。如果将此阶段范围限定为有限的服务集，你可以在不造成大量成本激增的情况下验证行为。
此时，新后端接收与你当前平台相同的指标、追踪和日志，但尚未移动任何仪表盘或告警。你只是在复制数据流。
第4步：转换查询和仪表盘
首先关注核心查询
大多数专有平台要么使用类似 PromQL 的语言，要么在 Prometheus 风格的时间序列和标签上运行自己的 DSL。你的新后端应提供 PromQL 兼容性或清晰的映射。
从80%的使用案例开始：
- 简单时间序列：带有
{env="prod", service="api"} 等过滤器的单个指标 - 基本聚合：
sum、avg、max、histogram_quantile - 标签 → label 映射：
env:prod→{env="prod"}
只有在这些稳固之后，再处理：
- 跨指标算术
- 连接和多序列表达式
- 厂商专用或“魔术”函数
如果你的新平台提供了查询转换器、PromQL 兼容层或 DSL 转换工具，请使用它们处理边缘情况，而不是手动移植所有内容。
只重建关键仪表盘
使用第3步中的优先级列表作为范围。
对于每个仪表盘：
- 从你的平台导出仪表盘定义（JSON/YAML/Terraform/等）。
- 在新后端中，使用翻译后的查询和等效的面板类型（时间序列、表格、单一统计信息）重新创建它。
- 保留布局和名称，以便值班工程师在事件期间无需重新学习肌肉记忆。
为了避免一次性工作，为每种服务类型（API、作业、数据管道）定义一些黄金模板，并使用标签/变量（服务、环境、区域）对其进行参数化以实现重用。
结果：你最重要的仪表盘和查询在新后端中行为相同，对依赖它们的人来说惊喜最小。
第5步：迁移告警而不错失覆盖
告警是风险所在——请谨慎对待。大多数平台将告警表示为查询、评估窗口和通知目标。
翻译查询以实现行为一致性
重用第4步的工作。对于每个告警，翻译描述条件的 PromQL 查询（或等效查询）。映射阈值和窗口。如果旧告警说“如果超过 80 持续 5 分钟则触发”，请确保新规则使用范围向量或告警窗口表达相同的逻辑。
在此阶段，你的目标是行为一致性，而不是重新设计。
最初保持路由简单
将现有的 Slack/PagerDuty/电子邮件目的地映射到新后端中的等效通道。尽可能地镜像当前行为，以便团队可以一对一地比较告警。将路由或升级的重新设计推迟到双运行稳定之后。
从必须有的告警开始。一旦这些告警稳定并且双运行良好，你就可以决定哪些优先级较低的告警值得迁移。
第6步：双运行和验证
此时，范围内的服务将相同的遥测数据发送到两个后端，并且你的关键仪表盘和告警在新系统中存在。现在，在真实条件下进行验证。
将你当前的平台作为主要事实来源。鼓励值班工程师在新仪表盘旁边打开旧仪表盘。当告警触发时，检查新后端中相应的告警是否也触发了，并比较时间线和严重性。这个验证阶段至关重要。正确评估可观测性厂商意味着确认它在真实生产条件下运行良好，而不仅仅是测试场景。
在此阶段，你主要检查：
- 缺失：在旧系统中触发但在新系统中未触发的告警。
- 额外噪音：在新系统中触发更频繁或相关性更低的告警。
- 用户体验问题：在压力下难以找到或解释的面板。
将问题记录在共享文档或工单队列中，以便你可以系统地解决它们。双运行足够长的时间以观察几次真实事件，而不仅仅是合成测试。一旦这些在新后端中感觉平静无事，并且拥有团队已经为该波次验证和批准，你就可以继续前进了。
第7步：逐步转向新系统
一旦团队感到满意，更新运行手册和文档，使链接和截图指向新后端。将新 UI 设置为值班轮换的默认视图，将旧平台视为备份。
接下来，关闭旧系统中的告警：
- 首先静音或降级那里的信息性告警。
- 在几次顺利的事件之后，禁用分页告警，这样你就不会因同一个问题而被呼叫两次。
- 最后，减少然后停止对已完全迁移服务的摄取。
许多团队会将旧后端保持在只读模式一段明确的历史时间窗口，然后一旦不再需要该数据就将其淘汰。届时，新平台将是你的运营事实来源。
迁移应该枯燥无味
这种横向转移的真正胜利不仅仅是降低成本或更漂亮的仪表盘，它在于掌控你的可观测性语义。你的指标采用 Prometheus 风格的格式。你的追踪和日志遵循 OpenTelemetry。你的仪表盘基于开放或有良好文档的 schema。你的告警以不与特定公司 UI 绑定的查询语言和规则模型表达。
这意味着：如果你将来需要再次更换厂商，你不会从零开始。如果你想让你的部分堆栈自托管，部分托管，你可以做到。如果你的平台团队想在你的可观测性数据之上构建内部工具，他们可以依赖稳定、开放的接口。
Mordor Intelligence 的研究表明，平均企业管理着五个或更多监控工具，即使遥测格式是开放的，专有查询语言也限制了迁移。这是许多组织将 OpenTelemetry 视为厂商无关增长的强大推动者的主要原因。
换句话说，这次迁移应该是最后一次痛苦的迁移。在此之后，可观测性变更将是迭代的。这是关于配置，而不是再发明。
让这成为你最后一次（也是最好的一次）迁移
如果你的遥测数据已经基于开放标准构建，那么你已经完成了最繁重的工作。摆在你面前的是一个受控的、增量式的过渡，它将为你带来长期的成功——而不是一次冒险的全面改革。现在采取这一步意味着用厂商锁定和不断上涨的成本换取一个可观测性基础，它将以你想要的方式、按你自己的条件精确地成长和发展。
