?基線預(yù)警數(shù)據(jù)庫運維監(jiān)控中的重要手段之一，通過基線發(fā)現(xiàn)系統(tǒng)中某些指標(biāo)存在的不合理波動，進(jìn)而提前預(yù)警，是一種數(shù)據(jù)庫運維監(jiān)控中最為常用的手段，也是目前大多數(shù)企業(yè)正在使用的主要監(jiān)控方案。

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

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

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

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

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

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

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

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