網絡故障監控系統設計探討

程 敏

（常州市廣播電視大學 信息工程系，常州 213001）

0 引言

針對網絡建設中和維護中面臨的種種挑戰和問題，電信運營商急需找到一個合理的方案，通過這個方案在復雜的網絡結構中找出當前網絡可能存在的問題，輔助網絡結構和網絡設備的優化。本論文提出的網絡監控系統能夠幫助運營商實時監控網絡的性能，輔助診斷網絡故障發生的原因，幫助提高IP網絡的QoS能力[1,2]。這在當前越來越多的企業與網絡運營商之間簽訂服務等級協議(SLA)的大背景下，本論文的網絡監控系統的現實意義無疑是重要的。

1 監控系統系統設計

1.1 軟、硬件環境

本系統開發、測試過程中所需要的軟硬件環境是不太一樣的，開發階段主要涉及到軟件本身的功能開發和系統測試；測試階段以模擬測試場景，構造測試例為主。軟件開發階段，其代碼與測試工作主要集中在單一或者若干臺PC之間；測試階段所需的部分測試環境實驗室環境是無法模擬出來的，因此需要依賴現網的檢驗。

測試階段所需的軟、硬件環境如表1所示。

1.2 系統體系結構

本系統是一個融合了軟件、數據庫和測試儀的綜合監控系統。

從系統結構可以看出，從功能上分類，監控系統的分為三塊[3]。第一，監控控制模塊；第二，數據采集和數據庫模塊；第三，數據結果分析模塊。監控控制模塊是本系統的核心部分，也是最復雜的部分。按照功能的細分，該模塊又分為中央控制模塊和局端控制模塊兩個字模塊。其中中央控制模塊控制各個節點發送指定的測試流量，收集測試結果反饋給數據操作模塊，此模塊同時提供網管功能，負責各個局端控制程序的管理工作。局端控制模塊根據監控中的作用不同，可能是一個軟件控制器，也可能是一臺網絡測試儀；該模塊的作用是主動發送監控流量到網絡中或者被動監控測試流量進行環回處理。

表1 測試階段需要的軟硬件環境

數據采集和數據庫模塊是本系統的數據操作模塊，該模塊通過數據收集服務提取中央控制模塊傳送的測量結果和監聽狀態數據，將這些數據寫入到數據庫的指定庫表中。

結果分析模塊是本系統監控結果展現和MIB信息上傳部分，該模塊實時提取數據庫中的結果，使用圖表或者文字的形式，顯示當前各個節點的監控結果，同時定義告警類別，上傳告警結果。

1.3 系統網絡架構

通常一個典型的IP網的網絡拓撲是由大量的設備如路器、交換機、HUB、防火墻以及主機等構成的。其中，外圍的部分為接入層部分，各種網絡設備通過不同的接入技術訪問網絡；中間層為匯聚層，該層的網絡設備負責將來自于接入層的各種服務請求；內部為核心層，核心層主要是網絡的骨干部分，核心網是整個網絡的總樞紐，通過它將各個子網連接起來。監控系統所需要監控的網絡節點.可能來自于核心網、匯聚網、接入網中的任何一個節點。無論這些節點所使用的接入方式和拓撲結構如何，只要其支持IP技術，監控節點就可以部署在其中。

監控系統的中央監控子系統部署于核心網的中心，其他的監控采集子系統部署在匯聚網或者接入網節點上；各個監控節點與節點之間，可以互發監控數據進行監控；中央監控子系統與各個監控節點之間也可進行監控數據的傳輸。這種分布式的系統結構，與網絡的分布式特點相切合。這種架構中，客戶端與服務器端的概念不再明顯。

1.4 數據庫設計

本系統設計之初，比較了Oracle，SqlServer和MySql三種關系型數據庫。本系統中的數據存儲主要以測量數據和告警信息為主，同時數據庫的交互只需要通過一個數據收集服務程序即可完成，因此最終決定采用MySql數據庫。該數據庫可跨Windows和Unix兩大平臺，并且是免費的，在百萬條數據的處理上速度仍然較快。雖然監控系統每一秒鐘都會產生多條新的測量、告警數據，但是通過數據表項的分類，程序內部定期處理無效的數據，同時對數據進行匯總整理，該數據庫系統仍然能夠滿足成千上萬的監控節點的實時測量數據的存儲上的性能要求。

本系統的數據庫表主要有監控節點實時數據表，實時告警信息表，故障知識庫表，監控數據日表，監控數據月表，監控數據年表，告警信息日表，告警信息月表，告警信息年表等。這里簡要列出最核心的兩張表的數據字典，其他的相關數據庫表和存儲過程、索引、視圖等信息不在論文中表述。

2 監控系統詳細設計分析

2.1 局端監控子系統

局端監控子系統是部署于網絡節點上用來監聽和生成測試數據并能生成測量結果的程序軟件。該子系統提供兩種工作模式：主動模式和受控模式。主動模式下，操作人員可直接操作該軟件，配置測試流量參數和監聽參數；受控模式下，該軟件只接受中央監控子系統的操作和管理。這種將監聽和流量發送、測量功能放在局端監控子系統中實現的做法，可以大大減少中央監控子系統的資源開銷，同時測試流量的構建上實現了任意性；這個設計與一直提的“瘦客戶機，瘦服務器"理念是吻合的。

