基於SNMP數據採集模塊的設計和實現
作者: ecsun 鏈接：http://papa.iteye.com/blog/226506 發表時間: 2008年08月11日
聲明：本文系JavaEye網站發佈的原創博客文章，未經作者書面許可，嚴禁任何網站轉載本文，否則必將追究法律責任！
網絡管理通常包括配置、故障、性能、計費和安全5個方面的管理功能。網管系統通過數據採集模塊採集各個被管設備中的對象，經處理後爲各個網管應用程序所用。網絡管理各個功能的實現，都是建立在對各種管理信息採集的基礎之上，數據採集是實現網絡管理的前提和基礎。面對大量需要採集的管理信息，構建一個穩定高效的數據採集模塊對於實施可靠的網絡管理具有舉足輕重的作用。目前，數據採集主要有如下幾種方式：基於簡單網絡管理協議(SNMP)、基於網絡探針 (Probe)、基於網絡流(Net-flow)。由於SNMP協議已成爲事實上的網絡管理標準，受到衆多網絡設備廠商的支持，且有標準函數接口支持，實現簡單，因此現在普遍採用SNMP進行網絡管理系統開發。本文針對基於SNMP數據採集方式中存在的效率問題，提出了面向數據類型的採集策略，同時採用多線程技術實現對不同被管設備的訪問，大大提高了數據採集的效率，並且減少了冗餘數據的重複採集。
1 對象訪問方法
MIB中的每個對象都有一個惟一的對象標識符(OID)，該標識符由所在MIB樹中的位置決定。通過SNMP獲取被管對象的信息，實際上並不是訪問一個MIB對象，而是訪問對象的一個特定實例。由於對象類型有標量對象、表對象(行對象和列對象)之分，因此對於他們實例的訪問存在差別。
1.1 標量對象
標量對象與其實例是一一對應的，即一個標量對象只有一個對象實例。爲了統一對象實例的標識，同時區分對象和對象實例，SNMP規定不屬於表的標量對象的實例標識符由他的對象標識符加上0組成。對於標量對象實例的訪問，可以通過調用SNMP++類庫(HP公司提供的SNMP開發包)中的 Snmp：：get()函數來實現。
1.2 列對象
在MIB定義中，表對象和行對象的訪問狀態是“無法訪問”。對於列對象來說，他的實例是一組用列對象標識符(ColumnOID)和行索引值 (RowIndexValue)聯合標識的實例。列對象標識符，是用來惟一標識列對象的OID。行索引值由一個或多個列對象對應實例的值組成。
列對象的每一個實例可以看作是表中指定列對應位置的元素。表中元素的位置可以用行座標和列座標表示，相應地，列對象的行座標可以用 RowIndexValue表示，列座標用ColumnOID表示。同一列元素有相同Colum-nOID，同一行元素有相同 RowIndexValue。表中元素可以通過如下公式進行標識：Oid=ColumnOID+RowIndex-Value。SNMP定義了訪問列對象實例的方法：順序訪問和隨機訪問。
(1) 順序訪問
MIB對象的標識符是按字典順序排列的，對於他們的實例也是按字典順序進行排列。利用這種特性，可以通過調用SNMP++類庫中的Snmp：： get_next()函數遍歷獲得一列或一個表甚至是整個MIB的結構。這種方法適合在未知被管設備MIB結構的前提下搜索和訪問對象。
(2) 隨機訪問
由於列對象實例由ColumnOID和RowIndexValue共同標識，所以先要根據被指定爲行索引的列對象獲取他(們)的實例值確定特定實例的RowIndexValue，在此基礎上聯合已知ColumnOID組成特定實例的完整Oid，據此利用Snmp：：get()獲取相應的值。這裏要指出一點，行索引本身也是一個或多個列對象，所以先要分別遍歷各個列對象的所有實例，然後根據特定實例所在列的位置確定出RowIndexValue (由同一位置的列對象實例值按指定順序組成)。由於同一行元素具有相同RowIndexValue，只需遍歷(利用Snmp：：get_next()函數)某一列對象獲取實例的完整Oid(利用Vb：：get_old()函數)，根據(Oid-ColumnOID)即可確定RowIndexOid。可見，隨機訪問列對象某個實例的過程其實是順序訪問列對象和標量對象訪問的結合。
2 數據採集策略
管理站從被管設備中採集數據有兩種方式：主動訪問被管對象和被動接收告警信息。主動訪問被管對象是指管理進程(管理站中)通過SNMP協議發起對被管對象的請求，被管設備中的代理進程則響應該請求。被動接收告警信息是指管理進程監聽陷阱端口(通常爲UDP162端口)，接收來自代理的告警信息。代理進程會在預定義事件發生時向管理進程發出Trap報文。
對於主動訪問來說，根據訪問對象的性質，可以分爲靜態信息和動態信息。對於靜態信息來說，一經配置基本上保持不變，因此沒必要在每一次採集過程中都對他進行輪詢操作，只有當他發生變化時進行必要的訪問以保證信息的有效。對於動態信息來說，他是隨着設備的運行情況做出相應的調整，以實時地反映設備的狀態或是性能信息。爲了能跟蹤設備性能參數的變化情況或是及時反映設備的運行狀態，有必要對被管對象進行輪詢操作，但是這裏就存在一個採集頻率的問題。
數據採集頻率的確定，是一個與網絡帶寬權衡的過程。採集頻率過低，佔用網絡資源相對較少，但是數據的更新週期相對較大，不能反映參數的真實變化情況；採集頻率過高，數據更新自然較快，但是在採集週期內所佔用的網絡資源就會很大，增加網絡設備的負擔，甚至有可能會影響到正常的網絡通信。因此在確定數據採集的頻率時，必須根據實際的網絡帶寬資源進行考慮，同時還要考慮被管設備中被管對象的數量。
在動態信息的訪問過程中，還存在另一個問題。如果按照串行操作，依次訪問所有設備的被管對象，由於對象數目衆多，將會佔用很長的處理時間(甚至超出既定的採集週期，這個問題也是確定採集頻率需要考慮的)，導致訪問工作不能正常進行。爲了保證管理進程能夠在採集週期內完成對所有被管對象的訪問，這裏採用多線程技術來完成對象的訪問工作。對於同一被管設備，採用獨立的子線程進行訪問，這樣一來既可以保證在一定週期內完成對所有被管對象的訪問，也使得各個子線程保持相對的獨立性，互不干擾。
在對象訪問過程中，爲減少管理進程和代理進程之間報文交換的次數，可以將不同對象綁定到同一個協議數據單元(PDU)的變量列表中，或是採用SNMPv2中新增加的GetBulkRequest-PDU。文獻[5]和[6]中還討論了有效獲取MIB對象的方法。
3 數據採集模塊的設計和實現
針對不同的數據採集方式，採用不同線程來完成數據採集工作。
3.1 告警信息接收線程
對於告警信息的被動接收，管理進程單獨開啓一個線程用來專門監聽陷阱端口，接收並處理所有來自網管代理的告警(Trap)消息。在網絡管理過程中，無論在性能管理、故障管理、還是安全管理等功能域，告警功能都是很重要的。這裏主要利用SNMP Trap機制實現實時告警功能。
3.2 靜態信息獲取線程
對於靜態信息的採集，管理進程同樣爲他單獨開啓一個線程來進行靜態信息的收集。由於靜態信息不隨設備的運行而變化(一般不進行手工設置，靜態信息保持不變)，就沒有必要重複地訪問這類信息。本線程就是依據這一點，在對所有靜態對象訪問一次之後，將採集到的管理信息入庫存儲。應用程序對這類數據的操作只需訪問本地數據庫即可。如此就減少了對非實時變化信息的訪問，同時也減少了冗餘信息的存儲。要指出一點，靜態信息的改變一般是由於手工配置引起的，因此需要跟蹤配置操作對相應的信息做出及時的更新。
3.3 動態信息輪詢線程
對於動態信息的採集，管理進程也開啓一個主線程用來專門負責動態信息的輪詢工作。爲了保證數據的實時性，就需要按照一定的時問間隔定時訪問被管對象以獲取最新的數據。對有關數據進行統計和分析，就能掌握動態信息的變化趨勢，爲故障管理、性能管理、計費管理等網絡管理功能提供必要的數據支持。
爲了使訪問工作在規定的時間間隔內完成，避免串行執行帶來的長週期問題，採用多個輪詢子線程各自負責屬於自己的管理對象子集。所有輪詢子線程的工作結束後，這一次的訪問工作便完成，即輪詢主線程進入等待，直到下一次輪詢點的到來或是接收到終止輪詢主線程的命令。
4 結語
數據採集模塊是網管系統對整個網絡實時有效、可靠管理的前提和基礎。本文首先分析了利用SNMP++開發包實現MIB對象訪問的方法。在此基礎上，根據不同的數據採集對象性質，對數據採集策略進行了探討，提出了面向不同對象類型採用多線程技術進行數據採集的方法。最後，結合實際開發工作，對數據採集模塊(特別是其中的動態信息輪詢線程)做了詳細的介紹。本文提供了一個高效、穩定的數據採集方案，並已在實際的網管系統中得到應用，取得了較好的效果。
已有 0 人發表留言，猛擊->>這裏<<-參與討論
JavaEye推薦
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章