微服务架构下的根因定位方法综述

李思毅，马诗雨，崔丽月，张圣林，孙永谦，张玉志

南开大学，软件学院，天津 300350

引 言

在移动互联网背景下，互联网等行业业务更新迭代速度加快，需求研发周期大大缩短，线上应用变更十分频繁。与此同时，新冠疫情加速了传统行业线上化和数字化转型，超大规模云平台作为关键基础设施，为我国经济转型升级提供了重要支撑，已广泛应用于电信、互联网、金融、政府、电力等多个行业，但这些行业线上业务体量庞大、监管严格、对异常容忍度极低[1]。随着互联网技术的发展和各行业业务的多元化需求，将会有越来越多的传统行业在数字化转型和上云过程中采用云原生架构[2]，将原本的单体应用拆分成数百个微服务[3]应用，每个微服务应用部署到上千个容器实例上。一个微服务应用可以同时为多个业务链路提供服务，因此微服务应用之间存在复杂的调用关系。当一个微服务应用出现异常时，它将影响调用链路下游的多个微服务应用，最终影响整个业务链路的成功率。例如，对于金融行业实现合约签订、信用审核等微服务应用会被其他应用高频次调用。当这类微服务应用出现异常时，异常会扩散至多个微服务应用，形成告警风暴，单纯依赖人工故障定位很难满足电信、互联网、金融、政府、电力等行业对于系统稳定性的要求，而对于这些行业来说，极短时间的故障也会产生巨大资损，给国家造成重大损失。因此，依赖费时费力、无法扩展的人工方式故障应急是不可行的。

鉴于此，本文总结了面向微服务架构的根因定位方法，探索在微服务架构下系统发生异常后自动、准确地定位引起异常的根因事件或异常组件，缩短异常修复时间，提高云上系统稳定性。

1 研究背景及意义

1.1 微服务架构

微服务指将大型的单体软件应用拆分成多个简单应用，每个简单应用描述一个细分业务或功能，系统中各个简单应用可被独立部署，且各个应用之间松耦合以实现系统的持续快速交付和运维[4]。微服务架构与传统的单体架构相比，旨在通过将功能分解到各个离散的服务中，实现单个系统复杂度和耦合性降低，通过系统之间的轻量级通信机制实现相互协作，具有更细粒度的独立部署、独立扩展、跨语言编程等特点。微服务架构在带来灵活性、开发敏捷性的同时也带来了运维层面的挑战，随着应用服务数量的增加，微服务之间的通信、部署依赖、数据一致性、监控以及安全性的管理成为新的挑战。

云原生技术是基于微服务架构思想、以容器技术为载体的一种产品研发运营的全新模式。云原生技术是各行业在公有云、私有云或混合云中构建和运行可弹性扩展的应用的核心技术。云原生的代表技术包括服务网格（Service Mesh）[5]、基于Kubernetes[6]的容器技术、微服务、不可变基础设施和声明式API。

综上，基于微服务架构的云原生系统将是未来一段时间各行业数字化转型过程中技术上主要的发展趋势。

1.2 微服务架构的运维

1.2.1 监控指标

监控中台是微服务架构下的核心系统之一，面向微服务场景下的全功能监控中台包含关键业务链路监控、应用监控、基础设施监控和自定义监控等功能，为系统监控报警以及后续运维操作提供基础。监控中台关注的主要包含如下指标：

（1）业务指标：包括关键业务链路的成功率、失败数、平均耗时等描述业务稳定性的指标。

（2）系统指标：包括POD 容器、应用容器、Sidecar 容器等多个维度的指标，主要有：CPU、LOAD（负载）、MEM（内存）、下游请求信息、上游请求信息、磁盘水位等。

监控中台在整合监控数据的基础上，同时集成了监控指标的异常检测能力，并通过异常事件中心等功能展示给运维工程师。

图1 某金融系统交易成功量（业务指标）Fig.1 The number of successful transactions in the financial system (business indicator)

图2 云平台中某物理机CPU 使用量（系统指标）Fig.2 CPU usage of a physical machine in the cloud platform (system metrics)

1.2.2 CMDB

CMDB[7]的全称是configuration management database(配置管理数据库)。CMDB 是云上所有核心硬件、软件及其关联关系的逻辑体现。如图3所示，CMDB 保存了机房、机柜、网络位置、网络设备、服务器、应用、应用分组、云资源实例等实体的物理拓扑和云上拓扑关系。CMDB 保存的运维元数据是异常处理的关键依据。

图3 CMDB 中的实时拓扑关系Fig.3 Real-time topological relationships in CMDB

