蝦米音樂的監控體系升級之路

科技 08-26

作者 | 宋旭

背景

監控一直是服務端掌握應用運行狀態的重要手段，經過近幾年的發展，阿里蝦米服務端目前已經有 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 條，而這些報警是我們認為必須要立即處理的報警。