經(jīng)過幾年的平臺建設(shè)，vivo監(jiān)控平臺產(chǎn)品矩陣日趨完善，在vivo終端龐大的用戶群體下，承載業(yè)務(wù)運(yùn)行的服務(wù)數(shù)量眾多，監(jiān)控服務(wù)體系是業(yè)務(wù)可用性保障的重要一環(huán)，監(jiān)控產(chǎn)品全場景覆蓋生產(chǎn)環(huán)境各個環(huán)節(jié)。從事前發(fā)現(xiàn)，事中告警、定位、恢復(fù)，事后復(fù)盤總結(jié)，監(jiān)控服務(wù)平臺都提供了豐富的工具包。從以前的水平拆分，按場景建設(shè)，到后來的垂直劃分，整合統(tǒng)一，降低平臺割裂感。同時從可觀測性、AIOps、云原生等方向，監(jiān)控平臺也進(jìn)行了建設(shè)實(shí)踐。未來vivo監(jiān)控平臺將會向著全場景、一站式、全鏈路、智能化方向不斷探索前行。

監(jiān)控服務(wù)平臺是自研的、覆蓋全場景的可用性保障系統(tǒng)。經(jīng)過多年深耕，vivo監(jiān)控團(tuán)隊(duì)已經(jīng)成體系構(gòu)筑起一整套穩(wěn)定性保障系統(tǒng)，隨著云原生可觀測技術(shù)變革不斷深化，監(jiān)控團(tuán)隊(duì)如何掌舵前行？下面就平臺的建設(shè)歷程、思考、探索，做一下簡單介紹。

(相關(guān)資料圖)

一、監(jiān)控體系建設(shè)之道1.1 監(jiān)控建設(shè)歷程

回顧監(jiān)控建設(shè)歷程，最初采用Zabbix，與告警中心的組合實(shí)現(xiàn)簡易監(jiān)控。隨著業(yè)務(wù)的發(fā)展在復(fù)雜監(jiān)控場景和數(shù)據(jù)量不斷增長的情況下，這種簡易的組合就顯的捉襟見肘。所以從2018年開始我們開啟了自研之路，最開始我們建設(shè)了應(yīng)用監(jiān)控、日志監(jiān)控、撥測監(jiān)控解決了很大一部分監(jiān)控場景沒有覆蓋的問題；2019年我們建設(shè)了基礎(chǔ)監(jiān)控、自定義監(jiān)控等，完成了主要監(jiān)控場景的基本覆蓋；2020年我們在完善前期監(jiān)控產(chǎn)品的同時，進(jìn)一步對周邊產(chǎn)品進(jìn)行了建設(shè)；隨著AI技術(shù)的不斷成熟，我們從2021年開始也進(jìn)行了轉(zhuǎn)型升級，先后建設(shè)了故障定位平臺、統(tǒng)一告警平臺有了這些平臺后我們發(fā)現(xiàn)，要想進(jìn)一步提升平臺價值，數(shù)據(jù)和平臺的統(tǒng)一至關(guān)重要；所以從2022年開始建設(shè)了統(tǒng)一監(jiān)控平臺，也就是將基礎(chǔ)監(jiān)控、應(yīng)用監(jiān)控和自定義監(jiān)控進(jìn)行了統(tǒng)一，統(tǒng)一監(jiān)控包含了統(tǒng)一配置服務(wù)和統(tǒng)一檢測服務(wù)。從監(jiān)控的建設(shè)歷程來看，我們一路覆蓋了IaaS、PaaS、DaaS、CaaS等平臺。我們的職能也從DevOps向AIOps邁進(jìn)。

1.2 監(jiān)控能力矩陣

