?運(yùn)維告警是運(yùn)維自動(dòng)化系統(tǒng)最為基礎(chǔ)的功能，早期的運(yùn)維監(jiān)控系統(tǒng)只報(bào)告系統(tǒng)是否還活著。那個(gè)時(shí)代的數(shù)據(jù)庫運(yùn)維十分簡(jiǎn)陋，大部分故障都是業(yè)務(wù)部門告警，運(yùn)維部門才知道，哦，數(shù)據(jù)庫出問題了。那時(shí)候的領(lǐng)導(dǎo)總是希望運(yùn)維部門能比業(yè)務(wù)部門早幾分鐘知道系統(tǒng)出問題了。以便于業(yè)務(wù)部門領(lǐng)導(dǎo)打電話來問的時(shí)候可以說，我們已經(jīng)在恢復(fù)中了。

隨著運(yùn)維能力的提升，僅僅監(jiān)控?cái)?shù)據(jù)庫是不是活著已經(jīng)不能滿足IT部門運(yùn)維的要求了?！胺阑加谖慈弧弊兂闪薎T部門對(duì)于運(yùn)維監(jiān)控的最基本的要求。不過要做到這一點(diǎn)并不容易，因?yàn)槲覀冃枰泻軓?qiáng)大的監(jiān)控預(yù)警能力，才能夠及時(shí)發(fā)現(xiàn)系統(tǒng)的隱患。于是我們采集了更多的指標(biāo)，并建立了基線，通過基線我們可以對(duì)某個(gè)指標(biāo)的異常進(jìn)行告警。

不過單一基線告警對(duì)于運(yùn)維告警來說做起來并不容易，雖然目前主流的開源監(jiān)控平臺(tái)大部分都是以基線告警為主，不過基線告警的能力還是太弱了，很容易出現(xiàn)大量無意義的告警。于是組合規(guī)則告警這種相對(duì)更準(zhǔn)確一些的告警替代了簡(jiǎn)單的基線告警，通過一組業(yè)務(wù)規(guī)則，幾個(gè)指標(biāo)之間的組合關(guān)系，更容易描述一個(gè)具體的故障場(chǎng)景。通過一個(gè)略微復(fù)雜的規(guī)則引擎，通過規(guī)則表達(dá)式可以實(shí)現(xiàn)更為準(zhǔn)確的告警。近些年來，在D-SMART上，這種被我們稱為“運(yùn)維經(jīng)驗(yàn)告警”的模式在發(fā)揮著主要的作用，已經(jīng)完全替代了基線告警。

通過這種組合規(guī)則告警，我們不僅可以收斂告警數(shù)量，還可以收斂告警問題的故障原因，提供專業(yè)的診斷工具用于問題分析與溯源。這種基于規(guī)則的復(fù)合場(chǎng)景告警可以大大收斂告警的數(shù)量，對(duì)于運(yùn)維告警能力的提升發(fā)揮了極大的作用。我們還可以把告警信息推送到企業(yè)微信上，讓告警變得更好用。企業(yè)微信推送是一個(gè)十分不錯(cuò)的功能，可以讓聊天群和告警推送緊密結(jié)合，可惜近期微信推送接口全面修改，必須將企業(yè)推送平臺(tái)托管到騰訊云的專門區(qū)域，這增加了這個(gè)接口的建設(shè)復(fù)雜度，同時(shí)可能也在為商業(yè)化收費(fèi)做準(zhǔn)備。

上面是一個(gè)企業(yè)微信的消息機(jī)器人發(fā)送的告警信息。細(xì)心的朋友可能看出了這個(gè)告警似乎有點(diǎn)不太一樣。上面的CPU使用率比較高的告警，明明是高于90%才告警，這個(gè)告警信息里當(dāng)前CPU使用率才29.2%怎么也告警了。

實(shí)際上我們要告警告的并不是指標(biāo)，而是數(shù)據(jù)庫的異常。在十多年前，服務(wù)器資源經(jīng)常處于不足的時(shí)候，大部分系統(tǒng)都是高負(fù)載運(yùn)行的，CPU使用率長(zhǎng)期超過90%甚至達(dá)到100%的事情經(jīng)常發(fā)生，一旦發(fā)生了，就需要DBA去處置了。而現(xiàn)在的系統(tǒng)CPU資源往往都很足夠，平時(shí)系統(tǒng)CPU使用率可能也就10%左右，出現(xiàn)異常時(shí)候也不見得能達(dá)到90%，因此我們?cè)O(shè)置一個(gè)90%的CPU告警閾值可能過高了。甚至我們必須針對(duì)不同的系統(tǒng)的不同時(shí)間段或者不同業(yè)務(wù)特點(diǎn)時(shí)段設(shè)置不同的告警閾值，才能夠?qū)崿F(xiàn)比較精準(zhǔn)的告警。

