CN113590451A - 一种根因定位方法、运维服务器及存储介质 - Google Patents

Abstract

本申请实施例提供一种根因定位方法、运维服务器及存储介质，其中方法包括：获取业务系统的运维数据，以及确定运维数据异常的目标数据特征；构建目标数据特征之间的第一依赖关系、目标数据特征与候选功能模块之间的第二依赖关系、以及候选功能模块与候选异常类型之间的第三依赖关系，以得到目标关系；对所述目标关系中的候选异常类型进行根因推断，以得到各候选异常类型的异常概率；根据各候选异常类型的异常概率，从候选异常类型中确定根因类型；根据所述根因类型，确定所述业务系统的根因定位结果。本申请实施例可以精准的进行根因定位，提升根因定位性能。

Description

一种根因定位方法、运维服务器及存储介质

技术领域

本申请实施例涉及系统运维技术领域，具体涉及一种根因定位方法、运维服务器及存储介质。

背景技术

根因定位是智能化运维的一个重要环节，用于在业务系统发生异常时，快速定位异常的根本原因。随着业务规模的增长，业务系统的根因定位也面临更高的要求和更大的挑战，因此如何提升根因定位性能，成为了本领域技术人员亟需解决的技术问题。

发明内容

有鉴于此，本申请实施例提供一种根因定位方法、运维服务器及存储介质，以精准的进行根因定位，提升根因定位性能。

为实现上述目的，本申请实施例提供如下技术方案。

第一方面，本申请实施例提供一种根因定位方法，包括：

获取业务系统的运维数据，以及确定所述运维数据异常的目标数据特征；

构建所述目标数据特征之间的第一依赖关系、所述目标数据特征与候选功能模块之间的第二依赖关系、以及候选功能模块与候选异常类型之间的第三依赖关系，以得到目标关系；其中，所述候选功能模块为所述业务系统中目标数据特征依赖的功能模块，候选异常类型为所述候选功能模块存在的异常类型；

对所述目标关系中的候选异常类型进行根因推断，以得到各候选异常类型的异常概率；根据各候选异常类型的异常概率，从候选异常类型中确定根因类型；

根据所述根因类型，确定所述业务系统的根因定位结果。

第二方面，本申请实施例提供一种运维服务器，包括至少一个存储器和至少一个处理器，所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如上述第一方面所述的根因定位方法。

第三方面，本申请实施例提供一种存储介质，所述存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令被执行时实现如上述第一方面所述的根因定位方法。

第四方面，本申请实施例提供一种计算机程序，所述计算机程序被执行时实现如上述第一方面所述的根因定位方法。

本申请实施例提供的根因定位方法可获取业务系统的运维数据，并确定出所述运维数据异常的目标数据特征；基于确定的目标数据特征，本申请实施例可构建出目标数据特征之间的第一依赖关系；并且为使得业务系统的根因定位能够深入到业务系统的功能模块和异常类型的层面，本申请实施例可进一步构建目标数据特征与所依赖的候选功能模块之间的第二依赖关系，构建候选功能模块与所存在的异常类型之间的第三依赖关系；从而由第一依赖关系、第二依赖关系和第三依赖关系形成目标关系，使得目标关系能够对目标数据特征至候选异常类型的因果关系进行逐层的梳理，为深入到功能模块的异常类型的层面进行根因定位提供了基础。基于此，在构建出目标关系之后，本申请实施例可对目标关系中的候选异常类型进行根因推断，以得到各候选异常类型的异常概率，从而根据各候选异常类型的异常概率，从候选异常类型中确定根因类型；进而，本申请实施例可根据所述根因类型，确定所述业务系统的根因定位结果，使得根因定位结果能够深入到业务系统的功能模块的异常类型的层面。

本申请实施例提供的根因定位方法能够深入到业务系统的功能模块以及功能模块的异常类型的层面，定位出业务系统的根因定位结果，而不只是在业务系统的指标层面提供根因定位结果，因此本申请实施例能够提升业务系统的根因定位的精准性。

附图说明

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

图1为业务系统与运维系统的架构示意图。

图2为本申请实施例提供的根因定位方法的流程图。

图3A为业务系统与运维系统的另一架构示意图。

图3B为本申请实施例提供的根因定位过程的阶段示例图。

图3C为成分、异常类型与检验方法的对应示例图。

图3D为标记训练数据的结构示例图。

图4A为本申请实施例提供的概率图模型的结构示例图。

图4B为本申请实施例提供的根因定位界面的示例图。

图5为本申请实施例提供的根因定位装置的框图。

图6为运维服务器的框图。

具体实施方式

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

根因定位可以认为是由运维系统对业务系统的运行过程进行监控，从而在业务系统发生异常时，运维系统可快速定位业务系统发生异常的根本原因。图1示出了业务系统与运维系统的架构示意图，可进行参照。如图1所示，该系统架构可以包括业务系统110和运维系统120。

其中，业务系统110可以是运行一个或多个业务服务的服务器集群。在一个示例中，随着云计算的发展，越来越多的业务系统转移到了云计算平台上，实现了软件和硬件资源的共享，并且云计算平台也相应提供了多种不同类型的计算引擎以满足业务需求；在此背景下，随着业务规模的增长，云计算平台的根因定位面临着更高的要求和更大的挑战，因此亟需提升云计算平台的根因定位性能。基于此，在本申请实施例的一些实施例中，业务系统110可以是不同架构的云计算平台。

运维系统120可以是保障业务系统（例如云计算平台）正常运行并进行系统维护的服务器集群。运维系统120可在业务系统的运行过程中对业务系统进行监控，例如对业务系统进行异常指标检测与根因定位。异常指标检测是从业务系统的指标出发，通过对业务系统在运行过程中的指标进行分析，从而检测出业务系统的异常指标，并进行实时告警。根因定位则是在检测到异常指标的基础上，定位异常的根因。在一个示例中，业务系统的指标例如业务系统的关键性能指标（Key Performance Indicator，KPI）等。

目前，根因定位主要集中在异常指标的关联分析上，运维系统在检测出业务系统的异常指标之后，通过业务系统的指标间依赖关系，分析与异常指标存在依赖关系的关联指标，从而实现业务系统的根因定位。然而，这种方式仅是将业务系统的根因定位聚焦在指标层面，最终得到的根因定位结果只是与异常指标存在依赖关系的关联指标，并无法定位到业务系统更深层次的异常根因，从而导致业务系统的根因定位的精准性较低。

需要说明的是，云计算平台等业务系统一般包括实现多个功能的功能模块，每个功能模块在业务系统的运行过程中可能产生不同的异常类型。在一个示例中，业务系统的一个功能模块可在业务系统的服务器集群中对应一个功能实体。为便于理解，以云计算平台为例，表1示出了一种示例的功能模块与异常类型的对应表，可进行参照。

表1

