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

[[326491]]

餓了么監(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ù)存儲(chǔ)與查詢。

每日處理總數(shù)據(jù)量近 PB ，每日寫入指標(biāo)數(shù)據(jù)量百 T，每日指標(biāo)查詢量幾千萬，配置圖表個(gè)數(shù)上萬，看板個(gè)數(shù)上千。

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

CAT 做的事情（開源版）

首先要強(qiáng)調(diào)的是這里我們只能拿到 GitHub 上開源版 CAT 的最新版 3.0.0 ，所以是基于此進(jìn)行對(duì)比。接下來說說 CAT 做了哪些事情？

①抽象出監(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ù)和總和。

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

②采樣鏈路

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

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

目前支持 Counter 和 Timer 類型的打點(diǎn)，支持 tag ，單機(jī)內(nèi)單個(gè) Metric 的 tag 組合數(shù)限制 1000 。

并且有簡單的監(jiān)控看板，如下圖所示：

④與其他組件集成

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

⑤告警

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

餓了么 EMonitor 和 CAT 的對(duì)比

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

①引入 Transaction、Event 的概念

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

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

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

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

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

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

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

• Real-Time Streaming Compute：對(duì)用戶發(fā)過來的鏈路中的 Transaction 、Event 等監(jiān)控模型轉(zhuǎn)變成指標(biāo)數(shù)據(jù)并進(jìn)行 10s 的預(yù)聚合，同時(shí)也對(duì)用戶發(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：對(duì)用戶發(fā)過來的鏈路數(shù)據(jù)構(gòu)建鏈路索引、向 HDFS 和 HBase 寫入索引和鏈路數(shù)據(jù)，同時(shí)會(huì)構(gòu)建應(yīng)用之間的依賴關(guān)系，將依賴關(guān)系寫入到 Neo4j 中。

所以 EMonitor 和 CAT 的一個(gè)很大不同點(diǎn)就在于對(duì)指標(biāo)的處理上， EMonitor 交給專業(yè)的時(shí)序數(shù)據(jù)庫來做。

而 CAT 自己做聚合就顯得功能非常受限，如下所示：

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

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

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

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

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

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

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

②采樣鏈路

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

• CAT 的采樣鏈路是分鐘級(jí)別的， EMonitor 是 10s 級(jí)別的。

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

EMonitor 的鏈路如下所示：

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

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

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

③自定義的 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：測(cè)量值，一般用于衡量隊(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 針對(duì) Metric 開發(fā)了一套可以媲美 Grafana 的指標(biāo)看板。

相比 Grafana 的優(yōu)勢(shì)：

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

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

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

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

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

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

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

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

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

• 可以配置 group by 以及 order by。

看板整體如下所示：

移動(dòng)端顯示如下：

⑤與其他組件集成

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

如下所示：
IaaS 層物理機(jī)、機(jī)房網(wǎng)絡(luò)交換機(jī)等的監(jiān)控指標(biāo)。
PaaS 層中間件服務(wù)端的監(jiān)控指標(biāo)。
應(yīng)用層 SOA、Exception、JVM、MQ 等客戶端的相關(guān)指標(biāo)。
應(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í)間以及和昨天的對(duì)比情況。

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

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

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

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

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

⑥告警

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

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

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

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

• 其他告警形式。

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

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

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

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

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

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

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

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

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

上一階段存在的問題：CAT 對(duì)自定義指標(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)的存儲(chǔ)和查詢，對(duì)接或者自研豐富的指標(biāo)看板如 Grafana 。

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

④平臺(tái)打通整合階段

上一階段存在的問題：系統(tǒng)監(jiān)控、中間件和業(yè)務(wù)監(jiān)控、部分業(yè)務(wù)監(jiān)控、鏈路監(jiān)控與指標(biāo)監(jiān)控都各搞一套數(shù)據(jù)收集、預(yù)處理、存儲(chǔ)、查詢、展現(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ái)。

告警方式：可以統(tǒng)一的針對(duì)各個(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)。

⑤深度分析階段

上一階段存在的問題：

• 用戶雖然可以在一個(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)控平臺(tái)，用戶查詢什么指標(biāo)就展示相應(yīng)的數(shù)據(jù)，監(jiān)控平臺(tái)并不去關(guān)心用戶所存儲(chǔ)數(shù)據(jù)的內(nèi)容。

現(xiàn)在呢就需要轉(zhuǎn)變思路，監(jiān)控平臺(tái)需要主動(dòng)去幫用戶分析里面所存儲(chǔ)的數(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)用做體檢，來主動(dòng)暴露出問題，而不是等用戶去一個(gè)個(gè)查指標(biāo)而后發(fā)現(xiàn)問題。

業(yè)務(wù)大盤：就是根據(jù)業(yè)務(wù)來梳理或者利用鏈路來自動(dòng)生產(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)一解決。

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

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

告警方式：可以統(tǒng)一的針對(duì)各個(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)的變動(dòng)信息。

比如是 Redis 波動(dòng)、Database 波動(dòng)、上下游應(yīng)用的某個(gè)方法波動(dòng)等等，來達(dá)到快速定位問題目的，或者通過對(duì)大盤執(zhí)行根因分析來定位到根因。

再談 Logging、Tracing、Metrics

三者關(guān)系如下圖所示：

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

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

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