[導(dǎo)讀]一、背景一套監(jiān)控系統(tǒng)的檢測(cè)和告警是密不可分的，檢測(cè)用來(lái)發(fā)現(xiàn)異常，告警用來(lái)將問(wèn)題信息發(fā)送給相應(yīng)的人。vivo監(jiān)控系統(tǒng)1.0時(shí)代各個(gè)監(jiān)控系統(tǒng)分別維護(hù)一套計(jì)算、存儲(chǔ)、檢測(cè)、告警收斂邏輯，這種架構(gòu)下對(duì)底層數(shù)據(jù)融合非常不利，也就無(wú)法實(shí)現(xiàn)監(jiān)控系統(tǒng)更廣泛場(chǎng)景的應(yīng)用，所以需要進(jìn)行整體規(guī)劃，重新對(duì)...
一、背景
一套監(jiān)控系統(tǒng)的檢測(cè)和告警是密不可分的，檢測(cè)用來(lái)發(fā)現(xiàn)異常，告警用來(lái)將問(wèn)題信息發(fā)送給相應(yīng)的人。vivo監(jiān)控系統(tǒng)1.0時(shí)代各個(gè)監(jiān)控系統(tǒng)分別維護(hù)一套計(jì)算、存儲(chǔ)、檢測(cè)、告警收斂邏輯，這種架構(gòu)下對(duì)底層數(shù)據(jù)融合非常不利，也就無(wú)法實(shí)現(xiàn)監(jiān)控系統(tǒng)更廣泛場(chǎng)景的應(yīng)用，所以需要進(jìn)行整體規(guī)劃，重新對(duì)整個(gè)監(jiān)控系統(tǒng)架構(gòu)進(jìn)行調(diào)整，在這樣的背景下統(tǒng)一監(jiān)控的目標(biāo)被確立。
以前監(jiān)控被劃分為基礎(chǔ)監(jiān)控、通用監(jiān)控、調(diào)用鏈、日志監(jiān)控、撥測(cè)監(jiān)控等幾大系統(tǒng)，統(tǒng)一監(jiān)控的目標(biāo)是將各個(gè)監(jiān)控指標(biāo)數(shù)據(jù)進(jìn)行統(tǒng)一計(jì)算、統(tǒng)一存儲(chǔ)、統(tǒng)一檢測(cè)、統(tǒng)一告警、統(tǒng)一展示。這里不作贅述，后面會(huì)出一期vivo監(jiān)控系統(tǒng)演進(jìn)的文章進(jìn)一步說(shuō)明。
上面我們說(shuō)了監(jiān)控統(tǒng)一的大背景。以前各個(gè)監(jiān)控系統(tǒng)會(huì)各自進(jìn)行告警收斂、消息組裝等工作，為了減少冗余，需要將收斂等工作由一個(gè)服務(wù)統(tǒng)一做處理，與此同時(shí)告警中心平臺(tái)也到了更新迭代的階段，這樣就需要建設(shè)一個(gè)對(duì)內(nèi)部各業(yè)務(wù)統(tǒng)一提供告警收斂、消息組裝、告警發(fā)送的告警平臺(tái)，有了這個(gè)構(gòu)想，我們準(zhǔn)備將各系統(tǒng)告警收斂能力與告警發(fā)送能力下沉，將統(tǒng)一告警服務(wù)做成一個(gè)與各監(jiān)控服務(wù)解偶的通用服務(wù)。
二、現(xiàn)狀分析
對(duì)于1.0時(shí)代的監(jiān)控系統(tǒng)來(lái)說(shuō)，如圖1所示各個(gè)監(jiān)控系統(tǒng)要先進(jìn)行告警收斂，然后分別和老的告警中心進(jìn)行對(duì)接，才能將告警消息發(fā)送出來(lái)。每一套系統(tǒng)都要單獨(dú)進(jìn)行維護(hù)一套規(guī)則，有很多重復(fù)功能建設(shè)，而實(shí)際這些功能具有高度通用性，完全可以建立合理模型對(duì)異常檢測(cè)服務(wù)生成的異常進(jìn)行統(tǒng)一處理，從而生成問(wèn)題，然后進(jìn)行統(tǒng)一的消息組裝，最后發(fā)送告警消息。
圖1 老監(jiān)控系統(tǒng)告警流程圖
在監(jiān)控系統(tǒng)中一個(gè)異常從被檢測(cè)出來(lái)到最終發(fā)出告警有幾個(gè)重要概念：
1)異常
在一個(gè)檢測(cè)窗口(窗口大小可以自定義)，一個(gè)或幾個(gè)指標(biāo)值達(dá)到檢測(cè)規(guī)則定義的異常閾值，就產(chǎn)生一個(gè)異常。如圖2所示，檢測(cè)規(guī)則定義當(dāng)指標(biāo)值在一個(gè)檢測(cè)窗口為6的檢測(cè)周期內(nèi)，有3個(gè)數(shù)據(jù)點(diǎn)超過(guò)閾值就認(rèn)為有異常，我們簡(jiǎn)稱這個(gè)檢測(cè)規(guī)則為6-3，如圖所示第一個(gè)檢測(cè)窗口內(nèi)(藍(lán)色虛線筐內(nèi))只有6和7兩個(gè)點(diǎn)的指標(biāo)值超過(guò)閾值(95)，不滿足6-3的條件，所以第一個(gè)檢測(cè)窗口沒(méi)有異常。在第二個(gè)檢測(cè)窗口內(nèi)(綠色虛線框內(nèi))有6、7、8三個(gè)點(diǎn)的指標(biāo)值超過(guò)閾值(95)，所以第二個(gè)窗口就是一個(gè)異常。
2)問(wèn)題
一個(gè)連續(xù)的周期內(nèi)產(chǎn)生的所有同類異常的集合，我們稱之為問(wèn)題。如圖2所示，第二個(gè)檢測(cè)窗口就是一個(gè)異常，同時(shí)這個(gè)異常也會(huì)對(duì)應(yīng)有一個(gè)問(wèn)題A，如果第三個(gè)檢測(cè)窗口也是一個(gè)異常，那么這個(gè)異常對(duì)應(yīng)的問(wèn)題也是A，所以問(wèn)題和異常是一對(duì)多的關(guān)系。
3)告警
當(dāng)一個(gè)問(wèn)題通過(guò)告警系統(tǒng)將消息以短信、電話、郵件等方式告知給用戶時(shí)，我們稱之為一條告警。
4)恢復(fù)
當(dāng)問(wèn)題對(duì)應(yīng)的異常不滿足檢測(cè)規(guī)則定義的異常條件時(shí)，就認(rèn)為所有異常都恢復(fù)了，同時(shí)問(wèn)題也認(rèn)為恢復(fù)了，恢復(fù)也會(huì)發(fā)送相應(yīng)的恢復(fù)通知。
圖2 時(shí)序數(shù)據(jù)異常檢測(cè)原理圖
三、衡量指標(biāo)
一個(gè)系統(tǒng)我們?nèi)绾魏饬克暮脡?，如何提升它，如何管理它？管理學(xué)大師彼得·德魯克曾說(shuō)“你如果無(wú)法度量它，就無(wú)法管理它(If you can’t measure it, you can’t manage it)”。從這里可以看出，如果想全面管理提升一個(gè)系統(tǒng)，就需要先對(duì)它的各項(xiàng)性能指標(biāo)有一個(gè)衡量，知道它的薄弱點(diǎn)在哪里，找到病癥所在才能對(duì)癥下藥。
圖3 運(yùn)維指標(biāo)時(shí)間節(jié)點(diǎn)關(guān)系圖
圖3是監(jiān)控系統(tǒng)運(yùn)營(yíng)指標(biāo)和對(duì)應(yīng)時(shí)間節(jié)點(diǎn)關(guān)系圖，主要體現(xiàn)了MTTD、MTTA、MTTF、MTTR、MTBF等指標(biāo)與時(shí)間節(jié)點(diǎn)的對(duì)應(yīng)關(guān)系，這些指標(biāo)對(duì)于提升系統(tǒng)性能，幫助運(yùn)維團(tuán)隊(duì)及早發(fā)現(xiàn)問(wèn)題有很高的參考價(jià)值。業(yè)界有很多云告警平臺(tái)也很注重這些指標(biāo)，下面我們著重介紹一下MTTA、MTTR這兩個(gè)和告警平臺(tái)關(guān)系緊密的指標(biāo)：
MTTA(Mean time to acknowledge,平均應(yīng)答時(shí)間)：
圖4 MTTA計(jì)算公式
-
t[i] -- 監(jiān)控系統(tǒng)運(yùn)行期間第i個(gè)服務(wù)出現(xiàn)問(wèn)題后運(yùn)維團(tuán)隊(duì)或者研發(fā)人員響應(yīng)問(wèn)題的時(shí)間；
-
r[i] -- 監(jiān)控系統(tǒng)運(yùn)行期間第i個(gè)服務(wù)出現(xiàn)問(wèn)題的總次數(shù)。
平均應(yīng)答時(shí)間是運(yùn)維團(tuán)隊(duì)或者研發(fā)團(tuán)隊(duì)響應(yīng)所有問(wèn)題所花費(fèi)的平均時(shí)間。MTTA度量標(biāo)準(zhǔn)用于衡量運(yùn)維團(tuán)隊(duì)或研發(fā)團(tuán)隊(duì)的響應(yīng)能力和警報(bào)系統(tǒng)的效率。通過(guò)跟蹤和最小化MTTA，項(xiàng)目管理團(tuán)隊(duì)可以優(yōu)化流程，提高問(wèn)題解決效率，保障服務(wù)可用性，提升用戶滿意度。
MTTR(Mean Time To Repair,平均維修時(shí)間)：
圖5 MTTR計(jì)算公式
-
t[ri] -- 監(jiān)控系統(tǒng)運(yùn)行期間第i個(gè)服務(wù)出現(xiàn)r次告警后服務(wù)恢復(fù)正常狀態(tài)的總時(shí)間
-
r[i] -- 監(jiān)控系統(tǒng)運(yùn)行期間第i個(gè)服務(wù)出現(xiàn)告警的總次數(shù)
平均修復(fù)時(shí)間（MTTR）是修復(fù)系統(tǒng)并將其恢復(fù)到正常功能所需的平均時(shí)間。運(yùn)維或研發(fā)人員開(kāi)始處理異常，MTTR便開(kāi)始計(jì)算，并且一直進(jìn)行到被中斷的服務(wù)完全恢復(fù)（包括所需的任何測(cè)試時(shí)間）為止。在IT服務(wù)管理行業(yè)中，MTTR中的R并不總是表示維修。它也可以表示恢復(fù)，響應(yīng)或解決。盡管這些指標(biāo)都對(duì)應(yīng)MTTR，但是它們都有各自的含義，因此，要弄清楚要使用哪個(gè)MTTR，有助于我們更好的分析理解問(wèn)題。讓我們簡(jiǎn)要地看一下它們各自的含義：
-
平均恢復(fù)時(shí)間(Mean time to recovery)是從系統(tǒng)告警中恢復(fù)所需的平均時(shí)間。這涵蓋了從服務(wù)異常導(dǎo)致告警到恢復(fù)正常的整個(gè)過(guò)程。MTTR是衡量整個(gè)恢復(fù)過(guò)程速度的指標(biāo)。
-
平均響應(yīng)時(shí)間(Mean time to respond)表示從出現(xiàn)第一個(gè)告警開(kāi)始到系統(tǒng)從故障中恢復(fù)到正常狀態(tài)所需的平均時(shí)間，不包括告警系統(tǒng)中的任何延遲。該MTTR通常用于網(wǎng)絡(luò)安全中，以衡量團(tuán)隊(duì)緩解系統(tǒng)攻擊的效率。
-
平均解決時(shí)間(Mean time to resolve)表示完全解決系統(tǒng)故障所花費(fèi)的平均時(shí)間，包括檢測(cè)故障、診斷問(wèn)題以及確保故障不再發(fā)生來(lái)解決問(wèn)題所需的時(shí)間。此 MTTR 指標(biāo)主要用于衡量不可預(yù)見(jiàn)事件的解決過(guò)程，而不是服務(wù)請(qǐng)求。
提升 MTTA 的核心是找對(duì)人、找到人，只有在最短的時(shí)間內(nèi)找對(duì)能處理問(wèn)題的人才能有效提升MTTR。通常在生產(chǎn)實(shí)踐過(guò)程中我們會(huì)遇到“告警泛濫”的問(wèn)題，大量的告警出現(xiàn)時(shí)需要運(yùn)維人員或者開(kāi)發(fā)同學(xué)去解決，對(duì)于應(yīng)激敏感的同學(xué)來(lái)說(shuō)很容易出現(xiàn)“狼來(lái)了”的現(xiàn)象，只要收到告警就會(huì)很緊張，同時(shí)當(dāng)大量的告警信息頻發(fā)騷擾我們運(yùn)維人員，會(huì)引發(fā)告警疲勞，體現(xiàn)為不重要的事件太多，最根本的問(wèn)題較少，頻繁處理普通事件，重要的信息淹沒(méi)在汪洋大海中。
圖6 告警泛濫問(wèn)題圖
四、功能設(shè)計(jì)
通過(guò)上面兩個(gè)重要指標(biāo)的分析，我們總結(jié)出要從告警數(shù)量、告警收斂、告警升級(jí)等方面著手，減少告警發(fā)送的數(shù)量，提升告警準(zhǔn)確性，最終提升解決問(wèn)題的效率，降低問(wèn)題恢復(fù)時(shí)長(zhǎng)。下面我們從系統(tǒng)和功能層面說(shuō)明如何降低告警量，把真正有價(jià)值的告警信息發(fā)送到用戶手中。本文也將重點(diǎn)圍繞告警消息收斂進(jìn)行講解。
從圖1中可以看出各個(gè)監(jiān)控系統(tǒng)中都有很多重復(fù)的功能模塊，所以針對(duì)這些功能模塊我們可以將其抽離出來(lái)，如圖7所示將告警收斂、告警屏蔽、告警升級(jí)等能力統(tǒng)一建設(shè)在統(tǒng)一告警服務(wù)中。這種架構(gòu)下統(tǒng)一告警服務(wù)與檢測(cè)相關(guān)服務(wù)完全解耦，在能力上具有一定的通用性。例如其它有告警或消息收斂需求的業(yè)務(wù)團(tuán)隊(duì)想接入統(tǒng)一告警，統(tǒng)一告警要能滿足消息收斂發(fā)送的需求，同時(shí)也要滿足消息直接發(fā)送的需求。統(tǒng)一告警會(huì)提供靈活可配置的消息發(fā)送方式，提供簡(jiǎn)單、多樣的功能滿足各類需求。
圖7 統(tǒng)一告警系統(tǒng)結(jié)構(gòu)圖
1、告警收斂
對(duì)于告警平臺(tái)每天會(huì)產(chǎn)生數(shù)以萬(wàn)計(jì)的告警，這些告警對(duì)于運(yùn)維或開(kāi)發(fā)人員都需要去分析、甄別優(yōu)先級(jí)、并處理故障。數(shù)以萬(wàn)計(jì)的告警如果不加收斂每條異常都發(fā)送告警，勢(shì)必會(huì)增大運(yùn)維人員的工作壓力，當(dāng)然也不是所有的告警都需要并且有必要發(fā)送給運(yùn)維人員進(jìn)行處理。所以我們需要對(duì)告警通過(guò)多種手段進(jìn)行收斂，下面我們從四個(gè)方面介紹一下如何進(jìn)行告警收斂。
1)首次告警等待
當(dāng)一個(gè)異常產(chǎn)生之后我們不會(huì)立即去做告警，而是通過(guò)等待一段時(shí)間才會(huì)去做告警發(fā)送，一般這個(gè)時(shí)間可以通過(guò)系統(tǒng)自定義，這個(gè)值如果太大就會(huì)影響告警延遲，太小不能提升告警合并效果。例如首次告警等待時(shí)間為5s，當(dāng)一個(gè)服務(wù)下節(jié)點(diǎn)1出現(xiàn)A指標(biāo)異常，5s內(nèi)節(jié)點(diǎn)2也出現(xiàn)了A指標(biāo)異常，那么發(fā)送告警時(shí)節(jié)點(diǎn)1和節(jié)點(diǎn)2會(huì)被合并到一起發(fā)送告警通知。
2)告警間隔
問(wèn)題在沒(méi)有恢復(fù)前，系統(tǒng)會(huì)根據(jù)告警間隔的配置每隔一段時(shí)間發(fā)送一條告警信息，告警間隔用來(lái)控制告警發(fā)送的頻率。
3)異常收斂維度
異常收斂維度用來(lái)將同個(gè)維度下的異常合并在一起。例如同個(gè)節(jié)點(diǎn)路徑A下，通過(guò)同一個(gè)檢測(cè)規(guī)則產(chǎn)生的異常，會(huì)在告警發(fā)送的時(shí)候根據(jù)配置的異常收斂維度合并在一起。
4)消息合并維度
當(dāng)多個(gè)異常收斂成一個(gè)問(wèn)題，在發(fā)送告警的時(shí)候會(huì)涉及到消息合并，消息合并維度就是用來(lái)指定哪些維度可以合并。可能這樣理解有些晦澀，我們可以通過(guò)圖8看一下從異常到消息的轉(zhuǎn)換過(guò)程。
假如一個(gè)異常有兩個(gè)維度名字和性別，當(dāng)這兩個(gè)異常經(jīng)過(guò)統(tǒng)一告警，我們會(huì)根據(jù)配置的收斂策略進(jìn)行合并，從圖中我們可以看到性別被定義為異常收斂維度，通常異常收斂維度的選擇一定是兩個(gè)或兩個(gè)以上具有相同的屬性的異常，這樣在消息合并后只取相同屬性的同一個(gè)值，對(duì)應(yīng)到示例圖，我們會(huì)將${sex}占位符替換成男。而名字是被定義為告警合并維度，就表示所有異常中名字是都要展示在消息文本中，所以在消息合并的時(shí)候我們會(huì)將${name}占位符對(duì)應(yīng)的信息一一拼接在消息文本中。
圖8 消息文本替換示意圖
2、告警認(rèn)領(lǐng)
當(dāng)出現(xiàn)告警后如果有人認(rèn)領(lǐng)了該告警，那么后續(xù)相同告警只會(huì)發(fā)送給告警認(rèn)領(lǐng)人。告警認(rèn)領(lǐng)主要是為了解決告警有人跟進(jìn)后，減少將告警發(fā)給其他人員，也能從一定程度上解決告警被重復(fù)處理的問(wèn)題。被認(rèn)領(lǐng)的告警可以取消認(rèn)領(lǐng)。
3、告警屏蔽
對(duì)于同一個(gè)問(wèn)題，可以設(shè)置告警屏蔽，后續(xù)如果有該問(wèn)題對(duì)應(yīng)的告警產(chǎn)生，那么將不會(huì)被發(fā)送出去。告警屏蔽能減少故障在定位解決過(guò)程中，或者服務(wù)在發(fā)版變更過(guò)程中造成的告警，能有效減少無(wú)效告警對(duì)運(yùn)維人員造成的困擾，屏蔽可以設(shè)置為周期性的，也可以設(shè)置為屏蔽某一時(shí)段，當(dāng)然也可以取消屏蔽。
4、告警回調(diào)
當(dāng)告警規(guī)則配置了回調(diào)，那么當(dāng)產(chǎn)生告警，就會(huì)調(diào)用回調(diào)接口，使服務(wù)或業(yè)務(wù)恢復(fù)正常。告警回調(diào)的目的是當(dāng)某個(gè)服務(wù)有告警產(chǎn)生，希望系統(tǒng)能夠通過(guò)一些自動(dòng)化的配置，使服務(wù)恢復(fù)到正常狀態(tài)，縮短故障恢復(fù)的時(shí)間，也能夠緊急情況下第一時(shí)間快速恢復(fù)服務(wù)。
5、誤告標(biāo)注
對(duì)于一個(gè)問(wèn)題，用戶可以通過(guò)誤告標(biāo)注備注該異常是否為誤告警。誤告標(biāo)注的主要目的是通過(guò)標(biāo)注讓系統(tǒng)開(kāi)發(fā)人員知道異常檢測(cè)過(guò)程中，哪寫(xiě)點(diǎn)還需要提升優(yōu)化，提高告警的準(zhǔn)確性，為用戶提供真實(shí)有效的告警提供保障。
6、告警升級(jí)
當(dāng)告警發(fā)生一定時(shí)間仍沒(méi)有恢復(fù)，那么系統(tǒng)就會(huì)根據(jù)配置自動(dòng)進(jìn)行告警升級(jí)處理，然后將告警升級(jí)信息通過(guò)配置發(fā)送給對(duì)應(yīng)的人員。告警升級(jí)一定程度上是為了縮短MTTA，當(dāng)告警長(zhǎng)時(shí)間未恢復(fù)，可以認(rèn)為故障沒(méi)有及時(shí)得到響應(yīng)，這時(shí)就需要更高級(jí)別的人員介入處理。
如圖9所示，每天告警系統(tǒng)會(huì)發(fā)送大量的告警，當(dāng)然這些告警會(huì)分別發(fā)送給不同服務(wù)的告警接收人。告警并不是越多越好，而是應(yīng)該第一時(shí)間準(zhǔn)確反映出服務(wù)的異常情況，所以如何提升有效告警，提高告警準(zhǔn)確性，減少告警量至關(guān)重要。通過(guò)以上系統(tǒng)設(shè)計(jì)和功能設(shè)計(jì)能夠有效減少重復(fù)告警發(fā)送。
圖9 主機(jī)監(jiān)控告警次數(shù)圖
五、架構(gòu)設(shè)計(jì)
上面我們從系統(tǒng)和功能層名講解了如何針對(duì)老架構(gòu)下存在的各種問(wèn)題進(jìn)行解決，那么對(duì)于這個(gè)構(gòu)想我們應(yīng)該用一套什么架構(gòu)來(lái)實(shí)現(xiàn)。
下面我們看下如何設(shè)計(jì)這套架構(gòu)。統(tǒng)一告警作為整個(gè)監(jiān)控最后一環(huán)，既要滿足告警發(fā)送能力也要滿足業(yè)務(wù)服務(wù)發(fā)送通知的需求，所以統(tǒng)一告警的各種能力要具有通用性。統(tǒng)一告警服務(wù)要做到與其它服務(wù)低耦合，尤其是與已有監(jiān)控系統(tǒng)做到解偶，這樣才能真正把通用能力釋放出來(lái)。服務(wù)要能做到根據(jù)業(yè)務(wù)場(chǎng)景的不同適配不同的業(yè)務(wù)邏輯，比如有的業(yè)務(wù)需要做告警收斂，有的業(yè)務(wù)不需要，那么服務(wù)要提供靈活的接入方式以適用業(yè)務(wù)需要。
如圖10所示，統(tǒng)一告警核心邏輯由收斂服務(wù)實(shí)現(xiàn)，收斂服務(wù)可以消費(fèi)kafka中的異常，也可以通過(guò)RestFul接口接收推送過(guò)來(lái)的異常，異常會(huì)先經(jīng)過(guò)異常處理生成一個(gè)問(wèn)題，然后將問(wèn)題和異常存入MySQL庫(kù)，經(jīng)過(guò)告警收斂模塊問(wèn)題會(huì)被推送到Redis延時(shí)隊(duì)列中，延時(shí)隊(duì)列會(huì)用來(lái)控制消息出隊(duì)時(shí)間，消息從隊(duì)列取出之后會(huì)進(jìn)行文本組裝等操作，最后會(huì)通過(guò)配置發(fā)送出去。
圖10 統(tǒng)一告警架構(gòu)圖
配置管理服務(wù)用來(lái)管理應(yīng)用、事件、告警等配置信息，元數(shù)據(jù)同步服務(wù)用來(lái)從其它服務(wù)同步告警收斂所需的元數(shù)據(jù)。
六、核心實(shí)現(xiàn)
統(tǒng)一告警的核心是告警收斂，收斂的目的就是減少發(fā)送重復(fù)的告警消息，避免因?yàn)榇罅康母婢瘜?duì)于告警接收人造成告警麻痹。
前文已經(jīng)說(shuō)到使用延時(shí)隊(duì)列做告警收斂，延時(shí)隊(duì)列在電商和支付項(xiàng)目中使用較多，比如商品下單后10分鐘未支付就要自動(dòng)取消訂單。在告警系統(tǒng)中使用延時(shí)隊(duì)列主要目的是，在一定的時(shí)間內(nèi)盡可能多的將同一個(gè)問(wèn)題對(duì)應(yīng)的異常合并在一起，減少告警發(fā)送的數(shù)量。舉個(gè)例，如果一個(gè)服務(wù)A有三個(gè)節(jié)點(diǎn)，當(dāng)發(fā)生異常時(shí)，一般情況下每個(gè)節(jié)點(diǎn)的異常都會(huì)生成一條告警發(fā)送出去，但是經(jīng)過(guò)告警收斂時(shí)候我們可以將三個(gè)節(jié)點(diǎn)的告警合并，由一條告警做通知。
延時(shí)隊(duì)列有很多種方式實(shí)現(xiàn)，這里我們選擇了Redis實(shí)現(xiàn)延時(shí)隊(duì)列，選用 Redis 延時(shí)隊(duì)列主要的原因就是其支持高性能的 score 排序，同時(shí) Redis 的持久化特性，保證了消息的消費(fèi)和存貯問(wèn)題。
如圖11所示，一個(gè)問(wèn)題通過(guò)一系列校驗(yàn)去重之后放入redis延時(shí)隊(duì)列，隊(duì)列中到期時(shí)間最小的問(wèn)題會(huì)被排到最前面，同時(shí)有一個(gè)監(jiān)聽(tīng)任務(wù)不斷查看隊(duì)列中是否有過(guò)期的任務(wù)，如果有過(guò)期的任務(wù)會(huì)被取出，取出的消息會(huì)經(jīng)過(guò)消息組裝等操作最終形成一條消息文本，然后根據(jù)配置通過(guò)不同的通道發(fā)送出去。
圖11 延時(shí)任務(wù)執(zhí)行原理圖
七、未來(lái)展望
基于統(tǒng)一告警服務(wù)定位來(lái)看，告警服務(wù)要能簡(jiǎn)單、高效、準(zhǔn)確的告訴運(yùn)維或者開(kāi)發(fā)人員，哪里有故障需要去處理。所以對(duì)于后續(xù)服務(wù)的建設(shè)，應(yīng)該考慮如何進(jìn)一步減少人為的配置，增強(qiáng)告警智能化收斂的能力，同時(shí)還要增強(qiáng)根因定位的能力，以上通過(guò)AI的加持能夠很好的解決此類問(wèn)題。
目前各大廠商都在向著AIOps探索前進(jìn)，并且已經(jīng)有一些產(chǎn)品投入使用，但是AIOps何時(shí)大規(guī)模落地，就目前來(lái)看還需要一段時(shí)間。相較于AI的使用，當(dāng)前最緊迫的就是讓統(tǒng)一告警串聯(lián)起上下游服務(wù)，從而打通數(shù)據(jù)，為數(shù)據(jù)流轉(zhuǎn)鋪平道路，增強(qiáng)服務(wù)的自動(dòng)化程度，并且支持從更高維度實(shí)現(xiàn)告警發(fā)送，為故障的發(fā)現(xiàn)和解決提供更準(zhǔn)確的信息。
-
作者丨Chen Ningning來(lái)源丨公眾號(hào)：vivo互聯(lián)網(wǎng)技術(shù)（ID：vivoVMIC）
欲知詳情，請(qǐng)下載word文檔
下載文檔
本站聲明： 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布，目的在于傳遞更多信息，并不代表本站贊同其觀點(diǎn)，本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專欄作者，如若文章內(nèi)容侵犯您的權(quán)益，請(qǐng)及時(shí)聯(lián)系本站刪除。
