摘要：至少可以提幾點(diǎn)不應(yīng)該做的事情不應(yīng)該用采集的難度決定你使用什么指標(biāo)去告警。

沒(méi)有多少系統(tǒng)的告警是設(shè)計(jì)得當(dāng)?shù)摹Ａ己玫母婢O(shè)計(jì)是一項(xiàng)非常困難的工作。如何知道你收到的告警是糟糕的？多少次你收到了告警之后，立即就關(guān)掉了的？是不是成天被這些然而并沒(méi)有什么卵用的東西給淹沒(méi)？最常見(jiàn)的告警設(shè)置：cpu使用率超過(guò)90%，然后告警。這種設(shè)置在大部分場(chǎng)合下是沒(méi)有辦法提供高質(zhì)量的告警的。

高質(zhì)量的告警應(yīng)該是這樣的：每次收到之后你可以立即評(píng)估影響的范圍，并且每一個(gè)告警需要你做出分級(jí)響應(yīng)。所謂每個(gè)告警都應(yīng)該是，actionable的。

告警的實(shí)質(zhì)可以用下圖表明：

服務(wù)器的設(shè)計(jì)應(yīng)該是以這樣的無(wú)人值守為目的的。假設(shè)所有的運(yùn)維全部放假了，服務(wù)也能7*24自動(dòng)運(yùn)轉(zhuǎn)。

告警的實(shí)質(zhì)就是“把人當(dāng)服務(wù)用”。在一些事情還沒(méi)有辦法做到程序化執(zhí)行的時(shí)候，用告警通知人的方式去干預(yù)系統(tǒng)達(dá)到修正的目的。一次告警就像一次服務(wù)調(diào)用一樣。如果告警了，但是收到告警的人并不需要做任何處理，那么這就是一種DDoS攻擊，攻擊的是運(yùn)維的幸福生活。

很多時(shí)候，告警通知人去干的事情是真的可以被自動(dòng)化掉的。比如服務(wù)器掛了，換一臺(tái)上來(lái)。在小一點(diǎn)的系統(tǒng)里，可能就是停機(jī)一會(huì)，人工來(lái)處理?yè)Q一臺(tái)冷備的機(jī)器上去。大一點(diǎn)的系統(tǒng)，因?yàn)榉?wù)器多了，天天都掛可不行，必須是熱備的，系統(tǒng)自動(dòng)切換到備機(jī)。再大一點(diǎn)的系統(tǒng)，因?yàn)榍袚Q實(shí)在太頻繁了，故障機(jī)的退庫(kù)，備機(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ī)器人來(lái)用的哥們來(lái)說(shuō)，生活確實(shí)有點(diǎn)不公平。

告警對(duì)象可以分為兩種：

業(yè)務(wù)規(guī)則監(jiān)控

系統(tǒng)可靠性監(jiān)控

對(duì)于業(yè)務(wù)規(guī)則監(jiān)控可以舉一個(gè)游戲的例子。比如DNF的游戲角色在一定裝備的情況下，單次打擊的傷害輸出應(yīng)該是有一個(gè)上限，如果超過(guò)了就說(shuō)明有作弊的情況。又比如斗地主游戲里一個(gè)人的連勝場(chǎng)次是有一定上限的，每天的勝率是有一定上限，如果超出平均值太多就可能是作弊。業(yè)務(wù)規(guī)則監(jiān)控的不是硬件，也不是軟件是否工作正常。而是軟件是否按照業(yè)務(wù)規(guī)則實(shí)現(xiàn)的，是否有漏洞。也可以理解為對(duì)“正確性”的監(jiān)控。

系統(tǒng)可靠性監(jiān)控是最常見(jiàn)的監(jiān)控形式，比如發(fā)現(xiàn)是不是服務(wù)器掛掉了，服務(wù)是不是過(guò)載了等等。對(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)存，磁盤(pán)等資源。一個(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)，一般來(lái)說(shuō)簡(jiǎn)單來(lái)說(shuō)可以分為四層：

產(chǎn)品策略和營(yíng)銷(xiāo)：它們決定了根本的請(qǐng)求到達(dá)的速率

