網絡管理通常包括配置、故障、性能、計費和安全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對象訪問的方法。在此基礎上，根據不同的數據采集對象性質，對數據采集策略進行了探討，提出了面向不同對象類型采用多線程技術進行數據采集的方法。最后，結合實際開發工作，對數據采集模塊（特別是其中的動態信息輪詢線程）做了詳細的介紹。本文提供了一個高效、穩定的數據采集方案，并已在實際的網管系統中得到應用，取得了較好的效果。