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

自2014年开源以来，Github 收获 7700+ Star，2800+ Forks，被 100+ 公司企业使用，其中不乏携程、陆金所、猎聘网、平安等业内知 名公司。在每一年全球 QCon 大会、全球架构与运维技术峰会等都有持续的技术输出，受到行业内承认，愈来愈多的企业伙伴加入了 CAT 的开 源建设工做，为 CAT 的成⻓贡献了巨大的力量。

项目的开源地址是 http://github.com/dianping/cat。

本文会对CAT总体设计、客户端、服务端等的一些设计思路作详细深刻的介绍。

背景介绍

CAT整个产品研发是从2011年末开始的，当时正是大众点评从.NET迁移到Java的核心起步阶段。当初大众点评已经有核心的基础中间件、RPC组件Pigeon、统一配置组件Lion。总体Java迁移已经在服务化的路上。随着服务化的深刻，总体Java在线上部署规模逐渐变多，同时，暴露的问题也愈来愈多。典型的问题有：

  • 大量报错，特别是核心服务，须要花好久时间才能定位。
  • 异常日志都须要线上权限登录线上机器排查，排错时间长。
  • 有些简单的错误定位都很是困难（一次将线上的库配置到了Beta，花了整个通宵排错）。
  • 不少不了了之的问题怀疑是网络问题（从如今看，内网真的不多出问题）。

虽然那时候也有一些简单的监控工具（好比Zabbix，本身研发的Hawk系统等），可能单个工具在某方面的功能还不错，但总体服务化水平良莠不齐、扩展能力相对较弱，监控工具间不能互通互联，使得查找问题根源基本都须要在多个系统之间切换，有时候真的是靠“人品”才能找出根源。

适逢在eBay工做长达十几年的吴其敏加入大众点评成为首席架构师，他对eBay内部应用很是成功的CAL系统有深入的理解。就在这样天时地利人和的状况下，咱们开始研发了大众点评第一代监控系统——CAT。

CAT的原型和理念来源于eBay的CAL系统，最初是吴其敏在大众点评工做期间设计开发的。他以前曾CAT不只加强了CAL系统核心模型，还添加了更丰富的报表。

总体设计

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

  • 实时处理：信息的价值会随时间锐减，尤为是事故处理过程当中。
  • 全量数据：最开始的设计目标就是全量采集，全量的好处有不少。
  • 高可用：全部应用都倒下了，须要监控还站着，并告诉工程师发生了什么，作到故障还原和问题定位。
  • 故障容忍：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序列化协议是自定义序列化协议，自定义序列化协议相比通用序列化协议要高效不少，这个在大规模数据实时处理场景下仍是很是有必要的。
  • CAT通讯是基于Netty来实现的NIO的数据传输，Netty是一个很是好的NIO开发框架，在这边就不详细介绍了。

客户端埋点

日志埋点是监控活动的最重要环节之一，日志质量决定着监控质量和效率。当前CAT的埋点目标是以问题为中心，像程序抛出exception就是典型问题。我我的对问题的定义是：不符合预期的就能够算问题，好比请求未完成、响应时间快了慢了、请求TPS多了少了、时间分布不均匀等等。

在互联网环境中，最突出的问题场景，突出的理解是：跨越边界的行为。包括但不限于：

  • HTTP/REST、RPC/SOA、MQ、Job、Cache、DAL;
  • 搜索/查询引擎、业务应用、外包系统、遗留系统;
  • 第三方网关/银行, 合做伙伴/供应商之间；
  • 各种业务指标，如用户登陆、订单数、支付状态、销售额。

遇到的问题

一般Java客户端在业务上使用容易出问题的地方就是内存，另一个是CPU。内存每每是内存泄露，占用内存较多致使业务方GC压力增大； CPU开销最终就是看代码的性能。

之前咱们遇到过一个极端的例子，咱们一个业务请求作餐饮加商铺的销售额，业务通常会经过for循环全部商铺的分店，结果就形成内存OOM了，后来发现这家店是肯德基，有几万分店，每一个循环里面都会有数据库链接。在正常场景下，ThreadLocal内部的监控一个对象就存在几万个节点，致使业务Oldgc特别严重。因此说框架的代码是不能想象业务方会怎么用你的代码，须要考虑到任何状况下都有出问题的可能。

