论文标题 ｜ MicroHECL: High-Efficient Root Cause Localization in Large-Scale Microservice Systems
论文来源 ｜ ICSE 2021
论文链接 ｜ https://arxiv.org/pdf/2103.01782.pdf
源码链接 ｜ 未公布

近期，由阿里云云效团队联合复旦大学 CodeWisdom 研究团队、阿里技术风险部安全生产团队，合作完成的论文《MicroHECL: High-Efficient Root Cause Localization in Large-Scale Microservice Systems》被 ICSE 2021 SEIP track 录用。本文针对大规模微服务系统的三种可用性问题，提出了一种高效的根因定位方法 MicroHECL。

MicroHECL 基于动态构建的服务间的依赖图，分析了所有可能的异常传播链路，并基于相关性分析对候选根因进行了排序。本文将机器学习和统计方法相结合，并通过个性化的模型来检测不同类型的服务异常（如性能异常、可靠性异常、流量异常）。为了提高异常检测的效率，在异常传播链分析的过程中，MicroHECL 采用了剪枝策略来消除不相关的服务调用。最后，通过实验研究，证明了 MicroHECL 在可用性问题异常检测的准确性和效率方面都显著优于两种先进的基线方法。MicroHECL 已经在阿里巴巴内部落地实践，截止 2020 年 7 月，实际 top-3 的命中率达到了 68%，根因定位的时间从原来的 30 分钟缩短到了 5 分钟。

研究背景

微服务架构已经成为构建云原生应用的最新趋势，越来越多的公司选择从单体系统迁移到微服务架构。工业微服务系统通常包含成百上千的应用，这些系统是高度动态和复杂的，一个服务可以有几个到几千个实例运行在不同的容器和服务器上，而可用性问题一直是大规模微服务系统面临的一个关键挑战。在这些系统中，服务质量（如性能、可靠性）的任何异常都有可能沿着服务调用链传播，并最终导致业务级别的可用性问题（如订单成功率下跌），这也是企业普遍碰到的问题。当监控系统监控到可用性问题时，它的根因服务和异常类型需要在短时间（如 3 分钟）内定位，以便开发人员快速解决问题。

阿里巴巴的电子商务系统每月活跃用户超过 8.46 亿人，它采用微服务架构，并且包含超过 3 万多个服务，这些服务都配备了一个称为 EagleEye 的大型监控基础设施。作为业务的载体，系统需要保证高可用。因此这些系统都部署了一个业务监控平台来及时的发出可用性问题报警。这些可用性问题通常表示业务运行中的问题，例如下单成功量下跌、交易成功率下跌等。这些可用性问题可能是由不同类型的异常引起的，异常可能从一个服务传播到另一个服务，最终导致可用性问题。在本文中，我们重点关注以下三种导致阿里巴巴大部分可用性问题的异常类型：

  1. 性能异常。性能异常表现为响应时间（RT）的异常增加。它通常是由有问题的系统实现或不正确的环境配置（例如容器或虚拟机的 CPU/内存配置）引起的。
  2. 可靠性异常。可靠性异常表现为错误数量（EC）的异常增加，例如服务调用失败的次数。它通常由代码缺陷或环境故障（例如服务器或网络中断）引起的异常。
  3. 流量异常。流量异常表现为每秒异常增加或减少的查询数量（QPS）。流量的异常增加可能会导致服务中断，而异常流量的减少可能表明许多请求无法到达服务。它通常是由不正确的流量配置（例如 Nginx 的限流）、DoS 攻击或意外的压测等引起。

相关研究

现有的方法不能有效的支持大规模微服务系统可用性问题根因定位，业界开发人员通常还需要依赖可视化工具来分析日志和链路，以识别可能的异常和异常传播链路，从而找到根本原因。研究人员已经提出了使用链路分析或服务依赖图的方法来自动定位微服务或更广泛的基于服务的系统的异常根因。基于链路分析的方法需要昂贵的链路数据收集和处理，因此不能有效的用于大规模系统。基于服务依赖图的方法是基于服务调用或因果关系来构造服务依赖图。这些方法通过遍历服务依赖图并用服务的指标数据（如响应时间）检测可能的异常来定位根因，然而这些方法由于对服务异常检测的不准确以及对服务依赖图的低效遍历而使用受限，尤其是在有很多服务和依赖关系的大规模微服务系统中。

方法概述