1.3 研究意义

当异常发生时，监控中台会根据已有的异常告警原则产生大量告警信息，短时间内产生的数量庞大的告警（告警风暴）给运维工程师异常处理带来了极大的挑战，在庞大的业务系统和海量的告警信息中迅速发现告警风暴背后的异常关联关系并锁定根因的难度非常大。本文调研了智能运维领域关于根因定位方法的相关文献，对微服务架构下基于图推理的根因定位方法进行总结，为大规模云平台的智能根因定位系统建设提供参考。

2 根因定位系统框架

在大规模云平台中，智能告警系统通过时间序列异常检测算法结合人工设置的指标异常检测规则实时监测系统状态，力求在最短时间内发现指标的异常情况。当系统发生异常，由于大型的网络、云平台内部设备众多，关联关系复杂，清晰的调用关系、设备与链接的相互连接关系是根因定位的重要基础。除了CMDB 提供的网络设备的物理拓扑之外，还存在指标间、协议间的关联关系。上述关联关系对异常的排查、止损与溯源起着至关重要的作用。根因定位系统在异常发生后基于相关运维元数据分析结合智能运维算法确定引发异常的根本原因。具体来讲，根因定位系统主要分为两个部分：系统首先通过关系学习方法构建异常指标、异常组件或异常事件之间的故障传播图，该图描述了异常发生时刻设备实体及其关键指标、告警状态间的关联关系或依赖关系。之后，根因定位系统通过图推理算法可以得出图中节点的根因可能性排名，取Top N 作为推荐根因输出。

3 根因定位方法综述

本章介绍微服务架构下用于构建故障传播图的关系学习方法和对故障传播图进行节点重要性排序实现推荐异常根因的相关算法。

3.1 关系学习方法

当微服务架构下的线上系统发生异常，由于大型的网络、云平台内部设备众多，关联关系复杂，清晰的调用关系、设备与链接的相互连接关系是根因定位的重要基础。除了网络设备的物理拓扑之外，还存在不同的指标、协议等关联关系。上述这些关联关系都对异常的排查、止损与溯源起着至关重要的作用。根据异常时段的关联关系构成的有向无环图（Directed Acyclic Graph,DAG）即为故障传播图。在故障传播图中，异常会沿着模块和设备间的依赖关系传播，导致更大范围的模块和设备的异常。

图4 微服务根因定位框架Fig.4 Root cause localization framework

由于实际生产环境多种多样，不同系统架构下构建出的故障传播图也各不相同。故障传播图按节点类型主要分为三类：以异常指标为节点的故障传播图、以异常组件为节点的故障传播图和以异常事件为节点的故障传播图。相同属性的节点多依赖算法挖掘和程序调用分析，不同属性的节点多依赖CMDB 提供的拓扑关系，综上，可以构建出描述异常发生时段内系统的故障传播图。

目前，已有的相关工作通过一些关系学习方法来构建故障传播图。关系学习方法主要有三种：系统信息构建、算法自动学习和两者相结合。这一节将分别介绍三种关系学习方法。

3.1.1 系统信息

基于系统信息构建的故障传播图如图5所示，根据系统设备、模块之间明确的的部署、依赖、调用关系等系统信息可以直接构建故障传播图，其中节点为异常性能指标对应的系统设备、模块，边为上述节点之间的部署、依赖、调用关系。这里的系统信息主要包括静态的物理设备之间的部署关系（通过CMDB 获取）以及动态的实时系统模块之间的调用关系。通过配置数据采集模块、日志分析工具、程序调用分析工具等手段获取系统模块之间的实时调用信息。

图5 以异常组件为节点的故障传播图示例Fig.5 A example of a fault propagation graph with anomalous components as nodes

根据系统信息可以直接构建故障传播图，但在实际的生产环境中，收集额外的系统数据需要更改线上Web 服务的架构。由于更改线上系统架构十分困难，所以基于系统信息的构图方法难以应用。

3.1.2 算法自动学习

采用算法自动学习的方法构建故障传播图的原理是通过对监控指标数据的学习，按需提取监控指标之间的依赖关系，以确定故障传播图中的异常节点及其关联关系。其中，节点为监控指标，边为挖掘出的指标之间的依赖关系。

目前相关工作中最常用的思路为通过PC 算法[8]自动构建监控指标之间的依赖关系来构建故障传播图。PC 算法主要分为两步。首先，通过检验条件独立性确定节点间的依赖关系，生成一个无向图以构建骨架（skeleton）。PC 算法把上述过程转化为d 分隔（d-separation）问题，采用了Fisher Z Test 作为条件独立性检验方法对任意两个节点进行条件独立性检验以判断d 分隔。然后，利用d 分隔的原理来确定图中边的依赖方向，把无向图扩展为有向无环图[8]。

