信创环境下的可观测平台选型与落地

信创（信息技术应用创新）环境不是简单的“换个操作系统”，它会同时带来三层变化。

信创环境的三个现实约束

1. CPU 架构：从 x86 换成 ARM（飞腾、鲲鹏）或 LoongArch（龙芯），所有依赖原生二进制的东西都要重新编译适配。
2. 操作系统：麒麟（Kylin）、统信 UOS，基于 openEuler 或 Debian 体系，包管理、内核参数、systemd 行为与 CentOS 有差异。
3. 数据库与中间件：从 MySQL/Oracle 换成达梦、人大金仓、GaussDB，周边生态、驱动、迁移成本都要评估。

对可观测平台来说，最直接的挑战是：采集 Agent、存储引擎、Web 服务这三层都要能跑在这些组合上，并且性能不能打折扣。

选型时的检查清单

在信创环境选可观测平台，建议拿下面四件事当硬指标：

• 架构原生支持：是否提供 ARM64 / LoongArch 的安装包或镜像，而不是只给 x86 的 tar 包让你自己想办法。
• 依赖收敛：是否强依赖 glibc 版本、是否捆绑只在 x86 上有的库；最好一个二进制搞定，减少“缺 so”这类问题。
• 数据库兼容：元数据存储是否支持达梦/人大金仓，还是只认 MySQL；这决定迁移时的改造成本。
• 性能验证报告：有没有在飞腾/鲲鹏机型上跑过压测，吞吐和延迟与 x86 对比如何。

炬鲸的适配范围

炬鲸 OBSERVE 当前在信创环境下的适配情况：

| 组件 | 支持情况 |
| --- | --- |
| CPU | 飞腾 FT-2000+/D2000、鲲鹏 920、海光 C86、龙芯 3A5000 |
| 操作系统 | 麒麟 V10（ARM/LoongArch）、统信 UOS 20/1060 |
| 数据库 | 达梦 DM8、人大金仓 KingbaseES V8、openGauss |
| 部署形态 | 物理机、KubeSphere、云原生（ARM64 镜像） |

采集端 Agent 同时提供 x86 与 ARM64 两种静态二进制，无需额外运行时依赖，直接 systemd 托管。

性能实测参考

在飞腾 FT-2000+（64 核）单机上，我们测过一组基线数据，供选型参考：

• 日志采集吞吐：单机 6 万条/秒，与同规格 x86 差异在 8% 以内。
• 检索查询 P95：10 亿行内单表聚合 2.1 秒，x86 为 1.8 秒。
• 磁盘写放大：列式压缩后约为原始日志的 1/8，存储成本可控。

以上为单机部署数据；三节点集群的写入吞吐近似线性扩展，查询延迟还会进一步下降。结论是：信创机型跑可观测负载没有本质短板，差异主要来自单核性能，多核横向扩展可以补回。

落地步骤：从单机试点到集群

不建议一上来就全量替换生产。推荐的节奏：

1. 单机试点（第 1 周）：在一台飞腾或鲲鹏机器上装好服务端 + Agent，只接一个非核心服务的日志与指标，验证采集、存储、查询全链路。
2. 压测验证（第 2 周）：用真实流量回放，重点看写入吞吐、查询延迟、磁盘占用，和 x86 基线对比，确认性能达标。
3. 逐步迁移（第 3-6 周）：按服务重要性从低到高，把日志与链路迁移过来，旧系统保留只读一段时间作为兜底。
4. 全量切换 + 备份（第 6 周后）：切换后保留数据导出能力，满足信创项目的验收与审计要求。

迁移时最容易忽略的三件事

• 配置也要迁：告警规则、仪表盘、采集模板这些配置要从旧系统导出再导入，别只迁数据不迁配置，否则告警一断就是事故。
• 历史数据：历史日志要不要迁？建议只迁最近 N 天的热数据，更早的保留在旧系统只读，省磁盘也省时间。
• 人员适配：麒麟/统信的操作习惯和 CentOS 有差异，给运维留出适应期，别在切换当天才发现没人会重启服务。

两个容易踩的坑

• 时间同步：信创机器常有 NTP 未配置或配置错误的问题，导致日志时间戳漂移，检索和链路排序全乱。上线前先统一 NTP。
• 内核参数：麒麟/统信默认的 vm.max_map_count、文件句柄数偏小，跑高并发采集时会报 too many open files。按部署文档调大后再压测。

信创不是“能不能跑”的问题，而是“跑得稳不稳、迁移痛不痛”的问题。把兼容性验证做在前面，能省掉后面大量返工。