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

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

Photo @ 蝦米音樂

文 | 宋旭

背景

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

與大部分團隊一樣,蝦米也有一個報警處理群,將內部的監控報警平臺(如 Sunfire 等)的信息通過機器人投遞到群中,由于監控項配置不合理、監控粒度較大,每天報警群都被幾十條甚至上百條報警通知狂轟亂炸,長此以往大家對報警已經麻木,大部分報警也不會去處理。

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

報警原因分析

過去的監控配置可謂五花八門,由應用負責同學配置的一些監控大多局限在應用整體 RT、QPS 的監控和部分業務日志的監控,報警發生時,大部分情況只知道這個應用有了問題,但很難快速定位是哪里出了問題,出了什么問題。一個新接手的同學可能需要經過查看配置項、登錄機器、掃描日志甚至去查離線日志等步驟,經過十幾分鐘才能定位到問題,有的時候甚至需要排查個大半天時間。

經過一段時間的研究和摸索,我們發現一個應用如果在穩定運行了一段時間以后突然發生報警,那么原因通常都是以下幾類:

  • 程序 Bug:如代碼問題導致空指針、頻繁 FullGC 等。

  • 上游依賴出問題:上游某個接口出了問題導致本應用出現接口超時、調用失敗等。

  • 單機故障:某個容器受宿主機應用導致 Load、CPU 突然升高,最終導致超時、線程池滿等情況發生。

  • 中間件故障:常見的如 Cache、DB抖 動導致一段時間內 RT 增長、超時增多。不過這里需要注意的是,單機 Load 高同樣會引發單機讀寫 Cache、DB 出現問題。

監控優化

分析了報警原因,下一步就是優化監控。監控的報警可以告訴你出了問題,而好的監控是可以告訴你哪里出了問題。我們以前的監控通常只完成了第一階段,而不能很好的告訴我們哪里出了問題,要通過一大堆輔助手段去定位。在分析了報警原因以后,我們就要想辦法通過監控的手段來精準定位問題。

目前蝦米的監控分為故障監控、基礎監控和通用監控三類,如下圖所示:

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

故障監控

所謂故障監控,就是這些監控發生報警意味著有故障產生了。我們認為一切外在因素如果對應用產生影響,那么必然反應在接口的 RT 和成功率上,要么引起接口 RT 升高,要么導致接口失敗數增加,成功率下跌,如果沒有這種影響,那么這個外在影響可以被忽略掉。因此我們把接口監控作為故障監控的一大塊來重點配置,如果每個應用都配置了核心接口的故障監控,在排查問題時,就很容易定位是否由于上游應用的某個接口導致了我的應用出了問題。

因此我們使用成功率、RT 和錯誤碼三個指標來進行一個接口的故障監控。特別指出的是,對于客戶端接口的 RT 監控上,我們沒有使用平均 RT,而是使用 Top 75% RT。因為想用它來反應用戶側的感受,比如 RT的 75% 分位線報警閾值設置為 1000ms,那么當這一監控項發生報警時,意味著有 25% 的用戶請求接口已經超過 1000ms。通常這一報警閾值設置成用戶不能忍受的一個 RT,比如 500ms 或 1000ms。

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

在故障監控里,我們還設置了應用維度的異常、錯誤和消息異常三種類型的監控,他們對服務器上的Exception和Error進行監控。這一類監控主要用于快速發現程序bug。例如當一次發布進行時,如果這三種類型的錯誤增加,那么應該可以考慮進行回滾了。

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

通用監控

大多數情況下,應用出現的問題都是由于單機故障引起的時候,如果某臺機器的接口黃金指標突然變化、錯誤或異常數量突然增多,而其他機器沒有什么變化,那就說明是單機引起的。因此我們對應用的故障監控都配置了對應的單機監控,在此處我們還額外引入了 HSF(Dubbo) 線程池滿和 HSF(Dubbo) 超時兩個類型的單機監控,是因為當單機 Load 高、CPU 有問題時,最為常見的表現就是HSF線程池突然打滿,HSF(Dubbo) 超時數量增多,這兩個監控同樣可以來輔助定位單機問題。通過這一類監控,我們可以方便地接口報警是否由某臺機器引起。

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

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

基礎監控

