企业官网建设流程全解析

简介：面向Zabbix运维人员的深信服AC监控模板，解决将深信服AC设备统一纳入Zabbix监控体系的问题，适合正在使用深信服AC且需要集中管理网络设备状态的运维工程师或网络管理员。资源包仅2KB，包含1个YAML模板文件，其中整合了完整监控项、触发器与图形配置，导入后即可自动生效，免去手工逐项配置的繁琐。已有1316人学习下载。模板覆盖CPU利用率、内存使用情况、容量剩余、接口进/出流量与接口状态，并进一步包含应用性能、安全事件和系统日志监控，可帮助运维人员及时发现设备过载、网络异常或潜在攻击行为，从而保障网络环境的稳定与安全。通过该模板，用户能快速建立对深信服AC的全方位监控视图，在提升排障效率的同时降低漏报风险，适合作为Zabbix环境下的标准化设备监控方案。 前阵子公司网络又双叒出问题了：办公区上网奇慢，业务同事在群里连环@，我登录深信服AC一看，CPU已经顶到90%多，在线用户数却还在慢慢涨。那一刻我特别尴尬——Zabbix里躺着这台AC主机，但只有一条ping存活监控，CPU、内存、会话数这些关键指标全是空的。因为AC上没有挂任何有用的模板，我压根不知道设备是从什么时候开始不对劲的。

所以后来我专门花了一周，把深信服AC的SNMP指标翻了个遍，整理出一套能直接导入Zabbix的AC监控模板，包括CPU、内存、接口流量、在线用户数、并发会话数，以及配套的告警触发器。这篇就把整个思路、踩坑和最终落地的XML模板都写出来，给正在给AC补监控的朋友做个参考。

需要先说明一点：深信服AC没有官方Zabbix模板，社区里也几乎没有现成方案。你最终拿到的模板，大概率是按照自己的AC型号、版本和SNMP返回情况一点点调出来的，这很正常。本文我会把"怎么探测OID→怎么设计监控项→怎么写成XML→导入后怎么调告警"的完整路径讲清楚。

1. 为什么AC是Zabbix监控里最容易被忽略的盲区

很多网络团队的监控现状是：核心交换机、防火墙、服务器都有正经模板，但AC这类上网行为管理设备往往是"半盲区"。原因不复杂，一是大家默认AC是策略设备，觉得它不承载什么关键数据；二是AC的SNMP实现确实比较"特立独行"，标准OID经常拿不到值，大家都被劝退了。

但恰恰是这种设备，出问题时影响范围最广。它串在用户和互联网之间，CPU被打满、会话表爆了、接口丢包，直接影响的是全公司所有人的上网体验。而且AC故障还经常是缓慢恶化的，不是一下子宕机，没有持续监控就很容易出现"网络慢了一周才发现是AC的问题"这种局面。

给AC做监控，我觉得要抓住三个核心维度：

• 设备健康度：CPU使用率、内存使用率、设备运行时间。这是判断AC"扛不扛得住"的基础。
• 业务承载量：在线用户数、并发会话数。这两个指标直接反映AC的负载压力，也能用来做容量规划。
• 链路质量：各接口的流入/流出流量、错误包、丢包。AC的接口通常接了局域网和运营商出口，链路拥塞和硬件故障都能从这里看出来。

记住这个分类，后面设计监控项的时候就不会乱。AC不是交换机，不需要把几十个接口全部纳进去，但上面这几个指标一个都不能少。

注意：给AC配监控前，先确认自己有没有厂商的技术支持渠道。部分AC型号的SNMP功能默认不开放，需要在控制台开权限，有些还要联系厂商解MIB限制。这个前置条件不满足，后面全是白搭。

2. 先做侦察：在深信服AC上把SNMP和OID摸清楚

2.1 在AC端开启SNMP，顺手把访问控制做了

登录AC的Web控制台，一般在"系统→SNMP配置"里可以开启SNMP服务。这里有两个实际建议：

第一，尽量用SNMP v2c而不是v3。我实测过几台不同版本的AC，它的v3实现稳定性因人而异，有的能正常返回，有的会出现OID间歇性超时。监控场景下v2c配合ACL限制来源IP，已经足够安全。

第二，Community不要用public，改成一段只有监控服务器知道的字符串。Zabbix模板里用宏{$SNMP_COMMUNITY}管理，后面方便统一改。

开启SNMP时还要设置允许管理端访问的来源IP，只放通Zabbix服务器所在网段，不要让AC把SNMP信息暴露给全网段。

2.2 用snmpwalk把AC的OID树扫一遍

准备工作做完后，最关键的环节来了：搞清楚AC到底回了哪些OID。不同版本的AC返回内容差异很大，网上搜到的OID表很可能对不上号，必须用工具实测。

