饿了么监控系统 EMonitor 与美团点评 CAT 的对比
背景介绍
CAT 做的事情(开源版)
抽象出监控模型
Transaction:用来记录一段代码的执行时间和次数。 Event:用来记录一件事发生的次数。 Heartbeat:表示程序内定期产生的统计信息, 如CPU利用率。 Metric:用于记录业务指标,可以记录次数和总和。
采样链路
自定义的 Metric 打点
与其他组件集成
告警
饿了么 EMonitor 和 CAT 的对比
引入 Transaction、Event 的概念
对 Transaction、Event 等消息模型按照 type 和 name 进行当前小时的聚合,历史小时的聚合数据写入到 mysql 中; 将链路数据写入到本地文件或者远程 HDFS 上。
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 内的采样链路,按照响应时间进行了排序; 可以随意点击某个响应时间来查看对应的链路详情。
自定义的 Metric 打点
Counter:计数累加类型。 Timer:可以记录一段代码的耗时,包含执行次数、耗时最大值、最小值、平均值。 Histogram:包含 Timer 的所有东西,同时支持计算 TP99 线,以及其他任意 TP 线(从 0 到 100 )。 Payload:可以记录一个数据包的大小,包含数据包个数、包的最大值、最小值、平均值。 Gauge:测量值,一般用于衡量队列大小、连接数、CPU、内存等等。
有一套类似 SQL 的非常简单的配置指标的方式; 跟公司人员组织架构集成,更加优雅的权限控制,不同的部门可以建属于自己的看板; 指标和看板的收藏,当源指标或看板改动后,无需收藏人员再改动; alpha、beta、prod 不同环境之间的一键同步指标和看板,无需配置多次; PC端和移动端的同步查看指标和看板。
可以配置图表的展现形式; 可以配置要查询的字段以及字段之间的加减乘除等丰富的表达式; 可以配置多个任意 tag 的过滤条件; 可以配置 group by 以及 order by。
与其他组件集成
IaaS层物理机、机房网络交换机等的监控指标; PaaS 层中间件服务端的监控指标; 应用层 SOA、Exception、JVM、MQ 等客户端的相关指标; 应用层自定义的监控指标。
左边列表给出每条 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 两者结合发挥出更多的可能性。
作者信息:
李刚,网名乒乓狂魔,饿了么监控组研发专家,饿了么内部时序数据库LinDB项目负责人,目前致力于监控的智能分析领域。
推荐阅读:
喜欢我可以给我设为星标哦
好文章,我 在看