面向企業(yè)客戶的大型云網(wǎng)監(jiān)控系統(tǒng)靈敏度優(yōu)化①

吳 舸, 肖 榮, 張明華, 金道臨, 孫毛杰

(上海理想信息產(chǎn)業(yè)(集團)有限公司, 上海 201315)

面向企業(yè)客戶的大型云網(wǎng)監(jiān)控系統(tǒng)在多云/多網(wǎng)環(huán)境下為用戶提供包括云網(wǎng)監(jiān)控、應用性能監(jiān)控等監(jiān)控服務, 為企業(yè)提供一體化的監(jiān)控運維管理, 系統(tǒng)的靈敏度對于提升客戶感知、云網(wǎng)資源運維效率、客戶黏度有著重要的影響, 監(jiān)控系統(tǒng)靈敏度依賴于數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)存儲、數(shù)據(jù)展現(xiàn)等多個環(huán)節(jié), 云網(wǎng)監(jiān)控系統(tǒng)通過融合開源成熟解決方案與自研關鍵技術相結合的方式, 提升系統(tǒng)的整體監(jiān)控靈敏度.

云網(wǎng)監(jiān)控系統(tǒng)主要目標是針對客戶的網(wǎng)絡、設備、應用等進行監(jiān)控, 為客戶提供云網(wǎng)及應用的整體運行狀況, 及時發(fā)現(xiàn)異常并告警, 確保客戶的基礎云網(wǎng)資源及在此基礎上構建的應用及業(yè)務的穩(wěn)定運行. 云網(wǎng)監(jiān)控系統(tǒng)的核心是發(fā)現(xiàn)異常、定位異常、解決異常, 這些操作均需要在一定的時間內完成, 以符合云網(wǎng)監(jiān)控系統(tǒng)對企業(yè)承諾的SLA 服務標準, 為了將異常發(fā)生時間與運維人員知曉異常的時間之間的間隔T(簡稱異常可視化時間)控制在SLA 服務標準內, 系統(tǒng)需要盡可能縮短T,T越小則云網(wǎng)監(jiān)控系統(tǒng)靈敏度越高, 使得系統(tǒng)能夠在異常發(fā)生后越快發(fā)現(xiàn)異常, 并引導運維人員人工介入處理異常, 提升企業(yè)的云網(wǎng)整體運維效率. 原有的云網(wǎng)監(jiān)控系統(tǒng)的采集頻率為60 s、300 s、600 s 等; 監(jiān)控頁面的刷新頻率為30 s, 異常可視化時間(T)在90–630 s 的范圍內. 通過對系統(tǒng)靈敏度的優(yōu)化, 模擬測試結果表明異常可視化時間(T)最短可以達到15 s.

1 影響云網(wǎng)監(jiān)控系統(tǒng)靈敏度的因素分析

1.1 云網(wǎng)監(jiān)控系統(tǒng)系統(tǒng)邏輯架構

根據(jù)云網(wǎng)監(jiān)控系統(tǒng)的邏輯架構[1], 如圖1 所示, 異常在被監(jiān)控的資源層發(fā)生后, 異常數(shù)據(jù)會在數(shù)據(jù)采集層、數(shù)據(jù)處理層、消息隊列、數(shù)據(jù)緩存、數(shù)據(jù)存儲層、業(yè)務及展示層中傳輸: 資源層異常通過主動上報或主動采集匯聚到數(shù)據(jù)采集層; 數(shù)據(jù)采集層對異常進行初步處理后提交到消息隊列; 數(shù)據(jù)處理層從消息隊列中獲取將異常轉換為告警后持久化到數(shù)據(jù)存儲層;業(yè)務及展示層從數(shù)據(jù)存儲層中讀取告警信息展示并提醒運營維護人員進行處理. 提升云網(wǎng)監(jiān)控系統(tǒng)的靈敏度, 就需要縮短異常在各層級中流轉、處理的時間.

圖1 云網(wǎng)監(jiān)控系統(tǒng)邏輯架構

