搞运维的同仁应该都有这个经历领导指着一台深信服下一代防火墙NGAF问“最近防火墙负载怎么样这两天有没有攻击拦截”你打开Web管理界面手动截几张图再登录SSH敲几条命令拼一份报告出来。这种事一次两次还能接受时间长了设备多了靠人肉巡检迟早要出事。Zabbix监控NGAF的诉求说白了就是要把这台边界安全设备的CPU、内存、会话数、接口流量、链路状态甚至部分安全事件全部拉进统一的监控体系里让值班大屏上能看到防火墙告警能自动通知到人。这篇内容我不打算搞成那种“照着敲就能成功”的教程——我也是摸过不少版本AF设备才把坑踩熟的所以我会把方案选型、MIB实测、模板配置、触发器调优、告警风暴治理这些环节都撕开讲。不管你是第一次接触Zabbix还是已经在用Zabbix 7.0想扩展监控边界这篇文章都能给你一条能直接落地的路径。1. 为什么要把深信服NGAF送进Zabbix1.1 NGAF在运维中的位置与监控盲区先聊场景。深信服NGAF在政企网络里几乎是边界标配尤其是等保建设环境下很多单位核心出口就是一台AF系列设备。它承担的不只是传统防火墙的访问控制还集成了入侵防御、Web应用防护、病毒检测、勒索病毒专杀、僵尸网络检测这些能力。也就是说它既是边界门禁又是安全传感器这台设备一旦出问题影响的是整个内网的可用性和合规水位。但问题也跟着来了很多团队的日常监控体系里根本没有把NGAF纳入统一监控。平时看它基本靠管理员登录Web管理界面手动看CPU、内存、会话数、接口流量截图汇报。真遇到某个业务半夜甩锅说“网络卡”还得先判断是不是防火墙被打满这一来一回非常被动。更麻烦的是NGAF默认的Web界面并不会主动告诉你“CPU已经在95%以上跑了2小时”也不会因为某条WAN口链路down了就自动发工单除非你单独配置邮件/短信告警。所以把NGAF接入Zabbix目的很纯粹让这台安全设备和其他服务器、交换机一样出现在同一个监控大屏上。CPU、内存、会话连接数、接口入出流量、丢包率、状态开关这些都能用一套体系统一盯。谁出问题值班人员和工单系统第一时间收到通知不用再靠人肉巡检。这也是Zabbix这类开源监控在老牌商业监控之外的强项只要你愿意折腾任何能出SNMP、能出日志、能调API的设备都能被拉进监控体系。NGAF就是一例。1.2 三种监控方式对比SNMP、Syslog日志、API拉取接NGAF进Zabbix主流的接入方式就三种先拉个表对比。接入方式获取内容实时性配置难度适合场景SNMP轮询v2c/v3CPU、内存、会话数、接口流量、上下线状态分钟级轮询周期可控低防火墙侧一个勾选日常资源与链路监控推荐首选Syslog/Trap 日志攻击拦截、威胁检测、策略命中、热点预警等安全告警秒级事件触发中需配置日志转发和接收端解析安全事件监控Zabbix做trap接收或转发到日志平台REST API 拉取设备信息、会话详情、威胁日志、专项报告分钟级脚本轮询高需有开发能力写外部检查脚本定制化监控、自动告警融合实际项目中我做得最多的组合是SNMP做资源与链路监控Syslog做安全事件预警API按需补充。先解释为什么SNMP是主力。NGAF作为网络设备对SNMP协议的支持很成熟设备信息、接口表、CPU内存这些都用标准MIB-II结构暴露Zabbix官方自带的Template Net Network Generic就能覆盖大部分。配置SNMP只需要在AF后台开一个只读团体名限定来源IP然后Zabbix侧填IP和团体名十分钟就能出第一张图形。这是性价比最高的一条路。Syslog和Trap则负责补SNMP看不到的东西。NGAF的价值很大一部分在“检测”上比如某个公网IP对你发起漏洞利用、内网主机中了僵木蠕、某条策略触发热点事件告警这些事件型信息并不会映射成SNMP的数值OID它们只会出现在系统日志里。Zabbix可以通过SNMP trap接收来自AF的告警信息也可以通过外部脚本读取AF的syslog文件或调用API把威胁日志导入自定义监控项。后者通常要开发量所以本文会把重点放在SNMP这套能快速落地的路径上安全事件部分会讲清楚思路和最小可行方案。选型时有个原则能标准协议解决的不去开发脚本能被动收日志的不去主动轮询API。监控是给运维减负的不是给自己造轮子的。SNMP这件“轮子”NGAF已经给你备好了直接用就行。2. 部署前的准备工作2.1 防火墙侧开启SNMP并收敛权限开启SNMP之前先想清楚一件事监控用途的SNMP必须用只读团体名禁止用读写。登录AF的Web管理界面路径一般是“系统 - SNMP管理”或“网络配置 - SNMP”不同版本菜单名称略有差异但大方向一致。配置项主要填这几个SNMP版本建议先用v2c老设备兼容性最好如果环境对安全要求高选v3并配置用户名、认证密码和加密密码把数据封装和认证都开起来。团体名自定义一个足够随机的字符串比如sangfor_ro_2024不要用public/private这些默认值。这个团体名后面要填到Zabbix主机宏里。来源IP限制只允许Zabbix Server的IP访问SNMP服务。很多版本支持填写“允许管理主机”在这里把Zabbix Server地址写进去其余一律拒绝。这是底线操作很多人忽略后果就是SNMP暴露在网络上等于把设备信息裸奔出去。端口默认161保持默认即可除非本机有冲突。开启后在管理PC本地测一下snmpwalk -v2c -c 团体名 防火墙管理IP 1.3.6.1.2.1.1如果能看到sysDescr、sysUpTime这些信息说明SNMP服务已经正常响应。这一步务必在配置Zabbix之前完成不要冲到Zabbix里才排查网络层问题。2.2 确认NGAF的MIB支持范围说句实在话NGAF的SNMP支持做得比较“标准但不完整”。标准部分接口表、系统信息、ARP表、IP地址表这些都有。但CPU使用率、内存使用率这些资源类监控项不同版本对应的OID节点可能会差很多甚至有的老版本只能看到接口表没有CPU和内存的OID。所以部署前一定要做一件事把整棵MIB树先dump出来看一遍。snmpwalk -v2c -c 团体名 防火墙管理IP 1.3.6.1 /tmp/ngaf_snmp_all.txt然后重点找这么几类以1.3.6.1.4.1开头、厂商私有节点下的CPU/内存使用率接口表ifTable下的ifDescr、ifHCInOctets、ifHCOutOctets、ifOperStatus系统资源相关节点。不同AF版本的私有OID差异很大我见过有一台AF 8.0.7的CPU使用率OID在1.3.6.1.4.1.13057.2.8.1.1.1附近另一台AF 9.1又不一样。所以不要迷信网上贴出来的OID清单一定要实测。这也是本文为什么没有直接给你一份“万能OID表”的原因——照着旧OID抄大概率在新版本上拿到空数据。2.3 Zabbix侧版本与网络准备Zabbix Server这边版本我建议至少是6.x现在很多团队已经上7.0了。Zabbix的SNMP监控能力从5.0到7.0变化不大但7.0在Webhook媒介、预处理、仪表盘编排上更顺手后面接钉钉告警会省事很多。如果还在用4.x建议先升级再折腾否则很多模板和预处理功能用不上。网络层面要确认三件事Zabbix Server到NGAF管理口/业务网口的SNMP可达即UDP 161端口通NGAF的SNMP来源IP限制已放通Zabbix Server地址Zabbix Server上装了snmp工具调试时可以手工walk验证。用Linux命令检查很直接nc -vuz 防火墙IP 161检测UDP端口再配合snmpwalk验证团体名和OID权限。这两步要是没过后面添加主机全是红灯。3. Zabbix主机添加与模板应用3.1 新增主机填好SNMP接口不踩字符集坑打开Zabbix前端走“数据采集 - 主机 - 创建主机”。主机名称我用IP后缀或者“AF-区域-业务”这样的命名方式比如NGAF-SH-Edge01方便大屏上区分多台防火墙。关键字段这样填主机名称填会显示在监控列表和告警里的名字建议带业务含义。可见名称可以不填默认同主机名。模板先不急着关联等主机保存后再关联分两步操作更稳。群组建议建一个Network/NGAF避免所有机器堆在默认组里。SNMP接口添加接口时选“SNMP”填入防火墙IP地址端口161版本选SNMPv2c团体名填刚才在AF上配的只读团体名。这里有个常见的坑如果后面要通过宏来管理多个设备的团体名不要在这里把团体名写死而是在宏里统一设置Zabbix会自动优先取主机级宏。有个细节容易被忽略主机名称里如果包含中文或特殊字符在SNMP发现规则和图形里可能出现显示问题建议主机名和可见名用纯英文、数字和横线。接口描述里的中文反而不要紧Zabbix侧显示的是模板里的宏变量。保存后不要急着等数据先用“监测 - 最新数据”看一眼有没有采集到第一笔数值。更新的周期默认1分钟刚添加完可能还是要等一会儿。等不及可以直接在服务器上用snmpwalk做对比确认数据源本身没问题再回来查Zabbix配置。3.2 模板选择官方模板打底自建模板做增量Zabbix对网络设备监控官方自带了几个很实用的模板Template Module Network Generic核心模板包含接口流量、连接数、丢包率、错误包率这些网络设备通用监控项和触发器Template Net Network Generic直接引用上面那个模块模板外加一些主机级宏Template Module ICMP Ping负责可达性监控。对NGAF来说建议直接关联Template Net Network Generic它会把接口发现、流量采集、ICMP可达性这些都带出来。然后在此基础上做一个自己的增量模板Template NGAF Resource只放CPU使用率、内存使用率、会话连接数、风扇/温度如果有OID支持这些NGAF专属监控项。这样做的好处是官方模板升级或新项目复用都方便另一台AF接入时直接关联这两个模板改个IP就能跑。官方模板里宏方面默认是{$SNMP_COMMUNITY}如果在主机上没设置这个宏Zabbix会用默认值public。所以要么在模板宏里改成你的团体名要么在主机宏里统一填。多台防火墙共用同一团体名时直接在模板宏里改如果每台不一样就在主机上单独设置宏模板保持默认。3.3 宏与发现规则关键配置关联模板后进“数据采集 - 主机 - 选中该主机 - 宏”检查一下几个宏{$SNMP_COMMUNITY}团体名{$SNMP_PORT}161一般不用改{$SNMP_TIMEOUT}建议保持默认3s如果网络延迟高可以调到5s{$IFNAME_MATCHES}和{$IFNAME_NOT_MATCHES}接口名匹配模式官方模板里有建议把{$IFNAME_NOT_MATCHES}配成排除管理口、环回口的正则比如^(lo|Stack|VLAN)避免发现出一堆无用的逻辑接口拉低大屏可读性。接口发现规则在模板里是内置的默认用ifDescr作为发现键值。如果需要按ifName或者ifAlias做需要进模板“数据采集 - 发现规则 - 网络接口发现”里改SNMP OID部分。多数场景不用动保持默认即可。到这里主机应该能在2-3分钟内出现接口列表和各接口的流量图形。如果界面上看到接口一大堆先别慌这就是物理口、VLAN子接口、聚合口全被发现出来的结果后面用宏过滤就行。4. 核心监控项与触发器配置4.1 资源监控项CPU、内存、会话数怎么配先说CPU和内存。由于NGAF不同版本OID不统一这里讲的是通用配置思路同时给一个“最可能可用”的OID候选作为参考。在自建模板Template NGAF Resource里添加监控项类型选SNMP代理键值建议这样命名CPU使用率ngaf.cpu.util内存使用率ngaf.mem.util会话连接数ngaf.session.count信息类型根据返回数据来定。如果snmpwalk看到返回的是整数百分比比如98信息类型选“数字(无正负)”单位写成%。如果看到返回的是字符串98%就得加一项预处理用正则表达式([0-9])提取数字输出$1才能变成数值型监控项。这是网上大量模板翻车最常见的地方原始值是带百分号的字符串直接当数字处理结果监控项状态一直是“不支持”。预处理里还有一个高频需求有些OID返回的是千分比比如CPU使用率返回9856真实值是98.56%。这种情况加一条“自定义倍数”预处理除以100保留两位小数。不同版本返回精度不同先在snmpwalk里看清楚原始值再决定。会话连接数在NGAF上通常是Gauge32类型直接作为“数字(无正负)”采进来就可以。如果返回值很大且超过32位上限需要改用64位类型并验证。会话数这个指标对整个资源监控很重要边界设备一旦被SYN Flood打成半连接CPU不一定高但会话数会猛涨所以它往往比CPU更能提前暴露异常。4.2 触发器阈值怎么设才不误报模板里只加监控项是不够的还要把触发器配上不然数据进了Zabbix也是死数据。CPU使用率的触发器我用的是last(/Template NGAF Resource/ngaf.cpu.util) 85严重级别警告恢复表达式last(/Template NGAF Resource/ngaf.cpu.util) 70这里有个经验触发阈值的恢复值不要等于阈值要留15%左右的回落区间。NGAF的CPU在业务高峰会短时间冲上去如果恢复值也是85就会在85附近反复抖动产生告警风暴。恢复值设70等于告诉Zabbix“CPU真降下来了才算恢复”这是血泪教训。内存使用率同理阈值90恢复值80。会话数阈值则要按设备型号和带宽来接入型AF和出口型AF的会话承载能力差很多不要套通用值。建议先观察一两周基线再定阈值初始可以先设相对宽松的告警。接口断线触发器官方模板里已经有“接口状态发生变化”的逻辑默认是Operational Status从up变成down时触发。这个保留就行。加上丢包率和错误包率的模板触发器基本链路监控就齐了。4.3 通过发现规则自动监控几十个接口NGAF上的接口少则五六个多则三四十个手工一个个添加监控项会累死人所以必须用发现规则。官方网络模板内置的接口发现规则工作流程是轮询ifTable拿到所有接口索引、描述、类型然后为每个接口自动生成4组监控项入流量、出流量、入错误包、出错误包以及速度、状态等附属监控项。你什么都不用做它自动铺开。但自动铺开带来的问题也需要处理接口名太乱。物理口、VLAN接口、子接口混在一起大屏上全列出来能刷好几屏。解决办法是模板宏{$IFNAME_NOT_MATCHES}配置正则把不想看的接口排除掉比如排除^(loop|NULL|VLAN|veth)只关注物理口和关键的聚合口。流量单位。官方模板对接口流量用的是64位计数器入出流量单位自动换算成bps。Zabbix 5.0对units的处理很智能直接显示Mb/s、Gb/s不用手工除。聚合口的ifHighSpeed异常。有些AF的聚合口速率OID返回0会导致模板里根据接口速率计算利用率的监控项出错。遇到这种情况直接在发现动作中禁用该监控项或者给聚合口单独建一个监控项用入流量和出口带宽手动算。5. 可视化大屏与告警通知落地5.1 聚合图形与仪表盘把防火墙数据摆上大屏监控数据进来了接下来就是让领导看得爽、让值班人员看得懂。Zabbix 7.0的仪表盘可以做多块面板自由编排。我会给单台NGAF建一个独立的面板布局大概是顶部CPU使用率折线图、内存使用率折线图、会话连接数柱状图时间范围统一选最近6小时中部WAN口入流量、出流量两条折线叠加重点关注带宽水位下部接口状态列表用“最新数据”组件直接把所有接口的up/down、错误包显示出来右侧近24小时触发器告警列表让值班人员一进来就能看到有没有未恢复的问题。如果有多台NGAF再建一个总览仪表盘每个设备占一个小面板放CPU、会话数、主要链路流量。总览面板用“图表”组件里的多主机图或者最新数据筛选可以一次把十几台防火墙的关键指标拉进同一张图里对比非常适合汇报和早会巡检。有个小技巧Zabbix的仪表盘支持给图表面板配置“自定义缩放”鼠标拖选时间段可以放大区域。建议把每个关键图表的“显示描述”打开写上这个面板的含义和负责人避免值班同事看半天不知道CPU图是谁的。5.2 告警通知接钉钉/企业微信7.0的Webhook玩法数据上了大屏只是第一步真正的价值是“有问题第一时间通知到人”。Zabbix 7.0对Webhook媒介支持很完善接入钉钉机器人基本不用写脚本。实现思路是在钉钉群添加一个自定义机器人拿到Webhook地址然后在Zabbix的“告警媒介类型”里新建一个Webhook类型媒介把地址配置进去再把DefaultMessage里放上{ALERT.SUBJECT}、{ALERT.MESSAGE}、{HOST.NAME}、{ITEM.NAME}、{ITEM.LASTVALUE}这些宏触发时Zabbix会自动POST给钉钉。企业微信机器人也是同样的路子只是Webhook格式不同。Zabbix 7.0自带的告警媒介类型里甚至有社区做好的现成模板导入改个Webhook地址就能用。这里不展开代码只说要点告警内容里务必带主机名、监控项名、当前值、链接否则值班人员收到告警还得登录Zabbix自己查是哪台设备出了问题。告警发送策略方面Zabbix的报警升级机制建议利用起来先发送给值班群5分钟没恢复升级发给网络维护组30分钟没恢复发给运维负责人。在故障期间让不同角色的人知道该由谁来处理比一堆人同时收到告警更高效。5.3 告警风暴的经典抑制手段NGAF接入Zabbix后最容易翻车的就是告警风暴。这里整理我实际踩过的坑和对应解法接口误报产生“连接断开”海量告警。NGAF设备上有大量VLAN子接口和虚拟接口业务侧某个虚拟接口闪断触发器就疯狂触发。解法是把{$IFNAME_NOT_MATCHES}正则加上同时把触发器改为“最近2次数据都down才触发”增加持续时间条件。CPU瞬时高负载误报。前面说过的恢复值回落区间是其一其二是触发器可以加“最近5分钟均值超过阈值”的条件即min(/Template NGAF Resource/ngaf.cpu.util,5m) 85用5分钟均值而不是瞬时值做判断能过滤掉大部分瞬时抖动。设备离线误报。NGAF有管理口和业务口如果监控走的是业务口某些版本在进行配置保存或版本升级时会短暂断SNMP。Zabbix的ICMP可达性监测如果和SNMP告警同时触发值班手机会瞬间刷屏。推荐策略是ICMP不可达触发器延迟设5分钟SNMP无数据触发延迟设3分钟让运维先有反应时间又不会漏报。维护窗口自动关闭告警。设备升级、割接、拔线作业时提前创建Zabbix维护窗口选择该主机加入维护维护期间触发器不产生告警。每次割接前我第一件事就是建好维护窗口这个习惯能救你无数次。6. 常见问题与排查实录6.1 SNMP不通八成是来源IP和团体名没对齐SNMP不通是接入NGAF时遇到最多的问题出现“ZBX_NOTSUPPORTED”或长时间“不支持”状态按顺序排查防火墙侧来源IP限制。AF的SNMP配置里只放行了指定IP但Zabbix Server实际使用哪个IP访问未必是你以为的那个。用Zabbix Server本机手动snmpwalk测试如果通说明AF侧没问题如果不通换一个放行的IP再试。运维里最常见的乌龙就是做了源IP限制结果放行的是管理口地址而不是Zabbix Server地址。团体名带特殊字符。如果团体名里包含#、、空格这类字符命令行snmpwalk需要加引号Zabbix模板宏里也要注意别被URL转义。建议团体名只用字母、数字和下划线省得后面处处踩坑。UDP 161端口被中间设备过滤。管理口和业务口如果不在同一个网络平面Zabbix Server到AF管理口之间的防火墙策略要放行UDP 161。这个和AF自身的SNMP来源限制是两层经常被忽略。AF版本不完整支持SNMP。极少数老AF固件SNMP配置页面能开但OID返回是空的。这种情况建议先升级AF固件或者降级方案用ICMP Ping加手动SSH巡检脚本兜底先把基础监控糊上再排OID问题。6.2 监控项“不支持”先看原始OID和预处理Zabbix里监控项状态变成红色“不支持”点开详情会看到错误信息最常见的有两种一种是“Cannot find OID”说明Zabbix去轮询这个OID没拿到数据。原因要么是OID写错了要么是SNMP版本或团体名不对要么是该型号固件没有这个节点。处理方式先在命令行snmpwalk确认OID是否真实存在存在就在监控项里用“测试”按钮看返回值不存在就换OID或换固件。另一种是“Value 98% is not numeric or out of range”说明采集到的是字符串监控项信息类型却选了数字。处理方式在预处理里加一步“正则表达式”提取比如模式写([0-9])输出写$1再转为数字类型。如果返回值本身带空格最好加一步“修剪空格”。“不支持”不代表设备有问题更多时候是Zabbix和设备的“翻译”不匹配。排查顺序是从设备原始数据出发一步步往Zabbix侧套而不是反过来。6.3 接口发现出来一堆奇怪的虚拟接口NGAF接口发现的结果通常远超你预期。除了物理口GE1/GE2/GE3还会有VLAN子接口、二层桥接口、管理口、虚拟系统接口如果是多租户模式甚至还有内部和虚拟交换相关的逻辑接口。处理办法有两个层面一是模板宏过滤。把{$IFNAME_NOT_MATCHES}设为^(Bridge|Veth|Tunnel|Vlanif|NULL|lo$)可以一次性过滤掉绝大多数逻辑接口。注意这个宏是正则区分大小写不同AF版本接口命名方式不同先看发现结果再调正则。二是发现动作禁用。如果过滤后还是有个别接口不想监控进入“监测 - 发现”找到该主机的发现记录选中目标接口将对应监控项禁用。但这里有个注意点禁用监控项不会影响下次发现重新创建如果AF重启或接口配置变更接口索引可能变化重新发现后之前禁用的监控项又回来了。因此尽量用模板宏过滤而非手工禁用才能一劳永逸。6.4 告警一直恢复不了触发器状态与恢复表达式的坑还有一种很隐蔽的问题触发器告警后设备CPU已经降下来了但告警一直不恢复。最常见原因是恢复表达式写错。比如你用的不是last(/Template NGAF Resource/ngaf.cpu.util) 70而是继续用last(/Template NGAF Resource/ngaf.cpu.util) 85触发表达式和恢复表达式完全一样那Zabbix永远认为条件仍满足告警当然不会恢复。恢复表达式必须是能判断“问题消失”的条件且表达式中的模板名、监控项键值必须和触发表达式完全一致。另外如果同一条告警涉及多个主机或用到了多值匹配恢复条件也要改为满足所有匹配才算恢复。NGAF多设备场景下建议每台设备单独建触发器或在主机上做触发器继承避免用多主机匹配的触发器造成恢复逻辑混乱。排查技巧在“监测 - 问题”里选中未恢复的告警查看触发器的表达式和“最近评估”信息Zabbix会显示当前各监控项的最新值对照恢复表达式的阈值一眼就能看出来是数据没降下来还是表达式写错了。6.5 安全事件监控的补充实践Syslog加Trap最小方案最后补充一下NGAF安全事件的接入思路这部分很多团队会单独上日志平台但如果你暂时没有日志系统只想让“热点事件预警与处置告警”这类信息进Zabbix也有一个轻量方案。思路是NGAF侧将系统日志或威胁日志以Syslog方式转发给一台采集服务器采集服务器用rsyslog接收并落盘Zabbix使用外部脚本或logrt监控项读取日志文件匹配特定关键字比如“高危”、“攻击拦截”、“病毒查杀”后给触发器产生告警。更“Zabbix原生”的做法是用SNMP TrapAF将告警以SNMP Trap发送到Zabbix Server的162端口Zabbix通过SNMP Trap模板接收再靠trap解析规则把OID映射成可读的告警信息。这套方案的好处是实时性极高坏处是需要理解NGAF trap消息体格式部分AF版本对trap消息的支持有限可能需要逐条在Zabbix里加解析规则。我的建议是如果团队已经上了日志平台安全事件日志直接走日志平台更合适Zabbix专注设备资源和链路可用性如果什么都没有那就用“rsyslog接收外部检查脚本”的过渡方案先把高优先级安全告警接进来后续再迁到专业日志平台。监控体系不是越复杂越好而是数据能正确流动、告警能准确送到人手里就是成功。写到这里整套NGAF接入Zabbix的路径已经清晰了。我个人在实际操作中最受益的一个习惯是每次接新设备前先在防火墙命令行上把SNMP OID树完整dump一份存档放到Zabbix模板的同名注释里。这样固件升级后如果OID漂移翻出存档一对比很快能定位是设备改了还是配置错了。监控设备的本质是理解设备的“性格”NGAF虽然版本差异大但这套“先实测MIB、再套模板、再调阈值”的方法论换到任何品牌防火墙、交换机上都一样适用。希望这些踩坑经验能帮你少走几步弯路。