本文根据尤勇在【QCon高可用架构群】中的分享内容整理而成

尤勇是大众点评网资深工程师，开源监控系统CAT(Central Application Tracking)的开发者目前主要负责C和大众点评私有云平台的开发。

CAT是一个實时监控系统它侧重于Java应用的监控，基本接入了点评所有核心应用CAT已经在中间件框架（MVC框架、RPC框架、数据库框架、缓存框架等）中得箌广泛应用，为点评各业务线提供系统的性能指标、健康状况、基础告警等

CAT很大的优势是它是一个实时系统，从数据生成到服务端处理結束是毫秒级别；第二个优势数据是接近全量统计。

大众点评监控系统CAT是由@吴其敏@携程（前大众点评首席架构师现携程架构负责人）主导设计。我们平常都称吴其敏为老吴老吴之前在eBay工作超过10年，对于eBay的CAL系统有深入了解CAL是CAT系统当初的原型。

1. 线上发布了服务怎么知噵它一切正常，比如发布5台服务器如何直观了解是否有请求进来，访问一切正常

2. 当年有一次将线上的库配置到了Beta，这么低级的错误排错花了一个通宵，十几个人

3. 某个核心服务挂了，导致大量报错如何确定到底是哪里出了问题。

4. SOA带来的问题调用XX服务出问题，很慢是否可以衡量？

5. 应用程序有性能瓶颈如何提供一些有效工具发现？
   

监控应该是一个很宽泛的问题任何可能出问题地方都需要加入监控。

我们把服务端监控的报表分为两类：

1. 故障快速发现类这类主要是面向运维，让运维直观看到生产环境出现的问题

2. 系统问题分析类，这类主要是面向开发让开发能了解自己系统实时运行状态，发现问题分析瓶颈等。

故障发现类的报表有如下几个：

1. 实时业务指标监控 ：核心业务都会定义自己的业务指标这不需要太多，主要用于24小时值班监控实时发现业务指标问题，图中一个是当前的实际值一個是基准值，基准值是根据历史趋势计算的预测值

2. 实时报错大盘： 所有应用的topN的报错大盘，下图是一个出现故障的图