講了監(jiān)控的發(fā)展歷程，那么這些監(jiān)控產(chǎn)品在我們的生產(chǎn)環(huán)境中是如何分布的呢？要想支撐數(shù)以萬計的業(yè)務(wù)運(yùn)行，需要龐雜的系統(tǒng)支撐，服務(wù)器、網(wǎng)絡(luò)環(huán)境、基礎(chǔ)組件等，都需要監(jiān)控系統(tǒng)保障它的穩(wěn)定性。我們將監(jiān)控的對象分為五層，在基礎(chǔ)設(shè)施層，包含了網(wǎng)絡(luò)設(shè)備、服務(wù)器、存儲硬件等，這一層我們通過VGW監(jiān)控對網(wǎng)絡(luò)設(shè)備進(jìn)行監(jiān)控，VGW是Vivo Gateway的縮寫，類似于LVS；通過自定義監(jiān)控，對機(jī)房進(jìn)行監(jiān)控；系統(tǒng)服務(wù)器層，我們定義的監(jiān)控對象是服務(wù)運(yùn)行依賴的環(huán)境，通過主機(jī)監(jiān)控對物理機(jī)、虛擬機(jī)等監(jiān)控，當(dāng)前容器在云原生技術(shù)體系中，已然成為微服務(wù)運(yùn)行的最佳載體，所以對容器的監(jiān)控必不可少；系統(tǒng)服務(wù)層，包含了各種數(shù)據(jù)庫產(chǎn)品、大數(shù)據(jù)組件等，在這一層主要通過自定義監(jiān)控檢測、告警；業(yè)務(wù)應(yīng)用層，主要有應(yīng)用服務(wù)，我們通過應(yīng)用監(jiān)控對業(yè)務(wù)鏈路信息進(jìn)行監(jiān)控；客戶體驗(yàn)層，我們定義了端上的訪問質(zhì)量，由宙斯平臺實(shí)現(xiàn)監(jiān)控。前面我們講了監(jiān)控能力矩陣，下面我們具體介紹一下監(jiān)控的范圍和整個平臺的能力。

1.3 監(jiān)控對象范圍

監(jiān)控對象涉及網(wǎng)絡(luò)、主機(jī)、基礎(chǔ)服務(wù)等。面對各地機(jī)房我們做到了監(jiān)控全覆蓋，為滿足各類環(huán)境部署訴求，我們可以做到針對不同環(huán)境的監(jiān)控。我們支持多種采集方式，SDK和API采集主要應(yīng)用在自定義監(jiān)控場景，Agent主要采集主機(jī)類指標(biāo)，采集上來的時序數(shù)據(jù)經(jīng)過預(yù)聚合、統(tǒng)一的數(shù)據(jù)清洗，然后存儲在TSDB數(shù)據(jù)庫。針對海量數(shù)據(jù)存儲我們采用了數(shù)據(jù)降精，寬表多維多指標(biāo)等方案。我們常用的檢測算法有恒值檢測、突變檢測、同比檢測等，同時還支持了無數(shù)據(jù)檢測、多指標(biāo)組合檢測，檢測出現(xiàn)的異常我們會形成一個問題，問題在經(jīng)過一系列的收斂后發(fā)出告警，我們有多種告警通道，支持告警合并、認(rèn)領(lǐng)、升級等，需要展示的指標(biāo)數(shù)據(jù)我們提供了豐富的自定義指標(biāo)看板，對使用頻率高 固化場景，我們提供了模板化配置方案。有了完備的監(jiān)控體系，那么系統(tǒng)的關(guān)鍵指標(biāo)和監(jiān)控對象體量如何？

1.4 監(jiān)控系統(tǒng)體量

當(dāng)前監(jiān)控服務(wù)體系保障著x萬+的主機(jī)實(shí)例，x萬+的DB實(shí)例，每天處理x千億條各類指標(biāo)和日志，對x千+的域名做到秒級監(jiān)控，對x萬+的容器實(shí)例監(jiān)控，每天從統(tǒng)一告警發(fā)出的各類告警達(dá)到x十萬+ ，對主機(jī)實(shí)例的監(jiān)控覆蓋率達(dá)到x %，監(jiān)控平臺通過不斷的探索實(shí)踐，實(shí)現(xiàn)了對海量數(shù)據(jù)計算存儲，當(dāng)前對核心業(yè)務(wù)的告警延遲在x秒以內(nèi)，告警召回率大于x %。

