实战：Zabbix百城千店监控方案

作者简介

王中博

多年Zabbix运维经验，Zabbix中文手册译者

目录

1. 基于7.4新特性 - 嵌套发现原型的监控方案设计
2. 自动发现配置

一、基于7.4新特性——嵌套发现原型的监控方案设计

无限制的嵌套原型低级别发现和主机原型发现

在以前老版本中，低级别发现和主机原型发现是有层级限制的，被发现的主机及指标无法再次发现原型。

新版本中支持了不限制级别的发现，因此可以配置发现规则实现以下复杂的场景：发现主机集群，在发现集群的主机，在发现主机上的数据库、数据库表空间等，大大简化了指标的配置。

1.1 门店监控需求分析

我们的监控场景主要面向覆盖全国范围的数百个商场门店，每个门店部署一台路由器作为网关，并通过 V** 与公司内网相连。需要监控的对象包括门店内的路由器、考勤机、打印机、摄像头等弱电设备，目标是在门店人员感知前，及时将故障推送给对应的 IT 运维人员。

此外，管理层可通过 SLA 报表清晰地了解各类服务的可用性，例如：比较打印机与摄像头的离线率、评估不同供应商（如 A 公司与 B 公司）设备的稳定性、考察 IT 人员响应故障的时效等。这些数据还可用于预判硬件故障趋势，合理规划备件储备。

除常规运维价值外，监控系统在应急场景中也发挥了关键作用。例如，某门店所在商场发生火灾，所有设备损毁。我们提供的路由器告警记录及最后在线时间，为消防部门分析起火顺序提供了数据支持。

随着业务规模扩大，每周都有门店新开或关闭，手动维护监控对象显然不现实，必须实现监控项目的全自动闭环管理——包括自动注册、更新与注销。

尽管门店管理系统可执行简单的拨测操作，但全量设备的监控数据持久化与分析属于专业运维范畴，应由监控系统统一承接，避免开发重复造轮子。甚至基于飞书多维表格都可以直接当做门店管理系统来使用。

在告警方面，关键需求是合并通知。例如，当门店整体失联时，应只发送一条聚合告警，而非所有设备独立告警，避免信息过载。

在架构选型上，曾考虑为每个门店部署 Zabbix Proxy 或 Agent，或定制专用监控硬件，甚至复用门店路由器执行监控任务，但这些方案都面临设备数量大、地域分散带来的管理和控制挑战。

因此，我们最终选择基于 Zabbix 的自动发现机制来实现集中化、自动化的监控管理。

1.2 老版本的监控方案

在原有方案中，我们通过定时任务（每小时执行一次）与门店管理系统进行数据同步，动态更新 Zabbix 中的监控规则。

具体流程如下：

• 比对新旧门店信息，删除已撤店门店的自动发现规则，并为新门店创建对应的规则；
• 调用 Zabbix API 为每个门店自动创建监控原型和触发器原型；
• 建立触发器依赖关系，将门店内设备的触发器依赖于门店路由器的状态。这样当路由器离线时，仅触发路由器告警，抑制下属设备告警，有效避免告警风暴。

我们也曾考虑使用单条自动发现规则批量管理所有门店设备，但该方案存在两个明显缺点：

1. 数万个监控项和触发器混杂在同一视图，难以维护和设置依赖关系；
2. 早期 Zabbix Agent（5.x 版本）在处理自动发现结果时存在 512KB 数据包限制，无法支持大规模设备的自动注册。

随着 Zabbix 版本迭代，我们发现：

• Zabbix 6.0 中 Agent 的数据包限制提升至 16MB，大幅提升发现能力；
• 此外，Zabbix Server 支持的 HTTP Agent 方式不再有数据上限，更适合实现大规模、集中式的设备自动发现与管理。

1.3 新版本的监控方案

1.3.1 手册地址

Zabbix Manual / 15 Discovery / 5 Discovery prototypes

(https://www.zabbix.com/documentation/current/en/manual/discovery/low_level_discovery/discovery_prototypes)

1.3.2 官方嵌套方案

1.3.3 基于嵌套发现原型的新方案

小问题：一个自动发现规则里，不允许有重复的自动发现原型

在参加于上海举办的 2025 Zabbix中国峰会时，了解到7.4版本新增了嵌套自动发现规则的功能，我立刻联想到几年前关于门店设备监控的场景，并在回归后迅速搭建测试环境进行验证，对原有技术方案进行了全面升级。

1） 数据获取方式优化

我们将原先基于用户自定义参数调用Python脚本的方式，升级为基于HTTP代理的方式。新方案不仅更加灵活轻量，还实现了一次配置永久使用，避免了反复登录服务器修改脚本、调整参数及重启Agent的繁琐操作。借助HTTP Header，我们能够传递更丰富的参数至接口，并获取更为复杂的返回数据结构，大幅提升了可扩展性和可维护性。

2）嵌套自动发现实现多层监控

借助7.4版本的嵌套自动发现特性，我们彻底替代了原方案中的定时任务同步机制。新方案架构分为两层自动发现：

• 第一层通过HTTP代理调用门店信息接口，获取全部门店清单，并自动为每个门店创建设备发现规则及路由器的监控项和触发器；
• 第二层在门店层级自动发起设备发现，通过传入门店ID至设备接口，获取该门店中各类设备的名称、IP等关键信息，进而自动生成设备监控项和关联触发器。

同时，通过直观的界面操作即可快速配置设备触发器与路由器触发器之间的依赖关系，极大提升交付效率。

此外，我们也可以将全部数据整合在一个JSON中返回，并借助JSON预处理与LLD宏实现层级间数据继承，完成嵌套发现。但由于“一个自动发现规则中不允许出现重复的自动发现原型”，同时为了复用ICMP Ping监控项，我们选择将设备IP与门店ID组合生成自定义宏，以规避监控项键值重复的问题。

3）支持多区域监控节点的数据分发

我们通过在HTTP请求头中传入{HOSTNAME}，由接口依据预设映射关系返回该Proxy所负责的门店数据，从而实现不同区域的监控节点仅采集其就近门店的监控数据，提升监控效率与网络可靠性。

1.3.4 嵌套级自动发现的扩展

目前方案中我们仅以ICMP监控为例做了演示，但实际上嵌套自动发现可支撑更大规模、更复杂的监控场景。例如，通过SNMP接口采集网络设备性能数据、调用自定义接口或脚本执行特定监控任务等。还有下面这些场景等，有很大的想象空间来实现。

• 公有云场景下：账户->区域->VPC->子网->实例
• K8s：集群->命名空间->Pod->容器
• 网络设备：核心交换机->接入交换机->端口->连接的设备
• 应用服务：应用->服务->实例->线程池
• 存储系统：存储阵列->磁盘组->磁盘->分区
• IOT场景：城市->区域->网关->传感器节点

低级别自动发现（LLD）本就旨在实现监控的动态化管理，而多层嵌套LLD机制与多样化的监控项原型相结合，无疑为复杂运维场景下的动态监控赋予了更强大的能力，展现出极大的想象空间和应用潜力。

二、自动发现配置

2.1 自动发现规则配置

2.2 发现原型配置（二级自动发现）

2.3 监控项原型配置

2.4 触发器原型及触发器依赖配置

尾声

运维者，犹如星际航行领航员；

此行不易，愿我们始终对生产环境保持敬畏。

本篇还有重磅拓展内容将于近期分享，敬请关注！