本文通过对比分析下两者所做的事情为契机讨论监控系统或许该有的面貌，以及浅谈下监控系统发展的各个阶段。
图片来自 Pexels
饿了么监控系统 EMonitor ：是一款服务于饿了么所有技术部门的一站式监控系统，覆盖了系统监控、容器监控、网络监控、中间件监控、业务监控、接入层监控以及前端监控的数据存储与查询。
每日处理总数据量近 PB ，每日写入指标数据量百 T，每日指标查询量几千万，配置图表个数上万，看板个数上千。
CAT：是基于 Java 开发的实时应用监控平台，为美团点评提供了全面的实时监控告警服务。
CAT 做的事情（开源版）
首先要强调的是这里我们只能拿到 GitHub 上开源版 CAT 的最新版 3.0.0 ，所以是基于此进行对比。接下来说说 CAT 做了哪些事情？
①抽象出监控模型
抽象出 Transaction、Event、Heartbeat、Metric 4 种监控模型：
Transaction：用来记录一段代码的执行时间和次数。
Event：用来记录一件事发生的次数。
Heartbeat：表示程序内定期产生的统计信息，如 CPU 利用率。
Metric：用于记录业务指标，可以记录次数和总和。
针对 Transaction 和 Event 都固定了两个维度， type 和 name ，并且针对 type 和 name 进行分钟级聚合成报表并展示曲线。
针对上述 Transaction、Event 的 type 和 name 分别有对应的分钟级的采样链路。
并且有简单的监控看板，如下图所示：
比如和 Mybatis 集成，在客户端开启相关的 sql 执行统计，并将该统计划分到 Transaction 统计看板中的 type=SQL 的一栏下。
饿了么 EMonitor 和 CAT 的对比
CAT 的架构图如下所示：
对 Transaction、Event 等消息模型按照 type 和 name 进行当前小时的聚合，历史小时的聚合数据写入到 MySQL 中。
将链路数据写入到本地文件或者远程 HDFS 上。
EMonitor 的架构图如下所示：
Real-Time Streaming Compute：对用户发过来的链路中的 Transaction 、Event 等监控模型转变成指标数据并进行 10s 的预聚合，同时也对用户发过来的 Metric 数据进行 10s 预聚合。
最后将 10s 预聚合的数据写入到 LinDB 时序数据库（已开源，有兴趣的可以关注 star 下）中，以及 Kafka 中，让告警模块 watchdog 去消费 Kafka 做实时告警。
Real-Time Data Writer：对用户发过来的链路数据构建链路索引、向 HDFS 和 HBase 写入索引和链路数据，同时会构建应用之间的依赖关系，将依赖关系写入到 Neo4j 中。
CAT 只能整小时的查看 type 和 name 数据，不能跨小时，即不能查看任意两个时间之间的报表数据， 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 含有 TP999、TP9999 线（但是准确性还有些问题）， EMonitor 只能细到 TP99 。
CAT 的 type 和 name 可以按照机器维度进行过滤， EMonitor 没有做到这么细粒度。
CAT 的采样链路是分钟级别的， EMonitor 是 10s 级别的。
针对某一个 type 和 name ，CAT 目前无法轻松找想要的链路， EMonitor 可以轻松的找到某个时刻或者说某段时间内响应时间想要的链路（目前已经申请专利）。
上图是某个10s 时刻、某个 type 和 name 过滤条件下的采样链路。 第一行是这 10s 内的采样链路，按照响应时间进行了排序。 可以随意点击某个响应时间来查看对应的链路详情。
Counter：计数累加类型。
Timer：可以记录一段代码的耗时，包含执行次数、耗时最大值、最小值、平均值。
Histogram：包含 Timer 的所有东西，同时支持计算 TP99 线，以及其他任意 TP 线（从 0 到 100 ）。
Payload：可以记录一个数据包的大小，包含数据包个数、包的最大值、最小值、平均值。
Gauge：测量值，一般用于衡量队列大小、连接数、CPU、内存等等。
有一套类似 SQL 的非常简单的配置指标的方式。
跟公司人员组织架构集成，更加优雅的权限控制，不同的部门可以建属于自己的看板。
指标和看板的收藏，当源指标或看板改动后，无需收藏人员再改动。
alpha、beta、prod 不同环境之间的一键同步指标和看板，无需配置多次。
PC 端和移动端的同步查看指标和看板。
可以配置图表的展现形式。
可以配置要查询的字段以及字段之间的加减乘除等丰富的表达式。
可以配置多个任意 tag 的过滤条件。
可以配置 group by 以及 order by。
看板整体如下所示：
移动端显示如下：
⑤与其他组件集成
目前 EMonitor 已经打通了 IaaS 层、 PaaS 层、应用层的所有链路和指标的监控，再也不用在多个监控系统中切换来切换去了。
IaaS 层物理机、机房网络交换机等的监控指标。
PaaS 层中间件服务端的监控指标。
应用层 SOA、Exception、JVM、MQ 等客户端的相关指标。
应用层自定义的监控指标。
以打通饿了么分库分表中间件 DAL 为例：
左边列表给出每条 SQL 的执行的平均耗时。
右边 2 个图表给出该条 SQL 在 DAL 中间件层面、 DB 层面的耗时以及调用 QPS。
可以给出该 SQL 打在后端 DAL 中间、 DB 上的分布情况，可以用于排查是否存在一些热点的情况。
还有一些 SQL 查询结果的数据包大小的曲线、 SQL 被 DAL 限流的情况等等。
可以查看任何时间点上该 SQL 的调用链路信息。
可以根据机房和状态信息进行过滤。
左边一栏列出该应用提供的 SOA 服务接口，同时给出平均响应时间以及和昨天的对比情况。
右边的两个图表分别给出了对应服务接口的服务响应时间和 QPS 以及和昨天的对比情况，同时可以切换平均响应时间到 TP99 或者其他 TP 值，同时配有可以快速对相关曲线添加告警的跳转链接。
可以切换到单机维度来查看每台机器该 SOA 接口的响应时间和 QPS ，用来定位某台机器的问题。
可以给出该 SOA 接口调用在不同集群的分布占比。
可以给出该 SOA 接口的所有调用方以及他们的 QPS。
可以查看任何时间点上该 SOA 接口的调用链路信息。
阈值：简单的阈值告警，适用于 CPU 、内存等。
同环比：与过去同期比较的告警。
趋势：适合于相对平滑连续的无需阈值的智能告警。
其他告警形式。
浅谈监控系统的发展趋势
用户虽然可以在一个系统中看到所有各个层面的监控数据了，但是每次排障时仍然要花很多的时间去查看各个层面是否有问题，一旦漏看一项可能就错过了问题所在的根因。
没有整个业务的全局监控视角，都停留在各自应用的角度。
应用大盘：就是为当前应用构建上下游应用依赖的监控、当前应用所关联的机器监控、Redis、MQ、Database 等等监控，可以时刻为应用做体检，来主动暴露出问题，而不是等用户去一个个查指标而后发现问题。
业务大盘：就是根据业务来梳理或者利用链路来自动生产大盘，该大盘可以快速告诉用户是哪些业务环节出的问题。
再谈 Logging、Tracing、Metrics
三者关系如下图所示：
三者在监控排障中的所占比例却大不一样：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 项目负责人，目前致力于监控的智能分析领域。
编辑：陶家龙、孙淑娟
出处：转载自微信公众号阿里巴巴中间件（ID：Aliware_2018）
精彩文章推荐：