在消耗CPU方面咱们也遇到一个case：在某个客户端版本，CAT本地存储当前消息ID自增的大小，客户端使用了MappedByteBuffer这个类，这个类是一个文件内存映射，测试下来这个类的性能很是高，咱们仅仅用这个存储了几个字节的对象，正常状况理论上不会有任何问题。在一次线上场景下，不少业务线程都block在这个上面，结果发现当自己这台机器IO存在瓶颈时候，这个也会变得很慢。后来的优化就是把这个IO的操做异步化，因此客户端须要尽量异步化，异步化序列化、异步化传输、异步化任何可能存在时间延迟的代码操做。

服务端设计

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

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

架构设计

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

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

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

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

实时分析

CAT服务端实时报表分析是整个监控系统的核心，CAT重客户端采集的是是原始的logview，目前一天大约有1000亿的消息，这些原始的消息太多了，因此须要在这些消息基础上实现丰富报表，来支持业务问题及性能分析的须要。

CAT是根据日志消息的特色(好比只读特性)和问题场景，量身定作的，它将全部的报表按消息的建立时间，一小时为单位分片，那么每小时就产生一个报表。当前小时报表的全部计算都是基于内存的，用户每次请求即时报表获得的都是最新的实时结果。对于历史报表，由于它是不变的，因此实时不实时也就无所谓了。

CAT基本上全部的报表模型均可以增量计算，它能够分为：计数、计时和关系处理三种。计数又能够分为两类：算术计数和集合计数。典型的算术计数如：总个数（count）、总和（sum）、均值（avg）、最大/最小（max/min)、吞吐（tps）和标准差（std）等，其余都比较直观，标准差稍微复杂一点，你们本身能够推演一下怎么作增量计算。那集合运算，好比95线（表示95%请求的完成时间）、999线（表示99.9%请求的完成时间），则稍微复杂一些，系统开销也更大一点。

报表建模

CAT每一个报表每每有多个维度，以transaction报表为例，它有5个维度，分别是应用、机器、Type、Name和分钟级分布状况。若是全维度建模，虽然灵活，但开销将会很是之大。CAT选择固定维度建模，能够理解成将这5个维度组织成深度为5的树，访问时老是从根开始，逐层往下进行。

CAT服务端为每一个报表单独分配一个线程，因此不会有锁的问题，全部报表模型都是非线程安全的，其数据是可变的。这样带来的好处是简单且低开销。

CAT报表建模是使用自研的Maven Plugin自动生成的。全部报表是可合并和裁剪的，能够轻易地将2个或多个报表合并成一个报表。在报表处理代码中，CAT大量使用访问者模式（visitor pattern）。

性能分析报表

故障发现报表

  • 实时业务指标监控 ：核心业务都会定义本身的业务指标，这不须要太多，主要用于24小时值班监控，实时发现业务指标问题，图中一个是当前的实际值，一个是基准值，就是根据历史趋势计算的预测值。以下图就是当时的情景，能直观看到支付业务出问题的故障。

  • 系统报错大盘。
  • 实时数据库大盘、服务大盘、缓存大盘等。

存储设计

CAT系统的存储主要有两块：

  • CAT的报表的存储。
  • CAT原始logview的存储。

报表是根据logview实时运算出来的给业务分析用的报表，默认报表有小时模式、天模式、周模式以及月模式。CAT实时处理报表都是产生小时级别统计，小时级报表中会带有最低分钟级别粒度的统计。天、周、月等报表都是在小时级别报表合并的结果报表。

原始logview存储一天大约100TB的数据量，由于数据量比较大因此存储必需要要压缩，自己原始logview须要根据Message-ID读取，因此存储总体要求就是批量压缩以及随机读。在当时场景下，并无特别合适成熟的系统以支持这样的特性，因此咱们开发了一种基于文件的存储以支持CAT的场景，在存储上一直是最难的问题，咱们一直在这块持续的改进和优化。

消息ID的设计

CAT每一个消息都有一个惟一的ID，这个ID在客户端生成，后续都经过这个ID在进行消息内容的查找。典型的RPC消息串起来的问题，好比A调用B的时候，在A这端生成一个Message-ID，在A调用B的过程当中，将Message-ID做为调用传递到B端，在B执行过程当中，B用context传递的Message-ID做为当前监控消息的Message-ID。

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

  • 第一段是应用名shop-web。
  • 第二段是当前这台机器的IP的16进制格式，0a01010680表示10.1.6.108。
  • 第三段的375030，是系统当前时间除以小时获得的整点数。
  • 第四段的2，是表示当前这个客户端在当前小时的顺序递增号。

