CAT（Central Application Tracking）是一個(gè)實(shí)時(shí)和接近全量的監(jiān)控系統(tǒng)，它側(cè)重于對(duì)Java應(yīng)用的監(jiān)控，基本接入了美團(tuán)上海側(cè)所有核心應(yīng)用。目前在中間件（MVC、RPC、數(shù)據(jù)庫、緩存等）框架中得到廣泛應(yīng)用，為美團(tuán)各業(yè)務(wù)線提供系統(tǒng)的性能指標(biāo)、健康狀況、監(jiān)控告警等。

自2014年開源以來，Github 收獲 7700+ Star，2800+ Forks，被 100+ 公司企業(yè)使用，其中不乏攜程、陸金所、獵聘網(wǎng)、平安等業(yè)內(nèi)知 名公司。在每年全球 QCon 大會(huì)、全球架構(gòu)與運(yùn)維技術(shù)峰會(huì)等都有持續(xù)的技術(shù)輸出，受到行業(yè)內(nèi)認(rèn)可，越來越多的企業(yè)伙伴加入了 CAT 的開 源建設(shè)工作，為 CAT 的成?貢獻(xiàn)了巨大的力量。

項(xiàng)目的開源地址是 http://github.com/dianping/cat。

本文會(huì)對(duì)CAT整體設(shè)計(jì)、客戶端、服務(wù)端等的一些設(shè)計(jì)思路做詳細(xì)深入的介紹。

背景介紹

CAT整個(gè)產(chǎn)品研發(fā)是從2011年底開始的，當(dāng)時(shí)正是大眾點(diǎn)評(píng)從.NET遷移到Java的核心起步階段。當(dāng)初大眾點(diǎn)評(píng)已經(jīng)有核心的基礎(chǔ)中間件、RPC組件Pigeon、統(tǒng)一配置組件Lion。整體Java遷移已經(jīng)在服務(wù)化的路上。隨著服務(wù)化的深入，整體Java在線上部署規(guī)模逐漸變多，同時(shí)，暴露的問題也越來越多。典型的問題有：

• 大量報(bào)錯(cuò)，特別是核心服務(wù)，需要花很久時(shí)間才能定位。
• 異常日志都需要線上權(quán)限登陸線上機(jī)器排查，排錯(cuò)時(shí)間長。
• 有些簡(jiǎn)單的錯(cuò)誤定位都非常困難（一次將線上的庫配置到了Beta，花了整個(gè)通宵排錯(cuò)）。
• 很多不了了之的問題懷疑是網(wǎng)絡(luò)問題（從現(xiàn)在看，內(nèi)網(wǎng)真的很少出問題）。

雖然那時(shí)候也有一些簡(jiǎn)單的監(jiān)控工具（比如Zabbix，自己研發(fā)的Hawk系統(tǒng)等），可能單個(gè)工具在某方面的功能還不錯(cuò)，但整體服務(wù)化水平參差不齊、擴(kuò)展能力相對(duì)較弱，監(jiān)控工具間不能互通互聯(lián)，使得查找問題根源基本都需要在多個(gè)系統(tǒng)之間切換，有時(shí)候真的是靠“人品”才能找出根源。

適逢在eBay工作長達(dá)十幾年的吳其敏加入大眾點(diǎn)評(píng)成為首席架構(gòu)師，他對(duì)eBay內(nèi)部應(yīng)用非常成功的CAL系統(tǒng)有深刻的理解。就在這樣天時(shí)地利人和的情況下，我們開始研發(fā)了大眾點(diǎn)評(píng)第一代監(jiān)控系統(tǒng)——CAT。

CAT的原型和理念來源于eBay的CAL系統(tǒng)，最初是吳其敏在大眾點(diǎn)評(píng)工作期間設(shè)計(jì)開發(fā)的。他之前曾CAT不僅增強(qiáng)了CAL系統(tǒng)核心模型，還添加了更豐富的報(bào)表。