MicroHECL 是一种解决可用性问题的高效的根因定位方法。在我们的场景中，可用性问题通常是从业务视角观测到的。例如，订单成功量下跌，它可能是由不同类型的异常引起的。目前 MicroHECL 支持三种类型的异常（即性能异常、可靠性异常、流量异常）。在定位特定类型的异常时，MicroHECL 考虑相应的服务调用指标以及异常的传播方向。例如，在定位性能异常时，MicroHECL 会主要考虑服务间调用的响应时间和异常传播方向（即从下游向上游传播）。MicroHECL 的方法概述如图 1 所示，主要包括以下三个部分。

MicroHECL 概述

服务依赖图构建

当运行时的监控系统检测到可用性问题时，MicroHECL 将启动根因分析过程。它基于运行时监控系统采集到的服务调用关系和指标，动态的构建一定时间窗口（例如最近 30 分钟）内的目标微服务系统的服务调用图。服务调用图是由一系列的服务节点 S={S1, S2,…, Sn}组成，每一个节点都代表了该服务在最近 30 分钟内发生过调用关系。边 Si–>Sj 代表了在最近一个时间窗口内服务 Si 调用过服务 Sj。为了对可用性问题进行根因分析，服务调用图上还记录了各种度量指标，例如响应时间（RT）、错误数量（EC）和每秒请求数（QPS），这些监控到的数据都被存储到了时间序列数据库（TSDB）。为了优化性能，服务调用关系是随着异常调用链分析的过程按需并增量构建的，只有在异常传播链分析过程中，到达了某个服务，才会去拉取与它相关的指标数据。

异常传播链分析

一个可用性问题最初是在某个服务（称为初始异常服务）上由监控系统发现的，但是异常的根因往往是它的上游或下游服务。根因服务和初始异常服务通常都处于由一系列的异常服务组成的异常传播链上。异常传播链分析的目的就是通过分析初始异常服务中可能的异常传播链来确定一组候选的异常根因服务，在分析的过程中，会沿着异常传播的相反方向。为了提高效率，MicroHECL 采用了一种剪枝策略来消除和当前异常传播链不相关的服务调用。通过异常传播链的分析，最终可以得到一系列的候选异常根因服务。

候选根因排序

MicroHECL 根据导致给定可用性问题的可能性对候选根因进行排序。通过对监测数据的分析，我们发现初始异常服务的异常指标数据与根因服务的异常指标有相似的变化趋势。注意这里初始异常服务的指标是某种业务指标（例如：订单成功量），而候选根因的异常指标是质量指标（如 RT、EC、QPS）。因此我们使用皮尔逊相关性系数对这两个异常指标X,YX, Y 的变化趋势进行相关性分析，并基于相关性值P(X，Y)P(X，Y)进行候选根因的排序。

P(X,Y)=∑i=1n(Xi−Xˉ)(Yi−Yˉ))∑i=1n(Xi−Xˉ)2∑i=1n(Yi−Yˉ)2P(X, Y)=\frac{\left.\sum_{i=1}^{n}\left(X_{i}-\bar{X}\right)\left(Y_{i}-\bar{Y}\right)\right)}{\sqrt{\sum_{i=1}^{n}\left(X_{i}-\bar{X}\right)^{2} \sum_{i=1}^{n}\left(Y_{i}-\bar{Y}\right)^{2}}}

异常传播链分析

分析过程

可用性问题可能是由不同类型的异常引起的。对于不同的异常类型，服务异常检测中考虑的指标和传播链分析中考虑的异常传播方向是不同的。如表 1 所示，性能异常、可靠性异常和流量异常考虑的主要指标分别是响应时间（RT）、错误数量（EC）和每秒请求数（QPS）。通常性能异常和可靠性异常的传播方向都是从下游到上游的，而流量异常的传播方向是从上游到下游的。

可用性问题的指标和异常传播方向
  1. 入口节点异常检测

初始异常服务视为异常检测的入口节点。MicroHECL 根据不同的异常类型和相应的指标数据，对入口节点相邻的节点（即直接调用入口节点或被入口节点直接调用的服务）进行服务异常检测。对于每个被检测到的相邻异常节点，如果其与入口节点的上下游关系与检测到的异常类型的异常传播方向一致，则从其开始进行异常传播链的分析，并将检测到的异常类型作为异常传播链的异常类型。例如，对于图中的入口节点 S5，检测到两个相邻的异常节点为 S4 和 S7，并且它们的异常类型分别是流量异常和性能异常。由于 S4 是 S5 的上游节点，其与流量异常的传播方向一致（ 从上游到下游），因此从 S4 开始进行业务异常的传播链分析。同样，性能异常的传播链分析是从 S7 开始的。

