面向有限帶寬環境下的分布式系統監控技術

蔣鳴遠 粟勇 梁璟

中國電子科技集團公司第二十九研究所 四川 成都 610036

引言

分布式系統如今廣泛存在于如金融、制造、醫療、交通等不同行業，這些系統一般都有多個獨立的子系統集成所得，子系統使用的開發技術和使用方式往往存在很大的差異，甚至于它們需要運行在異構的網絡節點之上[1]。系統監控是分布式系統配置和管理的基礎設施，管理員需要掌握系統中的可用資源，感知系統部署情況。良好的系統監控技術是對分布式系統有效管理的前提條件[2]。

本文針對某特定網絡有限帶寬環境，實現了一個對所屬分布式系統的系統監控原型軟件，補足了用戶在使用過程中無法掌握系統整體狀態的能力欠缺。本文先分析了目標環境，再結合監控需求設計出系統監控的架構，然后闡述了本文分布式系統監控的幾個關鍵技術，最后按照前文設計思路實現了面向有限帶寬環境分布式系統監控技術的原型軟件，并給出了模擬環境下監控的界面截圖。

1 目標環境

本文面向某專用網絡環境，網絡節點之間的傳輸有效帶寬限制為2Mbps，而在實際使用中，監控數據傳輸所能占用的網絡帶寬只會更少；并且節點之間的數據傳輸因底層限制不能隨意使用端口和傳輸協議，各節點監控數據的匯集上報只能通過特定的數據傳輸服務完成；同時，監控需求不僅僅是單個席位的硬件使用狀態，還包括對網絡節點間的通信鏈路、系統內的數據存儲服務等進行監控，因此要求系統監控具有良好的可擴展性。

業界常用的開源監控軟件有Nagios、Ganglia：Nagios[3]是一種企業級的開源監控系統，具有監控服務的運行狀態和網絡信息等的能力，其功能側重于監控服務的可用性，但是Nagios對監控需求的可擴展性和使用的便捷性不能滿足本項目的需求。

Ganglia是一套跨平臺的、可擴展的分布式開源監控系統，它基于分層設計，具有可視化界面顯示，適合于對集群系統的自動化監控。但是Ganglia沒有報警機制，出現問題不能夠及時報警。

所以上述兩款開源軟件都不適用于目標環境，本項目在此目標環境中提出了一種分布式系統監控技術：針對特定有限帶寬環境，在每個網絡節點內部署一個相同的節點監控中心，采用微服務架構采集監控數據，實現了對所屬系統中的節點狀態、通信鏈路、數據存儲進行有效監控；在網絡節點之間監控中心通過專用的數據傳輸服務對匯總的監控數據進行策略性上報，實現了滿足有限帶寬條件下的跨廣域網的分布式系統監控。

2 方案設計

本項目從廣域網整體出發，將接入系統的每個單位看作一個網絡節點，在節點內部部署一個節點監控中心負責匯總采集的監控數據，并負責跨廣域專用網絡的監視數據及控制指令的傳輸。系統內各個節點監控中心在專用網絡環境下的連接關系如圖1所示：

圖1 專網中節點監控中心連接關系圖

每個節點監控中心都留有接收下級節點上報監控數據的接口，同時還有自己的監控數據庫，用于存儲收集的監控數據并供給用戶交互界面展示。每個節點監控中心在匯集了本節點及下級節點的監控數據后，精簡監控數據并調用特定的專網數據傳輸服務向上級節點的監控中心進行點對點的數據傳輸，監控數據就能匯集于上級節點的監控中心；同理上級節點監控中心在收到用戶監控指令后也通過專網數據傳輸服務向下級監控中心傳達指令，至此也就實現了上級節點對下級節點的監視與控制。

微服務架構在復雜度控制、服務并發性、系統容錯性以及擴展能力方面都具有一定的優勢[4]。單個網絡節點內部的系統監控采用微服務架構，部署的節點監控中心包含代理管理服務、數據接收服務、日志服務、Web實時通信服務、數據上報服務，分別負責管理與各席位上的監控代理的服務雙向調用連接及指令轉達、將收到的監控數據存入本地監控數據庫、維護管理系統日志、在Web上主動向用戶推送數據、將監控數據選擇性跨專網上報至上級；各席位上的監控代理提供接收監控指令的SOA接口，負責執行下達的監控指令、向監控中心進行上線注冊、將采集席位狀態并上傳至監控中心，節點內邏輯架構設計如圖2所示。

圖2 節點內部邏輯架構圖

3 關鍵技術

3.1 針對有限帶寬環境的監控數據上報策略

本項目所在系統日常運行時，在單個網絡節點內會有大量監控數據產生，而目標環境會有多個節點同時接入，監控數據量將會成倍增長，由于網絡帶寬資源有限，目標環境不足以支撐下級節點將所有的監控數據上報給上級節點，本項目將采用以下策略在保證上級節點能夠有效監控下級節點的同時盡量減少網絡帶寬的負擔：

