云效故障定位研究论文被ICSE 2021 SEIP track收录

近期，由阿里云云效团队联合复旦大学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所示，主要包括以下三个部分。

图1. MicroHECL概述

服务依赖图构建

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

异常传播链分析

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

候选根因排序

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

            公式1. 皮尔逊相关性系数计算公式

异常传播链分析

分析过程

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

表1. 可用性问题的指标和异常传播方向

1、入口节点异常检测

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

图2. 异常传播链路分析过程

2、异常传播链路扩展

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

3、候选根因排序

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

服务异常检测

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

图3. 不同时段的指标波动

1、性能异常检测

性能异常检测是基于异常增加的响应时间（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种特征：

1. Number of Over-Max Values: 当前检测窗口中Response Time的值大于给定比较时间窗口内Response Time的最大值的数量。
2. Delta of Maximum Values: 当前检测窗口中Response Time的最大值与给定比较时间窗口内的Response Time最大值的差值。
3. Number of Over-Average Values: 当前检测时间窗口中超过给定比较时间窗口中Response Time滑动平均值最大值的数量。
4. Ratio of Average Values: 当前检测窗口中Response Time的平均值与给定时间窗口内Response Time的滑动平均值的最大值的比值。

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

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

表2. 性能异常的模型训练效果

2、可靠性异常检测

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

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

1. Previous Day Delta Outlier Value：计算最近一小时的Error Count值和前一天同一时间段的Error Count值的增量；使用3Sigma规则识别当前检测窗口中可能存在的增量异常值；如果存在，则返回异常值的平均值作为特征值，否则返回0。
2. Previous Minute Delta Outlier Value： 计算最近一小时内Error Count值和每一个值的前一分钟Error Count值的增量；使用3Sigma规则识别当前检测窗口中可能存在的增量异常值；如果存在，则返回异常值的平均值作为特征值，否则返回0。
3. Response Time Over Threshold： 检测窗口内的平均响应时间是否大于设定的阈值（例如，在本文的线上系统中，阈值设置为50ms）。
4. Maximum Error Rate：当前检测窗口内最大错误率（通过Error Count和QPS计算得到）。
5. Correlation with Response Time：Response Time和Error Count在检测时间窗口内的皮尔逊相关性值。

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

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

3、流量异常检测

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

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

剪枝策略

异常传播链路可能具有多个分支，并且分支的数量可以在异常传播链扩展期间继续增长。因此，异常传播链分析的一个主要挑战在于大规模服务依赖图上异常传播分支的数量可能成指数增长。而在这些分支中，一些异常服务和服务调用可能与当前可用性异常问题无关。为了解决这一问题，提高分析效率，我们采用剪枝策略来消除不相关的异常服务调用。剪枝策略是基于假设异常传播链中两个连续的服务调用的边具有相似的指标变化趋势。例如，在图2中，边S_{1 ^->} S₄上的QPS应该和边S₄->S₅上的QPS具有相似的变化趋势，否则S₁->S₄这条边就应该被剪枝。类似的，S₇->S₉边上的RT的指标变化应该和边S₅->S₇上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来评估方法根因定位的精确度。

公式2. HR@k与MRR的计算公式

定位精确度（RQ1）

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

表4. 总体准确度评估

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

表5. 不同异常类型的准确度

定位效率（RQ2）

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

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

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

剪枝效果（RQ3）

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

图5. 剪枝策略的效果评估

企业实践

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

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

总结

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

题目：MicroHECL: High-Efficient Root Cause Localization in Large-Scale Microservice Systems

作者：Dewei Liu(Fudan University) Chuan He(Fudan University)  Xin Peng(Fudan University)  Fan Lin(Alibaba Group)  Chenxi Zhang(Fudan University)  Shengfang Gong(Alibaba Group)  Ziang Li(Alibaba Group) Jiayu Ou（Alibaba Group） Zheshun Wu(Alibaba Group)。论文下载地址待正式发表后公布，请持续关注，敬请期待！

点击了解更多云效