整體設(shè)計(jì)

監(jiān)控整體要求就是快速發(fā)現(xiàn)故障、快速定位故障以及輔助進(jìn)行程序性能優(yōu)化。為了做到這些，我們對(duì)監(jiān)控系統(tǒng)的一些非功能做了如下的要求：

• 實(shí)時(shí)處理：信息的價(jià)值會(huì)隨時(shí)間銳減，尤其是事故處理過程中。
• 全量數(shù)據(jù)：最開始的設(shè)計(jì)目標(biāo)就是全量采集，全量的好處有很多。
• 高可用：所有應(yīng)用都倒下了，需要監(jiān)控還站著，并告訴工程師發(fā)生了什么，做到故障還原和問題定位。
• 故障容忍：CAT本身故障不應(yīng)該影響業(yè)務(wù)正常運(yùn)轉(zhuǎn)，CAT掛了，應(yīng)用不該受影響，只是監(jiān)控能力暫時(shí)減弱。
• 高吞吐：要想還原真相，需要全方位地監(jiān)控和度量，必須要有超強(qiáng)的處理吞吐能力。
• 可擴(kuò)展：支持分布式、跨IDC部署，橫向擴(kuò)展的監(jiān)控系統(tǒng)。
• 不保證可靠：允許消息丟失，這是一個(gè)很重要的trade-off，目前CAT服務(wù)端可以做到4個(gè)9的可靠性，可靠系統(tǒng)和不可靠性系統(tǒng)的設(shè)計(jì)差別非常大。

CAT從開發(fā)至今，一直秉承著簡(jiǎn)單的架構(gòu)就是最好的架構(gòu)原則，主要分為三個(gè)模塊：CAT-client、CAT-consumer、CAT-home。

• Cat-client 提供給業(yè)務(wù)以及中間層埋點(diǎn)的底層SDK。
• Cat-consumer 用于實(shí)時(shí)分析從客戶端提供的數(shù)據(jù)。
• Cat-home 作為用戶給用戶提供展示的控制端。

在實(shí)際開發(fā)和部署中，Cat-consumer和Cat-home是部署在一個(gè)JVM內(nèi)部，每個(gè)CAT服務(wù)端都可以作為consumer也可以作為home，這樣既能減少整個(gè)層級(jí)結(jié)構(gòu)，也可以增加系統(tǒng)穩(wěn)定性。

上圖是CAT目前多機(jī)房的整體結(jié)構(gòu)圖，圖中可見：

• 路由中心是根據(jù)應(yīng)用所在機(jī)房信息來決定客戶端上報(bào)的CAT服務(wù)端地址，目前美團(tuán)有廣州、北京、上海三地機(jī)房。
• 每個(gè)機(jī)房?jī)?nèi)部都有獨(dú)立的原始信息存儲(chǔ)集群HDFS。
• CAT-home可以部署在一個(gè)機(jī)房也可以部署在多個(gè)機(jī)房，在最后做展示的時(shí)候，home會(huì)從consumer中進(jìn)行跨機(jī)房的調(diào)用，將所有的數(shù)據(jù)合并展示給用戶。
• 實(shí)際過程中，consumer、home以及路由中心都是部署在一起的，每個(gè)服務(wù)端節(jié)點(diǎn)都可以充當(dāng)任何一個(gè)角色。

客戶端設(shè)計(jì)

客戶端設(shè)計(jì)是CAT系統(tǒng)設(shè)計(jì)中最為核心的一個(gè)環(huán)節(jié)，客戶端要求是做到API簡(jiǎn)單、高可靠性能，無論在任何場(chǎng)景下都不能影響客業(yè)務(wù)性能，監(jiān)控只是公司核心業(yè)務(wù)流程一個(gè)旁路環(huán)節(jié)。CAT核心客戶端是Java，也支持Net客戶端，近期公司內(nèi)部也在研發(fā)其他多語言客戶端。以下客戶端設(shè)計(jì)及細(xì)節(jié)均以Java客戶端為模板。

