勇攀监控高峰 | EMonitor 之根因分析

背景

---

阿里集团针对故障处理提出了“1/5/10”的目标-- 1 分钟发现、5 分钟定位、10 分钟恢复，这对我们的定位能力提出了更高的要求。

EMonitor 是一款集成 Tracing 和 Metrics，服务于饿了么所有技术部门的一站式监控系统，其覆盖了：

1、前端监控、接入层监控；

2、业务 Trace 和 Metric 监控；

3、所有的中间件监控；

4、容器监控、物理机监控、机房网络监控。

每日处理总数据量近 PB，每日写入指标数据量上百 T，日均几千万的指标查询量，内含上万个图表、数千个指标看板，并且已经将所有层的监控数据打通并串联了起来。但是在故障来临时，用户仍然需要花费大量时间来查看和分析 EMonitor 上的数据。

比如阿里本地生活的下单业务，涉及到诸多应用，每个应用诸多 SOA 服务之间错综复杂的调用关系，每个应用还依赖 DB、Redis、MQ 等等资源，在下单成功率下跌时，这些应用的负责人都要在 EMonitor 上查看指标曲线以及链路信息来进行人肉排障以自证清白，耗时耗力，所以自动化的根因分析必不可少。

根因分析建模

---

业界已经有好多在做根因分析的了，但是大都准确率不高，大部分还在 40% 到 70% 之间，从侧面说明根因分析确实是一个难啃的骨头。

根因分析看起来很庞大，很抽象，无从下手，从不同的角度（可能是表象）去看它，就可能走向不同的路。那如何才能透过表象来看到本质呢？

我这里并不会一开始就给你列出高大上的算法解决方案，而是要带你重新认知根因分析要解决的问题到底是什么。其实好多人对要解决的问题都模糊不清，你只有对问题理解清楚了，才能有更好的方案来解决它。

要解决什么样的问题

举个例子：现有一个应用，拥有一堆容器资源，对外提供了诸多 SOA 服务或者 Http 服务，同时它也依赖了其他应用提供的服务，以及 DB 资源、Redis 资源、MQ 资源等等，那我们如何才能够全面的掌控这个应用的健康状况呢？

我们需要掌控：

1、掌控这个应用的所有入口服务的「耗时」和「状态」

2、掌控每个入口服务之后每种操作的「耗时」和「状态」

一个应用都有哪些入口？

1、SOA 服务入口；

2、Http 服务入口；

3、MQ 消费消息入口；

4、定时 job 入口；

5、其他的一些入口。

进入每个入口之后，都可能会有一系列的如下 5 种操作和 1 种行为（下面的操作属性都是以阿里本地生活的实际情况为例，并且都包含所在机房的属性）：

1、DB 远程操作：有 dal group、table、operation（比如select、update、insert等）、sql 的操作属性；

2、Redis 远程操作：有 command 的操作属性；

3、MQ 远程操作（向MQ中写消息）：有 exchange、routingKey、vhost 的操作属性；

4、RPC 远程操作：有 远程依赖的 appId、远程 method 的操作属性；

5、Local 操作（即除了上述4种远程操作之外的本地操作）: 暂无属性；

6、抛出异常的行为：有异常 name 的属性。