面向企業(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)控、應(yīng)用性能監(jiān)控等監(jiān)控服務(wù), 為企業(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)通過融合開源成熟解決方案與自研關(guān)鍵技術(shù)相結(jié)合的方式, 提升系統(tǒng)的整體監(jiān)控靈敏度.

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

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

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

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

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

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

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

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

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

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

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

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

云網(wǎng)監(jiān)控系統(tǒng)采用私有云構(gòu)建, 在兼顧成本的前提下, 盡量購買硬件性能好的資源, 分布式數(shù)據(jù)庫盡量安裝在物理機上, 以提升系統(tǒng)的基礎(chǔ)性能, 縮短異常數(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 構(gòu)建了消息隊列、數(shù)據(jù)存儲、數(shù)據(jù)緩存.系統(tǒng)集成ActiveMQ 時, 數(shù)據(jù)采集側(cè)(生產(chǎn)者)采用異步發(fā)送及DeliveryMode=NON_PERSISTENT 的模式提升數(shù)據(jù)寫入速度; 數(shù)據(jù)處理側(cè)(消費者)采用Prefetch、事件驅(qū)動、多消費者協(xié)同等方式提升數(shù)據(jù)消費速度[2].系統(tǒng)采用MySQL 存儲相對靜態(tài)的基礎(chǔ)配置數(shù)據(jù), 采用HBase 存儲大數(shù)據(jù)量的動態(tài)采集數(shù)據(jù), 在HBase 的存儲模型設(shè)計時將設(shè)備ID、服務(wù)ID、時間戳等通過翻轉(zhuǎn)處理組合為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)可以達(dá)到近1400 條/s 的數(shù)據(jù)處理、存儲速度, 更快的處理速度可以使系統(tǒng)在更短的時間內(nèi)發(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ù)采集通過每個采集任務(wù)進(jìn)行, 提升采集系統(tǒng)的頻率需要縮短采集間隔, 會大量增加采集任務(wù)的數(shù)量. 采集任務(wù)的數(shù)量取決于被監(jiān)控資源數(shù)量、采集指標(biāo)數(shù)量、采集間隔. 采集任務(wù)數(shù)量=被監(jiān)控資源數(shù)量×采集指標(biāo)數(shù)量/采集間隔. 采集指標(biāo)的個數(shù)取決于客戶要求監(jiān)控的服務(wù)內(nèi)容(CPU、內(nèi)存、端口流量、系統(tǒng)狀態(tài)、風(fēng)扇等).

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

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

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

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

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

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

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

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

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

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

4) 變頻控制模塊判斷設(shè)備可達(dá)性, 如果設(shè)備不可達(dá), 則調(diào)整該設(shè)備的對應(yīng)采集任務(wù)頻率為低頻率, 如果設(shè)備可達(dá), 則變頻控制模塊獲取變頻邊界計算模塊計算的變頻邊界.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表3 預(yù)告警的概率

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

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

3 結(jié)論

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