除PC 算法之外，也可以通过相关性分析方法挖掘监控指标数据之间的依赖关系从而构建故障传播图。然而，在生产环境中可能存在一些难以观察和推导的隐变量，监控指标数据和告警信息也可能存在误报、漏报以及缺损，导致通过算法自动学习到的故障传播图准确度有限。

3.1.3 两者结合

为了构建更完整、更准确的故障传播图，也有一些相关工作将系统信息和自动学习方法结合使用。

首先结合系统架构的物理拓扑关系和系统模块之间的实时调用关系等系统信息构造系统模块之间的故障传播图，通过PC 算法或者相关性分析方法挖掘单个系统模块节点上不同监控指标之间的因果关系，最后通过结合构造的系统模块之间的故障传播图和单个系统模块节点上的监控指标之间的因果图得到一个完整的全局故障传播图。

3.2 根因定位方法

3.1 中的故障传播图描述了系统异常时刻关键异常节点的关联关系，依据故障传播图提供的节点类型、异常指标、拓扑关系等信息，对图中节点进行重要性排序，排序结果可以作为本次异常事件的根因推荐，本章节将对相关算法进行介绍。

3.2.1 深度优先搜索

深度优先搜索算法[9]（Depth-First-Search，简称DFS）是一种用于遍历或搜索树或图的算法。DFS会尽可能深地搜索树的分支。当节点的所在边都已被探寻过，搜索将回溯到发现节点的那条边的起始节点。这一过程一直进行到已发现从源节点可达的所有节点为止。在根因定位领域，根据上述关系学习方法获取的故障传播图表示了异常的传播过程，因此对其进行深度优先搜索是获得此次异常根因的方法之一。

3.2.2 皮尔森相关系数

在统计学中，皮尔森相关系数[10]（Pearson correlation coefficient）用于度量两个变量和之间的相关程度（线性相关）。两个变量之间的皮尔森相关系数定义为两个变量的协方差除以它们标准差的乘积，其值介于-1 与1 之间。

由于各种监控都是以时间序列的形式存在，因此对于两个异常的系统组件，可以分别选取其异常发生及前一段时间的监控指标，计算两个时间序列的皮尔森相关系数，表示异常组件的异常关联强度。

3.2.3 PageRank 算法

PageRank 算法[11]是Google 公司所使用的对其搜索引擎搜索结果中的网页进行排名的一种算法。其本质是一种以节点之间的连接个数和权值作为主要因素粗略地分析故障传播图中节点重要性的算法。

对于故障传播图中某个节点pi，其PageRank 值的计算公式如下：

一般情况下，云原生场景下的故障传播图是有向无环图，因此对于已知的故障传播图可以通过PageRank 算法计算图中节点的重要程度。有向无环图中节点的重要性排名也可以作为各节点对该异常的影响排名。

3.2.4 随机游走算法

随机游走[12]（Random Walk，缩写为 RW）是一种数学统计模型，它由一连串的轨迹所组成。在原生随机游走算法中，每一次游走的方向都是随机的。可以借鉴其原理，设计故障传播图的游走策略并生成概率转移矩阵。每一次游走因子从当前节点向更有可能是异常根因的节点转移或继续留在当前节点，重复此步骤上万次，并记录游走轨迹。基于故障传播图中每个节点被访问的次数对节点进行排序，结果可作为各节点对异常的贡献度排名，从而确定异常根因。随机游走算法分为一阶随机游走和二阶随机游走。一阶随机游走是指假设下一个要访问的节点只依赖于当前节点（马尔科夫性），其缺点是无法捕获高阶依赖关系。一阶随机游走根据最后一个顶点的状态选择下一个顶点，它的转移概率的计算方式为：

二阶随机游走在访问下一个节点时依赖于当前节点和当前节点的前一个节点。因此，二阶随机游走建立了高阶依赖关系，提高了应用的精度。二阶随机游走是根据最后两个顶点和的状态选择下一个顶点，转移概率是

4 根因定位方法应用

本章节介绍上述关系学习方法和基于图推理的根因分析方法的实践。

