Zabbix 3.0监控网络设备有哪些

SNMP简介

1 SNMP 概述

SNMP发展至今以成为应用最广的网络管理协议，目前应用的版本主要有SNMP v1、SNMP v2c和SNMP v3。各版本之间主要的差异表现在信息的定义、通信协议的操作和安全机制上，同时也出现了SNMP应用的两个扩展远程网络监控RMON（Remote Network Monitoring）和RMON2。

从物理层的角度看，使用SNMP对网络进行管理应该包含：网络管理站（NMS）、代理（Agent）、代理服务器（proxy）。在网络管理中，至少需要一个NMS来发出指令和接收通知信息。Agent能够响应管理节点的请求，也能够主动产生通知信息，在网络管理中可以有一个或多个。Proxy在不同网络间或不同版本间转发SNMP请求和通知信息。

从协议层的角度看，SNMP包含：SMI（Structure of Management Information，管理信息结构）和MIB（Management InformationBase，管理信息库）。SMI是ASN.1（Abstract SyntaxNotation one，抽象语法标记）的一个子集，SMI规定了SNMP中可使用ASN.1中的元素、自定义的数据类型和宏等，由这些元素、数据类型、宏及其他相关的语法可定义SNMP中的MIB。MIB是Agent中可被管理对象的抽象描述。在SNMP中，MIB是以树形结构组织进行查看的，树中的每个节点称为OID（Object identifier，对象标识），以类似于网址域名的方式组织，以证书表示各个节点，如 1.3.6.4。

SNMP是属于TCP/IP协议栈的应用层协议，类似于HTTP、FTP协议。只是SNMP传输层使用的是UDP协议。

在SNMP v1中，提供了一种从NMS到Agent的简单的认证模式----Community，NMS向Agent发送请求时需要提供Community字符串，Agent收到字符串后需检查是否和本地的一致。因使用明文传递Community，具有明显的安全隐患。

在1996年IETF发布了SNMP v2c（Community-BasedSNMP v2），该版本在v1的基础上定义了管理站之间的通信，所有支持分布式网络管理，但是在安全机制方面还是和v1的一样。

在1998年IETF发布了SNMP v3，在SNMP v2的基础上扩展了安全性（基于用户的安全模型及视图的访问控制模型）和管理机制。在安全性上，v3版本在协议报文中加入了安全性参数，允许对报文进行加密传输和强制性验证，是一种安全的协议。SNMP v3中使用模块化的思想定义了协议中的各个组成模块，完善了协议的体系结构，最重要的是和SNMP v1和SNMP v2保持兼容。

2 SNMP的功能

SNMP中agent主要负责信息的上传，NMS除了具有SNMP协议的级别功能外，还具有对已发送和接收的信息进行日志记录、通知信息的记录和管理及配置功能，并能提供图形化的配置和管理界面。

为了实现这些功能，SNMP中包含一系列的操作命令，主要有：

• 读取命令：Get系列命令，NMS像Agent发出请求收集管理信息。

• 设置命令：Set命令，NMs将报文中携带的数据写入Agent中。

• 告警功能：Trap系列，Agent主动向NMS发送告警/事件报文的信息。

图 13-1

1、 Get 操作

Get操作是NMS主动发起的操作。在发出的报文中除了携带Get请求标志外，还包括了待请求的OID名称和值对，并以这种名称和值对的绑定形式实现管理对象信息的传递。当然，Get操作中OID对应的值为NILL。

2、 Get-Next操作

Get-Next操作和Get功能类似，不同的是查询的信息并不是报文中绑定的OID信息而是该对象的下一个OID的信息（如果下一个OID信息是可读的）。比如说NMS想要收集Agent端的sysName的下一个节点sysLocation的信息，在请求报文中是sysName.0，而返回的报文中绑定的是sysLocation.0和值。

3、 Get-Bulk操作

实际上是多个Get-Next操作的集合，这是在SNMP v2中新加入的操作方法。

4、Set操作

Set操作可以对具有可写权限的OID进行参数设置，以实现对设备的参数管理、配置和控制等。与Get操作绑定变量不同的是Set中需要绑定对应OID设置的值。

5、Get-Response

