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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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