基于雙向標準化接口的海洋觀測網運行狀態監控系統研究與開發＊

劉凌峰，竇宇宏，關一，李厚坤，張曉明

（國家海洋技術中心 天津 300112）

海洋觀測網是我國海洋觀測預報業務的基礎。從技術上看，海洋觀測網是包含傳感器、觀測平臺、通信網絡和數據傳輸與管理等諸多要素的復雜系統，其高效穩定地運行是海洋環境預報系統連續獲得高質量基礎數據的關鍵。為了實時掌握重要系統的工作情況，研發它的運行狀態監控系統是保障其穩定運行的常規方法，例如：電力、電信等行業均已研發了針對本領域業務特點的運行狀態監控系統［1－2］，然而目前我國尚無專門針對海洋觀測網的統一監控系統，現有的部分監控系統也只是針對觀測網的某個局部或部分要素進行分散管控，其精度和管理的范圍均不能滿足需求。為此，在海洋公益性行業科研專項的支持下，國家海洋技術中心開始研發海洋觀測網運行狀態監控系統。本研究簡要介紹該系統研究與開發的內容及成果：第1部分分析系統的業務需求；第2部分介紹系統的總體架構；第3部分重點闡述系統的雙向標準接口；第4部分描述原型系統的開發進展及性能測試情況；第5部分對全文進行了總結并展望后續的工作方向。

1 業務需求

運行狀態監控系統的設計與開發是海洋觀測網業務化運行需求驅動的結果，本部分簡要概括這些業務需求。

1.1 海洋觀測網運行狀態精細管控的需求

要保障海洋觀測網的長期穩定業務化運行，首先需要全面掌握海洋觀測網各組成要素的運行狀態。為此，必須要建立一套可以完整收集海洋觀測網全部相關軟、硬件設備運行狀態的信息采集系統，并將這些狀態信息定期匯總至各級監控中心，這樣方可在基礎信息層面上實現觀測網全網運行狀態的精細管控，進而為后續基于這些信息進行故障檢測和關聯分析奠定基礎。

1.2 海洋觀測網運行故障實時檢測的需求

故障的檢測具有“遲滯特性”。例如：在一個配置完備的網絡中，當一個路由器發生故障時，數據包可繞行其他路徑到達目的節點，因而在故障發生初期，用戶很可能察覺不到故障的存在，但是，由于在繞行鏈路有限的帶寬中匯聚了大量異常流量，將很有可能造成網絡的擁塞，并最終導致整個網絡不可用。因此，及早發現故障是維持海洋觀測網穩定運行的必須，這就要求監控系統能夠依據預設的判定規則實時處理獲取到的狀態信息，及時檢測到故障發生，變故障的“事后發現”為故障的“事中發現”，從而縮短故障歷時，盡量減少由于故障所帶來的損失，提高系統可用性。

1.3 海洋觀測網故障原因關聯分析的需求

傳統的監控系統在故障發生時會產生告警的“連鎖效應”，即一處故障發生往往會導致多處告警。例如：當一臺網絡設備發生故障時，設備本身、相應鏈路以及數據傳輸應用軟件均會產生告警，這樣不利于迅速定位和及時處理故障。因此，監控系統必須要具備故障智能診斷和關聯分析功能，能夠從告警的“泛洪”［3］中有效地甄別故障源，判斷故障原因，從而可以為運維人員提供決策依據，盡快排除故障。

1.4 海洋觀測網運行態勢統計評估的需求

實現運行狀態信息的獲取、故障診斷、告警是監控系統的初級功能，在基礎信息積累到一定規模的前提下，對各類監控對象的工作狀態進行統計分析，發現監控對象的運行規律，結合其實際運行環境，對設備的穩定性、適用性進行有效評估，將故障的“事中發現”進一步提升到“事前預測”的水平，這將為提高海洋觀測網日常維護工作的針對性以及后續設備的選型提供科學的輔助決策支持。

2 系統總體架構

基于上述業務需求，海洋觀測網運行狀態監控系統在層次架構設計上劃分為信息獲取層、監控應用層以及信息共享層3個邏輯層級（圖1）。

圖1 海洋觀測網運行狀態監控系統總體架構

2.1 信息獲取層

海洋觀測網全部組成要素都是監控系統的監控對象（網元），通用狀態信息提取軟件基于簡單網絡管理協議（Simple Network Management Protocol，SNMP）提取這些網元的運行狀態信息［4］。對于網絡設備、主機等標準的可網管設備，其本身支持SNMP協議，按照管理信息庫（Management Information Base，MIB）中各管理對象標志符（Object Identifier，OID）內容的說明，通用狀態信息提取軟件通過SNMP協議命令直接獲取這些設備的狀態信息。對于原先不支持SNMP協議的海洋觀測設備（海洋站、浮標等），通過自定義這些設備的MIB，并在與設備相連的上位機部署自主研發的SNMP代理（Agent）軟件實現狀態信息的提取，該代理軟件主要完成兩項功能：其一是與觀測設備通信，獲得其運行狀態信息；其二是響應狀態信息提取軟件發出的標準SNMP請求或自動發出故障信息，將狀態信息輸出。

