本文根據尤勇在【QCon高可用架構羣】中的分享內容整理而成。
尤勇是大衆點評網資深工程師，開源監控系統CAT(Central Application Tracking)的開發者，目前主要負責C和大衆點評私有云平臺的開發。
CAT是一個實時監控系統，它側重於Java應用的監控，基本接入了點評所有核心應用。CAT已經在中間件框架（MVC框架、RPC框架、數據庫框架、緩存框架等）中得到廣泛應用，爲點評各業務線提供系統的性能指標、健康狀況、基礎告警等。
CAT很大的優勢是它是一個實時系統，從數據生成到服務端處理結束是毫秒級別；第二個優勢，數據是接近全量統計。
CAT背景介紹
大衆點評監控系統CAT是由@吳其敏@攜程（前大衆點評首席架構師，現攜程架構負責人）主導設計。我們平常都稱吳其敏爲老吳，老吳之前在eBay工作超過10年，對於eBay的CAL系統有深入瞭解，CAL是CAT系統當初的原型。
爲什麼要做監控
線上發佈了服務，怎麼知道它一切正常，比如發佈5臺服務器，如何直觀瞭解是否有請求進來，訪問一切正常。
當年有一次將線上的庫配置到了Beta，這麼低級的錯誤，排錯花了一個通宵，十幾個人。
某個核心服務掛了，導致大量報錯，如何確定到底是哪裏出了問題。
SOA帶來的問題，調用XX服務出問題，很慢，是否可以衡量？
應用程序有性能瓶頸，如何提供一些有效工具發現？
…...
監控應該是一個很寬泛的問題，任何可能出問題地方都需要加入監控。
服務端監控
我們把服務端監控的報表分爲兩類：
故障快速發現類，這類主要是面向運維，讓運維直觀看到生產環境出現的問題。
系統問題分析類，這類主要是面向開發，讓開發能瞭解自己系統實時運行狀態，發現問題，分析瓶頸等。
故障發現類的報表有如下幾個：
實時業務指標監控 ：核心業務都會定義自己的業務指標，這不需要太多，主要用於24小時值班監控，實時發現業務指標問題，圖中一個是當前的實際值，一個是基準值，基準值是根據歷史趨勢計算的預測值。
實時報錯大盤： 所有應用的topN的報錯大盤，下圖是一個出現故障的圖。
實時數據庫大盤
A. 實時數據庫大盤，實時知道數據庫訪問情況的大盤。如何確定存在問題，是根據實時的數據在加一些配置的訪問規則。
B. 這裏不要用DB服務端性能採集的數據（比如io，load，qps等），要用應用程序訪問這個database得出的響應時間、錯誤、訪問量的數據，這裏稱之爲端到端的數據。
C. 應用程序採集的數據和服務端的數據得出的結果會有很大很大的差異。
D. 後面的閃電符號是一個url link，這邊可以直接跳轉到運維的自動化平臺上，做database故障降級處理。實時核心網絡拓撲大盤
這裏採集了核心接入層網絡交換機的一些信息，將一些狀態定製到監控大盤上，主要的採集指標包括：進入口流量、丟包、錯包等。
以上講了我們做的給運維，更準確的是24小時值班監控團隊的監控大屏，主要目的是快速發現問題，這裏不需要很華麗的數字，主要用精確的紅色來代表發現故障，需要立刻通知解決。
什麼東西纔可以作爲一個大盤：這裏需要看公司整體運維的故障情況，TopN以及業務指標應該屬於通用，數據庫和網絡大盤是點評在實際經驗中經常容易出故障的地方，所以我們做成大盤這樣比較直觀的形式，用於發現問題。比如平時因爲發佈引起故障比較多，他們也做了一個發佈大盤，實時監控線上的發佈情況。
下面我會講到服務端分析問題的報表，在這之前我介紹幾個CAT監控的幾個基礎概念。
首先第一點就是監控的模型，監控最需要解決的兩個問題，響應時間和訪問量。
響應時間，一段代碼的響應時間，一段代碼可大可小，比如一段sql，一個服務訪問，一個url整個請求。
訪問量，走到一行code的次數，比如拋出的異常，走到代碼某個if的路徑等。
在這個基礎上我們定義監控最基礎的模型，Transaction和Event，這個也是後續問題最多的地方。
後面還擴展定期執行某些代碼以及一個指標變化值，第三個可以理解爲心跳（主要是框架使用）。最後一個一個指標變化值，主要用於業務指標的監控。 在這個基本模型的基礎上，我們定義了我們監控的Java的API，Sample大致如下：
這個API裏面Transaction以及Event都有兩層分類，爲什麼是兩層分類，從實際的經驗中兩層分類可以解決大部分的問題，所以定義了兩層。 當業務程序完成了API的情況，後面會產生CAT的原始監控請求，這裏我們稱之爲Logview。
這個Logview是一個樹的結構，根節點一般都是Transaction，Transaction可以嵌套子的Transaction，Event就是一個單個節點，不能嵌套。這個longview將應用程序的執行路徑按照時間序列組成一個Logview。
它還有另外一種展現形式，它很直觀看到整個調用路徑中最慢的地方。
整個點評邁向SOA化，Web調用服務，服務再調用其他的服務，調用關係的跟蹤很有必要。
在點評Call表示一個遠程訪問，當遇到一個遠程訪問時候，會有一個show節點，點擊show就能知道服務端對應這次Call的它的訪問序列，如果這個服務還調用其他的服務，一樣可以跟蹤下去。比如如下請求是URL，調用了groupService的服務，groupService的服務還調用了userBaseService的服務
以上部分講訴了整個CAT監控最核心的模型以及在此基礎上產生的Logview，後續監控產生所有的原始數據都來自於Logview。在點評監控，目前是做的全量監控，也意味着每次URL請求，SQL請求、緩存請求、遠程請求都有對應的實時Logview發送CAT以供實時處理。
監控裏面，儘量做全量監控，這樣看到的問題才足夠接近真實。監控儘可能做到實時，延遲一分鐘或者幾分鐘都意味着故障處理總時間的延長。
CAT每天大約有300億Logview，3500GB消息，Logview太多了人已經沒辦法處理，所以基於Logview肯定有一些實時分析的report，下面我講訴監控系統基於這些logview產生幾個核心的report。
1、TransactionReport
這個是TransationReport的第一個視圖，左上角可以選擇項目進行切換，一個項目定義爲一個獨立的war包上線單元。報表時間是一段時間，CAT統計報表的時間跨度是一個小時。根據一個小時的report，後續可以合併爲天、周、以及月。
Machines: 有一個All以及具體的機器明顯，可以看所有機器，也可以看單個某臺機器，如果某臺機器出現的問題，則可以很容易看到。
這裏展示了一個Transaction的第一層分類的視圖，可以知道這段時間裏面一個分類運行的次數，平均響應時間，延遲，95線以及99.9線。95line表示95%的請求的響應時間比這個值要小。
上圖這裏面是點擊URL進去的第二層，可以看到第二層的具體明細，統計值也是一樣。
看到這個數據能幫助我們什麼？
比如看到URL下面dependency的訪問量爲566，響應時間爲778ms，就需要多想，這樣的耗時有麼與辦法優化，這樣的訪問量是否合理。主要響應時間和訪問量，任何優化就可以開始以及有了根據。
TransactionReport是我們平時做優化最最常用的一張report。 點擊最左邊Show可以按照時間展示，可以看到按照分鐘粒度的精確的展示，1分鐘是CAT監控最小的粒度單元。
這裏的Transaction的埋點的Type和Name是業務自己定義。
2、EventReport
EventReport整體是和TransactionReport結構幾乎一樣，可以根據項目，ip進行導航，但是少了一個響應時間的概念，這裏只有訪問量。可以按照type展示，查詢二級目錄的情況，可以看到show，看到分鐘級別的趨勢圖。具體參考transaction，這邊我不多講了。
Event有個比較作用能方便幫助業務做一些業務上統計，舉個例子比如看每天用戶登錄次數或者代碼裏面有三個分支，可以很簡單使用Event API幫你做統計。
3、ProblemReport
之前講述過每個應用每次的請求都會有CAT的監控的Logview，這樣龐大的數量下，ProblemReport等於定義了很多特徵，特徵包括如下，ProblemReport就是把一堆logview中存在這些特徵的給聚合爲一個報表，讓用戶發現問題。
異常（Java裏面拋出的異常）
URL訪問出錯以及慢
緩存訪問出錯以及慢
數據庫訪出錯以及曼
服務訪問出錯以及慢
上訴報表就是tuangou-web項目一段時間內的產生的各種問題，右邊Looooooooog之類，就可以看到原始出錯的logview。這個loview可以看到很多明細，比如輸入的參數等，還有前後一些邏輯。這樣的logview信息是很容易幫助用戶發現問題。
上圖我點擊一個異常的後面的O，就看到這次異常出現的完整的上下文信息。
點擊show，可以看到此類錯誤對應的機器分佈情況以及分鐘粒度的趨勢圖，通過這個很容發現是否某臺機器故障還是全局問題等。
業務開發他們需要fix裏面一些比較嚴重的問題。比如SQL慢響應很多（比如通過索引或者緩存），服務慢響應（如何優化），調用下游錯誤（如果推動下游服務端解決），異常（NPE）等等。
4、Heartbeat Report
這裏主要CAT客戶端定期一分鐘向服務端彙報當前運行時候的一些狀態，幾個比較常用的指標有：
系統內存、swap、load
GC信息，GC時間以及數量，Java內存狀態
核心的一些線程數，比如http，一些RPC框架線程等
展示方式按照某臺機器的維度查詢
心跳報表還需要有一定擴展性，這裏CAT提供了一個SPI讓業務實現並註冊上來，這樣可以每分鐘上報心跳並回調，讓後把數據一起傳回服務端，並作監控展示。常見的使用場景有：當前機器每個數據庫的連接數、當前jvm使用隊列的當前隊列數量等。
最後一個Report Cross Report
這個報表主要作用瞭解決在RPC框架裏面的一些上下游調用鏈路的問題，統計粒度支持項目、具體某一IP、具體的服務方法。
比如上圖是當前項目xx-web調用了4個服務，調用每個服務的響應時間，訪問量以及錯誤量。
點擊某個項目進去可以知道具體調用此服務的具體每臺機器的情況如下，記得前端時間微博的同事分享過線上一臺服務掛了，導致了1/8的請求有問題，如果CAT能接入進去，應該是很快就能立刻發現是其中一臺服務出現故障。
點擊ALL或者單臺機器可以知道調用具體此服務某個方法耗時情況。
這個報表還有很多其他作用了，比如作爲一個服務端，他可以知道當前有多少客戶端訪問我，可以查詢服務端一個方法被多少客戶端調用，每個客戶端調用的響應以及耗時等等。（這裏往往會發現個別比較糟糕應用用一些不太合理的方式調用，比如夜裏的Job，大量的batch調用等，這樣就會考慮獨立部署幾臺給個別應用調用）。
CAT還有其他的一些報表，這裏我就不一一介紹了，有興趣同學可以參考下CAT的文檔。
Matrix 調用鏈路分析，統計調用鏈路上緩存，數據庫，遠程服務情況。
Storage 存儲節點分析，調用某個數據庫節點或者緩存節點情況。
Cache 緩存命中率分析，針對category的緩存命中率。
Dependency 依賴節點分析，分鐘級別依賴數據庫、緩存等情況。
CAT一些離線分析報表，比如jar版本分析，服務可用性排行等等。
系統設計
如上圖CAT在當初設計的基本幾個點，在再次基礎上我們後面很多方案都是基於此來實現。對應用無影響是必須的，實時性我們要求做到毫秒級，由於是全量監控，所以吞吐量也是需要保證，最後是開銷，開銷不能因爲應用接入監控提高很多的延遲。
最後兩個可靠性，應用端是否確定把所有消息傳輸到服務端，以及服務端是否必須處理所有消息，我們認爲是沒有必要的，但從實際的結果看來，有4個9的可用性。比如昨天數據，一共處理240億，丟了50w消息。
下面講到客戶端設計一些要點
設計思路
基於Java TheadLocal實現，跨線程的調用目前不能自動實現（需要顯示調用API）。
主線程同步構建消息，構建消息結束之後，放入內存隊列。
消息傳輸是基於Netty實現。
內存開銷
由於埋點問題，消息足夠大，比如一個message有幾萬個節點。做消息切割。（不做消息會導致oom）
比如查詢一個商戶月交易額，for循環商戶的門店，然後查詢數據庫每天計算累加，結果遇到了肯德基，幾萬家店鋪吧。監控需要做到在用戶任何極端不正確使用的場景下，也要保證業務正常。內部使用隊列，限定長度，full即丟棄。（messageQueue也限定長度，不然也會oom）
CPU開銷
構建消息足夠輕量，純內存計算。
異步編碼以及異步傳輸，目前消息沒有做gzip壓縮。
服務端的設計
目前CAT在高峯時候吞吐量單臺機器有16w/s，千萬網卡高峯時候已經打滿（近期會換萬兆網卡）。
服務端實時處理主要按照時間的分桶（一個小時一個桶）以及基於內存隊列全異步處理。
Analyzer是每個小時都是獨立線程，線程之間沒有任何鎖，在高併發高吞吐場景下，儘可能避免鎖的競爭。
原始消息的存儲，我們這裏使用了最簡單的文件存儲，文件索引以及內存都是自己定義以及實現。
存儲上的一些考慮
文件足夠簡單，簡單的東西就是好東西（老吳說過）。
hdfs的作用就是一個集中式的存儲，將寫好的文件異步傳輸存到hdfs上，hdfs作爲一個集中式的存儲。異步的話當hdfs掛了可以做到容錯，hdfs維護升級通常是幾個小時。 1 原始消息大小大約3500GB，我們希望文件需要是壓縮來節省空間。
消息內容查詢需要支持到Key-Value，Key就是消息ID，Value就是消息內容。
所以存儲需要做到順序寫，壓縮後隨機讀。
下圖是整個文件存儲的設計圖
在消息ID設計上，是${domain}+${ip}+${timestamp}+${index}，這作爲唯一的KEY，所以CAT不支持同一個IP部署兩個相同的應用。同一個IP部署多個不同的應用是沒有問題的。所有的文件都加上cat的consumer的ip作爲後綴，保證文件上傳到hdfs上不會有文件的衝突。
壓縮採用的是分塊壓縮，數據塊的大小在64K以內，所以記錄每個消息對應的所在塊以及消息在所在塊的偏移量。當需要找到某個消息，先隨機訪問到某一個塊，將這個塊全部讀取出來，然後根據塊內偏移地址找到對應的Logview，因爲消息可能是在多個文件中，最後檢查下讀取到的logview的id等於查詢時候的id，即找到消息。
總結
這裏說下點評實際的一些經驗。
很快到了今天總結的時候，這部分我會講講監控在點評一路的情況，有些問題的解決，如果還有其他的疑問，後續大家可以提問
第一個重點是埋點工作
Transaction埋點，主要記錄一些跨項目，跨模塊一些調用。最主要有三個，遠程服務，數據庫以及緩存。點評是在中間件上做的埋點，比如PRC框架，數據訪問層框架，緩存框架，然後在業務線全部升級框架。
Event埋點，主要記錄事件以及異常。最常見的場景就是當埋Transaction時候，需要event作爲補充，比如記錄當時訪問參數等。代碼一些特殊詭異路徑的分析，還有異常信息記錄。
Metric埋點，主要用於記錄了一些實際的業務指標，用於運維監控。Heartbeat不需要業務埋點。
當業務需要監控自己一段代碼訪問行爲，他可以自己使用API，常見有訪問第三方服務等等，一些比較複雜的邏輯算法等。當業務用好之後發現能解決問題之後，基本用了就停不下來，有的team第三方購買的系統，都會加入cat埋點，因爲遇到過第三方系統性能問題沒辦法分析。
監控系統需要做成開放式系統，每個核心的report最好能提供api，讓其他程序能夠訪問，每個業務的想看的一些指標展示各不相同，監控是無法完成業務定製化report需求，所以需要每個報表都能api，把自己做成一個數據平臺。目前有不少項目是自己寫程序爬CAT數據，作爲自己整個項目的週報，技術指標。還有一些用來推動業務進行技術優化的業務線橫向報表原始數據都來自CAT。
CAT不僅僅在生產環境做了部署，在線下以及性能環境也做了部署，qa做壓力測試、功能測試都會去看cat上面的數據，相比於以前測試，可以大量節省他們的時間，跑一次自動化case迴歸，看看CAT上面的報錯，響應時間，訪問量，大概就知道程序是否存在問題。
在實際推廣過程中，培訓很重要，並不是所有人都能很清楚知道和接受CAT怎麼用，相對資深同事更加容易接受。很多其他的公司部署了CAT，就是因爲有好幾個同事都是從點評離職過去，部署起來的。
整個CAT項目從2012初到現在，到現在大約3年多時間，整個過程持續2-3個人，幾點感觸和大家分享
先做小做精，再做大做全
持續集成，持續發佈，不斷監控
單機開發和調試
Everything Fails
關注客戶，快速響應
站在巨人的肩膀上
在今天演講的最後，請允許我打一次廣告，CAT的地址 https://github.com/dianping/cat 有興趣可以按照步驟搭建下，搭建過程我們寫了一鍵工具。 CAT很多其他的文檔都寫搭建的系統首頁上，只要本機有個mysql即可，CAT就能單機部署並運行起來。
Q1：監控系統數據採集的頻率如何把控？
CAT是全量數據採集，心跳數據是1分鐘一次。如果服務器或者硬件監控，一般幾秒一次。如果是特別重要的，可以一秒一次。
Q2：監控項一般都有哪些？
比較通用的監控項，也就是核心框架裏面監控項目，比如遠程訪問，數據庫訪問，緩存訪問的響應時間，訪問量等。
心跳裏面的監控項有
系統內存、swap、load
GC信息，GC時間以及數量，Java內存狀態
核心的一些線程數，比如http，一些RPC框架線程等
Q3：報表系統現在有很多開源的東西可以做，尤老師有沒推薦的？
建議報表系統還是自己做比較合適，報表這類需求定製太多了，比如按照部門、產品線等統計。
Q4: 跟其他開源監控方案對比如何？
開源的監控系統，比如zabbix，nagios，cacit算是很成熟的一套監控系統，他們能通過腳本或者snmp協議等收集很多服務端的性能數據，並配置很多監控規則來發現服務器等一些問題。點評這些也在用，主要是zabbix，他和CAT互相補充。
之前小米開源的系統應該也是基於指標的畫圖以及告警，和CAT應該是兩類不同的系統。
Q5: 能不能舉例說明一下服務監控和App監控的具體做法,有沒有最佳實踐？
服務端監控，就應該類似於我上面講的CAT在服務端監控一些做法，不僅僅包括問題發現，還包括了性能調優，路徑分析等等，這樣才能把幫助業務分析並找到問題。
App監控，由於時間問題，今天沒有講到，這裏說幾個點吧。App監控點評做了三個部分：
返回碼系統（多維度下，API、城市、運營商、網絡、APP版本等）
實時Crash日誌（版本、平臺、模塊等維度）
測速系統（打開一個APP某個頁面的分段速度測試，一個頁面可能包括廣告，導航、圖片等，每個階段的速度測試）
Q6: 有沒有CAT跟Dubbo集成的案例？
Dubbo是阿里的一套PRC開源框架，目前我們沒有集成的case，CAT和點評PRC組件集成得很好，堅信應該不是問題。
Q7: Cat是否適合創業公司用？希望不要太重。
創業公司可以根據自己實際需要，以及對於CAT的理解做出的一個評估。我理解的監控，是承接了公司整個開發流程上閉環的一個重要角色。監控能幫助應用發現問題，分析問題，找到問題，然後在快速進行迭代。如果要我說，我覺得應該是適合的。
重和不重，這點我不太好說，埋點的深度決定了監控的高度，可以輕量級使用，也可以重度使用。服務端對於創業公司來說應該很輕量，只需要MySQL即可，只要本地磁盤足夠OK，HDFS都可以不需要。
Q8：實施&運維的成本多大？
個人覺得運維成本不大，主要是使用以及依賴組件很少，MySQL，極端情況HDFS都可以不需要。
Q9：數據傳輸用Netty而不是基於現有消息隊列，是爲什麼？
基於性能考慮。Netty本身是非常成熟的開源網絡組件，event機制、全異步、高性能，還有簡單易用，非常適合於框架和基礎設施開發。CAT用Netty做長連接通訊，吞吐量非常高，健康檢測、故障轉移和故障恢復能力都非常強。消息隊列根本不適合這麼底層的數據傳輸，它的overhead太大，很多feature CAT並不需要。
Q10：有沒有實現內部服務調用鏈分析，如果有，能不能講一下大概思路？
用CAT可以將在多臺機器或多個進程的消息串起來，組成調用鏈。基本的思路是，在常用的場景中，客戶端產生一個新的消息ID，連同自己的消息ID在調用時作爲參數傳遞到服務端，然後在服務端的消息使用傳過來的消息ID，來存儲，並用客戶端的消息ID作爲向上的鏈接。這樣客戶端和服務器端就可以有雙向的鏈接了。但是這需要在相關的框架中埋點。
Q11：如果網絡斷了，數據在本地能備份嗎？
CAT客戶端有一個queue，queue是固定大小了，CAT一臺客戶端會連向幾個服務端，當一個服務端出問題，數據不會丟失。當所有服務端都掛掉，消息會存入queue，當queue滿了，就丟棄了，沒有做數據存儲本地等工作。
Q12：傳輸數據是什麼格式？有壓縮嗎？
數據傳輸格式爲普通文本，自己實現的序列化和反序列化，目前沒有做壓縮，壓縮需要考慮到客戶端和服務端的cpu壓力。
服務端存儲數據是有壓縮的，壓縮比例大概爲8:1
Q13：部署CAT，對監控的應用和服務器大概有多少影響？ CAT服務掛掉，如果避免不影響業務？
對於應用的服務基本影響很小，在做極端的壓力測試下，加上CAT以及不加入CAT，峯值qps影響在10%以內，均值基本不變。
CAT客戶端和服務端的通信都是異步的，當服務全部宕機，客戶端丟失消息即可。
Q14: 服務的調用鏈，怎麼做到在中間件層面判斷依賴關係？如果不是在中間件，分佈式裏面，怎麼做設計的上下游依賴？
上下游調用，主要用到全局統一項目名，這是點評一套架構上的規範，可以理解爲環境信息。RPC能在當前的運行環境下知道自己當前的項目名以及調用者的項目名。
Q15：是否有多語言client支持？
支持JAVA和 .Net。
Q16：CAT自身的健康狀態監測？
當一個客戶端不 work，client 會自動連接上 next server，所以有一個管理連接的線程，保持一個活動有效的連接，如果 server 全部掛了，消息就丟棄了。
Q17：如何檢測到丟失的消息數？
所有的消息都是基於消息隊列處理，如果隊列滿了，會有記錄。
Q18：CAT有做字節碼插樁麼？
沒有。
Q19: 對JVM的監控，是通過jstat腳本來收集數據的嗎？數據是客戶端上報，還是服務端拉取，數據格式也是logview？
不是通過腳本，具體的收集可以參考源碼 StatusInfoCollector，主要用到 MemoryMXBean， MemoryPoolMXBean等。
數據上報的格式也是logview，是客戶端主動一分鐘上報一次。
Q20: 客戶端上報數據的話，服務端可以不用高可用吧？
服務端儘量做到高可用吧。
Q21：手機客戶端的監控是怎麼做的，直接發到CAT還是業務系統轉發呢？
手機監控其實是另外一套系統，最後展示層在CAT。
Q20：我們在用Nagios做系統和服務的監控，但對服務調用鏈的監控，基本上是空白。不知能不能有機會聽一下中間件層面的服務調用是怎麼監控的。
服務端會分析上報logview，埋點信息會有客戶端和服務端的項目名信息，後端可以用此數據進行實時分析。
Q21: 這種數據用TCP長連接彙報的麼？爲什麼沒考慮使用UDP?是爲了可靠性麼？還是其他考量？
UDP在線下測試很不穩定，經常丟棄什麼，TCP的比UDP多的開銷其實對業務影響很小。
CAT系統最初的設計者吳其敏補充說： 如果系統的消息丟失率達到一定的比例，那麼它的的可信度就會降低，所以保證足夠多的消息能夠被好好處理是很重要的。CAT設計成不可靠系統，但實際上我們希望系統足夠可靠，只是不願爲承諾可靠而付出高額代價。 以前研究過Dapper，覺得它的機制與CAT相差很遠，監控的全面性不夠。當然如果到了Google的量級，情況就很不一樣了。
TCP是有連接的，有擁塞控制；UDP無連接，一般情況下內網成功率還是挺高的，極端情況下將非常糟糕。