MonitorRank[13]首先通过收集微服务应用上配置的传感器记录微服务之间的调用关系，然后根据异常时间段的调用关系来构建故障传播图。其基本思想是：故障传播图的指标m和异常前端节点（负责接收用户的请求以及进一步调用下游请求以完成用户的请求的微服务）的指标的相关性表示了该节点是根因的可能性。为避免非根因节点和异常前端节点的指标有较高的相关性，需要分别考虑指标之间的相关性和服务节点之间的依赖关系。概率转移矩阵的设计是随机游走算法的关键，MonitorRank主要使用故障传播图中不同节点监控指标的相关性来生成转移概率。向量定义了每个节点和异常前端节点指标的相关性因此概率转移矩阵可以定义为在实际情况中，每个微服务节点的异常根因并非一定由其下游调用节点导致，也可能是其自身节点或上游节点导致。综上，MonitorRank 给出的转移概率为：

因此完整的概率转移矩阵的定义为：

MicroRCA[14]在构建故障传播图时同样依赖微服务应用间的调用关系。与MonitorRank 不同的是，MicroRCA 同时会考虑微服务应用在宿主机上的部署关系。因为在实际的运维异常处理场景中，当一台物理机宕机，的确会影响到该异常物理机上部署的全部微服务应用。MicroRCA 同样基于皮尔森相关系数计算不同节点之间的相关性，用作Personalized PageRank 算法[15]中的权值来推断异常根因。

与上述工作相似，TON18[16]通过OpenStack 开源云计算管理平台中的系统接口和PreciseTracer 程序调用分析工具构建模块之间的故障传播图，然后通过随机游走算法分析故障传播图实现根因定位。

MicroHECL[17]基于监控中台的服务调用关系和指标动态构建一定时间窗口内的目标微服务系统的故障传播图。故障传播图上除了表示各个服务节点之间的调用关系外，还记录了各种度量指标，例如响应时间（RT）、错误数量（EC）和每秒请求数（QPS）等信息。由于根因服务和初始异常服务通常都处于由一系列的异常服务组成的异常传播链上，MicroHECL 分析了所有可能的异常传播链路，并采用了剪枝策略来消除不相关的服务调用，从而得到候选异常根因服务集合。MicroHECL 认为初始异常服务的异常指标数据与根因服务的异常指标有相似的变化趋势，因此使用皮尔森相关性系数进行相关性分析，基于相关性值对候选异常根因服务进行排序。

表1 基于图推理的根因定位方法实践Table 1 Practice of abnormal diagnosis method based on graph reasoning

Groot[18]首先从初始告警或者可疑服务开始通过分布式执行轨迹和日志分析维护一个全局服务依赖图G，服务依赖图中的有向边表示服务调用或其他形式的依赖。然后Groot 将G中的每个服务对应的异常情况映射成异常事件，总结了该系统中的各种类型的指标、日志的异常行为。结合SRE 的领域知识构建事件之间的因果关系，形成基于事件的实时因果关系图。Groot 提出了改进的PageRank 算法GrootRank，使每条边都与加权传播的加权分数相关联，对于误报率高的警报，算法将其设置得较低。此外，由于叶子节点更可能是根本原因，GrootRank算法将个性化向量定制叶子节点和其余节点的分数，以增强叶子节点之间的传播。Groot 基于事件类型构建因果关系图有两个显著的优点：

（1）使用监控事件作为基本节点对比使用服务节点能够获得更准确的结果；

（2）因果关系图支持各种事件类型，例如性能指标、状态日志和系统变更等，并且允许SRE 和开发人员引入不同的异常事件类型，使得Groot 更加灵活，并支持更广泛的事件类型。

CloudRanger[19]提出了一种动态因果关系分析方法，能够在缺乏拓扑的情况下构建故障传播图，基于二阶随机游走的启发式搜索算法来识别根因服务。CloudRanger 首先基于PC 算法自动构建监控指标之间的故障传播图。之后，CloudRanger 利用二阶随机游走算法来识别根因服务。利用皮尔森相关性系数定义相关性特征以描述指标序列之间的相关性。给定一个服务集，以及对于任何一对服务定义指标数据矩阵，相关性，对与的相关性定义如下：

此外，CloudRanger 设置了两种额外的转换类型，即后向和自向，使算法能够找到更多的路线并使其随机游走更具启发性。假设表示已经被访问过的节点，是从当前服务到它的邻居的后向转移概率，受后向常数限制，后向转移概率计算如下：

给定故障传播图，CloudRanger 根据以上公式计算前向、后向、自我转移概率随机游走，记录每个服务节点的访问次数并将其降序排序输出为根因识别结果。