2.2 監控應用層

完成監控系統各項主體功能，包括：狀態監控、拓撲可視化、故障告警、關聯分析、統計評估以及數據查詢等。狀態監控模塊作為該層的總控模塊定期調用通用狀態信息提取軟件相應模塊獲取各種設備的狀態信息；基于拓撲結構以可視化形式（運轉圖或數據列表）展現這些狀態信息；對于發生故障的設備給出告警提示，并采用智能化診斷技術；對告警的關聯性進行分析，鎖定故障源；信息查詢模塊可查詢各設備運行狀態數據歷史記錄，統計評估模塊對獲取到的狀態信息進行統計生成報表，并可基于故障預測模型對設備的穩定性和適用性進行評估。

2.3 信息共享層

以標準化接口將監控系統所獲取的運行狀態信息向上層系統輸出。基于最新的業務支撐系統設計理念，監控系統只是綜合運維系統的底層系統，綜合運維系統將海洋觀測網運行狀態信息和其他相關系統（如，觀測數據處理系統等）運行狀態信息進行綜合關聯分析，從而可以獲得海洋觀測系統整體運行狀態，這些狀態信息可基于統一的地理信息系統（Geographic Information System，GIS）界面進行可視化展示，并可依據信息技術基礎架構庫（Information Technology Infrastructure Library，ITIL）理論在綜合運維系統中開展運維流程跟蹤。狀態信息通過消息中間件（Message Oriented Middleware）向上層系統推送［5］，從而構成一個應用層通用數據網關，輸出的數據類型包括：觀測網基本屬性信息、實時性能信息以及故障告警信息，數據輸出格式為標準可擴展標記語言（eXtensible Markup Language，XML）格式。

3 雙向標準化接口

雙向標準化接口是海洋觀測網運行狀態監控系統的一個重要技術特色，它在信息獲取和信息共享兩個層面均實現了接口的標準化，使系統的可擴展性大大增強。

3.1 狀態信息獲取接口

狀態信息獲取接口（即監控系統的南向接口）基于簡單網絡管理協議（SNMP），這使得信息獲取層的狀態信息提取軟件可以采用通用的數據采集方法，無需針對海洋觀測設備進行專門的設計，極大地增強了系統的穩定性，并且可以減輕后續再擴充其他觀測設備的工作量。SNMP是由Internet活動委員會IAB制定的最為通用的管理TCP／IP網絡的標準協議。SNMP協議的體系結構由3部分組成：信息管理結構（Structure of Management Information，SMI）、管理信息庫（MIB）以及SNMP協議。其中，信息管理結構（SMI）可以確定管理信息庫（MIB）中被管對象的定義和SNMP報文的描述規則，它是構成整個SNMP的基礎。管理信息庫（MIB）描述了SNMP所用到的管理信息庫結構及其中變量的定義，它以樹形結構來表示。SMI和MIB兩者都遵循OSI的抽象語法表示（ASN.1）規則定義。SNMP協議則規定了管理站和監控對象之間交換管理信息的方法。

海洋觀測網運行狀態監控系統開發過程中設計了6種主要海洋觀測設備的MIB，這是我國海洋觀測系統發展歷史上首次定義觀測設備的MIB。依據通行的MIB編制規則，新定義的海洋觀測設備管理對象標志符位于iso.org.dod.internet.private.enterprise.notc.inspector 子 樹下，進而分為station、bouy、ship、radarstation 4個子樹，分別描述海洋站、浮標、志愿船以及雷達站4類觀測設備對象，其中，bouy子樹又進一步分為bbouy和sbouy兩個子樹，分別描述大型監測浮標和中／小型監測浮標；ship子樹進一步分為fship和nship兩個子樹，分別描述遠洋志愿船和近海志愿船。對于每一類觀測對象，MIB中定義的信息主要包括設備基本屬性信息、設備運行狀態信息和告警信息。基本屬性信息描述設備的編號、區站代碼、所屬關系、經緯度等靜態信息內容。運行狀態信息包括設備的電壓、電流，復位次數等信息以及各種傳感器的測量數據，用以綜合判斷設備及其所搭載的傳感器的工作狀態是否正常。告警信息主要規定由監控對象向管理站發送的記錄故障信息的Trap消息。在狀態信息獲取過程中，管理站中的通用狀態信息提取軟件的管理進程定期請求狀態信息，監控對象固有或自主研發的SNMP代理軟件進程向其提供標準的SNMP應答，實現了標準的基于網元管理的Manager－Agent交互模型，從而使監控應用層軟件可以實時獲取各類監控對象的運行狀態信息。基于SNMP的信息交換層次架構見圖2。