設(shè)計(jì)架構(gòu)

CAT客戶端在收集端數(shù)據(jù)方面使用ThreadLocal（線程局部變量），是線程本地變量，也可以稱之為線程本地存儲(chǔ)。其實(shí)ThreadLocal的功用非常簡(jiǎn)單，就是為每一個(gè)使用該變量的線程都提供一個(gè)變量值的副本，屬于Java中一種較為特殊的線程綁定機(jī)制，每一個(gè)線程都可以獨(dú)立地改變自己的副本，不會(huì)和其它線程的副本沖突。

在監(jiān)控場(chǎng)景下，為用戶提供服務(wù)都是Web容器，比如tomcat或者Jetty，后端的RPC服務(wù)端比如Dubbo或者Pigeon，也都是基于線程池來實(shí)現(xiàn)的。業(yè)務(wù)方在處理業(yè)務(wù)邏輯時(shí)基本都是在一個(gè)線程內(nèi)部調(diào)用后端服務(wù)、數(shù)據(jù)庫、緩存等，將這些數(shù)據(jù)拿回來再進(jìn)行業(yè)務(wù)邏輯封裝，最后將結(jié)果展示給用戶。所以將所有的監(jiān)控請(qǐng)求作為一個(gè)監(jiān)控上下文存入線程變量就非常合適。

如上圖所示，業(yè)務(wù)執(zhí)行業(yè)務(wù)邏輯的時(shí)候，就會(huì)把此次請(qǐng)求對(duì)應(yīng)的監(jiān)控存放于線程上下文中，存于上下文的其實(shí)是一個(gè)監(jiān)控樹的結(jié)構(gòu)。在最后業(yè)務(wù)線程執(zhí)行結(jié)束時(shí)，將監(jiān)控對(duì)象存入一個(gè)異步內(nèi)存隊(duì)列中，CAT有個(gè)消費(fèi)線程將隊(duì)列內(nèi)的數(shù)據(jù)異步發(fā)送到服務(wù)端。

API設(shè)計(jì)

監(jiān)控API定義往往取決于對(duì)監(jiān)控或者性能分析這個(gè)領(lǐng)域的理解，監(jiān)控和性能分析所針對(duì)的場(chǎng)景有如下幾種：

• 一段代碼的執(zhí)行時(shí)間，一段代碼可以是URL執(zhí)行耗時(shí)，也可以是SQL的執(zhí)行耗時(shí)。
• 一段代碼的執(zhí)行次數(shù)，比如Java拋出異常記錄次數(shù)，或者一段邏輯的執(zhí)行次數(shù)。
• 定期執(zhí)行某段代碼，比如定期上報(bào)一些核心指標(biāo)：JVM內(nèi)存、GC等指標(biāo)。
• 關(guān)鍵的業(yè)務(wù)監(jiān)控指標(biāo)，比如監(jiān)控訂單數(shù)、交易額、支付成功率等。

在上述領(lǐng)域模型的基礎(chǔ)上，CAT設(shè)計(jì)自己核心的幾個(gè)監(jiān)控對(duì)象：Transaction、Event、Heartbeat、Metric。

一段監(jiān)控API的代碼示例如下：

序列化和通信

序列化和通信是整個(gè)客戶端包括服務(wù)端性能里面很關(guān)鍵的一個(gè)環(huán)節(jié)。

• CAT序列化協(xié)議是自定義序列化協(xié)議，自定義序列化協(xié)議相比通用序列化協(xié)議要高效很多，這個(gè)在大規(guī)模數(shù)據(jù)實(shí)時(shí)處理場(chǎng)景下還是非常有必要的。
• CAT通信是基于Netty來實(shí)現(xiàn)的NIO的數(shù)據(jù)傳輸，Netty是一個(gè)非常好的NIO開發(fā)框架，在這邊就不詳細(xì)介紹了。

