大众点评php年夜众点评CAT

CAT（Central Application Tracking），是基于纯Java开拓的分布式实时监控系统。
开源代码托管在GitHub（搜索CAT即可），作者是吴其敏（qmwu2000，目前在安然任职）和尤勇（youyong205 目前在点评运维部）。

产品干系分享在网上可以找到：

看大众点评如何通过实时监控系统CAT打造724做事-尤勇@QCon高可用架构群 2015

大众点评php年夜众点评CAT AJAX

分布式监控系统的设计与实现-尤勇@QCon上海2015

大众点评网监控系统架构阐发-尤勇@2013第二届华东架构师大会

大众点评网监控平台阐发-吴其敏@QCon杭州2012

CAT现状

CAT采取非常开放的Apache License开源，在海内已经有100多家互联网公司在利用和评估，包括大众点评网、携程网、猎聘网、陆金所和找钢网等。
截至2016年3月，CAT已经得到了1000多个stars。

设计目标

可扩展：支持分布式、跨IDC支配，横向扩展。

高可用：所有运用都可以倒下了，须要监控还站着，见告它们发生了什么。

实时处理：信息的代价会随韶光锐减，尤其是事件处理过程中。

全量数据：小概率事宜是常态，百万分之一的概率，碰到了便是100%。

高吞吐：要想还底本相，须要全方位的监控和度量，必须要有超强的处理吞吐能力。

故障容忍：CAT本身故障不应该影响业务正常运转，CAT挂了，运用不该受影响，只是监控能力暂时减弱。

不担保可靠：许可丢失，这是一个很主要的trade-off，虽然目前CAT可以做到4个9的可靠性。

CAT架构

架构追求大略、去中央化、分工协作，两层构造，除了依赖外部存储如HDFS和MySQL外，不依赖其他系统，CAT内部全面采取组件化设计和实现。
CAT每天量巨大，一台机器是不能处理全部流量，必须分片处理，均衡负载。

业务运用目前利用CAT API进行埋点，后台异步线程采取TCP长连接办法，将源源不断地传输到后台做事器；CAT具有fail-over机制，在后台做事器不可用时会自动切换到另一台可用做事器。
CAT目前利用native协议做序列化和反序列化，将来会考虑支持更多协议，比如thrift。

被送到后台，经反序列化后会被放入行列步队，实时消费调度器会将分发到所有消费者内部队列，每个消费者只需处理自己的消费行列步队，各消费者之间彼此相对独立，如果消费速率太慢，导致消费行列步队满，则新来的会被丢弃。
范例消费者都采取实时增量打算的办法，流式处理，产生的报表会在当前小时结束后保存到中心数据库中。

日报表采取后台作业的形式，由24个小时报表合并得到。
周报表则由7个日报表合并得到，以此类推。

CAT掌握台，即UI层，卖力吸收用户要求，从后台存储中将报表信息取出显示。
对付实时报表，直接通过HTTP要求分发到相应消费机，待结果返回后聚合展示；历史报表则直接取数据库并展示。

所有原始会先存储在本地文件系统，然后上传到HDFS中保存；而对付报表，因其远比原始日志小，则以K/V的办法保存在MySQL中。

处理

处理分五个阶段：网络、传输、剖析、存储和展示。

网络阶段：卖力业务运用日志的埋点和采集。
CAT目前供应多种措辞的客户端供业务运用程序调用，埋点结果以树的形式存入传输行列步队。
如果行列步队满，则会自动丢弃当前。

传输阶段：CAT客户端卖力将客户端传输到后端，CAT消费机卖力吸收。
传输前CAT客户端会与CAT消费机建立TCP长连接，不断地从客户端行列步队中取出树，序列化后写入网络；CAT消费机则不断地从网络中取出数据，反序列化后放入消费行列步队。

剖析阶段：卖力报表天生。
实时消费调度器会将消费行列步队取出，分发给每个消费者内部队列；报表剖析器只会从自己的报表行列步队中取出树，逐个消费，更新报表模型。
CAT以小时为单位形成报表，原始日志转储(raw log dump)是一个分外的剖析器，它不生产报表，而是将存入本地文件系统。

存储阶段：卖力报表和原始日志的存储，目前报表会存在MySQL中，原始日志压缩后存在HDFS中长久保存。
保留时长取决于存储容量的大小，一样平常报表会保存3个月以上，原始日志保存一个月。

展示阶段：卖力数据的可视化。
作为用户做事入口，卖力报表和原始日志的输出显示。
对付实时报表要求，会向各个消费机分发要求，并将结果聚合后输出HTML，在浏览器展示；历史报表会直接取自数据库。
XML数据输出是另一种内置的数据展示办法，方便基于CAT开放外围工具。

日志埋点

