饿了么监控系统EMonitor：是一款服务于饿了么所有技术部门的一站式监控系统，覆盖了系统监控、容器监控、网络监控、中间件监控、业务监控、接入层监控以及前端监控的数据存储与查询。每日处理总数据量近PB，每日写入指标数据量百T，每日指标查询量几千万，配置图表个数上万，看板个数上千。
CAT：是基于Java 开发的实时应用监控平台，为美团点评提供了全面的实时监控告警服务
本文通过对比分析下2者所做的事情为契机讨论监控系统或许该有的面貌，以及浅谈下监控系统发展的各个阶段
首先要强调的是这里我们只能拿到github上开源版CAT的最新版3.0.0，所以是基于此进行对比
接下来说说CAT做了哪些事情？
抽象出Transaction、Event、Heartbeat、Metric 4种监控模型。
针对Transaction和Event都固定了2个维度，type和name，并且针对type和name进行分钟级聚合成报表并展示曲线。
针对上述Transaction、Event的type和name分别有对应的分钟级的采样链路
目前支持Counter和Timer类型的打点，支持tag，单机内单个Metric的tag组合数限制1000。
并且有简单的监控看板，如下图所示：
比如和Mybatis集成，在客户端开启相关的sql执行统计，并将该统计划分到Transaction统计看板中的type=SQL的一栏下
可以针对上述的Transaction、Event等做一些简单的阈值告警
饿了么EMonitor借鉴了CAT的相关思想，同时又进行了改进。
针对Transaction和Event都固定了2个维度，type和name，不同地方在于聚合用户发过来的数据
CAT的架构图如下所示：
CAT的消费机需要做如下2件事情：
EMonitor的架构图如下所示：
EMonitor分2路对数据进行隔离处理：
所以EMonitor和CAT的一个很大不同点就在于对指标的处理上，EMonitor交给专业的时序数据库来做，而CAT自己做聚合就显得功能非常受限，如下所示：
但是CAT也有自己的优势：
目前CAT和EMonitor都可以通过type和name来过滤采样链路，不同点在于
EMonitor的链路如下所示：
EMonitor支持Counter、Timer、Histogram、Payload、Gauge等等多种形式的打点方式，并且支持tag
也就是任意Metric打点都可以流经EMonitor进行处理了并输送到LinDB时序数据库中。至此，EMonitor就可以将任何监控指标统一在一起了，比如机器监控都可以通过EMonitor来保存了，这为一站式监控系统奠定了基础
CAT只有一个简易的Metric看板
EMonitor针对Metric开发了一套可以媲美Grafana的指标看板，相比Grafana的优势：
类SQL的配置查询指标方式如下所示：
看板整体如下所示：
移动端显示如下：
目前EMonitor已经打通了IaaS层、PaaS层、应用层的所有链路和指标的监控，再也不用在多个监控系统中切换来切换去了，如下所示
以打通饿了么分库分表中间件DAL为例：
再以打通饿了么SOA服务为例：
可以针对所有的监控指标配置如下告警方式：
本阶段实现方式：程序打日志，使用ELK来存储和查询程序的运行日志，ELK也能简单显示指标曲线
排障过程：一旦有问题，则去ELK中搜索可能的异常日志来进行分析排障
上一个阶段存在的问题：ELK只是基于一行一行日志进行聚合或者搜索分析，日志之间没有上下文关联。很难知道一次请求耗时较长究竟耗时在哪个阶段
本阶段实现方式：CAT横空出世，通过建模抽象出Transaction、Metric等监控模型，将链路分析和简单的报表带入了大家的视野
告警方式：针对报表可以进行阈值监控
排障过程：一旦有告警，可以通过点击报表来详细定位到是哪个type或name有一定问题，顺便找到对应的链路，查看详细的信息
上一阶段存在的问题：CAT对自定义指标支持的比较弱，也无法实现或者展现更加多样的查询聚合需求
本阶段的实现方式：支持丰富的Metric指标，将链路上的一些报表数据也可以划分到指标中，交给专业的时序数据库来做指标的存储和查询，对接或者自研丰富的指标看板如Grafana
告警方式：针对指标进行更加丰富的告警策略
排障过程：一旦有告警，可能需要到各个系统上查看指标看板，粗略定位根因，再结合链路总和分析
上一阶段存在的问题：系统监控、中间件和业务监控、部分业务监控、链路监控与指标监控都各搞一套数据收集、预处理、存储、查询、展现、告警流程，各个系统处理数据格式、使用方式不统一
本阶段的实现方式：打通从系统层面、容器层面、中间件层面、业务层面等等的可能的链路和指标监控，统一数据的处理流程，同时整合发布、变更、告警与监控曲线结合，成为一站式监控平台
告警方式：可以统一的针对各个层面的监控数据做统一化的告警
排障过程：只需要在一个监控系统中就可以查看到所有的监控曲线和链路信息
目前我们EMonitor已完成这个阶段，将公司之前存在已久的3套独立的监控系统统一整合成现如今的一套监控系统
上一阶段存在的问题：
总之：之前的阶段都是去做一个监控平台，用户查询什么指标就展示相应的数据，监控平台并不去关心用户所存储数据的内容。现在呢就需要转变思路，监控平台需要主动去帮用户分析里面所存储的数据内容
本阶段的实现方式：所要做的就是把帮用户分析的过程抽象出来，为用户构建应用大盘和业务大盘，以及为大盘做相关的根因分析。
根因分析：一个大盘有很多的环节，每个环节绑定有很多的指标，每次某个告警出来有可能需要详细的分析下每个环节的指标，比如消费kafka的延迟上升，有各种各样的原因都可能导致，每次告警排查都需要将分析流程再全部人为分析排查下，非常累，所以需要将定位根因的过程通过建模抽象下，来进行统一解决
趋势报表分析：主动帮用户发现一些逐渐恶化的问题点，比如用户发布之后，接口耗时增加，很可能用户没有发现，虽然当前没有问题，但是很有可能在明天的高峰期就会暴露问题，这些都是已经实实在在发生的事故
要想做主动分析，还深度依赖指标下钻分析，即某个指标调用量下降了，能主动分析出是哪些tag维度组合导致的下降，这是上述很多智能分析的基础，这一块也不简单
告警方式：可以统一的针对各个层面的监控数据做统一化的告警
排障过程：NOC根据业务指标或者业务大盘快速得知是哪些业务或者应用出先了问题，应用的owner通过应用大盘的体检得知相关的变动信息，比如是redis波动、database波动、上下游应用的某个方法波动等等，来达到快速定位问题目的，或者通过对大盘执行根因分析来定位到根因
常见一张3者关系的图
三者的确都不可或缺，相辅相成，但是我想说以下几点：
参考链接：
CAT：https://github.com/dianping/cat
深度剖析开源分布式监控CAT：https://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring.html
作者信息：李刚，网名乒乓狂魔，饿了么监控组研发专家，饿了么内部时序数据库LinDB项目负责人，目前致力于监控的智能分析领域。
(en)
简体中文