在Zabbix服务器上先装snmp工具，然后分两步走：

# 第一步：看标准MIB树是否支持 snmpwalk -v2c -c your_community -t 5 192.168.1.1 .1.3.6.1.2.1.1 snmpwalk -v2c -c your_community -t 5 192.168.1.1 .1.3.6.1.2.1.25.3.3.1.2 # 第二步：看厂商私有MIB树 snmpwalk -v2c -c your_community -t 5 192.168.1.1 .1.3.6.1.4.1.4242

第一步里的.1.3.6.1.2.1.1是system组，能拿到设备名称、运行时间等基础信息；.1.3.6.1.2.1.25.3.3.1.2是HOST-RESOURCES-MIB里的CPU负载表，如果AC实现了这个MIB，CPU指标可以直接用标准OID拿。但很多AC固件并不支持完整的主机资源MIB，所以必须走第二步，去厂商私有OID树里翻。

1.3.6.1.4.1.4242这个企业号是深信服注册的OID节点。执行完snmpwalk后，你会看到一堆数字节点和字符串值。重点找三类信息：

• 带百分比数字的值，多半是CPU或内存使用率
• 带用户数量含义的值，就是在线用户数
• 各种接口计数器，对应接口流量

探测时多用-t参数调大超时时间，AC的SNMP响应经常偏慢，默认的1秒超时很容易误判为"OID不存在"。拿到完整输出后，把每个关键OID和对应的值记下来，做一张自己的OID对照表。这一步很枯燥，但后面写模板时能省掉80%的瞎猜时间。

3. 监控项怎么定：不只看流量，还要盯住AC的命根子

3.1 先把五类核心指标定下来

根据我自己的监控经验，AC模板里最核心的监控项可以分五类。下面这张表是我在AC 13.x版本上实际用到的OID对应关系，注意不同版本可能不一样，仅供参考：

这里多说一句，很多人在AC上只监控接口流量，这是远远不够的。接口流量大只能说明链路忙，而在线用户数、并发会话数才是AC这个设备特有的、也是最容易出问题的指标。用户数突然掉到接近0，大概率是AC重启了；会话数缓慢爬升到接近上限，说明可能要扩容或者存在异常连接。

3.2 在线用户数和并发会话数的OID怎么确认

这两个指标想从标准OID拿到基本没戏，大多要走私有OID。问题是AC的私有OID树上，每个版本放的位置还不一样。我的经验是，通过snmpwalk输出里的"值特征"反推：

• 在线用户数通常是个十几位以内的整数，且数值与AC控制台显示的在线人数对得上
• 并发会话数一般是个波动明显的数值，会随着上网活动同步变化
• 有些版本把这两个值放在AC的"system resource"节点下，有些则挂在"session"节点附近

确认OID正确性的最好办法，是在控制台里强制踢一个用户下线，然后看对应OID的值有没有同步减一。能对的上的，基本就八九不离十了。

3.3 轮询间隔的建议

AC这类设备的SNMP agent性能有限，轮询间隔不建议太激进。我最开始设置的是30秒，结果Zabbix里动不动就报超时，后来统一改成60秒，问题基本消失。LLD发现规则的刷新间隔普通设置成3600秒就够，接口不会频繁增删，没必要短轮询。

4. 手写一份可直接导入的AC模板XML

4.1 XML骨架和关键节点说明

Zabbix模板本质是一个XML文件，可以在控制台里导入导出。我不喜欢用图形化界面一个个点监控项，那样太慢，直接在XML里改完再导入效率高得多。

模板XML的基本结构是：zabbix_export→template_groups→templates→template，再往下是groups、macros、items、triggers、discovery_rules。如果把模板比作一份菜谱，那么：

• macros是全局调料，放SNMP community这类通用参数
• items是主菜，定义具体采集哪个OID、多久采一次
• discovery_rules是"动态菜单"，让Zabbix自动发现AC上的接口
• triggers是"报警铃"，指标超标时自动响

4.2 一个可用的AC模板XML示例

下面这个XML是基于Zabbix 5.0/6.0格式写的，覆盖了CPU、内存、在线用户数、并发会话数以及接口流量LLD。OID部分需要替换成你自己AC实测到的值，数据结构可以直接借用：

