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