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

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

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

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

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

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

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

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

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