1.5 監(jiān)控系統(tǒng)面臨挑戰(zhàn)

雖然現(xiàn)階段取得了一些成果，但是目前仍然面臨很多挑戰(zhàn)，主要分為三大類：

部署環(huán)境復(fù)雜對數(shù)以萬計的主機(jī)和容器，實(shí)時采集 計算是一項(xiàng)困難的事情；面對各地機(jī)房監(jiān)控，部署過程中依賴項(xiàng)多，維護(hù)工作復(fù)雜；對海量數(shù)據(jù)計算存儲，保障監(jiān)控服務(wù)穩(wěn)定性、可用性難度大。平臺系統(tǒng)繁多當(dāng)前系統(tǒng)還存在割裂，用戶體驗(yàn)不強(qiáng)；數(shù)據(jù)割裂，沒有從底層融合在一起，對于數(shù)據(jù)組合使用形成挑戰(zhàn)。新技術(shù)挑戰(zhàn)首先基于容器的監(jiān)控方案，對傳統(tǒng)監(jiān)控方案形成挑戰(zhàn)，當(dāng)前對Prometheus指標(biāo)存儲處在探索階段，暫時沒有標(biāo)準(zhǔn)的解決方案，但是面對快速增長的數(shù)據(jù)量，新組件的探索試錯成本相對較高。二、監(jiān)控服務(wù)體系架構(gòu)2.1 產(chǎn)品架構(gòu)

產(chǎn)品架構(gòu)的能力服務(wù)層，我們定義了采集能力、檢測能力、告警能力等；功能層我們對這些能力做了具體實(shí)現(xiàn)，我們將監(jiān)控分為主機(jī)、容器、DB等9類場景，展示層主要由Dashboard提供靈活的圖表配置能力，日志中心負(fù)責(zé)日志查詢，移動端可以對告警信息進(jìn)行認(rèn)領(lǐng)、屏蔽。

2.2 技術(shù)架構(gòu)

技術(shù)架構(gòu)層分為采集、計算、存儲、可視化幾大塊，首先在采集層我們通過各種采集方式進(jìn)行指標(biāo)采集；上報的數(shù)據(jù)主要通過Bees-Bus進(jìn)行傳輸，Bees-Bus是一款公司自研的分布式、高可用的數(shù)據(jù)收集系統(tǒng)，指標(biāo)經(jīng)過Bees-Bus之后寫入Kafka，隨著Pulsar的受關(guān)注度與使用量的顯著增加，我們也在這方面進(jìn)行了一定的探索；計算層我們經(jīng)歷了Spark、Flink、KafkaStream幾個階段的探索，基本實(shí)現(xiàn)了計算層技術(shù)棧收歸到KafkaStream；數(shù)據(jù)主要存儲在Druid，當(dāng)前有190+節(jié)點(diǎn)的Druid集群。Opentsdb和Hive早期應(yīng)用在主機(jī)監(jiān)控場景，隨著業(yè)務(wù)發(fā)展其性能已經(jīng)不能勝任當(dāng)前的寫入和查詢需求，所以逐步被舍棄。

當(dāng)前我們選用了VictoriaMetrics作為Prometheus的遠(yuǎn)端存儲，日志信息存儲在ES中，目前我們有250+的ES節(jié)點(diǎn)。服務(wù)層中各類監(jiān)控場景的元數(shù)據(jù)，都由統(tǒng)一元數(shù)據(jù)服務(wù)提供；各類檢測規(guī)則、告警規(guī)則都由統(tǒng)一配置服務(wù)維護(hù)，統(tǒng)一告警服務(wù)則負(fù)責(zé)告警的收斂、合并、發(fā)送等。Grafana則主要用作自監(jiān)控告警。

2.3 交互流程

