版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/cd18333612683/article/details/82926992
前言
最近，刚换了一家公司，第一个任务就是要在CAT的基础上做二次开发，老大让先看一个星期的源码，利用国庆假期，就好好的做一下总结。首先，这一篇博客就来聊一聊CAT到底是个什么鬼
思维导图+概述
下边是我总结的思维导图，分别从what？why？how？的角度进行说明
what是什么：
cat是由美团的尤勇和吴其敏主导设计，使用java开发打造的实时应用监控平台。
why为什么：它可以帮助我们解决什么问题？
- 线上发布了服务，怎么知道它一切正常，比如发布5台服务器，如何直观了解是否有请求进来，访问一切正常。
- 当年有一次将线上的库配置到了Beta，这么低级的错误，排错花了一个通宵，十几个人。
- 某个核心服务挂了，导致大量报错，如何确定到底是哪里出了问题。
- SOA带来的问题，调用XX服务出问题，很慢，是否可以衡量？
- 应用程序有性能瓶颈，如何提供一些有效工具发现？
- ……
Cat拥有什么样的能力，可以解决上述问题？
• 实时处理：信息的价值会随时间锐减，尤其是事故处理过程中。
• 全量数据：最开始的设计目标就是全量采集，全量的好处有很多。
• 高可用：所有应用都倒下了，需要监控还站着，并告诉工程师发生了什么，做到故障还原和问题定位。
• 故障容忍：CAT本身故障不应该影响业务正常运转，CAT挂了，应用不该受影响，只是监控能力暂时减弱。
• 高吞吐：要想还原真相，需要全方位地监控和度量，必须要有超强的处理吞吐能力。
• 可扩展：支持分布式、跨IDC部署，横向扩展的监控系统。
• 不保证可靠：允许消息丢失，这是一个很重要的trade-off，目前CAT服务端可以做到4个9的可靠性，可靠系统和不可靠性系统的设计差别非常大。
how怎么实现:
- 收集阶段：负责业务应用日志的埋点和采集。CAT目前提供多种语言的客户端供业务应用程序调用，埋点结果以消息树的形式存入传输队列。如果队列满，则会自动丢弃当前消息。
- 传输阶段：CAT客户端负责将客户端消息传输到后端，CAT消费机负责接收消息。传输前CAT客户端会与CAT消费机建立TCP长连接，不断地从客户端队列中取出消息树，序列化后写入网络；CAT消费机则不断地从网络中取出数据，反序列化后放入消费队列。
- 分析阶段：负责报表生成。实时消费调度器会将消费队列消息取出，分发给每个消费者内部队列；报表分析器只会从自己的报表队列中取出消息树，逐个消费，更新报表模型。CAT以小时为单位形成报表，原始日志转储(raw log dump)是一个特殊的分析器，它不生产报表，而是将消息存入本地文件系统。
- 存储阶段：负责报表和原始日志的存储，目前报表会存在MySQL中，原始日志压缩后存在HDFS中长久保存。保留时长取决于存储容量的大小，一般报表会保存3个月以上，原始日志保存一个月。
- 展示阶段：负责数据的可视化。作为用户服务入口，负责报表和原始日志的输出显示。对于实时报表请求，会向各个消费机分发请求，并将结果聚合后输出HTML，在浏览器展示；历史报表会直接取自数据库。XML数据输出是另一种内置的数据展示方式，方便基于CAT开放外围工具。
- 告警阶段：可以进行阈值配置，如果超过一定阈值会根据告警策略的配置进行不同方式的告警（短信、微信、邮件）
总结
今天只是简单的概述一下CAT，下一篇将讲解如何搭建单击版的CAT
参考了 江湖再见994 的CSDN 博客 ，全文地址请点击：
https://blog.csdn.net/tankun940507994/article/details/56672385?utm_source=copy