背景介紹

餓了么監(jiān)控系統(tǒng)EMonitor：是一款服務(wù)于餓了么所有技術(shù)部門的一站式監(jiān)控系統(tǒng)，覆蓋了系統(tǒng)監(jiān)控、容器監(jiān)控、網(wǎng)絡(luò)監(jiān)控、中間件監(jiān)控、業(yè)務(wù)監(jiān)控、接入層監(jiān)控以及前端監(jiān)控的數(shù)據(jù)存儲與查詢。每日處理總數(shù)據(jù)量近PB，每日寫入指標(biāo)數(shù)據(jù)量百T，每日指標(biāo)查詢量幾千萬，配置圖表個(gè)數(shù)上萬，看板個(gè)數(shù)上千。

CAT：是基于Java 開發(fā)的實(shí)時(shí)應(yīng)用監(jiān)控平臺，為美團(tuán)點(diǎn)評提供了全面的實(shí)時(shí)監(jiān)控告警服務(wù)

本文通過對比分析下2者所做的事情為契機(jī)討論監(jiān)控系統(tǒng)或許該有的面貌，以及淺談下監(jiān)控系統(tǒng)發(fā)展的各個(gè)階段

CAT做的事情（開源版）

首先要強(qiáng)調(diào)的是這里我們只能拿到github上開源版CAT的最新版3.0.0，所以是基于此進(jìn)行對比

接下來說說CAT做了哪些事情？

1 抽象出監(jiān)控模型

抽象出Transaction、Event、Heartbeat、Metric 4種監(jiān)控模型。

• Transaction：用來記錄一段代碼的執(zhí)行時(shí)間和次數(shù)

• Event：用來記錄一件事發(fā)生的次數(shù)

• Heartbeat：表示程序內(nèi)定期產(chǎn)生的統(tǒng)計(jì)信息, 如CPU利用率

• Metric：用于記錄業(yè)務(wù)指標(biāo)，可以記錄次數(shù)和總和

針對Transaction和Event都固定了2個(gè)維度，type和name，并且針對type和name進(jìn)行分鐘級聚合成報(bào)表并展示曲線。

2 采樣鏈路

針對上述Transaction、Event的type和name分別有對應(yīng)的分鐘級的采樣鏈路

3 自定義的Metric打點(diǎn)

目前支持Counter和Timer類型的打點(diǎn)，支持tag，單機(jī)內(nèi)單個(gè)Metric的tag組合數(shù)限制1000。 并且有簡單的監(jiān)控看板，如下圖所示：

4 與其他組件集成

比如和Mybatis集成，在客戶端開啟相關(guān)的sql執(zhí)行統(tǒng)計(jì)，并將該統(tǒng)計(jì)劃分到Transaction統(tǒng)計(jì)看板中的type=SQL的一欄下

5 告警

可以針對上述的Transaction、Event等做一些簡單的閾值告警

餓了么EMonitor和CAT的對比

餓了么EMonitor借鑒了CAT的相關(guān)思想，同時(shí)又進(jìn)行了改進(jìn)。

1 引入Transaction、Event的概念

針對Transaction和Event都固定了2個(gè)維度，type和name，不同地方在于聚合用戶發(fā)過來的數(shù)據(jù)

CAT的架構(gòu)圖如下所示：

CAT的消費(fèi)機(jī)需要做如下2件事情：

• 對Transaction、Event等消息模型按照type和name進(jìn)行當(dāng)前小時(shí)的聚合，歷史小時(shí)的聚合數(shù)據(jù)寫入到mysql中

• 將鏈路數(shù)據(jù)寫入到本地文件或者遠(yuǎn)程HDFS上

EMonitor的架構(gòu)圖如下所示：

EMonitor分2路對數(shù)據(jù)進(jìn)行隔離處理：

• Real-Time Streaming Compute：對用戶發(fā)過來的鏈路中的Transaction、Event等監(jiān)控模型轉(zhuǎn)變成指標(biāo)數(shù)據(jù)并進(jìn)行10s的預(yù)聚合，同時(shí)也對用戶發(fā)過來的Metric數(shù)據(jù)進(jìn)行10s預(yù)聚合。最后將10s預(yù)聚合的數(shù)據(jù)寫入到LinDB時(shí)序數(shù)據(jù)庫（已開源，有興趣的可以關(guān)注star下）中，以及kafka中，讓告警模塊watchdog去消費(fèi)kafka做實(shí)時(shí)告警