由表1可以看出，云计算平台的功能模块例如YARN（Yet Another ResourceNegotiator，另一种资源协调者）模块、BRS（Blink Rest Server，启停Blink作业的服务）模块、ZK（ZooKeeper，一个分布式的开放源码的分布式应用程序协调服务）模块、HDFS（HadoopDistributed File System、分布式文件系统）模块、OS（Operating System，操作系统）模块等；其中，Blink是一个大数据处理平台。YARN模块的异常类型分为NM（Node Manager，节点管理）批量不可用、RM（Resource Manager，资源管理）切换等，BRS模块的异常类型分为作业无法提交等，ZK模块的异常类型分为leader（主节点）重启、slave（从节点）重启、服务闪断等，HDFS模块的异常类型分为call queue length（调用队列长度）超过上限、冷却水位报警等，OS模块的异常类型分为批量机器load（加载）过高、批量机器宕机等。需要说明的是，表1仅是对部分功能模块的部分异常类型进行示例说明，云计算平台所具有的功能模块以及各个功能模块的异常类型可根据实际情况而定，本申请实施例并不设限。

基于业务系统的功能模块可能发生异常并且功能模块存在不同的异常类型，本申请实施例旨在通过提供具有创造性的技术方案，以深入到业务系统的功能模块以及功能模块的异常类型的层面，定位出业务系统存在异常的功能模块（简称根因模块）以及该功能模块的异常类型（简称根因模块的根因类型），从而提供根因定位结果，而不只是在业务系统的指标层面提供根因定位结果，进而实现提升业务系统的根因定位精准性的效果。

基于上述思路，图2示出了本申请实施例提供的根因定位方法的可选流程图。该方法流程可由运维服务器执行实现，运维服务器可以视为是运维系统对应的服务器设备。参照图2，该方法流程可以包括如下步骤。

在步骤S210中，获取业务系统的运维数据，以及确定所述运维数据异常的目标数据特征。

业务系统的运维数据是用于业务系统的运行保障和维护的数据，包括业务系统的日志文本、指标等。在一些实施例中，业务系统的日志文本可由日志系统提供，日志系统可在业务系统的运行过程中生成业务系统的运行日志等日志文件，从而提供业务系统的日志文本。业务系统的指标可以通过监控方式得到，例如，业务系统的指标可由监控系统提供，监控系统可在业务系统的运行过程中监控业务系统的指标。指标可以例如业务系统的KPI等。

在一些实施例中，本申请实施例所指的运维数据可以是单一类型的运维数据，例如，运维数据为日志文本或者指标中的一项。在另一些实施例中，本申请实施例所指的运维数据可以是多类型的运维数据，例如运维数据可以为日志文本和指标，即结合业务系统的日志文本和指标，来进行业务系统的根因定位。

在获取业务系统的运维数据之后，本申请实施例可确定运维数据的数据特征。在一些实施例中，运维数据的数据特征可以包括：日志文本的日志特征，和/或，指标的指标特征。

在进一步的一些实施例中，本申请实施例可将日志文本的日志模式作为日志特征。日志文本的日志模式是指剔除日志文本中的变量，并基于多个日志文本提取公共数据所形成的特征。作为可选实现，本申请实施例可在剔除日志文本中的变量后，通过提取日志文本中的高频词，从而将日志文本中的高频词转换为特征形式，进而通过聚类相似特征的多个日志文本，以实现获得日志文本的日志模式。可以理解的是，不同特征的日志文本可形成不同的日志模式，从而日志模式能够对日志文本起到模式分类的效果。在进一步的一些实施例中，本申请实施例可将指标的指标异常检测结果作为指标特征。

在一个可选实现中，运维数据的数据特征可以包括日志模式以及指标异常检测结果。当然，在单独使用日志文本或者指标作为运维数据的情况下，运维数据的数据特征也可以是日志模式或者指标异常检测结果。

在得到运维数据的数据特征之后，本申请实施例可从运维数据的数据特征中确定出异常的目标数据特征。例如，本申请实施例可从日志模式以及指标异常检测结果中确定出异常的目标日志模式和目标指标异常检测结果。

在一些实施例中，本申请实施例可预先标记出业务系统可能存在异常的功能模块（称为标记根因模块），以及预先标记出各功能模块可能存在的异常类型（称为标记根因类型），从而针对任一个标记根因模块在任一个标记根因类型下可能存在异常的数据特征进行进一步标记，以得到标记训练数据。基于此，标记训练数据可以包括预先标记的标记根因模块在标记根因类型下存在异常的数据特征（例如，标记根因模块在标记根因类型下存在的日志模式和指标异常检测结果）。从而，本申请实施例可将运维数据的数据特征，与标记训练数据进行匹配，得出运维数据中异常的目标数据特征。例如，本申请实施例可将业务系统的日志模式以及指标异常检测结果，与标记训练数据中的标记根因模块在标记根因类型下存在的日志模式和指标异常检测结果进行匹配，从而从日志模式和指标异常检测结果中确定出异常的目标日志模式和目标指标异常检测结果。

在步骤S211中，构建所述目标数据特征之间的第一依赖关系、所述目标数据特征与候选功能模块之间的第二依赖关系、以及候选功能模块与候选异常类型之间的第三依赖关系，以得到目标关系。

在得到运维数据异常的目标数据特征之后，本申请实施例可构建出目标数据特征之间的依赖关系（称为第一依赖关系）。所述第一依赖关系可以表达目标数据特征之间的因果关系，例如表达目标日志模式、目标指标异常检测结果之间的因果关系。在一些实施例中，本申请实施例可确定任意两个目标数据特征之间的独立性（例如任意两个目标日志模式、任意两个目标指标异常检测结果之间的独立性），从而通过目标数据特征之间的独立性来确定目标数据特征之间的依赖关系，以构建出所述第一依赖关系。例如，本申请实施例可基于PC算法学习目标数据特征之间的第一依赖关系。

在构建出目标数据特征之间的第一依赖关系之后，本申请实施例可进一步构建目标数据特征与所依赖的业务系统的功能模块之间的依赖关系（称为第二依赖关系）。为便于说明，目标数据特征所依赖的业务系统的功能模块可称为候选功能模块，候选功能模块可作为根因模块的候选。在一些实施例中，基于构建的第一依赖关系，本申请实施例可确定第一依赖关系中的末端目标数据特征，该末端目标数据特征可以视为是第一依赖关系中无下一步依赖的目标数据特征，从而本申请实施例可确定末端目标数据特征在业务系统所依赖的候选功能模块，进而构建末端目标数据特征至候选功能模块的依赖关系，以实现构建第二依赖关系。作为可选实现，本申请实施例可预先设定业务系统的数据特征与功能模块之间的依赖关系，例如预设业务系统的日志模式、指标异常检测结果与功能模块之间的依赖关系，从而基于预设的数据特征与功能模块之间的依赖关系，本申请实施例可确定第一依赖关系中的末端目标数据特征所依赖的候选功能模块，进而构建出末端目标数据特征至候选功能模块的第一依赖关系。

在构建出第二依赖关系之后，本申请实施例可进一步构建候选功能模块与所存在的异常类型之间的依赖关系（称为第三依赖关系）。为便于说明，候选功能模块在业务系统存在的异常类型可称为候选异常类型，候选异常类型可以作为候选的根因类型。在一些实施例中，本申请实施例可预先设定业务系统的功能模块与异常类型之间的依赖关系，从而基于预设的功能模块与异常类型之间的依赖关系，本申请实施例可确定候选功能模块所依赖的候选异常类型，进而构建出候选功能模块至候选异常类型的第三依赖关系。