存储数据的设计

消息存储是CAT最有挑战的部分。关键问题是消息数量多且大，目前美团天天处理消息1000亿左右，大小大约100TB，单物理机高峰期每秒要处理100MB左右的流量。CAT服务端基于此流量作实时计算，还须要将这些数据压缩后写入磁盘。

总体存储结构以下图：

CAT在写数据一份是Index文件，一份是Data文件.

  • Data文件是分段GZIP压缩，每一个分段大小小于64K，这样能够用16bits能够表示一个最大分段地址。
  • 一个Message-ID都用须要48bits的大小来存索引，索引根据Message-ID的第四段来肯定索引的位置，好比消息Message-ID为ShopWeb-0a010680-375030-2，这条消息ID对应的索引位置为2*48bits的位置。
  • 48bits前面32bits存数据文件的块偏移地址，后面16bits存数据文件解压以后的块内地址偏移。
  • CAT读取消息的时候，首先根据Message-ID的前面三段肯定惟一的索引文件，在根据Message-ID第四段肯定此Message-ID索引位置，根据索引文件的48bits读取数据文件的内容，而后将数据文件进行GZIP解压，在根据块内偏移地址读取出真正的消息内容。

服务端设计总结

CAT在分布式实时方面，主要归结于如下几点因素：

  • 去中心化，数据分区处理。
  • 基于日志只读特性，以一个小时为时间窗口，实时报表基于内存建模和分析，历史报表经过聚合完成。
  • 基于内存队列，全面异步化、单线程化、无锁设计。
  • 全局消息ID，数据本地化生产，集中式存储。
  • 组件化、服务化理念。

总结

最后咱们再花一点点时间来说一下咱们在实践里作的一些东西。

1、MVP版本，Demo版本用了1个月，MVP版本用了3个月。

为何强调MVP版本？由于作这个项目须要老板和业务的支持。大概在2011年左右，咱们整个生产环境估计也有一千台机器（虚拟机），一旦出现问题就到运维那边看日志，看日志的痛苦你们都应该理解，这时候发现一台机器核心服务出错，可能会致使更多的问题。咱们就作了MVP版本解决这个问题，当时咱们大概作了两个功能：一个是实时知道全部的API接口访问量成功率等；第二是实时能在CAT平台上看到异常日志。这里我想说的是MVP版本不要作太多内容，可是在作一个产品的时候必须从MVP版本作起，要作一些最典型特别亮眼的功能让你们支持你。

2、数据质量。数据质量是整个监控体系里面很是关键，它决定你最后的监控报表质量。因此咱们要和跟数据库框架、缓存框架、RPC框架、Web框架等作深刻的集成，让业务方便收集以及看到这些数据。

3、单机开发环境，这也是咱们认为对整个项目开发效率提高最重要的一点。单机开发环境实际上就是说你在一台机器里能够把你全部的项目都启起来。若是你在一个单机环境下把全部东西启动起来，你就会千方百计地知道我依赖的服务挂了我怎么办？好比CAT依赖了HDFS。单机开发环境除了大幅度提升你的项目开发效率以外，还能提高你整个项目的可靠性。

4、最难的事情是项目上线推进。CAT整个项目大概有两三我的，当时白天都是支持业务上线，培训，晚上才能code，可是一旦随着产品和完善以及业务使用逐渐变多，一些好的产品后面会造成良性循环，推广就会变得比较容易。

5、开放生态。公司越大监控的需求越多，报表需求也更多，好比咱们美团，产品有不少报表，整个技术体系里面也有不少报表很是多的自定义报表，不少业务方都提各自的需求。最后咱们决定把整个CAT系统里面全部的数据都做为API暴露出去，这些需求并非不能支持，而是这事情根本是作不完的。美团内部下游有不少系统依赖CAT的数据，来作进一步的报表展现。

CAT项目从2011年开始作，到如今整个生产环境大概有三千应用，监控的服务端从零到几千，再到今天的两万多的规模，整个项目是从历时看起来是一个五年多的项目，但即便是作了五年多的这样一个项目，目前还有不少的需求须要开发。这边也打个广告，咱们团队急缺人，欢迎对监控系统研发有兴趣的同窗加入，请联系yong.you@dianping.com.