面向大規(guī)模集群的自動(dòng)化監(jiān)控系統(tǒng)

楊 杰，曾凌波，彭運(yùn)勇，蔣遷謙，杜 量

(中山大學(xué)國家超級(jí)計(jì)算廣州中心,廣東 廣州 510000)

1 引言

本文介紹的大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)運(yùn)行在一套大規(guī)模集群上，該集群規(guī)模龐大，全系統(tǒng)共有13 000多個(gè)結(jié)點(diǎn)；整個(gè)系統(tǒng)由計(jì)算結(jié)點(diǎn)、ION路由轉(zhuǎn)發(fā)結(jié)點(diǎn)、集群管理結(jié)點(diǎn)、集群登錄結(jié)點(diǎn)、存儲(chǔ)系統(tǒng)和內(nèi)部互連網(wǎng)絡(luò)組成。

超大規(guī)模集群和集群復(fù)雜的內(nèi)部組件使整個(gè)集群故障點(diǎn)多、故障種類繁雜、故障發(fā)生頻率高，從結(jié)點(diǎn)本身硬件、系統(tǒng)關(guān)鍵服務(wù)、存儲(chǔ)系統(tǒng)到內(nèi)部互連網(wǎng)絡(luò)等都可能會(huì)出現(xiàn)一系列故障，同時(shí)大規(guī)模集群上運(yùn)行著數(shù)以千計(jì)的科研任務(wù)，保障集群的穩(wěn)定運(yùn)行就成為了系統(tǒng)管理和系統(tǒng)運(yùn)維的首要工作。

現(xiàn)有很多開源監(jiān)控軟件和解決方案得到了廣泛的運(yùn)用，比如：Zabbix[1]、Nagios[2]和ELK[3]等，雖然這些開源技術(shù)和解決方案配置方便、擴(kuò)展性強(qiáng)，但是它們關(guān)注的重點(diǎn)是某個(gè)監(jiān)控對(duì)象或者某個(gè)監(jiān)控項(xiàng)，前端頁面展示內(nèi)容多且雜，無法根據(jù)集群自身的特點(diǎn)進(jìn)行定制化的展示和報(bào)警，對(duì)集群管理不友好，所以利用開源監(jiān)控技術(shù)和解決方案根據(jù)集群自身特點(diǎn)進(jìn)行集群監(jiān)控的開發(fā)非常有必要?；谏鲜鲈?，迫切需要開發(fā)一套大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)實(shí)時(shí)監(jiān)控集群的運(yùn)行狀態(tài)，并且實(shí)現(xiàn)故障發(fā)現(xiàn)、故障定位、故障消息推送的全自動(dòng)化。

2 大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)架構(gòu)設(shè)計(jì)

大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)共分為4個(gè)層次：數(shù)據(jù)采集層、數(shù)據(jù)存儲(chǔ)層、數(shù)據(jù)處理層和數(shù)據(jù)展示/報(bào)警層[4],整體架構(gòu)圖如圖1所示。

Figure 1 Overall structure of the automated monitoring system圖1 大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)整體架構(gòu)圖

2.1 數(shù)據(jù)采集層

數(shù)據(jù)采集層由Zabbix agent、Filebeat[5]和自有數(shù)據(jù)采集腳本[6]3部分組成：Zabbix agent部署在被監(jiān)控服務(wù)器上，用來采集服務(wù)器的基本數(shù)據(jù)，Zabbix agent將采集到的服務(wù)器的基本數(shù)據(jù)發(fā)送至Zabbix server對(duì)應(yīng)的數(shù)據(jù)庫中存儲(chǔ)；Filebeat監(jiān)控特定目錄或日志文件，它將采集到的日志數(shù)據(jù)轉(zhuǎn)存至Elasticsearch[7]集群中；自有數(shù)據(jù)采集腳本部署在集群管理結(jié)點(diǎn)上，周期性采集系統(tǒng)相關(guān)數(shù)據(jù)，采集到的數(shù)據(jù)存儲(chǔ)在集群自建mariadb gelera集群中。

2.2 數(shù)據(jù)存儲(chǔ)層