應(yīng)用層（更粗俗一點(diǎn)可以叫web層）：最上層的膠水

服務(wù)層：db，各種RPC服務(wù)，以及層層嵌套的服務(wù)

硬件層：cpu，內(nèi)存，磁盤(pán)，網(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)求繁忙與否取決于多少人打開(kāi)客戶端，多少人打開(kāi)客戶端又取決于產(chǎn)品策略和營(yíng)銷(xiāo)活動(dòng)。這種層次結(jié)構(gòu)決定了單純跟蹤一個(gè)指標(biāo)，比如絕對(duì)請(qǐng)求數(shù)，很難說(shuō)明這一層的服務(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使用率超過(guò)x%的時(shí)候告警，它給你的是一個(gè)他認(rèn)為最優(yōu)的解決方案。但是他真正想要的是知道db服務(wù)是否有異常，cpu使用率超過(guò)x%未必是最好的告訴你服務(wù)是否出現(xiàn)異常的指標(biāo)。

盲目地采集那些容易獲取的指標(biāo)，并隨意地設(shè)定閾值告警是大部分糟糕的告警質(zhì)量的根源。

那到底應(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？問(wèn)題或者瓶頸在哪里。

其中最核心最關(guān)鍵的是第一個(gè)問(wèn)題，is the work getting done。對(duì)于數(shù)據(jù)庫(kù)來(lái)說(shuō)，我們可以采集：

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使用率更能說(shuō)明問(wèn)題。不僅僅是db，各個(gè)層次的服務(wù)都可以用請(qǐng)求量和正確響應(yīng)占比來(lái)反映其工作狀況。比如http請(qǐng)求數(shù)（對(duì)比http正確響應(yīng)數(shù)），比如app打開(kāi)次數(shù)（對(duì)比服務(wù)端記錄的在線人數(shù)）等等。

為什么cpu使用率不能說(shuō)明問(wèn)題？大部分時(shí)候，我們并不關(guān)心cpu本身，而關(guān)心使用cpu為資源的服務(wù)。所以cpu使用率只是一種資源的請(qǐng)求數(shù)而已。與請(qǐng)求數(shù)相關(guān)的一個(gè)概念是saturation（上限），當(dāng)上限達(dá)到的時(shí)候，處理開(kāi)始排隊(duì)，延遲開(kāi)始變長(zhǎng)，錯(cuò)誤率開(kāi)始升高。那么cpu使用率是不是能夠說(shuō)明上限呢？cpu使用率的上限以100%記，那么90%開(kāi)始告警不是很合理嗎？畢竟cpu 100%了幾乎可以等同于db無(wú)法正常處理請(qǐng)求了。

這種利用底層資源調(diào)用量，評(píng)估其是否達(dá)到上限的做法有兩個(gè)根本缺陷：

你無(wú)法知道上層服務(wù)可以把底層資源利用到什么程度

底層資源的 saturation 未必可以容易度量

具體來(lái)說(shuō)，db是不是可以真的100%利用cpu是位置的。假如請(qǐng)求里鎖，或者sleep，那么也許cpu永遠(yuǎn)也無(wú)法達(dá)到100%。90%可能就是極限了。而且現(xiàn)代的cpu是多核的，如果請(qǐng)求處理只能利用單核，處理在多個(gè)核之間跳躍，對(duì)于一個(gè)核來(lái)說(shuō)永遠(yuǎn)也不會(huì)一直保持100%。

對(duì)于cpu可能其上限真的有一個(gè)100%的值。但是對(duì)于很多非硬件的服務(wù)，比如你是一個(gè)登陸服務(wù)，依賴于一個(gè)db。那么這個(gè)db每秒可以處理的不同sql組合數(shù)是很難度量的，絕非和磁盤(pán)一樣有一個(gè)mb/s的極限絕對(duì)值可以做為對(duì)比。

而且度量底層資源的使用還有一個(gè)缺陷是你無(wú)法枚舉出所有依賴的資源的。所以與其這么繞彎子地通過(guò)底層資源來(lái)間接監(jiān)控上層服務(wù)是否正常，還不如直接測(cè)量work是不是getting done呢。

對(duì)于第二個(gè)問(wèn)題，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è)問(wèn)題就是所謂的故障定位。要是人工來(lái)做的話，最常見(jiàn)的做法是收到了告警，然后登陸CRT，開(kāi)始敲各種命令查找原因。對(duì)于系統(tǒng)來(lái)說(shuō)，最合適的做法不是出了問(wèn)題再去執(zhí)行一堆命令，而是：

每個(gè)層次都對(duì)自己做告警

頂層服務(wù)出了告警觸發(fā)自動(dòng)定位程序

按照服務(wù)的依賴關(guān)系和大致的時(shí)間范圍，定位到告警之間的關(guān)聯(lián)，從而找到出問(wèn)題或者瓶頸的地方

當(dāng)然實(shí)際情況是很復(fù)雜的。很多原因和結(jié)果是互為因果的。兩個(gè)告警是兩個(gè)現(xiàn)象，還是一個(gè)原因一個(gè)現(xiàn)象實(shí)際上很難說(shuō)得清楚。

從告警算法的角度來(lái)講，對(duì)成功請(qǐng)求率，或者平均響應(yīng)延遲做告警是非常容易的。靜態(tài)閾值大家看不起，覺(jué)得簡(jiǎn)單。但是大部分告警用靜態(tài)閾值就可以解決問(wèn)題。

那告警要不要高難度的算法？我的觀點(diǎn)是采集到了正確的指標(biāo)，是不需要復(fù)雜算法的，就是靜態(tài)閾值都可以搞得定。但是至少有三種場(chǎng)合需要算法：

無(wú)法直接采集到錯(cuò)誤數(shù)：需要對(duì)錯(cuò)誤日志的自動(dòng)分類(lèi)

無(wú)法直接采集到請(qǐng)求成功率：需要對(duì)請(qǐng)求數(shù)或響應(yīng)數(shù)的絕對(duì)值做異常檢測(cè)

只有總數(shù)，無(wú)法采集到其中的每個(gè)細(xì)分構(gòu)成項(xiàng)的占比：需要對(duì)參與的factor進(jìn)行算法擬合

其實(shí)這三項(xiàng)都是一個(gè)主題的，當(dāng)你無(wú)法直接獲取到告警所需的指標(biāo)的時(shí)候，事情會(huì)變得復(fù)雜很多。有一個(gè)比喻是：最近NASA宣布的地球?qū)\生兄弟Kepler 452b。如果我們的探測(cè)器可以跑到1400光年之外，發(fā)現(xiàn)他將是非常容易的事情。正式因?yàn)橹苯荧@得數(shù)據(jù)非常困難，所以科學(xué)家才需要根據(jù)行星阻擋恒星時(shí)引起的亮度變化（所謂掩星法）來(lái)發(fā)現(xiàn)這些遙遠(yuǎn)的星球。