1.2 云網(wǎng)監(jiān)控系統(tǒng)靈敏度影響因素

針對系統(tǒng)各層級的功能, 表1 分析了各層級中影響異常流轉、處理時間的主要因素. 以下為影響云網(wǎng)監(jiān)控系統(tǒng)靈敏度的應用層方面的主要因素, 消息隊列、數(shù)據(jù)存儲、數(shù)據(jù)緩存方面的影響因素, 可以通過成熟開源軟件的性能調優(yōu)方式解決, 其他因素需要通過云網(wǎng)監(jiān)控系統(tǒng)本身的優(yōu)化進行解決.

表1 影響監(jiān)控系統(tǒng)靈敏度的因素分析

2 云網(wǎng)監(jiān)控系統(tǒng)靈敏度優(yōu)化

2.1 網(wǎng)絡層面的優(yōu)化分析

云網(wǎng)監(jiān)控系統(tǒng)使用SD-WAN 服務, 通過廣域網(wǎng)動態(tài)路徑控制選擇延遲最小的鏈路, 優(yōu)化采集機與被監(jiān)控設備之間的網(wǎng)絡鏈接, 縮短資源層異常到達采集機的時間.

2.2 硬件層面的優(yōu)化分析

云網(wǎng)監(jiān)控系統(tǒng)采用私有云構建, 在兼顧成本的前提下, 盡量購買硬件性能好的資源, 分布式數(shù)據(jù)庫盡量安裝在物理機上, 以提升系統(tǒng)的基礎性能, 縮短異常數(shù)據(jù)在計算、IO、傳輸?shù)拳h(huán)節(jié)的時間.

2.3 中間件、數(shù)據(jù)存儲、數(shù)據(jù)緩存的優(yōu)化分析

云網(wǎng)監(jiān)控系統(tǒng)基于開源的ActiveMQ、MySQL、HBase、Redis 構建了消息隊列、數(shù)據(jù)存儲、數(shù)據(jù)緩存.系統(tǒng)集成ActiveMQ 時, 數(shù)據(jù)采集側(生產(chǎn)者)采用異步發(fā)送及DeliveryMode=NON_PERSISTENT 的模式提升數(shù)據(jù)寫入速度; 數(shù)據(jù)處理側(消費者)采用Prefetch、事件驅動、多消費者協(xié)同等方式提升數(shù)據(jù)消費速度[2].系統(tǒng)采用MySQL 存儲相對靜態(tài)的基礎配置數(shù)據(jù), 采用HBase 存儲大數(shù)據(jù)量的動態(tài)采集數(shù)據(jù), 在HBase 的存儲模型設計時將設備ID、服務ID、時間戳等通過翻轉處理組合為RowKey, 分散存儲動態(tài)告警、性能數(shù)據(jù), 提升數(shù)據(jù)持久化、查詢的速度[3]. 系統(tǒng)采用Redis緩存相對靜態(tài)的配置數(shù)據(jù)及最近的動態(tài)采集數(shù)據(jù), 提升數(shù)據(jù)匯聚、處理、查詢的速度[4]. 通過以上優(yōu)化措施, 系統(tǒng)可以達到近1400 條/s 的數(shù)據(jù)處理、存儲速度, 更快的處理速度可以使系統(tǒng)在更短的時間內發(fā)現(xiàn)異常.

2.4 數(shù)據(jù)采集層的優(yōu)化分析

云網(wǎng)監(jiān)控系統(tǒng)的數(shù)據(jù)采集層主要通過被動接收或主動采集的方式獲取被采集資源的性能、告警、狀態(tài)數(shù)據(jù), 數(shù)據(jù)采集層影響監(jiān)控系統(tǒng)靈敏度的兩個主要因素是: 采集頻率和采集耗時, 采集頻率越高、采集耗時越小, 則發(fā)現(xiàn)異常的時間越短.

(1)采集頻率優(yōu)化