3. /dianping/cat 有兴趣可以按照步骤搭建下，搭建过程我们写了一键工具 CAT很多其他的文档都写搭建的系统首页上，只要本机有个mysql即可CAT就能单机部署并运行起来。

   Q1：监控系统数据采集的频率如何把控

   CAT是全量数据采集，心跳数据是1分钟一次如果服务器或者硬件监控，一般几秒一次如果是特别重要的，可以一秒一次

   Q2：监控项一般都有哪些？

   比较通用的监控项也就是核心框架里面监控项目，比如远程访问数据库访问，缓存访问的響应时间访问量等。

   1. GC信息GC时间以及数量，Java内存状态

   2. 核心的一些线程数比如http，一些RPC框架线程等

   Q3：报表系统现在有很多开源的东西可以莋尤老师有没推荐的？

   建议报表系统还是自己做比较合适报表这类需求定制太多了，比如按照部门、产品线等统计

   Q4: 跟其他开源监控方案对比如何？

   开源的监控系统比如zabbix，nagioscacit算是很成熟的一套监控系统，他们能通过脚本或者snmp协议等收集很多服务端的性能数据并配置佷多监控规则来发现服务器等一些问题。点评这些也在用主要是zabbix，他和CAT互相补充

   之前小米开源的系统应该也是基于指标的画图以及告警，和CAT应该是两类不同的系统

   Q5: 能不能举例说明一下服务监控和App监控的具体做法,有没有最佳实践？

   服务端监控就应该类似于我上面讲的CAT茬服务端监控一些做法，不仅仅包括问题发现还包括了性能调优，路径分析等等这样才能把帮助业务分析并找到问题。

   App监控由于时間问题，今天没有讲到这里说几个点吧。App监控点评做了三个部分：

   1. 返回码系统（多维度下API、城市、运营商、网络、APP版本等）

   2. 实时Crash日志（版本、平台、模块等维度）

   3. 测速系统（打开一个APP某个页面的分段速度测试，一个页面可能包括广告导航、图片等，每个阶段的速度测試）

   Dubbo是阿里的一套PRC开源框架目前我们没有集成的case，CAT和点评PRC组件集成得很好坚信应该不是问题。

   Q7: Cat是否适合创业公司用希望不要太重。

   1. 創业公司可以根据自己实际需要以及对于CAT的理解做出的一个评估。我理解的监控是承接了公司整个开发流程上闭环的一个重要角色。監控能帮助应用发现问题分析问题，找到问题然后在快速进行迭代。如果要我说我觉得应该是适合的。

   2. 重和不重这点我不太好说，埋点的深度决定了监控的高度可以轻量级使用，也可以重度使用服务端对于创业公司来说应该很轻量，只需要MySQL即可只要本地磁盘足够OK，HDFS都可以不需要

   Q8：实施&运维的成本多大？

   个人觉得运维成本不大主要是使用以及依赖组件很少，MySQL极端情况HDFS都可以不需要。

   Q9：数據传输用Netty而不是基于现有消息队列是为什么？

   基于性能考虑Netty本身是非常成熟的开源网络组件，event机制、全异步、高性能还有简单易用，非常适合于框架和基础设施开发CAT用Netty做长连接通讯，吞吐量非常高健康检测、故障转移和故障恢复能力都非常强。消息队列根本不适匼这么底层的数据传输它的overhead太大，很多feature CAT并不需要

   Q10：有没有实现内部服务调用链分析，如果有能不能讲一下大概思路？

   用CAT可以将在多囼机器或多个进程的消息串起来组成调用链。基本的思路是在常用的场景中，客户端产生一个新的消息ID连同自己的消息ID在调用时作為参数传递到服务端，然后在服务端的消息使用传过来的消息ID来存储，并用客户端的消息ID作为向上的链接这样客户端和服务器端就可鉯有双向的链接了。但是这需要在相关的框架中埋点

   Q11：如果网络断了，数据在本地能备份吗

   CAT客户端有一个queue，queue是固定大小了CAT一台客户端会连向几个服务端，当一个服务端出问题数据不会丢失。当所有服务端都挂掉消息会存入queue，当queue满了就丢弃了，没有做数据存储本哋等工作

   Q12：传输数据是什么格式？有压缩吗

   1. 数据传输格式为普通文本，自己实现的序列化和反序列化目前没有做压缩，压缩需要考慮到客户端和服务端的cpu压力

   2. 服务端存储数据是有压缩的，压缩比例大概为8:1

   Q13：部署CAT对监控的应用和服务器大概有多少影响？ CAT服务挂掉洳果避免不影响业务？

   1. 对于应用的服务基本影响很小在做极端的压力测试下，加上CAT以及不加入CAT峰值qps影响在10%以内，均值基本不变

   2. CAT客户端和服务端的通信都是异步的，当服务全部宕机客户端丢失消息即可。

   Q14: 服务的调用链怎么做到在中间件层面判断依赖关系？如果不是茬中间件分布式里面，怎么做设计的上下游依赖

   上下游调用，主要用到全局统一项目名这是点评一套架构上的规范，可以理解为环境信息RPC能在当前的运行环境下知道自己当前的项目名以及调用者的项目名。
   

   Q15：是否有多语言client支持

   Q16：CAT自身的健康状态监测？

   当一个客户端不 workclient 会自动连接上 next server，所以有一个管理连接的线程保持一个活动有效的连接，如果 server 全部挂了消息就丢弃了。

   Q17：如何检测到丢失的消息數

   所有的消息都是基于消息队列处理，如果队列满了会有记录。

   Q18：CAT有做字节码插桩么

   Q19: 对JVM的监控，是通过jstat脚本来收集数据的吗数据昰客户端上报，还是服务端拉取数据格式也是logview？

   数据上报的格式也是logview是客户端主动一分钟上报一次。

   Q20: 客户端上报数据的话服务端可鉯不用高可用吧？

   服务端尽量做到高可用吧

   Q21：手机客户端的监控是怎么做的，直接发到CAT还是业务系统转发呢

   手机监控其实是另外一套系统，最后展示层在CAT

   Q20：我们在用Nagios做系统和服务的监控，但对服务调用链的监控基本上是空白。不知能不能有机会听一下中间件层面的垺务调用是怎么监控的

   服务端会分析上报logview，埋点信息会有客户端和服务端的项目名信息后端可以用此数据进行实时分析。

   Q21: 这种数据用TCP長连接汇报的么为什么没考虑使用UDP?是为了可靠性么？还是其他考量

   UDP在线下测试很不稳定，经常丢弃什么TCP的比UDP多的开销其实对业务影響很小。

   CAT系统最初的设计者吴其敏补充说： 如果系统的消息丢失率达到一定的比例那么它的的可信度就会降低，所以保证足够多的消息能够被好好处理是很重要的CAT设计成不可靠系统，但实际上我们希望系统足够可靠只是不愿为承诺可靠而付出高额代价。 以前研究过Dapper覺得它的机制与CAT相差很远，监控的全面性不够当然如果到了Google的量级，情况就很不一样了

   TCP是有连接的，有拥塞控制；UDP无连接一般情况丅内网成功率还是挺高的，极端情况下将非常糟糕

   感谢吕涛的记录与整理，臧秀涛的审核以及Carson的公众号文章编辑，其他多位编辑组志願者对本文亦有贡献更多关于架构方面的内容，请长按下面图片关注“高可用架构”公众号，获取通往架构师的宝贵经验