作者：vivo 互聯(lián)網(wǎng)服務(wù)器團(tuán)隊(duì)- Chen Ningning

本文根據(jù)“2022 vivo開發(fā)者大會(huì)"現(xiàn)場演講內(nèi)容整理而成。

經(jīng)過幾年的平臺(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ǎn)環(huán)境各個(gè)環(huán)節(jié)。從事前發(fā)現(xiàn)讲弄，事中告警措左、定位、恢復(fù)垂睬，事后復(fù)盤總結(jié)媳荒，監(jiān)控服務(wù)平臺(tái)都提供了豐富的工具包抗悍。從以前的水平拆分，按場景建設(shè)钳枕，到后來的垂直劃分缴渊，整合統(tǒng)一，降低平臺(tái)割裂感鱼炒。同時(shí)從可觀測性衔沼、AIOps、云原生等方向昔瞧，監(jiān)控平臺(tái)也進(jìn)行了建設(shè)實(shí)踐指蚁。未來vivo監(jiān)控平臺(tái)將會(huì)向著全場景、一站式自晰、全鏈路凝化、智能化方向不斷探索前行。

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

一深员、監(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)品的同時(shí)，進(jìn)一步對(duì)周邊產(chǎn)品進(jìn)行了建設(shè)宏怔；隨著AI技術(shù)的不斷成熟奏路，我們從2021年開始也進(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年開始建設(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)一檢測服務(wù)儡首。從監(jiān)控的建設(shè)歷程來看片任，我們一路覆蓋了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ù)以萬計(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ǔ)硬件等，這一層我們通過VGW監(jiān)控對(duì)網(wǎng)絡(luò)設(shè)備進(jìn)行監(jiān)控较鼓，VGW是Vivo Gateway的縮寫椎木，類似于LVS；通過自定義監(jiān)控博烂，對(duì)機(jī)房進(jìn)行監(jiān)控香椎；系統(tǒng)服務(wù)器層，我們定義的監(jiān)控對(duì)象是服務(wù)運(yùn)行依賴的環(huán)境禽篱，通過主機(jī)監(jiān)控對(duì)物理機(jī)畜伐、虛擬機(jī)等監(jiān)控，當(dāng)前容器在云原生技術(shù)體系中躺率，已然成為微服務(wù)運(yùn)行的最佳載體玛界，所以對(duì)容器的監(jiān)控必不可少万矾；系統(tǒng)服務(wù)層，包含了各種數(shù)據(jù)庫產(chǎn)品慎框、大數(shù)據(jù)組件等良狈，在這一層主要通過自定義監(jiān)控檢測、告警鲤脏；業(yè)務(wù)應(yīng)用層们颜，主要有應(yīng)用服務(wù)，我們通過應(yīng)用監(jiān)控對(duì)業(yè)務(wù)鏈路信息進(jìn)行監(jiān)控猎醇；客戶體驗(yà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)控場景衡未，Agent主要采集主機(jī)類指標(biāo)，采集上來的時(shí)序數(shù)據(jù)經(jīng)過預(yù)聚合家凯、統(tǒng)一的數(shù)據(jù)清洗缓醋，然后存儲(chǔ)在TSDB數(shù)據(jù)庫。針對(duì)海量數(shù)據(jù)存儲(chǔ)我們采用了數(shù)據(jù)降精绊诲，寬表多維多指標(biāo)等方案送粱。我們常用的檢測算法有恒值檢測、突變檢測掂之、同比檢測等突那，同時(shí)還支持了無數(shù)據(jù)檢測梁棠、多指標(biāo)組合檢測顺呕，檢測出現(xiàn)的異常我們會(huì)形成一個(gè)問題端礼，問題在經(jīng)過一系列的收斂后發(fā)出告警，我們有多種告警通道冯乘，支持告警合并洽胶、認(rèn)領(lǐng)、升級(jí)等，需要展示的指標(biāo)數(shù)據(jù)我們提供了豐富的自定義指標(biāo)看板姊氓，對(duì)使用頻率高 固化場景丐怯，我們提供了模板化配置方案。有了完備的監(jiān)控體系翔横，那么系統(tǒng)的關(guān)鍵指標(biāo)和監(jiān)控對(duì)象體量如何读跷？

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