在監(jiān)控架構(gòu)的基礎(chǔ)上，我們介紹一下整體交互流程，采集規(guī)則由統(tǒng)一元數(shù)據(jù)服務(wù)管理，并主動下發(fā)到VCS-Master，VCS-Master主要用來任務(wù)下發(fā)，Agent執(zhí)行結(jié)果數(shù)據(jù)接收，任務(wù)查詢和配置管理等，Agent會定期從VCS-Master拉取緩存的采集規(guī)則，指標(biāo)經(jīng)過Bees-Bus雙寫到Kafka，由ETL程序?qū)χ笜?biāo)數(shù)據(jù)消費(fèi)，然后做清洗和計算，最后統(tǒng)一寫入到存儲服務(wù)中，統(tǒng)一配置服務(wù)下發(fā)檢測規(guī)則到異常檢測服務(wù)，檢測出的異常信息推送到Kafka，由告警代理服務(wù)對異常信息進(jìn)行富化，處理好的數(shù)據(jù)推到Kafka，然后由統(tǒng)一告警服務(wù)消費(fèi)處理。在存儲服務(wù)之上，我們做了一層查詢網(wǎng)關(guān)，所有的查詢會經(jīng)過網(wǎng)關(guān)代理。

三、可用性體系構(gòu)建與保障3.1 可用性體系構(gòu)建

前面說了監(jiān)控服務(wù)體系整體架構(gòu)，那么監(jiān)控產(chǎn)品如何服務(wù)于業(yè)務(wù)可用性。我們將業(yè)務(wù)穩(wěn)定性在時間軸上進(jìn)行分割，不同的時段有不同的系統(tǒng)保障業(yè)務(wù)可用性，當(dāng)前我們主要關(guān)注MTTD和MTTR，告警延遲越小發(fā)現(xiàn)故障的速度也就越快，系統(tǒng)維修時間越短說明系統(tǒng)恢復(fù)速度越快，我們將MTTR指標(biāo)拆解細(xì)化然后各個擊破，最終達(dá)成可用性保障要求。vivo監(jiān)控服務(wù)體系提供了，涵蓋在穩(wěn)定性建設(shè)中需要的故障預(yù)防、故障發(fā)現(xiàn)等全場景工具包，監(jiān)控平臺提供了產(chǎn)品工具，那么與運(yùn)維人員，研發(fā)人員是怎樣協(xié)作配合的？

3.2 系統(tǒng)可用性保障

當(dāng)監(jiān)控對象有問題時，監(jiān)控系統(tǒng)就會發(fā)送告警給運(yùn)維人員或業(yè)務(wù)開發(fā)，他們通過查看相關(guān)指標(biāo)修復(fù)問題。使用過程中運(yùn)維人員的訴求和疑問，由監(jiān)控平臺產(chǎn)品和開發(fā)協(xié)同配合解決，我們通過運(yùn)營指標(biāo)，定期梳理出不合理的告警，將對應(yīng)的檢測規(guī)則同步給運(yùn)維同學(xué)，然后制定調(diào)整計劃，后期我們計劃結(jié)合智能檢測，做到零配置就能檢測出異常指標(biāo)。通過監(jiān)控開發(fā)、運(yùn)維人員和業(yè)務(wù)開發(fā)一起協(xié)同配合，保障業(yè)務(wù)的可用性。

3.3 監(jiān)控系統(tǒng)可用性

除了保障業(yè)務(wù)可用性外，監(jiān)控系統(tǒng)自身的可用性保障也是一個重要的課題。為了保障Agent存活，我們構(gòu)建了多種維活機(jī)制，保障端上指標(biāo)采集正常。數(shù)據(jù)經(jīng)過Bees-Bus之后，會雙寫到兩個機(jī)房，當(dāng)有一個機(jī)房出現(xiàn)故障，會快速切到另一個機(jī)房，保障核心業(yè)務(wù)不受損。數(shù)據(jù)鏈路的每一層都有自監(jiān)控。監(jiān)控平臺通過Grafana監(jiān)控告警。