前面兩種類型的監控已經基本可以定位到故障是否由于程序 Bug、上游應用或單機故障引起的,還有一類就是對中間件的監控,這里我們利用了 Sunfire 的基礎監控對應用的 CPU、Load、JVM、HSF(Dubbo)、MetaQ 等中間件的各項指標進行監控。如果因為中間件故障,此處將會有明顯的報警。

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

報警路徑優化

經過對監控的梳理和優化,目前每個應用差不過有 30-50 個報警項,如果所有報警項用以前的方式投遞的報警群,那么將是一個災難,完全沒有辦法去看,更沒有辦法快速定位問題。同時,一個應用負責人通常只關心自己的應用報警,讓他去看其他應用的報警也是沒用的。因此我們構建了一個 SRE 平臺來優化報警鏈路,優化后的報警鏈路如下:

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

我們利用流計算設定報警窗口,進行報警聚合,通過報警分級來進行決定哪些報警應該被投遞出來,在報警群精準 AT 相關的同學,查看報警群時,可以直接定位到 AT 我的消息,快速提取有用的信息。同時在 SRE 平臺支持對應用和上游應用一小時內的報警進行分類和聚合展示,哪里出了問題一目了然。我們通過自己的機器人,在釘釘群里只發送符合規則的報警信息,極大減少了報警數量,提高了報警的可讀性,目前日均產生約 5000 條各種類型的報警信息,經過決策和規則篩選投遞出的報警信息約為 50-100 條,而這些報警是我們認為必須要立即處理的報警。

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

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

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

借助流量調度

在前面提到很多故障是由于單機引起的,過去我們排查出來單機故障經常做的就是把服務停了或者單機置換,這樣效率極低,實際上我們需要做的是在機器有問題的時候,能夠把它的流量快速切走,再它恢復的時候再把流量切回來,如果這一切能夠自動化地進行就更好了。

我們借助阿里巴巴的流量調度平臺(即阿里云  AHAS )可以完美地解決以下的問題:

  • 發布預熱問題,避免發布帶來的 RT、Load 升高問題 進而引發 HSF 超時等問題;

  • 局部機器流量過高、受宿主機影響、慢調用過多、HSF線程滿帶來的服務不可用、RT過高等問題。

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

目前,我們約有 40 個應用已經接入流量調度平臺,每周調度機器流量 1000 余次,借助流量調度平臺我們可以不再關心單機故障引發的應用報警。

推薦工具&產品

  • 阿里應用高可用服務 AHAS

    https://help.aliyun.com/document_detail/90320.html

加入我們

本文已添加至『StabilityGuide』,該項目是阿里多位阿里技術工程師共同發起的穩定性領域的知識庫開源項目,涵蓋性能壓測、故障演練、JVM、應用容器、服務框架、流量調度、監控、診斷等多個技術領域,以更結構化的方式來打造穩定性領域的知識庫,歡迎您的加入。

:white_check_mark: @GitHub :

https://github.com/StabilityMan/StabilityGuide

:white_check_mark: @釘釘群:

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

本文作者:

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

/ 點擊下方圖片,報名參加 /

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

Tips:

# 點下“ 看”:heart:

# 然后,公眾號對話框內發送“ 包您滿意 ”,試試手氣?:laughing:

# 本期獎品是來自 淘寶心選的休閑帆布雙肩包。

原文 

https://mp.weixin.qq.com/s/lc2PTU4Osmjei850–XEHA

本站部分文章源于互聯網,本著傳播知識、有益學習和研究的目的進行的轉載,為網友免費提供。如有著作權人或出版方提出異議,本站將立即刪除。如果您對文章轉載有任何疑問請告之我們,以便我們及時糾正。

PS:推薦一個微信公眾號: askHarries 或者qq群:474807195,里面會分享一些資深架構師錄制的視頻錄像:有Spring,MyBatis,Netty源碼分析,高并發、高性能、分布式、微服務架構的原理,JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源,目前受益良多

轉載請注明原文出處:Harries Blog? » 10 人,2 個月:蝦米音樂的監控體系升級之路

贊 (0)
分享到:更多 ()

評論 1

  • 昵稱 (必填)
  • 郵箱 (必填)
  • 網址
  1. repostone非技術的路過。回復
手机彩票计划软件超稳