饿了么监控系统 EMonitor 与美团点评 CAT 的对比

背景介绍

饿了么监控系统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的TP9九、TP999基于单机内某个小时内的报表是准确的，除此以外多机或者多个小时的聚合TP9九、TP999是用加权平均来计算的，准确性有待提升

可是CAT也有本身的优点：

• CAT含有TP99九、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二者结合发挥出更多的可能性

参考连接：
CAT：https://github.com/dianping/cat
深度剖析开源分布式监控CAT：https://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring.html

做者信息：李刚，网名乒乓狂魔，饿了么监控组研发专家，饿了么内部时序数据库LinDB项目负责人，目前致力于监控的智能分析领域。

 

 

 

 

原文连接

本文为云栖社区原创内容，未经容许不得转载