异常传播链路分析过程
  1. 异常传播链路扩展

对于每个异常传播链，通过从起始节点（即检测到的初始异常服务的相邻异常节点）沿着异常传播方向进行迭代扩展。在每次迭代中，根据异常类型对当前节点的上下游节点进行异常检测，并将检测到的异常节点添加到当前异常传播链中。当不能向链中添加更多节点时，异常传播链的扩展结束。例如，对于 S4 的异常传播链，扩展以 S1 结束，S1 是 S4 的上游节点并且符合流量异常的传播方向。相似的，对于 S7 的异常传播链，扩展以 S9 和 S10 结束。

  1. 候选根因排序

当初始异常服务的所有异常传播链分析结束时，将异常传播链扩展结束位置的所有服务作为候选的根因服务。例如，图中所示的分析过程得出的候选根因包括 S1、S9 和 S10。

服务异常检测

在异常传播链分析过程中，我们需要根据一些指标数据不断的检测一个服务是否存在某种类型的异常。例如，在图 2 中，通过入口节点异常检测，我们首先确定了 S4 和 S7，然后通过服务异常检测在异常传播链扩展中识别出异常服务 S1、S9、S10。根据不同的指标的特点，我们为每种异常类型选择了不同的分析模型，这些分析模型是根据相应指标类型的波动特征和指标之间的关系设计的。

不同时段的指标波动

性能异常检测

性能异常检测是基于异常增加的响应时间（RT），这里的挑战是如何区分 RT 的异常波动和正常波动。图 3(a) 和图 3(d) 分别显示了两个小时和一周的响应时间波动。从中可以看出，在一天的不同时间段和一周的不同日子里，RT 都有周期性的波动。如果我们使用像 3-sigma 这样的简单规则，这些周期性波动很可能会被认为是性能异常。为了识别异常波动，我们不仅考虑了当前时间段的指标，还需要考虑前一天的同一时间段和前一周的同一时间段的指标。而且，在历史数据中，响应时间大多数处于正常波动状态，只有少量的异常波动。

基于 RT 数据的特点，我们选择了 OC-SVM（one class support vector machine）作为 RT 异常波动的预测模型。OC-SVM 仅使用特定类别（正常 RT 波动）的信息来学习出一个分类器，该分类器可以识别出属于该类别的样本，并将其他样本识别为异常值（异常 RT 波动）。OC-SVM 具有建模简单、可解释性强、泛化能力强等优点。我们为模型定义了以下 4 种特征：

  • Number of Over-Max Values: 当前检测窗口中 Response Time 的值大于给定比较时间窗口内 Response Time 的最大值的数量。

  • Delta of Maximum Values: 当前检测窗口中 Response Time 的最大值与给定比较时间窗口内的 Response Time 最大值的差值。

  • Number of Over-Average Values: 当前检测时间窗口中超过给定比较时间窗口中 Response Time 滑动平均值最大值的数量。

  • Ratio of Average Values: 当前检测窗口中 Response Time 的平均值与给定时间窗口内 Response Time 的滑动平均值的最大值的比值。

我们把最后 10 分钟作为异常检测的时间窗口。对于对比的时间段，我们考虑以下三种：当前检测窗口之前的最后一小时，前一天相同的时间段，前一周同一天的相同时间段。因此，我们一共可以得到 12 个特征值。

为了训练模型，我们在阿里巴巴的监控系统中从不同的系统收集到了 100000 个案例。我们也收集了 600 个正负比例 1:1 的案例用于模型的验证。模型训练结果如表 2 所示。

性能异常的模型训练效果

可靠性异常检测

可靠性异常检测是基于异常增加的错误数量（EC）。如图 3(b) 和图 3(e) 所示，EC 的值大多数时候都是 0，但在某些情况下，即使某些服务出现一些错误，但是由于对业务没有造成影响，服务可能会在短时间内恢复正常。例如，当断路器断开时，服务调用失败并引发错误数量上涨，但在系统负载降低和断路器闭合后，服务将很快恢复正常。因此，我们不能使用性能异常检测模型来检测可靠性异常，一些二分类模型（如逻辑回归（LR）或随机森林（RF）可以被使用。然而，由于线上只搜集到少量的可靠性异常的案例，LR 模型很可能会过拟合。

