CAT分佈式監控系統（一）：CAT監控系統功能介紹
本文概要：
1、CAT監控系統是什麼。
2、CAT監控系統能做什麼，能監控些什麼。
下面有些截圖是CAT 2.0版本的，但和3.0版本沒什麼區別的。
一、 簡介
CAT（Central Application Tracking）是美團開源的基於Java開發的實時分佈式應用監控平臺，提供了全面的監控服務和業務決策支持。
CAT監控系統的定位：
cat本質上一個實時監控系統，主要體現在監控報表Transaction、event、problem、heartbeat等，cat系統定製的監控模型以及定製的實時分析報表也是cat系統核心優勢。
logview是cat原始的log採集方式，cat的logview使用的技術是threadlocal，將一個thread裏面的打點聚合上報，有一點弱化版本的鏈路功能，但是cat並不是一個標準的全鏈路系統，全鏈路系統參考dapper的論文，業內比較知名的鷹眼，zipkin等，其實經常拿cat和這類系統進行比較其實是不合適的。cat的logview在異步線程等等一些場景下，其實不合適，cat本身模型並不適合這個。在美團點評內部，有mtrace專門做全鏈路分析。
也就是說：CAT定義了一個基本的監控模型，可以用來實時監控，至於要監控些什麼可以自己定義，比如要做分佈式全鏈路跟蹤監控，可以自己埋點獲取監控信息；
怎麼埋點也是有參考方案的，下篇博文將會介紹本人重新封裝的客戶端埋點SDK。
另外，CAT傾向於指標、鏈路事件監控，不太適用於大量業務日誌的場景，因爲無法搜索、分析，CAT只看看到最新的樣本數據和出問題的數據。大量業務日誌的場景應該用ELK。
github：https://github.com/dianping/cat
官方DOME：http://unidal.org/cat/r/t?ip=All&queryname=&domain=cat
二、系統/應用狀態監控
接入CAT客戶端後，CAT客戶端每分鐘發送一次自身的狀態信息。
狀態信息包括：服務器系統信息、JVM 內存/GC信息、線程信息、CAT監控使用信息等。詳情如下圖：
狀態信息的原始數據可以查看“Transaction“中的System類型信息，如下圖：
“Heartbeat”實時報表用來展示狀態信息，可以看到當前項目下所有的部署機器（支付中心只有一臺服務器），如下圖：
配置說明：這個功能無需其他配置，接入就自動上傳狀態監控信息。
三、程序代碼運行情況監控
監控一段代碼運行情況：運行時間統計、次數、錯誤次數等等。如下圖：
上面圖一展示的是請求過程中監控的不同代碼段類型的執行情況，不同類型表示範圍不一樣；圖二展示方法類型裏各方法的執行情況。一次請求過程原始監控數據如下（注意類型和上面圖一對應）：
下面對圖中報表進行解釋：
a）Type統計界面
b）Name統計界面
c）一個小時內詳細指標統計
1. Duration Distribution表示transaction的執行時間分佈，這個圖可以看出，大部分shopcheckin是在16-64毫秒完成，還有很少部分在512-1024毫秒完成。
2. HitOverTime、Averager Duration Over Time,Failures Over Time 縱軸都是以5分鐘爲單位，HitOverTime表示5分鐘內的訪問次數。
3. Averager Duration Over Time表示5分鐘內的平均處理時間。
4. Failures Over Time表示5分鐘內的Transaction失敗次數。
配置說明：代碼監控需要相關埋點配置，如方法監控可用包路徑、或用@CatMethodMonitori註解配置，更多配置詳情請參考《項目接入說明》。
四、全鏈路監控分析
上面我們也看到了一次請求過程的原始監控信息，包括URL、METHOD的耗時、參數、返回值等，如下：
其中經歷了一次跨服務調用service-ribbon à service-hi（注意：跨服務是圖中第二個紅框到第三個紅框，而第一個紅框到第二個紅框是穿透Hystrix熔斷器異步線程的），耗時圖形分析如下：
“Cross”報表展示了跨服務調用的情況，如下圖：
相關配置：默認開啓，暫時支持該功能的通信組件：Spring Cloud Ribbon、Spring Cloud Feign（不兼容Sleuth）、Dubbo RPC，更多詳情請參考《項目接入說明》。
五、異常/錯誤等問題監控
Problem記錄整個項目在運行過程中出現的問題，包括一些錯誤、訪問較長的行爲。Problem的類型如下：
1、“Problem”實時報表介紹
All的錯誤界面
錯誤一個小時內的實時趨勢圖
點擊機器IP，進入某一臺機器出現的具體問題，這個包括了All中出現的所有錯誤統計之外，還增加了以分鐘和線程爲單位的錯誤分佈圖，具體如下：
2、“Problem”歷史報表介紹
1）在選擇了特定的域、報表類型、時間和IP之後，點擊[:: show ::] 查看某一Type下的Problem出現次數的分佈圖。(當前這一天、上一天、上週這一天)
2）進一步，可以查看該Type下，某個Status的Problem出現次數的分佈圖。(當前這一天、上一天、上週這一天)
相關配置：URL、方法監控會自動記錄異常名稱，如果需要集成日誌框架（log4j、logback）打印上傳錯誤信息，請參考《項目接入說明》。
六、SQL執行監控
SQL執行監控可以看到每個DAO方法執行解析的SQL語句、SQL語句執行時長、以及連接到哪個數據庫（URL）執行；如果SQL執行出現異常，還會記錄異常信息；另外還可以過濾出慢SQL。
SQL監控執行整體情況如下：
各DAO方法監控如下：
測試一個方法裏執行CURD的“Log View”信息如下：
SQL類型（insert/select/update/delete）執行情況的統計如下：
每個數據庫執行情況的統計如下：
另外，還可以在“Problem”標籤頁面過濾出慢SQL，如下圖：
相關配置：支持Mybatis的SQL監控，需要配置Mybatis監控插件，請參考《項目接入說明》。
七、自定義監控/業務監控
上面介紹這些功能主要是gc-cat-client SDK中實現的，稍微配置一下就可以使用。
除此外，還有可以自定義監控以實現業務監控，CAT客戶端本身提供了幾種監控類型的API， CAT支持的監控消息類型包括：
1）、Transaction：適合記錄跨越系統邊界的程序訪問行爲,比如遠程調用，數據庫調用，也適合執行時間較長的業務邏輯監控，Transaction用來記錄一段代碼的執行時間和次數。
2）、Event：用來記錄一件事發生的次數，比如記錄系統異常，它和transaction相比缺少了時間的統計，開銷比transaction要小。
3）、Heartbeat：表示程序內定期產生的統計信息, 如CPU%, MEM%, 連接池狀態, 系統負載等。
4）、Metric：用於記錄業務指標、指標可能包含對一個指標記錄次數、記錄平均值、記錄總和，業務指標最低統計粒度爲1分鐘。
Metric一共有三個API，分別用來記錄次數、平均、總和，統一粒度爲一分鐘：
a).logMetricForCount：用於記錄一個指標值出現的次數。
b).logMetricForDuration：用於記錄一個指標出現的平均值。
c).logMetricForSum：用於記錄一個指標出現的總和。
看到這些類型名稱，可知我們前面介紹的這些功能也是基於這幾種監控消息類型的API實現的。
一份埋點的樣例：
Transaction：用來記錄一段程序響應時間；Even：用來記錄一行code的執行次數；Metric：用來記錄一個業務指標。這些指標都是獨立的，可以單獨使用，主要看業務場景。
下面的埋點代碼裏面表示需要記錄一個頁面的響應時間，並且記錄一個代碼執行次數，以及記錄兩個業務指標,所有用了一個Transaction，一個Event，兩個Metric。Transaction的埋點一定要complete，切記放在finally裏面。
代碼中自定義好業務指標監控後，然後運行測試上傳一些監控數據，接着到“業務監控配置”頁面（http://192.168.1.52:8888/cat/s/config? op=list）配置大盤顯示和告警，然後就可以在“Business”而頁面看到相關圖表，如下：
八、告警設置
上面業務監控我們也說到業務指標也可以設置告警的，除此外，Transaction/Event/異常/心跳都可以設置告警，如下圖所示：
URL(/hi)執行次數告警測試：
九、其他報表統計
還有一些全局的報表統計，訪問地址（比較隱蔽）：http://192.168.1.52:8888/cat/r/overload
如“全局統計異常”報表，看到各個項目的異常情況：
“服務可用排行”報表，看到各服務可用情況：
“線上容量規劃”報表，看到各項目一些資源使用情況：
十、總結
以上總結了本人發現的且認爲比較有用的CAT監控功能，基本能滿足大部分監控需求，更多功能有待大家挖掘。
另外，下篇博文將會介紹本人重新封裝的CAT客戶端埋點SDK，歡迎提出建議。
【參考資料】
1、 CAT相關文檔
2、 GitHub - dianping/cat: Central Application Tracking
4、 大衆點評網監控平臺剖析