底層數(shù)據(jù)采集層將采集到的數(shù)據(jù)進(jìn)行持久化的存儲(chǔ)，對(duì)應(yīng)底層數(shù)據(jù)采集的3個(gè)部分，數(shù)據(jù)存儲(chǔ)也分為3個(gè)部分：Zabbix server集群、Elasticsearch集群和mariadb gelera數(shù)據(jù)。Zabbix agent采集的數(shù)據(jù)存儲(chǔ)至Zabbix server集群對(duì)應(yīng)的雙主數(shù)據(jù)庫集群中，保證了采集數(shù)據(jù)的高可用性；本文根據(jù)開源日志監(jiān)控方案ELK自建Elasticsearch集群，F(xiàn)ilebeat采集的日志數(shù)據(jù)在Elasticsearch集群中持久化存儲(chǔ)；自有數(shù)據(jù)采集腳本采集數(shù)據(jù)并存儲(chǔ)到自建的mariadb gelera集群中，保證數(shù)據(jù)的高可用性。

2.3 數(shù)據(jù)處理層

數(shù)據(jù)處理層的功能是對(duì)底層采集的監(jiān)控?cái)?shù)據(jù)進(jìn)行過濾，本文利用Python的微服務(wù)框架nameko[8]對(duì)底層監(jiān)控?cái)?shù)據(jù)進(jìn)行處理，利用微服務(wù)將大規(guī)模系統(tǒng)中不同組件的監(jiān)控實(shí)現(xiàn)成各組件對(duì)應(yīng)的監(jiān)控微服務(wù)，不僅將大的監(jiān)控任務(wù)分解為多個(gè)小的監(jiān)控服務(wù)，實(shí)現(xiàn)監(jiān)控功能的解耦，而且加快了開發(fā)進(jìn)度，縮短了開發(fā)周期。監(jiān)控微服務(wù)調(diào)用Zabbix server SDK和Elasticsearch SDK對(duì)Zabbix 監(jiān)控?cái)?shù)據(jù)和日志監(jiān)控?cái)?shù)據(jù)進(jìn)行處理，監(jiān)控微服務(wù)連接mariadb gelera集群處理系統(tǒng)自定義數(shù)據(jù)采集腳本采集的數(shù)據(jù)，每個(gè)監(jiān)控微服務(wù)中同時(shí)實(shí)現(xiàn)定時(shí)器函數(shù)和restful API函數(shù)。定時(shí)器函數(shù)用來周期性處理監(jiān)控?cái)?shù)據(jù)，從監(jiān)控?cái)?shù)據(jù)中及時(shí)發(fā)現(xiàn)預(yù)警和報(bào)警信息；restful API函數(shù)將原始監(jiān)控?cái)?shù)據(jù)轉(zhuǎn)換成新的數(shù)據(jù)格式供前端進(jìn)行調(diào)用展示。定時(shí)器函數(shù)流程如圖2所示。

不同組件監(jiān)控微服務(wù)數(shù)據(jù)處理邏輯如下所述：

(1)計(jì)算資源監(jiān)控微服務(wù)數(shù)據(jù)處理邏輯。

集群中各計(jì)算隊(duì)列總的結(jié)點(diǎn)數(shù)是確定的，本文根據(jù)系統(tǒng)運(yùn)營經(jīng)驗(yàn)將各計(jì)算隊(duì)列按照使用率和排隊(duì)作業(yè)數(shù)劃分為不同的報(bào)警級(jí)別：當(dāng)計(jì)算隊(duì)列中出現(xiàn)排隊(duì)作業(yè)或者結(jié)點(diǎn)使用率超過80%時(shí)，計(jì)算資源報(bào)警策略表中將這種情況的報(bào)警設(shè)置為二級(jí)；當(dāng)計(jì)算隊(duì)列排隊(duì)作業(yè)數(shù)超過10個(gè)或者結(jié)點(diǎn)使用率超過90%時(shí)，計(jì)算資源報(bào)警策略表中將這種情況的報(bào)警設(shè)置為一級(jí)。本文根據(jù)運(yùn)營經(jīng)驗(yàn)預(yù)先定義了計(jì)算資源報(bào)警策略表。微服務(wù)獲取計(jì)算隊(duì)列作業(yè)情況和結(jié)點(diǎn)使用情況后自動(dòng)和報(bào)警策略進(jìn)行匹配，一旦達(dá)到報(bào)警條件微服務(wù)會(huì)自動(dòng)調(diào)用報(bào)警接口將計(jì)算隊(duì)列資源使用情況及時(shí)推送出去，供管理員迅速進(jìn)行資源調(diào)整。

(2)關(guān)鍵服務(wù)監(jiān)控微服務(wù)數(shù)據(jù)處理邏輯。