Get-Response是对NMS的Get和Set两类命令的响应，根据命令的不同和命令中的参数不同，相应的返回变量绑定的信息及错误状态信息（表明命令执行成功或失败）等。

6、Trap系列

Trap是Agent向NMS主动报告重要事件的机制，对于这种报告，NMS无须对Agent进行响应。Trap信息中的内容表明了什么时间在什么地点发生了什么事情。

3 SMI和MIB

1、SMI

SMI是SNMP中以ASN.1语法定义的信息模块，是ASN.1中的一个子集。这些模块包含了许多特定于SNMP的宏、自定义数据类型和规则等。定义这些宏、数据类型、规则的主要目的有3个：一是表示和定义SNMP应用中特有的数据类型；二是简化管理对象的定义方法；三是分配SNMP中的对象标识符空间及管理对象编码的方法。SNMP正是基于这些定义在RFC文档中的信息模块，实现了协议的标准化，使得各个组织、企业和个人在定义管理对象时保持一致性。

在SNMP中，实际上定义了两个版本的SMI，分别是RFC 1151中定义的SMI v1和RFC 2578中定义的SMI v2。SMI v1中只是简单的定义了几种数据类型、规则说明、OBJECT-TYPE宏等，在SMI v2中则以模块化的定义方式，将所有的相关内容都完整的组织起来了。

SMI v1中定义的基础数据类型有：

• INTEGER：实际上是32位的整数。

• OCTET STRING：0个或多个8位字符（单字节），即可以表示文本字符，也可以表示物理地址。取值范围0 到65535。

• OBJECT IDENTIFIER：以点分十进制表示的OID。

• NULL：只在SMI v1中有定义，在SMI v2中已经不再使用。

• SEQUENCE：定义列表。

• SEQUENCE OF：定义表格。

在SMI v2中对以上的数据类型进一步明确了范围上的限制和更新，另外还引入了BITS类型。

SMI v1中自定义数据类型包括：

• NetworkAddress（网络地址），可以是除Internet外的网络地址族，

NetworkAddress ：：= CHOICE {Internet IPAddress }

• 32位的IP地址，用网络字节顺序表示

IPAddress ：：= [APPLICATION 0 ] IMPLICIT OCTET STRING （SIZE （4））

• Counter类型值单向增长，达到最大后，回归到0重新开始计数（Agent重启后也会重置为0），主要用于统计接口发送和接收的字节数

Counter ：：= [APPLICATION 1 ] IMPLICIT INTEGER（0 .. 4294967295）

• Gauge类型值可增可减，达到最大值时保持在最大值，如路由器中接口的速率可以用该类型表示

Gauge ：：= [ APPLICATION 2 ]IMPLICIT INTEGER（0 .. 4294967295）

• TimeTicks使用0.01秒为单位进行计时，表示两个时间点之间的时间间隔。要求在描述信息中说明其计时基准。

TimeTicks ：：= [ APPLICATION 3 ] IMPLICIT INTEGER（0 .. 4294967295）

• Opaque将其他ASN.1类型编码后的值两次封装。为了向后兼容，SMIv2中也定义了该类型，不建议使用。

Opaque ：：= [APPLICATION 4 ] IMPLICIT OCTET STRING

SMI v2中相对SMI v1有变化的自定义数据类型有：

• Gauge32 和Gauge实际上是一致的。Gauge32 and Unsigned32 share the same application type tag, therefore their encoding is essentially identical.。

Gauge32 ：：= [APPLICATION 2 ] IMPLICIT INTEGER（0 .. 4294967295）

Unsigned32 ：：= [APPLICATION 2 ] IMPLICIT INTEGER（0 .. 4294967295）

• Counter64是更大范围的Counter，有64为：2^64-1（0 ..18446744073709551615）。只有在计数器不足1小时就归0时，才会在标准MIB模块中使用Counter32。

Counter64 ：：= [ APPLICATION6 ] IMPLICIT INTEGER（0 ..18446744073709551615）

SMI v2中依然保留了IPAddress类型，且含有没有变化。不过不适用于IPv6的128为地址。对Counter32更进一步的说明：计数的值只有在有初始值和有记录变化时，当前的计数值才有明确的含义。

从MIB的视角来看，SMI是直接指导MIB定义的章程，定义了MIB的数据类型和语法，为MIB中的管理对象分配OID空间。

