【技術】聊聊告警
一、背景
大家知道，tiankonguse 是一個IT/計算機/網際網路公司的一個技術開發人員。
之前曾分享過一系列技術文章（文章最後點選原文檢視），其中介紹過《UNION系統的運營與運維 》。
那篇文章講的是 UNION 資料聚合快取系統成長起來後，進行的運營優化。
其中面對幾千個接入的業務，UNIOIN 系統做了自己的監控模組，從而做到了自動監控每個業務的訪問情況，還可以做到異常告警。
自然，這個告警模組也是 tiankonguse 使用 Python 指令碼 加 簡單的 mysql 資料庫實現的。
快速上線後，得到的好處是無數次提前幫業務發現問題。
然而也面臨一個問題：告警持續發生時，每分鐘就會收到一條告警，從而造成告警騷擾。
之前的兩年時間內，都是通過手動調整告警閾值來處理問題的。
一旦短時間內有事沒看到告警，微信訊息就是99+了。
今天，tiankonguse 終於決定修復這個問題了。
修復完了，坐下來聊聊告警。
二、關鍵指標
開發一個服務，如果關鍵的指標沒有上報，那就談不上監控了。
常見的指標有請求量、失敗量、平均耗時等，其他指標可以根據業務自身的特點來提取上報。
常見指標大家都會上報，業務自身相關的指標則經常被忘記上報，這個大家一定要留意。
比如突然有一天發現服務失敗，想看具體是哪個模組失敗的，結果發現相關模組沒有上報，那就比較被動了。
對於通訊服務，一般分為 上層來的請求 和 向下的請求。
上層來的請求監控，稱為被調監控。向下請求的監控，稱為主調監控。
通過被調監控，能夠知道我們的服務出問題了。通過主調監控，能夠知道是由於依賴的某個服務出問題才導致我們出問題。
不過到底該上報到哪個程度，這個也不好衡量。上面提到的主調監控和被調監控至少是要上報的。
一般是系統越大，上報的監控越多；系統越複雜，上報的監控越精細。
這裡的目標是如果發生異常，能夠快速發現問題，並解決問題。
具體上報指標，只能靠系統的負責人自己去思考了。
三、告警閾值
各種關鍵指標上報了，對於某些監控系統，還需要手動設定各維度的監控閾值才能真正有效的發出告警。
否則這個只是一個數據查詢系統，並沒有監控告警的效果。
沒有告警的弊端也很容易推測出來：我們被投訴之後，去監控系統一看，確實發生異常了，而且持續好久了。
所以，告警的目的是出問題了，能夠馬上主動發現問題，甚至是被投訴之前就修復問題了。
如果一個系統上報的指標多了，經常會發生沒有設定告警閾值的情況。
尤其是對於後來新增的監控指標，尤其要注意是否設定監控閾值。
這裡有一個邏輯：上報的目的是為了快速發現問題，所以所有上報都應該儘量設定監控閾值。
否則還是會發生這樣的場景：一個問題發生了，我們沒有及時告警出來，後來發現上報了，但是沒有設定告警閾值。
這樣的場景，周圍的小夥伴包括 tiankonguse 都遇到過，代價相當慘痛。
所以很多上報監控系統，都預設設定基礎指標的監控閾值。
tiankonguse 做的 這個實時監控告警系統也支援有策略的給每個呼叫方設定監控閾值，當然目前的策略還比較挫，但有至少比沒有好嘛。
四、告警處理
告警的目的是發現問題，那發現了問題自然要及時解決問題。
如果發現告警不合理（資料合理，閾值不合理），那就應該及時的調整告警閾值。
如果確實有問題，解決又需要一段時間，告警還在持續不斷的傳送，那可以臨時的遮蔽告警。
邏輯是這樣：我們已經知道問題存在了，告警再不斷的傳送就是騷擾我們。既然我們知道問題存在了，這個告警就沒有意義了，因為告警的目的已經不滿足了。
當然，如果短時間內就修復問題，那是否遮蔽都可以，如果長時間內才能修復問題，遮蔽就很有必要了。
遮蔽的代價也很容易想到：忘記取消遮蔽。
這個處理問題的流程如果規範化，其實還是可以避免的。
另外，系統支援指定時間段臨時遮蔽，那就更好了。
五、告警收斂
告警最令人頭疼的就是同樣的告警，收到無數條。
前幾條告警可以起到發現問題的作用，後面的告警只能起到資訊騷擾的作用。
所以告警收斂是每個告警系統都要支援的功能。
告警收斂的演算法很多，最簡單的就是固定週期收斂，比如五分鐘最多發一條。
當然，tiankonguse思考之後，採用了另外一個策略：指數週期收斂。
告警的目的是發現問題，而問題剛發生的時候，有可能沒看到第一條告警。
所以告警初期，還需要多傳送幾條告警（問題急迫，告警頻率較高）。
告警後期，如果負責人沒發現告警，傳送再多也沒用，所以間隔很久傳送一條就行了。
當然，這裡面還有告警指數區間的增長演算法與恢復演算法，就不多說了。
對於複雜業務，也會遇到發生問題時，發出大量的不同的告警。
這種不同告警的收斂也是有必要的，做最初版本的時候我就考慮了，大家也要考慮一下。
六、閾值的合理性
一般情況下，告警都是設定的固定值，這就引入一系列問題。
比如目前的網際網路業務，白天的量一般很大，後半夜的量很小。
往往設定一個波動告警，白天不滿足，但是後半夜滿足了。
這就導致我們只能調大波動告警的閾值，但是太大了白天異常了又發現不了了。
針對這種情況，比較有效的方法是按時間區間分別設定告警閾值。
波動告警和最大值最小值都可以按這個策略配置。
除了白天與黑夜的區別外，有些業務會在固定的時間點做活動，比如推tips。
這些也會臨時出現異常的波動情況，這種也需要按照時間區間做特殊配置。
當然，針對特殊的趨勢或者波動，靠人工去找特徵避免不了漏掉特徵或者特徵變化。
業界已經有很多人開始使用機器學習進行智慧識別特徵、智慧收斂告警、智慧傳送告警。
後面簡單的告警系統也不簡單了，而是AI告警系統了。
七、最後
簡單的聊了聊告警系統，往深處思考發現這裡面的學問還挺多的，你怎麼看待這個問題呢？
-EOF-
本文首發於公眾號：天空的程式碼世界，微訊號：tiankonguse-code。