本文整理自Zabbix认证培训师任勇在2025 Zabbix中国峰会上的演讲分享。

目录

一、背景与建设目标

二、规模化架构方案

三、信创融合与适配

四、智能探索与成效

一、背景与建设目标

1.1 背景情况

金融单位环境复杂，基本上是几百个业务系统。

金融单位的数据中心要求两地三中心，环境相对复杂，同时存在云上、云下的环境

l 行业的标准比较高，对监控平台的要求既要高可靠，又要高及时，还要高有效，还要全覆盖。

l 在近些年信创的驱动下，要实现与信创的融合，做到自主可控。

1.2 建设目标

怎样建设一个整体高可靠、自主可控的监控平台？

主要有五个关键词。

1、统一化

传统的监控架构基本是商用软件，分别有网管和系管，还有存储监控平台等多个厂商的监控工具。我们首先要用Zabbix做统一监控。

2、标准化

给制定监控配置规范和统一标准，包含监控广度、深度、数标。

3、规模化

采用分布式高可用架构，支撑百万的指标体系。

4、智能化

随着大模型的广泛的应用，把大模型也引入到监控平台，后文会给出智能化运维场景的案例。

5、信创化

全面适配国产的软硬件生态，支持国产芯片、操作系统、数据库。

1.3 监控平台发展路线

2016

客户开始探索Zabbix2.0LTS。当时他们正使用的是BMC的商软监控系统无法满足客户需求，对新一代监控系统进行选型。

2018

经历两年，正式确定了用Zabbix替换原来的商软系统。开始小规模的试点，把非重要的系统安装Zabbix进行监控纳管。后续两年进行试运行和小规模推广。

2020

正式的把核心系统用Zabbix全部纳管。Zabbix监控了他们整个核心系统，对系统，以及系统上的软件，包括数据库、中间件、存储、云等进行了全覆盖。

2021

监控平台跟第三方的平台进行了集成，分别对接大数据、自动化、告警中心、统一认证平台。

2023

客户开始替换旧的网管系统，全部由Zabbix进行统一纳管监控。

2024&2025

做了信创适配，使其完全适配了国产的环境且版本也升级为最新7.0版本，同时也引入了大模型，探索一些智能化场景。

二、规模化架构方案

2.1 架构设计

2.1.1 总体架构

架构是落地的核心，我们以Zabbix作为监控引擎外加日志和链路数据，构建了一个可观测体系的运维监控平台。

我们是主要分为三层：

第一层——采控层

主要依托 Zabbix 的采集和告警能力，对整个基础资源进行全面监控，重点采集 Metric 、部分Log指标。

第二层——运维数据中台

监控中台在采集 Metric 数据之外，还额外采集日志和链路数据，实现全方位监控。

管控中台由流程平台和自动化平台构成，负责调度和管理各类运维操作。

第三层——运维可视化层

包括 AI 监控平台、智能告警中心、日志平台、应用画像、应急操作以及可观测链路跟踪平台。

2.1.2 拆分原则

能支撑百万级的体系，少不了要对Zabbix的架构进行拆分。那我们的拆分原则是什么呢？

基本原则——单套Zabbix Server的NVPS不超2万

如果超2万，将按以下三个原则进行拆分。

（1）数据中心级拆分

如果“两地三中心”整体数据中心的 NVPS 超过 2 万，则每个数据中心独立部署一套 Zabbix。

（2）服务模式级拆分

若单数据中心内的 NVPS 仍超过 2 万，则按服务模式拆分：

PASS（软件服务） 一套

IAAS（硬件资源） 一套

（3）采集模式级拆分（Agent/Agentless）

如果单数据中心内的 NVPS 仍然超标，则根据采集方式拆分：

有 Agent 的部署一套

无 Agent 的部署一套

注：上述拆分原则的前提是网络互通。如果网络不通，则需要为该网络环境单独构建一套 Zabbix。

2.1.3 逻辑架构

按照前期的拆分规划，我们在“两地三中心”的环境中共构建了 六套 Zabbix 平台：主中心三套、同城灾备两套、异地灾备一套。

2.1.4 物理架构

