少走冤枉路！带你走过SNMP的那些坑

SNMP（Simple Network Management Protocol）即简单网络管理协议，是在网络与系统监控领域中，最常使用的一种数据采集技术。尽管这个协议非常简单，但在大规模IT环境监测中，还是经常会碰到各种坑，因此优云开源了一套友好的SNMPAPI，并通过本文简单介绍这套API中的一些特点，希望帮助各位运维同仁提前规避一些问题。

特点[0].提供解析各种数据类型的SnmpValue类

在SNMP中，有各种各样的数据类型，光表达数值类型的，就有Gauge32、Integer32、Counter32、Counter64等数十种，甚至有一种称为OctetString的万能数据类型，可以代表常见的ASCII字符串、IP地址、MAC地址、端口列表等等含义。很多老手都经常由于错误的转换OctetString，导致采用到的数据没有意义，更别提新手面对这些数据类型，会有多糊涂了。

本API所返回的采集结果，均使用SnmpValue类，对各种原数据类型进行了统一封装，提供了更友好的使用接口，如下所示：

特点[1].提供避免死循环的Walk操作

Walk操作是指不断使用Get-Next请求去逐个采集设备的一些相邻OID，以获取一批相关信息的操作。

从SNMP规范上来说，设备上的OID排列应该是升序并且不会重复，但林子大了，什么鸟都有！一些OID出现逆增长甚至干脆重复的设备也会出现。因此程序员写出会死循环的Walk操作也很常见。

而本API提供的三个特性可以避免这种情况出现：

·兼容OID逆增长

·自动合并重复OID，保留同一个OID采集到的最后一次值

·允许设置单次Walk最大结果数，避免死循环、

特点[2].提供Table数据类型与WalkTable操作

Walk操作很多时候都是在采集设备的表格类信息，如端口列表、路由表、转发表等。

但在使用普通的Walk操作时，返回的只是一个一维数组，每个元素只对应到表格中的一个单元格。因此为了从中完整的提取出一个路由记录、端口信息，往往要需要不停的遍历数组，根据OID与Index提取元素。同时由于设备的表格也可能在Walk过程中发生了改变，有时也会碰到缺失某些单元格的情况，无法组织起有效数据的情况。

因此，如果使用传统的方法来提取信息，一般会写出如下复杂的代码：

而使用本API中的walkTable与Table数据类型，可以大大的简化相关操作，如下所示：

特点[3].合并pdu发出多个requestoid，大幅度提高性能

在进行SNMP采集时，往往会出现大量的SNMP请求，这是因为进行Walk时，需要产生大量的Get-Next操作。

举例来说，采集一个拥有48个端口的设备端口表，则需要的请求数为：

​> 48（端口数）* 22（每端口字段数）=1056次请求

而本API，在设计时考虑到了减少请求的需求，会尝试将一行多个字段的OID请求合并到一次请求中，以大幅度减少需要发出的数据包数量。

同样采集一个48个端口，其需要的请求数为：

> 48（端口数）* 1（合并后的请求数）=48次请求

可见减少了96%的请求。

特点[4].控制SNMP采集频率，避免被管设备CPU飙升

最后，由于一些网络设备较为陈旧，其采用的CPU性能较弱，以及厂商的SNMP Agent存在性能缺陷，因此在实际的SNMP采集操作时，常经常会出现CPU利用率持续在100%，更有甚者开始出现网络数据丢包，影响正常数据转发功能的情况。

本API默认对访问频繁进行了50ms的最低频率控制，并且此参数也可按被采集的设备进行单独调整，因此可有效避免SNMP采集对设备的不利影响。

除上述特点外，此套开源类库，还提供了诸如“OID联合与父子判断”、“异常简化”、“V3参数简化”、“Table缺失容错”等优秀特性，欢迎大家使用与进一步补充功能。

作者介绍  蒋君伟 任职优云软件

·IT运维资深实践者；

·研发成果：网络管理、系统管理、CMDB、ITSM等产品，并成功建设了多个全国性的网络运维管理项目；

·实践项目：开源社区技术推广、实现SNMP协议栈、研究去中心化大规模集群技术。