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

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

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

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

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

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

很多時候，告警通知人去干的事情是真的可以被自動化掉的。比如服務(wù)器掛了，換一臺上來。在小一點的系統(tǒng)里，可能就是停機(jī)一會，人工來處理換一臺冷備的機(jī)器上去。大一點的系統(tǒng)，因為服務(wù)器多了，天天都掛可不行，必須是熱備的，系統(tǒng)自動切換到備機(jī)。再大一點的系統(tǒng)，因為切換實在太頻繁了，故障機(jī)的退庫，備機(jī)的保有都變成了一種管理負(fù)擔(dān)，那么可以和其他的運(yùn)維流程打通變成完全自動化的系統(tǒng)。只是因為業(yè)務(wù)處理不同階段，選擇不同的實現(xiàn)策略而已。業(yè)務(wù)量小，拿血肉當(dāng)機(jī)器用，有的時候更經(jīng)濟(jì)而已。當(dāng)然對于那個被當(dāng)成機(jī)器人來用的哥們來說，生活確實有點不公平。

告警對象可以分為兩種：

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

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

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

系統(tǒng)可靠性監(jiān)控是最常見的監(jiān)控形式，比如發(fā)現(xiàn)是不是服務(wù)器掛掉了，服務(wù)是不是過載了等等。對于大部分后臺服務(wù)，系統(tǒng)可以抽象建模成這個樣子：

對于這樣的系統(tǒng)可以采集什么指標(biāo)？

請求數(shù)，請求到達(dá)速率

正常響應(yīng)數(shù)，正常響應(yīng)占比

錯誤響應(yīng)數(shù)，錯誤響應(yīng)占比

響應(yīng)延時

隊列長度，排隊時間

實際的情況是，幾乎任何系統(tǒng)都不是孤立運(yùn)行的。而是這樣的：

一個DB會依賴于底層的cpu，內(nèi)存，磁盤等資源。一個Http服務(wù)會依賴于底層的DB服務(wù)。一個應(yīng)用會依賴于數(shù)個底層的RPC服務(wù)。于是又多了幾個指標(biāo)

資源A的調(diào)用量（比如CPU使用率）

資源B的調(diào)用量（比如內(nèi)存分配和釋放）

資源C的調(diào)用量（比如網(wǎng)絡(luò)發(fā)送包量）

...

這種層次結(jié)構(gòu)，一般來說簡單來說可以分為四層：

產(chǎn)品策略和營銷：它們決定了根本的請求到達(dá)的速率

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

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

硬件層：cpu，內(nèi)存，磁盤，網(wǎng)絡(luò)

因為這樣的一個依賴層次。上一層對下一層的資源消耗量變成了下一層的請求數(shù)。比如Http服務(wù)消耗了多少DB的資源，就對應(yīng)了DB服務(wù)需要處理多少請求數(shù)。DB繁忙與否取決于Http服務(wù)請求，Http服務(wù)請求繁忙與否取決于多少人打開客戶端，多少人打開客戶端又取決于產(chǎn)品策略和營銷活動。這種層次結(jié)構(gòu)決定了單純跟蹤一個指標(biāo)，比如絕對請求數(shù)，很難說明這一層的服務(wù)是否出現(xiàn)了故障。

有這么多層次，每層又有很多指標(biāo)可以采集。那么應(yīng)該采集什么指標(biāo)，用什么告警策略去告警呢？最前面已經(jīng)提到了告警必須是actionable的，但是實際情況下只有這種綱領(lǐng)性要求仍然是不好操作的。至少可以提幾點不應(yīng)該做的事情：

不應(yīng)該用采集的難度決定你使用什么指標(biāo)去告警。很多情況下cpu使用率可能是最好采集的，但是未必是最值得告警的。

不要給運(yùn)維他們想要的告警，而是要做“真正”想要的告警。大部分情況下，人們告訴你的是一個解決方案。運(yùn)維告訴你它需要對db進(jìn)程的cpu使用率超過x%的時候告警，它給你的是一個他認(rèn)為最優(yōu)的解決方案。但是他真正想要的是知道db服務(wù)是否有異常，cpu使用率超過x%未必是最好的告訴你服務(wù)是否出現(xiàn)異常的指標(biāo)。

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

那到底應(yīng)該采集什么指標(biāo)呢？我認(rèn)為大部分的系統(tǒng)可靠性監(jiān)控不外乎三個目標(biāo)：

