指標(biāo)異常檢測是基于對指標(biāo)歷史的分析的，傳統(tǒng)的指標(biāo)異常檢測是基于基線的。通過專家的經(jīng)驗(yàn)或者根據(jù)某個系統(tǒng)平時的運(yùn)行狀況，設(shè)定一個極限范圍，然后對指標(biāo)的高值、低值，均值等進(jìn)行分析，發(fā)現(xiàn)其是否有違背基線的現(xiàn)象發(fā)生，如果存在則產(chǎn)生基線告警。這種簡單的基線告警算法目前還是大多數(shù)運(yùn)維自動化系統(tǒng)中的主要方法。

在運(yùn)維實(shí)踐工作中，這種基線告警方法的效果并不好，主要有兩個原因，第一個是基線的設(shè)置都是個性化的，需要有經(jīng)驗(yàn)的專家針對系統(tǒng)的個性化特點(diǎn)去設(shè)置才更有效，否則基線告警的準(zhǔn)確性就不夠。而且隨著系統(tǒng)不斷地變化，基線也需要動態(tài)進(jìn)行調(diào)整，否則基線告警的準(zhǔn)確性會進(jìn)一步降低。

而這種動態(tài)調(diào)整，如果是手工進(jìn)行的，那么工作量就太大了。另外一個就是系統(tǒng)中的各種指標(biāo)也是存在一些畸變的，還有些指標(biāo)是單邊增長，并無上下限的，針對這樣的指標(biāo)的處理也需要有一定的個性化方法。

正是基于這個原因，指標(biāo)異常分析如果基于基線，就會存在實(shí)踐效果不佳的問題。如果我們對企業(yè)中的上百套系統(tǒng)使用幾種預(yù)置的基線模板，那么分析效果就十分有限。采用動態(tài)自動基線的方法是目前較為先進(jìn)的方法。

其基本方法是根據(jù)某個指標(biāo)在過去的某段時間里的變化特點(diǎn)，經(jīng)過一段時間的數(shù)據(jù)積累之后，自動抽象出其變化特點(diǎn)，形成一個立體化的帶有時間延續(xù)性的基線特征。然后根據(jù)這個特征來判斷指標(biāo)是否異常。

這種基于復(fù)合算法的指標(biāo)異常分析方法避免了通過簡單的上下閾值設(shè)置的指標(biāo)基線那種呆板與教條化的問題，在實(shí)際應(yīng)用中更為有效。不過這種算法更為消耗算例，為了控制計(jì)算量，會設(shè)定一個參數(shù)，通過調(diào)整精度來降低算例需求。這和人臉識別的準(zhǔn)確性與誤識別率類似，參數(shù)設(shè)置的嚴(yán)格了，算力要求高，誤判少，但是也可能會漏掉一些異常，設(shè)置的寬松一點(diǎn)，算力要求低，誤判就多了，遺漏的異常就會少一些。

因此這種異常檢測最大的問題就是準(zhǔn)確率和告警數(shù)量之間的平衡。不管怎么樣，這種算法總是會遺漏一些問題的。另外一種情況是，如果某個指標(biāo)是新加入的，或者以前并無歷史數(shù)據(jù)，那么算法是無法發(fā)揮作用的。這種時候，需要一些其他的方法來進(jìn)行輔助。

去年年底遇到的一個案例給了我一些啟示，在具有等待事件的某些數(shù)據(jù)庫系統(tǒng)(比如Oracle、PostgreSQL、達(dá)夢、Oceanbase、PolarDB等)中，利用等待事件分析結(jié)合指標(biāo)異常檢測，會取得更好的效果。

去年年底時候，一個客戶的系統(tǒng)突然比較慢，通過D-SMART發(fā)現(xiàn)這段時間有一個告警的出現(xiàn)比較頻繁。

