从 Elasticsearch 迁移到国产可观测平台：评估、迁移与验收清单

迁移前先摸底：数据量、查询习惯、合规要求

迁移日志平台最大的风险不是技术，而是「迁过去之后发现不好用」。所以在动手前，先花一周摸底三件事：

1. 数据量：每天日志量多少 GB、峰值多少、要保留多少天。这决定存储规格和归档策略，也直接影响成本估算。
2. 查询习惯：把现有 Kibana 的常用查询、看板、告警规则导出，统计哪些字段被频繁过滤（如 level、service、trace_id），迁移后优先保障这些字段的检索体验。
3. 合规要求：日志留存年限、是否允许外发、是否需要审计留痕。政企场景里这些是硬约束，直接决定部署形态。

摸底输出一份清单，作为后面验收的对照表，别凭感觉拍板。一个常见错误是只按磁盘容量估算规模——检索慢到 30 秒才出结果，比磁盘小更伤体验。把查询时延预期也写下来，比如「TOP-N 错误查询 90 分位要在 2 秒内返回」，这是可量化的验收目标。

国产软硬件栈评估

迁移不只是换个软件，往往是整套技术栈国产化的一个环节。炬鲸 OBSERVE 基于 Go 编写，单二进制交付，对国产环境的适配成本低。典型组合：

• 服务器：鲲鹏 920 / 飞腾 2000+ 等 ARM 服务器
• 操作系统：麒麟 V10（ARM）或统信 UOS
• 数据库：MySQL 8，或 OceanBase / 达梦的 MySQL 兼容模式，协议层零改动对接

评估时重点关注三点：ARM 架构下的写入与检索性能是否达标、数据库驱动兼容性、以及厂商是否提供信创环境的适配与测试报告。别只看参数表，要拿自己真实的数据量跑一轮压测，观察采集吞吐和查询时延。ARM 服务器扛日志采集没问题，但正则密集的解析这类 CPU 密集操作和 x86 表现可能有差异，务必用生产同款解析规则测一遍。

双写过渡，别搞一次性切库

直接停机迁移风险高，推荐「双写 + 灰度切换」：

1. 日志采集端（Filebeat / Vector / OTel Collector）同时向旧 ES 和新平台推送
2. 新平台跑通查询、告警、看板后，让一部分团队先切到新平台用一周
3. 灰度期间对比两边查询结果，确认无漏数据后，再逐步关掉旧 ES 的写入
4. 保留旧 ES 只读一段时间，作为回滚兜底

双写期间注意存储成本和采集端资源开销。采集组件要选支持多输出、可热加载配置的——Vector 和 OTel Collector 都支持，改输出不用重启进程。一个实用建议：灰度先从一个偏「读」的团队（如 NOC、支持组）开始，而不是告警写得最多的团队，先验证检索体验，再验证告警可靠性。

验收清单与回滚预案

迁移完成的验收至少覆盖这几项：

• 日志检索：常用查询语法转换后能跑通，结果一致
• 链路追踪：采样率、trace 关联日志正常
• 告警：规则迁移后能正常触发，通知通道可用
• 权限：租户、角色、数据隔离符合原有策略
• 数据一致性：抽样对比新旧平台，无丢失、无错乱

回滚预案同样要提前写：保留旧 ES 只读至少两周，明确回滚触发条件（如新平台连续 30 分钟不可用、关键查询结果偏差），并演练一次回滚流程。迁移的终点不是「数据搬过去了」，而是「出问题时能快速退回」。