近期，由阿里云云效团队联结复旦大学 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 将启动根因剖析过程。它基于运行时监控零碎采集到的服务调用关系和指标，动静的构建肯定工夫窗口（例如最近 30 分钟）内的指标微服务零碎的服务调用图。服务调用图是由一系列的服务节点 S ={S1, S2,…, Sn}组成，每一个节点都代表了该服务在最近 30 分钟内产生过调用关系。边 Si–>Sj 代表了在最近一个工夫窗口内服务 Si 调用过服务 Sj。为了对可用性问题进行根因剖析，服务调用图上还记录了各种度量指标，例如响应工夫（RT）、谬误数量（EC）和每秒申请数（QPS），这些监控到的数据都被存储到了工夫序列数据库（TSDB）。为了优化性能，服务调用关系是随着异样调用链分析的过程按需并增量构建的，只有在异样流传链分析过程中，达到了某个服务，才会去拉取与它相干的指标数据。

异样流传链分析

一个可用性问题最后是在某个服务（称为初始异样服务）上由监控零碎发现的，然而异样的根因往往是它的上游或上游服务。根因服务和初始异样服务通常都处于由一系列的异样服务组成的异样流传链上。异样流传链分析的目标就是通过剖析初始异样服务中可能的异样流传链来确定一组候选的异样根因服务，在剖析的过程中，会沿着异样流传的相同方向。为了提高效率，MicroHECL 采纳了一种剪枝策略来打消和以后异样流传链不相干的服务调用。通过异样流传链的剖析，最终能够失去一系列的候选异样根因服务。

候选根因排序

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

异样流传链分析

剖析过程

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

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

2、异样流传链路扩大

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

3、候选根因排序

当初始异样服务的所有异样流传链分析完结时，将异样流传链扩大完结地位的所有服务作为候选的根因服务。例如，图中所示的剖析过程得出的候选根因包含 S1、S9 和 S10。

服务异样检测

在异样流传链分析过程中，咱们须要依据一些指标数据一直的检测一个服务是否存在某种类型的异样。例如，在图 2 中，通过入口节点异样检测，咱们首先确定了 S4 和 S7，而后通过服务异样检测在异样流传链扩大中辨认出异样服务 S1、S9、S10。依据不同的指标的特点，咱们为每种异样类型抉择了不同的分析模型，这些分析模型是依据相应指标类型的稳定特色和指标之间的关系设计的。

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. 性能异样的模型训练成果

3、流量异样检测

流量异样检测是基于 QPS 的异样稳定。如图 3(c)和图 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 都显著优于基线办法。

表 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（包含两种基线办法）的执行工夫随着服务数量的减少而线性减少，体现出良好的可扩展性。

剪枝成果（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 的精确度和有效性，将来咱们也会在云效上提供危险预测定位的能力。

作者：Yvonne
原文链接
本文为阿里云原创内容，未经容许不得转载