?傳統(tǒng)的運(yùn)維監(jiān)控系統(tǒng)是以基線為核心判斷系統(tǒng)是否存在某個(gè)問題并進(jìn)行告警的。這種模式最大的問題就是基線如何設(shè)置十分困難，如果我們自己日常運(yùn)維的系統(tǒng)，我們對(duì)基線十分了解，那么我們可以給出相對(duì)合理的基線，實(shí)現(xiàn)較為精準(zhǔn)的告警。

不管如何設(shè)置，單指標(biāo)告警總是不準(zhǔn)確的，因?yàn)槲覀儫o(wú)法知道系統(tǒng)什么時(shí)候存在問題。我們以每秒邏輯讀這個(gè)指標(biāo)來(lái)做些分析吧。每秒邏輯讀這個(gè)指標(biāo)在二十年前監(jiān)控Oracle數(shù)據(jù)庫(kù)是否存在把系統(tǒng)撐爆的風(fēng)險(xiǎn)是十分有效的，那時(shí)候的服務(wù)器的CPU資源總是最緊張的。當(dāng)邏輯讀變得很高的時(shí)候，我們就需要告警讓DBA介入運(yùn)維了。這時(shí)候殺掉幾個(gè)大查詢往往就能挽救系統(tǒng)。實(shí)際上現(xiàn)在很多國(guó)產(chǎn)、開源數(shù)據(jù)庫(kù)運(yùn)維領(lǐng)域，這個(gè)指標(biāo)異常的監(jiān)測(cè)依然十分有效。

傳統(tǒng)的基線模式只能設(shè)置一個(gè)閾值來(lái)判斷邏輯讀是否異常，這個(gè)值往往會(huì)設(shè)置的不準(zhǔn)。因此我們會(huì)考慮采取一種新的方式來(lái)設(shè)置這個(gè)告警規(guī)則。

[metric,2189030]/[metric hour avg,2189030]>[num,$1] &&
[metric,2189030]>[bsl upper,2189030]*[num,$2]

上面的表達(dá)式的含義是當(dāng)邏輯讀是該指標(biāo)最近一小時(shí)平均值的N倍，并超過基線預(yù)警高值的M倍的時(shí)候產(chǎn)生該指標(biāo)的故障預(yù)警。這主要是為了避免設(shè)置不合理的閾值的時(shí)候產(chǎn)生閾值設(shè)置過高則有問題不報(bào)警，設(shè)置過低，則經(jīng)常誤報(bào)的問題。我們不需要再給系統(tǒng)設(shè)置一個(gè)預(yù)警的實(shí)際閾值了，而是根據(jù)系統(tǒng)中計(jì)算的當(dāng)前一小時(shí)平均值來(lái)做判斷。加上右面的這個(gè)條件是為了防止系統(tǒng)從閑時(shí)突然變忙碌時(shí)的一個(gè)臨界狀態(tài)。這個(gè)狀態(tài)往往是正常的。

通過這樣的改造之后，邏輯讀預(yù)警的誤報(bào)問題得到了很好的緩解，不過問題又來(lái)了。N值得設(shè)置依然十分具有挑戰(zhàn)性，設(shè)置的不合理依然會(huì)產(chǎn)生大量的誤報(bào)。如果DBA運(yùn)維的系統(tǒng)十分有限，而且對(duì)系統(tǒng)的這些指標(biāo)的波動(dòng)情況十分了解，那么設(shè)置合理的N還是不難做到的，不過在我們的用戶中并不總是這樣，很多運(yùn)維人員根本不知道該如何去設(shè)置這個(gè)參數(shù)。另外一方面，隨著運(yùn)維壓力日益增大，一個(gè)DBA可能要監(jiān)控上百個(gè)甚至數(shù)百個(gè)數(shù)據(jù)庫(kù)，每個(gè)數(shù)據(jù)庫(kù)都去這么玩，工作量太大了。

我們也一直想把異常檢測(cè)算法引入到故障模型中來(lái)，不過一直因?yàn)樗懔^大的問題，沒法大規(guī)模應(yīng)用。自從考慮采用異常檢測(cè)指標(biāo)化的策略后，這個(gè)問題才得到很好的解決。

對(duì)于指標(biāo)通過計(jì)算趨勢(shì)將各種狀態(tài)轉(zhuǎn)化為數(shù)字，比如3代表某個(gè)指標(biāo)急劇上升。那么我們就可以利用這個(gè)新的指標(biāo)來(lái)完成對(duì)上面的哪個(gè)表達(dá)式的改造了。

新的故障模型倍定義為當(dāng)每秒邏輯讀指標(biāo)超過一個(gè)絕對(duì)大的值（比如1000萬(wàn)、2000萬(wàn)等），或者每秒邏輯讀指標(biāo)急劇上升，并且每秒邏輯讀大于一個(gè)門檻值（比如50萬(wàn)），則說明系統(tǒng)的應(yīng)用可能存在一定的異常。這種異常很可能是應(yīng)用負(fù)載過大，也可能是應(yīng)用出現(xiàn)了BUG，或者某條關(guān)鍵SQL的執(zhí)行計(jì)劃出現(xiàn)了問題。

可能有些朋友還是有些不解，這里不也存在兩個(gè)參數(shù)嗎，似乎這個(gè)表達(dá)式的設(shè)置和以前并沒啥不同，不同的系統(tǒng)這些參數(shù)如何設(shè)置呢。實(shí)際上這兩個(gè)參數(shù)是補(bǔ)充型的，第一個(gè)設(shè)置為一個(gè)絕對(duì)高值，是為了避免指標(biāo)出現(xiàn)緩慢增長(zhǎng)，累計(jì)達(dá)到了一個(gè)較高的值，這個(gè)值對(duì)于當(dāng)前的硬件是致命的，因此比較容易設(shè)置，比如設(shè)置2路服務(wù)器為1000萬(wàn)，4路服務(wù)器為2000萬(wàn)，大體是能夠發(fā)揮作用的，而參數(shù)2是為了避免小負(fù)載波動(dòng)的門檻值，比如從1000增長(zhǎng)到20000，很可能被監(jiān)測(cè)為急劇增長(zhǎng)，不過這種增長(zhǎng)對(duì)系統(tǒng)來(lái)說是沒有太大影響的，為了避免此類現(xiàn)象誤報(bào)，需要設(shè)置一個(gè)門檻，一般來(lái)說10萬(wàn)，20萬(wàn)就可以避免了，設(shè)置起來(lái)也相當(dāng)容易。

經(jīng)過改造后，一旦出現(xiàn)異常負(fù)載，系統(tǒng)就能夠很好的告警了，而那些容易誤報(bào)的情況也不會(huì)再出現(xiàn)了。而且這個(gè)故障模型可以適應(yīng)于不同的應(yīng)用系統(tǒng)，不同類型的負(fù)載，不需要做個(gè)性化的調(diào)整。對(duì)于我們目前運(yùn)維大量的系統(tǒng)的DBA來(lái)說，就省了很多事。實(shí)際上只要在我們的普羅米修斯、Zabbix等系統(tǒng)中，將異常分析算法進(jìn)行指標(biāo)化改造，要想實(shí)現(xiàn)類似D-SMART中智能預(yù)警的功能也并不難。其重點(diǎn)是異常分析算法的設(shè)計(jì)與異常分析指標(biāo)化的設(shè)計(jì)。?