麒麟 + 鲲鹏环境跑通炬鲸 OBSERVE：信创部署实录

信创环境部署可观测平台，难点不在功能，而在架构和依赖：ARM64 镜像有没有、国产数据库能不能换、采集端在国产 OS 上稳不稳。这篇是我们在麒麟 V10 + 鲲鹏 920 上的部署实录。

环境与兼容范围

• OS：麒麟 V10 SP3，内核 4.19，ARM64（aarch64）
• CPU：鲲鹏 920，48 核 × 2 路
• 数据库：达梦 DM8（替代 MySQL 存储元数据与告警规则）
• 容器：Docker 20.10 + containerd

部署前先核对镜像架构。用 docker manifest inspect 看目标镜像是否带 arm64 层；只提供 amd64 的镜像在鲲鹏上跑会走 qemu 模拟，性能掉一个量级，表现为查询变慢而不是明显报错。炬鲸 OBSERVE 的服务端与采集端都提供多架构镜像，拉取时用 --platform linux/arm64 显式指定，避免混用。

部署步骤：服务端容器化

服务端用 docker-compose 编排，核心是四个服务：接入网关（收 OTLP 与指标）、存储引擎、查询引擎、控制面。达梦数据库的 JDBC 驱动需要单独挂载，连接串里的 schema 初始化脚本在镜像的 /init 目录下，首次启动自动执行。注意 DM8 对连接池的 validationQuery 要改成 SELECT 1 FROM DUAL，直接照搬 MySQL 的 SELECT 1 会报错，表现为负载升高后偶发"连接已关闭"。

采集端兼容：国产 OS 上的坑

采集端（node exporter、filelog、OpenTelemetry Collector）在麒麟上大部分能直接跑，但两个坑要提前处理：

• glibc 版本：麒麟 V10 的 glibc 偏旧，动态链接的采集器可能报 GLIBC_2.34 not found，改用静态编译版本或 musl 版本即可；
• 国产中间件监控：东方通、金蝶等中间件没有现成 exporter，用 OpenTelemetry 的 JMX 采集器接其暴露的 JMX 端口，指标名做一层映射即可。

性能与稳定性调优

鲲鹏的 NUMA 拓扑比同规格 x86 更明显，把存储引擎绑定到单个 NUMA 节点能减少跨节点访存，写入吞吐可提升约 20%，建议在做容量规划前先做完这一步。达梦建议把表空间和数据文件放到独立磁盘，并关闭查询引擎对元数据的频繁轮询。压测结论：同等规格下，ARM 环境写入与查询延迟与 x86 持平，冷启动稍慢，属正常范围。