本文通过对比分析两者所做的事情，讨论监控系统可能是什么样子，并简单说一下监控系统发展的各个阶段。图片来自PexelsEMonitor监控系统：是服务于饿了么所有技术部门的一站式监控系统，涵盖系统监控、容器监控、网络监控、中间件监控、业务监控、接入层监控以及数据存储和查询的前端监控。每天处理的数据总量近PB，每天写入的索引数据量数百TB，每天索引查询数千万，配置图表数量数万，看板是数千个。CAT：是基于Java开发的实时应用监控平台，为美团点评提供全面的实时监控和告警服务。CAT做了什么（开源版）首先要强调的是，这里我们只能拿到GitHub上最新的CAT开源版3.0.0版本，所以对比以此为准。接下来说说CAT是干什么的？①抽象监控模型抽象四种监控模型：Transaction、Event、Heartbeat、Metric：Transaction：用来记录一段代码的执行时间和次数。事件：用于记录事件发生的次数。心跳：表示程序内部周期性产生的统计信息，如CPU使用率。Metric：用于记录业务指标，可以记录个数和总和。Transaction和Event都固定type和name两个维度，对type和name进行分钟级聚合，生成报表和展示曲线。②采样链接对上述交易和事件的类型和名称有对应的分钟级采样链接。③自定义指标点目前支持Counter和Timer类型点，支持tag，单机单个metric的tag组合数量限制为1000个。并有一个简单的监控板，如下图：④与集成其他组件如Mybatis，在客户端打开相关的SQL执行统计，统计到事务统计板的type=SQL列。⑤Alarm可以对上述的Transaction、Event等做一些简单的阈值报警。饿了么EMonitor与CAT比较饿了么EMonitor借鉴了CAT的思想并同时对其进行了改进。①介绍Transaction和Event的概念。对于Transaction和Event，两个维度是固定的，type和name。区别在于用户发送的数据的聚合。CAT的架构图如下：CAT的消费机需要做以下两件事：根据当前小时的类型和名称聚合事务、事件等消息模型，并写入历史的聚合数据小时进入MySQL。将链接数据写入本地文件或远程HDFS。EMonitor的架构图如下：EMonitor通过两种方式隔离数据：实时流计算：将用户发送的链接中的Transaction、Event等监控模型转化为指标数据，并进行10s预聚合。同时，用户发送的指标数据也会进行10秒的预聚合。最后将10s的预聚合数据写入LinDB时序数据库（开源，有兴趣可以关注star），和Kafka，让报警模块watchdog消费Kafka进行实时报警。Real-TimeDataWriter：为用户发送的链接数据建立链接索引，将索引和链接数据写入HDFS和HBase，并建立应用程序之间的依赖关系，将依赖关系写入Neo4j。因此，EMonitor和CAT的一个很大的区别在于对指标的处理，而EMonitor是交给了专业的时序数据库。但是CAT的自聚合非常有限，如下图：CAT只能查看整整一个小时的类型和名称数据，不能跨小时，即不能查看任意两次之间的报表数据。EMonitor没有这样的限制。CAT无法查看所有类型的聚合响应时间和QPS，但EMonitor可以灵活自由地组合类型和名称进行聚合。CAT的类型和名称报告是分钟级别的，而EMonitor是10s级别的。CAT的类型和名称不能直接与历史报表曲线进行对比，而EMonitor可以对比历史报表曲线，更容易发现问题。CAT的类型和名称列表的第一页显示了一堆数字，一些直观的信息无法立即获取。比如给定TP99的响应时间100ms，不管是好是坏，EMonitor都有当前曲线和历史曲线，相对来说可以直接判断好不好。CAT的TP99和TP999是根据单机一定小时内的报告准确的。另外，多台机器或多个小时的总TP99和TP999是加权平均计算的，精度有待提高。但是CAT也有自己的优势：CAT包含TP999，TP9999线（但是精度还是有一些问题），EMonitor只能和TP99一样薄。CAT的类型和名称可以根据机器维度进行过滤，但是EMonitor没有那么细粒度。②采样链接目前CAT和EMonitor都支持按类型和名称过滤采样链接。不同的是CAT的采样环节是分钟级别的，而EMonitor是10s级别的。对于某个类型和名称，CAT目前还不能很容易地找到想要的链接，但是EMonitor可以很容易地在某个时间或某个时间段内找到想要的链接（已申请专利）。EMonitor的链接如下：上图是在某个10s的时间，在某个type和name的过滤条件下的采样链接。第一行是这10s内的采样链接，按照响应时间排序。随意点击一个回复时间查看对应的链接详情。③自定义Metric打点EMonitor支持Counter、Timer、Histogram、Payload、Gauge等多种打点形式，支持tag：Counter：计数累加型。定时器：可以记录一段代码的耗时，包括执行次数，耗时的最大值、最小值和平均值。Histogram：包含Timer的所有内容，支持计算TP99线，以及其他任意TP线（0到100）。Payload：可以记录一个数据包的大小，包括数据包的个数，包的最大值、最小值、平均值。Gauge：度量值，一般用于度量队列大小、连接数、CPU、内存等。即任何度量打点都可以通过EMonitor处理后发送到LinDB时序数据库。此时，EMonitor可以统一任何监控指标。例如，机器监控可以通过EMonitor进行保存，为一站式监控系统打下基础。④CustomMetricKanbanCAT只有一个简单的MetricKanban。EMonitor针对Metric开发了一套可以媲美Grafana的指标仪表盘。相对于Grafana的优势：有一种非常简单的方法来配置类似于SQL的指标。与公司人事组织架构相结合，权限控制更加优雅，不同部门可以建立自己的看板。对于指标和看板的采集，当源指标或看板发生变化时，采集员无需更改。alpha、beta、prod不同环境之间的指标和dashboard一键同步，无需多次配置。在PC和移动设备上同时查看指标和仪表板。类SQL配置查询索引方法如下：可以配置图表的显示形式。可以配置查询的字段和字段之间的加减乘除等丰富的表达式。可以为任何标签配置多个过滤条件。您可以配置分组依据和排序依据。看板整体如下：移动端显示如下：⑤与其他组件的集成目前EMonitor已经打通了IaaS层、PaaS层、应用层所有环节和指标的监控，没有需要在多个监控系统之间切换才行。如下：IaaS层物理机、机房网络交换机等监控指标。PaaS层中间件服务器监控指标。应用层SOA、Exception、JVM、MQ等客户端相关指标。应用层自定义的监控指标。以饿了么的分库分表中间件DAL为例：可以根据机房、执行状态、表、操作类型（如Insert、Update、Select等）过滤查看：左边的列表显示了每条SQL执行耗时的平均值。右边两张图展示了SQL在DAL中间件层面、DB层面和调用QPS的耗时。可以给出后端DAL中间和DB上打的SQL的分布情况，可以用来查看是否有热点。还有一些SQL查询结果的packetsize曲线，SQL被DAL限制的情况等等。可以随时查看SQL的调用链接信息。再以饿了么的SOA服务为例：可以根据数据中心和状态信息进行过滤。左栏列出了应用程序提供的SOA服务接口，以及平均响应时间和与昨天的比较。右边两张图分别是对应服务接口的服务响应时间和QPS以及与昨天的对比。同时，平均响应时间可切换为TP99或其他TP值，并有跳线可快速为相关曲线添加告警。去链接。可以切换到单机维度查看每台机器的SOA接口的响应时间和QPS来定位某台机器的问题。可以给出SOA接口调用在不同集群中的分布比例。这个SOA接口的所有调用者都可以连同他们的QPS一起给出。可以随时查看SOA接口的调用链接信息。⑥报警可以为所有监控指标配置如下报警方式：阈值：简单的阈值报警，适用于CPU、内存等。同比比较：与过去同期相比的报警。Trend：适用于不需要阈值的比较平滑连续的智能告警。其他形式的警告。浅谈监控系统的发展趋势①日志监控阶段该阶段的实现方式：程序日志，ELK用于存储和查询程序的运行日志，ELK也可以简单的展示指标曲线。排查流程：一旦出现问题，到ELK中查找可能存在的异常日志进行分析排查。②前一阶段链路监控阶段存在的问题：ELK只是根据逐行日志进行聚合或搜索分析，日志之间没有上下文关联。很难知道请求在哪个阶段花费了很长时间。现阶段实现方式：CAT诞生，通过建模抽象出Transaction、Metric等监控模型，将链路分析和简单报表带入大家的视野。告警方式：可以对报表进行阈值监控和排查处理：一旦有告警，可以点击报表详细定位是哪个型号或名称出现了某些问题，顺便找到对应的链接查看详细信息。③指标监控阶段前期存在的问题：CAT对自定义指标的支持相对较弱，无法实现或展示更多样化的查询聚合需求。现阶段实现方式：支持丰富的指标指标，将链路上的部分报表数据拆分成指标，交由专业的时序数据库进行指标存储和查询，对接或自研丰富的指标看板如Grafana。告警方式：对指标实施更丰富的告警策略排查流程：一旦出现告警，可能需要查看各个系统的指示灯板，大致定位根源，再结合链路汇总分析。④平台集成阶段前期存在的问题：系统监控、中间件和业务监控，部分业务监控、链路监控、指标监控各有一套数据采集、预处理、存储、查询、展示、告警流程，每个系统处理的数据格式和使用方法都不统一。本阶段实现方式：从系统层、容器层、中间件层、业务层等打通可能的环节和指标监控，统一数据处理流程，同时整合发布、变更、告警和监控曲线时间。成为一站式监控平台。告警方式：可对各级监控数据进行统一告警排查流程：所有监控曲线及链路信息仅在一个监控系统中查看。目前我们的EMonitor已经完成了这个阶段，将公司长期存在的三个独立的监控系统整合到现在的监控系统中。⑤深入分析阶段前一阶段的问题：虽然用户可以在一个系统中看到各个层级的监控数据，但在排查问题的时候还是需要花费大量的时间去查看各个层级是否存在问题。查看一项可能会错过问题的根本原因。没有整个业务的全局监控视角，都停留在各自应用的视角。简而言之：前一阶段是搭建一个监控平台，用户查询到的任何指标都会显示相应的数据。监控平台并不关心用户存储的数据内容。现在需要转变思路，监控平台需要主动帮助用户分析存储在其中的数据内容。该阶段的实现方式：需要做的就是将帮助用户分析的过程抽象出来，为用户搭建一个应用市场和业务市场，为市场做相关的根因分析。ApplicationDashboard：为当前应用搭建上下游应用依赖监控，对当前应用关联的机器、Redis、MQ、Database等进行监控，随时可以对应用进行体检应用主动暴露问题，而不是等用户走。一一检查指标，找出问题所在。业务行情：根据业务进行整理或使用链接自动产生行情。市场可以快速告诉用户哪些业务环节出现了问题。根源分析：一个大市场有很多环节，每个环节都绑定很多指标。每次出现某种告警，可能需要详细分析各个环节的指标。比如消费Kafka的延迟增加，可能是由于各种原因造成的。每次检查告警，分析过程都需要人工分析检查，非常累人。因此，定位根本原因的过程需要建模和抽象，求统一解。趋势报表分析：主动帮助用户发现一些逐渐恶化的问题。比如用户发布后，界面耗时增加。很有可能是用户没有找到。虽然目前没有问题，但很有可能明天的高峰期就会暴露问题。这些都是真实发生过的事故。如果要做主动分析，也非常依赖指标的下钻分析，即当某个指标的调用量下降时，可以主动分析是哪些标签维度组合导致了下降。这是上面很多智能分析的基础，而这一项并不简单。告警方式：可对各级监控数据进行统一的告警排查流程：NOC可根据业务指标或业务市场，快速获知哪个业务或应用最先出现问题，并可通过应用市场体检。了解相关变化。比如Redis的波动，数据库的波动，上下游应用某个方法的波动等等，快速定位问题，或者通过市场上的根因分析来定位根因。下面说说Logging、Tracing、Metrics的关系，如下图所示：三者确实缺一不可，相辅相成，但我想说的是：三者在监控和排查中的比例是有很大区别的：Metrics占据大头，Tracing次之，Logging最后。Tracing包含了应用之间重要的依赖信息，而Metrics有更大的深度分析和挖掘空间，所以未来一定要在Metrics上大做文章。结合Tracing中的applicationdependencies做更深入的全局分析，也就是Metrics和Tracing的结合有了更多的可能性。参考资料：CAThttps://github.com/dianping/cat深度剖析开源分布式监控CAThttps://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring。html作者：李刚简介：网名乒乓狂魔，饿了么监控团队研发专家，饿了么内部时序数据库LinDB项目负责人，目前致力于监控智能分析领域。