采集所需的指標(biāo)的困難可能是幾方面的因素。一種原因是采集本身是非常消耗資源的事情。比如獲取每個(gè)mysql查詢所消耗的cpu。跟蹤每個(gè)請(qǐng)求處理過(guò)程是不可能的。這個(gè)時(shí)候就需要算法的幫助了，可以仔細(xì)看一下vividcortex的視頻：http://www.youtube.com/watch?v=szAfGjwLO8k

更多情況是采集指標(biāo)困難是D/O分離造成的溝通問(wèn)題，運(yùn)維需要的指標(biāo)需要開(kāi)發(fā)去埋點(diǎn)，而開(kāi)發(fā)埋點(diǎn)的地方又需要運(yùn)維去做告警。很多時(shí)候退而求其次就會(huì)造成，有什么指標(biāo)就用什么指標(biāo)的狀況。比如雖然沒(méi)有請(qǐng)求響應(yīng)的錯(cuò)誤數(shù)，但是錯(cuò)誤基本上都會(huì)有錯(cuò)誤日志記錄，根據(jù)錯(cuò)誤日志滾動(dòng)的快慢可以大致知道是不是出了問(wèn)題。這就引入了一個(gè)非常困難的日志分類(lèi)問(wèn)題，什么日志代表了正常，什么日志代表了異常，異常又非了哪些類(lèi)型？這個(gè)方面算法做得好的是summo logic公司：https://www.sumologic.com/ 。為什么這種opsdev（嘲諷devops那）公司如此熱衷于算法？對(duì)于他們來(lái)說(shuō)好處是顯而易見(jiàn)的，客戶需要做的改動(dòng)越少，接入成本越低，客戶面就越廣。但是拿機(jī)器算法去挖掘海量日志真的是回答：is the work getting done？的最佳手段？顯然不是。這就是大炮打蚊子。日志的存在是用于解決問(wèn)題，而不是有了海量日志了，如何用好“它們”變成了問(wèn)題本身。