整体架构采用分布式高可用架构：

数据库：

采用国产信创数据库，搭建了大规模集群，每套 Zabbix 通过独立的租户进行连接与管理，确保资源隔离与安全合规。

高可用：

每套 Zabbix Server应用均采用 HA 模式 部署，以保证平台的稳定性和容灾能力。

分布式：

每套 Server 配置了多个 Zabbix Proxy，实现分布式纳管。Proxy 的分配机制基于实际网段自动匹配，确保监控数据采集高效、准确。

注：后续章节将详细介绍 Proxy 自动分配机制的设计与实现。

2.2 纳管规模

监控节点3万+，监控项400万+，触发器300万+，整体NVPS4万以上。

2.3 监控体系

2.3.1 监控广度

我们的监控体系覆盖了从基础设施到业务应用的全链路，具体分为七层：

硬件层：服务器、存储、网络设备等基础设施设备的运行状态监控。

虚拟化层：虚拟机、容器、虚拟网络的健康状态与性能指标。

系统软件层：操作系统、数据库、中间件等系统软件的性能、容量和可用性监控。

应用服务层：核心应用系统的运行状态、关键业务服务的可用性。

业务服务层：业务流程、交易系统等业务服务的端到端监控。

用户侧监控：用户体验、访问延迟、页面响应等指标。

第三方监控：业务服务和用户侧监控由其他监控软件采集，其余全部由 Zabbix 统一采集与管理，实现全面覆盖。

2.3.2 监控深度

在每一大类和子类监控对象中，我们通过监控对象原厂、专业岗运维专家建立了黄金监控指标体系，主要特点如下：

状态类指标：设备运行状态、服务健康状态、进程存活情况等。

容量类指标：磁盘空间、内存使用、数据库连接数等资源使用情况。

性能类指标：CPU 利用率、IO 性能、网络吞吐量、应用响应时间等关键性能指标。

这些指标由运维专家和原厂共同定义，经过实际验证和优化，既保证了监控的精确性，又便于统一运维管理。

通过广度+深度的设计，我们实现了监控体系的全覆盖与高精度。

【获取原厂专业支持：400-823-0118】

2.4 配置与管理规范化

2.4.1 主机、模板标准化

在大规模监控环境下，我们对整个监控配置与管理进行了全面标准化，包括：

主机与主机组规范：统一命名规则，主机名称格式为 {主机名}-{IP}，主机组按对象分类、环境、业务线进行分组，保证唯一性、可读性和一致性。

应用监控规范：定义应用监控策略信息，包括监控对象、监控周期、监控类型和监控频率，实现监控策略统一化管理。

模板标规范：监控模板命名规则明确，包括前缀标识、重要性、监控对象及其子类层级，使模板易于管理和复用。

监控项与触发器规范：触发器命名和配置规则统一，涵盖监控对象、子类、等级等，便于批量管理和告警治理

标签(Tag)规范：通过模板标签、监控项标签和触发器标签，实现对监控对象、监控分类和告警分类的精细管理。

通过上述标准化处理，整个平台的配置维护变得高效、统一且可扩展，大大降低了运维复杂度，同时为未来监控策略扩展和智能化探索提供了坚实基础。

2.4.2 Agent 智能适配

在实际落地中，被监控对象的系统版本繁多，涵盖不同内核和架构，若为每个版本单独维护Zabbix Agent包，容易造成管理混乱。为此，我们制定了Agent智能适配标准。

具体做法是：

将不同操作系统分别封装为 Linux All-in-One、AIX、Windows 三个统一的Agent包。

Agent内部内置了 Proxy地址映射表，启动时会根据主机所属网段自动选择并分配合适的Proxy。

当需要进行Agent迁移时，只需下发新的映射表并重启Agent，即可完成自动分配，无需重新安装或手动配置。

通过这种方式，整个环境仅需维护 三类标准Agent包，大幅降低了管理复杂度，实现了高效的规模化运维。

2.4.3 用户生命周期

在大规模环境下，Zabbix 平台的用户数量也越来越多。由于金融行业对安全要求极高，必须对用户账号进行严格的全生命周期管理。例如：要求用户定期修改密码，密码到期前进行提醒。但这些功能在原生 Zabbix 平台中是无法直接实现的。

