2020年工做上的最大收穫——監控告警體系

1 背景

2020年工做上的最大收穫就是初步完善了系統的監控告警體系。
2020年工做上可謂是很是苦逼的，項目上忙到腳打後腦勺的同時還被各類發佈問題、生產故障按在地上摩擦。可憐還因疫情緣由公司福利大大縮減。
總結了一下使人頭疼的問題：

1. 每次大的發佈總會產生一堆的生產問題
2. 平常應用出錯不能第一時間感知，老是到了客戶那裏才報過來

好比有一次發佈後產生了一個小小的傳值問題，可是會阻礙一部分客戶下單，結果兩天後經過客戶報障才發現，最終致使大量訂單損失！
整體來說就是缺少對系統的掌控，應用發佈上去後，就像個黑匣子，你只知道它在運行，殊不知道里面究竟是個什麼情況，也許內部已經亂的不可開交,你卻一無所知，發佈以後只留下一臉懵逼的你獨自凌亂。以至於每次發佈後的幾天都是提心吊膽，有點風吹草動就慌得一比！而在互聯網這個頻繁發佈的行業簡直就是災難
痛定思痛！終於在下半年的時候忍無可忍，決定給系統插上X光機。不只要扒掉系統這個「美女」的黑色外衣，甚至讓其骨骼線條都赤裸裸的暴露在開發人員眼中。這個X光機就是監控告警體系。

2 技術方案

咱們所使用的是公司自研的監控系統。其大體實現以下圖:

1. 各應用系統經過代理客戶端寫入Kafka
2. 持久化層服務訂閱Kafka消息進行持久化，這其中Influxdb主要存儲時序埋點，MySql與ES存儲點的一些特性方便檢索與聚合
3. UI層讀取展現埋點信息，監控告警配置，主要藉助兩個強大的可視化工具，Graphana與Kibana。

實現監控告警體系其實就分3步：

1. 應用系統埋點
2. 可視化展現
3. 監控告警配置

最簡單的方式能夠經過 ES+Kibana的方案來實現

注意;在系統沒有遇到瓶頸的時候應該儘量的用最簡單的方案解決問題，每引入一箇中間件便大大增長了系統的複雜度和維護成本

3 監控內容

技術上的實現，其實只是監控體系的第一步。最重要的部分在於監控的內容，只有作好了監控內容纔算是給你的系統構建了一個良好的監控大網。而監控哪些內容，不一樣的系統，不一樣的業務需求都不相同，這就須要根據業務與系統的要求去制定與不斷的完善。
根據咱們的經驗總結了幾個通用的監控點

1. 請求量

請求量不只能夠用來統計接口調用的數量、QPS等信息，還能夠發現系統的問題。
這裏請求量主要包含兩部分，一個是你本身提供的接口的請求量，一部分是你所依賴接口的請求量

• 若是你本身提供的接口的請求量忽然降低，那麼說明依賴你接口的下游應用、或是前置頁面極有可能除了問題。
• 而若是你本身接口的請求量正常，而所調用的第三方接口的請求量忽然降低，那麼極有可能你本身的代碼邏輯除了問題

請求量通常經過曲線圖展現，能夠更好的反映出來一個趨勢。

2. 響應量

響應量一般能夠和請求量結合使用，若是一個接口正常響應量小於請求量，那麼說明有一部分的請求是存在問題的。

3. 耗時

接口耗時主要用來監控接口性能，一樣包括你本身提供的接口的耗時和你所依賴的接口耗時。

4. 訂單量

在許多系統中，訂單量都是一個很重要的業務指標，也是咱們最重要的監控指標之一。

5. 響應狀態

響應狀態是一個很好的監控指標，它可以很好的反映咱們程序的處理結果。響應狀態比較適合用餅圖來展現。能夠很好的反映出各類狀態的佔比。

6. 異常狀態

同響應狀態同樣，異常狀態的監控也具備很重要的意義。同時異常狀態也是咱們用戶告警的重要指標之一，他能夠很直觀的反映出咱們系統的健康狀態，異常狀態能夠用餅圖，也能夠用曲線圖來展現。

7. 頁面之間轉化率

頁面之間轉化率不只僅是用戶衡量產品價值的指標，一樣是咱們系統監控的重要指標，若是從一個頁面到另外一個頁面的轉化率忽然下降，那麼極有多是這之間出現了什麼問題。

8. 其它

還有不少針對具體業務的監控指標，如搜索一般會有空搜率，商品會有缺貨率。。。
固然，可能還有不少不足，也可能隨着業務需求的變化，有些監控內容可能已通過時，又可能會須要更多監控，
這裏只提供一些思路，總之針對業務上的各類場景你能夠盡情去作到一切皆埋點。

4 告警策略

監控內容最好以後，監控體系並無結束，還差一步，就是自動告警。自動告警的功能Grafana和Kibana均可以提供，也能夠自定義咱們想要的告警方式。
這裏咱們主要的告警策略主要有三種

1. 閾值

咱們能夠對請求量、訂單量、異常量設定一個閾值，當每分鐘每小時請求量降低到某個閾值，或者異常量達到某個閾值的時候，觸發咱們的告警。

2. 環比

環比主要是與前一段時間的對比，好比這一小時(或一天)的請求量與上一小時(或一天)的請求量對比，若是小於若是小於某個閾值，就觸發咱們的告警。

3. 同比

有些時候環比是不可靠的，好比，咱們系統的特性就是周2、周3、週四的請求量要遠大於周5、周6、周天的請求量，此時若是拿週六的請求量和週五的請求量的去對比是沒有意義的，這裏就須要用到同比，即拿上週五的請求量和本週五的請求量進行對比，當小於某個閾值的時候觸發告警。
注意:這裏的告警和閾值並不是能夠一蹴而就的，須要結合實際去慢慢調整它到一個合適的值，咱們就深感其痛。(起初就由於一些不合理的告警配置，咱們優秀的人工智能常常三更半夜給打你電話，結果一般是虛驚一場，它還比較軸，你不處理它就一直打)。

5 監控成果

歷時半年，咱們對系統的監控告警體系的打造總算是告一段落。俗話說要想吃多少肉，就要先挨多少揍。這期間過程雖然是辛苦的，但成果也是巨大的。以前的問題獲得了良好的解決。大部分的線上問題，第一時間就暴露了出來，有些問題在測試環境上經過監控就提前發現。這也側面的助力咱們的測試工做。甚至在監控體系上線後一些「陳年」老bug也開始暴露出來。生產事件率大幅降低。 最重要的是每一個開發人員對系統多了一種掌控的感受，期待有一天，一羣苦逼了許久的程序員能夠在從此的每次發佈後，輕鬆看着監控大盤，喝茶扯淡！