简介

CAT（Central Application Tracking）是一个实时和接近全量的监控系统，它侧重于对Java应用的监控，基本接入了美团上海侧所有核心应用。目前在中间件（MVC、RPC、数据库、缓存等）框架中得到广泛应用，为美团各业务线提供系统的性能指标、健康状况、监控告警等。

• CAT 是基于 Java 开发的实时应用监控平台，为美团点评提供了全面的实时监控告警服务。
• CAT 作为服务端项目基础组件，提供了 Java, C/C++, Node.js, Python, Go 等多语言客户端，已经在美团点评的基础架构中间件框架（MVC框架，RPC框架，数据库框架，缓存框架等，消息队列，配置系统等）深度集成，为美团点评各业务线提供系统丰富的性能指标、健康状况、实时告警等。
• CAT 很大的优势是它是一个实时系统，CAT 大部分系统是分钟级统计，但是从数据生成到服务端处理结束是秒级别，秒级定义是48分钟40秒，基本上看到48分钟38秒数据，整体报表的统计粒度是分钟级；第二个优势，监控数据是全量统计，客户端预计算；链路数据是采样计算。

Cat 产品价值

• 减少故障发现时间
• 降低故障定位成本
• 辅助应用程序优化

Cat 优势

• 实时处理：信息的价值会随时间锐减，尤其是事故处理过程中
• 全量数据：全量采集指标数据，便于深度分析故障案例
• 高可用：故障的还原与问题定位，需要高可用监控来支撑
• 故障容忍：故障不影响业务正常运转、对业务透明
• 高吞吐：海量监控数据的收集，需要高吞吐能力做保证
• 可扩展：支持分布式、跨 IDC 部署，横向扩展的监控系统

整体设计

监控整体要求就是快速发现故障、快速定位故障以及辅助进行程序性能优化。为了做到这些，我们对监控系统的一些非功能做了如下的要求：

• 实时处理：信息的价值会随时间锐减，尤其是事故处理过程中。
• 全量数据：最开始的设计目标就是全量采集，全量的好处有很多。
• 高可用：所有应用都倒下了，需要监控还站着，并告诉工程师发生了什么，做到故障还原和问题定位。
• 故障容忍：CAT本身故障不应该影响业务正常运转，CAT挂了，应用不该受影响，只是监控能力暂时减弱。
• 高吞吐：要想还原真相，需要全方位地监控和度量，必须要有超强的处理吞吐能力。
• 可扩展：支持分布式、跨IDC部署，横向扩展的监控系统。
• 不保证可靠：允许消息丢失，这是一个很重要的trade-off，目前CAT服务端可以做到4个9的可靠性，可靠系统和不可靠性系统的设计差别非常大。

CAT从开发至今，一直秉承着简单的架构就是最好的架构原则，主要分为三个模块：CAT-client、CAT-consumer、CAT-home。

• Cat-client 提供给业务以及中间层埋点的底层SDK。
• Cat-consumer 用于实时分析从客户端提供的数据。
• Cat-home 作为用户给用户提供展示的控制端。

在实际开发和部署中，Cat-consumer和Cat-home是部署在一个JVM内部，每个CAT服务端都可以作为consumer也可以作为home，这样既能减少整个层级结构，也可以增加系统稳定性。

上图是CAT目前多机房的整体结构图，图中可见：

• 路由中心是根据应用所在机房信息来决定客户端上报的CAT服务端地址，目前美团有广州、北京、上海三地机房。
• 每个机房内部都有独立的原始信息存储集群HDFS。
• CAT-home可以部署在一个机房也可以部署在多个机房，在最后做展示的时候，home会从consumer中进行跨机房的调用，将所有的数据合并展示给用户。
• 实际过程中，consumer、home以及路由中心都是部署在一起的，每个服务端节点都可以充当任何一个角色。

客户端设计

客户端设计是CAT系统设计中最为核心的一个环节，客户端要求是做到API简单、高可靠性能，无论在任何场景下都不能影响客业务性能，监控只是公司核心业务流程一个旁路环节。CAT核心客户端是Java，也支持Net客户端，近期公司内部也在研发其他多语言客户端。以下客户端设计及细节均以Java客户端为模板。

设计架构

CAT客户端在收集端数据方面使用ThreadLocal（线程局部变量），是线程本地变量，也可以称之为线程本地存储。其实ThreadLocal的功用非常简单，就是为每一个使用该变量的线程都提供一个变量值的副本，属于Java中一种较为特殊的线程绑定机制，每一个线程都可以独立地改变自己的副本，不会和其它线程的副本冲突。

在监控场景下，为用户提供服务都是Web容器，比如tomcat或者Jetty，后端的RPC服务端比如Dubbo或者Pigeon，也都是基于线程池来实现的。业务方在处理业务逻辑时基本都是在一个线程内部调用后端服务、数据库、缓存等，将这些数据拿回来再进行业务逻辑封装，最后将结果展示给用户。所以将所有的监控请求作为一个监控上下文存入线程变量就非常合适。

如上图所示，业务执行业务逻辑的时候，就会把此次请求对应的监控存放于线程上下文中，存于上下文的其实是一个监控树的结构。在最后业务线程执行结束时，将监控对象存入一个异步内存队列中，CAT有个消费线程将队列内的数据异步发送到服务端。

API设计

监控API定义往往取决于对监控或者性能分析这个领域的理解，监控和性能分析所针对的场景有如下几种：

• 一段代码的执行时间，一段代码可以是URL执行耗时，也可以是SQL的执行耗时。
• 一段代码的执行次数，比如Java抛出异常记录次数，或者一段逻辑的执行次数。
• 定期执行某段代码，比如定期上报一些核心指标：JVM内存、GC等指标。
• 关键的业务监控指标，比如监控订单数、交易额、支付成功率等。

在上述领域模型的基础上，CAT设计自己核心的几个监控对象：Transaction、Event、Heartbeat、Metric。

一段监控API的代码示例如下：

服务端设计

服务端主要的问题是大数据的实时处理，目前后端CAT的计算集群大约35台物理机，存储集群大约35台物理机，每天处理了约100TB的数据量。线上单台机器高峰期大约是110MB/s，接近千兆网打满。

下面我重点讲下CAT服务端一些设计细节。

架构设计

在最初的整体介绍中已经画了架构图，这边介绍下单机的consumer中大概的结构如下：

如上图，CAT服务端在整个实时处理中，基本上实现了全异步化处理。

• 消息接受是基于Netty的NIO实现。
• 消息接受到服务端就存放内存队列，然后程序开启一个线程会消费这个消息做消息分发。
• 每个消息都会有一批线程并发消费各自队列的数据，以做到消息处理的隔离。
• 消息存储是先存入本地磁盘，然后异步上传到HDFS文件，这也避免了强依赖HDFS。

当某个报表处理器处理来不及时候，比如Transaction报表处理比较慢，可以通过配置支持开启多个Transaction处理线程，并发消费消息。