Zabbix 6 系列学习 11：监控 snmp 主机 01

继续接着上一篇，本篇将接着继续围绕网络设备展开，本文的对象是框式设备。

本文环境

• Zabbix 6.0
• 华为 S7706

设备版本

前端添加网络设备

过程可以参考上一篇文章，依然用官方模板 Huawei VRP by SNMP

过程忽略

查看模板详情

该模板的基础监控项包含 ：

• ICMP 部分
• SNMP agent 可用性
• 系统信息
• 启动时间

自动发现包含：

• 实体发现
• 实体状态发现
• FAN 自动发现
• MPU 自动发现
• 接口自动发现

监控项就不怎么讲了 顾名思义，就是单独的监控项，有完整的路径，以系统名称举例子说明下

前端表现

那么什么是自动发现呢？以接口名称为例，获取接口名称的 OID 为1.3.6.1.2.1.2.2.1.2

通过 snmpwalk 可以获取很多值。

那么很明显该 OID 并不是最末梢，再以 Console0/0/0/0 为例子，可以看到结果是

IF-MIB::ifDescr.3 = STRING: Console0/0/0/0

可以推测完整 OID 应该是 1.3.6.1.2.1.2.2.1.2.3

再进行测试

那么到了这里，基本就明白了监控项的原理就是需要有完整的 OID，如果是这种带动态的 OID，是无法单独去形成监控项的，同时我们不可能手工先去遍历所有的 OID，再进行手动写每个监控项，所以自动发现方案由此产生。那么这里会有两个宏值，就是{#SNMPINDEX}和{#SNMPVALUE}

通过上面两个值可以完成复杂的监控项自动创建的，在 Zabbix 里需要注意键值这个选项，该选项在每一台主机里是不能存在重复情况的，所以变量显得尤为重要，{#SNMPINDEX}代表刚刚遍历出的索引号。

而这些索引号又是与其他监控项息息相关的。

还是通过一个例子来举例吧，以本文 Eth-Trunk10 的流量为例，按照正常的逻辑走一遍

首先遍历出名称,用 ifDescr 1.3.6.1.2.1.2.2.1.2.3

找到 Eth-Trunk 10 的值

IF-MIB::ifDescr.107 = STRING: Eth-Trunk10

由此得知，该完整 OID 即为 1.3.6.1.2.1.2.2.1.2.3.107

通过 ifHCInOctets 1.3.6.1.2.1.31.1.1.1.6 来查询端口入方向流量，仅凭借下面的这么多值无法确定哪个接口是哪个接口的流量，通过刚刚得到的索引值为107

所以再通过完整 OID 再测试一遍

得到的值为 32710749372649 byte 约等于 3.7T，，这明显是不对的，那么可以参考该值的介绍，为该接口收到的字节总数，怎么理解呢？就是从系统启动后，该接口累计接收到的数据总和，那么该怎么计算呢？其实就是当前字节数减去前一秒时间的字节总数即为当前接口流量大小。

那么逻辑清楚了就看前端是怎么做的，前端也是带了索引值，只不过是动态的，这个索引值从哪里获取的呢？

看看母模板，如下图二

net.if.in[ifHCInOctets.{#SNMPINDEX}]

测试下该值

可以看到得出的索引值

关于此值会有两个预处理

其中一个是就是每秒变化，另外一个就是自定义倍数。这也就印证了之前的值的说法，获取的为累计值，计算得出当前接口口流量大小。

那么另外一个怎么理解呢？先来看看模板里的单位为 bps，bps全称为 bit per second，每秒比特，而该值的单位为字节，所以根据换算需要乘以8，就是这么来的

那么接口搞清楚了，其他的也一样，这里仅仅是告诉大家是怎么玩的，具体我会拿一章节来讲。

简单优化

通过这个 S7700 可以发现 莫名奇妙的就有1395个监控项，这么多的监控项是不是每个都有效呢？

搞过网络的朋友知道，我们关注的一般是实体的监控，并不是虚拟实体的监控，例如 vlanif 的接口，另外无用的端口（down）我们也不需要，但是这里也出现了，这是什么原因呢？

其实官方模板仅仅提供了一个普适的模板，而且在理想环境中测试的。

官方接口模板里一共用到的 OID 有

• ifOperStatus 1.3.6.1.2.1.2.2.1.8 接口状态
• ifAdminStatus 1.3.6.1.2.1.2.2.1.7 接口管理状态
• ifName 1.3.6.1.2.1.31.1.1.1.1 接口名称
• ifDescr 1.3.6.1.2.1.2.2.1.2 接口名称
• ifType 1.3.6.1.2.1.2.2.1.3 接口类型
• ifHCInOctets 1.3.6.1.2.1.31.1.1.1.6 接口入方向流量
• ifHCOutOctets 1.3.6.1.2.1.31.1.1.1.10 接口出方向流量
• ifInDiscards 1.3.6.1.2.1.2.2.1.13 接口入方向丢包
• ifOutDiscards 1.3.6.1.2.1.2.2.1.19 接口出方向丢包
• ifInErrors 1.3.6.1.2.1.2.2.1.14 接口入方向错包
• ifOutErrors 1.3.6.1.2.1.2.2.1.20 接口出方向错包
• ifHighSpeed 1.3.6.1.2.1.31.1.1.1.15 接口最高速率
• ifAlias 1.3.6.1.2.1.31.1.1.1.18 接口描述

那么是如何出现上面的情况，这里涉及到另外一个知识点，过滤规则

过滤规则就是过滤无用的监控项，可以通过官方模板看到，一共有这么多的过滤规则，看看条件（Type of calculation）是全部符合才会展示，那么无需关心规则项是什么，这里采用的是宏，所以进入到宏的界面（主机界面可以进入）

{$NET.IF.IFADMINSTATUS.MATCHES}  =》^.*
{$NET.IF.IFADMINSTATUS.NOT_MATCHES} =》^2$
{$NET.IF.IFALIAS.MATCHES}  =》.*
{$NET.IF.IFALIAS.NOT_MATCHES}  =》CHANGE_IF_NEEDED
{$NET.IF.IFDESCR.MATCHES}  =》.*
{$NET.IF.IFDESCR.NOT_MATCHES}  =》CHANGE_IF_NEEDED
{$NET.IF.IFNAME.MATCHES}  =》^.*$
{$NET.IF.IFNAME.NOT_MATCHES}  =》(^Software Loopback Interface|^NULL[0-9.]*$|^[Ll]o[0-9.]*$|^[Ss]ystem$|^Nu[0-9.]*$|^veth[0-9a-z]+$|docker[0-9]+|br-[a-z0-9]{12})
{$NET.IF.IFOPERSTATUS.MATCHES}  =》^.*$
{$NET.IF.IFOPERSTATUS.NOT_MATCHES}  =》^6$
{$NET.IF.IFTYPE.MATCHES}  =》.*
{$NET.IF.IFTYPE.NOT_MATCHES}  =》CHANGE_IF_NEEDED

可以看到宏的取值是用正则表达式代表的

那么可以得出，接口管理 down，接口名称不符合{$NET.IF.IFNAME.NOT_MATCHES}里的值，接口状态为 6 的不生成监控项。由于{$NET.IF.IFNAME.NOT_MATCHES}里的正则表达式仅适用系统，所以完全可以忽略[捂脸]。那么综合看出，官方模板仅针对端口状态做了限制，而且限制不全面。

那么怎么解决呢？

以我的经验，要排除以下几种

• 接口管理down
• 接口物理down
• 无用接口类型

{$NET.IF.IFOPERSTATUS.MATCHES}  =》^1$
{$NET.IF.IFOPERSTATUS.NOT_MATCHES}  =》CHANGE_IF_NEEDED
{$NET.IF.IFTYPE.MATCHES}  =》(^53$|^6$|^161$)
{$NET.IF.IFTYPE.NOT_MATCHES}  =》CHANGE_IF_NEEDED
{$NET.IF.IFADMINSTATUS.MATCHES}  =》^1$
{$NET.IF.IFADMINSTATUS.NOT_MATCHES} =》CHANGE_IF_NEEDED
{$NET.IF.IFNAME.MATCHES}  =》^.*$
{$NET.IF.IFNAME.NOT_MATCHES}  =》^Vlanif*

怎么确定 ifType 的值呢？直接去已经监控好的主机，由于Vlanif 和 eth-trunk（未启用LACP协议）是一样的值（53），所以需要加接口名称附加过滤

修改完成

当监控项出现黄色的感叹号，代表成功过滤掉了

可以看到最终监控项少了784个，其实还可以优化很多内容，后续会专门出一篇优化的

写在最后

上述内容介绍了如何监控一个框式设备，并做了简单优化，下一期来提提如何监控无线设备，这个相对复杂点，优化内容不知道大家有没有学习到，我会单独讲一期，本文仅仅是以接口为例子，到时候会讲一期完整的，欢迎大家关注。