日志埋点是监控活动的最主要环节之一，日志质量决定着监控质量和效率。
当前CAT的埋点目标因此问题为中央，像程序抛出exception便是范例问题。
我个人对问题的定义是：不符合预期的就可以算问题。
比如要求未完成，相应韶光快了慢了，要求TPS多了少了，韶光分布不屈均等等。

在互联网环境中，最突出的问题场景，我的理解是，超过边界的行为。
包括但不限于，HTTP/REST、RPC/SOA、MQ、Job、Cache、DAL; 搜索/查询引擎、业务运用、外包系统、遗留系统; 母/子公司, 第三方网关/银行, 互助伙伴/供应商之间；还有各种业务指标，如PV、用户登录、订单数、支付状态、发卖额。

CAT供应API支持的措辞有：Java，.NET，将来打算支持C/C++、NodeJS、Go、PHP、Python等。

领域建模

此模型可以覆盖大部分业务运用的日常埋点需求。
各种类型都有个性化剖析和展示。

树

CAT树如实记录真实用户要求的处理时序，这些要求可能被分布在多台机器上。
树可以丰富地表达嵌套关系、先后次序和并行处理，这将有助于开拓者清楚的理解用户要求到底是怎么被一步步实行的，尤其在追踪一些疑难杂症时，这会特殊有用。

只要遵照CAT埋点规范，CAT会自动地将多台机器上的树串起来，可以逐层展示。

当然也有另一种更适宜于人的视图，方便识别突出问题，毕竟人对图形识别更加善于。

CAT API

API力求精简，将来还有进一步优化空间。
大部分CAT埋点该当在底层根本架构中完成，一样平常运用层不须要做大多埋点。
有些产品利用如java-agent等办法埋点，CAT埋点也可以采取，埋点质量取决于现有运用代码的规范程度和覆盖范围。

实时剖析

CAT的实时性不是用户要看什么，CAT就实时打算出结果，呈现给用户；而是根据日志的特点(比如只读特性)和问题场景，量身定做的。
CAT将所有的报表按的创建韶光，一小时为单位分片，那么每小时就产生一个报表。
当前小时报表的所有打算都是基于内存的，用户每次要求即时报表得到的都是最新结果，给人一种“实时”的觉得。
对付历史报表，由于它是不变的，以是就实时不实时也就无所谓了。

对付内存增量打算，它可以分为：计数、计时和关系处理三种。
计数又可以分为两类：算术计数和凑集计数。
范例的算术计数如：总个数（count），总和（sum），均值（avg），最大/最小（max/min)，吞吐（tps）和标准差（std）等，其他都比较直不雅观，标准差轻微繁芜一点，大家自己可以推演一下怎么做增量打算。
那凑集运算，比如95线（表示95%要求的完成韶光），999线（表示99.9%要求的完成韶光），DAU（日活用户数）等，则轻微繁芜一些，系统开销也更大一点。
关系处理则涉及图的运算，这里不细述。

报表建模

理解增量打算很主要，但终极须要落实到各个不同的报表上。
一个报表每每有多个维度，以transaction报表为例，它有5个维度，分别是运用、机器、大类、小类和分布情形。
如果全维度建模，虽然灵巧，但开销将会非常之大。
CAT选择固定维度建模，可以理解成将这5个维度组织成深度为5的树，访问时总是从根开始，逐层往下进行。

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

报表代码是利用自研的maven plugin自动天生的。
所有报表是可合并和裁剪的，可以轻易地将2个或多个报表合并成一个报表。
在报表处理代码中，CAT大量利用访问者模式（visitor pattern）。

存储

存储是CAT最有寻衅的部分。
关键问题是数量多且大，像大众点评和携程每天数在300-400亿旁边，大小有50TB，也便是说每秒数在50-60万高下，每秒大小在1GB旁边。
如果分10台机器处理，则每天每秒须要处理5-6万，100MB大小。
如果网站流量来点颠簸的话，寻衅就更大了。
由于韶光关系，这部分本日就不细述了（感兴趣的同学，欢迎加群与吴老师一对一互换）。

总结

CAT在分布式实时方面，紧张归结于以下几点成分：

去中央化，数据分区处理；

基于日志只读特性，以一个小时为韶光窗口，实时报表基于内存建模和剖析，历史报表通过聚合完成；

基于内存行列步队，全面异步化，单线程化，无锁设计；

全局ID，数据本地化生产，集中式存储；

组件化、做事化理念，致力于工具间互通互联。

高朋先容

吴其敏，互联网老兵，软件工匠，开源爱好者，一贯深入代码一线，打仗java近20年。
现在携程网卖力框架研发，曾任大众点评网首席架构师、任eBay&易趣资深架构师等。
关注分布式系统框架、组件化系统开拓，高质量数据建模和代码天生等。

互动问答

问题：业界类似办理方案，以及与CAT的异同？

业界有很多开源监控系统，但大多是基于日志行的（如ELK），CAT是基于日志树的。
个中最紧张的差异是监控源数据的质量。