?運維告警是運維自動化系統最為基礎的功能，早期的運維監控系統只報告系統是否還活著。那個時代的數據庫運維十分簡陋，大部分故障都是業務部門告警，運維部門才知道，哦，數據庫出問題了。那時候的領導總是希望運維部門能比業務部門早幾分鐘知道系統出問題了。以便于業務部門領導打電話來問的時候可以說，我們已經在恢復中了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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