根据 EC 的特点，我们选择了 RF 作为 EC 异常波动的预测模型。RF 使用多个决策树进行分类，可以有效的结合多种特征，避免过拟合。我们为模型定义了以下五种特征。请注意，有些特征结合了其它指标（例如 RT、QPS），因为 EC 的异常增加经常与 RT 和 QPS 相关。

  • Previous Day Delta Outlier Value：计算最近一小时的 Error Count 值和前一天同一时间段的 Error Count 值的增量；使用 3Sigma 规则识别当前检测窗口中可能存在的增量异常值；如果存在，则返回异常值的平均值作为特征值，否则返回 0。

  • Previous Minute Delta Outlier Value： 计算最近一小时内 Error Count 值和每一个值的前一分钟 Error Count 值的增量；使用 3Sigma 规则识别当前检测窗口中可能存在的增量异常值；如果存在，则返回异常值的平均值作为特征值，否则返回 0。

  • Response Time Over Threshold： 检测窗口内的平均响应时间是否大于设定的阈值（例如，在本文的线上系统中，阈值设置为 50ms）。

  • Maximum Error Rate：当前检测窗口内最大错误率（通过 Error Count 和 QPS 计算得到）。

  • Correlation with Response Time：Response Time 和 Error Count 在检测时间窗口内的皮尔逊相关性值。

与性能异常检测类似，我们把最后 10 分钟作为异常检测的时间窗口。为了训练模型，我们同样搜集了线上 1000 个打标的可靠性异常案例，其中正负比例 1：3。我们也搜集了 400 个案例用于验证模型的训练效果，其中正负比例 5:3。模型训练结果如表 3 所示。

可靠性异常的模型训练效果

流量异常检测

流量异常检测是基于 QPS 的异常波动。如图 3© 和图 3(f) 所示，QPS 从短期和长期来看是比较符合正态分布特点的。因此，我们选择使用 3-sigma 规则来检测异常的 QPS 波动。同样采用最后 10 分钟作为异常检测的时间窗口，并基于最近一个小时的 QPS 值，我们使用 3-sigma 规则来检测当前检测窗口中的异常值。

此外，经过观察发现，单纯使用 3-sigma 仍然会存在一定的误报行为。为了进一步消除误报，我们还计算了这些异常服务的 QPS 值和初始异常服务的业务指标之间的皮尔逊相关性系数，只有当相关性高于预定义的阈值（例如 0.9）并且在当前检测窗口中识别出 3-sigma 异常值，才会认为当前服务存在流量异常。

剪枝策略

异常传播链路可能具有多个分支，并且分支的数量可以在异常传播链扩展期间继续增长。因此，异常传播链分析的一个主要挑战在于大规模服务依赖图上异常传播分支的数量可能成指数增长。而在这些分支中，一些异常服务和服务调用可能与当前可用性异常问题无关。为了解决这一问题，提高分析效率，我们采用剪枝策略来消除不相关的异常服务调用。剪枝策略是基于假设异常传播链中两个连续的服务调用的边具有相似的指标变化趋势。例如，在图 2 中，边 S1 -> S4 上的 QPS 应该和边 S4->S5 上的 QPS 具有相似的变化趋势，否则 S1->S4 这条边就应该被剪枝。类似的，S7->S9 边上的 RT 的指标变化应该和边 S5->S7 上 RT 的指标变化具有相似的趋势。

检测策略在异常传播链分析的扩展过程中被使用，我们只考虑相邻两条边上相同异常类型的指标数据（例如 RT、EC、QPS）在最近一个时间窗口（例如，最近 60 分钟）内的相似性。相似性的计算使用公式 1。如果相似度值低于阈值（如 0.7），那么当前异常边会被剪枝掉。

实验评估

为了评估 MicroHECL 的有效性和效率，我们进行了一系列的实验研究来回答下面三个研究问题：

  1. RQ1（定位精确度）：MicroHECL 在定位微服务系统的可用性问题的根因和特定异常类型的根因方面精确度如何？
  2. RQ2（定位效率）：MicroHECL 在根因定位过程中随着服务数量的增加，定位效率和可扩展性会有怎样的变化？
  3. RQ3（剪枝效果）：MicroHECL 在不同的相似度阈值下对定位的精确度和效率有何影响？

实验设置

从 2020 年 2 月到 6 月，我们在阿里巴巴的大型电子商务系统的 28 个子系统中收集了 75 个可用性问题异常案例，这些子系统平均包含 265（最小 7，最大 1687，中位数 82）个服务。在这 75 个可用性问题案例中，有 37 个是由性能异常导致，有 43 个是由可靠性问题导致，有 21 个是由流量异常导致。我们把 MicroHECL 与其它两种基线方法（MonitorRank、Microscope）进行了实验对比，并使用公式 2 中 HR@k 和 MRR 来评估方法根因定位的精确度。