基于上述原因，CPU等資源使用率過大告警無法采用傳統(tǒng)的模式。我們需要發(fā)現(xiàn)系統(tǒng)存在的異常，那么我們就需要去檢測(cè)異常，而不是檢測(cè)某個(gè)具體的閾值。于是有了這種基于“異常檢測(cè)”的預(yù)警。

通過上面這個(gè)告警，我們大體知道，這套系統(tǒng)的CPU使用率出現(xiàn)異常了，并且告警時(shí)的CPU使用率不算太高，不到30%。如果我手頭還有更緊急的事情，我們完全可以等會(huì)兒再來處理這個(gè)異常。

比較幸運(yùn)的是幾分鐘后我們又收到了一條告警信息，某條業(yè)務(wù)關(guān)注的關(guān)鍵SQL的平均邏輯讀突然增加了。這很可能意味著這條SQL的執(zhí)行計(jì)劃發(fā)生了改變或者訪問的表的數(shù)據(jù)發(fā)生了變化，而這個(gè)告警和上面的CPU使用率突然變高的告警是存在關(guān)聯(lián)關(guān)系的，很可能SQL語句執(zhí)行成本變高是CPU使用率突增的主要原因。

告警收斂是目前很多做AIOPS的企業(yè)都在做的工作，實(shí)際上上面的兩個(gè)告警很可能是有聯(lián)系的，兩個(gè)告警如果能夠合并那就最好了。不過以我們當(dāng)前的技術(shù)水平，還做不到直接對(duì)二者進(jìn)行合并，我們目前通過運(yùn)維知識(shí)圖譜實(shí)現(xiàn)了部分場(chǎng)景的自動(dòng)化合并，不過目前因?yàn)橛?jì)算量過大的問題，暫時(shí)還無法使用到運(yùn)維告警上。這是為什么呢？按理說如果是SQL語句執(zhí)行成本上升，導(dǎo)致邏輯讀上升，從而導(dǎo)致CPU使用率上升，應(yīng)該是邏輯讀上升先出現(xiàn)，而CPU使用率上升后出現(xiàn)。

不做在實(shí)際的監(jiān)控中想要準(zhǔn)確的捕獲到如此細(xì)微的變化是不容易的，這種情況普通的監(jiān)控很難做到，只有trace能夠做到。因?yàn)楸O(jiān)控是周期性采樣，哪怕監(jiān)控采樣周期縮短為30秒，也有可能采集不到這種先后變化的情況。

CPU使用率是2分鐘一次的定期采樣，而關(guān)鍵SQL跟蹤是每5分鐘一次的任務(wù)，因此關(guān)鍵SQL跟蹤發(fā)現(xiàn)問題就滯后了。另外還有一些告警場(chǎng)景不能每次捕獲到異常就告警，而是需要在某個(gè)周期內(nèi)滿足連續(xù)出現(xiàn)或者M(jìn)次中至少N次這樣的規(guī)則，因此順序與關(guān)聯(lián)合并變得更加復(fù)雜。同時(shí)因?yàn)閿?shù)據(jù)庫系統(tǒng)是十分復(fù)雜的系統(tǒng)，因此以我們目前的技術(shù)能力還無法在監(jiān)控階段就對(duì)此進(jìn)行十分明確的合并。因此我們選擇了同時(shí)發(fā)布多個(gè)告警，讓DBA隨后使用工具去做診斷發(fā)現(xiàn)。錯(cuò)誤的合并很可能會(huì)對(duì)后面的問題診斷產(chǎn)生誤導(dǎo)，因此我們選擇讓DBA和專家看到更多的細(xì)節(jié)，而不是幫他們做出錯(cuò)誤的判斷。

因?yàn)槭顷P(guān)鍵SQL出現(xiàn)了告警，因此我們不能像上一條告警一樣可以暫時(shí)擱置了。于是可以通過診斷工具去做一下分析。確實(shí)在告警期間，這條SQL的執(zhí)行成本發(fā)生了變化。