圖2 基于SNMP的信息交換層次架構

3.2 狀態信息共享接口

狀態信息共享接口（即監控系統的北向接口）基于消息中間件技術，消息中間件（Message Oriented Middleware）是用來構建松耦合系統的支持分布式應用系統之間同步／異步收發消息的中間件，該技術可支持實時數據推送與接收，可以有效地屏蔽異構技術細節而向外提供統一服務，適用于大數據量并發訪問。本系統未采用一些應用系統之間共享數據時經常使用的網絡服務（Web Service）接口形式，因為 Web Service的設計思想為被動響應式提取，并不適用于大量并發請求的場景，而海洋觀測網中監控對象（網元）眾多，一些設備的性能指標又很多，如果上層綜合運維系統軟件發出頻繁、大量請求，則提供信息的服務器響應時延就會增加，對服務器的性能壓力巨大。但是如果降低訪問頻率，則又會造成某些狀態信息不能及時反饋到上層系統，影響信息交換的實時性。采用消息中間件技術可以有效地解決上述問題，因為消息隊列中的數據是由信息共享層軟件模塊主動推出，可以有效地保障實時性，特別是故障發生時，可及時將故障告警數據上報上層系統，而消息中間件管理消息隊列并向外系統提供數據共享服務的效率和響應特性也遠高于 Web Service，因此特別適用于海洋觀測網監控信息共享的應用場景，第4部分的測試試驗也證明了這一論點。

在實際系統中，信息共享層的通用數據網關相應模塊（傳輸網絡狀態信息共享模塊和觀測設備狀態信息共享廣模塊）依據主題把數據推送到消息中間件的各個隊列，由消息中間件管理這些數據，并向綜合運維系統或其他系統訂閱該主題的軟件提供。依據業務需求，共建立3個主題的消息隊列，即：基本屬性信息隊列、實時性能信息隊列和故障告警信息隊列。其中，基本屬性信息隊列傳輸監控對象的靜態信息，更新周期一般為24h（發現設備變更時除外）；實時性能信息隊列傳輸監控對象的動態信息，更新周期最低為1min（海洋站觀測設備）；故障告警數據隊列傳輸故障信息，僅在發現故障時實時更新。數據信息采用標準的XML格式封裝，具有較強的通用性，考慮到網絡安全的要求，系統對數據內容進行了加密處理。此外，為了提高系統的靈活性，還開發了數據共享控制模塊，可對發送的信息內容和發送周期進行可視化配置。信息共享層軟件架構如圖3所示。

圖3 信息共享層軟件架構

4 系統原型與性能測試

目前，海洋觀測網運行狀態監控系統原型已完成開發，初步實現了海洋觀測設備和數據傳輸網絡的一體化監控功能，系統與監控對象間的基于SNMP的通用狀態信息提取軟件以及系統與綜合運維系統間的基于消息中間件的通用數據網關也均已研發完成，可以向上層系統提供基本屬性、實時性能和故障告警3類共享信息。

監控系統性能最主要的表征是故障發生時系統反映的及時程度，因此考慮兩個測試指標：平均故障發現時間和平均故障信息輸出時間。平均故障發現時間是指從故障發生到系統產生故障告警間隔時間的均值；而平均故障信息輸出時間是指從故障發生到向消息中間件中輸出告警信息間隔時間的均值。海洋觀測網運行狀態監控系統的設計要求是上述兩個指標均小于60s，平均故障發現時間Ts計算公式如下：

式中：n為故障總數；Tei為第i個故障發生時間；Tfi為該故障在系統中產生告警的時間。

平均故障信息輸出時間To計算公式如下：

式中：Tqi為消息中間件告警信息隊列中該故障的告警信息產生的時間，其他定義同上式。

測試場景如下：監控系統部署在雙至強E7－4807CPU／32G內存的服務器中，在時鐘同步的前提下，設置狀態信息常規采樣周期為30s，以100為遞增步長，向監控系統加入100～1200個監控對象（含觀測設備、網絡設備以及計算機／服務器等），測試其中隨機10%的監控對象發生故障時系統的平均故障發現時間和平均故障信息輸出時間。

需要說明的是，系統的告警按其產生的來源可以分為兩類：一類是由監控對象發現并以Trap消息向通用狀態信息提取軟件主動上報的故障告警，簡稱網元端告警；另一類是由監控應用層軟件通過分析獲取的狀態信息發現故障（如：超過某種預定的閾值等）進而產生的告警，簡稱系統端告警。圖4和圖5分別描繪了網元端告警和系統端告警的平均故障發現時間和平均故障信息輸出時間。