在一些实施例中，预设的数据特征与功能模块之间的依赖关系、预设的功能模块与异常类型之间的依赖关系可记录在CMDB（Configuration Management Database，配置管理数据库）等数据库中。

可以看出，本申请实施例构建的目标关系包含三层的依赖关系：目标数据特征之间的第一依赖关系，目标数据特征与候选功能模块之间的第二依赖关系，候选功能模块与候选异常类型之间的第三依赖关系。通过构建目标关系，本申请实施例可将目标数据特征（例如目标日志模式、目标指标异常检测结果）至候选异常类型的因果关系进行逐层的梳理，为后续能够深入到功能模块的异常类型的层面进行根因定位提供基础。

在进一步的一些实施例中，本申请实施例可通过构建概率图模型，以实现构建目标关系，即所述目标关系可由概率图模型表示。作为可选实现，概率图模型可以包括特征层和根因层；所述特征层包括与所述目标数据特征对应的特征节点，所述根因层包括与所述候选功能模块对应的模块节点，以及与所述候选异常类型对应的类型节点；从而，本申请实施例可通过构建特征层的特征节点之间的依赖关系，以实现构建第一依赖关系；通过构建特征层的叶子特征节点至根因层的模块节点的依赖关系，以实现构建第二依赖关系；通过构建根因层的模块节点至类型节点的依赖关系，以实现构建第三依赖关系。

在步骤S212中，对所述目标关系中的候选异常类型进行根因推断，以得到各候选异常类型的异常概率；根据各候选异常类型的异常概率，从候选异常类型中确定根因类型。

在构建出目标关系之后，本申请实施例可对目标关系中的候选异常类型进行根因推断，从而得到目标关系中的各候选异常类型的异常概率，进而根据各候选异常类型的异常概率，从候选异常类型中确定根因类型，以实现在功能模块的异常类型的层面，定位出业务系统的异常根因。作为可选实现，本申请实施例可将异常概率最大的候选异常类型作为是根因类型。

在一些实施例中，本申请实施例在构建概率图模型之后，可对概率图模型中的类型节点进行根因推断，从而得到概率图模型中的各类型节点的异常概率，进而根据各类型节点的异常概率，从类型节点中确定根因类型节点，将根因类型节点所对应的候选异常类型作为根因类型。例如，本申请实施例可将异常概率最大的类型节点确定为根因类型节点，从而将根因类型节点对应的候选异常类型确定为根因类型。

作为可选实现，本申请实施例可使用exact inference（精确推断）算法对目标关系中的候选异常类型进行根因推断，从而推断出目标关系中各候选异常类型的异常概率。例如，本申请实施例可使用exact inference算法对概率图模型中的类型节点进行根因推断，以推断出概率图模型中的各类型节点的异常概率。

在进一步的一些实施例中，本申请实施例在进行根因推断时，可结合由目标数据特征形成的特征矩阵。作为可选实现，本申请实施例可根据目标数据特征以及目标数据特征在标记训练数据中对应的标记根因模块和标记根因类型，形成特征矩阵；从而根据特征矩阵以及所述目标关系，使用exact inference算法对所述目标关系中的候选异常类型进行根因推断。例如，根据所述特征矩阵和概率图模型，使用exact inference算法对概率图中的类型节点进行根因推断。作为可选实现，本申请实施例可将所述特征矩阵和概率图模型作为exact inference算法的输入，从而通过执行exact inference算法，计算出概率图模型中的类型节点的异常概率。在其他可能的实现中，本申请实施例并不限于使用exactinference算法进行根因推断，例如也可使用随机游走算法进行根因推断。

在步骤S213中，根据所述根因类型，确定所述业务系统的根因定位结果。

在一些实施例中，本申请实施例可将根因类型，以及根因类型对应的候选功能模块（称为根因模块），确定为所述根因定位结果，从而使得根因定位结果深入到业务系统的功能模块以及功能模块的异常类型的层面。

在进一步的一些实施例中，如果根因类型的概率小于概率阈值，则业务系统可能出现了新的异常类型，当前确定的根因类型并无法表达该新的异常类型，因此本申请实施例可将根因类型对应的根因模块，确定为根因定位结果。

本申请实施例提供的根因定位方法可获取业务系统的运维数据，并确定出所述运维数据异常的目标数据特征；基于确定的目标数据特征，本申请实施例可构建出目标数据特征之间的第一依赖关系；并且为使得业务系统的根因定位能够深入到业务系统的功能模块和异常类型的层面，本申请实施例可进一步构建目标数据特征与所依赖的候选功能模块之间的第二依赖关系，构建候选功能模块与所存在的异常类型之间的第三依赖关系；从而由第一依赖关系、第二依赖关系和第三依赖关系形成目标关系，使得目标关系能够对目标数据特征至候选异常类型的因果关系进行逐层的梳理，为深入到功能模块的异常类型的层面进行根因定位提供了基础。基于此，在构建出目标关系之后，本申请实施例可对目标关系中的候选异常类型进行根因推断，以得到各候选异常类型的异常概率，从而根据各候选异常类型的异常概率，从候选异常类型中确定根因类型；进而，本申请实施例可根据所述根因类型，确定所述业务系统的根因定位结果，使得根因定位结果能够深入到业务系统的功能模块的异常类型的层面。

本申请实施例提供的根因定位方法能够深入到业务系统的功能模块以及功能模块的异常类型的层面，定位出业务系统的根因定位结果，而不只是在业务系统的指标层面提供根因定位结果，因此本申请实施例能够提升业务系统的根因定位的精准性。

下面以业务系统的运维数据包括业务系统的日志文本以及指标为例，对本申请实施例提供的根因定位过程进行介绍。在一些实施例中，图3A示出了业务系统与运维系统的另一架构示意图。结合图1和图3A所示，在图3A所示系统架构中，日志系统130可在业务系统110的运行过程中，生成业务系统的日志文本；监控系统140可在业务系统110的运行过程中，监控业务系统的指标。运维系统120（具体可以是运维系统对应的运维服务器）可从日志系统130获取到业务系统110的日志文本，从监控系统140获取到业务系统110的指标，以基于业务系统的日志文本和指标，对业务系统110进行根因定位。

在一些实施例中，基于图3A所示系统架构，图3B示出了本申请实施例提供的根因定位过程的阶段示例图。在本申请实施例中，运维服务器在获取到业务系统的日志文本以及指标之后，可通过图3B所示的阶段，实现对业务系统进行精准的根因定位。如图3B所示，本申请实施例提供的根因定位过程的阶段可以包括：日志聚类阶段310、指标检测阶段320、特征选择阶段330、关系构建阶段340、根因推断阶段350。本申请实施例所提供的各个阶段，以及各个阶段内的环节可通过配置相应的功能组件实现，具体的功能组件的配置方式，本申请实施例并不设限。