第三類(lèi)情況是沒(méi)有辦法采集到請(qǐng)求成功率，只能對(duì)絕對(duì)的處理成功的量。只有這類(lèi)數(shù)據(jù)要告警，就無(wú)法做簡(jiǎn)單的靜態(tài)閾值了。對(duì)于延遲，一般可以定一個(gè)業(yè)務(wù)上可以接受的延遲上限。對(duì)于成功率，也可以定一個(gè)可接受的成功率上限。但是對(duì)于絕對(duì)的處理量，是沒(méi)有辦法簡(jiǎn)單地比較一個(gè)靜態(tài)閾值就可以判斷是正常還是異常的。

在討論如何實(shí)現(xiàn)之前，再?gòu)?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ù)陡降了。這說(shuō)明是db故障了？還是app故障了？都有可能……最最上層是產(chǎn)品和營(yíng)銷(xiāo)。你發(fā)現(xiàn)一個(gè)業(yè)務(wù)的注冊(cè)量相對(duì)前幾天變少了，這個(gè)是不是說(shuō)明注冊(cè)服務(wù)出問(wèn)題了？也需是產(chǎn)品太爛了，游戲根本沒(méi)有人來(lái)玩。也可能是營(yíng)銷(xiāo)手段的營(yíng)銷(xiāo)，不送金幣了，玩家沒(méi)積極性了。

只有請(qǐng)求數(shù)，沒(méi)有參考的上限值（saturation），也沒(méi)有成功率，沒(méi)有失敗率，怎么檢測(cè)異常？

上圖的黃線是昨天的值，綠線是今天的值，大部分服務(wù)監(jiān)控的曲線圖都長(zhǎng)這樣?？梢缘贸鏊膫€(gè)思路：

曲線平滑：故障一般是對(duì)近期趨勢(shì)的一個(gè)破壞，視覺(jué)上來(lái)說(shuō)就是不平滑

絕對(duì)值的時(shí)間周期性：兩條曲線幾乎重合

波動(dòng)的時(shí)間周期性：假設(shè)兩個(gè)曲線不重合，在相同時(shí)間點(diǎn)的波動(dòng)趨勢(shì)和振幅也是類(lèi)似的

有一個(gè)長(zhǎng)度可觀的坑：當(dāng)曲線開(kāi)始回升到歷史范圍的時(shí)候，一般可以確認(rèn)這個(gè)時(shí)間段是真的故障了

從這四種直覺(jué)展開(kāi)，可以得出各種或復(fù)雜或簡(jiǎn)單的算法。下面要講的算法都是非常簡(jiǎn)單的，無(wú)需很高深的數(shù)學(xué)知識(shí)。

這種檢測(cè)的根據(jù)是在一個(gè)最近的時(shí)間窗口，比如1個(gè)小時(shí)。曲線會(huì)遵循某種趨勢(shì)，而新的數(shù)據(jù)點(diǎn)打破了這種趨勢(shì)，使得曲線不光滑了。也就是說(shuō)，這種檢測(cè)利用的是時(shí)間序列的temporal dependency，T對(duì)于T-1有很強(qiáng)的趨勢(shì)依賴性。業(yè)務(wù)邏輯上來(lái)說(shuō)，8:00 有很多人登陸，8:01 也有很多人來(lái)登陸的概率是很高的，因?yàn)槲藖?lái)登陸的因素是有很強(qiáng)的慣性的。但是7.1很多人來(lái)登陸，8.1也有很多人來(lái)登陸的慣性就要差很多。

