“
本文通過對比分析下兩者所做的事情為契機討論監控系統或許該有的面貌，以及淺談下監控系統發展的各個階段。
圖片來自
餓了么監控系統 ：是一款服務于餓了么所有技術部門的一站式監控系統，覆蓋了系統監控、容器監控、網絡監控、中間件監控、業務監控、接入層監控以及前端監控的數據存儲與查詢。
每日處理總數據量近 PB ，每日寫入指標數據量百 T，每日指標查詢量幾千萬，配置圖表個數上萬，看板個數上千。
CAT：是基于 Java 開發的實時應用監控平臺，為美團點評提供了全面的實時監控告警服務。
CAT 做的事情（開源版）
首先要強調的是這里我們只能拿到 上開源版 CAT 的最新版 3.0.0 ，所以是基于此進行對比。接下來說說 CAT 做了哪些事情？
①抽象出監控模型
抽象出 、Event、、 4 種監控模型：
針對 和 Event 都固定了兩個維度， type 和 name ，并且針對 type 和 name 進行分鐘級聚合成報表并展示曲線。
②采樣鏈路
針對上述 、Event 的 type 和 name 分別有對應的分鐘級的采樣鏈路。
③自定義的 打點
目前支持 和 Timer 類型的打點，支持 tag ，單機內單個 的 tag 組合數限制 1000 。
并且有簡單的監控看板，如下圖所示：
④與其他組件集成
比如和 集成，在客戶端開啟相關的 sql 執行統計，并將該統計劃分到 統計看板中的 type=SQL 的一欄下。
⑤告警
可以針對上述的 、Event 等做一些簡單的閾值告警。
餓了么 和 CAT 的對比
餓了么 借鑒了 CAT 的相關思想，同時又進行了改進。
①引入 、Event 的概念
針對 和 Event 都固定了兩個維度， type 和 name ，不同地方在于聚合用戶發過來的數據。
CAT 的架構圖如下所示：
CAT 的消費機需要做如下兩件事情：
的架構圖如下所示：
分兩路對數據進行隔離處理：
所以 和 CAT 的一個很大不同點就在于對指標的處理上， 交給專業的時序數據庫來做。
而 CAT 自己做聚合就顯得功能非常受限，如下所示：
但是CAT也有自己的優勢：
②采樣鏈路
目前 CAT 和 都可以通過 type 和 name 來過濾采樣鏈路，不同點在于：
的鏈路如下所示：
③自定義的 打點
支持 、Timer、、、Gauge 等等多種形式的打點方式sql獲取當前系統時間，并且支持 tag ：
也就是任意 打點都可以流經 進行處理了并輸送到 LinDB 時序數據庫中。
至此， 就可以將任何監控指標統一在一起了，比如機器監控都可以通過 來保存了，這為一站式監控系統奠定了基礎。
④自定義 看板
CAT 只有一個簡易的 看板。 針對 開發了一套可以媲美 的指標看板。
相比 的優勢：
類 SQL 的配置查詢指標方式如下所示：
看板整體如下所示：
移動端顯示如下：
⑤與其他組件集成
目前 已經打通了 IaaS 層、 PaaS 層、應用層的所有鏈路和指標的監控，再也不用在多個監控系統中切換來切換去了。
如下所示：
以打通餓了么分庫分表中間件 DAL 為例：
可以根據機房、執行狀態、表、操作類型（比如 、、 等）進行過濾查看：
再以打通餓了么 SOA 服務為例：
⑥告警
可以針對所有的監控指標配置如下告警方式：
淺談監控系統的發展趨勢
①日志監控階段
本階段實現方式：程序打日志，使用 ELK 來存儲和查詢程序的運行日志，ELK 也能簡單顯示指標曲線。
排障過程：一旦有問題，則去 ELK 中搜索可能的異常日志來進行分析排障。
②鏈路監控階段
上一個階段存在的問題：ELK 只是基于一行一行日志進行聚合或者搜索分析，日志之間沒有上下文關聯。很難知道一次請求耗時較長究竟耗時在哪個階段。
本階段實現方式：CAT 橫空出世，通過建模抽象出 、 等監控模型，將鏈路分析和簡單的報表帶入了大家的視野。
告警方式：針對報表可以進行閾值監控排障過程：一旦有告警sql獲取當前系統時間，可以通過點擊報表來詳細定位到是哪個 type 或 name 有一定問題，順便找到對應的鏈路，查看詳細的信息。
③指標監控階段
上一階段存在的問題：CAT 對自定義指標支持的比較弱，也無法實現或者展現更加多樣的查詢聚合需求。
本階段的實現方式：支持豐富的 指標，將鏈路上的一些報表數據也可以劃分到指標中，交給專業的時序數據庫來做指標的存儲和查詢，對接或者自研豐富的指標看板如 。
告警方式：針對指標進行更加豐富的告警策略排障過程：一旦有告警，可能需要到各個系統上查看指標看板，粗略定位根因，再結合鏈路總和分析。
④平臺打通整合階段
上一階段存在的問題：系統監控、中間件和業務監控、部分業務監控、鏈路監控與指標監控都各搞一套數據收集、預處理、存儲、查詢、展現、告警流程，各個系統處理數據格式、使用方式不統一。
本階段的實現方式：打通從系統層面、容器層面、中間件層面、業務層面等等的可能的鏈路和指標監控，統一數據的處理流程，同時整合發布、變更、告警與監控曲線結合，成為一站式監控平臺。
告警方式：可以統一的針對各個層面的監控數據做統一化的告警排障過程：只需要在一個監控系統中就可以查看到所有的監控曲線和鏈路信息。
目前我們 已完成這個階段，將公司之前存在已久的 3 套獨立的監控系統統一整合成現如今的一套監控系統。
⑤深度分析階段
上一階段存在的問題：
總之：之前的階段都是去做一個監控平臺，用戶查詢什么指標就展示相應的數據，監控平臺并不去關心用戶所存儲數據的內容。
現在呢就需要轉變思路，監控平臺需要主動去幫用戶分析里面所存儲的數據內容。
本階段的實現方式：所要做的就是把幫用戶分析的過程抽象出來，為用戶構建應用大盤和業務大盤，以及為大盤做相關的根因分析。
應用大盤：就是為當前應用構建上下游應用依賴的監控、當前應用所關聯的機器監控、Redis、MQ、 等等監控，可以時刻為應用做體檢，來主動暴露出問題，而不是等用戶去一個個查指標而后發現問題。
業務大盤：就是根據業務來梳理或者利用鏈路來自動生產大盤，該大盤可以快速告訴用戶是哪些業務環節出的問題。
根因分析：一個大盤有很多的環節，每個環節綁定有很多的指標，每次某個告警出來有可能需要詳細的分析下每個環節的指標。
比如消費 Kafka 的延遲上升，有各種各樣的原因都可能導致，每次告警排查都需要將分析流程再全部人為分析排查下，非常累，所以需要將定位根因的過程通過建模抽象下，來進行統一解決。
趨勢報表分析：主動幫用戶發現一些逐漸惡化的問題點，比如用戶發布之后，接口耗時增加，很可能用戶沒有發現，雖然當前沒有問題，但是很有可能在明天的高峰期就會暴露問題，這些都是已經實實在在發生的事故。
要想做主動分析，還深度依賴指標下鉆分析，即某個指標調用量下降了，能主動分析出是哪些 tag 維度組合導致的下降，這是上述很多智能分析的基礎，這一塊也不簡單。
告警方式：可以統一的針對各個層面的監控數據做統一化的告警排障過程：NOC 根據業務指標或者業務大盤快速得知是哪些業務或者應用先出了問題，應用的 owner 通過應用大盤的體檢得知相關的變動信息。
比如是 Redis 波動、 波動、上下游應用的某個方法波動等等，來達到快速定位問題目的，或者通過對大盤執行根因分析來定位到根因。
再談 、、
三者關系如下圖所示：
三者的確都不可或缺，相輔相成，但是我想說以下幾點：
參考資料：