一种微服务故障根因确定方法、电子设备及存储介质

技术领域

本发明涉及数据处理领域，特别是涉及一种微服务故障根因确定方法、电子设备及存储介质。

背景技术

目前，随着云计算和大规模分布式系统的快速发展，微服务架构已成为现代软件开发的重要趋势。在微服务架构运行过程中可能会存在各种故障并可能导致重大损失，然而针对微服务故障根本原因的分析并不简单，因为对于微服务架构而言，一个完整的应用程序会被解耦成多个功能最小化的服务，随着系统规模和微服务数量的不断扩大和增加，微服务之间的依赖关系也变得异常复杂，当某一微服务发生故障时，可能会产生涟漪效应，从而影响大范围的系统的运行状态，导致整个系统性能下降甚至功能故障。对于运维人员而言，通过人工的方式去处理复杂的依赖关系并从海量的监控数据中查找出故障的根因十分困难。

发明内容

针对上述技术问题，本发明采用的技术方案为：

一种微服务故障根因确定方法，应用于故障根因确定系统，故障根因确定系统连接有目标微服务系统，目标微服务系统包括若干目标微服务，每一目标微服务对应有若干指标数据；

所述微服务故障根因确定方法，包括如下步骤：

步骤S100、响应于检测到目标微服务系统发生故障，对每一目标微服务的前端接口进行异常检测，以确定出若干异常接口；

步骤S200、根据每一异常接口对应的调用链标识，确定每一异常接口对应的异常调用链；

步骤S300、对每一异常调用链进行跨度检测，以从若干目标微服务中确定出若干异常微服务；

步骤S400、获取每一异常微服务在目标时间段内的若干日志数据；

步骤S500、对每一异常微服务的每一日志数据进行关键词检测，以确定出每一异常微服务的若干异常日志数据；

步骤S600、根据每一异常微服务的若干异常日志数据和若干指标数据，确定目标微服务系统的故障根因。

在本申请的一种示例性实施例中，步骤S100包括：

步骤S110、获取每一目标微服务的前端接口在第一时间段T

步骤S120、若HTTP状态信息为异常状态信息，则将对应的前端接口确定为异常接口；否则，执行步骤S130；

步骤S130、根据每一目标微服务的前端接口被调用时对应的若干延迟时间，确定对应的前端接口的异常程度值；

步骤S140、若异常程度值大于预设的异常程度阈值，则将对应的前端接口确定为异常接口。

在本申请的一种示例性实施例中，步骤S130包括：