<?xml version="1.0" encoding="UTF-8"?> <zabbix_export> <version>5.0</version> <template_groups> <template_group> <name>Network Devices</name> </template_group> </template_groups> <templates> <template> <template>Sangfor AC by SNMP</template> <name>Sangfor AC by SNMP</name> <description>深信服AC上网行为管理设备监控模板，覆盖CPU、内存、接口流量、在线用户数、并发会话数</description> <groups> <group> <name>Network Devices</name> </group> </groups> <macros> <macro> <macro>{$SNMP_COMMUNITY}</macro> <value>sangfor_read</value> </macro> </macros> <items> <item> <name>AC CPU utilization</name> <type>SNMP_AGENT</type> <snmp_community>{$SNMP_COMMUNITY}</snmp_community> <snmp_oid>1.3.6.1.4.1.4242.1.1.2.1.2.1</snmp_oid> <key>sangfor.ac.cpu.util</key> <delay>60s</delay> <history>7d</history> <trends>30d</trends> <value_type>FLOAT</value_type> <units>%</units> <description>AC CPU使用率，OID请以snmpwalk实测为准</description> </item> <item> <name>AC memory utilization</name> <type>SNMP_AGENT</type> <snmp_community>{$SNMP_COMMUNITY}</snmp_community> <snmp_oid>1.3.6.1.4.1.4242.1.1.2.1.3.1</snmp_oid> <key>sangfor.ac.mem.util</key> <delay>60s</delay> <history>7d</history> <trends>30d</trends> <value_type>FLOAT</value_type> <units>%</units> </item> <item> <name>AC online users</name> <type>SNMP_AGENT</type> <snmp_community>{$SNMP_COMMUNITY}</snmp_community> <snmp_oid>1.3.6.1.4.1.4242.1.1.1.1.1</snmp_oid> <key>sangfor.ac.online.users</key> <delay>60s</delay> <history>7d</history> <trends>30d</trends> <value_type>FLOAT</value_type> </item> <item> <name>AC session count</name> <type>SNMP_AGENT</type> <snmp_community>{$SNMP_COMMUNITY}</snmp_community> <snmp_oid>1.3.6.1.4.1.4242.1.1.1.1.2</snmp_oid> <key>sangfor.ac.session.count</key> <delay>60s</delay> <history>7d</history> <trends>30d</trends> <value_type>FLOAT</value_type> </item> </items> <triggers> <trigger> <expression>last(/Sangfor AC by SNMP/sangfor.ac.cpu.util)&gt;85</expression> <name>AC CPU高：{HOST.NAME} CPU使用率超过85%</name> <priority>WARNING</priority> </trigger> <trigger> <expression>last(/Sangfor AC by SNMP/sangfor.ac.online.users)&lt;5</expression> <name>AC疑似重启：{HOST.NAME} 在线用户数异常下降</name> <priority>HIGH</priority> </trigger> </triggers> <discovery_rules> <discovery_rule> <name>Discover AC network interfaces</name> <type>SNMP_AGENT</type> <snmp_community>{$SNMP_COMMUNITY}</snmp_community> <snmp_oid>1.3.6.1.2.1.2.2</snmp_oid> <key>net.if.discovery</key> <delay>3600s</delay> <item_prototypes> <item_prototype> <name>Interface {#IFDESC} incoming traffic</name> <type>SNMP_AGENT</type> <snmp_community>{$SNMP_COMMUNITY}</snmp_community> <snmp_oid>1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX}</snmp_oid> <key>net.if.in[{#SNMPINDEX}]</key> <delay>60s</delay> <history>7d</history> <trends>30d</trends> <value_type>FLOAT</value_type> <units>bps</units> <preprocessing> <step> <type>MULTIPLIER</type> <params>8</params> </step> </preprocessing> </item_prototype> <item_prototype> <name>Interface {#IFDESC} outgoing traffic</name> <type>SNMP_AGENT</type> <snmp_community>{$SNMP_COMMUNITY}</snmp_community> <snmp_oid>1.3.6.1.2.1.2.2.1.16.{#SNMPINDEX}</snmp_oid> <key>net.if.out[{#SNMPINDEX}]</key> <delay>60s</delay> <history>7d</history> <trends>30d</trends> <value_type>FLOAT</value_type> <units>bps</units> <preprocessing> <step> <type>MULTIPLIER</type> <params>8</params> </step> </preprocessing> </item_prototype> </item_prototypes> </discovery_rule> </discovery_rules> </template> </templates> </zabbix_export>

从Zabbix 6.0开始，SNMP v2c的community在XML里的写法略有变化，但snmp_community节点仍然兼容。如果导入时报错，优先把版本改回5.0格式试试，或者直接用控制台的"导入"按钮走图形校验，错误提示会更清楚。

4.3 接口流量为什么要用LLD而不是写死

AC上接口一般不止一个，有LAN口还有运营商出口，某些型号还分管理口。如果手动一个个加监控项，换一台AC又要重来一遍，太折腾。用LLD规则让Zabbix自动去发现所有接口，然后按{#SNMPINDEX}生成对应的出入流量监控项，模板的一次性和复用性立刻就上来了。

有个坑要提醒：某些AC固件返回的{ifDescr}可能是中文或带空格，作为{#IFDESC}宏放进监控项名称没太大问题，但如果想用Python脚本做后续处理，最好用{#SNMPINDEX}而不是名称。Zabbix的LLD宏值默认会做字符过滤，中文也没事，但别指望它在图表里多优雅。

5. 模板导入、主机关联和告警分级

5.1 导入模板的三个常见报错

把XML内容保存为sangfor_ac_template.yaml或.xml文件，在Zabbix控制台"数据采集→模板→导入"里上传，大概率会遇到下面三个报错：

• template group not found：XML里引用的模板组（比如Network Devices）在系统中不存在。解决方法是先在"数据采集→模板组"里创建同名组，或者把XML里的template_group改成已有的组名。
• item with the same key already exists：模板里某些监控项的key和现有模板冲突。把key改得有辨识度即可，比如都加上sangfor_前缀。
• cannot import template: invalid tag value：XML格式有问题，最常见是保存时带了BOM头，或者标签大小写不匹配。用Notepad++或VS Code把文件转成UTF-8无BOM格式，再重新导入。

5.2 主机接线和宏覆盖

导入成功后，在"数据采集→主机"里选中AC这台主机，点"模板"标签，把Sangfor AC by SNMP链接上去。如果之前已经配过SNMP接口，Zabbix会自动使用主机上的SNMP community；如果没有，就在宏里覆盖{$SNMP_COMMUNITY}，改成你这台AC实际的只读字符串。

注意：模板级宏是默认值，主机级宏会覆盖模板级宏。如果公司有多台AC且community都不一样，不要改模板宏，直接在每台主机上单独覆盖。我习惯把AC的SNMP community规划成统一的，这样模板直接套用，省心很多。

5.3 触发器阈值怎么定才合理

模板里我放了两个示例触发器：CPU超过85%告警、在线用户数异常下降告警。实际部署时阈值一定要根据自己环境调，我给几个判断思路：

• CPU告警设成85%持续5分钟，比单次超过更可靠。Zabbix触发器表达式用min(/模板名/sangfor.ac.cpu.util,5m)>85即可。
• 在线用户数下降告警要小心误报。AC升级、重启、甚至管理操作都可能导致用户数短暂归零。建议用max(/模板名/sangfor.ac.online.users,2m)<5配合恢复表达式，并且只给HIGH级别，避免深夜被无关告警吵醒。
• 会话数更适合做趋势分析，触发告警反而很少用。真正有用的是给它配一个"会话数超过85%容量"的预测型告警，但前提是你知道AC的会话上限是多少。

6. 跑了大半年之后，聊聊坑和优化

这套模板在现网跑了半年多，中间遇到过几个值得记录的问题，写出来给大家避坑。

第一个坑是AC重启后接口计数器"断档"。AC这类设备在线时长久了，网络接口的计数器可能溢出或重置。LLD发现到的接口还在，但流量数据会出现一段空窗。这不是Zabbix的问题，也不是模板的问题，是设备侧SNMP计数器行为导致的。应对方法是给掉线数据做一个5分钟的差值趋势告警，发现连续5分钟数据异常就人工查一下。

第二个坑是AC的SNMP响应速度慢。刚开始轮询间隔设成30秒时，每天都有大量超时记录，看起来像设备不稳定，其实只是SNMP agent忙不过来。后来统一改成60秒，配合Zabbix的usable()函数做数据质量校验，误报率直接降为0。AC这类网关设备，真没必要把采集频率搞得比交换机还快。

第三个坑是AC固件升级后OID变位。半年后厂商做了一次版本升级，在线用户数那个OID突然取不到值了。排查方式还是老一套：snmpwalk重新扫私有树，确认新OID，再回控制台改模板。所以我强烈建议，每次升级AC固件前，先手动snmpwalk导出一份OID基准值存档。有了基线，升级后哪里变了一眼就能看出来。

最后分享一点心得：给AC做监控，最大的价值不是"设备挂了能第一时间发现"，而是"设备快挂之前能提前看到征兆"。CPU缓慢爬升、会话数稳步逼近上限、某个出口接口持续高负载，这些趋势数据才是这份模板真正的回报。在线用户数和并发会话数一定要保留长周期趋势，到了年底做带宽扩容、AC换代评估时，数据拿出来就是最有力的依据。没有监控的AC，就像一个没有仪表盘的驾驶舱，飞得越高心里越没底。花半天时间把模板配好，后面一整年都能睡得踏实。

本文还有配套的精品资源，点击获取