基于近期趨勢(shì)做告警，就需要對(duì)曲線的趨勢(shì)進(jìn)行擬合。擬合有兩種方式，moving average 或者 regression。這兩種擬合方式有不同的bias（傾向）。

這就是一種moving average的算法圖，叫做exponentially weighted moving average。它的計(jì)算非常簡(jiǎn)單

x是實(shí)際值，s是ewma計(jì)算出來(lái)的平均值。也就是下一點(diǎn)的平均值是由上一點(diǎn)的平均值，加上當(dāng)前點(diǎn)的實(shí)際值修正而來(lái)。這個(gè)修正的比例，就取決月這個(gè)alpha的decay factor的大小。視覺(jué)上來(lái)說(shuō)就是ewma曲線是否緊跟實(shí)際曲線，也就是平滑程度。

有了平均值之后可以計(jì)算方差，方差乘以一定的倍數(shù)可以得出對(duì)于振幅的容忍范圍。比較實(shí)際的值是否超出了這個(gè)范圍就可以知道是否可以告警了。超出了上界，可能是突然用戶量突然激增了。超出了下屆，可能是營(yíng)銷(xiāo)活動(dòng)結(jié)束了，用戶快速離開(kāi)，也可能是光纖斷了，玩家掉線了。想要了解更多關(guān)于ewma的算法細(xì)節(jié)：關(guān)注Baron Schwartz（http://www.slideshare.net/vividcortex/statistical-anomaly-detection-fo...）

moving average認(rèn)為曲線是趨向于歷史的，如果曲線的勢(shì)頭是上升，那么它認(rèn)為下一個(gè)點(diǎn)應(yīng)該是開(kāi)始下降的。regression認(rèn)為曲線是趨向于未來(lái)的，如果曲線的勢(shì)頭是上升，那么它認(rèn)為下一個(gè)點(diǎn)應(yīng)該是保持這個(gè)上升勢(shì)頭。還有更復(fù)雜的模型是綜合了moving average和regression的。無(wú)論是哪種算法，用過(guò)去10分鐘預(yù)測(cè)下10分鐘是不可能精確的。如果這種預(yù)測(cè)可以精確，那么股神早就誕生了。使用moving average，可能會(huì)掩蓋故障產(chǎn)生的下降（因?yàn)槠鋌ias是下降）。如果使用regression，那么又有可能把沒(méi)有上升得那么快當(dāng)成故障了（因?yàn)槠鋌ias是上升）。

這種基于近期趨勢(shì)計(jì)算方差的算法還有一個(gè)缺陷是當(dāng)前面幾個(gè)點(diǎn)振動(dòng)很大的時(shí)候，方差值會(huì)被搞大。后面的故障就被掩蓋了，使得連續(xù)的故障點(diǎn)無(wú)法被檢測(cè)到。其實(shí)也就是算法對(duì)于什么是正常是沒(méi)有概念的，它認(rèn)為過(guò)去的歷史就是正常。如果過(guò)去幾分鐘處于故障中，那么故障的曲線就是正常。

實(shí)際使用中發(fā)現(xiàn)這種基于曲線平滑度的算法的優(yōu)點(diǎn)有

依賴的數(shù)據(jù)少，只需要近期的歷史，不依賴于周期性

非常敏感，歷史如果波動(dòng)很小，方差就很小，容忍的波動(dòng)范圍也會(huì)非常小

缺點(diǎn)也是顯著的

過(guò)于敏感，容易誤報(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)故障。

上圖中不同的顏色代表了不同日期的曲線。很多監(jiān)控曲線都有這樣以一天為周期的周期性（早上4點(diǎn)最低，晚上11點(diǎn)最高之類(lèi)的）。一種利用時(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)閾值告警。過(guò)去靜態(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)重的問(wèn)題是如果14天歷史中有停機(jī)發(fā)布或者故障，那么最小值會(huì)受到影響。也就是說(shuō)不能把歷史當(dāng)成正常，而是要把歷史剔除掉異常值之后再進(jìn)行計(jì)算。一個(gè)務(wù)實(shí)的近似的做法是取第二小的值。

