vivo 服務(wù)端監(jiān)控架構(gòu)設(shè)計與實踐
一、業(yè)務(wù)背景
當(dāng)今時代處在信息大爆發(fā)的時代,信息借助互聯(lián)網(wǎng)的潮流在全球自由的流動,產(chǎn)生了各式各樣的平臺系統(tǒng)和軟件系統(tǒng),越來越多的業(yè)務(wù)也會導(dǎo)致系統(tǒng)的復(fù)雜性。
當(dāng)核心業(yè)務(wù)出現(xiàn)了問題影響用戶體驗,開發(fā)人員沒有及時發(fā)現(xiàn),發(fā)現(xiàn)問題時已經(jīng)為時已晚,又或者當(dāng)服務(wù)器的CPU持續(xù)增高,磁盤空間被打滿等,需要運維人員及時發(fā)現(xiàn)并處理,這就需要一套有效的監(jiān)控系統(tǒng)對其進(jìn)行監(jiān)控和預(yù)警。
如何對這些業(yè)務(wù)和服務(wù)器進(jìn)行監(jiān)控和維護(hù)是我們開發(fā)人員和運維人員不可忽視的重要一環(huán),這篇文章全篇大約5000多字,我將對vivo服務(wù)端監(jiān)控的原理和架構(gòu)演進(jìn)之路做一次系統(tǒng)性整理,以便大家做監(jiān)控技術(shù)選型時參考。
vivo服務(wù)端監(jiān)控旨在為服務(wù)端應(yīng)用提供包括系統(tǒng)監(jiān)控、JVM監(jiān)控以及自定義業(yè)務(wù)指標(biāo)監(jiān)控在內(nèi)的一站式數(shù)據(jù)監(jiān)控,并配套實時、多維度、多渠道的告警服務(wù),幫助用戶及時掌握應(yīng)用多方面狀態(tài),事前及時預(yù)警發(fā)現(xiàn)故障,事后提供詳實的數(shù)據(jù)用于追查定位問題,提升服務(wù)可用性。目前vivo服務(wù)端監(jiān)控累計接入業(yè)務(wù)方數(shù)量達(dá)到200+,本文介紹的是服務(wù)端監(jiān)控,我司還有其他類型的優(yōu)秀監(jiān)控包括通用監(jiān)控、調(diào)用鏈監(jiān)控和客戶端監(jiān)控等。
1.1 監(jiān)控系統(tǒng)的基本流程
無論是開源的監(jiān)控系統(tǒng)還是自研的監(jiān)控系統(tǒng),整體流程都大同小異。
1)數(shù)據(jù)采集:可以包括JVM監(jiān)控數(shù)據(jù)如GC次數(shù),線程數(shù)量,老年代和新生代區(qū)域大??;系統(tǒng)監(jiān)控數(shù)據(jù)如磁盤使用使用率,磁盤讀寫的吞吐量,網(wǎng)絡(luò)的出口流量和入口流量,TCP連接數(shù);業(yè)務(wù)監(jiān)控數(shù)據(jù)如錯誤日志,訪問日志,視頻播放量,PV,UV等。
2)數(shù)據(jù)傳輸:將采集的數(shù)據(jù)以消息形式或者 HTTP 協(xié)議的形式等上報給監(jiān)控系統(tǒng)。
3)數(shù)據(jù)存儲:有使用 MySQL、Oracle 等 RDBMS 存儲的,也有使用時序數(shù)據(jù)庫OpenTSDB、InfluxDB 存儲的,還有使用 HBase 直接存儲的。
4)數(shù)據(jù)可視化:數(shù)據(jù)指標(biāo)的圖形化展示,可以是折線圖,柱狀圖,餅圖等。
5)監(jiān)控告警:靈活的告警設(shè)置,以及支持郵件、短信、IM 等多種通知通道。
1.2 如何規(guī)范的使用監(jiān)控系統(tǒng)
在使用監(jiān)控系統(tǒng)之前,我們需要了解監(jiān)控對象的基本工作原理,例如JVM監(jiān)控,我們需要清楚JVM的內(nèi)存結(jié)構(gòu)組成和常見的垃圾回收機制;其次需要確定如何去描述和定義監(jiān)控對象的狀態(tài),例如監(jiān)控某個業(yè)務(wù)功能的接口性能,可以監(jiān)控該接口的請求量,耗時情況,錯誤量等;在確定了如何監(jiān)控對象的狀態(tài)之后,需要定義合理的告警閾值和告警類型,當(dāng)收到告警提醒時,幫助開發(fā)人員及時發(fā)現(xiàn)故障;最后建立完善的故障處理體系,收到告警時迅速響應(yīng),及時處理線上故障。
二、vivo服務(wù)端監(jiān)控系統(tǒng)架構(gòu)及演進(jìn)之路
在介紹vivo服務(wù)端監(jiān)控系統(tǒng)架構(gòu)之前,先帶大家了解一下OpenTSDB時序數(shù)據(jù)庫,在了解之前說明下為什么我們會選擇OpenTSDB,原因有以下幾點:
1) 監(jiān)控數(shù)據(jù)采集指標(biāo)在某一時間點具有唯一值,沒有復(fù)雜的結(jié)構(gòu)及關(guān)系。
2)監(jiān)控數(shù)據(jù)的指標(biāo)具有隨著時間不斷變化的特點。
3)基于HBase分布式、可伸縮的時間序列數(shù)據(jù)庫,存儲層不需要過多投入精力,具有HBase的高吞吐,良好的伸縮性等特點。
4)開源,Java實現(xiàn),并且提供基于HTTP的應(yīng)用程序編程接口,問題排查快可修改。
2.1 OpenTSDB簡介
1)基于HBase的分布式的,可伸縮的時間序列數(shù)據(jù)庫,主要用途就是做監(jiān)控系統(tǒng)。譬如收集大規(guī)模集群(包括網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)、應(yīng)用程序)的監(jiān)控數(shù)據(jù)并進(jìn)行存儲和查詢,支持秒級數(shù)據(jù)采集,支持永久存儲,可以做容量規(guī)劃,并很容易地接入到現(xiàn)有的監(jiān)控系統(tǒng)里,OpenTSDB的系統(tǒng)架構(gòu)圖如下:
(來自官方文檔)
存儲結(jié)構(gòu)單元為Data Point,即某個Metric在某個時間點的數(shù)值。Data Point包括以下部分:
- Metric,監(jiān)控指標(biāo)名稱;
- Tags,Metric的標(biāo)簽,用來標(biāo)注類似機器名稱等信息,包括TagKey和TagValue;
- Value,Metric對應(yīng)的實際數(shù)值,整數(shù)或小數(shù);
- Timestamp,時間戳。
核心存儲兩張表:tsdb和tsdb-uid。表tsdb用來存儲監(jiān)控數(shù)據(jù),如下圖:
(圖片出處: https://www.jianshu.com )
Row Key為Metric+Timestamp的小時整點+TagKey+TagValue,取相應(yīng)的字節(jié)映射組合起來;列族t下的Qualifier為Timestamp的小時整點余出的秒數(shù),對應(yīng)的值即為Value。
表tsdb-uid用來存儲剛才提到的字節(jié)映射,如下圖:
(圖片出處: https://www.jianshu.com )
圖中的“001”表示tagk=hots或者tagv=static,提供正反查詢。
2)OpenTSDB使用策略說明:
- 不使用OpenTSDB提供的rest接口,通過client與HBase直連;
- 工程端禁用compact動作的Thrd線程;
- 間隔10秒獲取Redis緩沖數(shù)據(jù)批量寫入OpenTSDB。
2.2 OpenTSDB在實踐中需要關(guān)注的點
1)精確性問題
String value = "0.51";
float f = Float.parseFloat(value);
int raw = Float.floatToRawIntBits(f);
byte[] float_bytes = Bytes.fromInt(raw);
int raw_back = Bytes.getInt(float_bytes, 0);
double decode = Float.intBitsToFloat(raw_back);
/**
* 打印結(jié)果:
* Parsed Float: 0.51
* Encode Raw: 1057132380
* Encode Bytes: 3F028F5C
* Decode Raw: 1057132380
* Decoded Float: 0.5099999904632568
*/
System.out.println("Parsed Float: " + f);
System.out.println("Encode Raw: " + raw);
System.out.println("Encode Bytes: " + UniqueId.uidToString(float_bytes));
System.out.println("Decode Raw: " + raw_back);
System.out.println("Decoded Float: " + decode);
如上代碼,OpenTSDB在存儲浮點型數(shù)據(jù)時,無法知悉存儲意圖,在轉(zhuǎn)化時會遇到精確性問題,即存儲"0.51",取出為"0.5099999904632568"。
2)聚合函數(shù)問題
OpenTSDB的大部分聚合函數(shù),包括sum、avg、max、min都是LERP(linear interpolation)的插值方式,即所獲取的值存在被補缺的現(xiàn)象,對于有空值需求的使用很不友好。詳細(xì)原理參見OpenTSDB關(guān)于 interpolation的文檔 。
目前vmonitor服務(wù)端監(jiān)控使用的OpenTSDB是我們改造后的源碼,新增了nimavg函數(shù),配合自帶的zimsum函數(shù)滿足空值插入需求。
2.3 vivo服務(wù)端監(jiān)控采集器原理
1)定時器
內(nèi)含3種采集器:OS采集器、JVM采集器和業(yè)務(wù)指標(biāo)采集器,其中OS及JVM每分鐘執(zhí)行采集和匯聚,業(yè)務(wù)指標(biāo)采集器會實時采集并在1分鐘的時間點完成匯聚重置,3份采集器的數(shù)據(jù)打包上報至RabbitMQ,上報動作異步超時。
2)業(yè)務(wù)指標(biāo)采集器
業(yè)務(wù)指標(biāo)采集方式有2種:日志輸出過濾和工具類代碼上報(侵入式),日志輸出過濾是通過繼承l(wèi)og4j的Filter,從而獲取指標(biāo)配置中指定的Appender輸出的renderedMessage,并根據(jù)指標(biāo)配置的關(guān)鍵詞、聚合方式等信息進(jìn)行同步監(jiān)聽采集;代碼上報根據(jù)代碼中指定的指標(biāo)code進(jìn)行message信息上報,屬于侵入式的采集方式,通過調(diào)用監(jiān)控提供的Util實現(xiàn)。業(yè)務(wù)指標(biāo)配置每隔5分鐘會從CDN刷新,內(nèi)置多種聚合器供聚合使用,包括count計數(shù)、 sum求和、average平均、max最大值和min最小值統(tǒng)計。
2.4 vivo服務(wù)端監(jiān)控老版本架構(gòu)設(shè)計
1)數(shù)據(jù)采集及上報:需求方應(yīng)用接入的監(jiān)控采集器vmonitor-agent根據(jù)監(jiān)控指標(biāo)配置采集相應(yīng)數(shù)據(jù),每分鐘上報1次數(shù)據(jù)至RabbitMQ,所采用的指標(biāo)配置每5分鐘從CDN下載更新,CDN內(nèi)容由監(jiān)控后臺上傳。
2)計算及存儲:監(jiān)控后臺接收RabbitMQ的數(shù)據(jù),拆解后存儲至OpenTSDB,供可視化圖表調(diào)用,監(jiān)控項目、應(yīng)用、指標(biāo)和告警等配置存儲于MySQL;通過Zookeeper和Redis實現(xiàn)分布式任務(wù)分發(fā)模塊,實現(xiàn)多臺監(jiān)控服務(wù)協(xié)調(diào)配合運作,供分布式計算使用。
3)告警檢測:從OpenTSDB獲取監(jiān)控指標(biāo)數(shù)據(jù),根據(jù)告警配置檢測異常,并將異常通過第三方依賴自研消息、短信發(fā)送,告警檢測通過分布式任務(wù)分發(fā)模塊完成分布式計算。
2.5 vivo服務(wù)端監(jiān)控老版本部署架構(gòu)
1)自建機房A:部署架構(gòu)以國內(nèi)為例,監(jiān)控工程部署在自建機房A,監(jiān)聽本機房的RabbitMQ消息,依賴的Redis、OpenTSDB、MySQL、Zookeeper等均在同機房,需要上傳的監(jiān)控指標(biāo)配置由文件服務(wù)上傳至CDN,供監(jiān)控需求應(yīng)用設(shè)備調(diào)用。
2)云機房:云機房的監(jiān)控需求應(yīng)用設(shè)備將監(jiān)控數(shù)據(jù)上報至云機房本地的RabbitMQ,云機房的RabbitMQ將指定隊列通過路由的方式轉(zhuǎn)發(fā)至自建機房A的RabbitMQ,云機房的監(jiān)控配置通過CDN拉取。
2.6 vivo服務(wù)端監(jiān)控新版本架構(gòu)設(shè)計
1)采集(接入方):業(yè)務(wù)方接入vmonitor-collector,并在相應(yīng)環(huán)境的監(jiān)控后臺配置相關(guān)監(jiān)控項即完成接入,vmonitor- collector將定時拉取監(jiān)控項配置,采集服務(wù)數(shù)據(jù)并每分鐘上報。
2)數(shù)據(jù)聚合:老版本支持的是RabbitMQ將采集到的數(shù)據(jù),路由至監(jiān)控機房的RabbitMQ(同機房則不發(fā)生該行為),由監(jiān)控后臺服務(wù)消費;CDN負(fù)責(zé)承載各應(yīng)用的配置供應(yīng)用定時拉取。新版本vmonitor-gateway作為監(jiān)控數(shù)據(jù)網(wǎng)關(guān),采用http方式上報監(jiān)控數(shù)據(jù)以及拉取指標(biāo)配置,拋棄了之前使用的RabbitMQ上報以及CDN同步配置的途徑,避免兩者故障時對監(jiān)控上報的影響。
3)可視化并且支持告警與配置(監(jiān)控后臺vmonitor):負(fù)責(zé)前臺的數(shù)據(jù)多元化展示(包括業(yè)務(wù)指標(biāo)數(shù)據(jù),分機房匯總數(shù)據(jù),單臺服務(wù)器數(shù)據(jù),以及業(yè)務(wù)指標(biāo)復(fù)合運算呈現(xiàn)),數(shù)據(jù)聚合,告警(目前包括短信及自研消息)等。
4)數(shù)據(jù)存儲:存儲使用HBASE集群和開源的OpenTSDB作為聚合的中介,原始數(shù)據(jù)上報之后通過OpenTSDB持久化到HBase集群,Redis作為分布式數(shù)據(jù)存儲調(diào)度任務(wù)分配、告警狀態(tài)等信息,后臺涉及的指標(biāo)和告警配置存儲于MySQL。
三、監(jiān)控采集上報和存儲監(jiān)控數(shù)據(jù)策略
為降低監(jiān)控接入成本以及避免RabbitMQ上報故障和CDN同步配置故障對監(jiān)控體系帶來的影響,將由采集層通過HTTP直接上報至代理層,并通過采集層和數(shù)據(jù)代理層的隊列實現(xiàn)災(zāi)時數(shù)據(jù)最大程度的挽救。
詳細(xì)流程說明如下:
1)采集器(vmonitor-collector)根據(jù)監(jiān)控配置每分鐘采集數(shù)據(jù)并壓縮,存儲于本地隊列(最大長度100,即最大存儲100分鐘數(shù)據(jù)),通知可進(jìn)行HTTP上報,將數(shù)據(jù)上報至網(wǎng)關(guān)。
2)網(wǎng)關(guān)(vmonitor-gateway)接收到上報的數(shù)據(jù)后鑒權(quán),認(rèn)定非法即丟棄;同時判斷當(dāng)前是否下層異常熔斷,如果發(fā)生則通知采集層重置數(shù)據(jù)退回隊列。
3)網(wǎng)關(guān)校驗上報時帶來的監(jiān)控配置版本號,過期則在結(jié)果返回時將最新監(jiān)控配置一并返回要求采集層更新配置。
4)網(wǎng)關(guān)將上報的數(shù)據(jù)存儲于該應(yīng)用對應(yīng)的Redis隊列中(單個應(yīng)用緩存隊列key最大長度1w);存儲隊列完成后立即返回HTTP上報,表明網(wǎng)關(guān)已接受到數(shù)據(jù),采集層可移除該條數(shù)據(jù)。
5)網(wǎng)關(guān)對Redis隊列數(shù)據(jù)進(jìn)行解壓以及數(shù)據(jù)聚合;如果熔斷器異常則暫停前一行為;完成后通過HTTP存儲至OpenTSDB;如果存儲行為大量異常則觸發(fā)熔斷器。
四、核心指標(biāo)
4.1 系統(tǒng)監(jiān)控告警和業(yè)務(wù)監(jiān)控告警
將采集到的數(shù)據(jù)通過OpenTSDB存放到HBase中后,通過分布式任務(wù)分發(fā)模塊完成分布式計算。如果符合業(yè)務(wù)方配置的告警規(guī)則,則觸發(fā)相應(yīng)的告警,對告警信息進(jìn)行分組并且路由到正確的通知方。可以通過短信自研消息進(jìn)行告警發(fā)送,可通過名字、工號、拼音查詢錄入需要接收告警的人員,當(dāng)接收到大量重復(fù)告警時能夠消除重復(fù)的告警信息,所有的告警信息可以通過MySQL表進(jìn)行記錄方便后續(xù)查詢和統(tǒng)計,告警的目的不僅僅是幫助開發(fā)人員及時發(fā)現(xiàn)故障建立故障應(yīng)急機制,同時也可以結(jié)合業(yè)務(wù)特點的監(jiān)控項和告警梳理服務(wù),借鑒行業(yè)最佳監(jiān)控實踐。告警流程圖如下:
4.2 支持的告警類型以及計算公式
1)最大值:當(dāng)指定字段超過該值時觸發(fā)報警(報警閾值單位:number)。
2)最小值:當(dāng)指定字段低于該值時觸發(fā)報警(報警閾值單位:number)。
3)波動量:取當(dāng)前時間到前15分鐘這段時間內(nèi)的最大值或者最小值與這15分鐘內(nèi)的平均值做浮動百分比報警,波動量需要配置波動基線,標(biāo)識超過該基線數(shù)值時才做“報警閥值”判定,低于該基線數(shù)值則不觸發(fā)報警(報警閾值單位:percent)。
計算公式:
波動量-向上波動計算公式:float rate = (float) (max - avg) / (float) avg;
波動量-向下波動計算公式:float rate = (float) (avg - min) / (float) avg;
波動量-區(qū)間波動計算公式:float rate = (float) (max - min) / (float) max;
4)日環(huán)比:取當(dāng)前時間與昨天同一時刻的值做浮動百分比報警(報警閾值單位:percent)。
計算公式:float rate = (當(dāng)前值 - 上一周期值)/上一周期值
5)周環(huán)比:取當(dāng)前時間與上周同一天的同一時刻的值做浮動百分比報警(報警閾值單位:percent)。
計算公式:float rate = (當(dāng)前值 - 上一周期值)/上一周期值
6)小時日環(huán)比:取當(dāng)前時間到前一小時內(nèi)的數(shù)據(jù)值總和與昨天同一時刻的前一小時內(nèi)的數(shù)據(jù)值總和做浮動百分比報警(報警閾值單位:percent)。
計算公式:float rate = (float) (anHourTodaySum - anHourYesterdaySum) / (float) anHourYesterdaySum。
五、演示效果
5.1 業(yè)務(wù)指標(biāo)數(shù)據(jù)查詢
1)查詢條件欄“指標(biāo)”可選擇指定指標(biāo)。
2)雙擊圖表上指標(biāo)名稱可展示大圖,底部是根據(jù)起始時間的指標(biāo)域合計值。
3)滾輪可以縮放圖表。
5.2 系統(tǒng)監(jiān)控&JVM監(jiān)控指標(biāo)數(shù)據(jù)查詢
1)每分鐘頁面自動刷新。
2)如果某行,即某臺機器整行顯示紅色,則代表該機器已逾半小時未上報數(shù)據(jù),如機器是非正常下線就要注意排查了。
3)點擊詳情按鈕,可以對系統(tǒng)&JVM監(jiān)控數(shù)據(jù)進(jìn)行明細(xì)查詢。
5.3 業(yè)務(wù)指標(biāo)配置
單個監(jiān)控指標(biāo)(普通)可以針對單個指定Appender的日志文件進(jìn)行數(shù)據(jù)采集。
【必填】【指標(biāo)類型】為“普通”、“復(fù)合”兩種,復(fù)合是將多個普通指標(biāo)二次聚合,所以正常情況下需要先新增普通指標(biāo)。
【必填】【圖表順序】正序排列,控制指標(biāo)圖表在數(shù)據(jù)頁面上的展示順序。
【必填】【指標(biāo)代碼】默認(rèn)自動生成UUID短碼。
【可選】【Appender】為log4j日志文件的appender名稱,要求該appender必須被logger的ref引用;如果使用侵入式采集數(shù)據(jù)則無需指定。
【可選】【關(guān)鍵字】為過濾日志文件行的關(guān)鍵詞。
【可選】【分隔符】是指單行日志列分割的符號,一般為","英文逗號或其它符號。
六、主流監(jiān)控對比
6.1 Zabbix
Zabbix 于 1998 年誕生,核心組件采用 C 語言開發(fā),Web 端采用 PHP 開發(fā),它屬于老牌監(jiān)控系統(tǒng)中的優(yōu)秀代表,能夠監(jiān)控網(wǎng)絡(luò)參數(shù),服務(wù)器健康和軟件完整性,使用也很廣泛。
Zabbix采用MySQL 進(jìn)行數(shù)據(jù)存儲,所有沒有OpenTSDB支持 Tag的特性,因此沒法按多維度進(jìn)行聚合統(tǒng)計和告警配置,使用起來不靈活。Zabbix 沒有提供對應(yīng)的 SDK,應(yīng)用層監(jiān)控支持有限,也沒有我們自研的監(jiān)控提供了侵入式的埋點和采集功能。
總體而言Zabbix 的成熟度更高,高集成度導(dǎo)致靈活性較差,在監(jiān)控復(fù)雜度增加后,定制難度會升高,而且使用的MySQL關(guān)系型數(shù)據(jù)庫,對于大規(guī)模的監(jiān)控數(shù)據(jù)插入和查詢是個問題。
6.2 Open-Falcon
OpenFalcon 是一款企業(yè)級、高可用、可擴展的開源監(jiān)控解決方案,提供實時報警、數(shù)據(jù)監(jiān)控等功能,采用 Go 和 Python 語言開發(fā),由小米公司開源。使用 Falcon 可以非常容易的監(jiān)控整個服務(wù)器的狀態(tài),比如磁盤空間,端口存活,網(wǎng)絡(luò)流量等等?;?Proxy-gateway,很容易通過自主埋點實現(xiàn)應(yīng)用層的監(jiān)控(比如監(jiān)控接口的訪問量和耗時)和其他個性化監(jiān)控需求,集成方便。
官方的架構(gòu)圖如下:
6.3 Prometheus(普羅米修斯)
Prometheus是由SoundCloud開發(fā)的開源監(jiān)控報警系統(tǒng)和時序列數(shù)據(jù)庫(TSDB),Prometheus使用Go語言開發(fā),是Google BorgMon監(jiān)控系統(tǒng)的開源版本。
和小米的Open-Falcon一樣,借鑒 OpenTSDB,數(shù)據(jù)模型中引入了 Tag,這樣能支持多維度的聚合統(tǒng)計以及告警規(guī)則設(shè)置,大大提高了使用效率。監(jiān)控數(shù)據(jù)直接存儲在 Prometheus Server 本地的時序數(shù)據(jù)庫中,單個實例可以處理數(shù)百萬的 Metrics,架構(gòu)簡單,不依賴外部存儲,單個服務(wù)器節(jié)點可直接工作。
官方的架構(gòu)圖如下:
6.4 vivo服務(wù)端監(jiān)控vmonitor
vmonitor作為監(jiān)控后臺管理系統(tǒng),可以進(jìn)行可視化查看,告警的配置,業(yè)務(wù)指標(biāo)的配置等,具備JVM監(jiān)控、系統(tǒng)監(jiān)控和業(yè)務(wù)監(jiān)控的功能。通過采集層(vmonitor-collector采集器)和數(shù)據(jù)代理層(vmonitor-gateway網(wǎng)關(guān))的隊列實現(xiàn)災(zāi)時數(shù)據(jù)最大程度的挽救。
提供了SDK方便業(yè)務(wù)方集成,支持日志輸出過濾和侵入式代碼上報數(shù)據(jù)等應(yīng)用層監(jiān)控統(tǒng)計,基于OpenTSDB時序開源數(shù)據(jù)庫,對其源碼進(jìn)行了改造,新增了nimavg函數(shù),配合自帶的zimsum函數(shù)滿足空值插入需求,具有強大的數(shù)據(jù)聚合能力,可以提供實時、多維度、多渠道的告警服務(wù)。
七、總結(jié)
本文主要介紹了vivo服務(wù)端監(jiān)控架構(gòu)的設(shè)計與演進(jìn)之路,是基于java技術(shù)棧做的一套實時監(jiān)控系統(tǒng),同時也簡單列舉了行業(yè)內(nèi)主流的幾種類型的監(jiān)控系統(tǒng),希望有助于大家對監(jiān)控系統(tǒng)的認(rèn)識,以及在技術(shù)選型時做出更合適的選擇。
監(jiān)控體系里面涉及到的面很廣,是一個龐大復(fù)雜的體系,本文只是介紹了服務(wù)端監(jiān)控里的JVM監(jiān)控,系統(tǒng)監(jiān)控以及業(yè)務(wù)監(jiān)控(包含日志監(jiān)控和工具類代碼侵入式上報),未涉及到客戶端監(jiān)控和全鏈路監(jiān)控等,如果想理解透徹,必須理論結(jié)合實踐再做深入。