2、MIB

MIB是管理信息的集合，是根据业务的需求或网络管理标准的要求，按照约定的组织规则、定义语法编写的结构化的文本文件。

每个管理信息库（MIB）中的管理对象均需明确描述其所有属性，包括名称、描述和数据类型等信息。通信双方可以通过对象的唯一标识符（OID）识别这些属性的内容。也就是说，MIB是NMS和Agent相互沟通的桥梁，只有Agent实现了该MIB，且NMS认识该MIB，两者才能正确配合实现相应的管理功能。将MIB导入NMS后，NMS才能知道待管理对象所有的细节。如果在代理程序中实现了MIB中定义的管理对象，则表明该代理程序支持该MIB。

一个Agent可以实现多个MIB，每个MIB包含的管理对象可多可少，没有明确的要求。MIB主要由两部分组成，一部分是国际标准化组织定义的标准的管理对象，包括MIB-I（RFC1156）和MIB-II（RFC1213）。所有已接入网络的设备均支持常规和基础的管理对象，这些对象在标准MIB中进行了定义。另一部分是各大厂商、组织或私人自定义的私有MIB，这些私有MIB是厂商根据设备管理的需求，将标准MIB中没有的需要管理的对象进行自定义。节点 enterprises（1.3.6.1.4.1）下定义了私有MIB。

标准MIB中将管理对象分为10个组，也就是MIB树中的10个分支，它们是：System、Interfaces、AT（Address Translation，状态为deprecated，表示下一版本不再使用）、IP、ICMP、TCP、UDP、EGP、Transmission、SNMP，它们的父节点是1.3.6.1.2.1（mib-2）。这10个组中的管理对象时网络管理中最重要的部分之一。

• System组：主要用来描述Agent系统层面信息。包括sysName、sysLocation、sysDescr、sysServices、sysUpTime、sysContact、sysObjectID等。这些OID提供了设备的名称、位置、在线时间等信息，在网络管理中非常重要，在实际环境中这些信息不能得到及时的更新，容易被忽略。

• Interfaces组：该组用于提供网路设备所有的接口信息。包括接口类型、接口描述、接口速率、接口状态等。

• AT组：即地址转换组。该组时间为一个表对象，实现网路地址到物理地址的映射对应关系。遍历该表就能得到IP地址和MAC地址之间的对应关系。

• IP组：定义了IP层相关信息的管理对象。这些对象包括IP数据包、错误信息、地址信息、路由信息和地址映射信息。

• ICMP组：该组定义了26个描述各种ICMP信息收发的标量对象，它们都是Counter类型。这些对象可以很容易地提供报文收发速率和ICMP各类报文类型（请求、响应）的速率。

• TCP组：该组主要包括：用于配置管理的TCP重传策略、重传最长、最短时间的对象，用于性能管理的链接被拒绝的请求数、TCP通信状态间转移情况记录数、重传总数、接收错误总数等对象，可能用于计费管理的收发TCP数据段技术对象，可能用于安全管理的tcpConnTable表对象，通过分析该表记录到的远端IP、端口号、状态等信息，跟踪来自远端可疑的链接。

• UDP组：该组包括可用于性能和计费管理的接收和发送UDP数据包的计数对象、错误报计数对象及端口和IP地址等相关信息的对象。

• EGP（Exterior Gateway Protocol，外部网关协议）组：EGP是用于在自治系统间（邻居间）交换路由信息的协议。该组包括用户失效管理的邻居运行状态等各类信息的egpNeighTable表对象、用户配置管理的本地自治系统的域号、用于性能管理的进入和离开本地实体EGP消息的速率及错误计数对象。

• Transmission组：该组的作用在于根据不同的传输媒介提供相应的管理信息。该组比较特殊，MIB-II中并没有在该分支下定义明确的管理对象，而是当某种传输媒介需要接受管理时才把对应的接口类型加入到改组中。

• SNMP组：该组定义了详细描述SNMP相关的对象。如可用于故障管理的不同类型错误数的统计、可用于配置管理的Trap认证失败是否产生消息的对象、可用于性能管理的发送和接收的各种消息数的统计。

4 OID树