首先，該子系統的開發上采用多層結構進行實現。這樣做的好處是將業務與展現進行了分離，各子模塊的獨立性增強，對開發人員的分工上更加明確，易于軟件項目的管理和系統的集成。

對于流量的發送和結果提取功能的流程圖來看，將流量的發送和處理定義為兩個類，通過各自的類方法實現對流量的發送、接收和處理。

通過對windows的進程和線程的調度機制和執行效率研究發現，進程可以完整的獲得資源，而線程只能獲得進程下的少量資源(例如寄存器或者棧等)。進程相對易于管理和控制，線程的系統開銷相對進程小很多，兩者均具備并發性。利用這一特點，為突破發包速率上的限制，提升監控系統發包效率，測試流的發送采用進程方式進行發包，這樣對系統資源的占用可盡量較多；而測試流的統計和分析上，使用線程來實現即可達到效率上的匹配。這樣做的好處是最大限度利用當前系統的資源，同時保證系統的運行穩定、可靠。同時，通過代碼調整、空間效率和編譯的優化，對瓶頸有很大的緩解。

另外，在線程的管理上，啟動一個監測線程的線程，定期查看各個流統計、分析線程的狀態，若發現當前線程狀態已經停止或者異常，重啟動該線程，這樣保證每一測試流對應的測量線程均能持續運行。這一機制類似于Unix系統下的進程管理機制。

對環回時延的處理機制上，當監控系統接收到監控數據時，立即打上接收時間戳，這樣做的好處是避免時延的處理上引入了上層協議響應的時延。

2.2 中央監控子系統

中央監控子系統是部署于整個監控網絡中央的監控管理系統，中央監控系統最主要的功能是能夠管理所有局端監控子系統。這些管理功能包括控制各個監控節點程序的啟動、停止，控制監控節點程序的測試流量和監聽流量的配置、啟動、停止、測量等。

在局端監控子系統的設計描述中提出的為“瘦服務器”模式，因此中央監控子系統并不直接參與測試流量的調度、監聽和測量分析操作，這一模式也是部署中央監控子系統本身的要求。在本文的設計中，中央監控子系統既能部署于一臺服務器上，也能部署于一臺高性能PC上，使得整個監控方案的實現成本大大降低。從技術實現角度考慮，無論是高性能PC還是服務器，其硬件架構都是馮.諾依曼體系結構，這種結構不利于網絡流量的調度，因此流量的發送和測量功能不能在中央監控子系統中實現。

在中央監控子系統與局端監控子系統在測試控制上的交互過程中，本子系統中通過SNMP協議進行管理各個局端監控子系統的功能，一個操作為get-request操作，另外一個為trap操作，通過這兩個動作可實時掌握每個節點程序的狀態。

2.3 結果采集與分析子系統

結果采集與分析子系統是整個監控系統的數據處理和展現部分。該子系統周期性的提取數據庫中的測量數據，根據設定的告警閥值，返回告警結果，同時可將告警結果上發到網管系統或者指定的業務平臺中。最后，該子系統提供統計報表的自動生成功能和對數據庫的自動清理和備份功能。

綜合來說，結果采集與分析子系統的功能定義如下：提供實時和按照指定周期進行結果數據的提取和展示功能；提供告警提示和告警結果分析功能；提供定期監控結果統計報表自動生成功能；提供SNMP接口，實現與網管系統或業務平臺的整合功能；提供數據庫的監測和自動維護功能。

在上述功能中，數據庫的維護主要通過存儲過程的定期運行來實現；與其他系統的對接上，通過SNMP協議的查詢功能即可實現數據的上傳。本部分實現相對復雜的部分就是故障分析功能，這一功能要求系統能夠根據測量結果準確的給出故障的原因。在實際的故障分析中，通常很難通過一個現象或者結果精確的給出故障原因，這就要求故障原因與故障現象的對應關系上能夠模糊匹配，同時故障庫又具備學習功能，能夠不斷的完善故障分析邏輯。

3 結束語

在網絡性能監控過程中，可以將本系統的局端監控子系統任意放置在接入網或者匯聚網的各個節點上，安裝過程簡單無需做任何配置。另外，通過結果采集與分析子系統中開放的接口和數據庫表，通過SNMP協議將告警結果信息庫直接傳遞到網管系統。一方面可充分利用網管系統在短信通知和故障定義上的完備性，另一方面實現了與已有系統的整合。對于網絡故障監控工作發展具有一定幫助。

[1] 張強, 陳琳, 龔正虎, 等. 分布式網絡故障管理系統實現技術研究[J]. 計算機工程與科學, 2006, 28(5).

[2] 李宏建, 徐明, 李洋. 無線Mesh網絡入侵檢測關鍵技術研究[J]. 計算機工程與科學, 2009, 31(7).

[3] 楊巋, 杜澤鰲, 李兵. 結合網絡測試儀器分析判斷網絡故障[J]. 微電子學與計算機, 2006, 23(z1)

[4] 李學峰, 李彩清, 王文杰. 網絡故障監測中多智能Agent模型的研究與實現[J]. 微電子學與計算機, 2007, 24(1).