• Real-Time Data Writer：對用戶發(fā)過來的鏈路數(shù)據(jù)構(gòu)建鏈路索引、向HDFS和HBase寫入索引和鏈路數(shù)據(jù)，同時(shí)會構(gòu)建應(yīng)用之間的依賴關(guān)系，將依賴關(guān)系寫入到Neo4j中

所以EMonitor和CAT的一個(gè)很大不同點(diǎn)就在于對指標(biāo)的處理上，EMonitor交給專業(yè)的時(shí)序數(shù)據(jù)庫來做，而CAT自己做聚合就顯得功能非常受限，如下所示：

• CAT只能整小時(shí)的查看type和name數(shù)據(jù)，不能跨小時(shí)，即不能查看任意2個(gè)時(shí)間之間的報(bào)表數(shù)據(jù)，EMonitor沒有此限制

• CAT沒法查看所有type匯總后的響應(yīng)時(shí)間和QPS，EMonitor可以靈活的自由組合type和name進(jìn)行聚合

• CAT的type和name報(bào)表是分鐘級的，EMonitor是10s級別的

• CAT的type和name沒能和歷史報(bào)表曲線直接對比，EMonitor可以對比歷史報(bào)表曲線，更容易發(fā)現(xiàn)問題

• CAT的type和name列表首頁展示了一堆數(shù)字，無法立即獲取一些直觀信息，比如給出了響應(yīng)時(shí)間TP99 100ms這個(gè)到底是好還是壞，EMonitor有當(dāng)前曲線和歷史曲線，相對來說可以直接判斷到底o(hù)k不ok

• CAT的TP99、TP999基于單機(jī)內(nèi)某個(gè)小時(shí)內(nèi)的報(bào)表是準(zhǔn)確的，除此之外多機(jī)或者多個(gè)小時(shí)的聚合TP99、TP999是用加權(quán)平均來計(jì)算的，準(zhǔn)確性有待提高

但是CAT也有自己的優(yōu)勢：

• CAT含有TP999、TP9999線(但是準(zhǔn)確性還有些問題)，EMonitor只能細(xì)到TP99

• CAT的type和name可以按照機(jī)器維度進(jìn)行過濾，EMonitor沒有做到這么細(xì)粒度

2 采樣鏈路

目前CAT和EMonitor都可以通過type和name來過濾采樣鏈路，不同點(diǎn)在于

• CAT的采樣鏈路是分鐘級別的，EMonitor是10s級別的

• 針對某一個(gè)type和name，CAT目前無法輕松找想要的鏈路，EMonitor可以輕松的找到某個(gè)時(shí)刻或者說某段時(shí)間內(nèi)響應(yīng)時(shí)間想要的鏈路（目前已經(jīng)申請專利）

EMonitor的鏈路如下所示：

• 這張圖是某個(gè)10s時(shí)刻、某個(gè)type和name過濾條件下的采樣鏈路

• 第一行是這10s內(nèi)的采樣鏈路，按照響應(yīng)時(shí)間進(jìn)行了排序

• 可以隨意點(diǎn)擊某個(gè)響應(yīng)時(shí)間來查看對應(yīng)的鏈路詳情

3 自定義的Metric打點(diǎn)

EMonitor支持Counter、Timer、Histogram、Payload、Gauge等等多種形式的打點(diǎn)方式，并且支持tag

• Counter：計(jì)數(shù)累加類型

• Timer：可以記錄一段代碼的耗時(shí)，包含執(zhí)行次數(shù)、耗時(shí)最大值、最小值、平均值

• Histogram：包含Timer的所有東西，同時(shí)支持計(jì)算TP99線，以及其他任意TP線(從0到100)

• Payload：可以記錄一個(gè)數(shù)據(jù)包的大小，包含數(shù)據(jù)包個(gè)數(shù)、包的最大值、最小值、平均值

• Gauge：測量值，一般用于衡量隊(duì)列大小、連接數(shù)、CPU、內(nèi)存等等

