2020年工作上的最大收穫——監控告警體系
1 背景
2020年工作上的最大收穫就是初步完善了系統的監控告警體系。
2020年工作上可謂是非常苦逼的，項目上忙到腳打後腦勺的同時還被各種發布問題、生產故障按在地上摩擦。可憐還因疫情原因公司福利大大縮減。
總結了一下令人頭疼的問題：
- 每次大的發布總會產生一堆的生產問題
- 日常應用出錯不能第一時間感知，總是到了客戶那裡才報過來
比如有一次發布後產生了一個小小的傳值問題，但是會阻礙一部分客戶下單，結果兩天後通過客戶報障才發現，最終導致大量訂單損失！
總體來講就是缺乏對系統的掌控，應用發布上去後，就像個黑匣子，你只知道它在運行，卻不知道裡面到底是個什麼狀況，也許內部已經亂的不可開交,你卻一無所知，發布之後只留下一臉懵逼的你獨自凌亂。以致於每次發布後的幾天都是提心弔膽，有點風吹草動就慌得一比！而在互聯網這個頻繁發布的行業簡直就是災難
痛定思痛！終於在下半年的時候忍無可忍，決定給系統插上X光機。不僅要扒掉系統這個「美女」的黑色外衣，甚至讓其骨骼線條都赤裸裸的暴露在開發人員眼中。這個X光機就是監控告警體系。
2 技術方案
我們所使用的是公司自研的監控系統。其大致實現如下圖:
- 各應用系統通過代理客戶端寫入Kafka
- 持久化層服務訂閱Kafka消息進行持久化，這其中Influxdb主要存儲時序埋點，MySql與ES存儲點的一些特性方便檢索與聚合
- UI層讀取展示埋點資訊，監控告警配置，主要藉助兩個強大的可視化工具，Graphana與Kibana。
實現監控告警體系其實就分3步：
- 應用系統埋點
- 可視化展示
- 監控告警配置
最簡單的方式可以通過 ES+Kibana的方案來實現
注意;在系統沒有遇到瓶頸的時候應該儘可能的用最簡單的方案解決問題，每引入一個中間件便大大增加了系統的複雜度和維護成本
3 監控內容
技術上的實現，其實只是監控體系的第一步。最重要的部分在於監控的內容，只有做好了監控內容才算是給你的系統構建了一個良好的監控大網。而監控哪些內容，不同的系統，不同的業務需求都不相同，這就需要根據業務與系統的要求去制定與不斷的完善。
根據我們的經驗總結了幾個通用的監控點
- 請求量
請求量不僅可以用來統計介面調用的數量、QPS等資訊，還可以發現系統的問題。
這裡請求量主要包含兩部分，一個是你自己提供的介面的請求量，一部分是你所依賴介面的請求量
- 如果你自己提供的介面的請求量突然下降，那麼說明依賴你介面的下游應用、或是前置頁面極有可能除了問題。
- 而如果你自己介面的請求量正常，而所調用的第三方介面的請求量突然下降，那麼極有可能你自己的程式碼邏輯除了問題
請求量一般通過曲線圖展示，可以更好的反映出來一個趨勢。
- 響應量
響應量通常可以和請求量結合使用，如果一個介面正常響應量小於請求量，那麼說明有一部分的請求是存在問題的。
- 耗時
介面耗時主要用來監控介面性能，同樣包括你自己提供的介面的耗時和你所依賴的介面耗時。
- 訂單量
在許多系統中，訂單量都是一個很重要的業務指標，也是我們最重要的監控指標之一。
- 響應狀態
響應狀態是一個很好的監控指標，它能夠很好的反映我們程式的處理結果。響應狀態比較適合用餅圖來展示。可以很好的反映出各種狀態的佔比。
- 異常狀態
同響應狀態一樣，異常狀態的監控也具有很重要的意義。同時異常狀態也是我們用戶告警的重要指標之一，他可以很直觀的反映出我們系統的健康狀態，異常狀態可以用餅圖，也可以用曲線圖來展示。
- 頁面之間轉化率
頁面之間轉化率不僅僅是用戶衡量產品價值的指標，同樣是我們系統監控的重要指標，如果從一個頁面到另一個頁面的轉化率突然降低，那麼極有可能是這之間出現了什麼問題。
- 其它
還有很多針對具體業務的監控指標，如搜索通常會有空搜率，商品會有缺貨率。。。
當然，可能還有很多不足，也可能隨著業務需求的變化，有些監控內容可能已經過時，又可能會需要更多監控，
這裡只提供一些思路，總之針對業務上的各種場景你可以盡情去做到一切皆埋點。
4 告警策略
監控內容最好之後，監控體系並沒有結束，還差一步，就是自動告警。自動告警的功能Grafana和Kibana都可以提供，也可以自定義我們想要的告警方式。
這裡我們主要的告警策略主要有三種
- 閾值
我們可以對請求量、訂單量、異常量設定一個閾值，當每分鐘每小時請求量下降到某個閾值，或者異常量達到某個閾值的時候，觸發我們的告警。
- 環比
環比主要是與前一段時間的對比，比如這一小時(或一天)的請求量與上一小時(或一天)的請求量對比，如果小於如果小於某個閾值，就觸發我們的告警。
- 同比
有些時候環比是不可靠的，比如，我們系統的特性就是周二、周三、周四的請求量要遠大於周五、周六、周天的請求量，此時如果拿周六的請求量和周五的請求量的去對比是沒有意義的，這裡就需要用到同比，即拿上周五的請求量和本周五的請求量進行對比，當小於某個閾值的時候觸發告警。
注意:這裡的告警和閾值並非可以一蹴而就的，需要結合實際去慢慢調整它到一個合適的值，我們就深感其痛。(起初就因為一些不合理的告警配置，我們優秀的人工智慧經常三更半夜給打你電話，結果通常是虛驚一場，它還比較軸，你不處理它就一直打)。
5 監控成果
歷時半年，我們對系統的監控告警體系的打造總算是告一段落。俗話說要想吃多少肉，就要先挨多少揍。這期間過程雖然是辛苦的，但成果也是巨大的。之前的問題得到了良好的解決。大部分的線上問題，第一時間就暴露了出來，有些問題在測試環境上通過監控就提早發現。這也側面的助力我們的測試工作。甚至在監控體系上線後一些「陳年」老bug也開始暴露出來。生產事件率大幅下降。
最重要的是每個開發人員對系統多了一種掌控的感覺，期待有一天，一群苦逼了許久的程式設計師可以在今後的每次發布後，輕鬆看著監控大盤，喝茶扯淡！