is the work getting done？系統(tǒng)是否在持續(xù)完成其設(shè)定的工作。

is the user having good experience？用戶體驗是否好。

where is the problem/bottleneck？問題或者瓶頸在哪里。

其中最核心最關(guān)鍵的是第一個問題，is the work getting done。對于數(shù)據(jù)庫來說，我們可以采集：

cpu 使用率

網(wǎng)絡(luò)帶寬大小

db請求數(shù)

db響應(yīng)數(shù)

db錯誤響應(yīng)數(shù)

db請求延遲

顯然要回答一個db是否完成了其指定的工作，更應(yīng)該關(guān)注的指標(biāo)是這兩個：

db請求數(shù)的絕對量

db正確響應(yīng)相對請求數(shù)的占比

這兩個指標(biāo)相對于采集什么cpu使用率更能說明問題。不僅僅是db，各個層次的服務(wù)都可以用請求量和正確響應(yīng)占比來反映其工作狀況。比如http請求數(shù)（對比http正確響應(yīng)數(shù)），比如app打開次數(shù)（對比服務(wù)端記錄的在線人數(shù)）等等。

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

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

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

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

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

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

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

對于第二個問題，is the user having good experience？可以采集的指標(biāo)為

平均排隊時間，平均總響應(yīng)延遲

99/95/90 percentile的排隊時間，99/95/90 percentile的響應(yīng)延遲

這里的用戶不一定是指人或者玩家，可能是上一層的服務(wù)調(diào)用方，另外一個系統(tǒng)。

第三個問題就是所謂的故障定位。要是人工來做的話，最常見的做法是收到了告警，然后登陸CRT，開始敲各種命令查找原因。對于系統(tǒng)來說，最合適的做法不是出了問題再去執(zhí)行一堆命令，而是：

每個層次都對自己做告警

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

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

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

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

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

無法直接采集到錯誤數(shù)：需要對錯誤日志的自動分類

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

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

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

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

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

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

在討論如何實現(xiàn)之前，再強(qiáng)調(diào)兩點：

處理成功的量不是度量is work getting done的最佳指標(biāo)。費(fèi)事費(fèi)力去搞算法，不如直接把成功率指標(biāo)給采集了。

處理成功的量，還取決于請求數(shù)。而請求數(shù)根本上是取決于上層服務(wù)了。你是一個dba，發(fā)現(xiàn)db的每秒處理的請求數(shù)陡降了。這說明是db故障了？還是app故障了？都有可能……最最上層是產(chǎn)品和營銷。你發(fā)現(xiàn)一個業(yè)務(wù)的注冊量相對前幾天變少了，這個是不是說明注冊服務(wù)出問題了？也需是產(chǎn)品太爛了，游戲根本沒有人來玩。也可能是營銷手段的營銷，不送金幣了，玩家沒積極性了。

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

上圖的黃線是昨天的值，綠線是今天的值，大部分服務(wù)監(jiān)控的曲線圖都長這樣。可以得出四個思路：

曲線平滑：故障一般是對近期趨勢的一個破壞，視覺上來說就是不平滑

絕對值的時間周期性：兩條曲線幾乎重合

波動的時間周期性：假設(shè)兩個曲線不重合，在相同時間點的波動趨勢和振幅也是類似的

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

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

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

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

這就是一種moving average的算法圖，叫做exponentially weighted moving average。它的計算非常簡單

x是實際值，s是ewma計算出來的平均值。也就是下一點的平均值是由上一點的平均值，加上當(dāng)前點的實際值修正而來。這個修正的比例，就取決月這個alpha的decay factor的大小。視覺上來說就是ewma曲線是否緊跟實際曲線，也就是平滑程度。

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

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

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

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

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

非常敏感，歷史如果波動很小，方差就很小，容忍的波動范圍也會非常小

缺點也是顯著的

過于敏感，容易誤報。因為方差會隨著異常點的引入而變大，所以很難使用連續(xù)三點才告警這樣的策略

業(yè)務(wù)曲線可能自身有規(guī)律性的陡增和陡降

最佳的使用方式是不用一根曲線做告警。結(jié)合幾條相關(guān)的曲線，如果同時出現(xiàn)平滑度破壞的情況，而且與業(yè)務(wù)規(guī)律的趨勢相背離（比如在線人數(shù)降低，登陸請求數(shù)增高）則可以認(rèn)定為業(yè)務(wù)出現(xiàn)故障。

