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

隨著運維能力的提升，僅僅監(jiān)控數(shù)據(jù)庫是不是活著已經(jīng)不能滿足IT部門運維的要求了。“防患于未然”變成了IT部門對于運維監(jiān)控的最基本的要求。不過要做到這一點并不容易，因為我們需要有很強大的監(jiān)控預(yù)警能力，才能夠及時發(fā)現(xiàn)系統(tǒng)的隱患。于是我們采集了更多的指標(biāo)，并建立了基線，通過基線我們可以對某個指標(biāo)的異常進(jìn)行告警。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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