在日志聚类阶段310，运维服务器可利用自然语言处理技术对相似的日志文本进行聚类，以得到业务系统的日志模式。本申请实施例可从业务系统的海量日志文本中提取出多个日志模式。一个日志模式可以表示日志文本的一个模式分类，对应相似的多个日志文本的聚类结果。

进一步的，结合图3B所示，日志聚类阶段310可以进一步包括以下多个环节：预处理环节311、日志子模式提取环节312、特征表示环节313、聚类环节314。

其中，在预处理环节311，运维服务器可对业务系统的日志文本进行预处理，例如对日志文本剔除停用词等变量。

在日志子模式提取环节312，运维服务器可提取预处理后的日志文本中的高频词，从而基于提取的日志文本的高频词，形成日志文本的日志子模式。例如，将日志文本的高频词组合为日志文本的日志子模式。预处理后的任一日志文本经过提取高频词后，可基于该日志文本的高频词形成该日志文本的日志子模式，从而业务系统每个预处理后的日志文本均可得到对应的日志子模式。日志文本的日志子模式可以认为是日志文本至日志模式的中间态，表示的是日志文本中高频词的组合结果。

在一些实施例中，本申请实施例可基于FT-tree（Frequent-pattern tree，频率模式树）算法，从预处理后的日志文本中提取高频词。FT-tree是一种树状数据结构，其以列表结构存储预处理后的日志文本的词，且预处理后的日志文本中的一个词对应FT-tree中的一个节点；在此基础上，本申请实施例可基于FT-tree中每个节点的子节点个数，从FT-tree中剪除预处理后的日志文本中的低频词且保留高频词，以得到预处理后的日志文本的高频词。FT-tree算法剪除低频词且保留高频词的剪枝策略是基于FT-tree中每个节点的子节点个数实现，这导致FT-tree算法的剪枝结果会受到日志文本中句子长度的限制。

基于此，在另一些实施例中，本申请实施例可对FT-tree算法进行优化，从而基于优化的FT-tree算法，从预处理后的日志文本中提取高频词。本申请实施例对于FT-tree算法的优化主要涉及两个方面：采用字典结构而非列表结构存储预处理后的日志文本的词；在剪枝策略上，基于叶子节点个数而非子节点个数，使得剪枝结果不受句子长度限制。作为可选实现，本申请实施例可基于优化的FT-tree算法，从预处理后的日志文本中提取高频词，其中，优化FT - tree算法使用优化的FT-tree，优化的FT-tree为树状数据结构且以字典结构存储预处理后的日志文本的词，预处理后的日志文本中的一个词对应优化的FT-tree中的一个节点；在此基础上，本申请实施例可基于优化的FT-tree中的叶子节点个数（即优化的FT-tree中末端节点的个数），剪除预处理后的日志文本中的低频词并保留高频词，以得到预处理后的日志文本的高频词。优化的FT-tree算法可称为AFT-tree算法。

在特征表示环节313，运维服务器可将日志文本的日志子模式转换为日志子模式特征。例如，将日志文本的高频词组合使用特征进行表示，从而得到日志文本相应的日志子模式特征。在一些实施例中，本申请实施例可对日志文本的日志子模式进行向量化表示，从而得到日志子模式特征，即日志子模式的向量化结果可以作为所述日志子模式特征。对日志子模式进行向量化表示的算法可以有多种，本申请实施例并不设限。例如，本申请实施例可基于Word2Vec算法，对日志文本的日志子模式进行向量化表示，从而得到日志文本的日志子模式特征。

在聚类环节314，运维服务器可将相似的日志子模式特征进行聚类，从而得到日志模式。例如，相似的多个日志文本的日志子模式特征可聚为一类，形成一个日志模式；进而，不同的日志子模式特征可分别聚类，得到多个日志模式。在一些实施例中，本申请实施例可基于层次聚类模型（Hierarichical Agglomerative Clustering），将相似的日志子模式特征进行聚类，从而得到日志模式；当然，对相似的日志子模式特征进行聚类的具体聚类模型可根据实际情况而定，例如也可使用DBSCAN（Density-Based Spatial Clustering ofApplications with Noise，基于密度的空间聚类在噪声中的应用）等密度聚类模型，将相似的日志子模式特征进行聚类，本申请实施例对此并不设限。

作为一个实现示例，下面以具体的日志文本为例，对日志聚类阶段310的执行示例进行说明。假设2个日志文本的示例如下：

(1) Table bigdata.merchant_info can not be found；

(2) Can't find table bigdata.merchant_info。

上述日志文本经过剔除变量的预处理、以及经过AFT-tree算法的日志子模式提取之后，可得到如下结果：

[1] Table * can not be found；

[2] Can't find table *。

其中，* 表示剔除变量之后的替代符号。进一步的，对日志子模式进行向量化表示后，假设上述[1]的日志子模式特征的hash编码示例为abc1，上述[2]的日志子模式特征的hash编码示例为abc2，则将相似的日志子模式特征进行聚类后，可得到日志模式：abc3。该日志模式abc3包含了两个日志子模式的特征abc1和abc2。

在指标检测阶段320，运维服务器可对业务系统的指标进行异常检测，得出业务系统的指标异常检测结果。在一些实施例中，本申请实施例可基于时间序列的异常检测算法（例如时序异常检测算法），对业务系统的指标进行异常检测，从而得到指标异常检测结果。指标异常检测结果可以表达业务系统发生异常的指标。作为可选实现，本申请实施例基于时间序列的异常检测算法，可将时间序列信号分解为多种成分，每种成分在检测不同异常类型时，使用不同的检验方法对指标进行异常检测，从而得出指标异常检测结果。例如，业务系统的指标可以由时间序列构成，本申请实施例可将指标的时间序列分解为多种成分，并预设成分、异常类型与检验方法的对应关系，从而本申请实施例可基于该对应关系，使用与指标的时间序列的成分以及需要检测的异常类型相对应的检验方法，对指标进行异常检测。

进一步的，结合图3B所示，指标检测阶段320可以进一步包括以下多个环节：时间序列分解环节321、异常检测环节322。

在时间序列分解环节321中，运维服务器可将业务系统的指标的时间序列，分解为趋势、残差等多种成分。在一些实施例中，运维服务器可利用Robust（鲁棒）STL（Seasonaland Trend decomposition using Loess，趋势成分和周期成分的分解）方法将指标的时间序列分解为多种成分；其中，Loess是一种鲁棒的回归算法，Robust STL方法是以鲁棒局部加权回归作为平滑方法的时间序列分解方法。

在异常检测环节322，运维服务器可使用与指标的时间序列的成分以及需要检测的异常类型相对应的检验方法，对指标进行异常检测，从而得出指标异常检测结果。

作为一种示例，图3C示出了成分、异常类型与检验方法的对应示例图。如图3C所示，指标的时间序列可以分解为趋势、残差等成分，指标需要检测的异常类型可以包括均值变化、方差变化、尖峰深谷、断崖、趋势预测等。

