可观测平台信创迁移实录：从 x86 到鲲鹏/飞腾的落地清单

为什么可观测栈是信创的硬骨头

业务系统替换到国产 CPU 往往只动应用层，但可观测平台要下沉到内核与容器运行时：采集器跑在每个节点上，Agent 要适配 glibc 与内核版本，存储引擎吃 CPU 指令集特性。组件多、依赖密、且一旦停摆，全公司的告警和排障能力一起下线。

我们把炬鲸 OBSERVE 全链路迁移到三类国产芯片：鲲鹏 920（ARM）、飞腾 S2500（ARM）、海光 C86（x86 兼容）。下面是可复用的落地清单。

第一步：镜像多架构构建

采集器和各服务组件统一走多架构镜像，用 buildx 一条命令出三份：

docker buildx build   --platform linux/amd64,linux/arm64   -t registry.local/observe/agent:3.2.1   --push .

要点：

• 基础镜像从 debian:bookworm-slim 换成多架构官方镜像，避免自己拼架构标签。
• 依赖里有 CGO 的组件（如某些 eBPF 采集器）必须按架构分别编译，ARM 上交叉编译 bpf 目标时注意 -target bpfel 与 bpfeb 的大小端差异。
• 产物进 Harbor 后按架构打 tag 或走 manifest list，K8s 节点根据自身架构自动拉取。

第二步：依赖与运行时兼容

迁移中踩到最多的三类坑：

1. glibc / 内核版本：飞腾部分机型出厂内核较老，eBPF 特性不完整。先在目标机上跑一遍 bpftool feature probe，确认 kprobe、tracepoint 可用再上 eBPF 采集器，否则退回到基于 /proc 的采集。
2. 压缩与加密指令：鲲鹏支持 NEON，海光支持 AVX2，但别假设所有节点都开了硬件加速。压缩库统一走纯软件实现（如 zstd 的 portable 版本），牺牲一点吞吐换可移植性。
3. JVM 参数：存储与计算服务如果跑在 JVM 上，ARM 下 -XX:+UseG1GC 的默认行为有差异，压测后重新调堆与 GC 线程数，不要照搬 x86 的参数。

第三步：性能对比与容量重算

迁移不是「搬过去能跑」就完事，要重做容量规划。我们压测结论（采集 Agent 单节点，10k 日志/s）：

| 指标 | x86 基线 | 鲲鹏 920 | 飞腾 S2500 |
| --- | --- | --- | --- |
| 采集吞吐 | 100% | 92% | 87% |
| CPU 占用 | 100% | 108% | 115% |
| 内存占用 | 100% | 96% | 99% |

ARM 单核弱一些，但核数多。压测后按实际吞吐把采集器副本数上调 10%~20%，存储层 Shard 数不变、但监控分片迁移时的 rebalance 阈值要重新设。

第四步：回滚与灰度

信创替换切忌一步到位，我们的灰度顺序是：

1. 先迁采集器（无状态、易回滚），观察数据连续性。
2. 再迁查询/告警服务，与旧 x86 实例并存跑双写，对比结果一致性。
3. 最后迁存储引擎，用 snapshot 迁移分片，迁移期间保留旧集群只读。

每一步都保留「切回 x86」的开关：DNS 或 LB 层一键改权重即可回滚，不依赖数据层还原。

落地清单小结

• 多架构镜像 + manifest list，节点自动匹配。
• 目标机先做 bpftool feature probe，按能力降级采集。
• 压缩、加密走 portable 实现，别押注单架构指令集。
• ARM 重调 JVM 与 GC 参数，压测后重算容量。
• 采集器 → 服务 → 存储三段式灰度，每段保留回滚开关。

把这套清单跑顺，可观测栈的信创替换是可控的，真正花时间的是压测和参数重调，而不是编译本身。