?基線預警數據庫運維監控中的重要手段之一，通過基線發現系統中某些指標存在的不合理波動，進而提前預警，是一種數據庫運維監控中最為常用的手段，也是目前大多數企業正在使用的主要監控方案。

雖然大家都用基線預警，不過大家關注的基線指標與閾值都存在較大的差異。因為雖然大家使用的數據庫的種類相同，但是大家的系統都存在較大的差異。具體用哪些指標來做預警，以及設定什么樣的閾值，這是十分個性化的。實際上一個能夠真正起作用的基線預警系統，里面都包含了大量的運維經驗。

以每秒讀時間這個指標為例，我們可以看出其取值范圍波動是較大的，并且沒有明顯的聚集特性，此類指標我們該如何設置基線呢？確實也是有些頭疼的事情。

再來看看另外一個數據庫的共享緩存區命中率，其點的集中度還是比較集中，但是還是存在散落分布的，差異很大的值。這些值要不要告警呢？告警對我們的運維有什么意義呢？也真的說不清楚。而且如果我們運維數百套，甚至上千套類似的數據庫系統，我們也無法對這些數據庫系統設置合理的基線閾值。如果不去做個性化的設置，那么基線告警就不準確，運維告警工作陷入了兩難的境地。

可能有朋友會說，干嘛不用動態基線或者智能基線。確實動態基線可以避免上面說的問題，但是動態基線就一定有意義嗎？我們來看上面有一個嚴重的IO LATCNCY基線告警。

IO延時出現了較為嚴重的波動，但是這有代表了什么含義呢？要不要發短信告警呢？運維人員收到短信要不要去處置呢？要不要對這個告警做閉環管理呢？我們還是搞不清楚，運維告警的意義一方面是發現系統的隱患，另外一方面是在系統出現嚴重故障前提前警示。似乎這個被標稱為“嚴重”的基線告警，對我們運維的幫助也沒有那么大。

從上面的例子我們看到了基線告警的局限性，簡單的單一指標異常為核心的基線告警并不能預示某類故障的發生，因此基線告警對于運維的作用就大大降低了。對基線告警進行簡單的升級，通過規則引擎構建故障模型，會有更好的效果。比如剛才的這個通過動態基線產生的IO延時基線異常，如果再疊加一些其他的條件，就可以構建出一個更有指向性的告警出來。比如IO延時基線異常，同時操作系統出現大量的IO方面的告警，或者出現多路徑鏈路切換，這樣的告警其指向性就更強了，而且告警的價值也大大提高了。

從另外一個角度來看，IO延時基線異常，同時IO吞吐量也大幅提高，某條關鍵SQL的執行時間也變長了，這種告警也更具有價值。也更值得做閉環管理。

通過故障模型替代基線告警，還有一個好處，那就是告警的指向性更強，因此當告警發生時，診斷問題的原因也變得簡單了很多，因為單一指標異常的可能原因過于復雜，大多數情況下讓人無法入手分析。而故障模型疊加了很多其他因素，因此故障的指向性也更強了，分析問題的時候也就更容易了。這也是現在D-SMART的基線告警并不推送到告警臺，而用故障模型告警替代的主要原因。?