为了解决这个问题，我们做了两方面的集成：

(1) 统一认证管理：

与门户的统一认证平台对接，由门户统一管理 Zabbix 用户的密码与认证策略。这样可以满足定期修改密码、到期提醒等安全要求。

(2) 流程自动化管理：

与管控中心的流程平台打通。用户在申请时，只需提交流程，即可在 Zabbix 平台上自动完成账号创建和权限分配。当用户有变动或离职时，也只需在门户发起删除流程，我们会自动同步删除对应账号。

通过这种方式，我们实现了 Zabbix 用户的全生命周期管理，既满足了金融行业的安全合规要求，又显著降低了人工运维成本。

2.4.4 监控服务目录

随着监控精细化要求的不断提升，个性化监控需求日益增多，监控策略也随之愈加复杂。为此，我们与管控中台完成了集成，建设了监控自服务能力，显著提升了监控运维的效率与灵活性。

对于一些非标准化的应用监控场景，例如进程、端口、日志、URL、拨测等类监控，其监控策略往往具有高度个性化。我们通过制定统一的规范，让需求方按照模板自行填写监控策略，再由管控中台的自动化作业平台自动下发并配置。这样既保证了监控策略的标准化与可控性，又实现了个性化监控的自助配置与自主维护。

2.5 告警与自愈

2.5.1 告警抑制

在大规模环境下，告警也越来越多。我们对无效告进行降噪。这个降噪我们是通过三个维度去实现的。

（1）动态阈值

动态阈值我们用Zabbix原生的函数，用同比，或是标准偏差等这些函数去进行计算。

像一些经典的场景，有些客户他的服务器晚上备份时，IO会冲高，或者早上开盘时，CPU内存会冲高。这种情况属于正常情况。我们可以通过动态阈值把这部分告警有效降噪。

（2）分级关联功能

很多时候，比如宿主机坏了，会影响整个宿主机下面所有虚拟机监控对象的采集，导致批量的告警风暴。我们基于拓扑进行数据告警的关联，就可以做到降低告警风暴，提升告警准确度。

（3）拓扑关联抑制

很多时候，比如网络交换机坏了，会影响整个网络交换机下面所有监控对象的采集，导致批量的告警风暴。我们基于拓扑进行数据告警的关联，就可以做到降低告警风暴，提升告警准确度。

2.5.2 告警自愈

在告警处理方面，我们将监控平台与自动化运维平台深度打通，构建了一系列“告警自愈”场景。这里的自愈主要面向日常高频、标准化的运维问题。例如，当发现某个Agent进程的CPU异常飙高时，系统会自动触发清理动作，及时终止异常进程，防止影响其他业务应用的稳定运行；又如，当文件系统容量即将耗尽时，平台能够自动执行扩容或清理策略，保障服务的连续性与数据安全。

与此同时，我们不仅仅停留在“修复”层面，而是进一步引入了“预处理”机制。当告警触发的同时，平台会主动采集现场的快照信息，如数据库的状态快照、中间件的线程/堆栈信息、系统资源利用情况等。这些信息能够为后续问题复盘、根因分析以及长期优化提供有力支撑。

通过这种方式，我们既实现了常见问题的自动化闭环处理，减少了人工介入的重复性工作，又大幅提升了故障处置的及时性和可追溯性，从而让运维团队能够将精力更多地集中在复杂问题和架构优化上。

三、信创融合与适配

3.1 总体思路

CentOS7（X86） + MySQL 5.7 + Zabbix 5.0

KylinOSv10(C86) + TDSQL 8.0 + Zabbix 7.0

环境运行在 CentOS7（X86） + MySQL 5.7 + Zabbix 5.0，我们规划迁移到新信创环境：KylinOSv10(C86) + TDSQL 8.0 + Zabbix 7.0，主要考虑到风险可控、对业务影响最小，我们采用数据库层级迁移的方式，应用架构、监控范围范围保持不变。

3.2 迁移过程

整个过程分为几个关键步骤：