也就是任意Metric打點(diǎn)都可以流經(jīng)EMonitor進(jìn)行處理了并輸送到LinDB時(shí)序數(shù)據(jù)庫中。至此，EMonitor就可以將任何監(jiān)控指標(biāo)統(tǒng)一在一起了，比如機(jī)器監(jiān)控都可以通過EMonitor來保存了，這為一站式監(jiān)控系統(tǒng)奠定了基礎(chǔ)

自定義Metric看板

CAT只有一個(gè)簡易的Metric看板 EMonitor針對Metric開發(fā)了一套可以媲美Grafana的指標(biāo)看板，相比Grafana的優(yōu)勢：

• 有一套類似SQL的非常簡單的配置指標(biāo)的方式

• 跟公司人員組織架構(gòu)集成，更加優(yōu)雅的權(quán)限控制，不同的部門可以建屬于自己的看板

• 指標(biāo)和看板的收藏，當(dāng)源指標(biāo)或看板改動后，無需收藏人員再改動

• alpha、beta、prod不同環(huán)境之間的一鍵同步指標(biāo)和看板，無需配置多次

• PC端和移動端的同步查看指標(biāo)和看板

類SQL的配置查詢指標(biāo)方式如下所示：

• 可以配置圖表的展現(xiàn)形式

• 可以配置要查詢的字段以及字段之間的加減乘除等豐富的表達(dá)式

• 可以配置多個(gè)任意tag的過濾條件

• 可以配置group by以及order by

看板整體如下所示：

移動端顯示如下：

4 與其他組件集成

目前EMonitor已經(jīng)打通了IaaS層、PaaS層、應(yīng)用層的所有鏈路和指標(biāo)的監(jiān)控，再也不用在多個(gè)監(jiān)控系統(tǒng)中切換來切換去了，如下所示

• 1 IaaS層物理機(jī)、機(jī)房網(wǎng)絡(luò)交換機(jī)等的監(jiān)控指標(biāo)

• 2 PaaS層中間件服務(wù)端的監(jiān)控指標(biāo)

• 3 應(yīng)用層SOA、Exception、JVM、MQ等客戶端的相關(guān)指標(biāo)

• 4 應(yīng)用層自定義的監(jiān)控指標(biāo)

以打通餓了么分庫分表中間件DAL為例：

• 可以根據(jù)機(jī)房、執(zhí)行狀態(tài)、表、操作類型（比如Insert、Update、Select等）進(jìn)行過濾查看

• 左邊列表給出每條SQL的執(zhí)行的平均耗時(shí)

• 右邊2個(gè)圖表給出該條SQL在DAL中間件層面、DB層面的耗時(shí)以及調(diào)用QPS

• 可以給出該SQL打在后端DAL中間、DB上的分布情況，可以用于排查是否存在一些熱點(diǎn)的情況

• 還有一些SQL查詢結(jié)果的數(shù)據(jù)包大小的曲線、SQL被DAL限流的情況等等

• 可以查看任何時(shí)間點(diǎn)上該SQL的調(diào)用鏈路信息

再以打通餓了么SOA服務(wù)為例：

• 可以根據(jù)機(jī)房和狀態(tài)信息進(jìn)行過濾

• 左邊一欄列出該應(yīng)用提供的SOA服務(wù)接口，同時(shí)給出平均響應(yīng)時(shí)間以及和昨天的對比情況

• 右邊的2個(gè)圖表分別給出了對應(yīng)服務(wù)接口的服務(wù)響應(yīng)時(shí)間和QPS以及和昨天的對比情況，同時(shí)可以切換平均響應(yīng)時(shí)間到TP99或者其他TP值，同時(shí)配有可以快速對相關(guān)曲線添加告警的跳轉(zhuǎn)鏈接

• 可以切換到單機(jī)維度來查看每臺機(jī)器該SOA接口的響應(yīng)時(shí)間和QPS，用來定位某臺機(jī)器的問題

• 可以給出該SOA接口調(diào)用在不同集群的分布占比

• 可以給出該SOA接口的所有調(diào)用方以及他們的QPS

• 可以查看任何時(shí)間點(diǎn)上該SOA接口的調(diào)用鏈路信息

5 告警

可以針對所有的監(jiān)控指標(biāo)配置如下告警方式：

• 閾值：簡單的閾值告警，適用于CPU、內(nèi)存等

• 同環(huán)比：與過去同期比較的告警

• 趨勢：適合于相對平滑連續(xù)的無需閾值的智能告警