进一步如图3C所示，当指标的时间序列的成分为趋势，需要检测的异常类型为均值变化时，可以使用T-test（T校验）方法对指标进行异常检测；T-test方法是用服从T分布的统计量检验两个正态总体平均值的一种方法。当指标的时间序列的成分为残差，需要检测的异常类型为方差变化时，可以使用F-test（F校验）方法对指标进行异常检测；F-test方法也叫做联合假设检验、方差比率检验、方差齐性检验等，它是一种在原假设之下，统计值服从F-分布的检验。当指标的时间序列的成分为残差，需要检测的异常类型为尖峰深谷时，可以使用ESD（Extreme Studentized Deviate ，极端学生化偏差）-test（校验）方法对指标进行异常检测。当指标的时间序列的成分为趋势，需要检测的异常类型为趋势预测时，可以使用MK（Mann Kendall，曼肯德尔）-test方法对指标进行异常检测。

在得到业务系统的日志模式以及指标异常检测结果之后，日志模式和指标异常检测结果可作为运维数据的数据特征。在特征选择阶段330，运维服务器可对日志模式和指标异常检测结果进行特征选择，从而从日志模式和指标异常检测结果中确定出与标记训练数据相对应的目标日志模式和目标指标异常检测结果。目标日志模式和目标指标异常检测结果可作为运维数据中异常的目标数据特征。

在一些实施例中，标记训练数据可标记业务系统存在过异常的功能模块和功能模块的异常类型，为便于说明，标记训练数据中标记的功能模块可称为标记根因模块，标记的异常类型可称为标记根因类型；进而，标记训练数据可以进一步标记：标记根因模块在标记根因类型下存在的日志模式和指标异常检测结果。也就是说，作为一种可选实现，标记训练数据可以包括标记根因模块在标记根因类型下存在的日志模式和指标异常检测结果。基于此，在进一步的一些实施例中，本申请实施例可将业务系统的日志模式和指标异常检测结果，分别与标记根因模块在标记根因类型下存在的日志模式和指标异常检测结果进行匹配，从而从业务系统的日志模式和指标异常检测结果中确定出与标记训练数据相匹配的目标日志模式和目标指标异常检测结果。例如，业务系统的某一日志模式为某一标记根因模块在某一标记根因类型下存在的日志模式，则该日志模式可成为该标记根因模块在该标记根因类型下的目标日志模式；业务系统的某一指标异常检测结果为某一标记根因模块在某一标记根因类型下存在的指标异常检测结果，则该指标异常检测结果可成为该标记根因模块在该标记根因类型下的目标指标异常检测结果。

在一些实施例中，标记训练数据可以通过故障注入的方式得到，例如通过模拟故障异常场景，来积累样本数据，从而通过分析样本数据中功能模块在各异常类型下存在的日志模式和指标异常检测结果，以实现获得标记训练数据。作为一种示例，图3D示出了标记训练数据的一种结构示例图。如图3D所示，标记训练数据可以有多条，例如标记训练数据31至3n，一条标记训练数据可以标记一个标记根因模块在一个标记根因类型下存在的日志模式和指标异常检测结果。假设业务系统的指标异常检测结果包含指标a的异常检测结果和指标b的异常检测结果，业务系统的日志模式包含日志模式c和日志模式d，则可产生4个数据特征；例如，结合图3D所示，数据特征1为指标a的异常检测结果，数据特征2为指标b的异常检测结果，数据特征3为日志模式c，数据特征4为日志模式d。在此基础上，标记训练数据可标记一个标记根因模块在一个标记根因类型下是否存在数据特征1至4，以实现对标记根因模块在标记根因类型下存在的日志模式和指标异常检测结果进行标记。例如，结合图3D所示，标记训练数据31可以标记ZK在ZK不可用的标记根因类型下，存在数据特征1、2和4；标记训练数据32可以标记ZK在ZK闪断的标记根因类型下，存在数据特征2、3和4。需要说明的是，一个数据特征在标记根因模块的标记根因类型下存在，则该数据特征可以在标记训练数据中标记为1，否则，标记为0。例如，图3D中数据特征1（指标a的异常检测结果）在标记训练数据31中存在，则数据特征1在标记训练数据31中被标记为1，而数据特征1在标记训练数据32中不存在，则数据特征1在标记训练数据32中被标记为0。

在进一步的一些实施例中，本申请实施例可基于TF（Term Frequency，词频）以及IDF(Inverse Document Frequency，逆文本频率指数)技术，从业务系统的日志模式以及指标异常检测结果中分别确定出高频词，从而基于日志模式以及指标异常检测结果的高频词分别与标记训练数据进行匹配，以得出目标日志模式和目标指标异常检测结果。

在本申请实施例中，特征选择阶段330所确定的目标日志模式和目标指标异常检测结果可形成目标数据特征。例如目标数据特征可以包括目标日志模式和目标指标异常检测结果。进一步的，本申请实施例可根据目标数据特征以及目标数据特征在标记训练数据中对应的标记根因模块和标记根因类型，形成特征矩阵。特征矩阵的结构与标记训练数据的结构类似，可参照图3D所示，此处不再展开说明。

在关系构建阶段340，运维服务器可构建目标数据特征之间的第一依赖关系（例如构建目标日志模式之间的依赖关系，和构建目标指标异常检测结果之间的依赖关系），以及构建目标数据特征与业务系统的候选功能模块之间的第二依赖关系（例如构建目标日志模式与功能模块之间的依赖关系，构建目标指标异常检测结果与功能模块之间的依赖关系），和构建候选功能模块与候选异常类型之间的第三依赖关系，以构建出目标关系。

在一些实施例中，本申请实施例可通过构建概率图模型，以实现构建上述具有三层依赖关系的目标关系。图4A示出了本申请实施例提供的概率图模型的结构示例图。如图4A所示，该概率图模型可以包括特征层410和根因层420。在特征层410中，目标数据特征（例如目标日志模式和目标指标异常检测结果）可以被抽象为特征节点，且一个目标数据特征对应一个特征节点（例如一个目标日志模式对应一个特征节点，一个目标指标异常检测结果对应一个特征节点等），本申请实施例可通过构建特征层中特征节点之间的依赖关系，以实现构建目标数据特征之间的第一依赖关系。作为可选实现，本申请实施例可通过PC算法学习得到特征层中特征节点之间的依赖关系。

在基于PC算法学习特征层中特征节点之间的依赖关系的可选实现上，本申请实施例可构建特征层中特征节点之间的全连接图，然后利用独立性检验方法判别任意两个特征节点之间是否独立，进而基于特征节点之间的独立性确定特征节点之间的依赖关系（例如特征节点之间的因果方向），从而构建出特征层中特征节点之间的依赖关系。

在构建出特征层中特征节点之间的依赖关系之后，本申请实施例可基于预先设定的数据特征与功能模块之间的依赖关系，确定特征层中的叶子特征节点（特征层中的叶子特征节点表示无下一步依赖的末端目标数据特征）所依赖的候选功能模块；从而在根因层420，将各个候选功能模块抽象为根因层的模块节点，并基于数据特征与功能模块之间的依赖关系，构建出特征层的叶子特征节点与根因层的模块节点之间的依赖关系，以实现构建出目标数据特征与候选功能模块之间的第二依赖关系。在一些实施例中，数据特征与功能模块之间的依赖关系可以预先设定在CMDB等数据库中，例如CMDB可以记录指标与功能模块之间的依赖关系等。需要说明的是，CMDB是一个逻辑数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)等。

