飞腾与鲲鹏上的可观测平台：国产芯片与操作系统的适配记录

信创改造不是换个数据库就完事，芯片和操作系统才是更底层的一关。采集器和后端要在飞腾（ARM64）、鲲鹏（ARM64）芯片上，跑在银河麒麟和统信 UOS 系统上，跟跑在 x86 + CentOS 上不是一回事。这篇记录我们把炬鲸 OBSERVE 全链路搬到国产芯片和国产 OS 上的过程和坑。

ARM64 镜像与编译：从能装到能跑

第一步是出 ARM64 镜像。后端和采集器的镜像都要在 arm64 架构下重新构建，不能直接复用 x86 的二进制。我们统一用多架构构建：

docker buildx build --platform linux/amd64,linux/arm64 -t ob-collector:v3.6.0 --push .

编译链上的坑比想象多。一些第三方库在 arm64 下没有现成的预编译包，得从源码编译；有的库依赖的底层汇编优化只针对 x86，换到 arm64 后功能正常但性能掉一截，需要逐个评估是否替换。我们整理了一份依赖清单，把有 arm64 官方支持的库和不支持的库分开，后者要么换替代品，要么自己维护编译脚本。

glibc 与系统依赖：版本对齐

麒麟和统信都基于 Linux，但 glibc 版本、系统库路径和 x86 发行版有差异。出问题最多的是 glibc：在较新的构建环境里编出来的二进制，拿到客户现场的旧版麒麟上，会因为 GLIBC_2.34 这类符号版本不存在而报"version not found"。

解决办法是构建时锁定一个较低的 glibc 基线，比如在匹配目标系统的容器里编译，或者静态链接关键依赖。同时把动态链接依赖用 ldd 逐个核对，缺什么补什么，别想当然地以为"都是 Linux 应该能跑"。

文件描述符与性能：ARM 不是慢的借口

跑起来之后要面对性能。ARM64 服务器单核性能弱于同代 x86，但核数多，所以并发类的采集、检索任务要按核数来配线程，而不是照搬 x86 的配置。我们踩过一个坑：采集器在 x86 上用固定 8 个 worker，搬到鲲鹏后文件描述符开得太多，触到麒麟默认的 ulimit 上限，采集直接中断。

两个调整：一是按 CPU 核数动态算 worker 数；二是把 open files 上限调高，并定期检查采集器的 fd 增长，发现泄漏及时修。性能上，我们做了对拍：同样的采集负载，飞腾 S2500 上优化后吞吐达到 x86 的七成左右，满足需求，关键是并发度要跟核数匹配。

国产浏览器与桌面端兼容

控制台前端也要跑在信创终端上，浏览器往往是奇安信浏览器、360 安全浏览器或统信的浏览器，内核版本偏旧。前端要避免使用过新的 JavaScript 语法和 API，图表库选兼容性好的版本，登录和导出这类关键路径要在国产浏览器上单独回归。我们列了一份"必须兼容的浏览器清单"，发版前逐一跑一遍，避免到客户现场才发现白屏。

验证清单

• 后端与采集器均提供 arm64 镜像，多架构构建脚本入库；
• glibc 基线锁定，ldd 核对依赖无缺失；
• worker 数按核数动态计算，open files 上限调高；
• 采集吞吐在目标芯片上对拍，确认满足业务量；
• 控制台在国产浏览器清单上逐项回归通过。

国产芯片和 OS 的适配没有捷径，坑都是固定的：架构、glibc、fd、性能、浏览器。踩过一次写成清单，下一个项目照着走，能省掉大半时间。