Zabbix6系列学习12监控SNMP主机02

　　Zabbix6系列学习11：监控snmp主机01
　　继续接着上一篇，本篇将接着继续围绕网络设备展开，本文的对象是框式设备。本文环境Zabbix6。0华为S7706
　　设备版本前端添加网络设备
　　过程可以参考上一篇文章，依然用官方模板HuaweiVRPbySNMP
　　过程忽略查看模板详情
　　该模板的基础监控项包含：ICMP部分SNMPagent可用性系统信息启动时间
　　自动发现包含：实体发现实体状态发现FAN自动发现MPU自动发现接口自动发现
　　监控项就不怎么讲了顾名思义，就是单独的监控项，有完整的路径，以系统名称举例子说明下
　　前端表现
　　那么什么是自动发现呢？以接口名称为例，获取接口名称的OID为1。3。6。1。2。1。2。2。1。2
　　通过snmpwalk可以获取很多值。
　　那么很明显该OID并不是最末梢，再以Console0000为例子，可以看到结果是IFMIB：：ifDescr。3STRING：Console0000
　　可以推测完整OID应该是1。3。6。1。2。1。2。2。1。2。3
　　再进行测试
　　那么到了这里，基本就明白了监控项的原理就是需要有完整的OID，如果是这种带动态的OID，是无法单独去形成监控项的，同时我们不可能手工先去遍历所有的OID，再进行手动写每个监控项，所以自动发现方案由此产生。那么这里会有两个宏值，就是｛SNMPINDEX｝和｛SNMPVALUE｝
　　通过上面两个值可以完成复杂的监控项自动创建的，在Zabbix里需要注意键值这个选项，该选项在每一台主机里是不能存在重复情况的，所以变量显得尤为重要，｛SNMPINDEX｝代表刚刚遍历出的索引号。
　　而这些索引号又是与其他监控项息息相关的。
　　还是通过一个例子来举例吧，以本文EthTrunk10的流量为例，按照正常的逻辑走一遍
　　首先遍历出名称，用ifDescr1。3。6。1。2。1。2。2。1。2。3
　　找到EthTrunk10的值IFMIB：：ifDescr。107STRING：EthTrunk10
　　由此得知，该完整OID即为1。3。6。1。2。1。2。2。1。2。3。107
　　通过ifHCInOctets1。3。6。1。2。1。31。1。1。1。6来查询端口入方向流量，仅凭借下面的这么多值无法确定哪个接口是哪个接口的流量，通过刚刚得到的索引值为107
　　所以再通过完整OID再测试一遍
　　得到的值为32710749372649byte约等于3。7T，，这明显是不对的，那么可以参考该值的介绍，为该接口收到的字节总数，怎么理解呢？就是从系统启动后，该接口累计接收到的数据总和，那么该怎么计算呢？其实就是当前字节数减去前一秒时间的字节总数即为当前接口流量大小。
　　那么逻辑清楚了就看前端是怎么做的，前端也是带了索引值，只不过是动态的，这个索引值从哪里获取的呢？
　　看看母模板，如下图二net。if。in〔ifHCInOctets。｛SNMPINDEX｝〕
　　测试下该值
　　可以看到得出的索引值
　　关于此值会有两个预处理
　　其中一个是就是每秒变化，另外一个就是自定义倍数。这也就印证了之前的值的说法，获取的为累计值，计算得出当前接口口流量大小。
　　那么另外一个怎么理解呢？先来看看模板里的单位为bps，bps全称为bitpersecond，每秒比特，而该值的单位为字节，所以根据换算需要乘以8，就是这么来的
　　那么接口搞清楚了，其他的也一样，这里仅仅是告诉大家是怎么玩的，具体我会拿一章节来讲。简单优化
　　通过这个S7700可以发现莫名奇妙的就有1395个监控项，这么多的监控项是不是每个都有效呢？
　　搞过网络的朋友知道，我们关注的一般是实体的监控，并不是虚拟实体的监控，例如vlanif的接口，另外无用的端口（down）我们也不需要，但是这里也出现了，这是什么原因呢？
　　其实官方模板仅仅提供了一个普适的模板，而且在理想环境中测试的。
　　官方接口模板里一共用到的OID有ifOperStatus1。3。6。1。2。1。2。2。1。8接口状态ifAdminStatus1。3。6。1。2。1。2。2。1。7接口管理状态ifName1。3。6。1。2。1。31。1。1。1。1接口名称ifDescr1。3。6。1。2。1。2。2。1。2接口名称ifType1。3。6。1。2。1。2。2。1。3接口类型ifHCInOctets1。3。6。1。2。1。31。1。1。1。6接口入方向流量ifHCOutOctets1。3。6。1。2。1。31。1。1。1。10接口出方向流量ifInDiscards1。3。6。1。2。1。2。2。1。13接口入方向丢包ifOutDiscards1。3。6。1。2。1。2。2。1。19接口出方向丢包ifInErrors1。3。6。1。2。1。2。2。1。14接口入方向错包ifOutErrors1。3。6。1。2。1。2。2。1。20接口出方向错包ifHighSpeed1。3。6。1。2。1。31。1。1。1。15接口最高速率ifAlias1。3。6。1。2。1。31。1。1。1。18接口描述
　　那么是如何出现上面的情况，这里涉及到另外一个知识点，过滤规则
　　过滤规则就是过滤无用的监控项，可以通过官方模板看到，一共有这么多的过滤规则，看看条件（Typeofcalculation）是全部符合才会展示，那么无需关心规则项是什么，这里采用的是宏，所以进入到宏的界面（主机界面可以进入）
　　｛NET。IF。IFADMINSTATUS。MATCHES｝》。｛NET。IF。IFADMINSTATUS。NOTMATCHES｝》2｛NET。IF。IFALIAS。MATCHES｝》。｛NET。IF。IFALIAS。NOTMATCHES｝》CHANGEIFNEEDED｛NET。IF。IFDESCR。MATCHES｝》。｛NET。IF。IFDESCR。NOTMATCHES｝》CHANGEIFNEEDED｛NET。IF。IFNAME。MATCHES｝》。｛NET。IF。IFNAME。NOTMATCHES｝》（SoftwareLoopbackInterfaceNULL〔09。〕〔Ll〕o〔09。〕〔Ss〕ystemNu〔09。〕veth〔09az〕docker〔09〕br〔az09〕｛12｝）｛NET。IF。IFOPERSTATUS。MATCHES｝》。｛NET。IF。IFOPERSTATUS。NOTMATCHES｝》6｛NET。IF。IFTYPE。MATCHES｝》。｛NET。IF。IFTYPE。NOTMATCHES｝》CHANGEIFNEEDED
　　可以看到宏的取值是用正则表达式代表的
　　那么可以得出，接口管理down，接口名称不符合｛NET。IF。IFNAME。NOTMATCHES｝里的值，接口状态为6的不生成监控项。由于｛NET。IF。IFNAME。NOTMATCHES｝里的正则表达式仅适用系统，所以完全可以忽略〔捂脸〕。那么综合看出，官方模板仅针对端口状态做了限制，而且限制不全面。
　　那么怎么解决呢？
　　以我的经验，要排除以下几种接口管理down接口物理down无用接口类型｛NET。IF。IFOPERSTATUS。MATCHES｝》1｛NET。IF。IFOPERSTATUS。NOTMATCHES｝》CHANGEIFNEEDED｛NET。IF。IFTYPE。MATCHES｝》（536161）｛NET。IF。IFTYPE。NOTMATCHES｝》CHANGEIFNEEDED｛NET。IF。IFADMINSTATUS。MATCHES｝》1｛NET。IF。IFADMINSTATUS。NOTMATCHES｝》CHANGEIFNEEDED｛NET。IF。IFNAME。MATCHES｝》。｛NET。IF。IFNAME。NOTMATCHES｝》Vlanif
　　怎么确定ifType的值呢？直接去已经监控好的主机，由于Vlanif和ethtrunk（未启用LACP协议）是一样的值（53），所以需要加接口名称附加过滤
　　修改完成
　　当监控项出现黄色的感叹号，代表成功过滤掉了
　　可以看到最终监控项少了784个，其实还可以优化很多内容，后续会专门出一篇优化的
　　写在最后
　　上述内容介绍了如何监控一个框式设备，并做了简单优化，下一期来提提如何监控无线设备，这个相对复杂点，优化内容不知道大家有没有学习到，我会单独讲一期，本文仅仅是以接口为例子，到时候会讲一期完整的，欢迎大家关注。