在构建出根因层中的模块节点（一个模块节点可对应一个上述确定的候选功能模块），以及特征层的叶子特征节点与根因层的模块节点之间的依赖关系之后，本申请实施例可基于预先设定的功能模块与异常类型之间的依赖关系，确定根因层的模块节点所依赖的候选异常类型，并将各模块节点所依赖的候选异常类型抽象为类型节点，以实现构建出候选功能模块与候选异常类型之间的第三依赖关系。在一些实施例中，功能模块与异常类型之间的依赖关系可以预先设定在CMDB等数据库中。

本申请实施例可通过构建概率图模型，以实现构建目标数据特征之间的第一依赖关系、目标数据特征与候选功能模块之间的第二依赖关系、候选功能模块与候选异常类型之间的第三依赖关系，从而实现构建目标关系。例如，概率图模型可以包括多个节点，该多个节点可以包括特征层的特征节点（对应目标数据特征）、根因层的模块节点（对应候选功能模块）、根因层的类型节点（对应候选异常类型），从而本申请实施例可通过构建特征节点之间的依赖关系、特征节点与模块节点之间的依赖关系、模块节点与类型节点之间的依赖关系，以实现构建概率图模型。在一些实施例中，本申请实施例提供的概率图模型可以是优化的BN（Bayesian Networks，贝叶斯网络）模型。需要说明的是，BN模型一般只有特征层的结构，而没有根因层的结构以及特征层与根因层之间的关系。本申请实施例通过对BN模型进行优化，使得优化的BN模型可以具有多层次的网络结构，以实现本申请实施例概率图模型所要求的特征层、根因层和特征层与根因层之间的网络结构。本申请实施例优化的BN模型可以称为KHBN（Knowledge-informed Hierarchical Bayesian Network，基于知识的层次贝叶斯网络）模型。

回到图3B所示，在根因推断阶段350，运维服务器可根据特征矩阵（由目标数据特征与标记训练数据中对应的标记根因模块和标记根因类型形成），以及关系构建阶段340构建的目标关系，从目标关系中的候选异常类型中确定出根因类型。在一些实施例中，本申请实施例可根据特征矩阵以及构建的目标关系，确定目标关系中各候选异常类型的异常概率，从而将异常概率最大的候选异常类型确定为根因类型。本申请实施例可至少根据根因类型确定出业务系统的根因定位结果。例如，根因类型所对应的候选功能模块可确定为根因模块，本申请实施例可由根因类型，或者，根因类型和根因模块形成根因定位结果。

作为可选实现，本申请实施例可根据特征矩阵以及目标关系，使用exactinference算法对目标关系中的候选异常类型进行根因推断，从而推断出目标关系中各候选异常类型的异常概率，将异常概率最大的候选异常类型确定为根因类型。例如，在通过构建概率图模型（例如KHBN模型）来构建目标关系的基础上，本申请实施例可根据特征矩阵以及概率图模型，使用exact inference算法对概率图模型的根因层中的类型节点进行根因推断，从而推断出各类型节点的异常概率，将异常概率最大的类型节点作为根因类型节点，从而将根因类型节点对应的异常类型确定为根因类型。

在进一步的一些实施例中，如果根因类型的异常概率小于概率阈值（说明目标关系中候选异常类型的最大异常概率小于概率阈值），则本申请实施例可认为出现了新的异常类型，当前的根因类型并无法表达该新的异常类型，从而本申请实施例并不将根因类型作为根因定位结果进行输出，而是将根因类型所对应的根因模块作为根因定位结果进行输出。也就是说，在根因类型的异常概率小于概率阈值，出现新的异常类型时，本申请实施例将根因定位结果定位到根因类型对应的根因模块上。作为可选实现，在构建概率图模型（例如KHBN模型）的基础上，本申请实施例可在判断根因类型节点的异常概率小于概率阈值时，认为出现了新的异常类型，从而将根因类型节点在概率图模型中对应的根因模块节点所对应的根因模块，作为根因定位结果。

在进一步的一些实施例中，本申请实施例还可基于确定的根因定位结果，提供根因定位界面，该根因定位界面可展示所确定的根因定位结果、进行根因定位使用的数据特征以及数据特征中异常的目标数据特征；其中，根因定位界面展示的根因定位结果可以包括根因模块和根因模块的根因类型。在一个示例中，图4B示出了本申请实施例提供的根因定位界面的示例图。如图4B所示，根因定位界面可以展示根因模块为ZK、根因类型为服务闪断的根因定位结果，并且可以采用表格的形式展示根因定位使用到的数据特征（例如指标异常检测结果、日志模式等），并且采用采样值的方式对异常的目标数据特征进行标识，例如数据特征的采样值为0，则表示指标异常检测结果为正常或者日志模式未出现，数据特征的采样值为1，则表示指标异常检测结果为异常或者日志模式出现。

本申请实施例提供的根因定位方法具有如下优点：同时考虑了文本类型的日志文本、连续数值型的指标、以及树状结构的实体依赖关系，来进行根因定位，能够提升根因定位的准确性。利用优化的FT-tree算法实现自动的日志模式提取，并利用自然语言处理技术对海量日志进行聚类，可以极大程度地压缩日志量，提取出日志文本的关键模式（即日志模式）。利用周期分解和统计检验等时序异常检测技术，可以对多种成分的指标在不同异常类型下进行异常检测，同时将不同数量级的指标归一化为0、1类型的时序特征，提升了指标异常检测的效率和准确性。基于日志模式、指标异常检测结果等数据特征，利用PC算法学习因果关系，同时结合CMDB中的先验知识构建分层的概率图模型，并基于exact inference算法进行根因推断，可以有效、精准的进行根因定位，并处理业务系统新出现的异常类型。

进一步的，本申请实施例的模型架构可以部署在大数据处理等云计算平台，具备处理的实时性，可以满足流式计算平台快速定位根因的需求。本申请实施例提供的根因定位方案以及模型架构可以应用于多种不同架构的云计算平台，具备通用型和拓展性；并且对于不同的云计算平台中的部分公共模块，可以利用迁移学习的方式来提升模型的学习效果，减少故障演练成本。

下面对本申请实施例提供的根因定位装置进行介绍。下文描述的根因定位装置可以认为是运维服务器，为实现本申请实施例提供的根因定位方法所需设置的功能单元。下文描述的装置内容可与上文描述的方法内容相互对应参照。

作为可选实现，图5示出了本申请实施例提供的根因定位装置的框图。参照图5所示，该根因定位装置可以包括：

数据及特征处理单元510，用于获取业务系统的运维数据，以及确定所述运维数据异常的目标数据特征；

关系构建单元520，用于构建所述目标数据特征之间的第一依赖关系、所述目标数据特征与候选功能模块之间的第二依赖关系、以及候选功能模块与候选异常类型之间的第三依赖关系，以得到目标关系；其中，所述候选功能模块为所述业务系统中目标数据特征依赖的功能模块，候选异常类型为所述候选功能模块存在的异常类型；