在云網(wǎng)監(jiān)控系統(tǒng)中, 數(shù)據(jù)采集通過每個采集任務進行, 提升采集系統(tǒng)的頻率需要縮短采集間隔, 會大量增加采集任務的數(shù)量. 采集任務的數(shù)量取決于被監(jiān)控資源數(shù)量、采集指標數(shù)量、采集間隔. 采集任務數(shù)量=被監(jiān)控資源數(shù)量×采集指標數(shù)量/采集間隔. 采集指標的個數(shù)取決于客戶要求監(jiān)控的服務內容(CPU、內存、端口流量、系統(tǒng)狀態(tài)、風扇等).

在實踐過程中發(fā)現(xiàn)頻率的提升會帶來嚴重的性能問題(圖2、圖3 分別為30 s、10 s 間隔單臺采集機CPU 使用率圖, 可以明顯看到10 s 間隔下, CPU 使用率頻繁觸及100%): 盡管系統(tǒng)通過多采集機分散采集任務, 且通過并行線程方式處理采集任務, 但大量的采集任務(如表2 所示)會競爭采集機有限的線程、網(wǎng)絡資源, 未被及時處理的采集任務處于排隊狀態(tài), 滯留的采集任務不斷堆積導致系統(tǒng)無法正常進行采集.

圖2 單臺采集機CPU(2 000 臺設備, 20 個OID, 30 s 采集間隔)

圖3 單臺采集機CPU(2 000 臺設備, 20 個OID, 10 s 采集間隔)

表2 采集任務數(shù)量舉例

為了解決這一問題, 系統(tǒng)設計了一種多級可變頻率網(wǎng)絡監(jiān)控數(shù)據(jù)采集方法及裝置[5](如圖4 所示): 不是所有設備均需要同時提升采集頻率, 只需要針對出現(xiàn)異常的設備提升采集頻率即可, 該方法根據(jù)最新采集數(shù)據(jù)與歷史數(shù)據(jù)的離散度識別異常設備, 賦予系統(tǒng)在設備采集數(shù)據(jù)離散程度加大或已發(fā)生告警時臨時提高數(shù)據(jù)采集頻率、異常消除或數(shù)據(jù)離散程度降低后降低采集頻率的自適應能力, 可以有效地提高數(shù)據(jù)采集效率、資源利用效率及系統(tǒng)的整體監(jiān)控靈敏度.

圖4 一種多級可變頻率網(wǎng)絡監(jiān)控數(shù)據(jù)采集方法及裝置

該設計包括定時調度模塊、并行采集模塊、并行數(shù)據(jù)處理模塊、變頻邊界計算模塊和變頻控制模塊.其工作原理如下:

1) 定時調度模塊從數(shù)據(jù)庫中加載采集任務信息為每種采集任務生成高、中、低3 種頻率的定時調度任務, 每種定時調度任務定時為設備采集頻率表中對應頻率的設備生成采集任務, 加入采集任務隊列.

2) 并行采集模塊從采集任務隊列獲取并執(zhí)行采集任務, 將采集數(shù)據(jù)加入采集數(shù)據(jù)隊列.

3) 并行數(shù)據(jù)處理模塊處理采集數(shù)據(jù)隊列中的采集數(shù)據(jù), 存儲到數(shù)據(jù)庫, 同時將最新的采集數(shù)據(jù)、設備可達狀態(tài)傳遞給變頻控制模塊.

4) 變頻控制模塊判斷設備可達性, 如果設備不可達, 則調整該設備的對應采集任務頻率為低頻率, 如果設備可達, 則變頻控制模塊獲取變頻邊界計算模塊計算的變頻邊界.

5) 變頻邊界計算模塊從數(shù)據(jù)庫中加載一段時間內的歷史采集數(shù)據(jù)并緩存, 計算變頻邊界: 算出緩存的歷史數(shù)據(jù)的算術平均值和標準差, 設置設備的變頻邊界為算術平均值K倍標準差、告警閾值上限、告警閾值下限.

