奇安信防火墙SNMP监控OID指南：从调通到准确采集

1. 为什么写这份OID说明文档：先理解监控侧的"翻译官"

做运维的人都有这种感觉：防火墙买到手，配置好策略，业务跑通，以为万事大吉。直到某天老板问你"最近防火墙CPU是不是又飙了""出口带宽还剩多少"，你打开管理界面看了一眼，手忙脚乱地翻页面，最后只能截图丢过去——那一刻你就知道，一套像样的监控系统该上了。

奇安信防火墙接入Zabbix、Prometheus或者自研监控平台，最核心的一步就是SNMP采集。而SNMP采集的灵魂，是OID。OID这玩意儿说白了就是SNMP世界里的门牌号，每个门牌号对应一个具体的监控项：CPU利用率、内存占用、会话数、接口流量、设备温度、电源状态……没有它，网管软件就是个睁眼瞎。

这份文档的定位，就是给那些需要把奇安信防火墙纳入统一监控的运维工程师、驻场工程师和学生党看的。它不教你怎么配策略，不教你怎么折腾高可用，只专心讲清楚一件事：奇安信防火墙上有哪些用得到的SNMP OID，怎么把它调通，怎么让采集数据准确反映设备真实状态。

我有朋友第一次接奇安信的监控，照着网上通用的"华为/深信服OID列表"去填，结果CPU、内存能采到，但会话数、接口流量全是空的。后来才发现，各家厂商虽然都走SNMP标准，但私有MIB库和OID设计习惯千差万别，拿A家的OID去套B家的设备，能出数才怪。所以这份文档，我按"标准MIB能用的、私有MIB必须查的、底层兜底可以试的"三层逻辑来整理，尽量让你少走弯路。

2. 先把SNMP调通：奇安信防火墙侧最容易踩的四个坑

2.1 配置入口和版本选择：别一上来就SNMPv3

奇安信防火墙的管理界面里，SNMP配置一般藏在"系统管理"或"设备管理"菜单下，不同版本（NGISEC、网神、天眼等产品线）菜单位置略有差异。如果你的设备是旧版本固件，可能要到"系统设置—网络管理—SNMP"里找；新版通常在"系统管理—SNMP配置"。

版本选择上，我的建议是：监控内网用SNMPv2c就够，能上v3就上v3，但别在第一步就死磕v3。为什么？因为很多奇安信设备的SNMPv3配置项里有"认证算法""加密算法""上下文名称"这些概念，一旦填错，采集端报"no response"或者"authentication failure"，排查起来比v2c麻烦得多。先把v2c的只读团体字配好，跑通采集链路，再去纠结要不要升级到v3加密，这个顺序可以帮你省掉大量排障时间。

2.2 只读团体字的命名：不要给监控留一个管理权限

奇安信防火墙的SNMP配置里，团体字分为只读和读写两种。我只建议配只读。曾经见过一个现场，为了图省事，直接在读写团体字里填了"public"，然后整台防火墙可以被人远程改配置——这是把钥匙挂门口，千万别干。

团体字命名还有一个容易被忽略的点：奇安信部分版本对团体字的字符长度和特殊字符有限制，比如不支持某些符号。我踩过坑的是团体字里带了一个"@"，保存时没报错，但采集端怎么都取不到数据，后来用抓包工具一看，设备返回的团体字被截断了。所以建议团体字用字母数字组合，长度控制在16位以内，稳。

2.3 源地址限制：监控服务器IP务必白名单

SNMP服务一旦开启，默认是所有接口都响应。如果你的防火墙有多出口，那意味着互联网侧也可能探测到SNMP端口（UDP 161）。奇安信防火墙SNMP配置里通常有"允许访问的主机"或"源地址限制"选项，务必把监控服务器的IP加进去，其他地址一律拒绝。

这不是矫情。SNMP v2c是明文协议，团体字泄露就等于设备状态泄露。尤其是互联网上有大量扫描器在扫UDP 161，只要团体字是public或者弱口令，分分钟被探测出来。配好源地址限制之后，即使团体字泄露，攻击者也没法直接连接。

2.4 防火墙自身的安全策略：别忘了放行UDP 161

这算是经典翻车现场了。很多人配置完SNMP，在监控端测试"snmpwalk -v2c -c 团体字 防火墙IP"，返回超时。查了半天，发现防火墙策略里没有放行"监控服务器到防火墙自身"的UDP 161流量。

