信创改造中的可观测平台迁移：从 x86 到国产 ARM 栈的落地清单

迁移前：先把兼容性摸清楚

信创改造最容易翻车的地方，不是技术本身，而是迁移前没把兼容性清单列清楚。可观测栈的组件远比看起来多：采集 Agent、存储引擎、查询层、告警组件、前端，任何一个在 ARM 上没有对应版本，迁移就会卡在半路。

建议先做一张表，把每个组件在国产环境下的支持情况列出来：

| 组件 | x86 现状 | 国产替代 / ARM 支持 | 结论 |
| --- | --- | --- | --- |
| 日志采集 | Filebeat | 炬鲸内置采集 Agent（Go 单二进制） | 可直接替换 |
| 存储引擎 | Elasticsearch | MySQL 8 / OceanBase / 达梦 | 协议兼容 |
| 查询层 | Kibana | 炬鲸 OBSERVE 控制台 | 类 SQL 检索 |
| 告警 | 自研脚本 | 内置告警规则引擎 | 迁移规则 |

炬鲸 OBSERVE 基于 Go 编写，单二进制交付，在 ARM 上直接编译运行，不依赖 JVM 等重运行时，这一环通常是最顺利的。

存储替换：从 Elasticsearch 到国产数据库

Elasticsearch 的替换是迁移的核心。炬鲸 OBSERVE 的存储层走 MySQL 协议，可以对接 MySQL 8、OceanBase（MySQL 模式）和达梦，应用侧零改动，只需要换连接串：

# 炬鲸 OBSERVE 只需改 env 配置
DB_HOST=10.0.0.12
DB_PORT=2881          # OceanBase MySQL 模式端口
DB_NAME=observe
DB_USER=observe
DB_PASSWORD=********

选择 OceanBase 或达梦时，注意两件事：一是字符集统一用 utf8mb4，避免日志里的中文和 emoji 乱码；二是确认目标库的兼容模式（OceanBase 选 MySQL 模式），别混用 Oracle 模式，否则 SQL 方言会出问题。

数据迁移与并行验证

直接"停机搬迁"风险太高，推荐并行验证：新栈先跑起来，与老栈同时接收一份镜像流量，两边结果对比。

1. 在采集侧配置双发：Agent 把同一批日志同时发到老 ELK 和新 OBSERVE
2. 跑一周对比：抽同样的 trace_id 和查询条件，核对两边结果是否一致
3. 关键指标对齐后，把只读流量切到新栈，再逐步切写流量
4. 老栈保留 30 天作为回退，确认无问题后再下线

历史日志要不要迁？建议只迁最近 90 天的热数据，更早的冷数据以归档文件形式保留，避免为访问频率极低的数据付出迁移成本。

验收清单

迁移完成后，按下面几项逐条验收：

• 日志检索、链路追踪、监控告警三大功能自检通过
• 数据完全落在内网，无任何外发请求（抓包确认）
• 权限、审计、多租户隔离满足等保与信创合规要求
• 国产数据库下压测：单租户 1 万 TPS 日志写入，查询 P99 延迟达标
• 应急回退预案就位，老栈可随时切回

信创迁移不是一次性动作，而是"评估—并行—切换—验收"的闭环。把清单走完，才能既不中断业务，又满足自主可控的要求。