ASE 2021丨Groot：基于事件图的工业环境根因分析方法

论文标题 ｜ Groot: An Event-graph-based Approach for Root Cause Analysis in Industrial Settings
论文来源 ｜ ASE 2021
论文链接 ｜ https://arxiv.org/abs/2108.00344
源码链接 ｜ 未公布

TL;DR

针对工业界微服务架构下根因定位的 operation, system scale, monitoring complexities 三大问题，论文中提出了基于事件图的根因分析 RCA 方法 Groot，该方法构建基于事件的实时因果关系图，这些事件是总结分析下的系统中各种类型的指标、日志和活动。 此外，为了采用 SRE 的领域知识，Groot 可以通过用户自定义事件和领域规则进行定制化。目前 Groot 可用于 5000 ± 微服务规模的根因定位问题，实验部分收集了 952 个历史故障案例来验证 Groot 的有效性，实验结果表明 Groot 可以达到准确率 Top-3 95%，Top-1 78%，而且运行时间约为 5s。

Algorithm/Model

首先以一个具体的故障案例来说明事件因果图的必要性，如下图所示。此图的真正根因是 Service E 新代码部署导致 Checkout 服务延迟增加 API Call Timeout。

左图就是直接的服务依赖图，图中颜色表示表示异常等级。按照传统的根据异常程度判定根因的方法会将 Service B、D、E 判定为根因，且 Service B 其异常程度高最可能有最大的根因概率，那么这一结果很可能定位错误。🤔

右图为 Groot 基于事件构造的因果图，每个服务的事件作为节点，每个节点都添加了告警信息，这样就非常一目了然了。

📢 注意：图中粉红线表示 Casual Link，但是 Casual 为人工标注 且 手动更新的，而不是挖掘出的因果关系。例如为 Service C 配置规则如下

以上真实故障示例说完，总结 Groot 流程如下图所示：

主要包括三部分：

• Service dependency graph construction
• Event causality graph construction
• Root cause ranking

服务依赖图构建

服务依赖图首先以告警服务集合出发表示为$I$​ ，例如上述示例中$I=\{Checkout\}$​。Groot 会在后端维护一个全局的服务依赖图$G_{global}$​，其服务调用关系从 log & trace 中解析得到。

服务依赖图根据$G_{global}$​​ 和$I$​​ 构建。首先扩展服务列表$L$​​ ，即图$G_{global}$​​ 中以$I$​​ 为中心半径为$r$​​ 的节点集合$L = \{ u |\exists ~ v \in I~~ dist(u, v) ≤ r~~or~~dist(v, u) ≤ r \}$​​​​，实际中$r$​​​​ 设为 2。这步说明作者会根因会出现在$r$​​​-hop 范围内。

事件因果图构建

首先需要收集事件，例如 eBay 提供的事件示例如下所示，注：“De Facto” 表示可直接从 API 查询的事件。

事件类型主要分为三类：

• 性能指标，大部分是通过历史数据收集；
• 状态日志，注 Markdown 表示整个服务 down；
• 开发者活动；

每个事件类型表示为$eT=\{pair_i=(property_i, possile\_value_i)\}$ ，每个事件表示为$e=\{pair_i=(Property_i, value_i)\}$。

所有事件需要包含三个属性：

• Service：事假所属服务名称；
• Type：事件类型；
• StartTime：事件开始时间；

例如图 1 中 Service-C 表示为 { “Service” : “Service-C”, “Type” : “Latency Spike”, “DataCenter” : “DC-1”, “StartTime” : XXXXX, “EndTime” : YYYYY, ... } .

基于服务依赖图$G$ 然后将服务中的告警信息包含在内，后面构造 Causal Link 用于 RCA 排序，至于 Causal Link 此处引用论文中的一句话：

SRE knowledge is engineered into rules and used to create causal links between the pairs of events.

每个 Causal Link 包含以下字段：

• Event：事件类型
• Target-Service：服务级别因果方向，其取值如下
  • self：表示目标事件在相同服务内；
  • Outgoing/Incoming：表示上游或者下游服务；
• Target-Events：目标服务的事件类型；

📢 Casual Link 方向一般为 Event 至 Target−Events，还有其它特殊字段的配置就不细讲，参考意义不大。

根因排序

论文在事件因果图中进行根因推荐。论文中提到了其 GrootRank 算法，本质上是对 PageRank 进行一项定制化。即根据作者观察根因很可能是叶子节点，因此叶子节点初始化分数为 1，其它初始化为 0.5。对比结果如下：

Experiments

实验部分采用了 952 个真实故障案例，其中 782 个业务故障 170 个服务故障。

baselines 仅采用了两种基于规则的方法：

• Naive Approach，基于异常程度的方法；

• Non-adaptive，即 Casual Link 中 Target Type 没有 Dynamic 且不使用 condition 字段的情况。

  简而言之就是规则不是那么细致的情况下。

实验结果如下所示：

再展示下用户界面，其它的不再赘述。

Thoughts

• 整体而言全篇论文属于规则的配置过程，创新是考虑了不同节点事件关系。
• 实验部分和基于规则的 baselines 对比没有什么参考价值，个人感觉 GrootRank 部分上其它算法也可得到不错的结果。
• 可能仅 eBay 自家使用没什么问题，如果作为一个产品大部分客户都不会去给每条边配置个故障 casual link。😭

---

---