CAT总体介绍
CAT(Central Application Tracking)是由吴其敏（前大众点评首席架构师，现携程架构负责人）主导设计基于Java开发打造的实时应用监控平台，为大众点评网提供了全面的监控服务和决策支持。
CAT作为大众点评网基础监控组件，它已经在中间件框架（MVC框架，RPC框架，数据库框架，缓存框架等）中得到广泛应用，为点评各业务线提供系统的性能指标、健康状况、基础告警等。
CAT解决什么问题？
- 线上发布了服务，怎么知道它一切正常，比如发布5台服务器，如何直观了解是否有请求进来，访问一切正常。
- 当年有一次将线上的库配置到了Beta，这么低级的错误，排错花了一个通宵，十几个人。
- 某个核心服务挂了，导致大量报错，如何确定到底是哪里出了问题。
- SOA带来的问题，调用XX服务出问题，很慢，是否可以衡量？
- 应用程序有性能瓶颈，如何提供一些有效工具发现？
- …...
15台CAT物理监控集群
单台机器15w qps
2000+ 业务应用（包括部分.net以及Job）
7000+ 应用服务器
50TB 消息，~450亿消息（每天）
项目地址：https://github.com/dianping/cat
CAT作者就CAT应用开发答疑解惑
第一个重点是埋点工作
-
Transaction埋点，主要记录一些跨项目，跨模块一些调用。最主要有三个，远程服务，数据库以及缓存。点评是在中间件上做的埋点，比如PRC框架，数据访问层框架，缓存框架，然后在业务线全部升级框架。
-
Event埋点，主要记录事件以及异常。最常见的场景就是当埋Transaction时候，需要event作为补充，比如记录当时访问参数等。代码一些特殊诡异路径的分析，还有异常信息记录。
-
Metric埋点，主要用于记录了一些实际的业务指标，用于运维监控。Heartbeat不需要业务埋点。
-
当业务需要监控自己一段代码访问行为，他可以自己使用API，常见有访问第三方服务等等，一些比较复杂的逻辑算法等。当业务用好之后发现能解决问题之后，基本用了就停不下来，有的team第三方购买的系统，都会加入cat埋点，因为遇到过第三方系统性能问题没办法分析。
-
监控系统需要做成开放式系统，每个核心的report最好能提供api，让其他程序能够访问，每个业务的想看的一些指标展示各不相同，监控是无法完成业务定制化report需求，所以需要每个报表都能api，把自己做成一个数据平台。目前有不少项目是自己写程序爬CAT数据，作为自己整个项目的周报，技术指标。还有一些用来推动业务进行技术优化的业务线横向报表原始数据都来自CAT。
-
CAT不仅仅在生产环境做了部署，在线下以及性能环境也做了部署，qa做压力测试、功能测试都会去看cat上面的数据，相比于以前测试，可以大量节省他们的时间，跑一次自动化case回归，看看CAT上面的报错，响应时间，访问量，大概就知道程序是否存在问题。
- 在实际推广过程中，培训很重要，并不是所有人都能很清楚知道和接受CAT怎么用，相对资深同事更加容易接受。很多其他的公司部署了CAT，就是因为有好几个同事都是从点评离职过去，部署起来的。
-
先做小做精，再做大做全
-
持续集成，持续发布，不断监控
-
单机开发和调试
-
Everything Fails
-
关注客户，快速响应
- 站在巨人的肩膀上
Q1：监控系统数据采集的频率如何把控？
CAT是全量数据采集，心跳数据是1分钟一次。如果服务器或者硬件监控，一般几秒一次。如果是特别重要的，可以一秒一次。
Q2：监控项一般都有哪些？
比较通用的监控项，也就是核心框架里面监控项目，比如远程访问，数据库访问，缓存访问的响应时间，访问量等。
心跳里面的监控项有
-
系统内存、swap、load
-
GC信息，GC时间以及数量，Java内存状态
- 核心的一些线程数，比如http，一些RPC框架线程等
建议报表系统还是自己做比较合适，报表这类需求定制太多了，比如按照部门、产品线等统计。
Q4: 跟其他开源监控方案对比如何？
开源的监控系统，比如zabbix，nagios，cacit算是很成熟的一套监控系统，他们能通过脚本或者snmp协议等收集很多服务端的性能数据，并配置很多监控规则来发现服务器等一些问题。点评这些也在用，主要是zabbix，他和CAT互相补充。
之前小米开源的系统应该也是基于指标的画图以及告警，和CAT应该是两类不同的系统。
Q5: 能不能举例说明一下服务监控和App监控的具体做法,有没有最佳实践？
服务端监控，就应该类似于我上面讲的CAT在服务端监控一些做法，不仅仅包括问题发现，还包括了性能调优，路径分析等等，这样才能把帮助业务分析并找到问题。
App监控，由于时间问题，今天没有讲到，这里说几个点吧。App监控点评做了三个部分：
-
返回码系统（多维度下，API、城市、运营商、网络、APP版本等）
-
实时Crash日志（版本、平台、模块等维度）
- 测速系统（打开一个APP某个页面的分段速度测试，一个页面可能包括广告，导航、图片等，每个阶段的速度测试）
Dubbo是阿里的一套PRC开源框架，目前我们没有集成的case，CAT和点评PRC组件集成得很好，坚信应该不是问题。
Q7: Cat是否适合创业公司用？希望不要太重。
-
创业公司可以根据自己实际需要，以及对于CAT的理解做出的一个评估。我理解的监控，是承接了公司整个开发流程上闭环的一个重要角色。监控能帮助应用发现问题，分析问题，找到问题，然后在快速进行迭代。如果要我说，我觉得应该是适合的。
- 重和不重，这点我不太好说，埋点的深度决定了监控的高度，可以轻量级使用，也可以重度使用。服务端对于创业公司来说应该很轻量，只需要MySQL即可，只要本地磁盘足够OK，HDFS都可以不需要。
个人觉得运维成本不大，主要是使用以及依赖组件很少，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：传输数据是什么格式？有压缩吗？
-
数据传输格式为普通文本，自己实现的序列化和反序列化，目前没有做压缩，压缩需要考虑到客户端和服务端的cpu压力。
- 服务端存储数据是有压缩的，压缩比例大概为8:1
-
对于应用的服务基本影响很小，在做极端的压力测试下，加上CAT以及不加入CAT，峰值qps影响在10%以内，均值基本不变。
-
CAT客户端和服务端的通信都是异步的，当服务全部宕机，客户端丢失消息即可。
上下游调用，主要用到全局统一项目名，这是点评一套架构上的规范，可以理解为环境信息。RPC能在当前的运行环境下知道自己当前的项目名以及调用者的项目名。
Q15：是否有多语言client支持？
支持JAVA和 .Net。
Q16：CAT自身的健康状态监测？
当一个客户端不 work，client 会自动连接上 next server，所以有一个管理连接的线程，保持一个活动有效的连接，如果 server 全部挂了，消息就丢弃了。
Q17：如何检测到丢失的消息数？
所有的消息都是基于消息队列处理，如果队列满了，会有记录。
Q18：CAT有做字节码插桩么？
没有。
Q19: 对JVM的监控，是通过jstat脚本来收集数据的吗？数据是客户端上报，还是服务端拉取，数据格式也是logview？
不是通过脚本，具体的收集可以参考源码 StatusInfoCollector，主要用到 MemoryMXBean， MemoryPoolMXBean等。
数据上报的格式也是logview，是客户端主动一分钟上报一次。
Q20: 客户端上报数据的话，服务端可以不用高可用吧？
服务端尽量做到高可用吧。
Q21：手机客户端的监控是怎么做的，直接发到CAT还是业务系统转发呢？
手机监控其实是另外一套系统，最后展示层在CAT。
Q20：我们在用Nagios做系统和服务的监控，但对服务调用链的监控，基本上是空白。不知能不能有机会听一下中间件层面的服务调用是怎么监控的。
服务端会分析上报logview，埋点信息会有客户端和服务端的项目名信息，后端可以用此数据进行实时分析。
Q21: 这种数据用TCP长连接汇报的么？为什么没考虑使用UDP?是为了可靠性么？还是其他考量？
UDP在线下测试很不稳定，经常丢弃什么，TCP的比UDP多的开销其实对业务影响很小。
CAT系统最初的设计者吴其敏补充说： 如果系统的消息丢失率达到一定的比例，那么它的的可信度就会降低，所以保证足够多的消息能够被好好处理是很重要的。CAT设计成不可靠系统，但实际上我们希望系统足够可靠，只是不愿为承诺可靠而付出高额代价。 以前研究过Dapper，觉得它的机制与CAT相差很远，监控的全面性不够。当然如果到了Google的量级，情况就很不一样了。
TCP是有连接的，有拥塞控制；UDP无连接，一般情况下内网成功率还是挺高的，极端情况下将非常糟糕。