根因推断单元530，用于对所述目标关系中的候选异常类型进行根因推断，以得到各候选异常类型的异常概率；根据各候选异常类型的异常概率，从候选异常类型中确定根因类型；

结果确定单元540，用于根据所述根因类型，确定所述业务系统的根因定位结果。

在一些实施例中，关系构建单元520，用于构建目标数据特征与候选功能模块之间的第二依赖关系包括：

确定所述第一依赖关系中无下一步依赖的末端目标数据特征，根据预设的数据特征与功能模块之间的依赖关系，确定所述末端目标数据特征依赖的候选功能模块；

构建所述末端目标数据特征至所述候选功能模块的依赖关系，以构建出所述第二依赖关系。

在一些实施例中，关系构建单元520，用于构建候选功能模块与候选异常类型之间的第三依赖关系包括：

根据预设的功能模块与异常类型之间的依赖关系，确定所述候选功能模块依赖的候选异常类型；构建所述候选功能模块至所述候选异常类型的依赖关系，以构建出所述第三依赖关系。

在一些实施例中，所述目标关系由概率图模型表示，所述概率图模型包括特征层和根因层；所述特征层包括与所述目标数据特征对应的特征节点，所述根因层包括与所述候选功能模块对应的模块节点，以及与所述候选异常类型对应的类型节点；所述第一依赖关系为特征节点之间的依赖关系，所述第二依赖关系为叶子特征节点至模块节点的依赖关系，所述第三依赖关系为模块节点至类型节点的依赖关系。

在一些实施例中，关系构建单元520，用于构建所述目标数据特征之间的第一依赖关系包括：

将目标数据特征抽象为所述特征层的特征节点，构建特征节点之间的依赖关系，以构建出所述第一依赖关系。

在一些实施例中，所述末端目标数据特征对应所述特征层的叶子特征节点。关系构建单元520，用于构建所述末端目标数据特征至所述候选功能模块的依赖关系，以构建出所述第二依赖关系包括：

将所述候选功能模块抽象为所述根因层的模块节点，构建所述叶子特征节点至所述模块节点的依赖关系，以构建出所述第二依赖关系。

在一些实施例中，关系构建单元520，用于构建所述候选功能模块至所述候选异常类型的依赖关系，以构建出所述第三依赖关系包括：

将所述候选异常类型抽象为所述根因层的类型节点，构建所述模块节点至所述类型节点的依赖关系，以构建出所述第三依赖关系。

在一些实施例中，根因推断单元530，用于对所述目标关系中的候选异常类型进行根因推断，以得到各候选异常类型的异常概率包括：

对概率图模型中的类型节点进行根因推断，以得到各类型节点的异常概率；

相应的，根因推断单元530，用于根据各候选异常类型的异常概率，从候选异常类型中确定根因类型包括：

根据各类型节点的异常概率，从类型节点中确定根因类型节点；将所述根因类型节点所对应的候选异常类型，确定为根因类型。

在一些实施例中，预设的数据特征与功能模块之间的依赖关系、以及预设的功能模块与异常类型之间的依赖关系，可以记录在CMDB中。

在一些实施例中，所述运维数据包括业务系统的日志文本和指标。数据及特征处理单元510，用于确定所述运维数据异常的目标数据特征包括：

确定所述日志文本的日志模式，从日志模式中确定出与标记训练数据相对应的目标日志模式；

以及，确定所述指标的指标异常检测结果，从指标异常检测结果中确定出与标记训练数据相对应的目标指标异常检测结果；

其中，所述目标日志模式和目标指标异常检测结果形成所述目标数据特征，所述标记训练数据包括预先标记的标记根因模块在标记根因类型下存在的日志模式和指标异常检测结果。

在一些实施例中，数据及特征处理单元510，用于确定所述日志文本的日志模式包括：

对所述日志文本进行预处理；提取预处理后的日志文本中的高频词，基于提取的日志文本的高频词，形成日志文本的日志子模式；将日志文本的日志子模式转换为日志子模式特征；将相似的日志子模式特征进行聚类，得到日志模式。

在一些实施例中，数据及特征处理单元510，用于确定所述指标的指标异常检测结果包括：

将指标的时间序列分解为多种成分；基于预设的成分、异常类型与检验方法的对应关系，使用与指标的时间序列的成分以及需要检测的异常类型相对应的检验方法，对指标进行异常检测，以得到指标异常检测结果。

在一些实施例中，数据及特征处理单元510，用于提取预处理后的日志文本中的高频词包括：

基于优化的FT-tree中的叶子节点个数，剪除预处理后的日志文本中的低频词并保留高频词，以得到预处理后的日志文本的高频词；其中，优化的FT-tree为树状数据结构且以字典结构存储预处理后的日志文本的词，预处理后的日志文本中的一个词对应优化的FT-tree中的一个节点。

在一些实施例中，本申请实施例提供的根因定位装置还可用于：根据目标数据特征以及目标数据特征在标记训练数据中对应的标记根因模块和标记根因类型，形成特征矩阵；

相应的，根因推断单元530，用于对所述目标关系中的候选异常类型进行根因推断包括：

根据特征矩阵以及所述目标关系，使用精确推断算法对所述目标关系中的候选异常类型进行根因推断。

在一些实施例中，结果确定单元540，用于根据所述根因类型，确定所述业务系统的根因定位结果包括：

将所述根因类型，和/或，所述根因类型在所述目标关系中对应的根因模块，确定为所述根因定位结果；

或者，若所述根因类型的概率小于概率阈值，将所述根因类型在所述目标关系中对应的根因模块，确定为所述根因定位结果。

在一些实施例中，本申请实施例提供的根因定位装置还可用于：提供根因定位界面，所述根因定位界面展示有根因定位结果、根因定位使用的数据特征以及数据特征中异常的目标数据特征；其中，所述根因定位结果包括根因模块和根因模块的根因类型。

本申请实施例还提供一种运维服务器。该运维服务器可以通过设置上述提供的根因定位装置，以实现本申请实施例提供的根因定位方法。在一些实施例中，图6示出了运维服务器的框图。如图6所示，该运维服务器可以包括：至少一个处理器61，至少一个通信接口62，至少一个存储器63和至少一个通信总线64。

在本申请实施例中，处理器61、通信接口62、存储器63、通信总线64的数量为至少一个，且处理器61、通信接口62、存储器63通过通信总线64完成相互间的通信。

可选的，通信接口62可以为用于进行网络通信的通信模块的接口。

可选的，处理器61可能是CPU（中央处理器），GPU（Graphics Processing Unit，图形处理器），NPU（嵌入式神经网络处理器），FPGA（Field Programmable Gate Array，现场可编程逻辑门阵列），TPU（张量处理单元），AI芯片，特定集成电路ASIC（ApplicationSpecific Integrated Circuit），或者是被配置成实施本申请实施例的一个或多个集成电路等。

存储器63可能包含高速RAM存储器，也可能还包括非易失性存储器（non-volatilememory），例如至少一个磁盘存储器。

其中，存储器63存储一条或多条计算机可执行指令，处理器61调用所述一条或多条计算机可执行指令，以执行本申请实施例提供的根因定位方法。

