10 人，2 個月 | 蝦米音樂的監控體系升級之路

背景

監控一直是服務端掌握應用運行狀態的重要手段，通過近幾年的發展，阿里蝦米服務端目前已經有 100 多個 Java 應用，承擔核心業務的應用也有將近 50 個，對於應用的監控配置也是因人而異。有的人配置的監控比較細，有的應用在經歷了多人開發階段之後，監控就逐漸疏於管理，有些應用的監控項最後修改時間只停留到 2 年之前，早已不適應業務的發展。

與大部分團隊同樣，蝦米也有一個報警處理羣，將內部的監控報警平臺（如 Sunfire 等）的信息經過機器人投遞到羣中，因爲監控項配置不合理、監控粒度較大，天天報警羣都被幾十條甚至上百條報警通知狂轟亂炸，久而久之你們對報警已經麻木，大部分報警也不會去處理。

基於這樣的現狀，蝦米 SRE 團隊（SRE全稱Site Reliability Engineering,最先由Google提出。致力於打造高可用、高拓展的站點穩定性工程）將工做重點放在了對監控的治理上面，通過 2 個月的研發，構建了蝦米全新的監控體系。

報警緣由分析

過去的監控配置可謂五花八門，由應用負責同窗配置的一些監控大多侷限在應用總體 RT、QPS 的監控和部分業務日誌的監控，報警發生時，大部分狀況只知道這個應用有了問題，但很難快速定位是哪裏出了問題，出了什麼問題。一個新接手的同窗可能須要通過查看配置項、登陸機器、掃描日誌甚至去查離線日誌等步驟，通過十幾分鍾才能定位到問題，有的時候甚至須要排查個大半天時間。

通過一段時間的研究和摸索，咱們發現一個應用若是在穩定運行了一段時間之後忽然發生報警，那麼緣由一般都是如下幾類：

• 程序 Bug：如代碼問題致使空指針、頻繁 FullGC 等。
• 上游依賴出問題：上游某個接口出了問題致使本應用出現接口超時、調用失敗等。
• 單機故障：某個容器受宿主機應用致使 Load、CPU 忽然升高，最終致使超時、線程池滿等狀況發生。
• 中間件故障：常見的如 Cache、DB抖 動致使一段時間內 RT 增加、超時增多。不過這裏須要注意的是，單機 Load 高一樣會引起單機讀寫 Cache、DB 出現問題。

監控優化

分析了報警緣由，下一步就是優化監控。監控的報警能夠告訴你出了問題，而好的監控是能夠告訴你哪裏出了問題。咱們之前的監控一般只完成了第一階段，而不能很好的告訴咱們哪裏出了問題，要經過一大堆輔助手段去定位。在分析了報警緣由之後，咱們就要想辦法經過監控的手段來精準定位問題。

目前蝦米的監控分爲故障監控、基礎監控和通用監控三類，以下圖所示：

故障監控

所謂故障監控，就是這些監控發生報警意味着有故障產生了。咱們認爲一切外在因素若是對應用產生影響，那麼必然反應在接口的 RT 和成功率上，要麼引發接口 RT 升高，要麼致使接口失敗數增長，成功率下跌，若是沒有這種影響，那麼這個外在影響能夠被忽略掉。所以咱們把接口監控做爲故障監控的一大塊來重點配置，若是每一個應用都配置了核心接口的故障監控，在排查問題時，就很容易定位是否因爲上游應用的某個接口致使了個人應用出了問題。

所以咱們使用成功率、RT 和錯誤碼三個指標來進行一個接口的故障監控。特別指出的是，對於客戶端接口的 RT 監控上，咱們沒有使用平均 RT，而是使用 Top 75% RT。由於想用它來反應用戶側的感覺，好比 RT的 75% 分位線報警閾值設置爲 1000ms,那麼當這一監控項發生報警時，意味着有 25% 的用戶請求接口已經超過 1000ms。一般這一報警閾值設置成用戶不能忍受的一個 RT，好比 500ms 或 1000ms。

在故障監控裏，咱們還設置了應用維度的異常、錯誤和消息異常三種類型的監控，他們對服務器上的Exception和Error進行監控。這一類監控主要用於快速發現程序bug。例如當一次發佈進行時，若是這三種類型的錯誤增長，那麼應該能夠考慮進行回滾了。

通用監控

大多數狀況下，應用出現的問題都是因爲單機故障引發的時候，若是某臺機器的接口黃金指標忽然變化、錯誤或異常數量忽然增多，而其餘機器沒有什麼變化，那就說明是單機引發的。所以咱們對應用的故障監控都配置了對應的單機監控，在此處咱們還額外引入了 HSF（Dubbo） 線程池滿和 HSF（Dubbo） 超時兩個類型的單機監控，是由於當單機 Load 高、CPU 有問題時，最爲常見的表現就是HSF線程池忽然打滿，HSF（Dubbo） 超時數量增多，這兩個監控一樣能夠來輔助定位單機問題。經過這一類監控，咱們能夠方便地接口報警是否由某臺機器引發。

基礎監控

前面兩種類型的監控已經基本能夠定位到故障是否因爲程序 Bug、上游應用或單機故障引發的，還有一類就是對中間件的監控，這裏咱們利用了 Sunfire 的基礎監控對應用的 CPU、Load、JVM、HSF（Dubbo）、MetaQ 等中間件的各項指標進行監控。若是由於中間件故障，此處將會有明顯的報警。

報警路徑優化

通過對監控的梳理和優化，目前每一個應用差不過有 30-50 個報警項，若是全部報警項用之前的方式投遞的報警羣，那麼將是一個災難，徹底沒有辦法去看，更沒有辦法快速定位問題。同時，一個應用負責人一般只關心本身的應用報警，讓他去看其餘應用的報警也是沒用的。所以咱們構建了一個 SRE 平臺來優化報警鏈路，優化後的報警鏈路以下：

咱們利用流計算設定報警窗口，進行報警聚合，經過報警分級來進行決定哪些報警應該被投遞出來，在報警羣精準 AT 相關的同窗，查看報警羣時，能夠直接定位到 AT 個人消息，快速提取有用的信息。同時在 SRE 平臺支持對應用和上游應用一小時內的報警進行分類和聚合展現，哪裏出了問題一目瞭然。咱們經過本身的機器人，在釘釘羣裏只發送符合規則的報警信息，極大減小了報警數量，提升了報警的可讀性，目前日均產生約 5000 條各類類型的報警信息，通過決策和規則篩選投遞出的報警信息約爲 50-100 條，而這些報警是咱們認爲必需要當即處理的報警。

藉助流量調度

在前面提到不少故障是因爲單機引發的，過去咱們排查出來單機故障常常作的就是把服務停了或者單機置換，這樣效率極低，實際上咱們須要作的是在機器有問題的時候，可以把它的流量快速切走，再它恢復的時候再把流量切回來，若是這一切可以自動化地進行就更好了。

• 咱們藉助阿里巴巴的流量調度平臺（即阿里雲 AHAS）能夠完美地解決如下的問題：
• 發佈預熱問題，避免發佈帶來的 RT、Load 升高問題 進而引起 HSF 超時等問題；
• 局部機器流量太高、受宿主機影響、慢調用過多、HSF線程滿帶來的服務不可用、RT太高等問題。

目前，咱們約有 40 個應用已經接入流量調度平臺，每週調度機器流量 1000 餘次，藉助流量調度平臺咱們能夠再也不關心單機故障引起的應用報警。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。