監(jiān)控的目的是發(fā)現(xiàn)異常，而在以前技術(shù)條件不具備的時(shí)候，我們只能把異常簡(jiǎn)單的定義為某個(gè)閾值，久而久之我們就誤以為監(jiān)控就是監(jiān)控閾值了。實(shí)際上，監(jiān)控技術(shù)這些年發(fā)展十分迅速，從簡(jiǎn)單的指標(biāo)監(jiān)控，到日志監(jiān)控、態(tài)勢(shì)監(jiān)控，在技術(shù)上都已經(jīng)日趨成熟。因此我們也應(yīng)該嘗試讓運(yùn)維告警從發(fā)現(xiàn)異常，自動(dòng)分析異常，從而逐步向自動(dòng)化處置邁進(jìn)。目前的技術(shù)可能離自動(dòng)化處置還有一段距離，不過我們依然能夠在消減告警數(shù)量，合并告警場(chǎng)景上有較大的提升空間。

第一個(gè)可以用于消減告警數(shù)量的方法就是對(duì)已恢復(fù)的告警的處置策略上的優(yōu)化。如果一個(gè)告警發(fā)生后，過了一會(huì)兒系統(tǒng)恢復(fù)了，或者說風(fēng)險(xiǎn)消失了，我們?cè)撊绾翁幚砟?？我們還去一個(gè)個(gè)死磕，要求做閉環(huán)管理，還是暫時(shí)可以不理會(huì)它呢？可能每個(gè)企業(yè)采用的不同的管理模式會(huì)對(duì)處置方法有些差異，不過隨著需要運(yùn)維管理的系統(tǒng)的數(shù)量不斷擴(kuò)大，哪怕僅僅對(duì)于核心系統(tǒng)的每個(gè)告警信息都做閉環(huán)管理也是一件成本比較高的事情。

如果我們處理這樣的告警還是比較容易的，如果連已經(jīng)恢復(fù)的告警也要一個(gè)個(gè)去做閉環(huán)分析，那么工作量就大了。

不過如果對(duì)于已恢復(fù)的告警就置之不理也不是一種合理的態(tài)度，如果這些問題確實(shí)是由一些深層次的隱患觸發(fā)的，不去分析他們就會(huì)留下一些地雷，說不定什么時(shí)候就引爆了。這讓我們陷入了兩難的境地，不做閉環(huán)，可能留下隱患，做閉環(huán)管理，成本又承受不起。解決這個(gè)問題的最好的辦法就是巡檢。

巡檢是近年來被詬病的最深的運(yùn)維業(yè)務(wù)了，不做巡檢除了問題有責(zé)任，做了巡檢沒有發(fā)現(xiàn)問題既浪費(fèi)時(shí)間又要背責(zé)任。在這種無奈之下，一個(gè)十分重要的運(yùn)維工具就被邊緣化了。出現(xiàn)過異常，但是很快自愈的問題，實(shí)際上可以放到巡檢的時(shí)候再來統(tǒng)一分析。巡檢時(shí)，可以對(duì)數(shù)據(jù)庫在某個(gè)時(shí)間段內(nèi)的整體情況進(jìn)行統(tǒng)一分析，可以對(duì)某個(gè)時(shí)間區(qū)間內(nèi)的多個(gè)異常進(jìn)行總體分析，因此能夠發(fā)現(xiàn)很多系統(tǒng)隱患。形成巡檢工作沒有太大價(jià)值的觀點(diǎn)的主要原因還是巡檢的質(zhì)量存在問題，如果在巡檢中能夠把某個(gè)時(shí)間段內(nèi)因?yàn)楣ぷ髁刻鬅o法分析而問題都幾種分析一下，那么巡檢工作就有了新的價(jià)值了。只不過這種分析必須是自動(dòng)化的，不能由人工去做。

基于此思想，我們最近的幾個(gè)版本中都花了大量的工作在巡檢報(bào)告的優(yōu)化上，爭(zhēng)取能夠讓巡檢報(bào)告實(shí)用化。在最近的一系列修改中，我們發(fā)現(xiàn)了以前報(bào)告的大量的問題，發(fā)現(xiàn)問題最好的方法是讓我們的專家僅僅通過閱讀巡檢報(bào)告就幫遠(yuǎn)程的用戶分析問題，經(jīng)過多次這樣的迭代，報(bào)告的質(zhì)量也就大大提高了。這些更新將會(huì)在本月底發(fā)布的V2.2中和大家見面。

運(yùn)維告警是個(gè)做起來不難，做好十分不易的事情，我們希望通過把這些年專家積累的經(jīng)驗(yàn)都提煉出來，融合到這個(gè)工作中去，并不斷在用戶那邊實(shí)踐，不斷提升這項(xiàng)能力。如果大家對(duì)這項(xiàng)工作有興趣，我們也可以進(jìn)行交流，我們也愿意把我們實(shí)踐中的發(fā)現(xiàn)不斷地分享給大家。?