建站
咨詢
售后
建站咨詢
新聞中心
指標(biāo)異常檢測是基于對指標(biāo)歷史的分析的，傳統(tǒng)的指標(biāo)異常檢測是基于基線的。通過專家的經(jīng)驗或者根據(jù)某個系統(tǒng)平時的運行狀況，設(shè)定一個極限范圍，然后對指標(biāo)的高值、低值，均值等進行分析，發(fā)現(xiàn)其是否有違背基線的現(xiàn)象發(fā)生，如果存在則產(chǎn)生基線告警。這種簡單的基線告警算法目前還是大多數(shù)運維自動化系統(tǒng)中的主要方法。
創(chuàng)新互聯(lián)建站"三網(wǎng)合一"的企業(yè)建站思路。企業(yè)可建設(shè)擁有電腦版、微信版、手機版的企業(yè)網(wǎng)站。實現(xiàn)跨屏營銷，產(chǎn)品發(fā)布一步更新，電腦網(wǎng)絡(luò)+移動網(wǎng)絡(luò)一網(wǎng)打盡，滿足企業(yè)的營銷需求！創(chuàng)新互聯(lián)建站具備承接各種類型的成都網(wǎng)站建設(shè)、成都網(wǎng)站制作項目的能力。經(jīng)過10年的努力的開拓，為不同行業(yè)的企事業(yè)單位提供了優(yōu)質(zhì)的服務(wù)，并獲得了客戶的一致好評。
在運維實踐工作中，這種基線告警方法的效果并不好，主要有兩個原因，第一個是基線的設(shè)置都是個性化的，需要有經(jīng)驗的專家針對系統(tǒng)的個性化特點去設(shè)置才更有效，否則基線告警的準確性就不夠。而且隨著系統(tǒng)不斷地變化，基線也需要動態(tài)進行調(diào)整，否則基線告警的準確性會進一步降低。
而這種動態(tài)調(diào)整，如果是手工進行的，那么工作量就太大了。另外一個就是系統(tǒng)中的各種指標(biāo)也是存在一些畸變的，還有些指標(biāo)是單邊增長，并無上下限的，針對這樣的指標(biāo)的處理也需要有一定的個性化方法。
正是基于這個原因，指標(biāo)異常分析如果基于基線，就會存在實踐效果不佳的問題。如果我們對企業(yè)中的上百套系統(tǒng)使用幾種預(yù)置的基線模板，那么分析效果就十分有限。采用動態(tài)自動基線的方法是目前較為先進的方法。
其基本方法是根據(jù)某個指標(biāo)在過去的某段時間里的變化特點，經(jīng)過一段時間的數(shù)據(jù)積累之后，自動抽象出其變化特點，形成一個立體化的帶有時間延續(xù)性的基線特征。然后根據(jù)這個特征來判斷指標(biāo)是否異常。
這種基于復(fù)合算法的指標(biāo)異常分析方法避免了通過簡單的上下閾值設(shè)置的指標(biāo)基線那種呆板與教條化的問題，在實際應(yīng)用中更為有效。不過這種算法更為消耗算例，為了控制計算量，會設(shè)定一個參數(shù)，通過調(diào)整精度來降低算例需求。這和人臉識別的準確性與誤識別率類似，參數(shù)設(shè)置的嚴格了，算力要求高，誤判少，但是也可能會漏掉一些異常，設(shè)置的寬松一點，算力要求低，誤判就多了，遺漏的異常就會少一些。
因此這種異常檢測最大的問題就是準確率和告警數(shù)量之間的平衡。不管怎么樣，這種算法總是會遺漏一些問題的。另外一種情況是，如果某個指標(biāo)是新加入的，或者以前并無歷史數(shù)據(jù)，那么算法是無法發(fā)揮作用的。這種時候，需要一些其他的方法來進行輔助。
去年年底遇到的一個案例給了我一些啟示，在具有等待事件的某些數(shù)據(jù)庫系統(tǒng)(比如Oracle、PostgreSQL、達夢、Oceanbase、PolarDB等)中，利用等待事件分析結(jié)合指標(biāo)異常檢測，會取得更好的效果。
去年年底時候，一個客戶的系統(tǒng)突然比較慢，通過D-SMART發(fā)現(xiàn)這段時間有一個告警的出現(xiàn)比較頻繁。
12點多之后一直出現(xiàn)這個報警。而這個報價一般情況下最常見的就是三種情況，一種是存在rman備份作業(yè)，一種是存在大量的DIRECT PATH操作，包括SQL LOADER，expdp，第三種是有些SQL寫的不好，產(chǎn)生了大量的direct path read 。這三種情況最終都引起了存儲的IO性能問題，從而影響了數(shù)據(jù)庫的總體性能。
和用戶溝通后，用戶認為當(dāng)天不是周末，中午時間頂多有幾分鐘就能完成的歸檔日志備份，不可能有能夠持續(xù)幾十分鐘的備份作業(yè)存在。他們馬上登錄到系統(tǒng)中，查看了當(dāng)前正在執(zhí)行的備份作業(yè)，也沒有發(fā)現(xiàn)當(dāng)前系統(tǒng)中存在rman備份的進程。
不過他們通過智能診斷工具分析了一下，發(fā)現(xiàn)了當(dāng)時確實存在較大的RMAN流量。于是查了系統(tǒng)中的rman備份歷史數(shù)據(jù)的相關(guān)視圖，發(fā)現(xiàn)了一個剛剛被終止不久的未完成備份。與管理系統(tǒng)備份的人員溝通后確認因為這是一套新升級，更換了存儲和服務(wù)器，升級了數(shù)據(jù)庫的版本。因此備份任務(wù)剛剛配置，并且備份啟動時間被配置錯了，第一次備份時間應(yīng)該是本周日開始，沒想到今天中午就觸發(fā)了。他們發(fā)現(xiàn)后也立即終止了備份任務(wù)。
這件事當(dāng)時就很簡單的結(jié)束了，不過從上面的診斷分析中，我們發(fā)現(xiàn)有很多指標(biāo)因為缺乏足夠的歷史數(shù)據(jù)，從而導(dǎo)致我們的異常檢測無法進行。
因此當(dāng)時的智能診斷的分析結(jié)果中，IO延時的問題被排在第一位，而智能診斷工具根據(jù)一些其他的蛛絲馬跡，也發(fā)現(xiàn)了其中可能存在備份任務(wù)的問題。不過如果看這個結(jié)果，IO延時可能是主因，而實際上備份作業(yè)引發(fā)了IO問題，是問題的主因。
去年這個案例發(fā)生的時候，我們的基于等待事件的智能診斷工具還沒有開發(fā)完成，不過用戶的歷史數(shù)據(jù)已經(jīng)送到我們實驗室了。今天早上我在想寫點什么的時候，翻出了這個案例。于是我利用等待事件智能分析工具重新分析了一下。雖然使用了歷史抽樣數(shù)據(jù)來進行分析，不過等待事件分析還是很好的還原了當(dāng)時系統(tǒng)的現(xiàn)場，更為準確的發(fā)現(xiàn)了當(dāng)時系統(tǒng)存在的問題。這個診斷結(jié)論比上面的那個要準確多了。
如果是人工分析，有經(jīng)驗的專家可以根據(jù)自己的經(jīng)驗舉一反三，很容易切中要點。不過智能分析主要依賴于存在缺陷的數(shù)據(jù)和算法，因此很難做到人類專家那樣的綜合分析。在以往的運維事件中，我們也發(fā)現(xiàn)了，通過不同維度的多種渠道去做分析，然后匯總其結(jié)果，這種三明治算法往往能夠獲得較好的效果。
在利用指標(biāo)異常檢測做智能化診斷分析的時候，配合以同一時間段的等待事件分析，綜合其結(jié)果，那么可能會獲得更好的分析性能。我們隨后會開展這方面的研究與驗證工作。后續(xù)我再給大家分享實踐結(jié)果吧！
分享文章：聊聊指標(biāo)異常檢測與等待事件分析的相互補充作用
標(biāo)題網(wǎng)址：http://www.fisionsoft.com.cn/article/dhhhcsd.html