當(dāng)前監(jiān)控服務(wù)體系保障著x萬+的主機(jī)實(shí)例，x萬+的DB實(shí)例禾唁，每天處理x千億條各類指標(biāo)和日志效览，對(duì)x千+的域名做到秒級(jí)監(jiān)控，對(duì)x萬+的容器實(shí)例監(jiān)控荡短，每天從統(tǒng)一告警發(fā)出的各類告警達(dá)到x十萬+ 丐枉，對(duì)主機(jī)實(shí)例的監(jiān)控覆蓋率達(dá)到x %，監(jiān)控平臺(tái)通過不斷的探索實(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ù)以萬計(jì)的主機(jī)和容器泪掀，實(shí)時(shí)采集 計(jì)算是一項(xiàng)困難的事情听绳；面對(duì)各地機(jī)房監(jiān)控，部署過程中依賴項(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ù)割裂，沒有從底層融合在一起澎胡，對(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í)沒有標(biāo)準(zhǔn)的解決方案，但是面對(duì)快速增長的數(shù)據(jù)量戚宦，新組件的探索試錯(cuò)成本相對(duì)較高个曙。

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

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

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

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

技術(shù)架構(gòu)層分為采集、計(jì)算非驮、存儲(chǔ)交汤、可視化幾大塊，首先在采集層我們通過各種采集方式進(jìn)行指標(biāo)采集劫笙；上報(bà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ì)算層我們經(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)控場景褐隆，隨著業(yè)務(wù)發(fā)展其性能已經(jīng)不能勝任當(dāng)前的寫入和查詢需求，所以逐步被舍棄剖踊。

當(dāng)前我們選用了VictoriaMetrics作為Prometheus的遠(yuǎn)端存儲(chǔ)庶弃，日志信息存儲(chǔ)在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ù)管理栈暇，并主動(dòng)下發(fā)到VCS-Master，VCS-Master主要用來任務(wù)下發(fā)箍镜，Agent執(zhí)行結(jié)果數(shù)據(jù)接收源祈，任務(wù)查詢和配置管理等，Agent會(huì)定期從VCS-Master拉取緩存的采集規(guī)則色迂，指標(biāo)經(jīng)過Bees-Bus雙寫到Kafka香缺，由ETL程序?qū)χ笜?biāo)數(shù)據(jù)消費(fèi)，然后做清洗和計(jì)算歇僧，最后統(tǒng)一寫入到存儲(chǔ)服務(wù)中图张，統(tǒng)一配置服務(wù)下發(fā)檢測規(guī)則到異常檢測服務(wù)，檢測出的異常信息推送到Kafka诈悍，由告警代理服務(wù)對(duì)異常信息進(jìn)行富化祸轮，處理好的數(shù)據(jù)推到Kafka，然后由統(tǒng)一告警服務(wù)消費(fèi)處理侥钳。在存儲(chǔ)服務(wù)之上适袜，我們做了一層查詢網(wǎng)關(guān)，所有的查詢會(huì)經(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)定性在時(shí)間軸上進(jìn)行分割疫萤，不同的時(shí)段有不同的系統(tǒng)保障業(yè)務(wù)可用性，當(dāng)前我們主要關(guān)注MTTD和MTTR敢伸，告警延遲越小發(fā)現(xiàn)故障的速度也就越快给僵，系統(tǒng)維修時(shí)間越短說明系統(tǒng)恢復(fù)速度越快，我們將MTTR指標(biāo)拆解細(xì)化然后各個(gè)擊破详拙，最終達(dá)成可用性保障要求。vivo監(jiān)控服務(wù)體系提供了蔓同，涵蓋在穩(wěn)定性建設(shè)中需要的故障預(yù)防饶辙、故障發(fā)現(xiàn)等全場景工具包，監(jiān)控平臺(tái)提供了產(chǎn)品工具斑粱，那么與運(yùn)維人員弃揽，研發(fā)人員是怎樣協(xié)作配合的？

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