• 其他告警形式

淺談監(jiān)控系統(tǒng)的發(fā)展趨勢

1 日志監(jiān)控階段

本階段實(shí)現(xiàn)方式：程序打日志，使用ELK來存儲和查詢程序的運(yùn)行日志，ELK也能簡單顯示指標(biāo)曲線

排障過程：一旦有問題，則去ELK中搜索可能的異常日志來進(jìn)行分析排障

2 鏈路監(jiān)控階段

上一個(gè)階段存在的問題：ELK只是基于一行一行日志進(jìn)行聚合或者搜索分析，日志之間沒有上下文關(guān)聯(lián)。很難知道一次請求耗時(shí)較長究竟耗時(shí)在哪個(gè)階段

本階段實(shí)現(xiàn)方式：CAT橫空出世，通過建模抽象出Transaction、Metric等監(jiān)控模型，將鏈路分析和簡單的報(bào)表帶入了大家的視野

告警方式：針對報(bào)表可以進(jìn)行閾值監(jiān)控 排障過程：一旦有告警，可以通過點(diǎn)擊報(bào)表來詳細(xì)定位到是哪個(gè)type或name有一定問題，順便找到對應(yīng)的鏈路，查看詳細(xì)的信息

3 指標(biāo)監(jiān)控階段

上一階段存在的問題：CAT對自定義指標(biāo)支持的比較弱，也無法實(shí)現(xiàn)或者展現(xiàn)更加多樣的查詢聚合需求

本階段的實(shí)現(xiàn)方式：支持豐富的Metric指標(biāo)，將鏈路上的一些報(bào)表數(shù)據(jù)也可以劃分到指標(biāo)中，交給專業(yè)的時(shí)序數(shù)據(jù)庫來做指標(biāo)的存儲和查詢，對接或者自研豐富的指標(biāo)看板如Grafana

告警方式：針對指標(biāo)進(jìn)行更加豐富的告警策略 排障過程：一旦有告警，可能需要到各個(gè)系統(tǒng)上查看指標(biāo)看板，粗略定位根因，再結(jié)合鏈路總和分析

4 平臺打通整合階段

上一階段存在的問題：系統(tǒng)監(jiān)控、中間件和業(yè)務(wù)監(jiān)控、部分業(yè)務(wù)監(jiān)控、鏈路監(jiān)控與指標(biāo)監(jiān)控都各搞一套數(shù)據(jù)收集、預(yù)處理、存儲、查詢、展現(xiàn)、告警流程，各個(gè)系統(tǒng)處理數(shù)據(jù)格式、使用方式不統(tǒng)一

本階段的實(shí)現(xiàn)方式：打通從系統(tǒng)層面、容器層面、中間件層面、業(yè)務(wù)層面等等的可能的鏈路和指標(biāo)監(jiān)控，統(tǒng)一數(shù)據(jù)的處理流程，同時(shí)整合發(fā)布、變更、告警與監(jiān)控曲線結(jié)合，成為一站式監(jiān)控平臺

告警方式：可以統(tǒng)一的針對各個(gè)層面的監(jiān)控?cái)?shù)據(jù)做統(tǒng)一化的告警 排障過程：只需要在一個(gè)監(jiān)控系統(tǒng)中就可以查看到所有的監(jiān)控曲線和鏈路信息

目前我們EMonitor已完成這個(gè)階段，將公司之前存在已久的3套獨(dú)立的監(jiān)控系統(tǒng)統(tǒng)一整合成現(xiàn)如今的一套監(jiān)控系統(tǒng)

5 深度分析階段

上一階段存在的問題：

• 用戶雖然可以在一個(gè)系統(tǒng)中看到所有各個(gè)層面的監(jiān)控?cái)?shù)據(jù)了，但是每次排障時(shí)仍然要花很多的時(shí)間去查看各個(gè)層面是否有問題，一旦漏看一項(xiàng)可能就錯(cuò)過了問題所在的根因

• 沒有整個(gè)業(yè)務(wù)的全局監(jiān)控視角，都停留在各自應(yīng)用的角度

