可观测平台在国产化环境落地,难点在数据库适配和 CPU 指令集差异。本文记录在麒麟 V10 + 达梦 + 海光/飞腾上的部署过程、迁移步骤与性能验证数据。
可观测平台本身也是软件,也要过信创这关。我们在某政企客户现场,把炬鲸 OBSERVE 完整跑在麒麟 V10(aarch64)+ 达梦 DM8 + 海光/飞腾 CPU 上,以下是可以复用的部署经验。
达梦需要先装 DM8 并初始化实例,注意页大小参数建议设 32K,兼容模式选 MySQL,否则后续建表会踩到默认 8K 页导致的长度限制。
用达梦自带的 DTS(数据迁移工具)把元数据从 MySQL 迁过来。迁移顺序建议:先结构后数据、先主表后关联表。两个坑要提前避:
orderId 这种驼峰列名,迁过去后要用双引号包起来,最好迁移前统一转成小写加下划线。ON DUPLICATE KEY UPDATE 语法,达梦用 MERGE INTO 替代,应用里的批量写入 SQL 要改。炬鲸 OBSERVE 已经内置达梦方言适配,在部署配置里把 db.dialect=dm 打开即可,不需要改业务代码。
平台本体以容器化方式部署,但 aarch64 下镜像必须用 multi-arch 或单独构建的 arm64 版本,直接拿 x86 镜像会起不来。我们的做法是:官方提供 arm64 镜像 tag,配合 docker/podman 在麒麟上跑。
监控 Agent 需要在海光和飞腾上分别编译:海光是 x86 兼容指令集,可直接用 x86 二进制;飞腾是纯 ARM,要单独出 aarch64 包。给客户交付时,安装脚本里按 uname -m 自动选包即可。
采集侧的 eBPF 探针在麒麟内核上需要确认内核版本与 BTF 支持,4.19 之后的麒麟内核基本可用,但老内核要降级到基于 procfs 的采集方式。
我们用 300 个节点的模拟环境压测:日志采集峰值 12 万条/秒、链路 span 4 万条/秒、单次检索 P99 在 1.2 秒内,与 x86 环境相比 CPU 占用高约 15%,属正常范围(飞腾单核性能弱于主流 x86,靠多核补)。
踩过的坑集中在三点:
GLIBC_2.34 not found,需要在目标环境本地编译或选低版本依赖。信创落地不是「能装上」就结束,而是「稳定跑起来、性能可接受、排障可支撑」。把这三点验证清楚,才算真正落地。