6) 變頻控制模塊根據(jù)最新采集數(shù)據(jù)與變頻邊界的關系動態(tài)調整采集頻率: 若最新采集數(shù)據(jù)小于等于告警閾值下限或大于等于告警閾值上限, 則調整設備對應的采集任務頻率為高頻率; 若最新采集數(shù)據(jù)大于算術平均值K倍標準差且小于算術平均值K倍標準差,則調整設備對應的采集任務頻率為低頻率; 若最新采集數(shù)據(jù)大于告警閾值下限且小于等于算術平均值K倍標準差或者最新采集數(shù)據(jù)大于等于算術平均值加K倍標準差且小于告警閾值上限, 則調整設備對應的采集任務頻率為中頻率, 其中1≤K≤3.

7) 如果設備的采集任務頻率與原頻率不同, 則更新設備任務采集頻率表.

采用自適應調整采集頻率的方法, 例如原固定頻率為60 s 的采集, 通過高中低頻率(10 s、30 s、60 s)的變頻控制, 發(fā)現(xiàn)異常的時間可以為10 s (最好情況)、30 s、40 s、60 s (最壞情況), 同時降低了正常設備的采集頻率, 有效降低了資源消耗, 提升了系統(tǒng)的容量和穩(wěn)定性.

(2)采集超時時間優(yōu)化

影響數(shù)據(jù)采集時間的還有一個隱性的因素: 采集超時時間, 在被采集設備可達的情況下, 采集超時時間對系統(tǒng)是無影響的, 當被采集設備由于某種原因不可達時, 采集任務會一直等到采集超時時間結束才會釋放資源, 當大量的被采集設備出現(xiàn)不可達的情況時, 會導致有限的網(wǎng)絡、內存資源被長時間占用, 采集任務不斷堆積導致系統(tǒng)無法正常采集. 為了消除這一影響,系統(tǒng)設計了一種基于超時因子的大規(guī)模網(wǎng)絡數(shù)據(jù)采集方法及裝置[6], 如圖5 所示.

圖5 一種基于超時因子的大規(guī)模網(wǎng)絡數(shù)據(jù)采集方法及裝置

該方法及裝置包括定時調度模塊、并行數(shù)據(jù)采集模塊、并行數(shù)據(jù)處理模塊、采集超時自適應模塊、設備采集耗時表、設備采集超時表. 該裝置的定時調度模塊、并行數(shù)據(jù)采集模塊、并行數(shù)據(jù)處理模塊功能與變頻設計中的對應模塊功能相同, 其主要工作原理如下:

1) 定時調度模塊為超時因子不等于0 的設備生成采集任務, 并加入采集任務隊列.

2) 并行數(shù)據(jù)采集模塊從采集任務隊列中獲取并執(zhí)行采集任務, 根據(jù)超時因子設置采集超時時間=超時因子×默認采集超時時間.

3) 判斷采集任務是否成功執(zhí)行, 若成功執(zhí)行則將采集的數(shù)據(jù)加入數(shù)據(jù)隊列, 若失敗則并行數(shù)據(jù)采集模塊更新超時設備信息表中該設備的超時因子=原超時因子?固定值, 超時因子最小值為0.

4) 超時因子控制模塊以固定頻率探測超時因子為0 的設備, 如果設備恢復上線, 則調整該設備的超時因子為最大值.

通過引入超時因子及延時反饋機制, 賦予云網(wǎng)監(jiān)控系統(tǒng)面對大規(guī)模數(shù)據(jù)采集的自適應能力, 能夠在有效的時間范圍內完成大量異構監(jiān)控對象的數(shù)據(jù)采集,有效提高數(shù)據(jù)采集效率及監(jiān)控系統(tǒng)的容錯能力, 提高云網(wǎng)監(jiān)控服務的異常發(fā)現(xiàn)效率.

2.5 數(shù)據(jù)處理層的優(yōu)化分析

