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