在SNMP中所有的管理对象都以一棵树形结构来组织，管理对象则体现为树中的节点，而这棵树则由国际上的相关标准化组织来维护和管理。通过这种结构化和层次化的组织方式，非常便于对象的管理和扩充。这种管理和扩充体现在节点的分配上。

企业、组织或个人均有权向国际组织申请节点，以成为树状结构中的一个分支。当成功申请到一个节点后，就可以在该分支下自由的分配其他节点，以满足其监控或管理业务的需要。

OID数，也称为MIB数。MIB实际上是由OID组成的ASN.1的模块，在现实中体现为树形结构。Internet中有很多标准的MIB，SNMP中定义了MIB-I、MIB-II等，还包括企业、组织、个人定义的MIB。如下图所示。

在OID树中，只有最顶层的root节点不带有具体的数字编号，可以看作是一个虚拟的节点，其他的节点都是具有在同一层的唯一编号，以作区分。

位于顶层的下一层节点分别为CCITT（也就是目前的ITU-T）负责管理的ccitt（0）、ISO负责的ISO（1）。

在internet节点下有很多的子节点，directory（1）保留，将来可能用于OSI目录服务。mgmt（2）则由IAB负责，用于定义RFC中的标准管理对象，实际上就是MIB-I和MIB-II。experimental（3）也是由IAB负责管理，用于定义internet实验性质的管理对象。Private（4）及下级节点enterprises（1）则由IANA负责分配和管理，在enterprises（1）节点下主要用于分配给各企业或组织使用。

OID树结构如下图13-2所示。

图 13-2

Zabbix中配置SNMP

1 数据类型

RFC 2578中你会发现SNMP中定义的数据类型，相对于这些数据类型，在Zabbix中配置监控项选项时，建议Type ofinformation和Store value选项按下表内容配置。

2 发现OID

在Zabbix中使用SNMP监控设备之前，需要先确定监控项对应的OID值和数据类型。除了标准的MIB和OID，你需要咨询设备厂商，通过厂商提供的文档和MIB库文件，能快速、准确的发现需要监控的OID值。

你可以使用一些图形化的工具如MG-SOFT MIB Browser，将MIB文件导入后，在图形界面中查询设备的信息，如下图13-3所示。

图 13-3

使用图形化工具可以帮助我们快速的浏览、查询和确定监控项的OID类型和值，

也可以使用snmpwalk工具直接从设备中查询。在使用snmpwalk之前，请确保系统已经安装了该软件。如果未安装，可以通过下面的命令进行安装：

# yum install net-snmp-utils

执行snmpwalk查询设备信息。

# snmpwalk -v 2c -c public 10.60.0.19 1.3.6.1.2.1.1

SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, ME380x Software(ME380x-UNIVERSALK9-M), Version 15.4(3)S2, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2015 by Cisco Systems, Inc.

Compiled Wed 28-Jan-15 11:43 by prod_rel_team

SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.1252

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2030697335) 235days, 0:49:33.35

SNMPv2-MIB::sysContact.0 = STRING:

SNMPv2-MIB::sysName.0 = STRING: XZX-3800

SNMPv2-MIB::sysLocation.0 = STRING:

SNMPv2-MIB::sysServices.0 = INTEGER: 6

SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00

也可以输出OID对应的数字路径：

# snmpwalk -v 2c -On -c public 10.60.0.19 1.3.6.1.2.1.1

.1.3.6.1.2.1.1.1.0 = STRING: Cisco IOS Software, ME380x Software(ME380x-UNIVERSALK9-M), Version 15.4(3)S2, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2015 by Cisco Systems, Inc.

Compiled Wed 28-Jan-15 11:43 by prod_rel_team

.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.9.1.1252

.1.3.6.1.2.1.1.3.0 = Timeticks: (2030720756) 235 days, 0:53:27.56

.1.3.6.1.2.1.1.4.0 = STRING:

.1.3.6.1.2.1.1.5.0 = STRING: XZX-3800

.1.3.6.1.2.1.1.6.0 = STRING:

.1.3.6.1.2.1.1.7.0 = INTEGER: 6

.1.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00

当使用不同的参数执行snmpwalk命令时，OID的显示方式在结果中也会有所不同。无论以何种方式呈现，结果始终由三个部分构成：OID、数据类型和返回值。例如设备名称的显示如下：