當(dāng)監(jiān)控對(duì)象有問題時(shí)，監(jiān)控系統(tǒng)就會(huì)發(fā)送告警給運(yùn)維人員或業(yè)務(wù)開發(fā)矿微，他們通過查看相關(guān)指標(biāo)修復(fù)問題痕慢。使用過程中運(yùn)維人員的訴求和疑問，由監(jiān)控平臺(tái)產(chǎn)品和開發(fā)協(xié)同配合解決涌矢，我們通過運(yùn)營指標(biāo)掖举，定期梳理出不合理的告警，將對(duì)應(yīng)的檢測規(guī)則同步給運(yùn)維同學(xué)娜庇，然后制定調(diào)整計(jì)劃塔次，后期我們計(jì)劃結(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)自身的可用性保障也是一個(gè)重要的課題。為了保障Agent存活汁掠，我們構(gòu)建了多種維活機(jī)制略吨，保障端上指標(biāo)采集正常。數(shù)據(jù)經(jīng)過Bees-Bus之后调塌，會(huì)雙寫到兩個(gè)機(jī)房晋南，當(dāng)有一個(gè)機(jī)房出現(xiàn)故障，會(huì)快速切到另一個(gè)機(jī)房羔砾，保障核心業(yè)務(wù)不受損负间。數(shù)據(jù)鏈路的每一層都有自監(jiān)控。監(jiān)控平臺(tái)通過Grafana監(jiān)控告警姜凄。

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

隨著公司業(yè)務(wù)發(fā)展政溃，業(yè)務(wù)模型、部署架構(gòu)越來越復(fù)雜态秧，讓故障定位很困難董虱，定位問題成本高。而監(jiān)控系統(tǒng)在面對(duì)復(fù)雜申鱼、異構(gòu)愤诱、調(diào)用關(guān)系冗長的系統(tǒng)時(shí)就起到了重要作用。在問題發(fā)現(xiàn)階段捐友，例如多服務(wù)串聯(lián)調(diào)用淫半，如果某個(gè)階段，出現(xiàn)耗時(shí)比較大的情況匣砖，可以通過應(yīng)用監(jiān)控科吭，降低問題排查難度昏滴。在告警通知階段，可以通過統(tǒng)一告警對(duì)異常統(tǒng)一收斂对人，然后根據(jù)告警策略谣殊，通知給運(yùn)維或者開發(fā)。問題定位時(shí)牺弄，可以利用故障定位服務(wù)找到最可能出現(xiàn)問題的服務(wù)姻几。解決問題時(shí)，類似磁盤打滿這種比較常見的故障猖闪，可以通過回調(diào)作業(yè)快速排障鲜棠。復(fù)盤改進(jìn)階段，故障管理平臺(tái)可以統(tǒng)一管理培慌，全流程復(fù)盤豁陆，使解決過程可追溯。預(yù)防演練階段吵护，在服務(wù)上線前盒音，可以對(duì)服務(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)品價(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晃跺，我們簡稱VM揩局，同一機(jī)房的Prometheus集群，均將監(jiān)控?cái)?shù)據(jù)Remote-Write到VM中哼审，VM配置為多副本存儲(chǔ)谐腰。通過撥測監(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ù)雙寫到兩個(gè)Kafka集群址儒，統(tǒng)一檢測服務(wù)異步檢測指標(biāo)數(shù)據(jù)芹枷，業(yè)務(wù)監(jiān)控指標(biāo)數(shù)據(jù)采用VM做遠(yuǎn)端存儲(chǔ)，Dashboard通過Promql語句查詢展示指標(biāo)數(shù)據(jù)莲趣。

4.2 AIOps：故障定位

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

4.3 可觀測性：可用性大盤

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

4.4 場景串聯(lián)

未來我們希望在場景串聯(lián)、可觀測性打厘、服務(wù)能力化進(jìn)一步探索修肠，深挖產(chǎn)品價(jià)值。場景串聯(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)一可觀測

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

• 在一元場景中缸浦，可以單獨(dú)查看指標(biāo)、日志氮兵、追蹤信息裂逐；

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

• 在二元場景薪缆，我們希望日志和指標(biāo)、日志和追蹤伞广、追蹤和指標(biāo)能夠相互結(jié)合拣帽，聚合分析疼电。

4.6 能力服務(wù)化

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

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