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

[[283123]]

 

圖片來自 Pexels

餓了么監(jiān)控系統(tǒng) EMonitor ：是一款服務于餓了么所有技術部門的一站式監(jiān)控系統(tǒng)，覆蓋了系統(tǒng)監(jiān)控、容器監(jiān)控、網(wǎng)絡監(jiān)控、中間件監(jiān)控、業(yè)務監(jiān)控、接入層監(jiān)控以及前端監(jiān)控的數(shù)據(jù)存儲與查詢。

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

CAT：是基于 Java 開發(fā)的實時應用監(jiān)控平臺，為美團點評提供了全面的實時監(jiān)控告警服務。

CAT 做的事情(開源版)

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

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

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

• Transaction：用來記錄一段代碼的執(zhí)行時間和次數(shù)。
• Event：用來記錄一件事發(fā)生的次數(shù)。
• Heartbeat：表示程序內(nèi)定期產(chǎn)生的統(tǒng)計信息，如 CPU 利用率。
• Metric：用于記錄業(yè)務指標，可以記錄次數(shù)和總和。

針對 Transaction 和 Event 都固定了兩個維度， type 和 name ，并且針對 type 和 name 進行分鐘級聚合成報表并展示曲線。

 

②采樣鏈路

針對上述 Transaction、Event 的 type 和 name 分別有對應的分鐘級的采樣鏈路。

 

③自定義的 Metric 打點

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

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

 

④與其他組件集成

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

 

⑤告警

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

餓了么 EMonitor 和 CAT 的對比

餓了么 EMonitor 借鑒了 CAT 的相關思想，同時又進行了改進。

①引入 Transaction、Event 的概念

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

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

 

CAT 的消費機需要做如下兩件事情：

• 對 Transaction、Event 等消息模型按照 type 和 name 進行當前小時的聚合，歷史小時的聚合數(shù)據(jù)寫入到 MySQL 中。
• 將鏈路數(shù)據(jù)寫入到本地文件或者遠程 HDFS 上。

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

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

 

• Real-Time Streaming Compute：對用戶發(fā)過來的鏈路中的 Transaction 、Event 等監(jiān)控模型轉(zhuǎn)變成指標數(shù)據(jù)并進行 10s 的預聚合，同時也對用戶發(fā)過來的 Metric 數(shù)據(jù)進行 10s 預聚合。

最后將 10s 預聚合的數(shù)據(jù)寫入到 LinDB 時序數(shù)據(jù)庫(已開源，有興趣的可以關注 star 下)中，以及 Kafka 中，讓告警模塊 watchdog 去消費 Kafka 做實時告警。

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

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

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

• CAT 只能整小時的查看 type 和 name 數(shù)據(jù)，不能跨小時，即不能查看任意兩個時間之間的報表數(shù)據(jù)， EMonitor 沒有此限制。
• CAT 沒法查看所有 type 匯總后的響應時間和 QPS ， EMonitor 可以靈活的自由組合 type 和 name 進行聚合。
• CAT 的 type 和 name 報表是分鐘級的， EMonitor 是 10s 級別的。
• CAT 的 type 和 name 沒能和歷史報表曲線直接對比， EMonitor 可以對比歷史報表曲線，更容易發(fā)現(xiàn)問題。
• CAT 的 type 和 name 列表首頁展示了一堆數(shù)字，無法立即獲取一些直觀信息。
• 比如給出了響應時間 TP99 100ms 這個到底是好還是壞， EMonitor 有當前曲線和歷史曲線，相對來說可以直接判斷到底 ok 不 ok。
• CAT的 TP99、TP999 基于單機內(nèi)某個小時內(nèi)的報表是準確的，除此之外多機或者多個小時的聚合 TP99、TP999 是用加權(quán)平均來計算的，準確性有待提高。

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

• CAT 含有 TP999、TP9999 線(但是準確性還有些問題)， EMonitor 只能細到 TP99 。
• CAT 的 type 和 name 可以按照機器維度進行過濾， EMonitor 沒有做到這么細粒度。

②采樣鏈路

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

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

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

EMonitor 的鏈路如下所示：

 

• 上圖是某個10s 時刻、某個 type 和 name 過濾條件下的采樣鏈路。
• 第一行是這 10s 內(nèi)的采樣鏈路，按照響應時間進行了排序。
• 可以隨意點擊某個響應時間來查看對應的鏈路詳情。

③自定義的 Metric 打點

EMonitor 支持 Counter、Timer、Histogram、Payload、Gauge 等等多種形式的打點方式，并且支持 tag ：

• Counter：計數(shù)累加類型。
• Timer：可以記錄一段代碼的耗時，包含執(zhí)行次數(shù)、耗時最大值、最小值、平均值。
• Histogram：包含 Timer 的所有東西，同時支持計算 TP99 線，以及其他任意 TP 線(從 0 到 100 )。
• Payload：可以記錄一個數(shù)據(jù)包的大小，包含數(shù)據(jù)包個數(shù)、包的最大值、最小值、平均值。
• Gauge：測量值，一般用于衡量隊列大小、連接數(shù)、CPU、內(nèi)存等等。

也就是任意 Metric 打點都可以流經(jīng) EMonitor 進行處理了并輸送到 LinDB 時序數(shù)據(jù)庫中。

至此， EMonitor 就可以將任何監(jiān)控指標統(tǒng)一在一起了，比如機器監(jiān)控都可以通過 EMonitor 來保存了，這為一站式監(jiān)控系統(tǒng)奠定了基礎。