集群中對(duì)關(guān)鍵服務(wù)主要監(jiān)控關(guān)鍵服務(wù)在線情況和關(guān)鍵服務(wù)高可用架構(gòu)整體對(duì)外提供服務(wù)情況。本文結(jié)合每個(gè)關(guān)鍵服務(wù)的在線情況和關(guān)鍵服務(wù)高可用架構(gòu)預(yù)先定義了關(guān)鍵服務(wù)的報(bào)警策略表。例如：主備關(guān)鍵服務(wù)中主關(guān)鍵服務(wù)掉線設(shè)置為一級(jí)故障，備份關(guān)鍵服務(wù)掉線設(shè)置為二級(jí)故障，主備關(guān)鍵服務(wù)同時(shí)掉線設(shè)置為特級(jí)故障。微服務(wù)獲取到關(guān)鍵服務(wù)監(jiān)控原始數(shù)據(jù)后，在報(bào)警策略表中進(jìn)行對(duì)比，自動(dòng)獲取故障類型和故障等級(jí)，調(diào)用相應(yīng)報(bào)警接口，將故障具體信息及時(shí)推送出去。

(3)集群內(nèi)部互連監(jiān)控微服務(wù)數(shù)據(jù)處理邏輯。

集群內(nèi)部互連網(wǎng)絡(luò)監(jiān)控微服務(wù)通過自有數(shù)據(jù)采集腳本周期性采集通信芯片狀態(tài)寄存器信息，根據(jù)通信芯片狀態(tài)寄存器預(yù)定義數(shù)值確定互連網(wǎng)絡(luò)故障(配置故障、拓?fù)涔收稀⑽帐止收虾椭貍鞴收?并根據(jù)故障嚴(yán)重程度確定故障等級(jí)，結(jié)合故障類型、故障等級(jí)預(yù)定義出內(nèi)部互連報(bào)警策略表。

互連監(jiān)控微服務(wù)獲取通信芯片狀態(tài)寄存器信息后和報(bào)警策略表進(jìn)行比對(duì)，如果狀態(tài)寄存器信息異常，則會(huì)直接從報(bào)警策略表中匹配出相應(yīng)的故障類型和故障等級(jí)，并調(diào)用相關(guān)報(bào)警接口將故障詳細(xì)信息推送出去，供管理員及時(shí)進(jìn)行處理。

Figure 2 Flow chart of timer function 圖2 定時(shí)器函數(shù)流程圖

(4)集群關(guān)鍵結(jié)點(diǎn)日常狀態(tài)實(shí)時(shí)監(jiān)控微服務(wù)數(shù)據(jù)處理邏輯。

集群關(guān)鍵結(jié)點(diǎn)分為2大類：管理結(jié)點(diǎn)和登錄結(jié)點(diǎn)。根據(jù)系統(tǒng)中管理結(jié)點(diǎn)高可用架構(gòu)中主備結(jié)點(diǎn)在線情況將管理結(jié)點(diǎn)故障分為一級(jí)故障和二級(jí)故障2類；根據(jù)主備管理結(jié)點(diǎn)負(fù)載情況將管理結(jié)點(diǎn)預(yù)警分為一級(jí)預(yù)警和二級(jí)預(yù)警2類，將登錄結(jié)點(diǎn)宕機(jī)歸為一級(jí)故障，登錄結(jié)點(diǎn)負(fù)載過高歸為一級(jí)預(yù)警。本文結(jié)合管理結(jié)點(diǎn)和登錄結(jié)點(diǎn)故障和預(yù)警的分級(jí)預(yù)定義了關(guān)鍵結(jié)點(diǎn)的報(bào)警策略表。獲取到關(guān)鍵結(jié)點(diǎn)在線情況和負(fù)載情況的監(jiān)控?cái)?shù)據(jù)后，微服務(wù)將監(jiān)控?cái)?shù)據(jù)和報(bào)警策略表進(jìn)行匹配自動(dòng)獲取故障等級(jí)預(yù)警等級(jí)信息，最后調(diào)用報(bào)警推送接口將故障和預(yù)警詳細(xì)信息推送出去及時(shí)報(bào)警。

(5)集群調(diào)度系統(tǒng)日志實(shí)時(shí)監(jiān)控微服務(wù)數(shù)據(jù)處理邏輯。

