前言

最近，剛換了一家公司，第一個任務就是要在CAT的基礎上做二次開發(fā)，老大讓先看一個星期的源碼，利用國慶假期，就好好的做一下總結。首先，這一篇博客就來聊一聊CAT到底是個什么鬼

思維導圖+概述

下邊是我總結的思維導圖，分別從what？why？how？的角度進行說明

what是什么：

cat是由美團的尤勇和吳其敏主導設計，使用java開發(fā)打造的實時應用監(jiān)控平臺。

why為什么：它可以幫助我們解決什么問題？

• 線上發(fā)布了服務，怎么知道它一切正常，比如發(fā)布5臺服務器，如何直觀了解是否有請求進來，訪問一切正常。
• 當年有一次將線上的庫配置到了Beta，這么低級的錯誤，排錯花了一個通宵，十幾個人。
• 某個核心服務掛了，導致大量報錯，如何確定到底是哪里出了問題。
• SOA帶來的問題，調(diào)用XX服務出問題，很慢，是否可以衡量？
• 應用程序有性能瓶頸，如何提供一些有效工具發(fā)現(xiàn)？
• ……

Cat擁有什么樣的能力，可以解決上述問題？

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

how怎么實現(xiàn):

收集階段：負責業(yè)務應用日志的埋點和采集。CAT目前提供多種語言的客戶端供業(yè)務應用程序調(diào)用，埋點結果以消息樹的形式存入傳輸隊列。如果隊列滿，則會自動丟棄當前消息。

傳輸階段：CAT客戶端負責將客戶端消息傳輸?shù)胶蠖?#xff0c;CAT消費機負責接收消息。傳輸前CAT客戶端會與CAT消費機建立TCP長連接，不斷地從客戶端隊列中取出消息樹，序列化后寫入網(wǎng)絡；CAT消費機則不斷地從網(wǎng)絡中取出數(shù)據(jù)，反序列化后放入消費隊列。

分析階段：負責報表生成。實時消費調(diào)度器會將消費隊列消息取出，分發(fā)給每個消費者內(nèi)部隊列；報表分析器只會從自己的報表隊列中取出消息樹，逐個消費，更新報表模型。CAT以小時為單位形成報表，原始日志轉(zhuǎn)儲(raw log dump)是一個特殊的分析器，它不生產(chǎn)報表，而是將消息存入本地文件系統(tǒng)。

存儲階段：負責報表和原始日志的存儲，目前報表會存在MySQL中，原始日志壓縮后存在HDFS中長久保存。保留時長取決于存儲容量的大小，一般報表會保存3個月以上，原始日志保存一個月。

展示階段：負責數(shù)據(jù)的可視化。作為用戶服務入口，負責報表和原始日志的輸出顯示。對于實時報表請求，會向各個消費機分發(fā)請求，并將結果聚合后輸出HTML，在瀏覽器展示；歷史報表會直接取自數(shù)據(jù)庫。XML數(shù)據(jù)輸出是另一種內(nèi)置的數(shù)據(jù)展示方式，方便基于CAT開放外圍工具。

告警階段：可以進行閾值配置，如果超過一定閾值會根據(jù)告警策略的配置進行不同方式的告警（短信、微信、郵件）

總結

今天只是簡單的概述一下CAT，下一篇將講解如何搭建單擊版的CAT

---

參考了 江湖再見994 的CSDN 博客 ，全文地址請點擊：
https://blog.csdn.net/tankun940507994/article/details/56672385?utm_source=copy

總結

以上是生活随笔為你收集整理的CAT概述的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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