基線告警是目前大部分數據庫監控軟件的最重要的功能之一，可以說，基線告警是運維人員的眼睛和耳朵，不過搞運維的人都為這個眼鏡耳朵傷透了腦筋，甚至很多人都被鋪天蓋地的無效告警傷害過。

基線告警雖然實現起來很簡單，也一定是有用的，不過每個系統的運行特性都不同，因此基線到底設置成多少呢是個令人頭痛的事情。IO延時的告警閾值設置為50毫秒還是20毫秒呢？如果設置為20毫秒，那么經常出告警，但是系統也沒啥問題。如果設置為50毫秒，有時候并發量高得時候，30多毫秒系統就出大問題了，甚至有時候IO延時50毫秒了還沒問題，但是有時候才30多毫秒，系統就掛了。

另外一種情況是，我們可能運維了數十個甚至數百個大大小小的數據庫，數據量差異很大，運行負載也各不相同。如果只是設計幾種基線模板，適用于這么多系統，那么肯定會遇到不太合適的情況。如果能夠根據每個系統的運行狀態，為每個系統設置一套基線，情況會好很多，但是工作量是極大的。

另外一方面，數據庫系統的基線并不是一成不變的，隨著系統負載的變化，業務增長，設備的老化，基線每年都在變，總不成每年都根據系統的情況調整一次基線？那么DBA也沒時間干別的事情了。

即使我們做了很多工作，基線告警依然不夠準確，每條告警信息都去處置，肯定忙不過來，很多時候我們只能忽略絕大多數告警信息。那么問題又來了，在黃油定律的主導下，很可能被我們忽略的某個告警，最終真的出事了。

正是因為這個問題，在設計D-SMART的告警功能的時候，基線并不是用來報警的，系統告警臺是不推送基線告警的，僅僅推送運維經驗告警，而運維經驗告警是基于一組規則的故障模型觸發的。

雖然不需要通過基線異常來產生系統告警，不過基線告警還是反映指標是否正常的最省事的方法，在進行診斷分析時我們還是需要判斷某個指標是否異常。為了避免基線閾值設置的不合理問題，指標是否異常是通過異常檢測算法來判斷的，并不依賴于基線模板。

雖然如此，我們在系統中還是設置了基線預警模板，并根據這個模板，自動記錄基線異常的告警信息（僅僅記錄，并不推送），基線產生的告警主要用于日檢和月度巡檢時發現系統“可能”存在的問題。

有一種更加靈活的基線，那就是動態基線。最早的動態基線的實現是為了解決每天白天和夜間不同的業務負載時某些指標的合力波動范圍的問題的。或者解決工作日與非工作日，月底業務高峰期與平時業務高峰期的差異性告警問題。以前我們管理的系統比較少的時候，還可以精工細作，隨著信息系統規模的不斷擴大，這種精益化運維的模式極難持續。如何解決如今IT系統數量爆炸式增長時加量不加價，實現減員增效，對于大多數IT運維部門都是一個頭疼的問題。如果這一切能夠變成自動的，那么就可以解決一個大問題了。

上圖是我們實驗室的一個基線告警的截圖，告警的閾值很多都是有零有整的，這些閾值并不是配置出來的，而是動態計算出來的。在實現動態基線的時候，我剛開始的設想是不設置基線模板，而是通過異常檢測算法自動計算異常，發現異常就告警。不過研發部門認為這樣做計算量太大，會導致Monitor任務變得不穩定。因此做了一個變通，那就是將異常檢測算法改造后動態生成某個指標的基線閾值。這樣處理后，Monitor在分析剛剛采集回來的數據的時候，就可以按照傳統的基線模板的模式去處理了。

在配置基線告警的時候，我們引入了一個虛擬模板-“智能基線告警模板”，這個模板不需要預先配置，而是系統自動生成的。生成這個模板的規則在圖數據庫中以圖譜的方式存儲，每天固定的時間里，后臺任務會自動計算這個模板所需要的閾值，然后將計算結果存儲到Redis中，供Monitor做基線評估時使用。

因此當系統剛剛上線的時候，這個模板還是一個虛擬的，沒有真實數據的模板，等系統跑上十天八天，數據就比較精準了，此時這個智能模板就可以發揮作用了。目前智能基線模板的功能還是BETA階段，使用起來還不夠方便。比如剛剛接入系統時還不能直接使用該模板，還需要使用常規模板，系統運行10天以后，模板數據比較準確了，才能切換。這樣使用起來也不夠方便，如果我們有100多套數據庫，那么配置起來還是挺費勁的。

目前傳統模板提供了一個對象應用功能，可以實現一鍵批量綁定，而智能模板是一個虛擬模板，目前在模板管理中是看不見的，因此無法實現一鍵綁定，后續我們將在V2.2中提供一個這樣的功能。這樣系統剛剛接入時可以使用傳統基線模板，半個月后，再手工設置為智能基線模板。甚至今后還可以提供更為方便的模式，在設置基線模板的時候提供一個選型，選擇參數，10天后自動切換為智能基線模板。

而在動態基線的自適應能力方面，也仍然有著極大的提升空間，針對不同的行業用戶的不同特點，其基線計算是不同的，比如券商的核心交易系統，只有在開市期間的負載才是有意義的，你如果把其他時段的數據加入進來計算，肯定會影響計算結果的準確性。因此在系統中加入“系統特征”這個參數十分重要。“系統特征”可以微調算法，讓算法更加準確。

運維自動化系統，需要帶給DBA的是準確高效的報警，便捷的操作。想要做好這一點真的不易，因為大部分的開發人員都是脫離運維第一線很長時間或者甚至沒有做過一天真正的運維工作。因此開發人員可能無法感知到運維人員的真實需求。做好一個運維自動化工具的項目還是比較容易的，因為客戶會不斷根據自己的運維習慣來提出修改意見，我們總是能把系統修改好；而要做一個好用的運維自動化產品就不易了，系統功能，使用習慣，面臨的差異化的系統都讓這項工作變得復雜很多。因此我們堅定的開啟了社區版的發布，希望通過社區的力量，幫我們把產品打磨的更好。