Zabbix监控深信服下一代防火墙的完整落地记录去年接手一套新网络环境时领导丢给我一台深信服AF防火墙要求必须纳入Zabbix监控体系。当时全网跑着的服务、交换机、服务器有上百台监控平台已经是Zabbix 6.0就差这台边界设备一直处于盲区状态。说实话刚开始我也以为就是加个主机、填个IP、选个模板那么简单结果实际操作下来坑不少——SNMP配置位置藏得深、OID踩空、模板不通用、告警风暴把钉钉群炸了。这篇文章就把我从零开始把深信服下一代防火墙接入Zabbix的完整过程、踩坑记录和最终能直接照抄的配置方案整理出来给正在做同类事情的运维朋友一个参考。这篇文章适合谁看如果你的环境里也有深信服AF/NGAF系列防火墙需要监控CPU、内存、会话数、接口流量甚至想联动钉钉报警那这篇文章基本上可以抄作业。如果你是刚接触Zabbix监控网络设备的新手文中的原理和排查思路同样有参考价值我尽量把每一步的为什么也讲清楚不只是丢一堆配置命令让你复制。1. 监控方案选型为什么我用Zabbix加SNMP这套组合1.1 先把监控目标定清楚在动手配置之前我习惯先列一个监控清单明确到底要盯哪些指标。很多朋友一上来就开干结果模板导入了一堆监控项数据出来了却不知道看哪些告警阈值也没设置等于白忙一场。对于一台边界防火墙来说最重要的指标其实就那么几类设备健康状态CPU使用率、内存使用率、系统温度、电源和风扇状态这些指标直接反映设备本身是否带病运行。会话与连接能力并发会话数、每秒新建连接数。防火墙是状态检测设备会话表满了才是真正的大事故这个指标往往比CPU更值得关注。接口流量与状态各物理接口和VLAN接口的出入流量、丢包率、错误包数、接口是否宕掉。链路故障或流量突增都要能第一时间感知。安全事件概况能检测到多少攻击、拦截了多少威胁。不过这里有个现实问题SNMP本身不擅长传递安全日志这类信息更适合通过Syslog或API对接后面我会单独讲。理清楚监控目标后再选技术方案就有依据了。我不需要监控防火墙内部每个安全策略的命中次数也不需要把所有URL过滤日志都搬进Zabbix——那些交给深信服自己的控制台和安全平台去管就好。1.2 SNMP协议与Zabbix的适配逻辑Zabbix监控网络设备最常见的手段就是SNMP这是网络设备通用的体检接口。SNMP有v1、v2c、v3三个主要版本我最终选择v2c原因很实际v1太老很多OID支持不完整而且明文团体名community安全性差现在基本淘汰。v3虽然安全性最好支持认证和加密但深信服AF在SNMP v3上的配置项比较多而且Zabbix侧也要同步配置安全级别和协议排查起来麻烦。对于内网监控场景我倾向于够用就好。v2c配置简单就一个读团体名read communityZabbix支持得非常成熟性能也够用。选SNMP的另一个原因是它对防火墙本身的性能影响极小。相比在防火墙上装AgentSNMP只是被动响应管理端的查询请求不会占用防火墙太多CPU和内存。这对一台承载全网流量的边界设备来说是非常重要的考量。注意如果你的防火墙是在公网或半信任网络建议别用v2c裸奔。至少把SNMP源地址限制成Zabbix Server或Proxy的IP深信服控制台里可以配置允许的源IP这样即使团体名泄露攻击者也无法从别的IP读取设备信息。2. 前置准备工作深信服侧和Zabbix侧2.1 深信服防火墙开启SNMP的正确姿势深信服下一代防火墙AF系列的SNMP开关位置在不同版本的控制台上略有差异但大方向是一样的。我这边控制台版本是AF 8.0.x路径为系统 → 网络配置 → 接口区域里找到管理接口然后再到系统 → SNMP也有版本在系统 → 高级设置 → SNMP。关键配置项如下配置项推荐值说明SNMP版本v2c兼容性和安全性平衡读团体名自定义例如zabbix_read相当于SNMP的密码允许管理端IPZabbix Server/Proxy的IP只允许监控平台访问写团体名不启用只用只读权限避免被远程修改接口索引默认全部或者按需选择要暴露的接口填完后先别急着关页面用你的笔记本或者直接在Zabbix Server上敲snmpwalk测试一下能不能读到数据snmpwalk -v 2c -c zabbix_read -On 192.168.1.1 sysDescr如果返回类似SNMPv2-MIB::sysDescr.0 STRING: Sangfor AF ...的信息说明SNMP已经通了。如果超时或返回No Response先检查三件事控制台SNMP总开关有没有打开、允许管理端IP有没有包含Zabbix Server的IP、中间有没有防火墙策略挡了UDP 161端口。2.2 Zabbix环境确认与前置条件在给Zabbix添加防火墙主机之前我建议先确认几件事避免后面配置完才发现环境有问题Zabbix版本我这边是Zabbix 6.0 LTS如果你的版本比较老比如4.x或3.x模板格式可能不兼容导入模板那一步会失败。建议至少用5.0以上版本。SNMP工具Zabbix Server上确保安装了snmpwalk、snmpget这类命令行工具排查OID时非常好用。Ubuntu/Debian下用apt install snmpCentOS/Rocky下用dnf install net-snmp-utils。权限确认添加主机、导入模板需要Zabbix Super Admin或者有一定权限的角色。如果你不是管理员提前找管理员开权限别等到操作到一半被卡住。另外如果你的监控环境已经分了多个网段Zabbix是通过Proxy去采集的话那么深信服SNMP的允许管理端IP里就要填Proxy的IP而不是Zabbix Server的IP。这个细节我现场就踩过配了Server的IP结果Proxy采集全部超时。3. 模板选型与定制从官方模板到私有OID3.1 三种模板来源如何取舍给深信服防火墙选模板我试过三条路各有优劣第一种直接用Zabbix内置模板Zabbix自带Template Network Generic by SNMP和Template Module Interfaces by SNMP这个方案最省事覆盖了接口流量和基础存活检测但对防火墙特有指标会话数、CPU、内存覆盖不足。好消息是CPU和内存这种通用指标在很多设备上可以通过HOST-RESOURCES-MIB读到深信服AF恰好支持这个MIB所以这个内置模板实际能用只是监控项的名字和图形不够精细。第二种官方模板深信服官方提供过一个适用于AF系列防火墙的Zabbix模板包含CPU、内存、会话数等关键监控项。不过这套模板在网上流传的版本比较多有适配Zabbix 4.x的有适配5.x的格式和宏定义不完全一样导入时容易报错。我的经验是找模板时优先看有没有英文原版整合过的中文版本容易出现OID被改错的坑。第三种自建模板用内置模板做底子再针对深信服AF补充私有OID监控项。这个方案最灵活也最推荐。毕竟每台设备的业务场景不同有些人关注SSL VPN在线用户数有些人关注内存池分配统一模板不一定覆盖到。我最终的做法是导入Template Module Interfaces by SNMP作为接口流量监控然后在一个新的自定义模板里加上CPU、内存、会话数、设备名称等监控项。这样既稳定又可控后面就算深信服换了一套API我也只需要改自定义模板里的几个监控项。3.2 自建模板的核心监控项和OID清单以下是我在Template Sangfor AF by SNMP里实际用到的监控项可以直接参考监控项名称OID数据类型说明设备名称.1.3.6.1.2.1.1.5.0字符读取系统名称CPU利用率.1.3.6.1.2.1.25.3.3.1.2.1浮点HOST-RESOURCES的CPU负载内存利用率.1.3.6.1.2.1.25.2.3.1.6.1浮点内存使用情况需要运算当前并发会话数.1.3.6.1.4.1.43518.1.1.1.3.1.0整型深信服私有MIB中的会话数每秒新建连接数.1.3.6.1.4.1.43518.1.1.1.3.2.0整型私有MIB接口入流量每个接口.1.3.6.1.2.1.31.1.1.1.6.x计数器标准IF-MIB接口出流量每个接口.1.3.6.1.2.1.31.1.1.1.10.x计数器标准IF-MIB说实话深信服私有OID在不同版本之间并不是完全一致的上面列的是我实测可用的OID。如果你发现某个OID读取不到数据建议先用下面的命令扫一遍看看snmpwalk -v 2c -c zabbix_read -On 192.168.1.1 .1.3.6.1.4.1.43518如果返回的列表里没有你要的指标就在输出里搜关键词比如session、cpu、memory把具体的OID和值记录下来再回Zabbix里配置。这也说明一个道理任何模板拿到手都要先验证OID不要盲目相信。3.3 内存利用率的计算逻辑这里有一个容易踩坑的地方HOST-RESOURCES-MIB里的内存OID它的值不是直接以百分比返回的而是以KB或者字节为单位需要你在Zabbix监控项的预处理里做计算。我用的是这两个OID总内存.1.3.6.1.2.1.25.2.3.1.5.1总大小单位通常是KB已用内存.1.3.6.1.2.1.25.2.3.1.6.1已使用单位通常是KB在Zabbix里可以建一个已用内存百分比的监控项绑定已用内存这个OID然后在预处理里加一条Change或者Custom multiplier再配合计算型监控项last(//.1.3.6.1.2.1.25.2.3.1.6.1) / last(//.1.3.6.1.2.1.25.2.3.1.5.1) * 100更推荐的做法是直接在监控项配置里启用Preprocessing选择JavaScript写一段简单的计算脚本return value * 100 / 1024; // 假设返回的是KB转为MB后再考虑注意有些深信服版本的内存OID返回值是百分比而不是KB判断方法很简单——先用snmpwalk读取一下如果返回值的范围在0到100之间且带小数多半已经是百分比如果是几万、几十万的数值那就是KB。写预处理前一定要先确认量纲否则图形上的数据全是错的。4. 主机添加与配置实操4.1 添加主机的标准和步骤把防火墙当成一台普通网络设备纳入Zabbix即可不需要装任何Agent。在Zabbix前端操作步骤如下进入数据采集 → 主机点击创建主机。主机名称填AF-边界-生产区或者类似能一眼看明白的名称可见名称我习惯加上IP和设备角色方便大屏展示。模板选择在模板框里搜索Sangfor AF by SNMP选中添加如果已经有现成的接口模板也一并关联上。主机组选择网络设备或你自定义的分组。SNMP接口那里IP填防火墙管理地址端口默认161版本选SNMP v2c团体名填之前配置的zabbix_read。宏设置里确认{$SNMP_COMMUNITY}被覆盖成了你的团体名如果所有防火墙用的团体名都一样直接改模板宏就省事了。保存之后等待30秒左右去监测 → 最新数据筛选这台主机看有没有数据进来。这一步是判断配置成功的最快方式。4.2 宏变量设置的细节Zabbix里宏用得好一台模板能管一个机房的设备。我在这个项目里主要用到了这些宏宏名值作用{$SNMP_COMMUNITY}zabbix_readSNMP团体名{$AF_CPU_CRIT}90CPU告警阈值严重{$AF_CPU_WARN}80CPU告警阈值警告{$AF_MEM_CRIT}90内存告警阈值严重{$AF_SESSION_WARN}100000会话数警告阈值宏配置的层级很清楚主机级宏 模板级宏 全局宏。如果大部分防火墙CPU阈值都差不多我建议在模板宏里定义个别设备CPU长期偏高就单独在主机宏里覆盖这样维护起来不累。4.3 图形聚合与触发器的设计思路数据有了之后光看表格没有感觉图形化展示更重要。我建了一张防火墙总览仪表盘里面用Zabbix自带聚合图形把几类指标放在一起CPU与内存趋势两个单独的Graph Prototype时间范围选最近1小时和最近24小时方便看短期突刺和长期趋势。会话数曲线这个很关键很多故障的前兆就是会话数缓慢爬升等到接近上限时才会引发问题。注意把会话数图形的时间范围拉长到7天趋势才看得出来。各接口出入流量叠加图整理园区网出口和服务器区接口用同一个图形叠加对比流量突增或突降一眼可见。触发器方面我设置的原则是尽量少而准避免告警疲劳。实际生效的触发器就这几条CPU使用率超过85%持续5分钟等级为警告。持续5分钟是为了过滤瞬时峰值。内存使用率超过90%持续3分钟等级为严重。内存告警比CPU更需要关注因为防火墙内存不足很多情况下只能重启设备。接口DOWN网管口和管理口DOWN那必须立刻告警业务口DOWN则按具体业务等级决定是否需要通知。并发会话数超过10万只告警不处理。会话数告警的阈值要根据设备规格来定比如设备最大支持30万会话那么10万告警还有处理空间。注意触发器表达式里的last()函数默认读取的是最后一个值对于CPU这种抖动厉害的指标建议配合min()函数或者avg()函数做平滑。例如min(/AF-边界-生产区/cpu_usage,5m) 85表示最近5分钟内最小值都超过85%这比单次超过85%可靠得多。5. 告警联动让钉钉群在深夜替你值班5.1 钉钉告警媒介的配置路径Zabbix 5.0以上版本自带Webhook集成配置钉钉告警比早期版本用自定义脚本方便太多。我当时用的是Webhook方式不用在Zabbix Server上装Python脚本也不用维护依赖库纯前端配置搞定。大致流程是这样的在钉钉群里添加一个自定义机器人拿到Webhook地址。在Zabbix的告警 → 媒介类型 → 创建媒介类型里类型选Webhook。参数里配置webhook_url为钉钉机器人地址message使用Zabbix默认的消息模板或者自定义成JSON格式。在发送消息的脚本区域写入钉钉要求的数据结构Zabbix的Webhook脚本用JavaScript实现直接把value参数里的JSON包一层放进钉钉要求的msgtype字段里。核心的JavaScript脚本逻辑大致是var params JSON.parse(value); var data JSON.stringify({ msgtype: markdown, markdown: { title: params.title, text: params.message } }); return data;不过需要注意的是Zabbix 6.0的Webhook脚本格式和5.0有些差异大家配置时多参考官方文档中Media Type部分。核心点是Webhook脚本负责把Zabbix的告警信息转成钉钉能识别的JSON请求方式选POSTContent-Type选application/json。5.2 告警通知时效和升级策略告警通知最怕两件事一是该报的不报二是不该报的拼命报。我在钉钉告警里做了两个优化第一告警升级。对于CPU和内存这类指标我设置了告警产生15分钟后仍未恢复则再次通知方式是创建第二个触发器用last()读取上一个触发器的状态配合nodata()函数实现。比如CPU持续高负载15分钟会从警告升级为严重钉钉群里收到的消息会从普通颜色变成红色高亮。第二告警恢复通知。很多人只配了问题通知忘了配恢复通知。结果是告警群里的消息永远只有问题产生没有结束久了就没人看群了。我在媒介类型里同时配置了Problem和Recovery两种事件级别的消息模板恢复消息用绿色标识这样整个告警生命周期闭环了。用下来感觉这套组合拳特别适合夜间值班正常情况下群里很安静出了事有告警恢复了也有回声不需要值班人员一直盯着监控大屏。6. 常见问题与排查技巧实录6.1 高频问题的速查表这里把我试过的所有坑整理成一个速查表方便大家对照排查问题现象可能原因解决办法主机显示Unreachable或SNMP超时防火墙SNMP服务未开启允许管理端IP没加UDP 161被拦确认控制台SNMP开关检查ACL策略用snmpwalk测试有数据但不更新采集间隔过长SNMP超时时间设置太短防火墙资源繁忙导致响应慢调短SNMP采集超时时间降低更新间隔查看Zabbix日志确认超时原因CPU值一直是0CPU OID不对HOST-RESOURCES-MIB不可用用snmpwalk确认实际OID换用私有MIB内存显示几百MB或几千MB单位搞错了KB显示成了MB用预处理转换单位或者直接用百分比OID接口流量为0但有值变化接口索引对应错ARPA类型接口解析异常用snmpwalk .1.3.6.1.2.1.31.1.1.1.1确认接口名和索引映射关系钉钉收不到告警Webhook参数配置错误钉钉机器人安全设置限制了关键词用Postman模拟测试Webhook检查机器人的自定义关键词是否匹配告警风暴一晚上几十条消息触发器表达式设置不合理主机的SNMP代理重启导致数据闪断增加持续时长条件设置nodata()检测调整告警升级策略6.2 SNMP通信排查的标准流程每次遇到主机添加了、模板也关联了、就是没数据这种问题我都会按下面的流程走一遍很快就能定位第一步看Zabbix是否收到SNMP响应。在Zabbix Server上手动执行zabbix_get -s 192.168.1.1 -k system.interface.ping zabbix_get -s 192.168.1.1 -k system.cpu.load[all,avg1]zabbix_get能直观反馈Agent类监控项的状态如果返回报错说明Agent侧的键值问题。第二步确认SNMP OID能正常读取。用snmpget或者snmpwalk做一对一的验证snmpget -v 2c -c zabbix_read -On 192.168.1.1 .1.3.6.1.4.1.43518.1.1.1.3.1.0如果这里超时那问题绝对出在防火墙SNMP配置或网络层面不用在Zabbix里浪费时间。第三步看Zabbix的前端数据是否正常采集。去监测 → 最新数据筛选主机后看监控项最后一次收到的值和时钟是否在更新。如果时钟停留在很久以前说明采集进程根本就没拿到数据。第四步查Zabbix Server日志。日志路径一般是/var/log/zabbix/zabbix_server.log搜索防火墙IP关键词看有没有SNMP time out、Cannot connect等字样。很多时候日志里的错误提示比前端更详细。6.3 深信服AF专用的一些注意事项和普通交换机、路由器不同深信服AF在SNMP监控上有几个细节值得单独提醒会话数OID可能因设备型号而异。AF不同型号如1000、2000、3000系列对私有MIB的支持有一些差异配置前建议先登录控制台查看系统状态里显示的会话数再和SNMP读到的值比对。如果差异很大优先检查OID对不对而不是怀疑数据延迟。跨版本升级后OID可能变更。有次深信服设备做了一次大版本升级我这边原来正常的会话数监控项突然全部No such instance后来一查是私有MIB的OID节点变了。因此防火墙升级后一定要把SNMP监控项重新验证一遍。开启SNMP会增加CPU和内存开销。虽然很小但如果你那台AF本身CPU常年80%以上建议把SNMP查询间隔调大一些比如从30秒改成60秒减少对设备的冲击。深信服AF的HA双机热备状态一般不能直接通过SNMP读取。如果环境使用的是AF双机部署只能监控当前主用设备。备机处于冷备状态SNMP通常不响应这是AF的正常行为。要监控HA状态更适合用AF的API接口或者定期登录控制台巡检。7. 数据质量优化与监控项调优技巧7.1 告别毛刺数据预处理和采集间隔的合理设计SNMP采集有一个天然问题网络设备的数据是计数器直接落库的话一旦设备重启计数器清零图形上会出现一条巨大的下跌假象。Zabbix内置了对计数器的处理能力在监控项类型选择SNMPv2计数器或者通过预处理里的Change per second即可自动处理这类跳变。我遇到的最典型问题是深信服AF的会话数有时候会瞬间抖动一下比如从5万跳到8万又回到5万。经过排查发现是AF控制台里某个会话统计的聚合周期和Zabbix的采集周期错位导致的。解决办法是在监控项预处理里加一条Change只保留变化量超过一定幅度才更新或者用平均值平滑掉瞬时尖峰。实际操作中我是这么处理的会话数监控项预处理里设置了三步分别是Change per second、Change大于1000才更新、Custom multiplier乘以1这样有效滤除了偶发抖动。7.2 数据保留周期和趋势存储的取舍很多人忽略数据保留策略结果Zabbix数据库越来越大最后查询卡顿。在配置这些监控项时也要考虑性能和存储的平衡。我的经验值是这样的原始数据history保留7天对于日常排障足够了。真要看几个月前的细节趋势数据能给出大概方向。趋势数据trends保留365天或者更长用于容量规划和季度回顾。对于接口流量的计数器类型原始数据可以只保留3天因为这类数据波动大留存意义有限CPU、内存、会话数这类指标保留30天更合理方便对比和容量规划。在模板层也可以统一设置不用每台主机单独调。Zabbix支持在模板的监控项页面批量修改历史数据保留时间把新加的监控项都选中然后设置统一的保留天数就可以。7.3 配合大屏展示的图形优化监控最终是要给人看的运维大屏直接展示在用数据。为了让大屏展示更好看、更贴近业务我做了两件事第一给监控项打上标签Tags。比如componentcpu、componentsession、interfacewan1然后在Zabbix仪表盘的聚合图形里用标签过滤——只选需要展示的接口流量而不把全部40个接口都铺上去。标签是个非常灵活的维度极大地提升了图形组装的效率。第二在仪表盘的最近问题组件中用标签过滤只显示levelcritical的告警。因为大屏是摆在办公室门口的如果警告级别的告警也全部显示满屏红色反而没有重点。只显示严重告警才能让大屏真正给人警示的作用。8. 扩展思路除了SNMP还有哪些值得做的监控方向8.1 通过Syslog接入安全告警SNMP适合采集状态和性能数据但安全告警这种事件类信息SNMP并不擅长。深信服AF可以把安全日志、攻击日志通过Syslog实时转发出来。如果你的Zabbix环境里已经用了zabbix_get或者日志监控插件完全可以用Syslog接收器把AF的日志导入Zabbix然后通过触发器对特定攻击类型做告警。不过老实说专门的日志分析平台比如ELK、Splunk更适合做安全日志的深入分析。Zabbix的优势在于把日志产生和设备健康状态结合到一起比如某个接口突然收到大量UDP攻击包的同时CPU和会话数也在攀升这种关联告警才是Zabbix的强项。8.2 调用深信服API实现更深层管理深信服AF提供了RESTful API能查询设备的软件版本、序列号、双机热备状态、安全策略命中统计等丰富信息。如果你的环境里Zabbix已经配了外部脚本External scripts或者使用Webhook类型的监控项可以定期调用API把数据拉回来。我到目前为止没有在Zabbix里深度集成AF的API因为安全和运维两个团队对AF的权限划分比较明确。但对于单兵作战或者小团队来说用Python脚本调用AF API把API返回的数据写成JSON文件再让Zabbix通过zabbix_get去读取确实能实现很多有趣的监控效果。8.3 监控大屏的趋势分析方向很多运维团队在建监控大屏时只关注现在有没有问题忽略了未来可能会出问题。我在后续的优化中准备把会话数、CPU、内存的历史趋势数据按月做分析预测设备什么时候会到瓶颈。比如会话数每月增长10%那么半年后是否要扩容或优化策略这个预判对预算和资源规划特别有价值。Zabbix的趋势数据配合Grafana很容易实现这种预测效果。把Zabbix作为数据源接入Grafana利用Grafana的预测插件或者简单的线性回归函数就能在一个聚合面板上同时展示历史趋势和未来预测区间。这个思路对于一个稳定增长的园区网络来说比单纯的告警更有长远意义。9. 我对这套监控方案的最终体会做到现在这台深信服AF已经稳定运行在Zabbix监控下大半年了。我最大的体会是监控本身不产生价值通过监控发现的问题、避免的事故才是价值。这半年里这套方案帮我抓到了两次真实问题——一次是出口链路流量异常逼近带宽上限另一次是AF内存缓慢泄漏触发了90%告警都是靠监控提前发现的。如果你也想在自己环境里落地这套监控我建议不要一口气追求完美先把最核心的CPU、内存、会话数、接口流量监控起来跑通SNMP链路后再逐步加告警、接钉钉、上大屏。一个能持续运行的简单方案永远好过一个只存在于文档里的完美方案。最后再分享一个小技巧如果你管理多台深信服设备可以在Zabbix里把SNMP团体名统一下然后新建一个AF业务组把所有的AF主机放进这个组同时把写好的仪表盘绑定到这个业务组。这样每次新增防火墙设备时只需要复制主机、换IP所有的图形、触发器、告警自动生效几乎不用额外配置。这套方法我后来复制到交换机、无线控制器监控上同样好用。
Zabbix监控深信服AF防火墙落地实践：SNMP配置与告警联动
Zabbix监控深信服下一代防火墙的完整落地记录去年接手一套新网络环境时领导丢给我一台深信服AF防火墙要求必须纳入Zabbix监控体系。当时全网跑着的服务、交换机、服务器有上百台监控平台已经是Zabbix 6.0就差这台边界设备一直处于盲区状态。说实话刚开始我也以为就是加个主机、填个IP、选个模板那么简单结果实际操作下来坑不少——SNMP配置位置藏得深、OID踩空、模板不通用、告警风暴把钉钉群炸了。这篇文章就把我从零开始把深信服下一代防火墙接入Zabbix的完整过程、踩坑记录和最终能直接照抄的配置方案整理出来给正在做同类事情的运维朋友一个参考。这篇文章适合谁看如果你的环境里也有深信服AF/NGAF系列防火墙需要监控CPU、内存、会话数、接口流量甚至想联动钉钉报警那这篇文章基本上可以抄作业。如果你是刚接触Zabbix监控网络设备的新手文中的原理和排查思路同样有参考价值我尽量把每一步的为什么也讲清楚不只是丢一堆配置命令让你复制。1. 监控方案选型为什么我用Zabbix加SNMP这套组合1.1 先把监控目标定清楚在动手配置之前我习惯先列一个监控清单明确到底要盯哪些指标。很多朋友一上来就开干结果模板导入了一堆监控项数据出来了却不知道看哪些告警阈值也没设置等于白忙一场。对于一台边界防火墙来说最重要的指标其实就那么几类设备健康状态CPU使用率、内存使用率、系统温度、电源和风扇状态这些指标直接反映设备本身是否带病运行。会话与连接能力并发会话数、每秒新建连接数。防火墙是状态检测设备会话表满了才是真正的大事故这个指标往往比CPU更值得关注。接口流量与状态各物理接口和VLAN接口的出入流量、丢包率、错误包数、接口是否宕掉。链路故障或流量突增都要能第一时间感知。安全事件概况能检测到多少攻击、拦截了多少威胁。不过这里有个现实问题SNMP本身不擅长传递安全日志这类信息更适合通过Syslog或API对接后面我会单独讲。理清楚监控目标后再选技术方案就有依据了。我不需要监控防火墙内部每个安全策略的命中次数也不需要把所有URL过滤日志都搬进Zabbix——那些交给深信服自己的控制台和安全平台去管就好。1.2 SNMP协议与Zabbix的适配逻辑Zabbix监控网络设备最常见的手段就是SNMP这是网络设备通用的体检接口。SNMP有v1、v2c、v3三个主要版本我最终选择v2c原因很实际v1太老很多OID支持不完整而且明文团体名community安全性差现在基本淘汰。v3虽然安全性最好支持认证和加密但深信服AF在SNMP v3上的配置项比较多而且Zabbix侧也要同步配置安全级别和协议排查起来麻烦。对于内网监控场景我倾向于够用就好。v2c配置简单就一个读团体名read communityZabbix支持得非常成熟性能也够用。选SNMP的另一个原因是它对防火墙本身的性能影响极小。相比在防火墙上装AgentSNMP只是被动响应管理端的查询请求不会占用防火墙太多CPU和内存。这对一台承载全网流量的边界设备来说是非常重要的考量。注意如果你的防火墙是在公网或半信任网络建议别用v2c裸奔。至少把SNMP源地址限制成Zabbix Server或Proxy的IP深信服控制台里可以配置允许的源IP这样即使团体名泄露攻击者也无法从别的IP读取设备信息。2. 前置准备工作深信服侧和Zabbix侧2.1 深信服防火墙开启SNMP的正确姿势深信服下一代防火墙AF系列的SNMP开关位置在不同版本的控制台上略有差异但大方向是一样的。我这边控制台版本是AF 8.0.x路径为系统 → 网络配置 → 接口区域里找到管理接口然后再到系统 → SNMP也有版本在系统 → 高级设置 → SNMP。关键配置项如下配置项推荐值说明SNMP版本v2c兼容性和安全性平衡读团体名自定义例如zabbix_read相当于SNMP的密码允许管理端IPZabbix Server/Proxy的IP只允许监控平台访问写团体名不启用只用只读权限避免被远程修改接口索引默认全部或者按需选择要暴露的接口填完后先别急着关页面用你的笔记本或者直接在Zabbix Server上敲snmpwalk测试一下能不能读到数据snmpwalk -v 2c -c zabbix_read -On 192.168.1.1 sysDescr如果返回类似SNMPv2-MIB::sysDescr.0 STRING: Sangfor AF ...的信息说明SNMP已经通了。如果超时或返回No Response先检查三件事控制台SNMP总开关有没有打开、允许管理端IP有没有包含Zabbix Server的IP、中间有没有防火墙策略挡了UDP 161端口。2.2 Zabbix环境确认与前置条件在给Zabbix添加防火墙主机之前我建议先确认几件事避免后面配置完才发现环境有问题Zabbix版本我这边是Zabbix 6.0 LTS如果你的版本比较老比如4.x或3.x模板格式可能不兼容导入模板那一步会失败。建议至少用5.0以上版本。SNMP工具Zabbix Server上确保安装了snmpwalk、snmpget这类命令行工具排查OID时非常好用。Ubuntu/Debian下用apt install snmpCentOS/Rocky下用dnf install net-snmp-utils。权限确认添加主机、导入模板需要Zabbix Super Admin或者有一定权限的角色。如果你不是管理员提前找管理员开权限别等到操作到一半被卡住。另外如果你的监控环境已经分了多个网段Zabbix是通过Proxy去采集的话那么深信服SNMP的允许管理端IP里就要填Proxy的IP而不是Zabbix Server的IP。这个细节我现场就踩过配了Server的IP结果Proxy采集全部超时。3. 模板选型与定制从官方模板到私有OID3.1 三种模板来源如何取舍给深信服防火墙选模板我试过三条路各有优劣第一种直接用Zabbix内置模板Zabbix自带Template Network Generic by SNMP和Template Module Interfaces by SNMP这个方案最省事覆盖了接口流量和基础存活检测但对防火墙特有指标会话数、CPU、内存覆盖不足。好消息是CPU和内存这种通用指标在很多设备上可以通过HOST-RESOURCES-MIB读到深信服AF恰好支持这个MIB所以这个内置模板实际能用只是监控项的名字和图形不够精细。第二种官方模板深信服官方提供过一个适用于AF系列防火墙的Zabbix模板包含CPU、内存、会话数等关键监控项。不过这套模板在网上流传的版本比较多有适配Zabbix 4.x的有适配5.x的格式和宏定义不完全一样导入时容易报错。我的经验是找模板时优先看有没有英文原版整合过的中文版本容易出现OID被改错的坑。第三种自建模板用内置模板做底子再针对深信服AF补充私有OID监控项。这个方案最灵活也最推荐。毕竟每台设备的业务场景不同有些人关注SSL VPN在线用户数有些人关注内存池分配统一模板不一定覆盖到。我最终的做法是导入Template Module Interfaces by SNMP作为接口流量监控然后在一个新的自定义模板里加上CPU、内存、会话数、设备名称等监控项。这样既稳定又可控后面就算深信服换了一套API我也只需要改自定义模板里的几个监控项。3.2 自建模板的核心监控项和OID清单以下是我在Template Sangfor AF by SNMP里实际用到的监控项可以直接参考监控项名称OID数据类型说明设备名称.1.3.6.1.2.1.1.5.0字符读取系统名称CPU利用率.1.3.6.1.2.1.25.3.3.1.2.1浮点HOST-RESOURCES的CPU负载内存利用率.1.3.6.1.2.1.25.2.3.1.6.1浮点内存使用情况需要运算当前并发会话数.1.3.6.1.4.1.43518.1.1.1.3.1.0整型深信服私有MIB中的会话数每秒新建连接数.1.3.6.1.4.1.43518.1.1.1.3.2.0整型私有MIB接口入流量每个接口.1.3.6.1.2.1.31.1.1.1.6.x计数器标准IF-MIB接口出流量每个接口.1.3.6.1.2.1.31.1.1.1.10.x计数器标准IF-MIB说实话深信服私有OID在不同版本之间并不是完全一致的上面列的是我实测可用的OID。如果你发现某个OID读取不到数据建议先用下面的命令扫一遍看看snmpwalk -v 2c -c zabbix_read -On 192.168.1.1 .1.3.6.1.4.1.43518如果返回的列表里没有你要的指标就在输出里搜关键词比如session、cpu、memory把具体的OID和值记录下来再回Zabbix里配置。这也说明一个道理任何模板拿到手都要先验证OID不要盲目相信。3.3 内存利用率的计算逻辑这里有一个容易踩坑的地方HOST-RESOURCES-MIB里的内存OID它的值不是直接以百分比返回的而是以KB或者字节为单位需要你在Zabbix监控项的预处理里做计算。我用的是这两个OID总内存.1.3.6.1.2.1.25.2.3.1.5.1总大小单位通常是KB已用内存.1.3.6.1.2.1.25.2.3.1.6.1已使用单位通常是KB在Zabbix里可以建一个已用内存百分比的监控项绑定已用内存这个OID然后在预处理里加一条Change或者Custom multiplier再配合计算型监控项last(//.1.3.6.1.2.1.25.2.3.1.6.1) / last(//.1.3.6.1.2.1.25.2.3.1.5.1) * 100更推荐的做法是直接在监控项配置里启用Preprocessing选择JavaScript写一段简单的计算脚本return value * 100 / 1024; // 假设返回的是KB转为MB后再考虑注意有些深信服版本的内存OID返回值是百分比而不是KB判断方法很简单——先用snmpwalk读取一下如果返回值的范围在0到100之间且带小数多半已经是百分比如果是几万、几十万的数值那就是KB。写预处理前一定要先确认量纲否则图形上的数据全是错的。4. 主机添加与配置实操4.1 添加主机的标准和步骤把防火墙当成一台普通网络设备纳入Zabbix即可不需要装任何Agent。在Zabbix前端操作步骤如下进入数据采集 → 主机点击创建主机。主机名称填AF-边界-生产区或者类似能一眼看明白的名称可见名称我习惯加上IP和设备角色方便大屏展示。模板选择在模板框里搜索Sangfor AF by SNMP选中添加如果已经有现成的接口模板也一并关联上。主机组选择网络设备或你自定义的分组。SNMP接口那里IP填防火墙管理地址端口默认161版本选SNMP v2c团体名填之前配置的zabbix_read。宏设置里确认{$SNMP_COMMUNITY}被覆盖成了你的团体名如果所有防火墙用的团体名都一样直接改模板宏就省事了。保存之后等待30秒左右去监测 → 最新数据筛选这台主机看有没有数据进来。这一步是判断配置成功的最快方式。4.2 宏变量设置的细节Zabbix里宏用得好一台模板能管一个机房的设备。我在这个项目里主要用到了这些宏宏名值作用{$SNMP_COMMUNITY}zabbix_readSNMP团体名{$AF_CPU_CRIT}90CPU告警阈值严重{$AF_CPU_WARN}80CPU告警阈值警告{$AF_MEM_CRIT}90内存告警阈值严重{$AF_SESSION_WARN}100000会话数警告阈值宏配置的层级很清楚主机级宏 模板级宏 全局宏。如果大部分防火墙CPU阈值都差不多我建议在模板宏里定义个别设备CPU长期偏高就单独在主机宏里覆盖这样维护起来不累。4.3 图形聚合与触发器的设计思路数据有了之后光看表格没有感觉图形化展示更重要。我建了一张防火墙总览仪表盘里面用Zabbix自带聚合图形把几类指标放在一起CPU与内存趋势两个单独的Graph Prototype时间范围选最近1小时和最近24小时方便看短期突刺和长期趋势。会话数曲线这个很关键很多故障的前兆就是会话数缓慢爬升等到接近上限时才会引发问题。注意把会话数图形的时间范围拉长到7天趋势才看得出来。各接口出入流量叠加图整理园区网出口和服务器区接口用同一个图形叠加对比流量突增或突降一眼可见。触发器方面我设置的原则是尽量少而准避免告警疲劳。实际生效的触发器就这几条CPU使用率超过85%持续5分钟等级为警告。持续5分钟是为了过滤瞬时峰值。内存使用率超过90%持续3分钟等级为严重。内存告警比CPU更需要关注因为防火墙内存不足很多情况下只能重启设备。接口DOWN网管口和管理口DOWN那必须立刻告警业务口DOWN则按具体业务等级决定是否需要通知。并发会话数超过10万只告警不处理。会话数告警的阈值要根据设备规格来定比如设备最大支持30万会话那么10万告警还有处理空间。注意触发器表达式里的last()函数默认读取的是最后一个值对于CPU这种抖动厉害的指标建议配合min()函数或者avg()函数做平滑。例如min(/AF-边界-生产区/cpu_usage,5m) 85表示最近5分钟内最小值都超过85%这比单次超过85%可靠得多。5. 告警联动让钉钉群在深夜替你值班5.1 钉钉告警媒介的配置路径Zabbix 5.0以上版本自带Webhook集成配置钉钉告警比早期版本用自定义脚本方便太多。我当时用的是Webhook方式不用在Zabbix Server上装Python脚本也不用维护依赖库纯前端配置搞定。大致流程是这样的在钉钉群里添加一个自定义机器人拿到Webhook地址。在Zabbix的告警 → 媒介类型 → 创建媒介类型里类型选Webhook。参数里配置webhook_url为钉钉机器人地址message使用Zabbix默认的消息模板或者自定义成JSON格式。在发送消息的脚本区域写入钉钉要求的数据结构Zabbix的Webhook脚本用JavaScript实现直接把value参数里的JSON包一层放进钉钉要求的msgtype字段里。核心的JavaScript脚本逻辑大致是var params JSON.parse(value); var data JSON.stringify({ msgtype: markdown, markdown: { title: params.title, text: params.message } }); return data;不过需要注意的是Zabbix 6.0的Webhook脚本格式和5.0有些差异大家配置时多参考官方文档中Media Type部分。核心点是Webhook脚本负责把Zabbix的告警信息转成钉钉能识别的JSON请求方式选POSTContent-Type选application/json。5.2 告警通知时效和升级策略告警通知最怕两件事一是该报的不报二是不该报的拼命报。我在钉钉告警里做了两个优化第一告警升级。对于CPU和内存这类指标我设置了告警产生15分钟后仍未恢复则再次通知方式是创建第二个触发器用last()读取上一个触发器的状态配合nodata()函数实现。比如CPU持续高负载15分钟会从警告升级为严重钉钉群里收到的消息会从普通颜色变成红色高亮。第二告警恢复通知。很多人只配了问题通知忘了配恢复通知。结果是告警群里的消息永远只有问题产生没有结束久了就没人看群了。我在媒介类型里同时配置了Problem和Recovery两种事件级别的消息模板恢复消息用绿色标识这样整个告警生命周期闭环了。用下来感觉这套组合拳特别适合夜间值班正常情况下群里很安静出了事有告警恢复了也有回声不需要值班人员一直盯着监控大屏。6. 常见问题与排查技巧实录6.1 高频问题的速查表这里把我试过的所有坑整理成一个速查表方便大家对照排查问题现象可能原因解决办法主机显示Unreachable或SNMP超时防火墙SNMP服务未开启允许管理端IP没加UDP 161被拦确认控制台SNMP开关检查ACL策略用snmpwalk测试有数据但不更新采集间隔过长SNMP超时时间设置太短防火墙资源繁忙导致响应慢调短SNMP采集超时时间降低更新间隔查看Zabbix日志确认超时原因CPU值一直是0CPU OID不对HOST-RESOURCES-MIB不可用用snmpwalk确认实际OID换用私有MIB内存显示几百MB或几千MB单位搞错了KB显示成了MB用预处理转换单位或者直接用百分比OID接口流量为0但有值变化接口索引对应错ARPA类型接口解析异常用snmpwalk .1.3.6.1.2.1.31.1.1.1.1确认接口名和索引映射关系钉钉收不到告警Webhook参数配置错误钉钉机器人安全设置限制了关键词用Postman模拟测试Webhook检查机器人的自定义关键词是否匹配告警风暴一晚上几十条消息触发器表达式设置不合理主机的SNMP代理重启导致数据闪断增加持续时长条件设置nodata()检测调整告警升级策略6.2 SNMP通信排查的标准流程每次遇到主机添加了、模板也关联了、就是没数据这种问题我都会按下面的流程走一遍很快就能定位第一步看Zabbix是否收到SNMP响应。在Zabbix Server上手动执行zabbix_get -s 192.168.1.1 -k system.interface.ping zabbix_get -s 192.168.1.1 -k system.cpu.load[all,avg1]zabbix_get能直观反馈Agent类监控项的状态如果返回报错说明Agent侧的键值问题。第二步确认SNMP OID能正常读取。用snmpget或者snmpwalk做一对一的验证snmpget -v 2c -c zabbix_read -On 192.168.1.1 .1.3.6.1.4.1.43518.1.1.1.3.1.0如果这里超时那问题绝对出在防火墙SNMP配置或网络层面不用在Zabbix里浪费时间。第三步看Zabbix的前端数据是否正常采集。去监测 → 最新数据筛选主机后看监控项最后一次收到的值和时钟是否在更新。如果时钟停留在很久以前说明采集进程根本就没拿到数据。第四步查Zabbix Server日志。日志路径一般是/var/log/zabbix/zabbix_server.log搜索防火墙IP关键词看有没有SNMP time out、Cannot connect等字样。很多时候日志里的错误提示比前端更详细。6.3 深信服AF专用的一些注意事项和普通交换机、路由器不同深信服AF在SNMP监控上有几个细节值得单独提醒会话数OID可能因设备型号而异。AF不同型号如1000、2000、3000系列对私有MIB的支持有一些差异配置前建议先登录控制台查看系统状态里显示的会话数再和SNMP读到的值比对。如果差异很大优先检查OID对不对而不是怀疑数据延迟。跨版本升级后OID可能变更。有次深信服设备做了一次大版本升级我这边原来正常的会话数监控项突然全部No such instance后来一查是私有MIB的OID节点变了。因此防火墙升级后一定要把SNMP监控项重新验证一遍。开启SNMP会增加CPU和内存开销。虽然很小但如果你那台AF本身CPU常年80%以上建议把SNMP查询间隔调大一些比如从30秒改成60秒减少对设备的冲击。深信服AF的HA双机热备状态一般不能直接通过SNMP读取。如果环境使用的是AF双机部署只能监控当前主用设备。备机处于冷备状态SNMP通常不响应这是AF的正常行为。要监控HA状态更适合用AF的API接口或者定期登录控制台巡检。7. 数据质量优化与监控项调优技巧7.1 告别毛刺数据预处理和采集间隔的合理设计SNMP采集有一个天然问题网络设备的数据是计数器直接落库的话一旦设备重启计数器清零图形上会出现一条巨大的下跌假象。Zabbix内置了对计数器的处理能力在监控项类型选择SNMPv2计数器或者通过预处理里的Change per second即可自动处理这类跳变。我遇到的最典型问题是深信服AF的会话数有时候会瞬间抖动一下比如从5万跳到8万又回到5万。经过排查发现是AF控制台里某个会话统计的聚合周期和Zabbix的采集周期错位导致的。解决办法是在监控项预处理里加一条Change只保留变化量超过一定幅度才更新或者用平均值平滑掉瞬时尖峰。实际操作中我是这么处理的会话数监控项预处理里设置了三步分别是Change per second、Change大于1000才更新、Custom multiplier乘以1这样有效滤除了偶发抖动。7.2 数据保留周期和趋势存储的取舍很多人忽略数据保留策略结果Zabbix数据库越来越大最后查询卡顿。在配置这些监控项时也要考虑性能和存储的平衡。我的经验值是这样的原始数据history保留7天对于日常排障足够了。真要看几个月前的细节趋势数据能给出大概方向。趋势数据trends保留365天或者更长用于容量规划和季度回顾。对于接口流量的计数器类型原始数据可以只保留3天因为这类数据波动大留存意义有限CPU、内存、会话数这类指标保留30天更合理方便对比和容量规划。在模板层也可以统一设置不用每台主机单独调。Zabbix支持在模板的监控项页面批量修改历史数据保留时间把新加的监控项都选中然后设置统一的保留天数就可以。7.3 配合大屏展示的图形优化监控最终是要给人看的运维大屏直接展示在用数据。为了让大屏展示更好看、更贴近业务我做了两件事第一给监控项打上标签Tags。比如componentcpu、componentsession、interfacewan1然后在Zabbix仪表盘的聚合图形里用标签过滤——只选需要展示的接口流量而不把全部40个接口都铺上去。标签是个非常灵活的维度极大地提升了图形组装的效率。第二在仪表盘的最近问题组件中用标签过滤只显示levelcritical的告警。因为大屏是摆在办公室门口的如果警告级别的告警也全部显示满屏红色反而没有重点。只显示严重告警才能让大屏真正给人警示的作用。8. 扩展思路除了SNMP还有哪些值得做的监控方向8.1 通过Syslog接入安全告警SNMP适合采集状态和性能数据但安全告警这种事件类信息SNMP并不擅长。深信服AF可以把安全日志、攻击日志通过Syslog实时转发出来。如果你的Zabbix环境里已经用了zabbix_get或者日志监控插件完全可以用Syslog接收器把AF的日志导入Zabbix然后通过触发器对特定攻击类型做告警。不过老实说专门的日志分析平台比如ELK、Splunk更适合做安全日志的深入分析。Zabbix的优势在于把日志产生和设备健康状态结合到一起比如某个接口突然收到大量UDP攻击包的同时CPU和会话数也在攀升这种关联告警才是Zabbix的强项。8.2 调用深信服API实现更深层管理深信服AF提供了RESTful API能查询设备的软件版本、序列号、双机热备状态、安全策略命中统计等丰富信息。如果你的环境里Zabbix已经配了外部脚本External scripts或者使用Webhook类型的监控项可以定期调用API把数据拉回来。我到目前为止没有在Zabbix里深度集成AF的API因为安全和运维两个团队对AF的权限划分比较明确。但对于单兵作战或者小团队来说用Python脚本调用AF API把API返回的数据写成JSON文件再让Zabbix通过zabbix_get去读取确实能实现很多有趣的监控效果。8.3 监控大屏的趋势分析方向很多运维团队在建监控大屏时只关注现在有没有问题忽略了未来可能会出问题。我在后续的优化中准备把会话数、CPU、内存的历史趋势数据按月做分析预测设备什么时候会到瓶颈。比如会话数每月增长10%那么半年后是否要扩容或优化策略这个预判对预算和资源规划特别有价值。Zabbix的趋势数据配合Grafana很容易实现这种预测效果。把Zabbix作为数据源接入Grafana利用Grafana的预测插件或者简单的线性回归函数就能在一个聚合面板上同时展示历史趋势和未来预测区间。这个思路对于一个稳定增长的园区网络来说比单纯的告警更有长远意义。9. 我对这套监控方案的最终体会做到现在这台深信服AF已经稳定运行在Zabbix监控下大半年了。我最大的体会是监控本身不产生价值通过监控发现的问题、避免的事故才是价值。这半年里这套方案帮我抓到了两次真实问题——一次是出口链路流量异常逼近带宽上限另一次是AF内存缓慢泄漏触发了90%告警都是靠监控提前发现的。如果你也想在自己环境里落地这套监控我建议不要一口气追求完美先把最核心的CPU、内存、会话数、接口流量监控起来跑通SNMP链路后再逐步加告警、接钉钉、上大屏。一个能持续运行的简单方案永远好过一个只存在于文档里的完美方案。最后再分享一个小技巧如果你管理多台深信服设备可以在Zabbix里把SNMP团体名统一下然后新建一个AF业务组把所有的AF主机放进这个组同时把写好的仪表盘绑定到这个业务组。这样每次新增防火墙设备时只需要复制主机、换IP所有的图形、触发器、告警自动生效几乎不用额外配置。这套方法我后来复制到交换机、无线控制器监控上同样好用。