3.4 復(fù)雜場景下依托監(jiān)控解決問題手段 監(jiān)控能力矩陣

隨著公司業(yè)務(wù)發(fā)展，業(yè)務(wù)模型、部署架構(gòu)越來越復(fù)雜，讓故障定位很困難，定位問題成本高。而監(jiān)控系統(tǒng)在面對復(fù)雜、異構(gòu)、調(diào)用關(guān)系冗長的系統(tǒng)時就起到了重要作用。在問題發(fā)現(xiàn)階段，例如多服務(wù)串聯(lián)調(diào)用，如果某個階段，出現(xiàn)耗時比較大的情況，可以通過應(yīng)用監(jiān)控，降低問題排查難度。在告警通知階段，可以通過統(tǒng)一告警對異常統(tǒng)一收斂，然后根據(jù)告警策略，通知給運(yùn)維或者開發(fā)。問題定位時，可以利用故障定位服務(wù)找到最可能出現(xiàn)問題的服務(wù)。解決問題時，類似磁盤打滿這種比較常見的故障，可以通過回調(diào)作業(yè)快速排障。復(fù)盤改進(jìn)階段，故障管理平臺可以統(tǒng)一管理，全流程復(fù)盤，使解決過程可追溯。預(yù)防演練階段，在服務(wù)上線前，可以對服務(wù)進(jìn)行壓力測試，根據(jù)指標(biāo)設(shè)置容量。

四、行業(yè)變革下的監(jiān)控探索實(shí)踐及未來規(guī)劃4.1 云原生：Prometheus監(jiān)控

當(dāng)前行業(yè)正迎來快速變革，我們在云原生、AIOps、可觀性等方向均進(jìn)行了探索實(shí)踐。未來我們也想緊跟行業(yè)熱點(diǎn)，繼續(xù)深挖產(chǎn)品價值。隨著Kubernetes成為容器編排領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，Prometheus因?yàn)閷θ萜鞅O(jiān)控良好的適配，使其成為云原生時代，容器監(jiān)控的事實(shí)標(biāo)準(zhǔn)。下面我們介紹一下整體架構(gòu)，我們將容器監(jiān)控分為容器集群監(jiān)控和容器業(yè)務(wù)監(jiān)控，首先對于容器集群監(jiān)控，每個生產(chǎn)集群都有獨(dú)立的監(jiān)控節(jié)點(diǎn)，用于部署監(jiān)控組件，Prometheus按照采集目標(biāo)服務(wù)劃分為多組，數(shù)據(jù)存儲采用VictoriaMetrics，我們簡稱VM，同一機(jī)房的Prometheus集群，均將監(jiān)控數(shù)據(jù)Remote-Write到VM中，VM配置為多副本存儲。通過撥測監(jiān)控，實(shí)現(xiàn)對Prometheus自監(jiān)控，保障Prometheus異常時能收到告警信息。容器業(yè)務(wù)監(jiān)控方面，Agent部署在宿主機(jī)，并從Cadvisor拉取指標(biāo)數(shù)據(jù)，上報到Bees-Bus，Bees-Bus將數(shù)據(jù)雙寫到兩個Kafka集群，統(tǒng)一檢測服務(wù)異步檢測指標(biāo)數(shù)據(jù)，業(yè)務(wù)監(jiān)控指標(biāo)數(shù)據(jù)采用VM做遠(yuǎn)端存儲，Dashboard通過Promql語句查詢展示指標(biāo)數(shù)據(jù)。

4.2 AIOps：故障定位

當(dāng)前業(yè)界對AIOps的探索，大部分在一些細(xì)分場景，我們也在故障定位這個方向進(jìn)行了探索。分析過程中首先通過CMDB節(jié)點(diǎn)樹，選定需要分析的項(xiàng)目節(jié)點(diǎn)，然后選擇需要分析的時段，就可以按組件和服務(wù)下鉆分析，通過計算得出每個下游服務(wù)的波動方差，再利用K-Means聚類，過濾掉波動較小的聚類，找到可能出現(xiàn)異常的服務(wù)或組件。分析過程會形成一張原因鏈路圖，方便用戶快速找到異常服務(wù)，分析結(jié)果會推薦給用戶，告知用戶最可能出現(xiàn)異常的原因。詳情查看功能可以看到被調(diào)用的下游服務(wù)、接口名、耗時等信息。