与CloudRanger 相似的是，MSRank[20]、Service-Rank[21]也通过自动构建监控指标之间的故障传播图去定位根因。它们首先利用PC 算法构造有向无环图表示监控指标间的依赖关系，然后使用不同的算法遍历生成的故障传播图实现根因定位。其中，MSRank 使用了二阶随机游走算法去定位根因，ServiceRank 使用皮尔森相关系数进行相关性分析以实现根因定位。

MicroCause[22]在上述工作的基础上提出一些改进。在PC 算法的基础上提出PCTS(Path Condition Time Series)算法构建监控指标间的依赖关系，使用TCORW(Temporal Cause Oriented Random Walk)算法去定位根因。当关键性能指标(Key Performance Indicator，简称KPI) 中检测到在线异常 时，MicroCause 将被激活。发生异常微服务在异常前数小时的监控指标数据将用作MicroCause 的输入。MicroCause 利用PCTS 算法用于生成该异常的故障传播图。使用改进的PC 算法用于学习时间序列的因果图。PCTS 算法假设，如果时间序列A 和时间序列B 在某个时间点中存在因果关系，那么在故障传播图中A 代表节点和B 代表节点间就会存在一条边。因此，因果关系最终会被合并转化为故障传播图。与此同时，异常检测模块检测输入数据集是否存在异常。故障传播图学习模块和异常检测模块可以并行处理。MicroCause 还设计了面向时间因果的随机游走（TCORW）。MicroCause 利用偏相关系数（Partial Correlation)来计算转移概率矩阵。与Pearson 相关性不同的是，和异常KPI 因果性更强的系统指标将具有更高的偏相关系数，而皮尔森相关性更注重两个指标之间的相关性，因此和异常KPI 因果性更强的系统指标将在随机游走中获得更高的访问次数。然后随机游走的结果和指标的异常程度对于异常的指标计算潜在根因得分，计算方式如下：

除PC 算法外，也有一些论文采用相关性分析的方法构建故障传播图。例如，BRCA[23]通过分析应用服务监控指标数据中的告警信息去构造故障传播图，然后通过基于故障传播图设计排序算法实现根因定位。

另外也有一些算法结合系统信息和自动学习方法以构建更完整的故障传播图。Microscope[24]首先通过PC 算法和网络IP 及端口信息构建了微服务内各子服务之间的故障传播图，然后通过一些预定义的规则去获取候选根因列表，并使用皮尔森相关性系数对候选根因排序。CauseInfer[25]通过不同服务节点之间的网络通信数据去构造服务节点之间的故障传播图，基于PC 算法去构造单个服务节点上不同监控指标之间的因果图，结合构造的服务节点之间的故障传播图和单个服务节点上的因果图，通过DFS算法搜索所有异常节点，并根据得分对根因进行排序输出。DFS 算法遍历得到的故障传播图，当某个异常节点无异常子节点，则判断此指标为根因指标。如果该节点指标正常，则对父节点指标进行异常检测，重复此步骤。由于存在多条因果路径，DFS 算法最终得到的是根因节点的集合。基于z-score 方法计算每个根因节点的得分，对其进行排序输出。计算公式如下，其中和是平均值和标准滑动窗口的偏差。

5 结论与展望

本文介绍了云原生架构下面临的运维挑战，总结了通用的微服务架构根因定位框架，分别介绍了基于指标、系统拓扑关系、异常告警等信息构造故障传播图，以及异常根因推理的方法。文中介绍的微服务架构根因定位方案有以下特点：

（1）通用性强：基于图推理的根因定位方法适用于云原生架构的多种类型异常。

（2）可解释性强：本文阐述的故障传播图的构建方案能够自动梳理告警风暴背后的逻辑关联，直观地将异常在系统中的传播关系展现给运维工程师，且故障传播图的构建依赖准确的系统拓扑结构和应用调用日志，因此具有很强的可解释性。

（3）自适应且轻量级：以上方案只需要少量人工干预，节约了大量人力，并且该框架可以适应网络应用的动态变化（如线上系统的频繁变更）。

现有的框架仅通过可捕获的时空数据挖掘潜在的依赖关系，但这类挖掘方法的准确度有限。此外，现有的方法在挖掘到依赖关系后仅依赖故障传播图进行异常的定位，锁定可能导致异常的关键指标、关键组件或关键异常事件，尚未有方法能够给出对应止损策略。另外，如果能够结合运维人员专家经验，就能构建出更准确、更精简的故障传播图。在异常根因推理过程中，可以基于强化学习等方法提高定位的准确性，实现快速、准确的止损。

利益冲突说明

所有作者声明不存在利益冲突关系。