集群調(diào)度系統(tǒng)需要關(guān)注4個(gè)類型的日志數(shù)量：調(diào)度系統(tǒng)總的日志數(shù)、調(diào)度系統(tǒng)創(chuàng)建作業(yè)條目數(shù)、調(diào)度系統(tǒng)錯(cuò)誤日志數(shù)和調(diào)度系統(tǒng)結(jié)點(diǎn)繁忙日志數(shù)。微服務(wù)從Elasticsearch集群中獲取到調(diào)度系統(tǒng)原始日志后，調(diào)用Elasticsearch SDK[9]對(duì)日志進(jìn)行分類處理，Elasticsearch SDK查詢函數(shù)從日志消息體指定字段中進(jìn)行特殊字段匹配即可獲取到一段時(shí)間內(nèi)指定日志類型的條目數(shù)，同時(shí)將查詢出來的日志進(jìn)行聚合即得到了一段時(shí)間內(nèi)某種類型的日志總條目數(shù)。

(6)集群文件系統(tǒng)實(shí)時(shí)監(jiān)控微服務(wù)數(shù)據(jù)處理邏輯。

本文根據(jù)文件系統(tǒng)架構(gòu)和服務(wù)器主從關(guān)系預(yù)先構(gòu)建集群文件系統(tǒng)報(bào)警策略表[10]，報(bào)警策略表中定義了文件系統(tǒng)故障類型與報(bào)警分級(jí)信息、預(yù)警分級(jí)信息等。例如：主元數(shù)據(jù)服務(wù)器宕機(jī)或者對(duì)象存儲(chǔ)服務(wù)器宕機(jī)對(duì)應(yīng)一級(jí)故障，備份元數(shù)據(jù)服務(wù)器宕機(jī)對(duì)應(yīng)二級(jí)故障，主元數(shù)據(jù)服務(wù)器或者對(duì)象存儲(chǔ)服務(wù)器負(fù)載超過閾值對(duì)應(yīng)一級(jí)預(yù)警，備份元數(shù)據(jù)服務(wù)器負(fù)載超過閾值對(duì)應(yīng)二級(jí)預(yù)警，不同等級(jí)故障和不同等級(jí)預(yù)警對(duì)應(yīng)不同的報(bào)警接口。

文件系統(tǒng)監(jiān)控微服務(wù)連接數(shù)據(jù)庫獲取監(jiān)控原始數(shù)據(jù)，根據(jù)預(yù)先構(gòu)建的報(bào)警策略依次處理原始監(jiān)控?cái)?shù)據(jù)；當(dāng)監(jiān)控微服務(wù)檢測到某臺(tái)服務(wù)器宕機(jī)或者某臺(tái)服務(wù)器負(fù)載超過閾值時(shí)會(huì)與報(bào)警策略表進(jìn)行匹配，通過服務(wù)器主機(jī)名與故障描述自動(dòng)檢測出故障等級(jí)或者預(yù)警等級(jí)與需要調(diào)用的報(bào)警接口；最后通過報(bào)警接口將具體故障信息或者預(yù)警信息及時(shí)推送。

2.4 數(shù)據(jù)展示/報(bào)警層

前端調(diào)用數(shù)據(jù)處理層實(shí)現(xiàn)的restful API接口，獲取到特定監(jiān)控項(xiàng)處理后的監(jiān)控?cái)?shù)據(jù)，前端根據(jù)集群自身的特點(diǎn)渲染前端頁面，保證管理員能夠一目了然地全面了解集群各個(gè)組件的運(yùn)行狀態(tài)，同時(shí)前端也會(huì)展示歷史報(bào)警信息，管理員能夠查詢?nèi)到y(tǒng)歷史報(bào)警信息。

3 大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)實(shí)現(xiàn)的功能

3.1 大規(guī)模集群各組件的實(shí)時(shí)監(jiān)控

(1)集群各計(jì)算隊(duì)列使用率實(shí)時(shí)監(jiān)控：實(shí)時(shí)監(jiān)控集群中各計(jì)算隊(duì)列使用情況，包括隊(duì)列使用率、開放結(jié)點(diǎn)數(shù)、使用結(jié)點(diǎn)數(shù)、空閑結(jié)點(diǎn)數(shù)和排隊(duì)作業(yè)數(shù)。

(2)集群各關(guān)鍵服務(wù)實(shí)時(shí)監(jiān)控：實(shí)現(xiàn)了集群關(guān)鍵服務(wù)狀態(tài)的監(jiān)控，包括資源調(diào)度服務(wù)slurm、集群用戶認(rèn)證服務(wù)openldap、IB子網(wǎng)管理服務(wù)opensm和數(shù)據(jù)庫服務(wù)mysql等服務(wù)狀態(tài)實(shí)時(shí)監(jiān)控。