奇安信防火墙默认策略一般是拒绝所有，你需要在"安全策略"中新增一条：源地址为监控服务器IP，目的地址为防火墙自身管理口IP，服务为SNMP（UDP 161），动作为允许。注意，这里的目的地址不能写成"any"，写"any"虽然也能通，但等于是对所有来源开放SNMP探测，白名单形同虚设。目的地址请明确指定到管理口IP或管理网段。

2.5 验证配置：用snmpwalk做一次快速体检

配置完成后，先在监控服务器上用命令验证一下：

bash复制snmpwalk -v2c -c your_community 192.168.1.1 system

能正常返回sysDescr、sysUpTime这些信息，说明SNMP链路已经通了。如果这一步不通，后面谈OID都是白搭。常见的不通原因，一个是防火墙自身策略没放行，另一个是监控服务器和自己不在同一网络没法做路由，还有一个就是团体字错了——这个用snmpwalk的-v和-c参数重试就能排查。

3. OID全景图：奇安信防火墙常用的监控项与OID对照

奇安信防火墙的OID体系，可以拆成两块：一块是标准的RFC1213/RFC2863 MIB-II，另一块是奇安信自己研发的私有MIB。标准MIB主要用于基础网络监控，比如接口流量、系统运行时间、接口状态等；私有MIB则覆盖了CPU、内存、会话数、安全事件等防火墙特有指标，正是这些指标才真正反映一台防火墙的健康度。

3.1 标准MIB部分：接口流量和系统信息

这些OID是所有网络设备通用的，奇安信防火墙也完全兼容。但注意，通过标准MIB只能拿到"接口索引+接口描述"，要把它和实际业务口、管理口对应起来，还需要在监控平台上做一步"索引到接口名"的映射。这个后面讲Zabbix模板时会展开。

3.2 私有MIB部分：CPU、内存、会话数、并发连接

私有MIB的OID前缀通常是奇安信自己申请的厂商私有分支。不同产品线、不同固件版本，甚至虚拟机版和硬件版，OID都可能不一样。这也是"网上抄来的OID列表总是对不上"的根本原因。典型的CPU和内存OID长这样：

text复制1.3.6.1.4.1.35717.1.1.1.1.0    CPU利用率
1.3.6.1.4.1.35717.1.1.1.2.0    内存利用率
1.3.6.1.4.1.35717.1.1.1.3.0    会话总数
1.3.6.1.4.1.35717.1.1.1.4.0    当前并发连接数

注意，这里35717是奇安信的私有企业号，但子节点编号在不同版本里可能重新编排。所以拿到任何一份OID列表，第一步不是填进监控平台，而是先在设备上用snmpwalk去"探测"这些OID是否真的存在、返回值是什么类型。我自己就遇到过：文档上写的是CPU利用率的OID，实际返回的是一个计数器而不是百分比，监控平台画出来的图直接突破天际线。

3.3 安全类指标：会话表、策略命中、攻击事件

防火墙区别于交换机路由器的地方，就在于安全监控指标。奇安信防火墙通过SNMP能暴露的常用安全指标包括：

以下提供一条建议：不要把攻击事件计数的监控期望值设成0。防火墙产生攻击日志是常态，关键看趋势，而不是看有没有。监控告警阈值可以设"单次轮询周期内新增事件数大于某个值"，而不是"总数大于0就告警"。

3.4 物理硬件监控：温度、风扇、电源、CPU核

硬件防火墙最容易被忽略的是物理健康监控。机房空调挂了，设备高温报警，可能先于业务中断给到预警。这类OID一般也能通过snmpwalk在私有MIB分支里发现，常见后缀包括：

text复制1.3.6.1.4.1.35717.1.x.1   CPU温度
1.3.6.1.4.1.35717.1.x.2   风扇转速
1.3.6.1.4.1.35717.1.x.3   电源状态

硬件监控数据在SNMP里通常有两种类型：一种是实时读数，如温度值、转速值；一种是状态码，如电源的"1表示正常，2表示异常"。后者在Zabbix里落地时要注意做值映射，不然告警信息会变成一串数字，看着头大。

4. 探索私有OID的实用方法：别只靠手册，学会自己"找门牌号"

写到这里，你大概已经发现，任何一份固定OID列表都有局限，因为奇安信防火墙的固件迭代频繁，OID小版本差异多。这一节我分享一个方法论，让你在没有最新文档的情况下，也能自己摸出一套可用的OID。

4.1 从系统根节点开始遍历

先加载奇安信自己的MIB文件（通常可以从设备导出或在官方支持站下载），然后用snmpwalk从企业私有根节点开始走：

