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

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

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

1.1 監(jiān)控建設(shè)歷程

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

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

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

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

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

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

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

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

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

• 部署環(huán)境復(fù)雜

對(duì)數(shù)以萬(wàn)計(jì)的主機(jī)和容器，實(shí)時(shí)采集 計(jì)算是一項(xiàng)困難的事情；面對(duì)各地機(jī)房監(jiān)控，部署過(guò)程中依賴項(xiàng)多，維護(hù)工作復(fù)雜；對(duì)海量數(shù)據(jù)計(jì)算存儲(chǔ)，保障監(jiān)控服務(wù)穩(wěn)定性、可用性難度大。

• 平臺(tái)系統(tǒng)繁多

當(dāng)前系統(tǒng)還存在割裂，用戶體驗(yàn)不強(qiáng)；數(shù)據(jù)割裂，沒(méi)有從底層融合在一起，對(duì)于數(shù)據(jù)組合使用形成挑戰(zhàn)。

• 新技術(shù)挑戰(zhàn)

首先基于容器的監(jiān)控方案，對(duì)傳統(tǒng)監(jiān)控方案形成挑戰(zhàn)，當(dāng)前對(duì)Prometheus指標(biāo)存儲(chǔ)處在探索階段，暫時(shí)沒(méi)有標(biāo)準(zhǔn)的解決方案，但是面對(duì)快速增長(zhǎng)的數(shù)據(jù)量，新組件的探索試錯(cuò)成本相對(duì)較高。

二、監(jiān)控服務(wù)體系架構(gòu)

2.1 產(chǎn)品架構(gòu)

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

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

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

當(dāng)前我們選用了VictoriaMetrics作為Prometheus的遠(yuǎn)端存儲(chǔ)，日志信息存儲(chǔ)在ES中，目前我們有250+的ES節(jié)點(diǎn)。服務(wù)層中各類監(jiān)控場(chǎng)景的元數(shù)據(jù)，都由統(tǒng)一元數(shù)據(jù)服務(wù)提供；各類檢測(cè)規(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ù)管理，并主動(dòng)下發(fā)到VCS-Master，VCS-Master主要用來(lái)任務(wù)下發(fā)，Agent執(zhí)行結(jié)果數(shù)據(jù)接收，任務(wù)查詢和配置管理等，Agent會(huì)定期從VCS-Master拉取緩存的采集規(guī)則，指標(biāo)經(jīng)過(guò)Bees-Bus雙寫(xiě)到Kafka，由ETL程序?qū)χ笜?biāo)數(shù)據(jù)消費(fèi)，然后做清洗和計(jì)算，最后統(tǒng)一寫(xiě)入到存儲(chǔ)服務(wù)中，統(tǒng)一配置服務(wù)下發(fā)檢測(cè)規(guī)則到異常檢測(cè)服務(wù)，檢測(cè)出的異常信息推送到Kafka，由告警代理服務(wù)對(duì)異常信息進(jìn)行富化，處理好的數(shù)據(jù)推到Kafka，然后由統(tǒng)一告警服務(wù)消費(fèi)處理。在存儲(chǔ)服務(wù)之上，我們做了一層查詢網(wǎng)關(guān)，所有的查詢會(huì)經(jīng)過(guò)網(wǎng)關(guān)代理。

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

3.1 可用性體系構(gòu)建

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

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

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

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

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

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

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

四、行業(yè)變革下的監(jiān)控探索實(shí)踐及未來(lái)規(guī)劃

4.1 云原生：Prometheus監(jiān)控

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

4.2 AIOps：故障定位

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

4.3 可觀測(cè)性：可用性大盤(pán)

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

4.4 場(chǎng)景串聯(lián)

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

首先我們希望告警能夠與故障定位平臺(tái)串聯(lián)，幫助用戶快速找到故障根因，縮短排查時(shí)間 ；

告警記錄能夠一鍵轉(zhuǎn)為事件，減少數(shù)據(jù)鏈路中人為操作的環(huán)節(jié)，保障數(shù)據(jù)的真實(shí)性；

我們希望能與CMDB等平臺(tái)打通，將數(shù)據(jù)價(jià)值最大化。 

4.5 統(tǒng)一可觀測(cè)

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

在一元場(chǎng)景中，可以單獨(dú)查看指標(biāo)、日志、追蹤信息；

在轉(zhuǎn)化場(chǎng)景中，能夠通過(guò)日志獲得指標(biāo)數(shù)據(jù)，對(duì)日志的聚合和轉(zhuǎn)化得到追蹤，利用調(diào)用鏈的分析，獲得調(diào)用范圍內(nèi)的指標(biāo)。通過(guò)指標(biāo)、日志、追蹤多個(gè)維度找到故障的源頭；

在二元場(chǎng)景，我們希望日志和指標(biāo)、日志和追蹤、追蹤和指標(biāo)能夠相互結(jié)合，聚合分析。

4.6 能力服務(wù)化

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

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