(3)集群內(nèi)部互連實(shí)時(shí)監(jiān)控：實(shí)現(xiàn)了對(duì)內(nèi)部互連網(wǎng)絡(luò)的實(shí)時(shí)監(jiān)控，包括內(nèi)部高速互連拓?fù)?、在線芯片數(shù)、配置故障、拓?fù)涔收稀⑽帐止收虾椭貍鞴收系膶?shí)時(shí)監(jiān)控。

(4)集群關(guān)鍵結(jié)點(diǎn)日常狀態(tài)實(shí)時(shí)監(jiān)控：集群中管理結(jié)點(diǎn)和登錄結(jié)點(diǎn)狀態(tài)的監(jiān)控，實(shí)時(shí)了解關(guān)鍵結(jié)點(diǎn)的運(yùn)行狀態(tài)。

(5)集群調(diào)度系統(tǒng)日志實(shí)時(shí)監(jiān)控：實(shí)現(xiàn)了對(duì)資源調(diào)度服務(wù)日志的全監(jiān)控，包括資源調(diào)度日志總條目數(shù)、創(chuàng)建作業(yè)條目數(shù)、報(bào)錯(cuò)條目數(shù)和繁忙日志條目數(shù)的實(shí)時(shí)監(jiān)控。

(6)集群文件系統(tǒng)狀態(tài)實(shí)時(shí)監(jiān)控：集群文件系統(tǒng)為共享文件系統(tǒng)，文件系統(tǒng)本身狀態(tài)和性能監(jiān)控至關(guān)重要。文件系統(tǒng)狀態(tài)監(jiān)控實(shí)現(xiàn)了對(duì)文件系統(tǒng)本身的可用性、文件系統(tǒng)讀寫性能、文件系統(tǒng)IOPS以及文件系統(tǒng)后臺(tái)服務(wù)器狀態(tài)、后端存儲(chǔ)盤陣狀態(tài)的監(jiān)控。

圖3展示了大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)前端頁面圖。

Figure 3 Front page of automated monitoring system圖3 自動(dòng)化監(jiān)控系統(tǒng)前端頁面

3.2 報(bào)警信息推送服務(wù)

報(bào)警信息推送服務(wù)實(shí)現(xiàn)了郵件和釘釘消息的推送接口，推送接口用來進(jìn)行報(bào)警信息推送；郵件推送接口利用Python的smtplib庫實(shí)現(xiàn)；釘釘群推送接口調(diào)用釘釘開放平臺(tái)的webhook[11]實(shí)現(xiàn)消息推送。

3.3 故障歷史記錄

報(bào)警日志微服務(wù)提供查詢故障歷史記錄的restful API，前端調(diào)用報(bào)警日志微服務(wù)API接口實(shí)現(xiàn)故障歷史的全展示，包括故障源、故障發(fā)生時(shí)間、故障恢復(fù)時(shí)間和故障類型等信息。

3.4 實(shí)驗(yàn)結(jié)果

大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)部署在天河二號(hào)上，對(duì)結(jié)點(diǎn)狀態(tài)、存儲(chǔ)狀態(tài)、網(wǎng)絡(luò)以及關(guān)鍵服務(wù)等進(jìn)行監(jiān)控，為了在13 000個(gè)結(jié)點(diǎn)規(guī)模下穩(wěn)定運(yùn)行做了大量的實(shí)驗(yàn)，根據(jù)采集數(shù)據(jù)的規(guī)模、底層數(shù)據(jù)庫的性能壓力等，確定出了各監(jiān)控項(xiàng)的最短延遲時(shí)間和系統(tǒng)穩(wěn)定運(yùn)行各監(jiān)控項(xiàng)的平均延遲時(shí)間。

3.4.1 各類故障發(fā)現(xiàn)延時(shí)統(tǒng)計(jì)