bash复制snmpwalk -v2c -c your_community -m ALL -M /path/to/mibs 192.168.1.1 1.3.6.1.4.1.35717

如果执行成功，你会看到一堆OID和对应的值。把输出保存成文本，接下来就是"找名字"的功夫。先关注那些返回值为Gauge32或Integer32的节点，它们多半是实时指标；Counter32/Counter64则是计数器，需要做差值。

4.2 没有MIB文件时，用OID命名来找线索

很多时候你拿不到官方MIB文件，只有一份残缺文档。这时不要慌，SNMP树里还有两个"人性化"节点可以帮到你：

• 1.3.6.1.2.1.1.5.0（sysName）：设备主机名，可以用来确认身份
• 1.3.6.1.2.1.1.6.0（sysLocation）：设备位置，可辅助确认你访问的是不是目标设备

然后到私有分支上，用snmpwalk遍历，留意值的变化。比如你手动在防火墙管理界面创建了100条测试连接，再遍历会话数相关节点，看哪个OID的值跟着变化，那基本就是会话总数的OID了。这个方法虽然土，但绝对有效。

4.3 OID值类型判断：一张表讲清楚

这个判断为什么重要？因为很多人把Counter类型的OID直接填成Zabbix的"无符号整数"类型，画出来的图是一条永远向上的斜线，然后满世界问"为什么流量一直涨"。所以拿到OID后，先用snmpwalk单查一次，看看返回的数据类型，再去配置监控项。

5. 监控平台接入实操：以Zabbix为例的完整落地步骤

5.1 创建主机和SNMP接口

在Zabbix里添加奇安信防火墙，主机名可以写设备业务名（比如"FW-核心-01"），可见名建议带上IP和机房位置，方便后期排查。接口选择SNMP，IP填防火墙管理口地址，端口默认161。

版本选择上，如果设备开的是SNMPv2c，就选SNMPv2c，填团体字。SNMPv3则要填安全级别、认证协议、认证密码、加密协议、加密密码。我见过不少人在这一步填错，比如认证协议写MD5但设备只支持SHA，或者加密算法写成DES但设备要求AES。最简单的办法是：先在设备上通过命令行验证v3参数没问题，再往Zabbix里填。

5.2 宏变量设计：把OID集中管理

建议在主机或者模板上设置宏变量，把常用OID抽象成{$CPU_OID}、{$MEM_OID}、{$SESSION_OID}这种形式。好处是，如果固件升级导致OID变化，你只需要修改宏的值，不用把所有监控项挨个改一遍。

我实际维护的机房里，奇安信防火墙有十几个型号，OID存在细微差异。用宏变量之后，每个型号建一个模板，模板里引用同一个宏名字，不同模板的宏值各不相同。后期替换设备时，直接换模板，监控项不用动，省了很多事。

5.3 流量监控的正确姿势：差值+速率

接口流量OID（ifInOctets/ifOutOctets）返回的是计数器，Zabbix里要配置成"差值"或"每秒速率"。

具体步骤：在监控项配置里，类型选"SNMP客户端"，值类型选"无符号整数"，单位填"bps"，然后预处理规则里选择"变化率（每秒）"。这样Zabbix会自动计算两次轮询之间计数器的差值，除以时间间隔，得到每秒字节数。如果你用Prometheus，公式类似：

text复制rate(ifInOctets[2m]) * 8

拿到的是bps，注意和Bps区分，差了8倍。监控面板上如果发现数值异常放大，先检查是不是单位换算错了。

5.4 接口索引映射：从ifIndex到接口名

奇安信防火墙的接口描述（ifDescr）一般是GigabitEthernet1/0/1、GigabitEthernet1/0/2这种格式，但在Zabbix里，你直接用ifIndex作为监控项的键值，画图时看不出哪个接口是哪个。

解决办法有两个：

• 用SNMP的ifDescr作为监控项名称的一部分，在创建监控项时用"接口描述"做动态名称。
• 或者在Zabbix里做一次"接口发现规则"，通过发现接口索引列表，循环创建监控项，并把ifDescr作为监控项名义上的标签。

推荐后者，因为接口发现规则可以自动适应接口的增删。配好之后，防火墙加了个新接口，Zabbix自动就能发现并开始监控，不用手工加监控项。

5.5 告警阈值设置：别被突刺刷屏

CPU、内存、会话数的告警阈值，建议分三级：

• 信息级：CPU > 60%，持续5分钟
• 警告级：CPU > 75%，持续5分钟
• 严重级：CPU > 90%，持续3分钟