云網(wǎng)監(jiān)控系統(tǒng)的數(shù)據(jù)處理層負責處理消息隊列中的采集數(shù)據(jù)并持久化到數(shù)據(jù)存儲中. 通常情況下, 對于單值類的數(shù)據(jù)告警一般采用預設閾值的方式, 當采集數(shù)據(jù)超出閾值一定次數(shù)后, 系統(tǒng)發(fā)出告警信息. 實踐中采集數(shù)據(jù)一般有一個逐漸趨于閾值并超越閾值的過程.在數(shù)據(jù)處理層, 系統(tǒng)在原有閾值告警的基礎上, 增加了隨采集數(shù)據(jù)動態(tài)變化的預告警機制[7]: 計算緩存的歷史數(shù)據(jù)的算術平均值和標準差, 動態(tài)預告警閾值為算術平均值±兩倍標準差, 預告警規(guī)則如下:

圖6 中的閾值告警控制模塊即為原有的通過閾值判斷告警的模塊, 系統(tǒng)增加了動態(tài)調整邊界的預告警控制模塊后, 賦予了系統(tǒng)在設備采集數(shù)據(jù)離散程度加大時產(chǎn)生預告警, 使得運維工程師可以提前進行設備的異常排查和干預, 避免了傳統(tǒng)的必須超過固定閾值才能告警的方式, 既能夠有效預防異常的發(fā)生, 又可以提高系統(tǒng)的整體監(jiān)控靈敏度.

圖6 增加了預告警的云網(wǎng)監(jiān)控系統(tǒng)

對于告警靈敏度要求較高的企業(yè)可以通過調整標準差倍數(shù)告警邊界及超過告警邊界次數(shù)進行靈活的預告警設置, 表格3 為常用標準差倍數(shù)及連續(xù)3 次越過告警界限情況下的預告警的概率值. 預告警的概率值=(1?標準正態(tài)分布概率)超過告警邊界次數(shù), 如表3.

表3 預告警的概率

2.6 業(yè)務展現(xiàn)層的優(yōu)化分析

云網(wǎng)監(jiān)控系統(tǒng)的告警信息進入數(shù)據(jù)存儲后, 一方面可以通過郵件、短信、語音等方式通知運維人員,另一個重要的途徑是通過業(yè)務及展現(xiàn)層通知給監(jiān)控人員, 為了實現(xiàn)實時的通知, 云網(wǎng)監(jiān)控系統(tǒng)采用WebSocket長鏈接代替客戶端定時刷新[8], WebSocket 的服務端在消息隊列注冊一個消費者, 數(shù)據(jù)處理層遇到高優(yōu)先級的告警時, 會將告警信息在持久化前放入消息隊列中,WebSocket 的服務端接收到告警信息后, 立即將告警信息推送給客戶端, 在客戶端頁面的顯著位置進行告警提示(同時伴有聲音提示). 相比客戶端定時刷新機制, 基于WebSocket 的消息機制能夠在更短的時間內將告警信息推送給監(jiān)控人員, 盡快引導運維人員介入異常處理, 提升了系統(tǒng)的監(jiān)控靈敏度.

3 結論

基于以上分析及優(yōu)化, 影響云網(wǎng)監(jiān)控系統(tǒng)靈敏度的因素中, 除了網(wǎng)絡、硬件層面的因素外, 其他因素系統(tǒng)均采取了對應的設計方案進行了優(yōu)化, 其中系統(tǒng)可控的且對系統(tǒng)監(jiān)控靈敏度影響最大的兩個因素: 采集頻率、采集超時時間, 采用了自適應的動態(tài)應對方案,相對于未優(yōu)化前整個系統(tǒng)的靈敏度有了極大的提高(最優(yōu)情況下可以達到秒級). 靈敏度的提升往往伴隨著成本的提升, 目前企業(yè)的運維需求基本是在分鐘或小時級別的異常處理標準, 監(jiān)控系統(tǒng)的靈敏度需要在客戶需求與成本投入之間找到一個結合點, 達到雙贏的結果.