蝦米音樂的監控體系更新之路

宋旭，花名全琮，蝦米音樂技術專家，2017 年加入阿裡巴巴，從事蝦米音樂穩定性建設相關工作。

背景

監控一直是服務端掌握應用運作狀态的重要手段，經過近幾年的發展，阿裡蝦米服務端目前已經有 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 餘次，借助流量排程平台我們可以不再關心單機故障引發的應用報警。

推薦工具&産品

• 阿裡雲應用高可用服務 AHAS https://help.aliyun.com/document_detail/90320.html