在傳統(tǒng)運維監(jiān)控系統(tǒng)中加入新的預警能力
?傳統(tǒng)的運維監(jiān)控系統(tǒng)是以基線為核心判斷系統(tǒng)是否存在某個問題并進行告警的。這種模式最大的問題就是基線如何設置十分困難，如果我們自己日常運維的系統(tǒng)，我們對基線十分了解，那么我們可以給出相對合理的基線，實現(xiàn)較為精準的告警。
不管如何設置，單指標告警總是不準確的，因為我們無法知道系統(tǒng)什么時候存在問題。我們以每秒邏輯讀這個指標來做些分析吧。每秒邏輯讀這個指標在二十年前監(jiān)控Oracle數(shù)據(jù)庫是否存在把系統(tǒng)撐爆的風險是十分有效的，那時候的服務器的CPU資源總是最緊張的。當邏輯讀變得很高的時候，我們就需要告警讓DBA介入運維了。這時候殺掉幾個大查詢往往就能挽救系統(tǒng)。實際上現(xiàn)在很多國產(chǎn)、開源數(shù)據(jù)庫運維領域，這個指標異常的監(jiān)測依然十分有效。
傳統(tǒng)的基線模式只能設置一個閾值來判斷邏輯讀是否異常，這個值往往會設置的不準。因此我們會考慮采取一種新的方式來設置這個告警規(guī)則。
上面的表達式的含義是當邏輯讀是該指標最近一小時平均值的N倍，并超過基線預警高值的M倍的時候產(chǎn)生該指標的故障預警。這主要是為了避免設置不合理的閾值的時候產(chǎn)生閾值設置過高則有問題不報警，設置過低，則經(jīng)常誤報的問題。我們不需要再給系統(tǒng)設置一個預警的實際閾值了，而是根據(jù)系統(tǒng)中計算的當前一小時平均值來做判斷。加上右面的這個條件是為了防止系統(tǒng)從閑時突然變忙碌時的一個臨界狀態(tài)。這個狀態(tài)往往是正常的。
通過這樣的改造之后，邏輯讀預警的誤報問題得到了很好的緩解，不過問題又來了。N值得設置依然十分具有挑戰(zhàn)性，設置的不合理依然會產(chǎn)生大量的誤報。如果DBA運維的系統(tǒng)十分有限，而且對系統(tǒng)的這些指標的波動情況十分了解，那么設置合理的N還是不難做到的，不過在我們的用戶中并不總是這樣，很多運維人員根本不知道該如何去設置這個參數(shù)。另外一方面，隨著運維壓力日益增大，一個DBA可能要監(jiān)控上百個甚至數(shù)百個數(shù)據(jù)庫，每個數(shù)據(jù)庫都去這么玩，工作量太大了。
我們也一直想把異常檢測算法引入到故障模型中來，不過一直因為算力過大的問題，沒法大規(guī)模應用。自從考慮采用異常檢測指標化的策略后，這個問題才得到很好的解決。
對于指標通過計算趨勢將各種狀態(tài)轉化為數(shù)字，比如3代表某個指標急劇上升。那么我們就可以利用這個新的指標來完成對上面的哪個表達式的改造了。
新的故障模型倍定義為當每秒邏輯讀指標超過一個絕對大的值（比如1000萬、2000萬等），或者每秒邏輯讀指標急劇上升，并且每秒邏輯讀大于一個門檻值（比如50萬），則說明系統(tǒng)的應用可能存在一定的異常。這種異常很可能是應用負載過大，也可能是應用出現(xiàn)了BUG，或者某條關鍵SQL的執(zhí)行計劃出現(xiàn)了問題。
可能有些朋友還是有些不解，這里不也存在兩個參數(shù)嗎，似乎這個表達式的設置和以前并沒啥不同，不同的系統(tǒng)這些參數(shù)如何設置呢。實際上這兩個參數(shù)是補充型的，第一個設置為一個絕對高值，是為了避免指標出現(xiàn)緩慢增長，累計達到了一個較高的值，這個值對于當前的硬件是致命的，因此比較容易設置，比如設置2路服務器為1000萬，4路服務器為2000萬，大體是能夠發(fā)揮作用的，而參數(shù)2是為了避免小負載波動的門檻值，比如從1000增長到20000，很可能被監(jiān)測為急劇增長，不過這種增長對系統(tǒng)來說是沒有太大影響的，為了避免此類現(xiàn)象誤報，需要設置一個門檻，一般來說10萬，20萬就可以避免了，設置起來也相當容易。
經(jīng)過改造后，一旦出現(xiàn)異常負載，系統(tǒng)就能夠很好的告警了，而那些容易誤報的情況也不會再出現(xiàn)了。而且這個故障模型可以適應于不同的應用系統(tǒng)，不同類型的負載，不需要做個性化的調(diào)整。對于我們目前運維大量的系統(tǒng)的DBA來說，就省了很多事。實際上只要在我們的普羅米修斯、Zabbix等系統(tǒng)中，將異常分析算法進行指標化改造，要想實現(xiàn)類似D-SMART中智能預警的功能也并不難。其重點是異常分析算法的設計與異常分析指標化的設計。?
