简介面向需要统一监控网络设备的企业运维人员这份Zabbix模板专门用于监控深信服AC设备适用于通过SNMP对接SangforAC的运维场景。压缩包内包含1个yaml格式的模板导出文件大小仅2KB配置涵盖监控项、触发器、图形与屏幕等核心元素导入Zabbix后即可快速完成对AC设备的纳管。目前已有1316人学习适合正在建设Zabbix监控体系并需纳入深信服AC的单位参考。模板聚焦CPU利用率、内存使用、容量、接口流量与状态、应用性能、安全事件及系统日志等关键指标可协助运维人员实时掌握设备健康状况、排查性能瓶颈并及时响应异常事件进而提升网络运行稳定性与安全性。 干网络运维的应该都有这种体验核心交换机、防火墙、服务器都老老实实在 Zabbix 里盯着了唯独那台上网行为管理设备也就是大家口中常说的深信服 AC一直是监控盲区。AC 一旦扛不住压力用户侧就是各种“网络慢、认证卡、网页打不开”出事之后所有人第一反应都是跑去看 AC 控制台可等你想起来的时候故障影响面早就扩散了。把 AC 纳入 Zabbix 监控并不复杂核心就是利用模板。这里说的模板既可以是 Zabbix 自带的通用网络设备模板也可以是自己按 AC 的实际能力定制的模板。我这次把整个流程走完最大的体会是难点不在 Zabbix 本身而在搞清楚 AC 到底暴露了哪些监控能力、数据从哪里拿、哪些指标真的有用。下面把完整的思路、搭建过程、踩过的坑都写出来给正在折腾同类设备的朋友一个直接能抄作业的参考。1. 为什么非要盯着深信服AC不放1.1 先说说这类设备在机房里到底有多关键深信服 AC 在企事业网络里的位置通常是在出口链路的核心节点上所有用户的上网流量都要从它这里过。它不只是做流控很多场景下还承担了认证网关、策略下发、日志审计这些职责。换句话说它不是一台“挂了也无所谓”的旁路设备而是实实在在影响全网上网体验的咽喉节点。这种设备一旦出现 CPU 跑满、内存泄漏、会话数打满这类问题最先体现在用户体验上接入认证失败率变高、网页打开明显变慢、某个应用把出口带宽占满。而 AC 的管理后台通常只有网络团队少数几个人能登其他人看不到内部状态所以必须由 Zabbix 这类系统从外部持续盯住它。说白了把 AC 纳入监控不是为了让监控页面好看而是为了在用户开口抱怨之前先把隐患按下去。1.2 我最后定了这么一份监控指标清单做监控最忌讳的是什么都想盯最后告警泛滥没人当回事。我给自己定了一条原则只盯会直接影响用户体验的指标。落到 AC 上核心就是四类资源健康类CPU 使用率、内存使用率、磁盘占用。这类指标反映 AC 自身的运行状态长期高水位就该扩容或优化策略了。接口状态类各物理接口的收发包流量、接口 up/down 状态。接口状态直接决定链路通断是必须盯的。用户与连接类当前在线用户数、并发连接数、会话数。这两个指标最能反映 AC 实际承担的压力。系统可用性设备是否在线、系统运行时间用来触发“AC 挂了”这种最高优先级告警。按这个清单去建模板监控项数量能控制在 10 到 15 个之间。我见过有些同事一上来就照着设备支持的全部 MIB 建了几十个监控项结果每天被无关告警轰炸最后连 CPU 飙高这种重要告警都被忽略了。监控的度和量永远比监控项的数量更重要。2. 监控方式怎么选SNMP 与 API 的权衡2.1 SNMP 是最稳妥的通用方案深信服 AC 从老到新基本都是支持 SNMP 的虽然不同版本开放程度有差异但系统资源、接口流量这些基础数据通过 SNMP 都能拿得到。Zabbix 对 SNMP 的原生支持很成熟在模板里直接定义 OID、SNMP 版本、认证社区就行只要设备端开了服务、Zabbix 到设备 161 端口网络通数据基本就能采上来。SNMPv2c 是我这次用的版本配置很干净只需要一个只读 community。如果公司安全要求高也可以上 SNMPv3用户、认证协议、加密协议都要在监控项里逐一配置安全性更好但排障成本也高。我自己的偏好是内网专用监控网段里用 v2c把管理网段 ACL 限好效果已经很够用。2.2 API 能拿更多业务数据但也有硬伤深信服 AC 从新版固件开始提供 RESTful API理论上可以拿到在线用户数、应用流量排行、认证事件等 SNMP 拿不到的更贴业务的数据。Zabbix 这边用 HTTP agent 类型的监控项就能做发 GET 请求、拿 token、解析 JSON、取出字段标准流程。这里要说一下API 方案有两个挺现实的硬伤。第一是固件版本跨度大不同版本的 API 路径和认证方式都不一样官方文档又不容易拿到很多运维同事连设备上哪里开 API 入口都找不到。第二是 API 拿到的数据很多是快照型数据做持续趋势告警还需要自己在 Zabbix 里攒历史、写预处理。所以我把 API 当作锦上添花的数据源只有确需做业务级报表时才去折腾模板底座仍然以 SNMP 为主。2.3 我的最终选型思路综合下来最终方案很明确模板主链路走 SNMP把 CPU、内存、接口流量、设备在线状态这些基础能力全部覆盖API 仅在确认 AC 固件支持、且运维确实需要业务数据时作为扩展项单独做。这样既能保证方案在其他型号上可复制也不会因为某个固件版本把整个监控方案锁死。3. 模板搭建实战从探 OID 到挂模板3.1 别急着建监控项先去设备上摸一遍 OID模板的核心就是监控项监控项的核心是 OID。深信服 AC 的私有 MIB 网上基本找不到完整公开文档所以最靠谱的办法是自己在设备上探一遍。我的标准操作是用一台能连通 AC 的 Linux 机器装好 net-snmp执行snmpwalk -v2c -c community -On AC地址 1.3.6.1.2.1.1 snmpwalk -v2c -c community -On AC地址 1.3.6.1.4.1第一条命令看系统基本信息比如系统名称、描述、运行时间这些属于标准 OID所有网络设备基本一致。第二条命令刷私有节点部分固件默认不让外部读太多跑出来可能只有很少内容这时候就需要回 AC 控制台确认 SNMP 服务真正开启有些节点还要在设备侧额外授权才能读到。探到疑似 CPU、内存的节点后连续跑两次 snmpwalk看数值是否随设备负载波动。能跟着变的才是真正能用的指标千万别拿一个恒定值去建监控项那只是给自己加了个永远亮着绿灯的假监控。3.2 基于官方通用模板叠加私有监控项Zabbix 自带一个特别好用的模板Template Network Generic Device SNMPv2。它已经内置了系统名称、系统运行时间、接口流量、接口状态这一整套标准采集逻辑还会用 discovery 规则自动发现设备所有物理接口生成对应的流量监控项和图形。我强烈建议不要重造轮子直接在这个模板基础上扩展。具体做法是新建一个模板命名成 Template Network Sangfor AC SNMPv2然后在配置里把这个官方模板加为父模板。接下来往新模板里添加 AC 的私有监控项比如 CPU 使用率、内存使用率、会话数等。父模板管通用接口子模板管设备特性结构非常干净以后同类设备也能复用。3.3 监控项配置的关键参数具体配置监控项时有几个参数值得认真对待。以 CPU 使用率为例Type 选 SNMP agentOID 填探测到的私有 OIDType of information 选 Numericunsigned单位填 %Update interval 我习惯设 60 秒既不会太频繁也不会错过瞬时尖峰。接口流量监控项有个比较隐蔽的坑Zabbix 的通用模板里接口流量默认走 64 位计数器 OIDifHCInOctets / ifHCOutOctets拿到的是累计字节数必须经过预处理转换成速率才有意义。在 Zabbix 7.x 中官方模板已经处理好了如果是自己建的监控项需要在 Preprocessing 里加 Change per second再根据图表需要选不同的单位。这一步错了图形里看到的就不是流量曲线而是一条只涨不跌的累计线。3.4 触发器、宏和图形一起配好模板建完监控项必须把触发器一并配好否则监控项只是数据采集器没有告警能力。我这套模板主要配了下面几个触发器触发器名称表达式示例说明AC CPU 使用率过高last(/Template Network Sangfor AC SNMPv2/cpu_usage) {$AC_CPU_WARN}持续 5 分钟触发AC 设备离线nodata(/Template Network Sangfor AC SNMPv2/sysUpTime, 3m)13 分钟无数据判定离线AC 内存使用率过高last(/Template Network Sangfor AC SNMPv2/memory_usage) {$AC_MEM_WARN}持续 5 分钟触发AC 会话数过高last(/Template Network Sangfor AC SNMPv2/session_count) {$AC_SESSION_WARN}阈值按网络规模调整注意这里用到了宏变量{$AC_CPU_WARN}、{$AC_MEM_WARN}、{$AC_SESSION_WARN}。把阈值抽成宏好处是同一套模板能用在不同型号、不同规格的 AC 上每台主机单独覆盖宏的值就行不用复制模板。告警媒介那边我临了顺手接了个钉钉机器人和企业微信机器人Zabbix 原生支持都还不错这里就不展开了。图形部分就是把 CPU、内存、会话数、接口流量分别组合成多线图。Zabbix 7.x 里图形已经支持拖拽式布局把监控项拖进去就行不用写 SVG 面板也不用纠结坐标轴。4. 主机接入与数据验证4.1 深信服AC侧需要做的事情模板在 Zabbix 侧准备好了AC 那边也得先把 SNMP 服务开起来。不同版本管理后台入口不完全一样大致路径是在系统配置、网络配置或监控告警这个层级下找 SNMP 设置开启 SNMP 服务后填写只读 community然后把 Zabbix Server 或负责采集的 proxy 的 IP 加进允许管理主机列表避免 SNMP 口被整个内网随便探测。这里提醒一句community 别设成 public也别用纯数字弱口令。虽然这类设备在运维圈里经常被忽略但安全团队定期做网络扫描的时候扫描器第一个试的就是 public。用一个有辨识度的字符串比如 ac-monitor-2024 这种再配合管理网段 ACL安全上就稳很多。4.2 在Zabbix里接入主机的完整流程在 Zabbix 前端里依次走 Hosts - Create host主机名建议和资产台账保持一致比如 SANGFOR-AC-01别用 IP 当主机名后期维护会难受。Interfaces 标签页添加一个 SNMP 接口填 AC 的 IP端口默认 161SNMP version 选 v2ccommunity 填刚才设备上设置的值。接下来切到 Templates 标签页把 Template Network Sangfor AC SNMPv2 加进去点 Add 保存。等大概 30 到 60 秒再去这台主机的 Latest data 列表看系统运行时间、接口名称、CPU、内存这些监控项就应该陆续进来了。如果什么都没进先检查 Hosts 列表里 SNMP interface 的状态是不是 Unknown是的话基本就是设备端没有正常回包。4.3 数据验证与常见坑数据进来了不代表就正确了。我一般会额外做三件事。第一确认接口发现出来的数量和 AC 后台实际物理口数量一致有些设备带 VLAN 口、链路聚合口发现出来数量多一些是正常的重点盯物理口。第二对比 AC 控制台自带的 CPU 和内存显示与 Zabbix 里的数值偏差超过几个百分点就要检查 OID 是不是取错了。第三把图形翻出来看接口流量曲线是否和出口带宽的趋势一致这里最容易发现单位换算的问题。5. 上线后会遇到的那些坑5.1 SNMP数据一直获取不到最常见的是网络层问题。AC 的 SNMP 服务默认绑定的可能不是管理 VLANZabbix 和数据面能 Ping 通但 AC 回包走的源地址是另一个接口导致无响应。其次是安全策略拦截也就是设备上有允许管理主机列表这个功能但 Zabbix 的采集 IP 不在列表里。最后才是 community 不匹配。按这个顺序排查比在 Zabbix 前端瞎试快得多。5.2 接口流量曲线对不上实际带宽如果图形里流量数值和预期差了一个数量级十有八九是计数器精度或单位换算的问题。老式桥接口可能只支持 32 位计数器流量超过一定阈值就会翻转必须用 64 位计数器 ifHCInOctets / ifHCOutOctets。另外Zabbix 模板预处理里如果只做了 speed per second单位是 bytes/s要跟出口带宽的 bit 单位对比就需要在模板里按目标单位配好预处理链。5.3 历史进程堆积告警模板里监控项太多或者采集间隔太短Zabbix 会出现 history syncer processes over 75% 这类内部性能告警。这类告警本身不一定是某个 AC 模板导致的但如果你一次性把几十台 AC 全部挂上新模板历史表和趋势表压力会陡增。稳妥做法是先小范围试点确认采集间隔和监控项数量都合理再批量推送。别一股脑否则模板还没跑热自家 Zabbix 先被你搞挂了。5.4 版本升级带来的模板兼容问题Zabbix 7.x 在模板导入导出上的格式和老版本差别不小旧版 XML 模板导入时可能遇到兼容性报错。我的建议是模板文件在同一大版本内维护比如都用 7.0 就尽量在 7.0.x 之间流转。AC 固件升级后原来能拿到的私有 OID 有可能变化这意味着模板升级后需要重新探测一轮至少盯一眼 CPU 和内存两个核心监控项是否还正常出数。这次把深信服 AC 接入 Zabbix我最大的感受是模板真正值钱的地方不是省去了你一条条手点监控项的时间而是把“应该盯什么、阈值定多少、怎么判断异常”这组经验固化成了可复用的资产。设备多了以后模板就是你的监控大脑每一条触发器都是你和一个具体故障打过交道之后沉淀下来的结论。最后分享一个小习惯我会在每个模板的名称里带上 SNMP 版本和设备厂商比如 Template Network Sangfor AC SNMPv2 这种格式避免以后设备类型多了自己都分不清。再提醒一句如果 AC 有多台务必先在测试机上跑稳一周确认告警准确率上来了再推广到生产节点不然上线第一周就会被告警风暴淹没。本文还有配套的精品资源点击获取