客戶端埋點(diǎn)

日志埋點(diǎn)是監(jiān)控活動(dòng)的最重要環(huán)節(jié)之一，日志質(zhì)量決定著監(jiān)控質(zhì)量和效率。當(dāng)前CAT的埋點(diǎn)目標(biāo)是以問題為中心，像程序拋出exception就是典型問題。我個(gè)人對(duì)問題的定義是：不符合預(yù)期的就可以算問題，比如請(qǐng)求未完成、響應(yīng)時(shí)間快了慢了、請(qǐng)求TPS多了少了、時(shí)間分布不均勻等等。

在互聯(lián)網(wǎng)環(huán)境中，最突出的問題場(chǎng)景，突出的理解是：跨越邊界的行為。包括但不限于：

• HTTP/REST、RPC/SOA、MQ、Job、Cache、DAL;
• 搜索/查詢引擎、業(yè)務(wù)應(yīng)用、外包系統(tǒng)、遺留系統(tǒng);
• 第三方網(wǎng)關(guān)/銀行, 合作伙伴/供應(yīng)商之間；
• 各類業(yè)務(wù)指標(biāo)，如用戶登錄、訂單數(shù)、支付狀態(tài)、銷售額。

遇到的問題

通常Java客戶端在業(yè)務(wù)上使用容易出問題的地方就是內(nèi)存，另外一個(gè)是CPU。內(nèi)存往往是內(nèi)存泄露，占用內(nèi)存較多導(dǎo)致業(yè)務(wù)方GC壓力增大； CPU開銷最終就是看代碼的性能。

以前我們遇到過一個(gè)極端的例子，我們一個(gè)業(yè)務(wù)請(qǐng)求做餐飲加商鋪的銷售額，業(yè)務(wù)一般會(huì)通過for循環(huán)所有商鋪的分店，結(jié)果就造成內(nèi)存OOM了，后來發(fā)現(xiàn)這家店是肯德基，有幾萬分店，每個(gè)循環(huán)里面都會(huì)有數(shù)據(jù)庫連接。在正常場(chǎng)景下，ThreadLocal內(nèi)部的監(jiān)控一個(gè)對(duì)象就存在幾萬個(gè)節(jié)點(diǎn)，導(dǎo)致業(yè)務(wù)Oldgc特別嚴(yán)重。所以說框架的代碼是不能想象業(yè)務(wù)方會(huì)怎么用你的代碼，需要考慮到任何情況下都有出問題的可能。

在消耗CPU方面我們也遇到一個(gè)case：在某個(gè)客戶端版本，CAT本地存儲(chǔ)當(dāng)前消息ID自增的大小，客戶端使用了MappedByteBuffer這個(gè)類，這個(gè)類是一個(gè)文件內(nèi)存映射，測(cè)試下來這個(gè)類的性能非常高，我們僅僅用這個(gè)存儲(chǔ)了幾個(gè)字節(jié)的對(duì)象，正常情況理論上不會(huì)有任何問題。在一次線上場(chǎng)景下，很多業(yè)務(wù)線程都block在這個(gè)上面，結(jié)果發(fā)現(xiàn)當(dāng)本身這臺(tái)機(jī)器IO存在瓶頸時(shí)候，這個(gè)也會(huì)變得很慢。后來的優(yōu)化就是把這個(gè)IO的操作異步化，所以客戶端需要盡可能異步化，異步化序列化、異步化傳輸、異步化任何可能存在時(shí)間延遲的代碼操作。

服務(wù)端設(shè)計(jì)

服務(wù)端主要的問題是大數(shù)據(jù)的實(shí)時(shí)處理，目前后端CAT的計(jì)算集群大約35臺(tái)物理機(jī)，存儲(chǔ)集群大約35臺(tái)物理機(jī)，每天處理了約100TB的數(shù)據(jù)量。線上單臺(tái)機(jī)器高峰期大約是110MB/s，接近千兆網(wǎng)打滿。