總之：之前的階段都是去做一個(gè)監(jiān)控平臺，用戶查詢什么指標(biāo)就展示相應(yīng)的數(shù)據(jù)，監(jiān)控平臺并不去關(guān)心用戶所存儲數(shù)據(jù)的內(nèi)容?，F(xiàn)在呢就需要轉(zhuǎn)變思路，監(jiān)控平臺需要主動去幫用戶分析里面所存儲的數(shù)據(jù)內(nèi)容

本階段的實(shí)現(xiàn)方式：所要做的就是把幫用戶分析的過程抽象出來，為用戶構(gòu)建應(yīng)用大盤和業(yè)務(wù)大盤，以及為大盤做相關(guān)的根因分析。

• 應(yīng)用大盤：就是為當(dāng)前應(yīng)用構(gòu)建上下游應(yīng)用依賴的監(jiān)控、當(dāng)前應(yīng)用所關(guān)聯(lián)的機(jī)器監(jiān)控、redis、MQ、database等等監(jiān)控，可以時(shí)刻為應(yīng)用做體檢，來主動暴露出問題，而不是等用戶去一個(gè)個(gè)查指標(biāo)而后發(fā)現(xiàn)問題

• 業(yè)務(wù)大盤：就是根據(jù)業(yè)務(wù)來梳理或者利用鏈路來自動生產(chǎn)大盤，該大盤可以快速告訴用戶是哪些業(yè)務(wù)環(huán)節(jié)出的問題

根因分析：一個(gè)大盤有很多的環(huán)節(jié)，每個(gè)環(huán)節(jié)綁定有很多的指標(biāo)，每次某個(gè)告警出來有可能需要詳細(xì)的分析下每個(gè)環(huán)節(jié)的指標(biāo)，比如消費(fèi)kafka的延遲上升，有各種各樣的原因都可能導(dǎo)致，每次告警排查都需要將分析流程再全部人為分析排查下，非常累，所以需要將定位根因的過程通過建模抽象下，來進(jìn)行統(tǒng)一解決

趨勢報(bào)表分析：主動幫用戶發(fā)現(xiàn)一些逐漸惡化的問題點(diǎn)，比如用戶發(fā)布之后，接口耗時(shí)增加，很可能用戶沒有發(fā)現(xiàn)，雖然當(dāng)前沒有問題，但是很有可能在明天的高峰期就會暴露問題，這些都是已經(jīng)實(shí)實(shí)在在發(fā)生的事故

要想做主動分析，還深度依賴指標(biāo)下鉆分析，即某個(gè)指標(biāo)調(diào)用量下降了，能主動分析出是哪些tag維度組合導(dǎo)致的下降，這是上述很多智能分析的基礎(chǔ)，這一塊也不簡單

告警方式：可以統(tǒng)一的針對各個(gè)層面的監(jiān)控?cái)?shù)據(jù)做統(tǒng)一化的告警 排障過程：NOC根據(jù)業(yè)務(wù)指標(biāo)或者業(yè)務(wù)大盤快速得知是哪些業(yè)務(wù)或者應(yīng)用出先了問題，應(yīng)用的owner通過應(yīng)用大盤的體檢得知相關(guān)的變動信息，比如是redis波動、database波動、上下游應(yīng)用的某個(gè)方法波動等等，來達(dá)到快速定位問題目的，或者通過對大盤執(zhí)行根因分析來定位到根因

再談Logging、Tracing、Metrics

常見一張3者關(guān)系的圖

三者的確都不可或缺，相輔相成，但是我想說以下幾點(diǎn)：

• 三者在監(jiān)控排障中的所占比例卻大不一樣：Metrics占據(jù)大頭，Tracing次之，Logging最后

• Tracing含有重要的應(yīng)用之間的依賴信息，Metrics有更多的可深度分析和挖掘的空間，所以未來必然是在Metrics上大做文章，再結(jié)合Tracing中的應(yīng)用依賴來做更深度全局分析，即Metrics和Tracing兩者結(jié)合發(fā)揮出更多的可能性

參考鏈接： CAT：https://github.com/dianping/cat深度剖析開源分布式監(jiān)控CAT：https://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring.html

作者信息：李剛，網(wǎng)名乒乓狂魔，餓了么監(jiān)控組研發(fā)專家，餓了么內(nèi)部時(shí)序數(shù)據(jù)庫LinDB項(xiàng)目負(fù)責(zé)人，目前致力于監(jiān)控的智能分析領(lǐng)域。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載