本文概要:
1、CAT监控系统是什么。
2、CAT监控系统能做什么,能监控些什么。
下面有些截图是CAT 2.0版本的,但和3.0版本没什么区别的。
CAT(Central Application Tracking)是美团开源的基于Java开发的实时分布式应用监控平台,提供了全面的监控服务和业务决策支持。
CAT监控系统的定位:
cat本质上一个实时监控系统,主要体现在监控报表Transaction、event、problem、heartbeat等,cat系统定制的监控模型以及定制的实时分析报表也是cat系统核心优势。
logview是cat原始的log采集方式,cat的logview使用的技术是threadlocal,将一个thread里面的打点聚合上报,有一点弱化版本的链路功能,但是cat并不是一个标准的全链路系统,全链路系统参考dapper的论文,业内比较知名的鹰眼,zipkin等,其实经常拿cat和这类系统进行比较其实是不合适的。cat的logview在异步线程等等一些场景下,其实不合适,cat本身模型并不适合这个。在美团点评内部,有mtrace专门做全链路分析。
也就是说:CAT定义了一个基本的监控模型,可以用来实时监控,至于要监控些什么可以自己定义,比如要做分布式全链路跟踪监控,可以自己埋点获取监控信息;
怎么埋点也是有参考方案的,下篇博文将会介绍本人重新封装的客户端埋点SDK。
另外,CAT倾向于指标、链路事件监控,不太适用于大量业务日志的场景,因为无法搜索、分析,CAT只看看到最新的样本数据和出问题的数据。大量业务日志的场景应该用ELK。
github:https://github.com/dianping/cat
官方DOME:http://unidal.org/cat/r/t?ip=All&queryname=&domain=cat
接入CAT客户端后,CAT客户端每分钟发送一次自身的状态信息。
状态信息包括:服务器系统信息、JVM 内存/GC信息、线程信息、CAT监控使用信息等。详情如下图:
状态信息的原始数据可以查看“Transaction“中的System类型信息,如下图:
“Heartbeat”实时报表用来展示状态信息,可以看到当前项目下所有的部署机器(支付中心只有一台服务器),如下图:
配置说明:这个功能无需其他配置,接入就自动上传状态监控信息。
监控一段代码运行情况:运行时间统计、次数、错误次数等等。如下图:
上面图一展示的是请求过程中监控的不同代码段类型的执行情况,不同类型表示范围不一样;图二展示方法类型里各方法的执行情况。一次请求过程原始监控数据如下(注意类型和上面图一对应):
下面对图中报表进行解释:
a)Type统计界面
b)Name统计界面
c)一个小时内详细指标统计
1. Duration Distribution表示transaction的执行时间分布,这个图可以看出,大部分shopcheckin是在16-64毫秒完成,还有很少部分在512-1024毫秒完成。
2. HitOverTime、Averager Duration Over Time,Failures Over Time 纵轴都是以5分钟为单位,HitOverTime表示5分钟内的访问次数。
3. Averager Duration Over Time表示5分钟内的平均处理时间。
4. Failures Over Time表示5分钟内的Transaction失败次数。
配置说明:代码监控需要相关埋点配置,如方法监控可用包路径、或用@CatMethodMonitori注解配置,更多配置详情请参考《项目接入说明》。
上面我们也看到了一次请求过程的原始监控信息,包括URL、METHOD的耗时、参数、返回值等,如下:
其中经历了一次跨服务调用service-ribbon à service-hi(注意:跨服务是图中第二个红框到第三个红框,而第一个红框到第二个红框是穿透Hystrix熔断器异步线程的),耗时图形分析如下:
“Cross”报表展示了跨服务调用的情况,如下图:
相关配置:默认开启,暂时支持该功能的通信组件:Spring Cloud Ribbon、Spring Cloud Feign(不兼容Sleuth)、Dubbo RPC,更多详情请参考《项目接入说明》。
Problem记录整个项目在运行过程中出现的问题,包括一些错误、访问较长的行为。Problem的类型如下:
1、“Problem”实时报表介绍
All的错误界面
错误一个小时内的实时趋势图
点击机器IP,进入某一台机器出现的具体问题,这个包括了All中出现的所有错误统计之外,还增加了以分钟和线程为单位的错误分布图,具体如下:
2、“Problem”历史报表介绍
1)在选择了特定的域、报表类型、时间和IP之后,点击[:: show ::] 查看某一Type下的Problem出现次数的分布图。(当前这一天、上一天、上周这一天)
2)进一步,可以查看该Type下,某个Status的Problem出现次数的分布图。(当前这一天、上一天、上周这一天)
相关配置:URL、方法监控会自动记录异常名称,如果需要集成日志框架(log4j、logback)打印上传错误信息,请参考《项目接入说明》。
SQL执行监控可以看到每个DAO方法执行解析的SQL语句、SQL语句执行时长、以及连接到哪个数据库(URL)执行;如果SQL执行出现异常,还会记录异常信息;另外还可以过滤出慢SQL。
SQL监控执行整体情况如下:
各DAO方法监控如下:
测试一个方法里执行CURD的“Log View”信息如下:
SQL类型(insert/select/update/delete)执行情况的统计如下:
每个数据库执行情况的统计如下:
另外,还可以在“Problem”标签页面过滤出慢SQL,如下图:
相关配置:支持Mybatis的SQL监控,需要配置Mybatis监控插件,请参考《项目接入说明》。
上面介绍这些功能主要是gc-cat-client SDK中实现的,稍微配置一下就可以使用。
除此外,还有可以自定义监控以实现业务监控,CAT客户端本身提供了几种监控类型的API, CAT支持的监控消息类型包括:
1)、Transaction:适合记录跨越系统边界的程序访问行为,比如远程调用,数据库调用,也适合执行时间较长的业务逻辑监控,Transaction用来记录一段代码的执行时间和次数。
2)、Event:用来记录一件事发生的次数,比如记录系统异常,它和transaction相比缺少了时间的统计,开销比transaction要小。
3)、Heartbeat:表示程序内定期产生的统计信息, 如CPU%, MEM%, 连接池状态, 系统负载等。
4)、Metric:用于记录业务指标、指标可能包含对一个指标记录次数、记录平均值、记录总和,业务指标最低统计粒度为1分钟。
Metric一共有三个API,分别用来记录次数、平均、总和,统一粒度为一分钟:
a).logMetricForCount:用于记录一个指标值出现的次数。
b).logMetricForDuration:用于记录一个指标出现的平均值。
c).logMetricForSum:用于记录一个指标出现的总和。
看到这些类型名称,可知我们前面介绍的这些功能也是基于这几种监控消息类型的API实现的。
一份埋点的样例:
Transaction:用来记录一段程序响应时间;Even:用来记录一行code的执行次数;Metric:用来记录一个业务指标。这些指标都是独立的,可以单独使用,主要看业务场景。
下面的埋点代码里面表示需要记录一个页面的响应时间,并且记录一个代码执行次数,以及记录两个业务指标,所有用了一个Transaction,一个Event,两个Metric。Transaction的埋点一定要complete,切记放在finally里面。
代码中自定义好业务指标监控后,然后运行测试上传一些监控数据,接着到“业务监控配置”页面(http://192.168.1.52:8888/cat/s/config? op=list)配置大盘显示和告警,然后就可以在“Business”而页面看到相关图表,如下:
上面业务监控我们也说到业务指标也可以设置告警的,除此外,Transaction/Event/异常/心跳都可以设置告警,如下图所示:
URL(/hi)执行次数告警测试:
还有一些全局的报表统计,访问地址(比较隐蔽):http://192.168.1.52:8888/cat/r/overload
如“全局统计异常”报表,看到各个项目的异常情况:
“服务可用排行”报表,看到各服务可用情况:
“线上容量规划”报表,看到各项目一些资源使用情况:
以上总结了本人发现的且认为比较有用的CAT监控功能,基本能满足大部分监控需求,更多功能有待大家挖掘。
另外,下篇博文将会介绍本人重新封装的CAT客户端埋点SDK,欢迎提出建议。
【参考资料】
1、 CAT相关文档
2、 GitHub - dianping/cat: Central Application Tracking
3、 深度剖析开源分布式监控CAT
4、 大众点评网监控平台剖析
5、 透过CAT,来看分布式实时监控系统的设计与实现
6、 Dapper,大规模分布式系统的跟踪系统 by bigbully