④自定義 Metric 看板

CAT 只有一個簡易的 Metric 看板。EMonitor 針對 Metric 開發(fā)了一套可以媲美 Grafana 的指標看板。

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

• 有一套類似 SQL 的非常簡單的配置指標的方式。
• 跟公司人員組織架構(gòu)集成，更加優(yōu)雅的權(quán)限控制，不同的部門可以建屬于自己的看板。
• 指標和看板的收藏，當源指標或看板改動后，無需收藏人員再改動。
• alpha、beta、prod 不同環(huán)境之間的一鍵同步指標和看板，無需配置多次。
• PC 端和移動端的同步查看指標和看板。

 

類 SQL 的配置查詢指標方式如下所示：

• 可以配置圖表的展現(xiàn)形式。
• 可以配置要查詢的字段以及字段之間的加減乘除等豐富的表達式。
• 可以配置多個任意 tag 的過濾條件。
• 可以配置 group by 以及 order by。

看板整體如下所示：

 

移動端顯示如下：

 

⑤與其他組件集成

 

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

如下所示：

 

• IaaS 層物理機、機房網(wǎng)絡交換機等的監(jiān)控指標。
• PaaS 層中間件服務端的監(jiān)控指標。
• 應用層 SOA、Exception、JVM、MQ 等客戶端的相關指標。
• 應用層自定義的監(jiān)控指標。

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

 

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

• 左邊列表給出每條 SQL 的執(zhí)行的平均耗時。
• 右邊 2 個圖表給出該條 SQL 在 DAL 中間件層面、 DB 層面的耗時以及調(diào)用 QPS。
• 可以給出該 SQL 打在后端 DAL 中間、 DB 上的分布情況，可以用于排查是否存在一些熱點的情況。
• 還有一些 SQL 查詢結(jié)果的數(shù)據(jù)包大小的曲線、 SQL 被 DAL 限流的情況等等。
• 可以查看任何時間點上該 SQL 的調(diào)用鏈路信息。

 

再以打通餓了么 SOA 服務為例：

• 可以根據(jù)機房和狀態(tài)信息進行過濾。
• 左邊一欄列出該應用提供的 SOA 服務接口，同時給出平均響應時間以及和昨天的對比情況。
• 右邊的兩個圖表分別給出了對應服務接口的服務響應時間和 QPS 以及和昨天的對比情況，同時可以切換平均響應時間到 TP99 或者其他 TP 值，同時配有可以快速對相關曲線添加告警的跳轉(zhuǎn)鏈接。
• 可以切換到單機維度來查看每臺機器該 SOA 接口的響應時間和 QPS ，用來定位某臺機器的問題。
• 可以給出該 SOA 接口調(diào)用在不同集群的分布占比。
• 可以給出該 SOA 接口的所有調(diào)用方以及他們的 QPS。
• 可以查看任何時間點上該 SOA 接口的調(diào)用鏈路信息。

⑥告警

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

• 閾值：簡單的閾值告警，適用于 CPU 、內(nèi)存等。
• 同環(huán)比：與過去同期比較的告警。
• 趨勢：適合于相對平滑連續(xù)的無需閾值的智能告警。
• 其他告警形式。

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

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

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

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

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

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

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

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

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

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

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

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

④平臺打通整合階段

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

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

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

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

⑤深度分析階段

上一階段存在的問題：

• 用戶雖然可以在一個系統(tǒng)中看到所有各個層面的監(jiān)控數(shù)據(jù)了，但是每次排障時仍然要花很多的時間去查看各個層面是否有問題，一旦漏看一項可能就錯過了問題所在的根因。
• 沒有整個業(yè)務的全局監(jiān)控視角，都停留在各自應用的角度。

總之：之前的階段都是去做一個監(jiān)控平臺，用戶查詢什么指標就展示相應的數(shù)據(jù)，監(jiān)控平臺并不去關心用戶所存儲數(shù)據(jù)的內(nèi)容。

現(xiàn)在呢就需要轉(zhuǎn)變思路，監(jiān)控平臺需要主動去幫用戶分析里面所存儲的數(shù)據(jù)內(nèi)容。

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

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

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

根因分析：一個大盤有很多的環(huán)節(jié)，每個環(huán)節(jié)綁定有很多的指標，每次某個告警出來有可能需要詳細的分析下每個環(huán)節(jié)的指標。

比如消費 Kafka 的延遲上升，有各種各樣的原因都可能導致，每次告警排查都需要將分析流程再全部人為分析排查下，非常累，所以需要將定位根因的過程通過建模抽象下，來進行統(tǒng)一解決。

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

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

告警方式：可以統(tǒng)一的針對各個層面的監(jiān)控數(shù)據(jù)做統(tǒng)一化的告警排障過程：NOC 根據(jù)業(yè)務指標或者業(yè)務大盤快速得知是哪些業(yè)務或者應用先出了問題，應用的 owner 通過應用大盤的體檢得知相關的變動信息。

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

再談 Logging、Tracing、Metrics

三者關系如下圖所示：

 

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

• 三者在監(jiān)控排障中的所占比例卻大不一樣：Metrics 占據(jù)大頭， Tracing 次之， Logging 最后。
• Tracing 含有重要的應用之間的依賴信息， Metrics 有更多的可深度分析和挖掘的空間，所以未來必然是在 Metrics 上大做文章。

再結(jié)合 Tracing 中的應用依賴來做更深度全局分析，即 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ù)據(jù)庫 LinDB 項目負責人，目前致力于監(jiān)控的智能分析領域。