这里的关键是"持续"两个字。SNMP采集可能因为网络抖动或设备繁忙出现单次毛刺，如果你的告警条件是"任意一次采集值超过阈值"，一个十秒的毛刺就能把值班手机打爆。Zabbix里配置触发器时一定要加时间范围，比如min(5m)，也就是最近5分钟的最小值都超过阈值才触发。

会话数的告警则要注意基线。一台业务繁忙的核心防火墙，平时会话数可能就有几十万，设个"会话数>10万就告警"毫无意义。我的习惯是：连续监控两周，统计出会话数的正常波动范围，能按周几/时间段设置动态阈值最好，做不到的话，就把告警线设在"最近一周最大值的1.5倍"或"历史峰值的80%"。

6. 实战排查：OID能取到值，但数据不对，问题出在哪

数据不对，比取不到数据更让人头疼。我遇到过三次典型的"能采到值但不合理"的情况，拿出来逐条讲讲。

6.1 CPU利用率永远是0或满格

有一次，监控平台显示某台奇安信防火墙的CPU利用率长期是0%，但设备管理界面里明明显示占用30%左右。查OID返回类型，发现它返回的是一个"剩余CPU百分比"或"空闲率"，而不是利用率。解决办法就是公式取反：100 - 采集值 = CPU利用率。

还有一次相反，一台状态正常的设备CPU利用率长期显示为100%。后来发现采集端把OID对应的计数器类型当成了Gauge来用，每次拿到的都是累计值。这种通常要确认设备是不是返回Counter，如果是，就改成差值计算。

6.2 接口流量数值大得离谱

接口流量OID返回的是字节数，不是比特数。假设你看到某个接口的ifInOctets值是"1250000000"，这表示1.25GB的累计字节数，但如果你的监控平台把它当成"当前速率bps"，瞬间就变成10Gbps，在千兆接口上显然不合理。

正确的换算链路是：计数器差值除以时间间隔 = 每秒字节数，再乘以8 = bps。如果监控平台已经帮你算好差值，但单位是字节/秒（B/s），你还需要再乘8才是bit。单位写错、少乘8，是流量图最常见的"虚高"原因。

6.3 会话数曲线呈阶梯状，像跳楼一样暴跌

某天会话数曲线突然从5万掉到500，然后又慢慢爬回5万，周而复始。第一反应是防火墙重启了？但sysUpTime显示没有重启。后来才发现，是防火墙的会话表存在"会话老化"机制，大量短连接在超时后集中被回收。如果采集时间每次都落在回收完成后，曲线看起来就是阶梯状。

这种情况不算故障，但会影响告警判断。建议把会话数的轮询周期缩短（比如从5分钟改为1分钟），同时在触发器里增加"持续时间"条件，避免因为采样点刚好落在回收后而产生误报。

6.4 抓包排查法：确认SNMP报文是否真的正常返回

如果数据不对又查不出原因，最直接的办法是抓包看SNMP响应。在监控服务器上执行：

bash复制tcpdump -i eth0 udp port 161 -nn -vv

然后从另一台机器上手动执行snmpwalk，观察请求和响应报文。重点看：

• 设备是否返回"TooBig"错误，说明请求的OID范围太大，需要拆小
• 返回的PDU里有没有多个OID值，确认是不是某一次的响应被截断
• 团体字是否正确，错误码是否为"noSuchName"（表示OID不存在）

抓包是最后手段，但往往能一锤定音。很多看起来玄乎的问题，抓包之后发现不过是"请求了设备不存在的OID节点，设备返回noSuchName，采集端没做容错处理，把这个错误当成0值入库而已"。

7. Prometheus等其他平台接入时的OID处理思路

现在很多运维团队用Prometheus+Grafana做监控，SNMP采集器一般是snmp_exporter。接入奇安信防火墙和接入Zabbix的逻辑类似，但有几个地方需要注意。

7.1 snmp_exporter的模块化配置

snmp_exporter通过配置文件定义模块，每个模块对应一组OID集合。可以给奇安信防火墙单独建一个module，把CPU、内存、会话数、接口流量等OID都写进去。例如：

yaml复制auth:
  community: your_community
modules:
  qianxin_firewall:
    walk:
      - 1.3.6.1.2.1.1
      - 1.3.6.1.2.1.2
      - 1.3.6.1.4.1.35717
    metrics:
      - name: sysUpTime
        oid: 1.3.6.1.2.1.1.3.0
        type: gauge
      - name: ifInOctets
        oid: 1.3.6.1.2.1.2.2.1.10
        type: counter
        indexes:
          - labelname: ifIndex
            type: gauge
        lookups:
          - labels: [ifIndex]
            labelname: ifDescr
            oid: 1.3.6.1.2.1.2.2.1.2