本申请实施例还提供一种存储介质，该存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令被执行时实现如本申请实施例提供的根因定位方法。

本申请实施例还提供一种计算机程序，该计算机程序被执行时实现如本申请实施例提供的根因定位方法。

上文描述了本申请实施例提供的多个实施例方案，各实施例方案介绍的各可选方式可在不冲突的情况下相互结合、交叉引用，从而延伸出多种可能的实施例方案，这些均可认为是本申请实施例披露、公开的实施例方案。

虽然本申请实施例披露如上，但本申请并非限定于此。任何本领域技术人员，在不脱离本申请的精神和范围内，均可作各种更动与修改，因此本申请的保护范围应当以权利要求所限定的范围为准。

Claims (14)

1.一种根因定位方法，其中，包括：

获取业务系统的运维数据，以及确定所述运维数据异常的目标数据特征；

构建所述目标数据特征之间的第一依赖关系、所述目标数据特征与候选功能模块之间的第二依赖关系、以及候选功能模块与候选异常类型之间的第三依赖关系，以得到目标关系；其中，所述候选功能模块为所述业务系统中目标数据特征依赖的功能模块，候选异常类型为所述候选功能模块存在的异常类型；

对所述目标关系中的候选异常类型进行根因推断，以得到各候选异常类型的异常概率；根据各候选异常类型的异常概率，从候选异常类型中确定根因类型；

根据所述根因类型，确定所述业务系统的根因定位结果。

2.根据权利要求1所述的方法，其中，所述构建目标数据特征与候选功能模块之间的第二依赖关系包括：

确定所述第一依赖关系中无下一步依赖的末端目标数据特征，根据预设的数据特征与功能模块之间的依赖关系，确定所述末端目标数据特征依赖的候选功能模块；

构建所述末端目标数据特征至所述候选功能模块的依赖关系，以构建出所述第二依赖关系。

3.根据权利要求2所述的方法，其中，所述构建候选功能模块与候选异常类型之间的第三依赖关系包括：

根据预设的功能模块与异常类型之间的依赖关系，确定所述候选功能模块依赖的候选异常类型；构建所述候选功能模块至所述候选异常类型的依赖关系，以构建出所述第三依赖关系。

4.根据权利要求3所述的方法，其中，所述目标关系由概率图模型表示，所述概率图模型包括特征层和根因层；所述特征层包括与所述目标数据特征对应的特征节点，所述根因层包括与所述候选功能模块对应的模块节点，以及与所述候选异常类型对应的类型节点；所述第一依赖关系为特征节点之间的依赖关系，所述第二依赖关系为叶子特征节点至模块节点的依赖关系，所述第三依赖关系为模块节点至类型节点的依赖关系。

5.根据权利要求4所述的方法，其中，所述构建所述目标数据特征之间的第一依赖关系包括：将目标数据特征抽象为所述特征层的特征节点，构建特征节点之间的依赖关系，以构建出所述第一依赖关系；

所述末端目标数据特征对应所述特征层的叶子特征节点；所述构建所述末端目标数据特征至所述候选功能模块的依赖关系，以构建出所述第二依赖关系包括：将所述候选功能模块抽象为所述根因层的模块节点，构建所述叶子特征节点至所述模块节点的依赖关系，以构建出所述第二依赖关系；

所述构建所述候选功能模块至所述候选异常类型的依赖关系，以构建出所述第三依赖关系包括：将所述候选异常类型抽象为所述根因层的类型节点，构建所述模块节点至所述类型节点的依赖关系，以构建出所述第三依赖关系。

6.根据权利要求4或5所述的方法，其中，所述对所述目标关系中的候选异常类型进行根因推断，以得到各候选异常类型的异常概率包括：

对概率图模型中的类型节点进行根因推断，以得到各类型节点的异常概率；

所述根据各候选异常类型的异常概率，从候选异常类型中确定根因类型包括：

根据各类型节点的异常概率，从类型节点中确定根因类型节点；将所述根因类型节点所对应的候选异常类型，确定为根因类型。

7.根据权利要求3-5任一项所述的方法，其中，预设的数据特征与功能模块之间的依赖关系、以及预设的功能模块与异常类型之间的依赖关系，记录在配置管理数据库CMDB中。

8.根据权利要求1所述的方法，其中，所述运维数据包括业务系统的日志文本和指标；所述确定所述运维数据异常的目标数据特征包括：

确定所述日志文本的日志模式，从日志模式中确定出与标记训练数据相对应的目标日志模式；

以及，确定所述指标的指标异常检测结果，从指标异常检测结果中确定出与标记训练数据相对应的目标指标异常检测结果；

其中，所述目标日志模式和目标指标异常检测结果形成所述目标数据特征，所述标记训练数据包括预先标记的标记根因模块在标记根因类型下存在的日志模式和指标异常检测结果。

9.根据权利要求8所述的方法，其中，所述确定所述日志文本的日志模式包括：对所述日志文本进行预处理；提取预处理后的日志文本中的高频词，基于提取的日志文本的高频词，形成日志文本的日志子模式；将日志文本的日志子模式转换为日志子模式特征；将相似的日志子模式特征进行聚类，得到日志模式；

所述确定所述指标的指标异常检测结果包括：将指标的时间序列分解为多种成分；基于预设的成分、异常类型与检验方法的对应关系，使用与指标的时间序列的成分以及需要检测的异常类型相对应的检验方法，对指标进行异常检测，以得到指标异常检测结果。

10.根据权利要求9所述的方法，其中，所述提取预处理后的日志文本中的高频词包括：

基于优化的频率模式树FT-tree中的叶子节点个数，剪除预处理后的日志文本中的低频词并保留高频词，以得到预处理后的日志文本的高频词；其中，优化的FT-tree为树状数据结构且以字典结构存储预处理后的日志文本的词，预处理后的日志文本中的一个词对应优化的FT-tree中的一个节点。

11.根据权利要求8所述的方法，其中，还包括：根据目标数据特征以及目标数据特征在标记训练数据中对应的标记根因模块和标记根因类型，形成特征矩阵；

所述对所述目标关系中的候选异常类型进行根因推断包括：

根据特征矩阵以及所述目标关系，使用精确推断算法对所述目标关系中的候选异常类型进行根因推断；

所述根据所述根因类型，确定所述业务系统的根因定位结果包括：

将所述根因类型，和/或，所述根因类型在所述目标关系中对应的根因模块，确定为所述根因定位结果；

或者，若所述根因类型的概率小于概率阈值，将所述根因类型在所述目标关系中对应的根因模块，确定为所述根因定位结果。

12.根据权利要求1所述的方法，其中，还包括：

提供根因定位界面，所述根因定位界面展示有根因定位结果、根因定位使用的数据特征以及数据特征中异常的目标数据特征；其中，所述根因定位结果包括根因模块和根因模块的根因类型。

13.一种运维服务器，其中，包括至少一个存储器和至少一个处理器，所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如权利要求1-12任一项所述的根因定位方法。

14.一种存储介质，其中，所述存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令被执行时实现如权利要求1-12任一项所述的根因定位方法。

Images