百度商业大规模微服务分布式监控系统-凤睛
導(dǎo)讀：作為鳳睛早期的接入方、后期的核心成員，筆者經(jīng)歷了整個(gè)項(xiàng)目前后四年的變遷，看過項(xiàng)目的艱難開端、中期的默默積累以及后期的蓬勃發(fā)展。每一次架構(gòu)的變遷都帶著技術(shù)浪潮的烙印，也看到項(xiàng)目成員利用有限資源來解決實(shí)際問題而持續(xù)不斷的創(chuàng)新。
鳳睛是百度商業(yè)業(yè)務(wù)系統(tǒng)的性能監(jiān)控系統(tǒng)（APM），它側(cè)重于對(duì)Java應(yīng)用的監(jiān)控，基本接入了百度絕大部分Java應(yīng)用（覆蓋數(shù)千個(gè)業(yè)務(wù)應(yīng)用，數(shù)萬個(gè)容器）。它能夠?qū)χ髁髦虚g件框架（ Spring Web、RPC、數(shù)據(jù)庫(kù)、緩存等）進(jìn)行自動(dòng)埋點(diǎn)，實(shí)現(xiàn)全棧式性能監(jiān)控和全鏈路追蹤診斷，為百度各業(yè)務(wù)線提供微服務(wù)系統(tǒng)性能指標(biāo)、業(yè)務(wù)黃金指標(biāo)、健康狀況、監(jiān)控告警等。
△鳳睛產(chǎn)品流程圖
- 數(shù)據(jù)采集：鳳睛探針技術(shù)能夠自動(dòng)植入到業(yè)務(wù)進(jìn)程中去，采集相關(guān)性能信息，業(yè)務(wù)進(jìn)程完全無感知。
- 數(shù)據(jù)計(jì)算和分析：按照類型，時(shí)序數(shù)據(jù)存儲(chǔ)在百度SIA智能監(jiān)控平臺(tái)的時(shí)序數(shù)據(jù)庫(kù)TSDB，用來生成可視化報(bào)表和異常報(bào)警。調(diào)用鏈數(shù)據(jù)會(huì)被存入Palo（ 開源名為Doris） 大數(shù)據(jù)倉(cāng)庫(kù)，用來拓?fù)浞治龊驼{(diào)用鏈檢索。
- 應(yīng)用場(chǎng)景：如上所述，鳳睛提供穩(wěn)定性報(bào)表、異常報(bào)警、錯(cuò)誤堆棧分析、服務(wù)耗時(shí)分析、調(diào)用拓?fù)浞治觥I(yè)務(wù)日志關(guān)聯(lián)分析等。
△鳳睛的架構(gòu)變遷時(shí)間線
01 鳳睛立項(xiàng)
項(xiàng)目發(fā)起在2016年，百度鳳巢廣告業(yè)務(wù)系統(tǒng)中間件 (分布式RPC框架 Stargate等、配置中心、數(shù)據(jù)庫(kù)中間件等)已經(jīng)完善。隨著單體服務(wù)拆分的深入，整體Java在線上部署規(guī)模逐漸變多，同時(shí)，暴露的問題也越來越多。
典型的問題有：
- 核心服務(wù)問題定位周期長(zhǎng)。多個(gè)模塊大量報(bào)錯(cuò)后，花費(fèi)了很長(zhǎng)時(shí)間才定位問題。
- 集群日志獲取代價(jià)非常高，缺乏日志調(diào)用鏈關(guān)系等原因?qū)е露ㄎ淮鷥r(jià)很高，甚至有些問題無法定位。
- 異常日志需要登錄具體的線上實(shí)例查看。而線上部署實(shí)例數(shù)目多，排錯(cuò)時(shí)間長(zhǎng)。
鳳巢業(yè)務(wù)端急需一個(gè)分布式追蹤系統(tǒng)來完成整個(gè)業(yè)務(wù)端日志的“大串聯(lián)”。所以百度商業(yè)平臺(tái)基礎(chǔ)架構(gòu)組發(fā)起了鳳睛的項(xiàng)目，名曰“鳳巢之眼”。
02 鳳睛1.0
在分布式鏈路追蹤領(lǐng)域，探針采集這個(gè)環(huán)節(jié)主要存在侵入式和無侵入式。1.0探針走的侵入方式。業(yè)務(wù)開發(fā)人員首先引入探針相關(guān)的依賴 jar 包，通過攔截器自動(dòng)收集調(diào)用關(guān)系以及性能數(shù)據(jù)；然后，添加硬編碼補(bǔ)充業(yè)務(wù)數(shù)據(jù)。
△編碼示例
探針采集的數(shù)據(jù)會(huì)被打印到磁盤，通過kafka收集走。底層的數(shù)據(jù)處理和數(shù)據(jù)存儲(chǔ)采用了Storm、 Hbase等當(dāng)時(shí)流行的數(shù)據(jù)處理系統(tǒng)。后端架構(gòu)比較復(fù)雜。
△鳳睛1.0架構(gòu)示意圖
03 鳳睛2.0
鳳睛2.0版本中，首先是降低探針接入成本。2.0版本中，探針改用java agent技術(shù)結(jié)合cglib 做AOP注解，把依賴引入的jar 包從N個(gè)降低到1個(gè)。從編寫大段的調(diào)用鏈填充代碼改為盡量走AOP。探針端傳輸層采用了更高效的傳輸協(xié)議（protobuffer+gzip）, 直接通過 HTTP 協(xié)議發(fā)送到 kafka，大大了降低磁盤IO開銷。
2.0探針較1.0接入方便，傳輸也更快。但是仍需業(yè)務(wù)方添加AOP代碼。對(duì)于業(yè)務(wù)端數(shù)以百計(jì)的應(yīng)用來說，接入仍然是大工程，推廣依然困難。
04 鳳睛3.0
鳳睛3.0架構(gòu)設(shè)計(jì)中，項(xiàng)目組成員一直在思考兩個(gè)問題：
對(duì)當(dāng)時(shí)幾種流行的監(jiān)控診斷工具進(jìn)行了調(diào)研：
△Newrelic，pinpoint，greys監(jiān)控探針調(diào)研
3.0探針參考了Greys支持運(yùn)行時(shí)增強(qiáng)的特點(diǎn)以及 pinpoint、Newrelic基于插件擴(kuò)展開發(fā)的設(shè)計(jì)理念。最終效果是探針能夠自動(dòng)對(duì)業(yè)務(wù)進(jìn)程植入監(jiān)控代碼，監(jiān)控具體工作交由插件體系完成，完全面向切面監(jiān)控。
△探針主動(dòng)加載示意圖
后端存儲(chǔ)系統(tǒng)轉(zhuǎn)而依托Doris。Doris是百度自研的基于 MPP 的交互式 SQL 數(shù)據(jù)倉(cāng)庫(kù)，兼容mysql協(xié)議，學(xué)習(xí)成本低。既可以做存儲(chǔ)又可以做分析計(jì)算，初期避免引入spark，storm等技術(shù)，降低系統(tǒng)復(fù)雜度。
△架構(gòu)設(shè)計(jì)如圖所示
架構(gòu)升級(jí)后，作為小團(tuán)隊(duì)，也能快速批量部署探針，計(jì)算存儲(chǔ)能力也能滿足需求。截止2017年，鳳睛3.0上線了100多個(gè)應(yīng)用，跑在1000多個(gè)容器上面。
05 鳳睛4.0
2018年，微服務(wù)和虛擬化浪潮席卷而來。隨著部署平臺(tái)的不斷升級(jí)和 springboot體系的成熟完善，單體能夠被快速拆分成了數(shù)目眾多的微服務(wù)，依托平臺(tái)進(jìn)行高效的運(yùn)維部署。鳳睛作為基礎(chǔ)組件被微服務(wù)托管平臺(tái)集成，并得到公司級(jí)的推廣應(yīng)用，整體部署應(yīng)用規(guī)模從百級(jí)別激增到了千級(jí)別，部署容器從千級(jí)別變成了萬級(jí)別。
這個(gè)階段爆發(fā)了很多問題，技術(shù)核心問題主要有兩點(diǎn)：
2019年，鳳睛進(jìn)行了進(jìn)一步的改造升級(jí)，針對(duì)1、2兩個(gè)問題，進(jìn)行了技術(shù)攻堅(jiān)。
探針層面研究如何支持熱插拔，也就是探針在業(yè)務(wù)進(jìn)程運(yùn)行的情況下自動(dòng)完成升級(jí)。起初為了保證業(yè)務(wù)類對(duì)探針插件類的可見性，探針類統(tǒng)一放到了 System Classloader里。但是System Classloader 作為系統(tǒng)默認(rèn)的，不支持卸載。反之，如果把探針類全部放到自定義類加載器中。探針類則對(duì)業(yè)務(wù)類完全不可見，也就無法完成字節(jié)碼增強(qiáng)。
△探針熱插拔classloader體系
為了解決可見性問題，探針引入了橋接類，通過橋接類提供的代碼樁和插件類庫(kù)投影，用戶類可以訪問實(shí)際使用的探針類，完成監(jiān)控改造的目的。對(duì)于不同插件，則放在不同的自定義 Classloader 里面。這樣來插件之間互不可見。單個(gè)插件也可以完成熱插拔。具體的設(shè)計(jì)細(xì)節(jié)后面會(huì)有文章詳細(xì)解讀。
毋庸置疑，鳳睛探針是業(yè)界唯一能夠熱插拔的監(jiān)控探針技術(shù)，我們也申請(qǐng)了專利。它的功能正確性和性能是經(jīng)歷過大規(guī)模線上流量驗(yàn)證的。
繼續(xù)推進(jìn)優(yōu)化調(diào)用鏈檢索的性能。
首先分析下我們的底層存儲(chǔ)結(jié)構(gòu)：
通過對(duì)慢查詢的分析，發(fā)現(xiàn)檢索慢主要是兩個(gè)原因：一是大量查詢沒有走任何索引，全表掃描海量數(shù)據(jù)非常慢。二是，導(dǎo)入碎片過多，導(dǎo)致文件Compaction特別慢，典型的LSM-Tree 的讀放大。為了解決這些問題，調(diào)用鏈存儲(chǔ)層重構(gòu)表結(jié)構(gòu)，通過大量Rollup配合基本表，優(yōu)化查詢時(shí)間。Doris 此時(shí)已經(jīng)具備流式導(dǎo)入的能力，也借機(jī)從小批量導(dǎo)入切換到流式導(dǎo)入。
△調(diào)用鏈處理架構(gòu)
△上圖是鳳睛實(shí)時(shí)構(gòu)建的微服務(wù)全景拓?fù)鋱D。截止2020年1月，大概涵蓋了數(shù)十條產(chǎn)品線的線上流量拓?fù)?#xff0c;最細(xì)粒度的節(jié)點(diǎn)為接口，即 Java 應(yīng)用中的函數(shù)。從圖中可以分析出，托管全平臺(tái)非孤島接口節(jié)點(diǎn)大概有50w+，接口節(jié)點(diǎn)連線200w+ 條。
06 數(shù)據(jù)處理架構(gòu)分離
架構(gòu)繼續(xù)演進(jìn)，鳳睛采集的數(shù)據(jù)量越來越多，業(yè)務(wù)方需求也越來越多。
主要面臨兩個(gè)問題：
這兩個(gè)問題歸根結(jié)底是時(shí)序數(shù)據(jù)如何存儲(chǔ)和展現(xiàn)。這涉及到分布式追蹤領(lǐng)域兩個(gè)很基礎(chǔ)的概念，時(shí)序時(shí)間和調(diào)用鏈數(shù)據(jù)。所謂的時(shí)序數(shù)據(jù)是基于時(shí)間的一系列的數(shù)據(jù)，用于查看一些指標(biāo)數(shù)據(jù)和指標(biāo)趨勢(shì)。調(diào)用鏈數(shù)據(jù)是指記錄一個(gè)請(qǐng)求的全部流程，用于查看請(qǐng)求在哪個(gè)環(huán)節(jié)出了故障，系統(tǒng)的瓶頸在哪兒。
時(shí)序數(shù)據(jù)不需要保存細(xì)節(jié)，只存時(shí)間、維度和指標(biāo)的數(shù)據(jù)點(diǎn), 可以存儲(chǔ)在專門的時(shí)間序列數(shù)據(jù)庫(kù)（Time Series Database）。實(shí)際場(chǎng)景中，鳳睛沒有專門去維護(hù)一個(gè)時(shí)序數(shù)據(jù)庫(kù)。而是對(duì)接百度SIA智能監(jiān)控平臺(tái)的分布式時(shí)序數(shù)據(jù)庫(kù)TSDB。同時(shí)，利用百度SIA平臺(tái)提供豐富的多維可視化分析報(bào)表，用以解決用戶各種可視化多維度數(shù)據(jù)分析的需求。
?△當(dāng)前整體的架構(gòu)
07 結(jié)語
鳳睛整個(gè)項(xiàng)目前后持續(xù)了4年，中間經(jīng)歷過無數(shù)的困難和坎坷，通過積累了項(xiàng)目成員們持續(xù)的付出，最終取得里程碑式的成果。本文簡(jiǎn)要介紹了鳳睛產(chǎn)品的業(yè)務(wù)背景、技術(shù)架構(gòu)和產(chǎn)品形態(tài)，后續(xù)會(huì)繼續(xù)發(fā)文介紹技術(shù)相關(guān)的實(shí)現(xiàn)細(xì)節(jié)，歡迎持續(xù)關(guān)注。
推薦閱讀：
百度世界2021：百度大腦升級(jí)、昆侖芯2量產(chǎn)、智能云加速AI落地爆發(fā)
總結(jié)
以上是生活随笔為你收集整理的百度商业大规模微服务分布式监控系统-凤睛的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 如何快速定位程序Core？
- 下一篇： 炼丹神器！模型调参这门“玄学”，终于被破