步骤S131、获取每一目标微服务的前端接口被调用时对应的每一延迟时间，得到延迟时间列表集V=(V

步骤S132、遍历V，若|V

步骤S133、根据每一目标延迟时间对应的前端接口的被调用时间，确定每一前端接口在第二时间段T

步骤S134、确定第m个目标微服务的前端接口的异常程度值Y

在本申请的一种示例性实施例中，步骤S300包括：

步骤S310、提取每一异常调用链的每个跨度的若干特征数据；特征数据包括对应的前端接口信息、被调用接口信息、被调用次数、在对应的异常调用链中的深度；

步骤S320、将每个跨度的若干特征数据输入预设调用模型中，得到该跨度对应的预测延迟时间，确定预测延迟时间列表C=(C

步骤S330、若(|C

步骤S340、遍历每一异常跨度，若异常跨度的子跨度为非异常跨度或异常跨度没有子跨度，则将该异常跨度所在的目标微服务确定为异常微服务。

在本申请的一种示例性实施例中，步骤S500包括：

步骤S510、若日志数据中包含预设关键词，则将该日志数据确定为异常日志数据。

在本申请的一种示例性实施例中，步骤S600包括：

步骤S610、获取每一异常日志数据的发生时间；

步骤S620、将发生时间位于第四时间段T

步骤S630、获取每一目标异常日志数据的日志内容；

步骤S640、将同一目标异常日志数据的相同类型的若干日志内容确定为同一个日志类型组；

步骤S650、根据同一目标异常日志数据的每一日志类型组中的日志内容的数量，确定每一异常微服务的日志根因数据；

步骤S660、根据每一异常微服务的日志根因数据和若干指标数据，确定目标微服务系统的故障根因。

在本申请的一种示例性实施例中，步骤S660包括：

步骤S661、获取每一异常微服务的若干指标数据；

步骤S662、根据同一异常微服务的每一指标数据和每一日志根因数据的依赖关系，确定该异常微服务的根因指标；

步骤S663、根据每一根因指标与不同异常微服务间的依赖关系，确定目标微服务系统的故障根因。

在本申请的一种示例性实施例中，异常微服务的指标数据包括异常流量、可用内存、文件页每秒写入速度、文件页每秒读入速度、剩余物理内存、网口进口流量、网口出口流量、磁盘使用空间。

根据本申请的一个方面，提供一种非瞬时性计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现前述的微服务故障根因确定方法。

根据本申请的一个方面，提供一种电子设备，包括处理器和前述的非瞬时性计算机可读存储介质。

本发明至少具有以下有益效果：

本发明在检测到目标微服务系统发生故障时，对每一目标微服务的前端接口进行异常检测，确定出异常接口，根据每一异常接口对应的调用链标识，确定每一异常接口对应的异常调用链，对每一异常调用链进行跨度检测，从若干目标微服务中确定出若干异常微服务，以减少目标微服务系统中的微服务根因分析的搜索空间，再通过获取每一异常微服务在目标时间段内的若干日志数据，对每一异常微服务的每一日志数据进行关键词检测，确定出每一异常微服务的若干异常日志数据，根据每一异常微服务的若干异常日志数据和若干指标数据，确定目标微服务系统的故障根因，减小了分析根因的计算量，实现了精准、高效的高细粒度微服务故障根本原因分析。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的微服务故障根因确定方法的流程图；

图2为本发明实施例提供的微服务故障根因确定方法的步骤S660的示例图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

目前的微服务故障根因分析方法主要依赖于监控微服务系统中的指标数据。指标数据一般通过部署在应用上的代理监控程序以恒定的采样频率获得,属于时间序列数据（如CPU空闲使用率、内存占用率等）。

如现有技术中的1、基于指标数据的MircoScrop方法，利用PC算法构建微服务间的非通信依赖，并依据与异常前端指标的皮尔逊相关系数排名获取根因微服务，但该方法依赖于难以获取的系统架构信息。再如2、现有技术中的ServiceRank方法，不依赖系统架构信息，其使用延迟指标捕获微服务之间异常传播关系，并使用基于相关性的二阶随机游走得到根因微服务，但该方法只能定位微服务级别的根因而无法实现服务内部的故障根因分析。还有3、现有技术中的CausualInfo方法，基于系统之间的流量延迟指标的相关性构建外层因果图，利用PC算法构建内层因果图，最终利用深度优先方法实现微服务内部指标的根因分析。4、MicroCause方法做了进一步改进，在PC算法的基础上提出通过PCTS算法捕获指标在时间序列上的因果关系，并且使用一种面向时序关联的随机游走算法得出根因。但是单纯基于PC算法构建指标间因果图的方法不适用于大规模的微服务场景，且此类方法严重依赖于其基于指标所生成的故障图，在复杂的微服务系统中难以通过收集完备的数据来实现准确的故障图构建。5、RCD方法使用一种基于软干预的方法实现对微服务系统的根因分析，但其在识别中进行的随机分组方式缺乏对于微服务系统的考量。6、基于频繁项集的方法统计异常调用链和正常调用链中微服务的占比，最后计算雅戈尔系数作为根因微服务的得分。将大量调用链结构聚合为少量方法调用模型，并基于方法调用模型的执行时间分解模型及预测方法检测和定位异常。与使用指标数据的方法相比，调用链能高效定位微服务级别的故障，但因为调用链数据极其庞大，所以想要直接获得根因需要花费大量时间，另一方面由于调用链的特性，其只能对于微服务粒度级别的故障进行分析，对更细粒度的如指标级别的故障则无能为力。

所以，综上所述，当前现有技术中存在的主要问题如下：

（1）现阶段研究主要针对单一数据源进行研究分析，无法同时使用多数据源对微服务系统进行联合根因分析；

（2）现阶段方法无法分析出微服务内部由指标以外的故障(如错误的系统配置等)所导致微服务系统异常根本原因；

（3）现阶段方法本身也存在问题，主要有故障分析粒度粗、复杂度高、在大规模微服务系统中的识别率低。

所以，针对上述现有技术中存在的不足，本发明提出一种微服务故障根因确定方法，应用于故障根因确定系统，故障根因确定系统连接有目标微服务系统，目标微服务系统包括若干目标微服务，每一目标微服务对应有若干指标数据。

所述的微服务故障根因确定方法，如图1所示，包括如下步骤：

步骤S100、响应于检测到目标微服务系统发生故障，对每一目标微服务的前端接口进行异常检测，以确定出若干异常接口；

进一步，步骤S100包括：

步骤S110、获取每一目标微服务的前端接口在第一时间段T

步骤S120、若HTTP状态信息为异常状态信息，则将对应的前端接口确定为异常接口；否则，执行步骤S130；

步骤S130、根据每一目标微服务的前端接口被调用时对应的若干延迟时间，确定对应的前端接口的异常程度值；

其中，步骤S130包括：

步骤S131、获取每一目标微服务的前端接口被调用时对应的每一延迟时间，得到延迟时间列表集V=(V

步骤S132、遍历V，若|V

由于微服务框架中的极端延迟主要由两种情况产生：一是未标识的故障，二是由于前端广泛采用HTTP缓存技术，缓存技术会将频繁访问HTTP请求的数据缓存，并在下次调用时直接返回。这些延迟会远远小于或大于正常的延迟，所以，为了可以有效地反映正常状态跨度的延迟，而中位差不会受到极端值的影响，所以，就要通过舍去偏离绝对中位数的点来处理极端延迟。

步骤S133、根据每一目标延迟时间对应的前端接口的被调用时间，确定每一前端接口在第二时间段T

步骤S134、确定第m个目标微服务的前端接口的异常程度值Y

本发明通过响应延迟和HTTP状态作为判断接口异常的依据。针对每一个前端接口单独使用其历史调用的均值和方差来模拟其正常的状态。为增强检测健壮性，计算期望和方差时采用两类延迟：最近响应延迟（即第二时间段T

步骤S140、若异常程度值大于预设的异常程度阈值，则将对应的前端接口确定为异常接口。

异常程度阈值可以基于3σ法则设置为3。

步骤S200、根据每一异常接口对应的调用链标识，确定每一异常接口对应的异常调用链；

目标微服务系统在完成一次业务调用的过程中，会把微服务之间的调用信息（包括服务标识、调用关系、执行时间等信息）生成一条特殊的记录，然后将本次请求执行所涉及的所有记录通过标记连接为一个树状链条就产生了一个调用链(Trace)，调用链上的每一个节点称为跨度(Span)。由于调用链上详细记录了系统间的微服务调用信息，所以，可以通过获取异常接口对应的调用链，来准确的确定出异常微服务。

由于每一次请求都会生成大量的调用链记录，如果实时对所有调用链记录进行构建和分析，将会花费高昂的时间和计算成本。因此通过前端接口锁定关键的异常调用链，以减少分析时间和计算量，从大量调用链中锁定少量关键的异常调用链去做分析，而不需要实时去维护一个庞大的调用链状态信息。如果一个请求响应受到故障影响，则故障会从根因微服务上沿着请求调用链传播并最终导致前端接口异常，因此可以通过单独分析异常接口请求所对应的调用链，快速锁定异常调用链。

步骤S300、对每一异常调用链进行跨度检测，以使从若干目标微服务中确定出若干异常微服务；

由于目标微服务系统在运行中会产生海量的调用链数据，所以为了减少对大量调用链进行分析所消耗的时间和资源，本发明通过对前端接口的异常检测，从大量调用链中筛选出少量且具体的关键异常调用链。继而分析异常调用链，通过对正常调用链的特征提取并学习调用链中每一个跨度的调用延迟，利用深度优先方法检验异常调用链中跨度的延迟时间，确定出异常微服务，异常微服务即存在潜在故障的微服务。

进一步，步骤S300包括：

步骤S310、提取每一异常调用链的每个跨度的若干特征数据；特征数据包括对应的前端接口信息、被调用接口信息、被调用次数、在对应的异常调用链中的深度；

步骤S320、将每个跨度的若干特征数据输入预设调用模型中，得到该跨度对应的预测延迟时间，确定预测延迟时间列表C=(C

预设调用模型可以为LightGBM，通过梯度提升和决策树可以有效实现非参数模型的回归，适用于对抽象跨度延迟的预测。因此使用LightGBM学习所有正常抽象跨度数据，当检测到某条调用链异常时回归预异常调用链中所有的跨度延迟，得到该跨度对应的预测延迟时间。

步骤S330、若(|C

步骤S340、遍历每一异常跨度，若异常跨度的子跨度为非异常跨度或异常跨度没有子跨度，则将该异常跨度所在的目标微服务确定为异常微服务。

对调用链跨度的异常检测不需要检测所有的跨度，因为按照故障传播规律，子跨度的异常将会导致父跨度的异常，因此本发明采用深度优先的方法，当遍历到一个跨度时，如果当前跨度延迟显著增加或发现其调用错误，则继续遍历其后代，否则遍历其兄弟跨度。当其没有子跨度或其子跨度没有异常时将此跨度所在的微服务视为根因微服务，即异常微服务。

步骤S400、获取每一异常微服务在目标时间段内的若干日志数据；

日志数据中包含大量系统运行时的信息，因此通过额外引入日志数据解决诸如配置问题等非指标故障的分析检测。

步骤S500、对每一异常微服务的每一日志数据进行关键词检测，以确定出每一异常微服务的若干异常日志数据；

进一步，步骤S500包括：

步骤S510、若日志数据中包含预设关键词，则将该日志数据确定为异常日志数据。

步骤S600、根据每一异常微服务的若干异常日志数据和若干指标数据，确定目标微服务系统的故障根因；

进一步，步骤S600包括：

步骤S610、获取每一异常日志数据的发生时间；

步骤S620、将发生时间位于第四时间段T

步骤S630、获取每一目标异常日志数据的日志内容；

步骤S640、将同一目标异常日志数据的相同类型的若干日志内容确定为同一个日志类型组；

步骤S650、根据同一目标异常日志数据的每一日志类型组中的日志内容的数量，确定每一异常微服务的日志根因数据；

步骤S660、根据每一异常微服务的日志根因数据和若干指标数据，确定目标微服务系统的故障根因。

由于日志是文本类型数据，首先需要将日志建模为多元时序数据。本发明采取统计记录每种错误日志模板在各微服务中的发生次数，由于日志模板是对源代码中的打印语句的抽象，其在原始日志中表现为具有不同参数值模板复用，因此提取故障发生时的错误日志，并提取其时间戳和错误日志内容，并将每种相同错误日志内容视为一种故障表现形式和潜在故障根因，如L(s,t)={Ms,fault_1,t,Ms,fault_2,t,...Ms,fault_3,t}可以表示为微服务s在t时刻每种故障日志fault_n的发生次数M。时间序列化后的日志数据形式就如同微服务其他指标数据一样，每个错误日志内容可以视为一个指标变量，通过后续的根因分析方法一同分析。如果是分析出的根因是日志变量，可以通过将错误日志内容作为故障的根因输出给运维人员，帮助其快速定位根本原因故障。

其中，步骤S660包括：

步骤S661、获取每一异常微服务的若干指标数据；

异常微服务的指标数据包括异常流量、可用内存、CPU空闲时间、CPU用户处理时间、文件页每秒写入速度、文件页每秒读入速度、剩余物理内存、对应网口的进口流量、对应网口的出口流量、磁盘使用空间等。

步骤S662、根据同一异常微服务的每一指标数据和每一日志根因数据的依赖关系，确定该异常微服务的根因指标；

步骤S663、根据每一根因指标与不同异常微服务间的依赖关系，确定目标微服务系统的故障根因。

其中，步骤S660中的根据根因指标来确定故障根因的方法，采用针对微服务架构的干预识别方法，干预(Intervention)是因果推断(Causal Inference)中的一个术语，在因果推断中使用因果贝叶斯网络构建变量的因果关系，因果贝叶斯网络是一个有向无环图，其中每一个节点代表一个变量，箭头表示变量间的因果关系，可以用因果结构方程(SCM)描述一个节点所受的因果效应，干预是指变量受到外界干预，使其不再满足原有的因果结构和产生机制。

首先构建每个微服务的局部因果图，基于微服务内部的历史指标数据定期更新维护每一个微服务内部指标间的因果图，这样做的目的是利用历史数据来满足需要大量数据支持的因果图生成，减小在故障发生时的计算量；另一方面定期更新还可以应对真实场景中微服务频繁的迭代更新。当故障发生后进行干预识别，干预识别阶段引入可能存在的故障日志数据和一个额外的F-Node节点（为标识系统是否故障的故障标识节点，用于表示干预对系统的影响），初始的F-Node和日志数据变量默认均处于全连接状态，之后计算F-Node和其他节点的因果关系，将与之有直接因果关联的变量作为识别出的干预变量。

当目标微服务系统发生故障时，首先分析每个异常微服务内部的潜在干预，之后再识别异常微服务间的干预，每次干预都基于局部干预识别算法。微服务的指标间有两种依赖：1、微服务之间因调用而产生依赖关系，这种关系可以通过调用链反映，而不必使用计算复杂度颇高的因果关系计算(如PC算法)，因此之前使用调用链分析所得出的异常微服务中的指标变量（指标数据和日志根因数据）可以视为从全局因果图上摘取下的子图节点，每个节点由于是通过深度优先得到的，可以视为此节点为通信依赖上的根因节点。2、微服务的指标间的另一种依赖是资源抢占所导致的依赖关系，这部分不能被调用链所反映,需要计算其因果关系。因此在获得了每个微服务的干预指标后，可以认为这些根因指标是被第二种因素所影响，因此再次对这些指标进行干预识别分析。这种方式的优点一是可以减小各指标项间的干扰，避免由于观测数据不全面造成的误差；二是可以大大减少分析时的计算量，因为每次只需要考虑一个微服务内部的指标项间的因果关系而非整个系统，因此可以减少大量的条件独立性计算；同时得益与这种的学习框架，使周期性离线学习维护其微服务内部的因果关系图得以实现，进一步加快分析出根因的时间。如图2所示的每一个框代表一个微服务，其内部的节点表示对应微服务的指标变量，F节点为设置的F-Node节点，F节点最终指向的变量即根因变量，如图2中最终根因为微服务2的A指标变量和微服务1的B指标变量。

另外，由于识别干预时严重依赖于干预节点和其他节点的独立性检验准确性，使用传统的卡方检验对于连续性变量不能有效识别其独立性，因此本发明提出了一种先进的独立性检验方法—基于随机傅里叶特征的独立性检测方法(RCIT)。该方法基于核条件独立性检验方法(KCIT)使用傅里叶逆变换估计核函数，因此能够实现快速的非参数化独立性检验。虽然这种非参数的方法在计算复杂度上高于传统方法，但是由于在本发明确定根因变量阶段需要进行的独立性检验的变量数量非常有限，因此使用RCIT能在相对短的时间内获得更加精准的结果，最后对确定出的故障根因进行排名。排名依据是微服务异常得分高的在前，若多个微服务的异常得分相等，则按照同一微服务的指标依据和F-Node节点的相关性强弱进行排名，关联性强的在前，其中微服务的异常得分可以根据用户的需要进行打分，也可根据现有技术的故障根因出现的次数和重要程度来进行打分。

本发明在检测到目标微服务系统发生故障时，对每一目标微服务的前端接口进行异常检测，确定出异常接口，根据每一异常接口对应的调用链标识，确定每一异常接口对应的异常调用链，对每一异常调用链进行跨度检测，从若干目标微服务中确定出若干异常微服务，以减少目标微服务系统中的微服务根因分析的搜索空间，再通过获取每一异常微服务在目标时间段内的若干日志数据，对每一异常微服务的每一日志数据进行关键词检测，确定出每一异常微服务的若干异常日志数据，根据每一异常微服务的若干异常日志数据和若干指标数据，确定目标微服务系统的故障根因，减小了分析根因的计算量，实现了精准、高效的高细粒度微服务故障根本原因分析。

本发明的实施例还提供了一种非瞬时性计算机可读存储介质，该存储介质可设置于电子设备之中以保存用于实现方法实施例中一种方法相关的至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现上述实施例提供的方法。

本发明的实施例还提供了一种电子设备，包括处理器和前述的非瞬时性计算机可读存储介质。

虽然已经通过示例对本发明的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本发明的范围。本领域的技术人员还应理解，可以对实施例进行多种修改而不脱离本发明的范围和精神。本发明开的范围由所附权利要求来限定。