金融行业Zabbix信创实践

本文摘自2024年Zabbix中国峰会，大中华区培训师任勇的演讲《金融行业Zabbix信创实践分享》。

一、信创的始末缘由

1、信创的定义与目标

“信创”全称“信息技术应用创新产业”，旨在通过信息技术（“信”）与应用创新（“创”）推动产业全面国产化，覆盖基础硬件、基础软件、应用软件及信息安全四大领域。

2、信创产业链全景图

• 基础硬件：芯片（CPU、GPU、FPGA）、存储（DRAM、NAND Flash）、服务器、通信设备等。
• 基础软件：操作系统（桌面OS、移动OS、云OS）、数据库、中间件、虚拟化技术。
• 应用软件：金融IT、工业软件（ERP、MES）、政务IT、医疗IT等。
• 信息安全：数据安全、云安全、终端安全、IoT安全等。

注意

值得注意的是，Zabbix属于监控软件，而监控工具是不在强制信创以及首批要进行信创改造的范围当中的，Zabbix只要与信创环境做好适配就可以正常使用。

3、国内信创发展现状

信创推行遵循“2+8+N”推广路径：

2-第一梯队：党政，推进最快。

8-第二梯队：金融、电信、电力、交通、航空航天等国计民生行业。

N-第三梯队：制造、物流、消费等泛行业。

当前我们处于规模化推广期（2024-2027），金融行业作为先锋，已进入深度实践阶段。因此本文选取具有代表性的金融行业案例，为大家进行落地的深入剖析。

二、Zabbix与信创生态的融合

在与大量甲方用户的交流过程中，我们总结了两个用户关切的核心问题：

Q1

Zabbix能否在信创环境中部署运行？

操作系统兼容性

支持内核版本4.19及以上的信创操作系统（如麒麟、统信、OpenEuler），Zabbix 6.0可通过编译部署。

数据库兼容性

适配主流信创数据库（OceanBase、TDSQL、GoldenDB、人大金仓、达梦等），支持MySQL/PostgreSQL协议。

兼容认证证书

已获麒麟、统信、龙芯等操作系统认证，并与OpenGauss、OceanBase等数据库完成互兼容认证。

Q2、Zabbix能否监控信创对象？

监控方式

通过Agent、SNMP、SSH、HTTP/HTTPS等协议，覆盖信创操作系统、数据库、中间件、硬件及网络设备。

开箱即用模板

我们已积累近百套监控模板，涵盖7大类信创对象（如麒麟OS、达梦数据库、东方通中间件等），且均已验证并运行良好。

技术适配能力总结

• 操作系统监控：实时采集CPU、内存、磁盘、进程等指标。
• 数据库监控：支持SQL性能分析、连接池状态、慢查询日志等。
• 中间件监控：通过JMX/API获取线程池、事务处理、缓存命中率等数据。
• 网络与硬件监控：基于SNMP协议实现交换机、路由器、存储设备的健康状态检测。

三、Zabbix信创

落地案例

1、麒麟OS + OceanBase（C86架构）—

从兼容适配到平滑迁移

某大型金融机构原监控系统基于Zabbix 5.0（MySQL 5.7、CentOS 7.5），需迁移至信创环境（麒麟OS + OceanBase 4.2）。核心难点在于：

1）数据库版本兼容性：OceanBase 4.2的版本标识与Zabbix 6.0的数据库检测机制冲突，导致部署失败。

2）SQL语法差异：Zabbix历史数据查询语句因OceanBase分布式特性报错，例如GROUP BY语法限制。

2. 解决方案与实施

1）参数调优：调整OceanBase的compatible_mode参数，模拟MySQL 8.0版本标识，绕过Zabbix环境检测。

2）SQL适配：调整OceanBase 配置，兼容GROUP BY语法参数，兼容Zabbix语法规则。

3）分阶段迁移：

a. 先升级后迁移：在CentOS环境完成Zabbix 5.0→6.0升级，验证功能完整性。

b. 数据割接：通过OceanBase数据迁移工具（OMS）将MySQL数据在线迁移至OceanBase集群，租户隔离保障性能。

3. 成效与数据

1）规模：16,000+设备、220万监控项、180万触发器、3TB历史数据。

2）稳定性：迁移后Zabbix Server负载下降15%，聚合查询效率提升30%。

4. 客户反馈：

“通过参数适配与SQL优化，Zabbix在OceanBase上运行稳定，为后续信创全栈替换提供了监控保障。”

2、麒麟OS + TDSQL（C86架构）—

主键缺失与高并发冲突的破局

1. 背景与挑战：

某省级银行系统升级至TDSQL分布式数据库后，Zabbix出现两类严重问题：

1）主键缺失：TDSQL要求所有表必须显式定义主键，而Zabbix部分核心表（如history_log）未满足条件，导致数据写入失败。

2）高频操作冲突：Zabbix自动分区功能与TDSQL的DDL锁机制冲突，引发数据库实例崩溃。

3）驱动不兼容：主备切换导致的Zabbix Server连接中断问题。

2. 解决方案与实施

1）表结构改造：为9张Zabbix核心表添加主键，确保TDSQL兼容性。

2）锁机制冲突优化：修复TDSQL核心源代码处理逻辑，避免高频DDL与DML锁机制冲突。

3）驱动适配：采用应用守护进程，解决主备切换导致的Zabbix Server连接中断问题。

3. 成效与数据

1）规模：18,000+设备、260万监控项、200万触发器、3TB存储。

2）可靠性：分区冲突频率降至0，主备切换耗时从分钟级缩短至秒级。

4. 客户反馈：

“TDSQL的高性能特性与Zabbix结合后，监控系统的性能显著提升。”

3、麒麟OS + GoldenDB（ARM架构）—

ARM生态下的无缝迁移

1. 背景与挑战：

某证券机构需将Zabbix从X86平台迁移至ARM信创环境（麒麟OS + GoldenDB 8.9.99），面临两大挑战：

1）ARM编译兼容性：Zabbix 依赖的第三方库（如OpenSSL）需重新编译适配ARM指令集。

2）性能调优：GoldenDB在ARM架构下IO性能与传统X86存在差异，可能影响监控数据写入效率。

2. 解决方案与实施

1）ARM编译适配：基于麒麟OS交叉编译工具链，重构Zabbix及依赖库，确保ARM原生支持。

2）数据库参数优化：调整GoldenDB的innodb_flush_log_at_trx_commit=2，平衡数据安全性与写入吞吐量。

3）渐进式迁移：

a.并行验证：在ARM环境部署Zabbix Server/Proxy，与原有X86 Server并行运行，数据双向同步验证。

b.全量切换：确认稳定性后，下线X86节点，全面切换至ARM平台。

3. 成效与数据

1）规模：185+设备、2万监控项、1万触发器、100GB存储。

2）性能：ARM平台CPU利用率降低20%，数据采集延迟稳定在50ms以内。

4. 客户反馈：

“ARM架构与GoldenDB的组合，不仅满足信创要求，还降低了硬件成本，Zabbix的跨平台能力令人印象深刻。”

四、总结与展望

Zabbix在金融信创实践中，通过参数调优、SQL适配、架构改造三大核心手段，成功突破数据库兼容性、高并发冲突、跨平台迁移等难题，验证了其在信创生态中的技术普适性。未来，Zabbix将持续深化与国产芯片、操作系统的协同优化，推动监控能力从“可用”向“好用”跃迁，为金融行业信创转型筑牢技术底座。