3.1.1 監控數據分級。將采集到的監控數據根據緊急程度進行分級，優先保障情況緊急的監控信息如性能告警、資源負荷緊張等第一時間從下級節點上傳至上級監控中心，而緊急程度不高的監控數據如顯示席位運行狀態正常的數據將批量壓縮后再跨專網進行匯總。

3.1.2 監控數據壓縮。在沒有緊急程度高的監控數據出現的情況下，將相鄰幾個采集周期所收集的監控數據取均值上報以描述一個較長時間內的系統運行狀態，減少了上報的監控數據量，延長了上報時間間隔，從而減少網絡帶寬占用量。

3.1.3 監控數據按需上報。平時下級節點的監控中心僅會定時上報匯總處理后的各項監控摘要信息，若上級節點用戶需要查看某項監控數據的全集，則會向下級節點發出請求，下級節點在收到請求后才會按需將全集數據上報給上級節點的監控中心并推送顯示。

3.2 面向服務的監控數據匯集技術

在節點內，監控中心提供監控數據上報的服務化接口，使得監控代理與節點監控中心呈松耦合關系，便于節點內監控代理部署數量的擴展，并且監控代理無論運行在何種平臺，只要符合接口規范的定義，均能夠將席位狀態發送至節點監控中心；同樣，節點監控中心也可以快速獲取異構網絡環境下數據共享服務以及通信服務的狀態。

3.3 基于ICE的分布式日志管理技術

ICE是由ZeroC公司推出的一種新的高性能的對象中間件平臺。本文將系統內產生的日志數據從廣泛的監控數據中剝離出來單獨維護管理，建立了一套基于ICE的分布式日志管理方法。

首先，本文擬定了可擴展日志內容文本規則，日志數據必須滿足此規則才能被系統管理起來；其次，監控代理會定期掃描本地的日志數據并為它們建立日志索引，并將索引上傳至節點監控中心，而原始的日志數據依舊存儲在各席位上，從而分攤了存儲壓力，實現了日志數據的分布式存儲，日志索引的集中式管理；然后，節點監控中心僅將匯總的日志索引進行跨專網上報，減少了在日常運行過程中，日志數據傳輸對帶寬的占用；最后系統將日志索引呈現給用戶，并提供一定的統計數據，用戶也可以通過索引反向檢索查看原始日志數據。

3.4 基于ICE的web實時通信技術

在日常運行過程中，系統會產生告警、通知等消息需要推送至Web前端的用戶，由于http協議的原因，若想要獲取這些消息，傳統的做法是采用Ajax輪詢的方法，這樣無疑會帶來不必要的網絡流量，本文提出了一種基于ICE的Web實時通信方案，能夠將系統產生的消息主動推送至Web前端。在節點監控中間建立一個Web實時通信服務，通過ICE與Web前端用戶建立雙向連接，并負責維護一張用戶的消息訂閱列表，當這個Web實時通信服務受到某條消息時，就會去查看消息訂閱列表并將消息通過之前建立的雙線連接分發給訂閱了的Web前端用戶，從而實現了消息從后臺服務主動推送至Web前端的方法。

4 實現與效果

4.1 實現

根據前文所述設計及項目需求，本文按如下圖3所示的物理結構圖搭建了原型軟件。每一個節點內都有獨立的Web應用為用戶提供操作界面，后端采用ThinkPHP框架搭建Web應用，快速獲取前端請求的監控數據庫中的數據并推送給前端；Web應用的前端通過Ajax訪問異步訪問后端獲取監控數據，也可以通過ICE與監控中心直接建立雙向連接并訂閱相應主題直接從監控中心獲取監控數據，Web前端融入了Bootstrap的UI風格，通過豐富的ECharts圖形控件展示獲取到的各類監控數據。

圖3 物理架構圖

監控代理是基于Electron開發的跨平臺桌面應用，使用Node.js原生模塊收集所在的席位運行狀態數據并進行本地化展示。監控代理通過ICE向監控中心注冊并建立雙向連接，并通過此連接上傳監控數據，接受并執行上級下達的監控指令。監控代理平時以托盤形式運行于后臺，也可以通過托盤調出本地化界面進行查看。

4.2 效果

本文模擬了由節點A和B組成的專用網絡環境，在節點A內部署了節點監控中心，兩個節點的若干席位上部署了監控代理，同時將兩節點之間的傳輸帶寬限制為2Mbps。本文將所實現的原型系統運行至模擬環境中，實現對數據存儲服務、通信鏈路的監控，最后通過web前端對系統狀態進行實時的展示。

節點B中某一席位的監控代理運行界面如圖4所示，從節點A中遠程查看節點B所有席位的運行狀態界面如圖5所示。此外節點A的Web前端還提供了對數據共享服務和節點間通信鏈路的狀態的監控能力，具體包括了包括數據共享服務各個節點的存儲負荷、余量，各個節點之間的通信鏈路通連狀態、吞吐量等。

圖4 監控代理原型示意圖

圖5 節點內狀態監視原型示意圖