故障發(fā)現(xiàn)延遲由數(shù)據(jù)采集的頻率決定，通過大量實(shí)驗(yàn)發(fā)現(xiàn)本系統(tǒng)的延遲主要取決于Zabbix server的性能。本系統(tǒng)中由于Zabbix server服務(wù)器硬件配置和mysql版本性能限制，Zabbix server每秒處理監(jiān)控?cái)?shù)值數(shù)NVPS(New Values Per Second)的上限為30 000。目前在天河二號(hào)13 000結(jié)點(diǎn)上部署了Zabbix agent，平均每個(gè)被監(jiān)控服務(wù)器有30個(gè)監(jiān)控項(xiàng)，總監(jiān)控項(xiàng)數(shù)約為390 000，390 000個(gè)監(jiān)控項(xiàng)監(jiān)控?cái)?shù)據(jù)更新完最短時(shí)間需要13 s左右?？梢缘贸霰鞠到y(tǒng)中Zabbix server數(shù)據(jù)更新頻率最短時(shí)間約為13 s左右。后續(xù)如果想要提高Zabbix server的性能，可以從2個(gè)方面優(yōu)化，一方面對(duì)Zabbix server本身數(shù)據(jù)庫做優(yōu)化，包括mysql版本的升級(jí)、mysql參數(shù)配置優(yōu)化[12]，磁盤優(yōu)化使用SSD固態(tài)硬盤替換傳統(tǒng)機(jī)械硬盤，以提高磁盤IO性能，提高mysql的性能，進(jìn)而提升Zabbix server的性能；另外一方面對(duì)于超大規(guī)模的系統(tǒng)，Zabbix 架構(gòu)優(yōu)化建議采用Zabbix agent、Zabbix proxy和Zabbix server 3層分布式架構(gòu)來分散和緩解Zabbix server的壓力。

Figure 4 Monthly automatic alarm statistics圖4 每月自動(dòng)報(bào)警數(shù)統(tǒng)計(jì)

日志數(shù)據(jù)主要針對(duì)關(guān)鍵結(jié)點(diǎn)進(jìn)行收集，數(shù)據(jù)量不大，所以日志的監(jiān)控基本趨于實(shí)時(shí)[11]。自有數(shù)據(jù)采集腳本的采集頻率默認(rèn)設(shè)置為5 s，根據(jù)大量的實(shí)踐發(fā)現(xiàn)，采集頻率設(shè)置過小，則系統(tǒng)變化不明顯，且增加數(shù)據(jù)存儲(chǔ)壓力；采集頻率設(shè)置過大，則系統(tǒng)變化感知不敏感。綜合考慮自有數(shù)據(jù)采集腳本的頻率設(shè)置為5 s較合適。各類故障最短延時(shí)統(tǒng)計(jì)如表1所示。

在實(shí)際生產(chǎn)部署環(huán)境中，大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)數(shù)據(jù)采集的監(jiān)控項(xiàng)采集頻率設(shè)置為20 s可以滿足生產(chǎn)需求，自有數(shù)據(jù)采集腳本的延時(shí)在5 s左右，日志監(jiān)控基本接近實(shí)時(shí)，整個(gè)監(jiān)控系統(tǒng)故障發(fā)現(xiàn)和定位滿足生產(chǎn)需求，為大規(guī)模集群的穩(wěn)定運(yùn)行提供了保障。

Table 1 Statistics of the minimum delay time of various faults表1 各類故障最短延時(shí)時(shí)間統(tǒng)計(jì)表 s

3.4.2 系統(tǒng)效果

大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)自2019年1月上線以來，共自動(dòng)發(fā)現(xiàn)1 837次預(yù)警和報(bào)警，集群故障的98%都是由于大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)的及時(shí)發(fā)現(xiàn)，實(shí)現(xiàn)了實(shí)時(shí)故障定位和報(bào)警，使故障處理更加有針對(duì)性，整個(gè)集群的正常運(yùn)營時(shí)間比達(dá)到99%，顯著提升了系統(tǒng)運(yùn)營的穩(wěn)定性。大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)上線至今報(bào)警數(shù)量統(tǒng)計(jì)表如圖4所示。

4 結(jié)束語

本文介紹了大規(guī)模集群自動(dòng)化監(jiān)控系統(tǒng)實(shí)現(xiàn)的基本原理和具體功能，該系統(tǒng)實(shí)現(xiàn)集群各組件監(jiān)控的全覆蓋，基本杜絕了誤報(bào)、漏報(bào)的問題，實(shí)時(shí)監(jiān)控業(yè)務(wù)運(yùn)行與系統(tǒng)狀態(tài)，大大縮短了故障發(fā)現(xiàn)和定位的時(shí)間，實(shí)現(xiàn)了秒級(jí)告警，減少了一線運(yùn)維人員的重復(fù)工作量，提升了整體運(yùn)維效率。但是，該套系統(tǒng)目前側(cè)重于故障的發(fā)現(xiàn)和定位，故障發(fā)生后還需要人力介入進(jìn)行恢復(fù)，對(duì)于故障的自愈合考慮得還不夠，下一步的工作會(huì)將故障自愈合作為監(jiān)控的重點(diǎn)，減少人力的介入，基本實(shí)現(xiàn)全自動(dòng)化的運(yùn)維。