下面我重點(diǎn)講下CAT服務(wù)端一些設(shè)計(jì)細(xì)節(jié)。

架構(gòu)設(shè)計(jì)

在最初的整體介紹中已經(jīng)畫了架構(gòu)圖，這邊介紹下單機(jī)的consumer中大概的結(jié)構(gòu)如下：

如上圖，CAT服務(wù)端在整個(gè)實(shí)時(shí)處理中，基本上實(shí)現(xiàn)了全異步化處理。

• 消息接受是基于Netty的NIO實(shí)現(xiàn)。
• 消息接受到服務(wù)端就存放內(nèi)存隊(duì)列，然后程序開啟一個(gè)線程會(huì)消費(fèi)這個(gè)消息做消息分發(fā)。
• 每個(gè)消息都會(huì)有一批線程并發(fā)消費(fèi)各自隊(duì)列的數(shù)據(jù)，以做到消息處理的隔離。
• 消息存儲(chǔ)是先存入本地磁盤，然后異步上傳到HDFS文件，這也避免了強(qiáng)依賴HDFS。

當(dāng)某個(gè)報(bào)表處理器處理來不及時(shí)候，比如Transaction報(bào)表處理比較慢，可以通過配置支持開啟多個(gè)Transaction處理線程，并發(fā)消費(fèi)消息。

實(shí)時(shí)分析

CAT服務(wù)端實(shí)時(shí)報(bào)表分析是整個(gè)監(jiān)控系統(tǒng)的核心，CAT重客戶端采集的是是原始的logview，目前一天大約有1000億的消息，這些原始的消息太多了，所以需要在這些消息基礎(chǔ)上實(shí)現(xiàn)豐富報(bào)表，來支持業(yè)務(wù)問題及性能分析的需要。

CAT是根據(jù)日志消息的特點(diǎn)(比如只讀特性)和問題場(chǎng)景，量身定做的，它將所有的報(bào)表按消息的創(chuàng)建時(shí)間，一小時(shí)為單位分片，那么每小時(shí)就產(chǎn)生一個(gè)報(bào)表。當(dāng)前小時(shí)報(bào)表的所有計(jì)算都是基于內(nèi)存的，用戶每次請(qǐng)求即時(shí)報(bào)表得到的都是最新的實(shí)時(shí)結(jié)果。對(duì)于歷史報(bào)表，因?yàn)樗遣蛔兊?#xff0c;所以實(shí)時(shí)不實(shí)時(shí)也就無所謂了。

CAT基本上所有的報(bào)表模型都可以增量計(jì)算，它可以分為：計(jì)數(shù)、計(jì)時(shí)和關(guān)系處理三種。計(jì)數(shù)又可以分為兩類：算術(shù)計(jì)數(shù)和集合計(jì)數(shù)。典型的算術(shù)計(jì)數(shù)如：總個(gè)數(shù)（count）、總和（sum）、均值（avg）、最大/最小（max/min)、吞吐（tps）和標(biāo)準(zhǔn)差（std）等，其他都比較直觀，標(biāo)準(zhǔn)差稍微復(fù)雜一點(diǎn)，大家自己可以推演一下怎么做增量計(jì)算。那集合運(yùn)算，比如95線（表示95%請(qǐng)求的完成時(shí)間）、999線（表示99.9%請(qǐng)求的完成時(shí)間），則稍微復(fù)雜一些，系統(tǒng)開銷也更大一點(diǎn)。

報(bào)表建模

CAT每個(gè)報(bào)表往往有多個(gè)維度，以transaction報(bào)表為例，它有5個(gè)維度，分別是應(yīng)用、機(jī)器、Type、Name和分鐘級(jí)分布情況。如果全維度建模，雖然靈活，但開銷將會(huì)非常之大。CAT選擇固定維度建模，可以理解成將這5個(gè)維度組織成深度為5的樹，訪問時(shí)總是從根開始，逐層往下進(jìn)行。

