从 ELK 迁移到信创可观测平台：数据与告警平滑过渡实录

为什么要迁，以及难在哪

自建 ELK 的团队最怕两件事：一是 Elasticsearch 集群扩容和索引管理吃掉大量人力，二是信创合规要求日志数据落到国产软硬件。迁移的难点不在“把数据搬过去”，而在“搬的过程中业务不能断、告警不能丢、历史日志还能查”。

三步过渡：双写、校验、切换

1. 双写过渡：先在应用侧同时往 ELK 和炬鲸 OBSERVE 各写一份日志，观察一到两周，确认新平台的日志量、字段、时间戳与 ELK 一致。这个阶段 ELK 仍是“主”，新平台是“影子”。
2. 校验比对：用脚本抽样比对两个平台的日志条数和关键字段，重点看多行日志、JSON 结构、时区这三类最容易对不上的点。
3. 切换：验证通过后，把采集端（Filebeat / OpenTelemetry Agent）的上报地址指向新平台，停掉 ELK 侧的写入。ELK 保留只读一段时间作为兜底。

历史数据怎么办

历史日志不必全量搬。按合规要求的保留期（常见 90 天 / 180 天），把热数据迁移到新平台，冷数据导出到对象存储归档，需要时再回灌。全量搬迁 ELK 的索引既慢又贵，绝大多数查询都集中在最近几周，冷热分层才是正解。

告警规则平移

Kibana Watcher 和 ElastAlert 的规则不能直接复用，需要逐条翻译成新平台的 YAML 规则。建议按触发频率排序，先把“最近 30 天触发过”的规则平移，死规则直接丢弃：

alert_rules:
  - name: error-log-burst
    expr: count(logs, level='ERROR', window='5m') > 100
    severity: P1
    notify: [email-oncall]

平移时顺便做一次告警瘦身——很多团队迁移完才发现，一半以上的旧规则从来没触发过。

踩过的坑

• 时区：ELK 默认 UTC，新平台默认东八区，切换前务必统一，否则历史查询时间轴会错位；
• 字段命名：Filebeat 会加 log.file.path 这类前缀，迁移后检索语句里的字段名要同步调整；
• 多行日志：Java 堆栈、Python traceback 的合并规则要在采集端重新配置，否则一行堆栈拆成几十条。

迁移不是“替换工具”，而是把告警和检索习惯一起搬过去。双写过渡加冷热分层加规则瘦身，能把这件“大工程”变成一次低风险的切换。