从 ELK 平滑迁移到信创可观测平台：割接方案与坑

为什么要迁，以及为什么难

政企把日志系统从 ELK 迁到国产平台，通常有两个驱动：一是信创合规，要求核心系统跑在国产软硬件上；二是 ELK 的授权和运维成本，随数据量增长越来越难看——节点越扩越多，Grok 规则越堆越乱，还要专门有人盯着集群健康。

但日志系统是“生产系统的生产系统”，迁错了就是事故。难点集中在三处：历史日志不能丢、现有查询和看板不能断、迁移期间数据不能有缺口。下面按四个阶段来拆，每个阶段都有可核对的产出物。

阶段一：盘点现状

动手前先把现有资产摸清楚，否则迁移就是盲切：

• 列出所有 Logstash pipeline，逐个记录输入的来源、Grok 解析规则、输出的目标。这一步最容易被忽略，但 Grok 规则是迁移时字段对不齐的元凶
• 列出 Kibana 里真正在用的看板和告警，而不是全部（很多人有几十个，常用的不到五个）
• 统计日均日志量和峰值 QPS，用来给新平台定规格，避免“迁完才发现规格不够”
• 确认日志保留周期和合规要求，比如金融行业动辄要求保存 3 年以上

这一步的输出是一张清单，后面每一步都对着它核对。

阶段二：双写并行

不要一次性切流量，先在应用侧把日志同时发到 ELK 和新平台，跑一到两周。目的有两个：验证新平台的采集、解析、检索能力，同时积累一批“新格式”数据，为后面的回填对齐格式。

双写期间重点对比两边的日志条数、字段、时间戳。条数对不上，多半是采集端丢数据；字段对不上，多半是解析规则没迁全。建议每天固定时间做一次对账，把差异记下来，别等到割接那天才发现。

阶段三：历史回填

历史日志是迁移里最容易翻车的部分。不建议把 Elasticsearch 里几 TB 的索引原样导过来，原因有两个：一是索引 mapping 和字段类型对不上，二是会拉高存储成本。

更务实的做法是“按需回填”：只把高频查询的最近 30–90 天数据导过来，更早的日志留在原 ELK 里做冷备，查询入口保留一段时间。导出时用 elasticsearch-dump 或滚动导出，注意控制并发，别把源集群压垮。

# 滚动导出最近 30 天订单服务日志
multielasticdump --input=http://old-es:9200 \
  --output=/backup/logs \
  --match='order-service-*' \
  --scrollTime=10m \
  --concurrency=2

回填时还要做字段映射：Elasticsearch 的 @timestamp、嵌套字段、以及 Grok 拆出来的自定义字段，都要映射到新平台的字段模型上。建议先导一个索引做试点，验证字段对齐无误后再批量回填。

阶段四：割接与收尾

割接选在低峰窗口。切换顺序建议：先把查询入口切到新平台，再停掉 ELK 侧的写入，最后下线 Logstash。这个顺序保证任何时刻都至少有一个系统在接收日志。

收尾三件事：

• 迁移看板：Kibana 的查询语法和国产平台的类 SQL 语法不同，需要逐个翻译关键看板，建议只迁真正在用的那几张
• 迁移告警：ElastAlert 或 Watcher 的规则要重新在新平台配置，注意动态基线可以替代很多拍脑袋的固定阈值
• 保留回滚窗口：ELK 至少保留 30 天只读状态，万一新平台出问题还能切回去

三个最常见的坑

我们见过的大部分翻车，都不是技术问题，而是这三个原因：

1. 盘点不清：Grok 规则、看板、告警没列全，割接后发现字段解析错乱、关键告警没迁
2. 双写太短：跑两三天就急着切，新平台的解析差异没暴露出来
3. 回填贪多：想一口气把几年数据全导过来，结果源集群被压垮、存储成本爆炸，还拖慢了割接

把这三个坑避开，迁移基本就稳了。核心原则一句话：宁可慢一点，别丢一条日志、别断一个告警。