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缺失容錯”等優秀特性，歡迎大家使用與進一步補充功能。
福利在這里哦：本文涉及代碼均已開源在：https://github.com/uyun/common-snmp，同時優云也會陸續開源一些運維工具項目，如監控采集代理等。優云是一家致力于通過技術幫助企業提升運維效益的公司。
作者介紹 蔣君偉 任職優云軟件（秉承devops的理念，從監控、到應用體驗，到自動化持續交付，全棧運維解決方案服務商）
原創文章，作者：uyunops，如若轉載，請注明出處：http://www.www58058.com/18261
有硬貨的軟廣我們也支持