CAT服務(wù)端為每個(gè)報(bào)表單獨(dú)分配一個(gè)線程，所以不會(huì)有鎖的問題，所有報(bào)表模型都是非線程安全的，其數(shù)據(jù)是可變的。這樣帶來的好處是簡(jiǎn)單且低開銷。

CAT報(bào)表建模是使用自研的Maven Plugin自動(dòng)生成的。所有報(bào)表是可合并和裁剪的，可以輕易地將2個(gè)或多個(gè)報(bào)表合并成一個(gè)報(bào)表。在報(bào)表處理代碼中，CAT大量使用訪問者模式（visitor pattern）。

性能分析報(bào)表

故障發(fā)現(xiàn)報(bào)表

• 實(shí)時(shí)業(yè)務(wù)指標(biāo)監(jiān)控 ：核心業(yè)務(wù)都會(huì)定義自己的業(yè)務(wù)指標(biāo)，這不需要太多，主要用于24小時(shí)值班監(jiān)控，實(shí)時(shí)發(fā)現(xiàn)業(yè)務(wù)指標(biāo)問題，圖中一個(gè)是當(dāng)前的實(shí)際值，一個(gè)是基準(zhǔn)值，就是根據(jù)歷史趨勢(shì)計(jì)算的預(yù)測(cè)值。如下圖就是當(dāng)時(shí)的情景，能直觀看到支付業(yè)務(wù)出問題的故障。

• 系統(tǒng)報(bào)錯(cuò)大盤。
• 實(shí)時(shí)數(shù)據(jù)庫大盤、服務(wù)大盤、緩存大盤等。

存儲(chǔ)設(shè)計(jì)

CAT系統(tǒng)的存儲(chǔ)主要有兩塊：

• CAT的報(bào)表的存儲(chǔ)。
• CAT原始logview的存儲(chǔ)。

報(bào)表是根據(jù)logview實(shí)時(shí)運(yùn)算出來的給業(yè)務(wù)分析用的報(bào)表，默認(rèn)報(bào)表有小時(shí)模式、天模式、周模式以及月模式。CAT實(shí)時(shí)處理報(bào)表都是產(chǎn)生小時(shí)級(jí)別統(tǒng)計(jì)，小時(shí)級(jí)報(bào)表中會(huì)帶有最低分鐘級(jí)別粒度的統(tǒng)計(jì)。天、周、月等報(bào)表都是在小時(shí)級(jí)別報(bào)表合并的結(jié)果報(bào)表。

原始logview存儲(chǔ)一天大約100TB的數(shù)據(jù)量，因?yàn)閿?shù)據(jù)量比較大所以存儲(chǔ)必須要要壓縮，本身原始logview需要根據(jù)Message-ID讀取，所以存儲(chǔ)整體要求就是批量壓縮以及隨機(jī)讀。在當(dāng)時(shí)場(chǎng)景下，并沒有特別合適成熟的系統(tǒng)以支持這樣的特性，所以我們開發(fā)了一種基于文件的存儲(chǔ)以支持CAT的場(chǎng)景，在存儲(chǔ)上一直是最難的問題，我們一直在這塊持續(xù)的改進(jìn)和優(yōu)化。

消息ID的設(shè)計(jì)

CAT每個(gè)消息都有一個(gè)唯一的ID，這個(gè)ID在客戶端生成，后續(xù)都通過這個(gè)ID在進(jìn)行消息內(nèi)容的查找。典型的RPC消息串起來的問題，比如A調(diào)用B的時(shí)候，在A這端生成一個(gè)Message-ID，在A調(diào)用B的過程中，將Message-ID作為調(diào)用傳遞到B端，在B執(zhí)行過程中，B用context傳遞的Message-ID作為當(dāng)前監(jiān)控消息的Message-ID。