SNMPv2-MIB::sysName.0 = STRING: XZX-3800

.1.3.6.1.2.1.1.5.0= STRING: XZX-3800

虽然显示的内容是一样的，都是sysName的返回值，但是OID的表达方式不同，在Zabbix中定义items时，在SNMP OID配置参数中一些最常用的OID可以使用OID名称，Zabbix会自动将一些最常用的 SNMP OID转换成数字，例如 SNMPv2-MIB::sysName.0会转换为1.3.6.1.2.1.1.5.0 。但是企业私有MIB的OID只能使用全数字路径。Zabbix中可自动转换的OID如下表13-1所示。

表 13-1

3 配置SNMP

Zabbix中开始配置SNMP前，请先确定Zabbix server已经打开SNMP监控的功能。Zabbix server启动时会在日志文件中列出Zabbixserver的功能列表，如下所示：

911:20160218:103649.120 Starting Zabbix Server. Zabbix 3.0.1 (revision58734).

911:20160218:103649.160 ****** Enabled features ******

911:20160218:103649.160 SNMPmonitoring: YES

911:20160218:103649.160 IPMI monitoring: YES

911:20160218:103649.160 Web monitoring: YES

911:20160218:103649.160 VMware monitoring: YES

911:20160218:103649.160 SMTP authentication: YES

911:20160218:103649.160 Jabber notifications: YES

911:20160218:103649.160 Ez Texting notifications: YES

911:20160218:103649.160 ODBC: YES

911:20160218:103649.160 SSH2 support: YES

911:20160218:103649.160 IPv6 support: YES

911:20160218:103649.160 TLS support: YES

911:20160218:103649.160 ******************************

911:20160218:103649.160 using configuration file:/etc/zabbix/zabbix_server.conf

如果没有发现SNMP monitoring启用的信息，那你需要安装Zabbixserver，如果你使用源码编译安装，需要使用编译配置选项 --with-net-snmp。

Zabbix中进行SNMP监控时只使用UDP协议，并在一次请求中可以查询多个值，不论是常规的SNMPitems、dynamic indexes（动态索引）SNMP items，还是SNMPlow-level discovery rules，这在处理大量的SNMP时可以提供效率。通过设置主机的SNMP Interfaces的选项Use bulkrequests允许或禁用批量查询。如下图13-4所示。

图 13-4

在单个接口中具有相同参数的所有SNMP 监控项会以设置的时间间隔同时查询，对于常规的SNMPitems和dynamic indexes SNMPitems来说pollers会同时处理128个监控项，而SNMP low-leveldiscovery rules会单独进行处理，有两种类型的操作在查询时完成：收集多个指定的对象和遍历OID树。其中收集是指一个GetRequest-PDU可以绑定最多128个变量，遍历是指在SNMP v1中使用GetNextRequest-PDU，SNMP v2或SNMP v3中使用带有max-repetitions字段的GetBulkRequest，可以绑定最多128个变量。

因此，批量处理每个SNMP 监控项有以下好处：

• 常规的SNMP 监控项收集数据的性能得到提升。

• Dynamic indexes（动态索引）SNMP监控项收集数据和遍历数据的性能得到提升。

• SNMP low-level discovery rules遍历数据的性能得到提升。

但是从技术上来讲，并不是所有的设备都能返回每个请求的128个值，有些设备能返回某些响应值，有些设备返回错误代码 tooBig（1）或什么响应都没有。为了确定对设备查询对象的最佳数目，Zabbix使用了一些策略，一开始在查询请求中只查询一个值，如果成功了在查询请求中查询2个值，如果成功了在查询请求中查询3个值，并继续同样的查询对象的数量乘以1.5,进行查询。这些查询数量按照升序排列：1、2、3、4、6、9、13、19、28、42、63、94、128。当设备拒绝返回正确的响应时（如查询42个变量），Zabbix或做两件事：

当前批量查询的item减半，也就是查询21个变量。如果设备正常的返回值，那么在绝大多数情况下应该没有问题，因为我们知道查询28个变量是没有问题的，21要明显小于28。如果将item减半后仍然无法获得正常的返回值，那就需要逐个回退查询的变量数，直到获得正常的返回值。