4.3可觀測性：可用性大盤

由于CNCF在云原生的定義中提到了Observerbility，所以近兩年可觀性，成了技術(shù)圈很火熱的關(guān)鍵詞。當(dāng)前業(yè)界基于Metrics、Logs、Traces對可觀測性形成了一定共識。谷歌也給出了可觀測的核心價值就是快速排障。我們認(rèn)為指標(biāo)、日志、追蹤是實(shí)現(xiàn)可觀測性的基礎(chǔ)，在此基礎(chǔ)上將三者有機(jī)融合，針對不同的場景將他們串聯(lián)在一起，實(shí)現(xiàn)方便快捷的查找故障根因，綜上我們建設(shè)了可用性大盤，它能查看服務(wù)的健康狀況，通過下鉆，可以看到上下游服務(wù)依賴關(guān)系、域名健康狀況、后端服務(wù)分布等。通過串聯(lián)跳轉(zhuǎn)等方式可以看到對應(yīng)服務(wù)的日志和指標(biāo)信息。

4.4 場景串聯(lián)

未來我們希望在場景串聯(lián)、可觀測性、服務(wù)能力化進(jìn)一步探索，深挖產(chǎn)品價值。場景串聯(lián)上：

首先我們希望告警能夠與故障定位平臺串聯(lián)，幫助用戶快速找到故障根因，縮短排查時間；告警記錄能夠一鍵轉(zhuǎn)為事件，減少數(shù)據(jù)鏈路中人為操作的環(huán)節(jié)，保障數(shù)據(jù)的真實(shí)性；我們希望能與CMDB等平臺打通，將數(shù)據(jù)價值最大化。4.5 統(tǒng)一可觀測

現(xiàn)在，vivo監(jiān)控服務(wù)體系的可觀測產(chǎn)品沒有完全融合在一起，所以后續(xù)我們希望構(gòu)建統(tǒng)一可觀測平臺：

在一元場景中，可以單獨(dú)查看指標(biāo)、日志、追蹤信息；在轉(zhuǎn)化場景中，能夠通過日志獲得指標(biāo)數(shù)據(jù)，對日志的聚合和轉(zhuǎn)化得到追蹤，利用調(diào)用鏈的分析，獲得調(diào)用范圍內(nèi)的指標(biāo)。通過指標(biāo)、日志、追蹤多個維度找到故障的源頭；在二元場景，我們希望日志和指標(biāo)、日志和追蹤、追蹤和指標(biāo)能夠相互結(jié)合，聚合分析。4.6 能力服務(wù)化

目前監(jiān)控有很多服務(wù)，在公司構(gòu)建混合云平臺的大背景下，監(jiān)控系統(tǒng)的服務(wù)應(yīng)該具備以能力化的方式提供出去。未來我們希望指標(biāo)、圖表、告警等，以API或者獨(dú)立服務(wù)的方式提供能力，例如在CICD服務(wù)部署過程中，就可以通過監(jiān)控提供的圖表能力，看到服務(wù)部署時關(guān)鍵指標(biāo)變化情況，而不需要跳轉(zhuǎn)到監(jiān)控服務(wù)查看指標(biāo)信息。

最后，我們希望監(jiān)控能更好的保障業(yè)務(wù)可用性，在此基礎(chǔ)上，我們也希望通過監(jiān)控系統(tǒng)提升業(yè)務(wù)服務(wù)質(zhì)量。

關(guān)鍵詞： 監(jiān)控系統(tǒng) 故障定位 可觀測性 可能出現(xiàn) 介紹一下