建站
咨詢
售后
建站咨詢
新聞中心
這篇文章給大家介紹怎么設(shè)計(jì)告警系統(tǒng)，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。
創(chuàng)新互聯(lián)于2013年開始，先為西湖等服務(wù)建站，西湖等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為西湖企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
告警的本質(zhì)
告警對(duì)象
監(jiān)控的指標(biāo)和策略
理論與現(xiàn)實(shí)
異常檢測(cè)
基于曲線的平滑性檢測(cè)
基于絕對(duì)值的時(shí)間周期性
基于振幅的時(shí)間周期性
基于曲線回升的異常判斷
核心要點(diǎn)總結(jié)
告警的本質(zhì)
沒有多少系統(tǒng)的告警是設(shè)計(jì)得當(dāng)?shù)摹Ａ己玫母婢O(shè)計(jì)是一項(xiàng)非常困難的工作。
如何知道你收到的告警是糟糕的？多少次你收到了告警之后，立即就關(guān)掉了的？是不是成天被這些沒有什么卵用的東西給淹沒？
最常見的告警設(shè)置：cpu使用率超過90%，然后告警。這種設(shè)置在大部分場(chǎng)合下是沒有辦法提供高質(zhì)量的告警的。
高質(zhì)量的告警應(yīng)該是這樣的：每次收到之后你可以立即評(píng)估影響的范圍，并且每一個(gè)告警需要你做出分級(jí)響應(yīng)。所謂每個(gè)告警都應(yīng)該是，actionable的。
告警的實(shí)質(zhì)可以用下圖表明：
服務(wù)器的設(shè)計(jì)應(yīng)該是以這樣的無人值守為目的的。假設(shè)所有的運(yùn)維全部放假了，服務(wù)也能7*24自動(dòng)運(yùn)轉(zhuǎn)。
告警的實(shí)質(zhì)就是“把人當(dāng)服務(wù)用”。在一些事情還沒有辦法做到程序化執(zhí)行的時(shí)候，用告警通知人的方式去干預(yù)系統(tǒng)達(dá)到修正的目的。
一次告警就像一次服務(wù)調(diào)用一樣。如果告警了，但是收到告警的人并不需要做任何處理，那么這就是一種DDoS攻擊，攻擊的是運(yùn)維的幸福生活。
很多時(shí)候，告警通知人去干的事情是真的可以被自動(dòng)化掉的。比如服務(wù)器掛了，換一臺(tái)上來。
在小一點(diǎn)的系統(tǒng)里，可能就是停機(jī)一會(huì)，人工來處理換一臺(tái)冷備的機(jī)器上去。
大一點(diǎn)的系統(tǒng)，因?yàn)榉?wù)器多了，天天都掛可不行，必須是熱備的，系統(tǒng)自動(dòng)切換到備機(jī)。
再大一點(diǎn)的系統(tǒng)，因?yàn)榍袚Q實(shí)在太頻繁了，故障機(jī)的退庫，備機(jī)的保有都變成了一種管理負(fù)擔(dān)，那么可以和其他的運(yùn)維流程打通變成完全自動(dòng)化的系統(tǒng)。
只是因?yàn)闃I(yè)務(wù)處理不同階段，選擇不同的實(shí)現(xiàn)策略而已。業(yè)務(wù)量小，拿血肉當(dāng)機(jī)器用，有的時(shí)候更經(jīng)濟(jì)而已。當(dāng)然對(duì)于那個(gè)被當(dāng)成機(jī)器人來用的哥們來說，生活確實(shí)有點(diǎn)不公平。
告警對(duì)象
告警對(duì)象可以分為兩種：
業(yè)務(wù)規(guī)則監(jiān)控
系統(tǒng)可靠性監(jiān)控
對(duì)于業(yè)務(wù)規(guī)則監(jiān)控可以舉一個(gè)游戲的例子。
比如DNF的游戲角色在一定裝備的情況下，單次打擊的傷害輸出應(yīng)該是有一個(gè)上限，如果超過了就說明有作弊的情況。
又比如斗地主游戲里一個(gè)人的連勝場(chǎng)次是有一定上限的，每天的勝率是有一定上限，如果超出平均值太多就可能是作弊。
業(yè)務(wù)規(guī)則監(jiān)控的不是硬件，也不是軟件是否工作正常。而是軟件是否按照業(yè)務(wù)規(guī)則實(shí)現(xiàn)的，是否有漏洞。也可以理解為對(duì)“正確性”的監(jiān)控。
系統(tǒng)可靠性監(jiān)控是最常見的監(jiān)控形式，比如發(fā)現(xiàn)是不是服務(wù)器掛掉了，服務(wù)是不是過載了等等。
對(duì)于大部分后臺(tái)服務(wù)，系統(tǒng)可以抽象建模成這個(gè)樣子：
對(duì)于這樣的系統(tǒng)可以采集什么指標(biāo)？
請(qǐng)求數(shù)，請(qǐng)求到達(dá)速率
正常響應(yīng)數(shù)，正常響應(yīng)占比
錯(cuò)誤響應(yīng)數(shù)，錯(cuò)誤響應(yīng)占比
響應(yīng)延時(shí)
隊(duì)列長(zhǎng)度，排隊(duì)時(shí)間
實(shí)際的情況是，幾乎任何系統(tǒng)都不是孤立運(yùn)行的。而是這樣的：
一個(gè)DB會(huì)依賴于底層的cpu，內(nèi)存，磁盤等資源。一個(gè)Http服務(wù)會(huì)依賴于底層的DB服務(wù)。一個(gè)應(yīng)用會(huì)依賴于數(shù)個(gè)底層的RPC服務(wù)。
于是又多了幾個(gè)指標(biāo)：
資源A的調(diào)用量（比如CPU使用率）
資源B的調(diào)用量（比如內(nèi)存分配和釋放）
資源C的調(diào)用量（比如網(wǎng)絡(luò)發(fā)送包量）
...
這種層次結(jié)構(gòu)，一般來說簡(jiǎn)單來說可以分為四層：
產(chǎn)品策略和營銷：它們決定了根本的請(qǐng)求到達(dá)的速率
應(yīng)用層（更粗俗一點(diǎn)可以叫web層）：最上層的膠水
服務(wù)層：db，各種RPC服務(wù)，以及層層嵌套的服務(wù)
硬件層：cpu，內(nèi)存，磁盤，網(wǎng)絡(luò)
因?yàn)檫@樣的一個(gè)依賴層次。上一層對(duì)下一層的資源消耗量變成了下一層的請(qǐng)求數(shù)。
比如Http服務(wù)消耗了多少DB的資源，就對(duì)應(yīng)了DB服務(wù)需要處理多少請(qǐng)求數(shù)。DB繁忙與否取決于Http服務(wù)請(qǐng)求，Http服務(wù)請(qǐng)求繁忙與否取決于多少人打開客戶端，多少人打開客戶端又取決于產(chǎn)品策略和營銷活動(dòng)。
這種層次結(jié)構(gòu)決定了單純跟蹤一個(gè)指標(biāo)，比如絕對(duì)請(qǐng)求數(shù)，很難說明這一層的服務(wù)是否出現(xiàn)了故障。
有這么多層次，每層又有很多指標(biāo)可以采集。那么應(yīng)該采集什么指標(biāo)，用什么告警策略去告警呢？
最前面已經(jīng)提到了告警必須是actionable的，但是實(shí)際情況下只有這種綱領(lǐng)性要求仍然是不好操作的。至少可以提幾點(diǎn)不應(yīng)該做的事情：
不應(yīng)該用采集的難度決定你使用什么指標(biāo)去告警。很多情況下cpu使用率可能是最好采集的，但是未必是最值得告警的。
不要給運(yùn)維他們想要的告警，而是要做“真正”想要的告警。大部分情況下，人們告訴你的是一個(gè)解決方案。運(yùn)維告訴你它需要對(duì)db進(jìn)程的cpu使用率超過x%的時(shí)候告警，它給你的是一個(gè)他認(rèn)為最優(yōu)的解決方案。但是他真正想要的是知道db服務(wù)是否有異常，cpu使用率超過x%未必是最好的告訴你服務(wù)是否出現(xiàn)異常的指標(biāo)。
盲目地采集那些容易獲取的指標(biāo)，并隨意地設(shè)定閾值告警是大部分糟糕的告警質(zhì)量的根源。
監(jiān)控的指標(biāo)和策略
那到底應(yīng)該采集什么指標(biāo)呢？我認(rèn)為大部分的系統(tǒng)可靠性監(jiān)控不外乎三個(gè)目標(biāo)：
is the work getting done？系統(tǒng)是否在持續(xù)完成其設(shè)定的工作
is the user having good experience？用戶體驗(yàn)是否好
where is the problem/bottleneck？問題或者瓶頸在哪里
其中最核心最關(guān)鍵的是第一個(gè)問題，is the work getting done。對(duì)于數(shù)據(jù)庫來說，我們可以采集：
cpu 使用率
網(wǎng)絡(luò)帶寬大小
db請(qǐng)求數(shù)
db響應(yīng)數(shù)
db錯(cuò)誤響應(yīng)數(shù)
db請(qǐng)求延遲
顯然要回答一個(gè)db是否完成了其指定的工作，更應(yīng)該關(guān)注的指標(biāo)是這兩個(gè)：
db請(qǐng)求數(shù)的絕對(duì)量
db正確響應(yīng)相對(duì)請(qǐng)求數(shù)的占比
這兩個(gè)指標(biāo)相對(duì)于采集什么cpu使用率更能說明問題。不僅僅是db，各個(gè)層次的服務(wù)都可以用請(qǐng)求量和正確響應(yīng)占比來反映其工作狀況。
比如http請(qǐng)求數(shù)（對(duì)比http正確響應(yīng)數(shù)），比如app打開次數(shù)（對(duì)比服務(wù)端記錄的在線人數(shù)）等等。
為什么cpu使用率不能說明問題？大部分時(shí)候，我們并不關(guān)心cpu本身，而關(guān)心使用cpu為資源的服務(wù)。所以cpu使用率只是一種資源的請(qǐng)求數(shù)而已。
與請(qǐng)求數(shù)相關(guān)的一個(gè)概念是saturation（上限），當(dāng)上限達(dá)到的時(shí)候，處理開始排隊(duì)，延遲開始變長(zhǎng)，錯(cuò)誤率開始升高。
那么cpu使用率是不是能夠說明上限呢？cpu使用率的上限以100%記，那么90%開始告警不是很合理嗎？畢竟cpu 100%了幾乎可以等同于db無法正常處理請(qǐng)求了。
這種利用底層資源調(diào)用量，評(píng)估其是否達(dá)到上限的做法有兩個(gè)根本缺陷：
你無法知道上層服務(wù)可以把底層資源利用到什么程度
底層資源的 saturation 未必可以容易度量
具體來說，db是不是可以真的100%利用cpu是未知的。假如請(qǐng)求里鎖，或者sleep，那么也許cpu永遠(yuǎn)也無法達(dá)到100%，90%可能就是極限了。
而且現(xiàn)代的cpu是多核的，如果請(qǐng)求處理只能利用單核，處理在多個(gè)核之間跳躍，對(duì)于一個(gè)核來說永遠(yuǎn)也不會(huì)一直保持100%。
對(duì)于cpu可能其上限真的有一個(gè)100%的值。但是對(duì)于很多非硬件的服務(wù)，比如你是一個(gè)登陸服務(wù)，依賴于一個(gè)db。那么這個(gè)db每秒可以處理的不同sql組合數(shù)是很難度量的，絕非和磁盤一樣有一個(gè)mb/s的極限絕對(duì)值可以做為對(duì)比。
而且度量底層資源的使用還有一個(gè)缺陷是你無法枚舉出所有依賴的資源的。所以與其這么繞彎子地通過底層資源來間接監(jiān)控上層服務(wù)是否正常，還不如直接測(cè)量work是不是getting done呢。
對(duì)于第二個(gè)問題，is the user having good experience？可以采集的指標(biāo)為
平均排隊(duì)時(shí)間，平均總響應(yīng)延遲
99/95/90 percentile的排隊(duì)時(shí)間，99/95/90 percentile的響應(yīng)延遲
這里的用戶不一定是指人或者玩家，可能是上一層的服務(wù)調(diào)用方，另外一個(gè)系統(tǒng)。
第三個(gè)問題就是所謂的故障定位。要是人工來做的話，最常見的做法是收到了告警，然后登陸CRT，開始敲各種命令查找原因。
對(duì)于系統(tǒng)來說，最合適的做法不是出了問題再去執(zhí)行一堆命令，而是：
每個(gè)層次都對(duì)自己做告警
頂層服務(wù)出了告警觸發(fā)自動(dòng)定位程序
按照服務(wù)的依賴關(guān)系和大致的時(shí)間范圍，定位到告警之間的關(guān)聯(lián)，從而找到出問題或者瓶頸的地方
當(dāng)然實(shí)際情況是很復(fù)雜的。很多原因和結(jié)果是互為因果的。兩個(gè)告警是兩個(gè)現(xiàn)象，還是一個(gè)原因一個(gè)現(xiàn)象實(shí)際上很難說得清楚。
從告警算法的角度來講，對(duì)成功請(qǐng)求率，或者平均響應(yīng)延遲做告警是非常容易的。靜態(tài)閾值大家看不起，覺得簡(jiǎn)單。但是大部分告警用靜態(tài)閾值就可以解決問題。
理論與現(xiàn)實(shí)
那告警要不要高難度的算法？
我的觀點(diǎn)是采集到了正確的指標(biāo)，是不需要復(fù)雜算法的，就是靜態(tài)閾值都可以搞得定。但是至少有三種場(chǎng)合需要算法：
無法直接采集到錯(cuò)誤數(shù)：需要對(duì)錯(cuò)誤日志的自動(dòng)分類
無法直接采集到請(qǐng)求成功率：需要對(duì)請(qǐng)求數(shù)或響應(yīng)數(shù)的絕對(duì)值做異常檢測(cè)
只有總數(shù)，無法采集到其中的每個(gè)細(xì)分構(gòu)成項(xiàng)的占比：需要對(duì)參與的factor進(jìn)行算法擬合
其實(shí)這三項(xiàng)都是一個(gè)主題的，當(dāng)你無法直接獲取到告警所需的指標(biāo)的時(shí)候，事情會(huì)變得復(fù)雜很多。
有一個(gè)比喻是：最近NASA宣布的地球?qū)\生兄弟Kepler 452b。如果我們的探測(cè)器可以跑到1400光年之外，發(fā)現(xiàn)他將是非常容易的事情。
正是因?yàn)橹苯荧@得數(shù)據(jù)非常困難，所以科學(xué)家才需要根據(jù)行星阻擋恒星時(shí)引起的亮度變化（所謂掩星法）來發(fā)現(xiàn)這些遙遠(yuǎn)的星球。
采集所需的指標(biāo)的困難可能是幾方面的因素。一種原因是采集本身是非常消耗資源的事情。
比如獲取每個(gè)MySQL查詢所消耗的cpu。跟蹤每個(gè)請(qǐng)求處理過程是不可能的。這個(gè)時(shí)候就需要算法的幫助了，可以仔細(xì)看一下vividcortex的視頻：
http://www.youtube.com/watch?v=szAfGjwLO8k
更多情況是采集指標(biāo)困難是D/O分離造成的溝通問題，運(yùn)維需要的指標(biāo)需要開發(fā)去埋點(diǎn)，而開發(fā)埋點(diǎn)的地方又需要運(yùn)維去做告警。很多時(shí)候退而求其次就會(huì)造成，有什么指標(biāo)就用什么指標(biāo)的狀況。
比如雖然沒有請(qǐng)求響應(yīng)的錯(cuò)誤數(shù)，但是錯(cuò)誤基本上都會(huì)有錯(cuò)誤日志記錄，根據(jù)錯(cuò)誤日志滾動(dòng)的快慢可以大致知道是不是出了問題。
這就引入了一個(gè)非常困難的日志分類問題，什么日志代表了正常，什么日志代表了異常，異常又非了哪些類型？
這個(gè)方面算法做得好的是summo logic公司：
https://www.sumologic.com/
為什么這種opsdev（嘲諷devops那）公司如此熱衷于算法？
對(duì)于他們來說好處是顯而易見的，客戶需要做的改動(dòng)越少，接入成本越低，客戶面就越廣。
但是拿機(jī)器算法去挖掘海量日志真的是回答：is the work getting done？的最佳手段？
顯然不是。這就是大炮打蚊子。日志的存在是用于解決問題，而不是有了海量日志了，如何用好“它們”變成了問題本身。
第三類情況是沒有辦法采集到請(qǐng)求成功率，只能對(duì)絕對(duì)的處理成功的量。只有這類數(shù)據(jù)要告警，就無法做簡(jiǎn)單的靜態(tài)閾值了。
對(duì)于延遲，一般可以定一個(gè)業(yè)務(wù)上可以接受的延遲上限。對(duì)于成功率，也可以定一個(gè)可接受的成功率上限。但是對(duì)于絕對(duì)的處理量，是沒有辦法簡(jiǎn)單地比較一個(gè)靜態(tài)閾值就可以判斷是正常還是異常的。
在討論如何實(shí)現(xiàn)之前，再強(qiáng)調(diào)兩點(diǎn)：
處理成功的量不是度量is work getting done的最佳指標(biāo)。費(fèi)事費(fèi)力去搞算法，不如直接把成功率指標(biāo)給采集了
處理成功的量，還取決于請(qǐng)求數(shù)。而請(qǐng)求數(shù)根本上是取決于上層服務(wù)。
你是一個(gè)dba，發(fā)現(xiàn)db的每秒處理的請(qǐng)求數(shù)陡降了。這說明是db故障了？還是app故障了？
都有可能……最最上層是產(chǎn)品和營銷。
你發(fā)現(xiàn)一個(gè)業(yè)務(wù)的注冊(cè)量相對(duì)前幾天變少了，這個(gè)是不是說明注冊(cè)服務(wù)出問題了？
也許是產(chǎn)品太爛了，游戲根本沒有人來玩。也可能是營銷手段的營銷，不送金幣了，玩家沒積極性了。
異常檢測(cè)
只有請(qǐng)求數(shù)，沒有參考的上限值（saturation），也沒有成功率，沒有失敗率，怎么檢測(cè)異常？
上圖的黃線是昨天的值，綠線是今天的值，大部分服務(wù)監(jiān)控的曲線圖都長(zhǎng)這樣?？梢缘贸鏊膫€(gè)思路：
曲線平滑：故障一般是對(duì)近期趨勢(shì)的一個(gè)破壞，視覺上來說就是不平滑
絕對(duì)值的時(shí)間周期性：兩條曲線幾乎重合
波動(dòng)的時(shí)間周期性：假設(shè)兩個(gè)曲線不重合，在相同時(shí)間點(diǎn)的波動(dòng)趨勢(shì)和振幅也是類似的
有一個(gè)長(zhǎng)度可觀的坑：當(dāng)曲線開始回升到歷史范圍的時(shí)候，一般可以確認(rèn)這個(gè)時(shí)間段是真的故障了
從這四種直覺展開，可以得出各種或復(fù)雜或簡(jiǎn)單的算法。下面要講的算法都是非常簡(jiǎn)單的，無需很高深的數(shù)學(xué)知識(shí)。
基于曲線的平滑性檢測(cè)
這種檢測(cè)的根據(jù)是在一個(gè)最近的時(shí)間窗口，比如1個(gè)小時(shí)。曲線會(huì)遵循某種趨勢(shì)，而新的數(shù)據(jù)點(diǎn)打破了這種趨勢(shì)，使得曲線不光滑了。
也就是說，這種檢測(cè)利用的是時(shí)間序列的temporal dependency，T對(duì)于T-1有很強(qiáng)的趨勢(shì)依賴性。
業(yè)務(wù)邏輯上來說，8:00 有很多人登陸，8:01 也有很多人來登陸的概率是很高的，因?yàn)槲藖淼顷懙囊蛩厥怯泻軓?qiáng)的慣性的。
但是7.1很多人來登陸，8.1也有很多人來登陸的慣性就要差很多。
基于近期趨勢(shì)做告警，就需要對(duì)曲線的趨勢(shì)進(jìn)行擬合。
擬合有兩種方式，moving average 或者 regression。這兩種擬合方式有不同的bias（傾向）。
這就是一種moving average的算法圖，叫做exponentially weighted moving average。它的計(jì)算非常簡(jiǎn)單
x是實(shí)際值，s是ewma計(jì)算出來的平均值。也就是下一點(diǎn)的平均值是由上一點(diǎn)的平均值，加上當(dāng)前點(diǎn)的實(shí)際值修正而來。
這個(gè)修正的比例，就取決月這個(gè)alpha的decay factor的大小。視覺上來說就是ewma曲線是否緊跟實(shí)際曲線，也就是平滑程度。
有了平均值之后可以計(jì)算方差，方差乘以一定的倍數(shù)可以得出對(duì)于振幅的容忍范圍。比較實(shí)際的值是否超出了這個(gè)范圍就可以知道是否可以告警了。
超出了上界，可能是突然用戶量突然激增了。超出了下屆，可能是營銷活動(dòng)結(jié)束了，用戶快速離開，也可能是光纖斷了，玩家掉線了。
想要了解更多關(guān)于ewma的算法細(xì)節(jié)：關(guān)注Baron Schwartz：
http://www.slideshare.net/vividcortex/statistical-anomaly-detection
moving average認(rèn)為曲線是趨向于歷史的，如果曲線的勢(shì)頭是上升，那么它認(rèn)為下一個(gè)點(diǎn)應(yīng)該是開始下降的。
regression認(rèn)為曲線是趨向于未來的，如果曲線的勢(shì)頭是上升，那么它認(rèn)為下一個(gè)點(diǎn)應(yīng)該是保持這個(gè)上升勢(shì)頭。
還有更復(fù)雜的模型是綜合了moving average和regression的。無論是哪種算法，用過去10分鐘預(yù)測(cè)下10分鐘是不可能精確的。如果這種預(yù)測(cè)可以精確，那么股神早就誕生了。
使用moving average，可能會(huì)掩蓋故障產(chǎn)生的下降（因?yàn)槠鋌ias是下降）
如果使用regression，那么又有可能把沒有上升得那么快當(dāng)成故障了（因?yàn)槠鋌ias是上升）。
這種基于近期趨勢(shì)計(jì)算方差的算法還有一個(gè)缺陷是當(dāng)前面幾個(gè)點(diǎn)振動(dòng)很大的時(shí)候，方差值會(huì)被搞大。后面的故障就被掩蓋了，使得連續(xù)的故障點(diǎn)無法被檢測(cè)到。
其實(shí)也就是算法對(duì)于什么是正常是沒有概念的，它認(rèn)為過去的歷史就是正常。如果過去幾分鐘處于故障中，那么故障的曲線就是正常。
實(shí)際使用中發(fā)現(xiàn)這種基于曲線平滑度的算法的優(yōu)點(diǎn)有
依賴的數(shù)據(jù)少，只需要近期的歷史，不依賴于周期性
非常敏感，歷史如果波動(dòng)很小，方差就很小，容忍的波動(dòng)范圍也會(huì)非常小
缺點(diǎn)也是顯著的：
過于敏感，容易誤報(bào)。因?yàn)榉讲顣?huì)隨著異常點(diǎn)的引入而變大，所以很難使用連續(xù)三點(diǎn)才告警這樣的策略
業(yè)務(wù)曲線可能自身有規(guī)律性的陡增和陡降
最佳的使用方式是不用一根曲線做告警。結(jié)合幾條相關(guān)的曲線，如果同時(shí)出現(xiàn)平滑度破壞的情況，而且與業(yè)務(wù)規(guī)律的趨勢(shì)相背離（比如在線人數(shù)降低，登陸請(qǐng)求數(shù)增高）則可以認(rèn)定為業(yè)務(wù)出現(xiàn)故障。
基于絕對(duì)值的時(shí)間周期性
上圖中不同的顏色代表了不同日期的曲線。
很多監(jiān)控曲線都有這樣以一天為周期的周期性（早上4點(diǎn)最低，晚上11點(diǎn)最高之類的）。一種利用時(shí)間周期性的最簡(jiǎn)單的算法：
min(14 days history) * 0.6
對(duì)歷史14天的曲線取最小值。怎么個(gè)取最小值的方法？
對(duì)于12:05分，有14天對(duì)應(yīng)的點(diǎn)，取最小值。對(duì)于12:06分，有14天對(duì)應(yīng)的點(diǎn)，取最小值。這樣可以得出一條一天的曲線。
然后對(duì)這個(gè)曲線整體乘以0.6。如果幾天的曲線低于這條參考線則告警。
這其實(shí)是一種靜態(tài)閾值告警的升級(jí)版，動(dòng)態(tài)閾值告警。
過去靜態(tài)閾值是一個(gè)根據(jù)歷史經(jīng)驗(yàn)拍腦袋的產(chǎn)物。用這個(gè)算法，其實(shí)是把同時(shí)間點(diǎn)的歷史值做為依據(jù)，計(jì)算出一個(gè)最不可能的下界。同時(shí)閾值不是唯一的一個(gè)，而是每個(gè)時(shí)間點(diǎn)有一個(gè)。如果1分鐘一個(gè)點(diǎn)，一天中就有1440個(gè)下界閾值。
實(shí)際使用中0.6當(dāng)然還是要酌情調(diào)整的。而且一個(gè)嚴(yán)重的問題是如果14天歷史中有停機(jī)發(fā)布或者故障，那么最小值會(huì)受到影響。
也就是說不能把歷史當(dāng)成正常，而是要把歷史剔除掉異常值之后再進(jìn)行計(jì)算。一個(gè)務(wù)實(shí)的近似的做法是取第二小的值。
為了讓告警更加精確，可以累積計(jì)算實(shí)際曲線和參考曲線的差值之和。也就是相對(duì)于參考曲線下跌的面積。這個(gè)面積超過一定的值則告警。
對(duì)于深度下跌，則累積幾個(gè)點(diǎn)就可以告警。對(duì)于淺度下跌，那么多累幾個(gè)點(diǎn)也可以告警出來。
翻譯成人話就是，一下在跌了很多，則很有可能是故障了。或者連續(xù)好久都偏離正常值，那么也很有可能是出問題了。
優(yōu)點(diǎn)：
計(jì)算簡(jiǎn)單
可以確保發(fā)現(xiàn)大的故障，出了告警一定是大問題，可以直接打電話
缺點(diǎn)：
依賴周期性的歷史數(shù)據(jù)，計(jì)算量大，而且無法對(duì)新接入的曲線告警
非常不敏感，小波動(dòng)無法發(fā)現(xiàn)
基于振幅的時(shí)間周期性
有些時(shí)候曲線是有周期性，但是兩個(gè)周期的曲線相疊加是不重合的。
比如上圖這樣的，曲線整體的趨勢(shì)是網(wǎng)上的。兩個(gè)周期的曲線一疊加，一個(gè)會(huì)比另外一個(gè)高出一頭。對(duì)于這種情況，利用絕對(duì)值告警就會(huì)有問題。
比如今天是10.1日，放假第一天。過去14天的歷史曲線必然會(huì)比今天的曲線低很多。那么今天出了一個(gè)小故障，曲線下跌了，相對(duì)于過去14天的曲線仍然是高很多的。這樣的故障如何能夠檢測(cè)得出來？
一個(gè)直覺的說法是，兩個(gè)曲線雖然不一樣高，但是“長(zhǎng)得差不多”。那么怎么利用這種“長(zhǎng)得差不多”呢？那就是振幅了。
與其用x(t)的值，不如用x(t) - x(t-1)的值，也就是把絕對(duì)值變成變化速度?？梢灾苯永眠@個(gè)速度值，也可以是 x(t) - x(t-1) 再除以 x(t-1)，也就是一個(gè)速度相對(duì)于絕對(duì)值的比率。
比如t時(shí)刻的在線900人，t-1時(shí)刻的在線是1000人，那么可以計(jì)算出掉線人數(shù)是10%。這個(gè)掉線比率在歷史同時(shí)刻是高還是低？那么就和前面一樣處理了。
實(shí)際使用中有兩個(gè)技巧：可以是x(t) - x(t-1），也可以是x(t) - x(t-5）等值?？缍仍酱螅娇梢詸z測(cè)出一些緩慢下降的情況。
另外一個(gè)技巧是可以計(jì)算x(t) -x(t-2)，以及x(t+1) - x(t-1)，如果兩個(gè)值都異常則認(rèn)為是真的異常，可以避免一個(gè)點(diǎn)的數(shù)據(jù)缺陷問題。
優(yōu)點(diǎn)：
比絕對(duì)值要敏感
利用了時(shí)間周期性，規(guī)避了業(yè)務(wù)曲線自身的周期性陡降
缺點(diǎn)：
要求原曲線是光滑的
周期性陡降的時(shí)間點(diǎn)必須重合，否則誤警
按百分比計(jì)算容易在低峰時(shí)期誤警
陡降不一定代表故障，由上層服務(wù)波動(dòng)引起的沖高再回落的情況時(shí)有發(fā)生
這種異常告警算法是比較優(yōu)秀的。缺點(diǎn)也很多。所以可以進(jìn)行一些修補(bǔ)湊合用。
為了避免低峰時(shí)期，基于振幅百分比容易誤警，可以加入絕對(duì)振幅的下限。
業(yè)務(wù)上來說，就是小波動(dòng)如果相對(duì)比率大，但是絕對(duì)影響范圍小也是沒關(guān)系的。對(duì)于沖高回落的問題，可以判斷一下沖高的情況，對(duì)于沖高之后屏蔽一段時(shí)間。
基于曲線回升的異常判斷
當(dāng)我們看見圖2的時(shí)候比圖1更確認(rèn)是故障了。為什么？
因?yàn)閳D2中有一個(gè)明顯的回升。算法其實(shí)和人眼一樣。如果多等幾個(gè)時(shí)間點(diǎn)，發(fā)現(xiàn)曲線回升了可以更很準(zhǔn)確地判斷“曾經(jīng)”有一個(gè)故障。
但是這種基于回升的異常檢測(cè)是沒有多少“告警”意義上的機(jī)制的。
告警的作用就是讓人參與干預(yù)，去幫助曲線回升。如果曲線已經(jīng)開始回升，再告警不是事后諸葛了嗎？
這種檢測(cè)的意義在于機(jī)器復(fù)制告警的確認(rèn)。
當(dāng)我們需要統(tǒng)計(jì)誤警率，漏警率的時(shí)候，用另外一種視角的算法重新跑一遍可以統(tǒng)計(jì)出很多原算法的問題。
同時(shí)也可以用半自動(dòng)化的方式建立一個(gè)歷史故障的樣本庫。這個(gè)樣本庫可以變成更復(fù)雜的機(jī)器學(xué)習(xí)算法的訓(xùn)練集。
核心要點(diǎn)：
高質(zhì)量的告警是actionable的
不應(yīng)該用采集的難度決定你使用什么指標(biāo)去告警
不要?jiǎng)e人做什么告警，你就做什么，要做“真正”有用的告警：特別是cpu使用率告警
is work getting done：請(qǐng)求數(shù) + 成功率
is the user having good experience：響應(yīng)延遲
只要采集對(duì)了指標(biāo)，大部分時(shí)候告警不需要復(fù)雜算法
基于算法的異常檢測(cè)：算法不難，實(shí)在必要也是可以做到的
關(guān)于怎么設(shè)計(jì)告警系統(tǒng)就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。
網(wǎng)站欄目：怎么設(shè)計(jì)告警系統(tǒng)
本文URL：http://fisionsoft.com.cn/article/gjdgei.html