CAT消息的Message-ID格式ShopWeb-0a010680-375030-2，CAT消息一共分為四段：

• 第一段是應(yīng)用名shop-web。
• 第二段是當(dāng)前這臺(tái)機(jī)器的IP的16進(jìn)制格式，0a01010680表示10.1.6.108。
• 第三段的375030，是系統(tǒng)當(dāng)前時(shí)間除以小時(shí)得到的整點(diǎn)數(shù)。
• 第四段的2，是表示當(dāng)前這個(gè)客戶端在當(dāng)前小時(shí)的順序遞增號(hào)。

存儲(chǔ)數(shù)據(jù)的設(shè)計(jì)

消息存儲(chǔ)是CAT最有挑戰(zhàn)的部分。關(guān)鍵問題是消息數(shù)量多且大，目前美團(tuán)每天處理消息1000億左右，大小大約100TB，單物理機(jī)高峰期每秒要處理100MB左右的流量。CAT服務(wù)端基于此流量做實(shí)時(shí)計(jì)算，還需要將這些數(shù)據(jù)壓縮后寫入磁盤。

整體存儲(chǔ)結(jié)構(gòu)如下圖：

CAT在寫數(shù)據(jù)一份是Index文件，一份是Data文件.

• Data文件是分段GZIP壓縮，每個(gè)分段大小小于64K，這樣可以用16bits可以表示一個(gè)最大分段地址。
• 一個(gè)Message-ID都用需要48bits的大小來存索引，索引根據(jù)Message-ID的第四段來確定索引的位置，比如消息Message-ID為ShopWeb-0a010680-375030-2，這條消息ID對(duì)應(yīng)的索引位置為2*48bits的位置。
• 48bits前面32bits存數(shù)據(jù)文件的塊偏移地址，后面16bits存數(shù)據(jù)文件解壓之后的塊內(nèi)地址偏移。
• CAT讀取消息的時(shí)候，首先根據(jù)Message-ID的前面三段確定唯一的索引文件，在根據(jù)Message-ID第四段確定此Message-ID索引位置，根據(jù)索引文件的48bits讀取數(shù)據(jù)文件的內(nèi)容，然后將數(shù)據(jù)文件進(jìn)行GZIP解壓，在根據(jù)塊內(nèi)偏移地址讀取出真正的消息內(nèi)容。

服務(wù)端設(shè)計(jì)總結(jié)

CAT在分布式實(shí)時(shí)方面，主要?dú)w結(jié)于以下幾點(diǎn)因素：

• 去中心化，數(shù)據(jù)分區(qū)處理。
• 基于日志只讀特性，以一個(gè)小時(shí)為時(shí)間窗口，實(shí)時(shí)報(bào)表基于內(nèi)存建模和分析，歷史報(bào)表通過聚合完成。
• 基于內(nèi)存隊(duì)列，全面異步化、單線程化、無鎖設(shè)計(jì)。
• 全局消息ID，數(shù)據(jù)本地化生產(chǎn)，集中式存儲(chǔ)。
• 組件化、服務(wù)化理念。

總結(jié)

最后我們?cè)倩ㄒ稽c(diǎn)點(diǎn)時(shí)間來講一下我們?cè)趯?shí)踐里做的一些東西。

一、MVP版本，Demo版本用了1個(gè)月，MVP版本用了3個(gè)月。