Zabbix在后续的查询中以上次查询成功的变量数（我们的例子是28）进行查询，并继续增大请求查询变量的数量（每次加1），直到达到上限。例如，假设最大响应的是32个变量。后续请求将按照29、30、31、32和33进行查询，最好一个请求会失败（33个变量），Zabbix将永远不会再发出绑定33个变量的请求。在这个设备上Zabbix的SNMP 查询最多绑定32个变量。

当Zabbix server 或 proxy server接收到一个不正确的SNMP响应时会在日志文件中增加类似下面的内容：

SNMP responsefrom host "gateway" does not contain all of the requested variablebindings

虽然这个信息并没有涵盖所有有问题的情况，但至少有一点就是该主机的SNMP接口中的选项 Use bulk requests应该被禁用。

4 配置常规SNMP 监控项

使用SNMP监控设备时，常规的SNMP 监控项可按下面的步骤配置：

创建主机并在其中添加SNMP接口。可以使用Zabbix中提供的Template SNMP Generic模板自动的添加收集设备基本信息的监控项。

2、 确定监控的OID。

通过MIB Browser或snmpwalk查找并确定需要监控的OID，例如我们要监控交换的某个千兆端口的流量，通过snmpwalk查找 GigabitEthernet0/1接口的index是10101。

# snmpwalk -v 2c -c public 10.60.0.19 IF-MIB::ifDescr

GigabitEthernet0/1可以被重写为IF-MIB::ifDescr.10101的字符串值

IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2

GigabitEthernet0/3 is identified as IF-MIB::ifDescr.10103.

字符串“GigabitEthernet0/4”是IF-MIB中“ifDescr.10104”的值

IF-MIB::ifDescr.10105 = STRING: GigabitEthernet0/5

字符串"IF-MIB::ifDescr.10106"对应的是"GigabitEthernet0/6"

IF-MIB::ifDescr.10107 = STRING: GigabitEthernet0/7

…

获得GigabitEthernet0/1接口出口流量的OID是.1.3.6.1.2.1.2.2.1.16.10101。

# snmpwalk -v 2c -On -c qhdpublic 10.60.0.19IF-MIB::ifOutOctets.10101

.1.3.6.1.2.1.2.2.1.16.10101 =Counter32: 3619738552

3、 创建监控项，使用SNMPv2 agent监控方式，SNMP OID为.1.3.6.1.2.1.2.2.1.16.10101。

5 配置动态索引SNMP监控项

在设备的OID树中，有些管理对象的OID经常会用到index，例如网络接口，使用相同的index关联到网络接口的不同对象上。就像下面snmpwalk输出的一样。

# snmpwalk -v 2c -c public 10.60.0.19 .1.3.6.1.2.1.2.2.1

IF-MIB::ifIndex.1 = INTEGER: 1

IF-MIB::ifIndex.5001 = INTEGER: 5001

IF-MIB::ifIndex.5002 = INTEGER: 5002

IF-MIB::ifIndex.5003 = INTEGER: 5003

IF-MIB::ifIndex.10101 = INTEGER: 10101

IF-MIB::ifIndex.10102 = INTEGER: 10102

...

IF-MIB::ifDescr.1 = STRING: Vlan1

IF-MIB::ifDescr.5001 = STRING: Port-channel1

IF-MIB::ifDescr.5002 = STRING: Port-channel2

IF-MIB::ifDescr.5003 = STRING: Port-channel3

GigabitEthernet0/1可以被重写为IF-MIB::ifDescr.10101的字符串值

IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2

...

IF-MIB::ifType.1 = INTEGER: propVirtual(53)

IF-MIB::ifType.5001 = INTEGER: propVirtual(53)

IF-MIB::ifType.5002 = INTEGER: propVirtual(53)

IF-MIB::ifType.5003 = INTEGER: propVirtual(53)

IF-MIB::ifType.10101 = INTEGER: ethernetCsmacd(6)

IF-MIB::ifType.10102 = INTEGER: ethernetCsmacd(6)

...

IF-MIB::ifMtu.1 = INTEGER: 1500

IF-MIB::ifMtu.5001 = INTEGER: 1500