(1) 数据导出：使用 数据库备份工具将原 MySQL 数据完整导出，保证表结构与数据一致性。

(2) 数据迁移：使用数据库恢复工具导入到新库 TDSQL 8.0 。

(3) 应用升级：Zabbix应用由5.0升级到Zabbix7.0 。

(4) 切换 IP：通过修改 IP 指向方式，将监控代理快速切换到新Zabbix7.0平台。

(5) 数据验证：迁移后使用几十条 SQL 脚本进行全量比对，验证数据的一致性和准确性。

整个切换过程用时 不足 10 分钟，实现了“平滑迁移”。

3.3 问题和挑战

(1) 数据库分区 Crash：在高并发场景下，旧版本TDSQL出现分区崩溃问题。最终通过 升级到 TDSQL版本，修复了该类问题。

(2) 主备切换引发 Zabbix Server 宕机：在数据库主备漂移时，Zabbix Server 会出现连接中断，导致短暂不可用。为此我们在 Server 层面增加了服务守护机制，当检测到连接异常时可自动重连，从而实现“无感知恢复”。

3.4 效果验证

迁移完成后，我们重点关注性能指标。实测结果显示：

(1) 在 NVPS 3 万 的高压力下，数据入库进程 CPU 使用率仅约 30%，说明信创环境下在高并发写入和查询方面的性能足够充足。

(2) Zabbix Server 的运行也更加稳定，未再出现因数据库故障引发的宕机情况。

(3) 数据一致性验证全部通过，业务方使用体验与原环境保持一致，甚至在查询速度上有所提升。

四、智能探索与成效

最后我们分享下智能化探索一些有趣的使用场景 。

4.1 从命令行到自然语言

在传统的监控场景下，我们经常会遇到以下问题：

第一个问题：查询复杂。比如运维同事想知道“过去 7 天 CPU 平均利用率超过 80% 的主机有哪些”，在 Zabbix 里，需要构造复杂的 SQL 或 API 调用，普通用户很难直接完成。

第二个问题：学习门槛高。很多人对 SQL 不熟悉，或者不清楚监控项的 key，导致只能依赖专家来帮忙查询。

第三个问题：效率低。每次问题排查，都需要在界面上点来点去，或者写脚本，花费大量时间。

基于这个痛点，我们这次做了一个 NL2SQL 的探索。核心思想很简单，就是把自然语言直接翻译成 SQL，让系统替你写查询。

4.2 自然语言 → SQL → 可视化

具体流程是这样的：

(1) 在 Web 窗口或者运维平台里输入一句自然语言；

(2) 通过 NLP 加大模型来识别意图，再结合我们本地的指标库，自动生成对应的 SQL；

(3) SQL 去查只读库，把结果返回并展示。

这样一来，原本需要 DBA 或资深运维才能搞定的操作，现在任何人只要会“提问题”，就能获取想要的结果。

4.3 从问题到答案，只需一句话

举几个直观的例子：

想查“某个核心系统的主机宏”，直接一句话输入就行；

想看“某主机近 7 天 CPU 利用率趋势”，不需要再去拼字段、写函数，直接返回一张图表；

甚至可以说“帮我拉一下近一天核心系统的告警清单”，系统就能立刻给出清单结果。

4.4 成效与价值

这种方式带来的价值主要有三点：

(1) 访问更智能：完全用自然语言交互，不用关心表结构和 SQL 语法，降低使用门槛；

(2) 响应更高效：查数据就像对话一样，即问即答，随时随地能看结果；

(3) 部署更灵活：可以嵌到运维平台、事件平台里，直接调用，形成“一站式查询体验”。

Zabbix&NL2SQL 打开了一条新的路。它不只是提升效率，更是把监控和数据的使用权交给了更广泛的人群。未来，不只是监控管理员，业务人员也能通过一句话来拿到他们关心的指标。

总结

通过规模化架构设计、信创适配、智能化探索，我们构建了一套金融级高可靠、可扩展、智能化的监控平台。

它不仅满足了 金融行业的安全合规性，也让运维团队更高效，更智能。

注：本演讲PPT不可对外公开，如需更详细信息，请+小Z的VX号 17502189550。