定位精确度（RQ1）

表 4 显示了 MicroHECL 和其它两种基线方法的总体精确度评估结果，可以看出 MicroHECL 在 HR@1、HR@3 和 HR@5 的命中率分别为 0.48、0.67 和 0.72，MRR 为 0.58。在所有这些指标方面，MicroHECL 都显著优于基线方法。

总体准确度评估

我们还评估了 MicroHECL 在不同异常类型方面的精确度。从表 5 可以看出，MicroHECL 在这三种异常类型方面都优于基线方法。而且可以看出 MicroHECL 在性能异常方面的优势最为显著，在流量异常方面的优势不太显著。

不同异常类型的准确度

定位效率（RQ2）

本文中的 75 个可用性问题异常案例来自 28 个子系统，这些子系统有不同的服务数量。为了评估 MicroHECL 的效率和可扩展性，我们在这 75 个案例中分析了 MicroHECL 和两种基线方法的异常检测时间。并研究了异常检测的时间如何随目标系统的大小（服务数量）而变化，实验结果如图。请注意，从同一个子系统中收集的可用性问题可能有多个，每个可用性问题在图中都用一个点表示。总体来说，MicroHECL 的执行时间比 Microscope 少 22.3%，比 MonitorRank 少了 31.7%。在这三种方法中，对于不同大小的子系统和大多数的可用性问题，MicroHECL 使用的时间都是最少的。

图中的两条曲线分别显示了 MicroHECL 相对于两种基线方法平均时间差的变化。可以看出，当服务数量小于 250 个时，MicroHECL 的优势并不显著；当服务数量超过 250 个时，MicroHECL 的优势随着服务数量的增加而越来越显著。此外，MicroHECL（包括两种基线方法）的执行时间随着服务数量的增加而线性增加，表现出良好的可扩展性。

检测时间随服务节点数量的变化

剪枝效果（RQ3）

剪枝策略是影响根因定位精确度和效率的关键。本文通过分析 75 个可用性问题的根因定位的精确度和时间消耗随不同的相似度阈值的变化来评价剪枝策略的效果， 并选择 HR@3 作为精确度的评估指标。评估结果如图 5 所示，从中可以看出，随着阈值的增加，精确度和时间都会有所下降。而且当阈值从 0 增加到 0.7 时，精确度保持在 0.67，而时间从 75 秒减少到了 46 秒。实验结果验证了剪枝策略在保证精确度的前提下，显著提高异常定位效率的有效性，并且对于这些可用性案例，最佳相似度阈值为 0.7。

剪枝策略的效果评估

企业实践

MicroHECL 已经实现为一个基于 EagleEye 和其它监控基础设施的分布式系统在阿里巴巴部署运行。在实际应用中，MicroHECL 还支持更细粒度的故障定位，比如将中间件（数据库，消息队列，缓存服务）等作为定位的目标，这些组件和交互的指标数据也会被记录到服务调用图上。在过去的 5 个多月里，MicroHECL 处理了超过 600 个可用性问题，平均可以在 76s 产出定位结果，开发人员通常可以在监控系统检测到可用性问题后 5 分钟内确认并开始故障修复。来自开发人员的反馈表明，大多数开发人员都比较信任系统的推荐，默认会把推荐的结果作为异常的根因。

在实际应用中，除了一些系统因指标数据缺失导致无法准确定位之外，我们还分析了 MicroHECL 不能准确定位其它异常根因的案例，发现 MicroHECL 仍需要从多方面进行改进。例如，一些可用性异常被检测到后，它的服务质量指标可能没有任何异常。而且有一些异常可能是慢慢积累起来的，它的指标波动可能超过了异常监测的时间窗口。这些需要更先进的技术来改进目前的方法。

总结

本文针对微服务系统的可用性问题，提出了一种高效的根因定位方法 MicroHECL, 它通过动态构造服务调用图并分析可能的异常传播链路。与现有方法不同，MicroHECL 使用基于机器学习和统计方法的个性化模型来检测不同类型的服务异常（即性能异常、可靠性异常、流量异常），并在异常传播链分析中采用剪枝策略来消除不相关的服务调用。 实验研究和阿里巴巴的实际应用都证实了 MicroHECL 的精确度和有效性，未来我们也会在云效上提供风险预测定位的能力。

以上内容摘抄自：云效故障定位研究论文被 ICSE 2021 SEIP track 收录，本文仅是记录！！！

联系作者