上圖中不同的顏色代表了不同日期的曲線。很多監(jiān)控曲線都有這樣以一天為周期的周期性（早上4點最低，晚上11點最高之類的）。一種利用時間周期性的最簡單的算法

min(14 days history) * 0.6

對歷史14天的曲線取最小值。怎么個取最小值的方法？對于12:05分，有14天對應(yīng)的點，取最小值。對于12:06分，有14天對應(yīng)的點，取最小值。這樣可以得出一條一天的曲線。然后對這個曲線整體乘以0.6。如果幾天的曲線低于這條參考線則告警。

這其實是一種靜態(tài)閾值告警的升級版，動態(tài)閾值告警。過去靜態(tài)閾值是一個根據(jù)歷史經(jīng)驗拍腦袋的產(chǎn)物。用這個算法，其實是把同時間點的歷史值做為依據(jù)，計算出一個最不可能的下界。同時閾值不是唯一的一個，而是每個時間點有一個。如果1分鐘一個點，一天中就有1440個下界閾值。

實際使用中0.6當(dāng)然還是要酌情調(diào)整的。而且一個嚴(yán)重的問題是如果14天歷史中有停機(jī)發(fā)布或者故障，那么最小值會受到影響。也就是說不能把歷史當(dāng)成正常，而是要把歷史剔除掉異常值之后再進(jìn)行計算。一個務(wù)實的近似的做法是取第二小的值。

為了讓告警更加精確，可以累積計算實際曲線和參考曲線的差值之和。也就是相對于參考曲線下跌的面積。這個面積超過一定的值則告警。對于深度下跌，則累積幾個點就可以告警。對于淺度下跌，那么多累幾個點也可以告警出來。翻譯成人話就是，一下在跌了很多，則很有可能是故障了。或者連續(xù)好久都偏離正常值，那么也很有可能是出問題了。

優(yōu)點：

計算簡單

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

缺點：

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

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

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

比如今天是10.1日，放假第一天。過去14天的歷史曲線必然會比今天的曲線低很多。那么今天出了一個小故障，曲線下跌了，相對于過去14天的曲線仍然是高很多的。這樣的故障如何能夠檢測得出來？一個直覺的說法是，兩個曲線雖然不一樣高，但是“長得差不多”。那么怎么利用這種“長得差不多”呢？那就是振幅了。

與其用x(t)的值，不如用x(t) - x(t-1)的值，也就是把絕對值變成變化速度。可以直接利用這個速度值，也可以是 x(t) - x(t-1) 再除以 x(t-1)，也就是一個速度相對于絕對值的比率。比如t時刻的在線900人，t-1時刻的在線是1000人，那么可以計算出掉線人數(shù)是10%。這個掉線比率在歷史同時刻是高還是低？那么就和前面一樣處理了。

實際使用中有兩個技巧：可以是x(t) - x(t-1），也可以是x(t) - x(t-5）等值。跨度越大，越可以檢測出一些緩慢下降的情況。

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

優(yōu)點：

比絕對值要敏感

利用了時間周期性，規(guī)避了業(yè)務(wù)曲線自身的周期性陡降

缺點：

要求原曲線是光滑的

周期性陡降的時間點必須重合，否則誤警

按百分比計算容易在低峰時期誤警

陡降不一定代表故障，由上層服務(wù)波動引起的沖高再回落的情況時有發(fā)生

這種異常告警算法是比較優(yōu)秀的。缺點也很多。所以可以進(jìn)行一些修補(bǔ)湊合用。為了避免低峰時期，基于振幅百分比容易誤警，可以加入絕對振幅的下限。業(yè)務(wù)上來說，就是小波動如果相對比率大，但是絕對影響范圍小也是沒關(guān)系的。對于沖高回落的問題，可以判斷一下沖高的情況，對于沖高之后屏蔽一段時間。

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

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

Key take away

高質(zhì)量的告警是actionable的

不應(yīng)該用采集的難度決定你使用什么指標(biāo)去告警

不要別人做什么告警，你就做什么，要做“真正”有用的告警：特別是cpu使用率告警

is work getting done：請求數(shù) + 成功率

is the user having good experience：響應(yīng)延遲

只要采集對了指標(biāo)，大部分時候告警不需要復(fù)雜算法

基于算法的異常檢測：算法不難，實在必要也是可以做到的