12點(diǎn)多之后一直出現(xiàn)這個報警。而這個報價一般情況下最常見的就是三種情況，一種是存在rman備份作業(yè)，一種是存在大量的DIRECT PATH操作，包括SQL LOADER，expdp，第三種是有些SQL寫的不好，產(chǎn)生了大量的direct path read 。這三種情況最終都引起了存儲的IO性能問題，從而影響了數(shù)據(jù)庫的總體性能。

和用戶溝通后，用戶認(rèn)為當(dāng)天不是周末，中午時間頂多有幾分鐘就能完成的歸檔日志備份，不可能有能夠持續(xù)幾十分鐘的備份作業(yè)存在。他們馬上登錄到系統(tǒng)中，查看了當(dāng)前正在執(zhí)行的備份作業(yè)，也沒有發(fā)現(xiàn)當(dāng)前系統(tǒng)中存在rman備份的進(jìn)程。

不過他們通過智能診斷工具分析了一下，發(fā)現(xiàn)了當(dāng)時確實(shí)存在較大的RMAN流量。于是查了系統(tǒng)中的rman備份歷史數(shù)據(jù)的相關(guān)視圖，發(fā)現(xiàn)了一個剛剛被終止不久的未完成備份。與管理系統(tǒng)備份的人員溝通后確認(rèn)因?yàn)檫@是一套新升級，更換了存儲和服務(wù)器，升級了數(shù)據(jù)庫的版本。因此備份任務(wù)剛剛配置，并且備份啟動時間被配置錯了，第一次備份時間應(yīng)該是本周日開始，沒想到今天中午就觸發(fā)了。他們發(fā)現(xiàn)后也立即終止了備份任務(wù)。

這件事當(dāng)時就很簡單的結(jié)束了，不過從上面的診斷分析中，我們發(fā)現(xiàn)有很多指標(biāo)因?yàn)槿狈ψ銐虻臍v史數(shù)據(jù)，從而導(dǎo)致我們的異常檢測無法進(jìn)行。

因此當(dāng)時的智能診斷的分析結(jié)果中，IO延時的問題被排在第一位，而智能診斷工具根據(jù)一些其他的蛛絲馬跡，也發(fā)現(xiàn)了其中可能存在備份任務(wù)的問題。不過如果看這個結(jié)果，IO延時可能是主因，而實(shí)際上備份作業(yè)引發(fā)了IO問題，是問題的主因。

去年這個案例發(fā)生的時候，我們的基于等待事件的智能診斷工具還沒有開發(fā)完成，不過用戶的歷史數(shù)據(jù)已經(jīng)送到我們實(shí)驗(yàn)室了。今天早上我在想寫點(diǎn)什么的時候，翻出了這個案例。于是我利用等待事件智能分析工具重新分析了一下。雖然使用了歷史抽樣數(shù)據(jù)來進(jìn)行分析，不過等待事件分析還是很好的還原了當(dāng)時系統(tǒng)的現(xiàn)場，更為準(zhǔn)確的發(fā)現(xiàn)了當(dāng)時系統(tǒng)存在的問題。這個診斷結(jié)論比上面的那個要準(zhǔn)確多了。

如果是人工分析，有經(jīng)驗(yàn)的專家可以根據(jù)自己的經(jīng)驗(yàn)舉一反三，很容易切中要點(diǎn)。不過智能分析主要依賴于存在缺陷的數(shù)據(jù)和算法，因此很難做到人類專家那樣的綜合分析。在以往的運(yùn)維事件中，我們也發(fā)現(xiàn)了，通過不同維度的多種渠道去做分析，然后匯總其結(jié)果，這種三明治算法往往能夠獲得較好的效果。

在利用指標(biāo)異常檢測做智能化診斷分析的時候，配合以同一時間段的等待事件分析，綜合其結(jié)果，那么可能會獲得更好的分析性能。我們隨后會開展這方面的研究與驗(yàn)證工作。后續(xù)我再給大家分享實(shí)踐結(jié)果吧！