https://blog.csdn.net/weixin_43970890/article/details/103028551
饿了么监控系统 EMonitor 与美团点评 CAT 的对比
阿里云技术 2019-11-12 16:02:16 428 收藏 2
文章标签： 云栖社区 Transaction 监控
版权
背景介绍
饿了么监控系统EMonitor：是一款服务于饿了么所有技术部门的一站式监控系统，覆盖了系统监控、容器监控、网络监控、中间件监控、业务监控、接入层监控以及前端监控的数据存储与查询。每日处理总数据量近PB，每日写入指标数据量百T，每日指标查询量几千万，配置图表个数上万，看板个数上千。
CAT：是基于Java 开发的实时应用监控平台，为美团点评提供了全面的实时监控告警服务
本文通过对比分析下2者所做的事情为契机讨论监控系统或许该有的面貌，以及浅谈下监控系统发展的各个阶段
CAT做的事情（开源版）
首先要强调的是这里我们只能拿到github上开源版CAT的最新版3.0.0，所以是基于此进行对比
接下来说说CAT做了哪些事情？
1 抽象出监控模型
抽象出Transaction、Event、Heartbeat、Metric 4种监控模型。
Transaction：用来记录一段代码的执行时间和次数
Event：用来记录一件事发生的次数
Heartbeat：表示程序内定期产生的统计信息, 如CPU利用率
Metric：用于记录业务指标，可以记录次数和总和
针对Transaction和Event都固定了2个维度，type和name，并且针对type和name进行分钟级聚合成报表并展示曲线。
2 采样链路
针对上述Transaction、Event的type和name分别有对应的分钟级的采样链路
3 自定义的Metric打点
目前支持Counter和Timer类型的打点，支持tag，单机内单个Metric的tag组合数限制1000。
并且有简单的监控看板，如下图所示：
4 与其他组件集成
比如和Mybatis集成，在客户端开启相关的sql执行统计，并将该统计划分到Transaction统计看板中的type=SQL的一栏下
5 告警
可以针对上述的Transaction、Event等做一些简单的阈值告警
饿了么EMonitor和CAT的对比
饿了么EMonitor借鉴了CAT的相关思想，同时又进行了改进。
1 引入Transaction、Event的概念
针对Transaction和Event都固定了2个维度，type和name，不同地方在于聚合用户发过来的数据
CAT的架构图如下所示：
CAT的消费机需要做如下2件事情：
对Transaction、Event等消息模型按照type和name进行当前小时的聚合，历史小时的聚合数据写入到mysql中
将链路数据写入到本地文件或者远程HDFS上
EMonitor的架构图如下所示：
EMonitor分2路对数据进行隔离处理：
Real-Time Streaming Compute：对用户发过来的链路中的Transaction、Event等监控模型转变成指标数据并进行10s的预聚合，同时也对用户发过来的Metric数据进行10s预聚合。最后将10s预聚合的数据写入到LinDB时序数据库（已开源，有兴趣的可以关注star下）中，以及kafka中，让告警模块watchdog去消费kafka做实时告警
Real-Time Data Writer：对用户发过来的链路数据构建链路索引、向HDFS和HBase写入索引和链路数据，同时会构建应用之间的依赖关系，将依赖关系写入到Neo4j中
所以EMonitor和CAT的一个很大不同点就在于对指标的处理上，EMonitor交给专业的时序数据库来做，而CAT自己做聚合就显得功能非常受限，如下所示：
CAT只能整小时的查看type和name数据，不能跨小时，即不能查看任意2个时间之间的报表数据，EMonitor没有此限制
CAT没法查看所有type汇总后的响应时间和QPS，EMonitor可以灵活的自由组合type和name进行聚合
CAT的type和name报表是分钟级的，EMonitor是10s级别的
CAT的type和name没能和历史报表曲线直接对比，EMonitor可以对比历史报表曲线，更容易发现问题
CAT的type和name列表首页展示了一堆数字，无法立即获取一些直观信息，比如给出了响应时间TP99 100ms这个到底是好还是坏，EMonitor有当前曲线和历史曲线，相对来说可以直接判断到底ok不ok
CAT的TP99、TP999基于单机内某个小时内的报表是准确的，除此之外多机或者多个小时的聚合TP99、TP999是用加权平均来计算的，准确性有待提高
但是CAT也有自己的优势：
CAT含有TP999、TP9999线(但是准确性还有些问题)，EMonitor只能细到TP99
CAT的type和name可以按照机器维度进行过滤，EMonitor没有做到这么细粒度
2 采样链路
目前CAT和EMonitor都可以通过type和name来过滤采样链路，不同点在于
CAT的采样链路是分钟级别的，EMonitor是10s级别的
针对某一个type和name，CAT目前无法轻松找想要的链路，EMonitor可以轻松的找到某个时刻或者说某段时间内响应时间想要的链路（目前已经申请专利）
EMonitor的链路如下所示：
这张图是某个10s时刻、某个type和name过滤条件下的采样链路
第一行是这10s内的采样链路，按照响应时间进行了排序
可以随意点击某个响应时间来查看对应的链路详情
3 自定义的Metric打点
EMonitor支持Counter、Timer、Histogram、Payload、Gauge等等多种形式的打点方式，并且支持tag
Counter：计数累加类型
Timer：可以记录一段代码的耗时，包含执行次数、耗时最大值、最小值、平均值
Histogram：包含Timer的所有东西，同时支持计算TP99线，以及其他任意TP线(从0到100)
Payload：可以记录一个数据包的大小，包含数据包个数、包的最大值、最小值、平均值
Gauge：测量值，一般用于衡量队列大小、连接数、CPU、内存等等
也就是任意Metric打点都可以流经EMonitor进行处理了并输送到LinDB时序数据库中。至此，EMonitor就可以将任何监控指标统一在一起了，比如机器监控都可以通过EMonitor来保存了，这为一站式监控系统奠定了基础
自定义Metric看板
CAT只有一个简易的Metric看板
EMonitor针对Metric开发了一套可以媲美Grafana的指标看板，相比Grafana的优势：
有一套类似SQL的非常简单的配置指标的方式
跟公司人员组织架构集成，更加优雅的权限控制，不同的部门可以建属于自己的看板
指标和看板的收藏，当源指标或看板改动后，无需收藏人员再改动
alpha、beta、prod不同环境之间的一键同步指标和看板，无需配置多次
PC端和移动端的同步查看指标和看板
类SQL的配置查询指标方式如下所示：
可以配置图表的展现形式
可以配置要查询的字段以及字段之间的加减乘除等丰富的表达式
可以配置多个任意tag的过滤条件
可以配置group by以及order by
看板整体如下所示：
移动端显示如下：
4 与其他组件集成
目前EMonitor已经打通了IaaS层、PaaS层、应用层的所有链路和指标的监控，再也不用在多个监控系统中切换来切换去了，如下所示
1 IaaS层物理机、机房网络交换机等的监控指标
2 PaaS层中间件服务端的监控指标
3 应用层SOA、Exception、JVM、MQ等客户端的相关指标
4 应用层自定义的监控指标
以打通饿了么分库分表中间件DAL为例：
可以根据机房、执行状态、表、操作类型（比如Insert、Update、Select等）进行过滤查看
左边列表给出每条SQL的执行的平均耗时
右边2个图表给出该条SQL在DAL中间件层面、DB层面的耗时以及调用QPS
可以给出该SQL打在后端DAL中间、DB上的分布情况，可以用于排查是否存在一些热点的情况
还有一些SQL查询结果的数据包大小的曲线、SQL被DAL限流的情况等等
可以查看任何时间点上该SQL的调用链路信息
再以打通饿了么SOA服务为例：
可以根据机房和状态信息进行过滤
左边一栏列出该应用提供的SOA服务接口，同时给出平均响应时间以及和昨天的对比情况
右边的2个图表分别给出了对应服务接口的服务响应时间和QPS以及和昨天的对比情况，同时可以切换平均响应时间到TP99或者其他TP值，同时配有可以快速对相关曲线添加告警的跳转链接
可以切换到单机维度来查看每台机器该SOA接口的响应时间和QPS，用来定位某台机器的问题
可以给出该SOA接口调用在不同集群的分布占比
可以给出该SOA接口的所有调用方以及他们的QPS
可以查看任何时间点上该SOA接口的调用链路信息
5 告警
可以针对所有的监控指标配置如下告警方式：
阈值：简单的阈值告警，适用于CPU、内存等
同环比：与过去同期比较的告警
趋势：适合于相对平滑连续的无需阈值的智能告警
其他告警形式
浅谈监控系统的发展趋势
1 日志监控阶段
本阶段实现方式：程序打日志，使用ELK来存储和查询程序的运行日志，ELK也能简单显示指标曲线
排障过程：一旦有问题，则去ELK中搜索可能的异常日志来进行分析排障
2 链路监控阶段
上一个阶段存在的问题：ELK只是基于一行一行日志进行聚合或者搜索分析，日志之间没有上下文关联。很难知道一次请求耗时较长究竟耗时在哪个阶段
本阶段实现方式：CAT横空出世，通过建模抽象出Transaction、Metric等监控模型，将链路分析和简单的报表带入了大家的视野
告警方式：针对报表可以进行阈值监控
排障过程：一旦有告警，可以通过点击报表来详细定位到是哪个type或name有一定问题，顺便找到对应的链路，查看详细的信息
3 指标监控阶段
上一阶段存在的问题：CAT对自定义指标支持的比较弱，也无法实现或者展现更加多样的查询聚合需求
本阶段的实现方式：支持丰富的Metric指标，将链路上的一些报表数据也可以划分到指标中，交给专业的时序数据库来做指标的存储和查询，对接或者自研丰富的指标看板如Grafana
告警方式：针对指标进行更加丰富的告警策略
排障过程：一旦有告警，可能需要到各个系统上查看指标看板，粗略定位根因，再结合链路总和分析
4 平台打通整合阶段
上一阶段存在的问题：系统监控、中间件和业务监控、部分业务监控、链路监控与指标监控都各搞一套数据收集、预处理、存储、查询、展现、告警流程，各个系统处理数据格式、使用方式不统一
本阶段的实现方式：打通从系统层面、容器层面、中间件层面、业务层面等等的可能的链路和指标监控，统一数据的处理流程，同时整合发布、变更、告警与监控曲线结合，成为一站式监控平台
告警方式：可以统一的针对各个层面的监控数据做统一化的告警
排障过程：只需要在一个监控系统中就可以查看到所有的监控曲线和链路信息
目前我们EMonitor已完成这个阶段，将公司之前存在已久的3套独立的监控系统统一整合成现如今的一套监控系统
5 深度分析阶段
上一阶段存在的问题：
用户虽然可以在一个系统中看到所有各个层面的监控数据了，但是每次排障时仍然要花很多的时间去查看各个层面是否有问题，一旦漏看一项可能就错过了问题所在的根因
没有整个业务的全局监控视角，都停留在各自应用的角度
总之：之前的阶段都是去做一个监控平台，用户查询什么指标就展示相应的数据，监控平台并不去关心用户所存储数据的内容。现在呢就需要转变思路，监控平台需要主动去帮用户分析里面所存储的数据内容
本阶段的实现方式：所要做的就是把帮用户分析的过程抽象出来，为用户构建应用大盘和业务大盘，以及为大盘做相关的根因分析。
应用大盘：就是为当前应用构建上下游应用依赖的监控、当前应用所关联的机器监控、redis、MQ、database等等监控，可以时刻为应用做体检，来主动暴露出问题，而不是等用户去一个个查指标而后发现问题
业务大盘：就是根据业务来梳理或者利用链路来自动生产大盘，该大盘可以快速告诉用户是哪些业务环节出的问题
根因分析：一个大盘有很多的环节，每个环节绑定有很多的指标，每次某个告警出来有可能需要详细的分析下每个环节的指标，比如消费kafka的延迟上升，有各种各样的原因都可能导致，每次告警排查都需要将分析流程再全部人为分析排查下，非常累，所以需要将定位根因的过程通过建模抽象下，来进行统一解决
趋势报表分析：主动帮用户发现一些逐渐恶化的问题点，比如用户发布之后，接口耗时增加，很可能用户没有发现，虽然当前没有问题，但是很有可能在明天的高峰期就会暴露问题，这些都是已经实实在在发生的事故
要想做主动分析，还深度依赖指标下钻分析，即某个指标调用量下降了，能主动分析出是哪些tag维度组合导致的下降，这是上述很多智能分析的基础，这一块也不简单
告警方式：可以统一的针对各个层面的监控数据做统一化的告警
排障过程：NOC根据业务指标或者业务大盘快速得知是哪些业务或者应用出先了问题，应用的owner通过应用大盘的体检得知相关的变动信息，比如是redis波动、database波动、上下游应用的某个方法波动等等，来达到快速定位问题目的，或者通过对大盘执行根因分析来定位到根因
再谈Logging、Tracing、Metrics
常见一张3者关系的图
三者的确都不可或缺，相辅相成，但是我想说以下几点：
三者在监控排障中的所占比例却大不一样：Metrics占据大头，Tracing次之，Logging最后
Tracing含有重要的应用之间的依赖信息，Metrics有更多的可深度分析和挖掘的空间，所以未来必然是在Metrics上大做文章，再结合Tracing中的应用依赖来做更深度全局分析，即Metrics和Tracing两者结合发挥出更多的可能性
————————————————
版权声明：本文为CSDN博主「阿里云技术」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_43970890/article/details/103028551