IF-MIB::ifMtu.5002 = INTEGER: 1500

IF-MIB::ifMtu.5003 = INTEGER: 1500

IF-MIB::ifMtu.10101 = INTEGER: 1500

IF-MIB::ifMtu.10102 = INTEGER: 1500

...

IF-MIB::ifSpeed.1 = Gauge32: 1000000000

IF-MIB::ifSpeed.5001 = Gauge32: 2000000000

IF-MIB::ifSpeed.5002 = Gauge32: 2000000000

IF-MIB::ifSpeed.5003 = Gauge32: 1000000000

IF-MIB::ifSpeed.10101 = Gauge32: 1000000000

IF-MIB::ifSpeed.10102 = Gauge32: 1000000000

...

IF-MIB::ifPhysAddress.1 = STRING: b0:7d:47:be:ea:c0

IF-MIB::ifPhysAddress.5001 = STRING: b0:7d:47:be:ea:c2

IF-MIB::ifPhysAddress.5002 = STRING: b0:7d:47:be:ea:c3

IF-MIB::ifPhysAddress.5003 = STRING: b0:7d:47:be:ea:c4

IF-MIB::ifPhysAddress.10101 = STRING: b0:7d:47:be:ea:c2

IF-MIB::ifPhysAddress.10102 = STRING: b0:7d:47:be:ea:c3

...

IF-MIB::ifAdminStatus.1 = INTEGER: down(2)

IF-MIB::ifAdminStatus.5001 = INTEGER: up(1)

IF-MIB::ifAdminStatus.5002 = INTEGER: up(1)

IF-MIB::ifAdminStatus.5003 = INTEGER: up(1)

IF-MIB::ifAdminStatus.10101 = INTEGER: up(1)

IF-MIB::ifAdminStatus.10102 = INTEGER: up(1)

...

从上面的数据你可以看到每个网络接口都有很多OID，每个OID表示网络接口不同的指标，比如说接口的名称、类型、物理地址等。你会发现不同的OID都是通过相同的index关联起来。例如第一个千兆接口的名称是GigabitEthernet0/1的物理地址是 b0:7d:47:be:ea:c2，状态是up（1），它的index是10101。

为了监控同一网络接口的不同指标，你可以创建不同的监控项，在SNMP OID字段中输入完成的OID。这种方法没有任何问题，但在实际环境中使用index会有些问题，原因就是index会因为软件或硬件的升级发生变化，造成配置的不一致。为了解决这个问题，Zabbix提供了动态索引的方法，即使index值发生变化也不影响对监控项的监控。

使用dynamic indexes SNMP OID的语法如下：

<OID ofdata>["index","<base OID ofindex>","<string to search for>"]

语法中各部分的含义如下：

• OID of data：item中定义的需要查询的OID。

• Index：处理的方法，当前只支持这一种方法。Index是指搜索index并将其追加到OID。

• Base OID of index：将按照该OID查找其对应的index值。

• string to search for：查找时使用该字符串进行匹配，区分大小写。

例如你想监控GigabitEthernet0/1接口的 ifInOctets，按照语法可以定义为：

ifInOctets["index","ifDescr","GigabitEthernet0/1"]

可以理解为在ifDescr中匹配查找GigabitEthernet0/1接口，并或的该接口在ifDescr中index值，然后把收集的index值追加到ifInOctets的后面，从而收集GigabitEthernet0/1接口的ifInOctets值。

当使用dynamic indexes时，Zabbix会接收和缓存索引OID的整个SNMP表，通过缓存可以很快的发现索引的OID，如果以后其他监控项查询相同索引OID时，直接从缓存中查找，不需要在去查询监控主机。

随后在接收监控项的数据时会验证index是否变化，如果index没有发送变化，会继续使用该值查询，如果index发送变化，Zabbix会重建缓存，每个poller会再次遍历索引OID的SNMP表。

在Zabbix中，每个poller进程都有自己的缓存。

6 配置SNMP low-level discovery rules

创建SNMP OIDs 的发现规则时，不像定义文件系统或网络接口的发现规则，不使用snmp.discovery这个Key，使用SNMP agnet监控方式就可以，在SNMPOID字段中定义需要发现的OIDs，格式为 discovery[{#MACRO1}, oi