為了讓告警更加精確，可以累積計(jì)算實(shí)際曲線和參考曲線的差值之和。也就是相對(duì)于參考曲線下跌的面積。這個(gè)面積超過(guò)一定的值則告警。對(duì)于深度下跌，則累積幾個(gè)點(diǎn)就可以告警。對(duì)于淺度下跌，那么多累幾個(gè)點(diǎn)也可以告警出來(lái)。翻譯成人話就是，一下在跌了很多，則很有可能是故障了?；蛘哌B續(xù)好久都偏離正常值，那么也很有可能是出問(wèn)題了。

優(yōu)點(diǎn)：

計(jì)算簡(jiǎn)單

可以確保發(fā)現(xiàn)大的故障，出了告警一定是大問(wèn)題，可以直接打電話

缺點(diǎn)：

依賴周期性的歷史數(shù)據(jù)，計(jì)算量大，而且無(wú)法對(duì)新接入的曲線告警

非常不敏感，小波動(dòng)無(wú)法發(fā)現(xiàn)

有些時(shí)候曲線是有周期性，但是兩個(gè)周期的曲線相疊加是不重合的。比如上圖這樣的，曲線整體的趨勢(shì)是網(wǎng)上的。兩個(gè)周期的曲線一疊加，一個(gè)會(huì)比另外一個(gè)高出一頭。對(duì)于這種情況，利用絕對(duì)值告警就會(huì)有問(wèn)題。

比如今天是10.1日，放假第一天。過(guò)去14天的歷史曲線必然會(huì)比今天的曲線低很多。那么今天出了一個(gè)小故障，曲線下跌了，相對(duì)于過(guò)去14天的曲線仍然是高很多的。這樣的故障如何能夠檢測(cè)得出來(lái)？一個(gè)直覺(jué)的說(shuō)法是，兩個(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）等值。跨度越大，越可以檢測(cè)出一些緩慢下降的情況。

另外一個(gè)技巧是可以計(jì)算x(t) -x(t-2)，以及x(t+1) - x(t-1)，如果兩個(gè)值都異常則認(rèn)為是真的異常，可以避免一個(gè)點(diǎn)的數(shù)據(jù)缺陷問(wèn)題。

優(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ù)上來(lái)說(shuō)，就是小波動(dòng)如果相對(duì)比率大，但是絕對(duì)影響范圍小也是沒(méi)關(guān)系的。對(duì)于沖高回落的問(wèn)題，可以判斷一下沖高的情況，對(duì)于沖高之后屏蔽一段時(shí)間。

當(dāng)我們看見(jiàn)圖2的時(shí)候比圖1更確認(rèn)是故障了。為什么？因?yàn)閳D2中有一個(gè)明顯的回升。算法其實(shí)和人眼一樣。如果多等幾個(gè)時(shí)間點(diǎn)，發(fā)現(xiàn)曲線回升了可以更很準(zhǔn)確地判斷“曾經(jīng)”有一個(gè)故障。但是這種基于回升的異常檢測(cè)是沒(méi)有多少“告警”意義上的機(jī)制的。告警的作用就是讓人參與干預(yù)，去幫助曲線回升。如果曲線已經(jīng)開(kāi)始回升，再告警不是事后諸葛了嗎？

這種檢測(cè)的意義在于機(jī)器復(fù)制告警的確認(rèn)。當(dāng)我們需要統(tǒng)計(jì)誤警率，漏警率的時(shí)候。用另外一種視角的算法重新跑一遍可以統(tǒng)計(jì)出很多原算法的問(wèn)題。同時(shí)也可以用半自動(dòng)化的方式建立一個(gè)歷史故障的樣本庫(kù)。這個(gè)樣本庫(kù)可以變成更復(fù)雜的機(jī)器學(xué)習(xí)算法的訓(xùn)練集。

Key take away

高質(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í)在必要也是可以做到的