圖4 網元端告警平均故障發現和平均故障信息輸出時間

圖5 系統端告警平均故障發現和平均故障信息輸出時間

從測試結果可以看出，對于網元端告警，由于告警信息是由監控對象主動發出，無需通用狀態信息提取軟件輪詢采集，其對監控系統的壓力較小，雖然隨著監控對象數和故障數的增加，平均故障發現時間Ts和平均故障信息輸出時間To有所上升，但上升幅度并不顯著，在1200個監控對象的場景下，Ts不大于5.02s，To不大于10.23s。

而對于系統端告警，在測試監控對象總數少于500個的情況下，系統的平均故障發現時間Ts在30s左右波動（不大于36.21s），當測試監控對象超過500個時，系統平均故障發現時間持續上升至61.45s（1200個測試節點）。對于平均故障信息輸出時間To，其值亦隨監控對象數量的增加而升高，但與平均故障發現時間Ts的差值始終在2.02～9.11s之間波動，未表現出明顯的上升趨勢。

因此，綜合分析上述測試過程與結果，監控系統的“瓶頸”在于狀態信息的獲取，隨著測試監控對象數量的增加，輪詢提取狀態信息所消耗的時間也在增長。當系統中的監控對象總數小于1000個時，平均故障發現時間Ts與平均故障信息輸出時間To均小于60s（分別為53.15s和57.97s），符合海洋觀測網運行狀態監控系統的設計要求，而當系統中的監控對象總數超過1000個則無法滿足設計要求，此時只有采取層級部署的模式，方可實現狀態信息的同步快速提取。而對于狀態信息特別是告警信息的輸出，由于采用了松耦合的消息中間件機制而表現出較好的承載力，不會造成系統的瓶頸。

5 結論與展望

研發海洋觀測網運行狀態監控系統是一項開創性的工作，在海洋公益性行業科研專項的支持下，這項工作已經產生了一些成果。本研究概括性地介紹了海洋觀測網運行狀態監控系統的業務需求、總體架構和原型系統開發情況，重點介紹了與該系統的3項技術創新點：首先是第一次研發了覆蓋海洋觀測網全部主要組成要素的運行狀態監控系統，改變了以往缺乏監控或只具備分散監控的現狀；第二是定義了海洋觀測設備的MIB，研發了基于SNMP標準協議的海洋觀測設備監控代理（Agent）軟件，使海洋觀測設備具備了標準化監控和管理能力；第三是引入雙向標準化接口的概念，它使監控系統向下集成更多監控對象和向上與更高層系統進行對接的能力都大為增強。最后文章描述并分析了系統的性能測試結果，給出了單系統部署規模上限的參考值，為系統投入實際業務化運行奠定了良好的理論基礎。

在海洋觀測網運行狀態監控系統初步研發完成后，后續的工作方向主要有兩個：一是基于現有的標準化信息共享接口研發上層的綜合運維系統，全面實現海洋觀測系統的綜合保障功能；二是逐步推進海洋觀測設備監控代理軟件與現有觀測設備的硬集成，實現觀測設備的智能化。但是，應該看到，這兩者都不是簡單的工作。綜合運維的核心——ITIL理論，雖然已提出數年，但其在業界真正有效運行的案例還很少，究其原因在于它需要與各應用領域的特點和具體業務需求緊密結合方可顯現強大的生命力，而且其業務化運行也需要各層級用戶的良好配合，否則它只能是一個軟件框架而缺乏實際的應用價值。觀測設備智能化是一個技術趨勢，但受限于設備目前的通信能力，其實現程度還不高，一些設備尚未具備雙向實時通信功能，這在一定程度上阻礙了設備實時管控功能前移的進程。總之，海洋觀測網運行狀態監控系統的研究與開發還處在初期階段，雖然目前已取得了一些成果，但還有很多方面值得進一步探索。

［1］曹軍威，萬宇鑫，涂國煜 .智能電網信息系統體系結構研究［J］.計算機學報，2013（1）：143－167.

［2］趙彥敏，張道有 .電信級客服系統監控的研究［J］.福州大學學報：哲學社會科學版，2004（4）：462－465.

［3］SHARADA K A，HEMANT，PRASHANTH.A model proposed for reducing the false positive alarm rate using the feature of event correlation［J］.International Journal of Advanced Research in Computer Science and Software Engineering，2012（8）：103－108.

［4］PRAS A，DREVERS T，MEENT R V.Comparing the performance of SNMP and web services－based management［J］.IEEE eTNSM－eTransactions on Network and Service Management，2004（2）：72－82.

［5］戴大蒙，李虎雄，陳賽 .綜合性能監控管理模型的設計與實現［J］.計算機應用，2007（1）：252.