这里walk列表是自动遍历的OID范围，metrics列表则是把walk结果映射成Prometheus指标。注意Counter类型指标自动带"_total"后缀，在Grafana里画速率时要用rate()函数。

7.2 Prometheus告警规则示例

yaml复制groups:
  - name: qianxin_firewall_alerts
    rules:
      - alert: 防火墙CPU利用率过高
        expr: qianxin_cpu_usage > 90
        for: 5m
        annotations:
          summary: "防火墙CPU利用率超过90%"
      - alert: 防火墙会话数异常增长
        expr: sum(increase(qianxin_session_count[5m])) > 50000
        for: 10m
        annotations:
          summary: "5分钟内会话数增量超过5万，疑似遭受扫描或攻击"

告警规则的"for"字段就是持续时间，建议都加上，否则单次抖动就会误报。

7.3 Grafana面板的流量图

用ifInOctets、ifOutOctets画流量图时，在Grafana里建议用：

text复制rate(ifInOctets_total{ifDescr="GigabitEthernet1/0/1"}[2m]) * 8

单位选bits/s。如果你看到数值是字节速率，可以先除以8再乘8，或者直接在面板单位里选"bps"并确认源数据是字节。这类问题在Grafana里出现频率极高，提前把单位换算理清楚，能帮你省掉很多调试时间。

8. 长期维护建议：OID清单管理和版本变更应对

SNMP监控上线只是开始，后续维护才是重头。奇安信防火墙固件升级后，OID变化的情况不少见，尤其是跨大版本升级（比如从NGISEC 6.x升到7.x），私有MIB分支可能重新规划。我的长期维护经验有这几点：

8.1 建立Excel或Wiki形式的OID资产台账

每台防火墙的型号、固件版本、SNMP版本、团体字（或v3参数）、CPU OID、内存OID、会话OID、接口索引规则、流量单位换算方式，全部记录在案。不要嫌麻烦，等设备多到一定程度，这台台账就是救命的。

台账里还应该记录"每个OID的值类型"。比如某台设备CPU OID返回Gauge，某台返回Counter，在监控平台上配置的预处理方式就完全不同。不记录吃亏的只会是后来接手的人。

8.2 固件升级前的OID变更测试

防火墙固件升级前，先在测试环境（或者低峰期）用snmpwalk导出当前所有OID值，升级后再对比一遍。重点看私有MIB前缀是否变化、关键OID节点是否被重新编号。如果发现OID变了，先确认设备侧是否提供兼容模式，或者从新固件里重新导出MIB文件，再更新监控模板。

我见过一个真实事故：运维半夜升级防火墙固件，第二天早上发现监控平台一片红——所有SNMP监控项都变成"不支持"。查下来就是OID树整体换了前缀，模板没同步。从那之后，我把"升级前导出OID基线"写进了变更流程，强制执行。

8.3 定期验证SNMP可达性

防火墙的SNMP服务虽然稳定，但偶尔也会因为某些操作被误关或改配置。建议在监控平台上设置一个"系统运行时间"的监控项，如果这个项连续N次取不到值，自动触发告警。或者定期（比如每周）执行一次：

bash复制snmpget -v2c -c your_community 192.168.1.1 1.3.6.1.2.1.1.3.0

能出结果，说明SNMP链路还在；出不来，就得去防火墙上看服务状态和策略有没有被动过。

8.4 结合其他监控手段做补充

SNMP是防火墙监控的主干，但不是全部。有条件的话，建议再叠加两种手段：

• 日志审计：通过Syslog把防火墙的登录日志、策略变更日志、攻击日志送到日志平台，和SNMP数据做关联。
• 业务拨测：从防火墙后面发起定时HTTP/HTTPS探测，验证关键业务是否真的通了。

SNMP告诉你"设备还活着、资源够不够"，业务拨测告诉你"业务到底通不通"，日志告诉你"谁干了什么、发生了什么"。三套数据配合，才能把防火墙监控做扎实。

我在实际项目中，通常会把SNMP的CPU/内存/会话数作为"性能水位"，把Syslog里的"策略命中次数""攻击事件"作为"安全水位"，把业务拨测结果作为"可用性水位"，三个维度一起上。这比单靠SNMP看几十个OID指标要立体得多，也更容易在故障发生前就捕捉到苗头。