為什么強(qiáng)調(diào)MVP版本？因?yàn)樽鲞@個(gè)項(xiàng)目需要老板和業(yè)務(wù)的支持。大概在2011年左右，我們整個(gè)生產(chǎn)環(huán)境估計(jì)也有一千臺(tái)機(jī)器（虛擬機(jī)），一旦出現(xiàn)問題就到運(yùn)維那邊看日志，看日志的痛苦大家都應(yīng)該理解，這時(shí)候發(fā)現(xiàn)一臺(tái)機(jī)器核心服務(wù)出錯(cuò)，可能會(huì)導(dǎo)致更多的問題。我們就做了MVP版本解決這個(gè)問題，當(dāng)時(shí)我們大概做了兩個(gè)功能：一個(gè)是實(shí)時(shí)知道所有的API接口訪問量成功率等；第二是實(shí)時(shí)能在CAT平臺(tái)上看到異常日志。這里我想說的是MVP版本不要做太多內(nèi)容，但是在做一個(gè)產(chǎn)品的時(shí)候必須從MVP版本做起，要做一些最典型特別亮眼的功能讓大家支持你。

二、數(shù)據(jù)質(zhì)量。數(shù)據(jù)質(zhì)量是整個(gè)監(jiān)控體系里面非常關(guān)鍵，它決定你最后的監(jiān)控報(bào)表質(zhì)量。所以我們要和跟數(shù)據(jù)庫框架、緩存框架、RPC框架、Web框架等做深入的集成，讓業(yè)務(wù)方便收集以及看到這些數(shù)據(jù)。

三、單機(jī)開發(fā)環(huán)境，這也是我們認(rèn)為對(duì)整個(gè)項(xiàng)目開發(fā)效率提升最重要的一點(diǎn)。單機(jī)開發(fā)環(huán)境實(shí)際上就是說你在一臺(tái)機(jī)器里可以把你所有的項(xiàng)目都啟起來。如果你在一個(gè)單機(jī)環(huán)境下把所有東西啟動(dòng)起來，你就會(huì)想方設(shè)法地知道我依賴的服務(wù)掛了我怎么辦？比如CAT依賴了HDFS。單機(jī)開發(fā)環(huán)境除了大幅度提高你的項(xiàng)目開發(fā)效率之外，還能提升你整個(gè)項(xiàng)目的可靠性。

四、最難的事情是項(xiàng)目上線推動(dòng)。CAT整個(gè)項(xiàng)目大概有兩三個(gè)人，當(dāng)時(shí)白天都是支持業(yè)務(wù)上線，培訓(xùn)，晚上才能code，但是一旦隨著產(chǎn)品和完善以及業(yè)務(wù)使用逐漸變多，一些好的產(chǎn)品后面會(huì)形成良性循環(huán)，推廣就會(huì)變得比較容易。

五、開放生態(tài)。公司越大監(jiān)控的需求越多，報(bào)表需求也更多，比如我們美團(tuán)，產(chǎn)品有很多報(bào)表，整個(gè)技術(shù)體系里面也有很多報(bào)表非常多的自定義報(bào)表，很多業(yè)務(wù)方都提各自的需求。最后我們決定把整個(gè)CAT系統(tǒng)里面所有的數(shù)據(jù)都作為API暴露出去，這些需求并不是不能支持，而是這事情根本是做不完的。美團(tuán)內(nèi)部下游有很多系統(tǒng)依賴CAT的數(shù)據(jù)，來做進(jìn)一步的報(bào)表展示。

CAT項(xiàng)目從2011年開始做，到現(xiàn)在整個(gè)生產(chǎn)環(huán)境大概有三千應(yīng)用，監(jiān)控的服務(wù)端從零到幾千，再到今天的兩萬多的規(guī)模，整個(gè)項(xiàng)目是從歷時(shí)看起來是一個(gè)五年多的項(xiàng)目，但即使是做了五年多的這樣一個(gè)項(xiàng)目，目前還有很多的需求需要開發(fā)。這邊也打個(gè)廣告，我們團(tuán)隊(duì)急缺人，歡迎對(duì)監(jiān)控系統(tǒng)研發(fā)有興趣的同學(xué)加入，請(qǐng)聯(lián)系yong.you@dianping.com.

總結(jié)

以上是生活随笔為你收集整理的深度剖析开源分布式监控CAT的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。