一种基于知识图谱的云原生系统故障分析方法

摘要

本申请公开了一种基于知识图谱的云原生系统故障分析方法，包括：获取云原生系统中的原始数据，并基于原始数据构建知识图谱，得到图数据；通过异常检测模型对图数据进行异常检测，得到异常节点；计算异常节点和异常节点对应的副本节点的相似度，并基于相似度进行故障根因定位，其中，异常节点对应的副本节点为与异常节点同类型的节点。本申请解决了现有技术忽略了实体之间的交互关系，只能定位到发生故障的实体，难以快速和准确地定位云原生系统的故障根因的技术问题。

权利要求

1.一种基于知识图谱的云原生系统故障分析方法，其特征在于，包括：获取云原生系统中的原始数据，并基于所述原始数据构建知识图谱，得到图数据，所述原始数据包括实体信息和网络连接数据，所述获取云原生系统的原始数据包括：获取云原生系统中的所述实体信息，所述实体包括容器，Process和File；通过nsenter工具进入容器的命名空间，将宿主机的netstat文件所在目录挂载到容器的文件系统上；在容器中执行nsenter命令获取所述网络连接数据；

所述基于所述原始数据构建知识图谱，得到图数据包括：对所述原始数据依次进行实体抽取、实体关系抽取以及实体属性抽取，其中，所述实体属性包括静态属性和动态属性；基于抽取的所述实体、所述实体关系以及所述实体属性构建知识图谱，得到图数据；

通过异常检测模型对所述图数据进行异常检测，得到异常节点；

计算所述异常节点和所述异常节点对应的副本节点的相似度，并基于所述相似度进行故障根因定位，其中，所述异常节点对应的副本节点为与所述异常节点同类型的节点。

2.根据权利要求1所述的基于知识图谱的云原生系统故障分析方法，其特征在于，所述计算所述异常节点和所述异常节点对应的副本节点的相似度，并基于所述相似度进行故障根因定位，包括：

计算所述异常节点和所述异常节点对应的副本节点的动态属性相似度、静态属性相似度，分别得到动态属性相似度分值和静态属性相似度分值；

基于所述动态属性相似度分值和所述静态属性相似度分值确定异常属性。

3.根据权利要求2所述的基于知识图谱的云原生系统故障分析方法，其特征在于，计算所述异常节点和所述异常节点对应的副本节点的动态属性相似度，得到动态属性相似度分值，包括：

获取预置时间段内所述异常节点和所述异常节点对应的副本节点的动态属性，生成异常节点动态属性向量和副本节点动态属性向量；

计算所述异常节点动态属性向量和所述副本节点动态属性向量的余弦相似度，得到动态属性相似度分值。

4.根据权利要求2所述的基于知识图谱的云原生系统故障分析方法，其特征在于，计算所述异常节点和所述异常节点对应的副本节点的静态属性相似度，得到静态属性相似度分值，包括：

对所述异常节点的静态属性、所述异常节点对应的副本节点的静态属性依次进行分词、停用词过滤和oneHot编码，分别得到异常节点文本向量和副本节点文本向量；

计算所述异常节点文本向量和所述副本节点文本向量的余弦相似度，得到静态属性相似度分值。

5.根据权利要求1所述的基于知识图谱的云原生系统故障分析方法，其特征在于，所述通过异常检测模型对所述图数据进行异常检测，得到异常节点，包括：提取所述图数据中各节点的有向拓扑关系，得到邻接矩阵，提取所述图数据中各节点的属性，得到属性矩阵；

通过异常检测模型对所述邻接矩阵和所述属性矩阵进行异常检测，得到异常节点。

6.根据权利要求5所述的基于知识图谱的云原生系统故障分析方法，其特征在于，所述异常检测模型包括编码器和解码器；

所述通过异常检测模型对所述邻接矩阵和所述属性矩阵进行异常检测，得到异常节点，包括：

通过所述异常检测模型中的所述编码器对所述邻接矩阵和所述属性矩阵进行编码处理，得到编码特征向量，并将所述编码特征向量和所述邻接矩阵输入到所述解码器；

通过所述异常检测模型中的所述解码器结合所述邻接矩阵和所述编码特征向量进行解码处理，得到重构邻接矩阵和重构属性矩阵；

通过所述异常检测模型基于所述邻接矩阵、所述属性矩阵和所述重构邻接矩阵、所述重构属性矩阵计算重构误差，并基于所述重构误差确定异常节点。

7.根据权利要求6所述的基于知识图谱的云原生系统故障分析方法，其特征在于，所述编码器包括依次连接的图卷积网络和递归神经网络；

所述通过所述异常检测模型中的所述编码器对所述邻接矩阵和所述属性矩阵进行编码处理，得到编码特征向量，包括：通过所述图卷积网络将所述邻接矩阵和所述属性矩阵映射到低维空间，得到低维特征向量；

通过所述递归神经网络对所述低维特征向量进行特征提取，得到编码特征向量。

8.根据权利要求6所述的基于知识图谱的云原生系统故障分析方法，其特征在于，所述解码器包括拓扑结构重构模块和属性信息重构模块，其中，所述属性信息重构模块包括依次连接的递归神经网络和图卷积网络；

所述通过所述异常检测模型中的所述解码器结合所述邻接矩阵和所述编码特征向量进行解码处理，得到重构邻接矩阵和重构属性矩阵，包括：通过所述拓扑结构重构模块对所述编码特征向量进行解码处理，得到重构邻接矩阵；

通过所述属性信息重构模块中的所述递归神经网络对所述编码特征向量进行解码处理，得到输出结果；

通过所述属性信息重构模块中的所述图卷积网络基于所述邻接矩阵对所述输出结果进行解码处理，得到重构属性矩阵。

说明书

一种基于知识图谱的云原生系统故障分析方法

技术领域

[0001] 本申请涉及故障分析技术领域，尤其涉及一种基于知识图谱的云原生系统故障分析方法。

背景技术

[0002] 随着容器化、虚拟化等技术的发展，越来越多的软件系统迁移到云环境中，云原生系统已经成为应用程序开发和部署的主流解决方案。云原生系统面向微服务，通过容器打
包、微服务部署的方式将应用程序解耦到多个服务中。然而，在这种微服务的架构中，一个
应用可以产生数百甚至数千个微服务，并且这些微服务之间往往具有错综复杂的交互关
系。云原生系统庞大的微服务架构和海量的告警、指标数据，给运维工作带来极大的挑战和
压力。一旦出现问题，将给企业带来重大的业务影响，造成巨大的业务损失。

[0003] 云原生系统中包含海量的实体，如微服务、容器、进程等，各实体之间存在错综复杂的交互关系，而云原生系统出现故障时，故障会沿着实体之间的交互网传播，使得云原生
系统的故障定位难度更大。而现有的故障定位方法忽略了实体之间的交互关系，只能定位
到发生故障的实体，难以快速和准确地定位云原生系统的故障根因。

发明内容

[0004] 本申请提供了一种基于知识图谱的云原生系统故障分析方法，用于解决现有技术忽略了实体之间的交互关系，只能定位到发生故障的实体，难以快速和准确地定位云原生
系统的故障根因的技术问题。

[0005] 有鉴于此，本申请第一方面提供了一种基于知识图谱的云原生系统故障分析方法，包括：

[0006] 获取云原生系统中的原始数据，并基于所述原始数据构建知识图谱，得到图数据；

[0007] 通过异常检测模型对所述图数据进行异常检测，得到异常节点；

[0008] 计算所述异常节点和所述异常节点对应的副本节点的相似度，并基于所述相似度进行故障根因定位，其中，所述异常节点对应的副本节点为与所述异常节点同类型的节点。

[0009] 可选的，所述原始数据包括实体信息和网络连接数据；

[0010] 所述获取云原生系统中的原始数据，包括：

[0011] 获取云原生系统中的所述实体信息，所述实体至少包括容器；

[0012] 通过nsenter工具进入容器的命名空间，将宿主机的netstat文件所在目录挂载到容器的文件系统上；

[0013] 在容器中执行nsenter命令获取所述网络连接数据。

[0014] 可选的，所述基于所述原始数据构建知识图谱，得到图数据，包括：

[0015] 对所述原始数据依次进行实体抽取、实体关系抽取以及实体属性抽取，其中，所述实体属性包括静态属性和动态属性；

[0016] 基于抽取的所述实体、所述实体关系以及所述实体属性构建知识图谱，得到图数据。

[0017] 可选的，所述计算所述异常节点和所述异常节点对应的副本节点的相似度，并基于所述相似度进行故障根因定位，包括：

[0018] 计算所述异常节点和所述异常节点对应的副本节点的动态属性相似度、静态属性相似度，分别得到动态属性相似度分值和静态属性相似度分值；

[0019] 基于所述动态属性相似度分值和所述静态属性相似度分值确定异常属性。

[0020] 可选的，计算所述异常节点和所述异常节点对应的副本节点的动态属性相似度，得到动态属性相似度分值，包括：

[0021] 获取预置时间段内所述异常节点和所述异常节点对应的副本节点的动态属性，生成异常节点动态属性向量和副本节点动态属性向量；

[0022] 计算所述异常节点动态属性向量和所述副本节点动态属性向量的余弦相似度，得到动态属性相似度分值。

[0023] 可选的，计算所述异常节点和所述异常节点对应的副本节点的静态属性相似度，得到静态属性相似度分值，包括：

[0024] 对所述异常节点的静态属性、所述异常节点对应的副本节点的静态属性依次进行分词、停用词过滤和oneHot编码，分别得到异常节点文本向量和副本节点文本向量；

[0025] 计算所述异常节点文本向量和所述副本节点文本向量的余弦相似度，得到静态属性相似度分值。

[0026] 可选的，所述通过异常检测模型对所述图数据进行异常检测，得到异常节点，包括：

[0027] 提取所述图数据中各节点的有向拓扑关系，得到邻接矩阵，提取所述图数据中各节点的属性，得到属性矩阵；

[0028] 通过异常检测模型对所述邻接矩阵和所述属性矩阵进行异常检测，得到异常节点。

[0029] 可选的，所述异常检测模型包括编码器和解码器；

[0030] 所述通过异常检测模型对所述邻接矩阵和所述属性矩阵进行异常检测，得到异常节点，包括：

[0031] 通过所述异常检测模型中的所述编码器对所述邻接矩阵和所述属性矩阵进行编码处理，得到编码特征向量，并将所述编码特征向量和所述邻接矩阵输入到所述解码器；

[0032] 通过所述异常检测模型中的所述解码器结合所述邻接矩阵和所述编码特征向量进行解码处理，得到重构邻接矩阵和重构属性矩阵；

[0033] 通过所述异常检测模型基于所述邻接矩阵、所述属性矩阵和所述重构邻接矩阵、所述重构属性矩阵计算重构误差，并基于所述重构误差确定异常节点。

[0034] 可选的，所述编码器包括依次连接的图卷积网络和递归神经网络；

[0035] 所述通过所述异常检测模型中的所述编码器对所述邻接矩阵和所述属性矩阵进行编码处理，得到编码特征向量，包括：

[0036] 通过所述图卷积网络将所述邻接矩阵和所述属性矩阵映射到低维空间，得到低维特征向量；

[0037] 通过所述递归神经网络对所述低维特征向量进行特征提取，得到编码特征向量。

[0038] 可选的，所述解码器包括拓扑结构重构模块和属性信息重构模块，其中，所述属性信息重构模块包括依次连接的递归神经网络和图卷积网络；

[0039] 所述通过所述异常检测模型中的所述解码器结合所述邻接矩阵和所述编码特征向量进行解码处理，得到重构邻接矩阵和重构属性矩阵，包括：

[0040] 通过所述拓扑结构重构模块对所述编码特征向量进行解码处理，得到重构邻接矩阵；

[0041] 通过所述属性信息重构模块中的所述递归神经网络对所述编码特征向量进行解码处理，得到输出结果；

[0042] 通过所述属性信息重构模块中的所述图卷积网络基于所述邻接矩阵对所述输出结果进行解码处理，得到重构属性矩阵。

[0043] 从以上技术方案可以看出，本申请具有以下优点：

[0044] 本申请提供了一种基于知识图谱的云原生系统故障分析方法，包括：获取云原生系统中的原始数据，并基于原始数据构建知识图谱，得到图数据；通过异常检测模型对图数
据进行异常检测，得到异常节点；计算异常节点和异常节点对应的副本节点的相似度，并基
于相似度进行故障根因定位，其中，异常节点对应的副本节点为与异常节点同类型的节点。

[0045] 本申请中，通过获取云原生系统中的原始数据，根据原始数据中各实体的属性以及依赖关系构建知识图谱，得到图数据，再通过异常检测模型对带有属性信息和依赖关系
的图数据进行异常检测，得到异常节点，考虑了云原生系统中各实体之间的相互关系，可以
快速和准确地定位故障；并且本申请通过计算异常节点与异常节点为同类型的节点的相似
度，来进一步进行故障根因定位，可以更加细粒度和准确地定位到故障根因，解决了现有技
术忽略了实体之间的交互关系，只能定位到发生故障的实体，难以快速和准确地定位云原
生系统的故障根因的技术问题。

附图说明

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

[0047] 图1为本申请实施例提供的一种基于知识图谱的云原生系统故障分析方法的一个流程示意图；

[0048] 图2为本申请实施例提供的一种实体依赖关系模型的一个示意图；

[0049] 图3为本申请实施例提供的一种图数据的一个示意图；

[0050] 图4为本申请实施例提供的一种图数据构建过程的一个示意图；

[0051] 图5为本申请实施例提供的一种云原生系统故障分析方法的一个整体架构示意图。

具体实施方式

[0052] 本申请提供了一种基于知识图谱的云原生系统故障分析方法，用于解决现有技术忽略了实体之间的交互关系，只能定位到发生故障的实体，难以快速和准确地定位云原生
系统的故障根因的技术问题。

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

[0054] 为了便于理解，请参阅图1，本申请实施例提供的一种基于知识图谱的云原生系统故障分析方法，包括：

[0055] 步骤101、获取云原生系统中的原始数据，并基于原始数据构建知识图谱，得到图数据。

[0056] 云原生应用程序使用弹性基础架构进行管理。目前，主流的弹性基础架构主要是Kubernetes，Kubernetes以其完备的容器编排能力和集群管理能力成为目前实质上的云原
生系统。构建Kubernetes云原生系统的知识图谱需要获取云原生系统中各实体及实体之间
的依赖关系，并从每个实体的众多属性中筛选出主要的属性。

[0057] 获取云原生系统中非结构化的数据，例如具体资源对象(实体)的配置文件、微服务之间的TCP连接数据等，得到原始数据。

[0058] 进一步，考虑到现有技术采集云原生系统的数据信息时，需要安装相应的agent或者对软件进行代码插桩来获取相应的数据信息，特别是云原生系统的依赖关系、调用关系
的获取。该方法对云原生系统的侵入性太强，安全性和可靠性较低，甚至会对云原生系统产
生一定程度的影响。为了解决该问题，本申请实施例采用一种非侵入式的数据获取方法，该
过程需要获取各个资源实体信息以及微服务或Pod之间的网络连接数据。

[0059] 具体的，原始数据包括实体信息和网络连接数据，获取云原生系统中的原始数据的具体过程包括两个部分：实体信息获取和网络连接数据获取。

[0060] (1)实体信息获取

[0061] 本申请实施例中，在获取实体信息阶段，通过Python语言编写抓取Kubernetes实体信息的工具。在抓取数据的过程中，主要利用Kubernetes client‑Python、Docker‑py以
及Paramiko这三个第三方工具库。各类实体(资源对象)的获取方式可以简单分为三种，具
体实体的获取方式可以参考表1。

[0062] 表1各实体的数据获取方式

[0063]

[0064] 容器(Container)以上级别的资源对象主要是借助Kubernetes client‑Python模块获取相关数据。利用该模块访问Kubernetes集群的APIServer需要在集群的MasterNode
上创建具有Admin权限的ServiceAccount，并获取APIServer的地址和Token，作为远程访问
APIServer的许可凭证。Kubernetes client‑Python模块提供了非常便捷的API和Model，例
如可以利用以下脚本获取指定命名空间(namespace)的所有Pod实体信息：

[0065] kubernetes.client.CoreV1Api().list_namespaced_Pod(namespace)

[0066] 该脚本的获取结果为系统中指定namespace下所有Pod实体的集合，利用迭代器可以依次取出各个Pod实体，根据该模块的Model设计规则可以获取需要的各个重要字段的信
息。因此，该脚本编写的数据获取工具适用于不同规模的集群。其他的资源对象也是类似的
获取方式，在此不再进行赘述。

[0067] Kubernetes集群的最小调度单位是Pod，因此Container和Image的详细信息无法利用KubernetesAPI获取。由于目前大部分的容器使用的是Docker类型的容器，因此本申请
实施例采用DockerremoteAPI获取Container和Image相关信息。DockerremoteAPI是从
Dockerd获取数据的接口，Docker‑py模块是DockerremoteAPI的封装。Docker‑py也提供了
便捷的API和Model，可以一次性获取指定宿主机上的所有Container或Image，也可以获取
指定ID的Container或Image。

[0068] Process和File实体的信息需要利用Linux内核命令获取。Paramiko模块遵循SSH2协议，支持以加密的方式连接到远程服务器。借助paramiko模块可以在远程服务器上执行
命令，并将执行命令所得结果返回到本地客户端。例如，利用以下脚本获取指定pid的进程
打开的所有文件：

[0069] command＝'lsof‑p'+str(con['pid'])

[0070] stdin,stdout,stderr＝ssh_client.exec_command(command)

[0071] (2)网络连接数据获取

[0072] 考虑到现有方法抓取Pod实体之间的网络连接数据需要侵入到Container中，在Container启动之前挂载宿主机的一个文件目录，由于抓取网络连接数据时，云原生系统中
的Container是动态运行的，出于安全性考虑，Container是不允许动态挂载文件目录的，因
此，传统的挂载方法无法在运行的Container中挂载宿主机的文件目录。

[0073] 针对上述问题，本申请实施例借助nsenter(namespace enter)工具在运行的Container中动态挂载宿主机文件目录。nsenter是一个可以进入容器命名空间的小工具，
已经集成到Linux中。通过nsenter工具进入容器的命名空间(包括进程空间、文件空间、网
络空间)，将宿主机的netstat文件所在目录挂载到容器的文件系统上，在容器中执行
nsenter命令获取网络连接数据。本申请实施例只利用nsenter工具进入到容器的命名空
间，读取相关文件空间的信息用于执行文件挂载等操作，并不会直接修改容器的源码，对容
器造成的影响几乎可以忽略不计，因此使用该netstat工具并不具有侵入性，并且是安全
的。

[0074] 具体的，将宿主机的netstat文件所在目录挂载到Container中并获取信息可以包括以下几个步骤：

[0075] S1、通过nsenter工具进入到容器的命名空间，将宿主机的netstat文件所在目录挂载到容器的文件系统上；

[0076] S2、在Container中执行nsenter命令获取TCP连接数据；

[0077] S3、处理TCP连接数据，去除其中重复的连接、已经结束的连接或建立失败的连接；

[0078] S4、筛选出每个连接的local address ip(本地ip地址)和foreign address ip(外部ip地址)；

[0079] S5、找到每个ip地址对应的Pod，建立Pod之间的TCP连接。

[0080] 例如，将宿主机的/bin文件挂载到id为60c2e42f1e80的容器的/mnt文件目录中，首先利用容器id获取其对应进程的PID，例如PID＝5882，nsenter工具根据PID＝5882找到
对应进程，进入该进程的名称空间。接着将宿主机的/bin目录挂载到容器的/mnt文件目录
中，此时，进入容器内部，在/mnt目录下执行netstat指令可以获取内部网络连接数据。获取
的TCP连接形式可以参考表2。将这些TCP连接数据进行处理，抽取每个连接的ip地址，并找
出该ip地址对应的两个Pod实体，并在实体依赖图中，添加这两个Pod实体的一个连接关系。

[0081] 表2 TCP连接数据

[0082]

[0083] 在获取到云原生系统的原始数据后，基于该原始数据构建知识图谱，得到图数据。构建知识图谱的过程中，首先，对该原始数据进行数据抽取，具体的，对该原始数据依次进
行实体抽取、实体关系抽取以及实体属性抽取。

[0084] 1、实体抽取

[0085] 实体抽取阶段主要是抽取deployment及以下的应用组件，包括node、namespace、deployment、replicaset、Pod、endpoint、service、container、image、process以及file。

[0086] 2、实体关系抽取

[0087] 实体关系抽取主要是根据经验知识，抽取各个实体之间的关系以及各个关系的描述方式。本申请实施例针对提取的实体，抽取实体关系，具体为：

[0088] 1)Process与File之间的联系：宿主机中，一个process可以打开多个file，同一个file也可以被多个process打开，它们之间是多对多的关系。因此，这两者的关系可以描述
为：file—opened→process。

[0089] 2)Container与Image之间的联系：Kubernetes中的Container是使用Image创建的。Image和Container之间是一对多的关系：同一个Image可以动态运行成为多个不同的
Container，但是每一个Container只能与一个Image相对应。这两者的关系可以描述为：
image—spawn→container。

[0090] 3)Container与Process之间的联系：每一个动态运行的Container都是宿主机上的一个进程，通过查看每个Container对应的宿主机进程Pid，可以将Container和Process
联系起来。这两者是一对一的关系，可以描述为：process—mapping→container。

[0091] 4)Pod与Container之间的联系：Kubernetes集群中最小的编排调度单位是Pod。Pod和Container两者之间存在着一对多的关系；每个Pod里面可以运行一到多个的
Container，这些Container共享同一个Pod的资源。因此可以描述为：container—running
→pod。

[0092] 5)ReplicaSet与Pod之间的联系：ReplicaSet是Pod的管理工具，其本质是定义了一个期望场景(所需Pod的副本数、筛选目标Pod的label selector、Pod的创建模板等)。Pod
可以由ReplicaSet和DaemonSet部署而来。每个Pod会在其配置文件中记录Pod的owner的相
关信息，可以利用该信息将Pod与ReplicaSet联系起来。Pod与ReplicaSet之间是多对一的
关系，可以将两者关系描述为：pod—replica→replicaSet。

[0093] 6)Deployment与ReplicaSet之间的联系：Deployment通过创建ReplicaSet实现对Pod更好的编排。ReplicaSet的定义文件中也记录着owner的相关信息，可以利用该信息将
ReplicaSet与Deployment联系起来。ReplicaSet与Deployment是多对一的关系，两者的关
系可以描述为：replicaSet－comprise→deployment。

[0094] 7)Deployment与Namespace之间的联系：Namespace主要通过一定的技术实现集群中的资源隔离，用户可以在不同的Namespace中划分集群中的资源对象，从而实现多租户、
不同小组以及多个项目之间的资源隔离。每个Deployment只能属于集群中的其中一个
Namespace，并且由这个Deployment部署而来的Pod等对象实体也都属于该Namespace。
Deployment的配置文件中记录了所属的Namespace信息。Deployment与Namespace是多对一
的关系，两者的关系可以描述为：deployment—deployed→namespace。

[0095] 8)Node与Namespace之间的联系：Node节点一般对应一台物理机或者对应一台虚拟机，Node是集群中所有实体运行的宿主。Namespace逻辑上与Node不存在联系，但是这两
者可以通过Pod关联起来。每个Namespace中的Pod编排在不同的Node上，因此每个
Namespace会有多个Node与其关联，每个Node也可以被多个Namespace共用，两者是多对多
的关系，两者关系可以描述为：namespace—host→node。

[0096] 9)Pod与endpoint、service之间的联系：Kubernetes集群中，Service是一个抽象的概念，对应集群中真实应用。每一个Service由一系列的Pod提供支持。Service利用label 
selector和Pod建立关联。Kubernetes会为配置有label selector的service创建对应的
endpoint(主要包括pod IP和podport信息)资源对象，并存储在Etcd中，利用该endpoint可
以将Service与对应的所有Pod关联起来。三者的关系可以描述为：service—binding→
endpoint—register→pod。

[0097] 10)Pod与Pod之间的联系：不论是同一宿主机之间还是不同宿主机之间，集群中的Pod可以通过网络进行通信。本申请实施例通过进入Container中获取集群中的TCP连接，每
个连接的主要数据包括local address IP、foreign address IP、status这三个字段，这里
提取出local address IP以及foreign address IP，这两个IP是该集群给两个Pod实体分
配的IP地址，并且该连接是没有方向的，因此，Pod之间的联系可以描述为：pod←tcp→pod。

[0098] 综上所述，Kubernetes集群上这些实体之间的依赖关系可以梳理成如图2所示的实体依赖关系模型。

[0099] 3、实体属性抽取

[0100] 本申请实施例抽取的实体属性主要包括静态属性和动态属性。静态属性主要包括唯一标识一个组件的信息以及一些配置信息，比如name、id等标识信息和环境变量、ip、
port等配置信息。这些信息不会随着组件的运行而发生变化，一般比较稳定，一旦改动，可
能会引起一些故障，因此可以作为故障检测的关键指标。

[0101] 动态属性是指IT组件在运行过程中表现出来的特征，主要是IT组件或应用程序运行状况的关键指标，如服务延迟、吞吐量和系统资源(如CPU、内存、网络利用率)。

[0102] 经过上述的数据抽取后，可以得到实体、实体关系以及实体属性，根据得到的实体、实体关系和实体属性可以构建实体依赖关系模型，本申请实施例采用自上而下的方式
构建实体依赖关系模型，从node节点到namespace节点，从namespace节点到deployment节
点等，一层一层自上而下构建实体依赖关系模型，根据构建的实体依赖关系模型可以采用
图数据表示，请参考图3，每一个实体对应图数据中的一个节点，并且该节点具有多个属性，
实体之间的关系映射为图数据中的边，每条边可以有多个属性值；属性与属性值以key‑
values模式存储。建模好的图数据利用Neo4j图数据库或其他数据库进行存储，借助内置
Cypher查询语句，能完成高效的查询工作。其中，图数据的构建过程可以参考图4。

[0103] 步骤102、通过异常检测模型对图数据进行异常检测，得到异常节点。

[0104] 云原生系统的图数据可以用G(V,E,X)表示，V为节点的集合，E为所有连接边的集合，X为所有节点的属性矩阵，其中，Xi为第i个节点的属性向量。

[0105] 在本申请实施例中，异常检测模型的输入数据为邻接矩阵和属性矩阵。提取图数据G(V,E,X)中各节点的有向拓扑关系，得到邻接矩阵A，Aij＝1表示实体i和实体j(i、j∈V)
之间有连接边eij∈E，Aij＝0表示实体i和实体j(i、j∈V)之间没有连接边；提取图数据中各
节点的属性，得到属性矩阵X，属性矩阵X由矩阵中各个实体的属性拼接而成，主要选取的属
性是具有时序特征的动态属性，例如一段时间内的CPU的使用率、网络的传输和接收带宽、
时延等来诊断异常节点。通过异常检测模型对邻接矩阵和属性矩阵进行异常检测，得到异
常节点。

[0106] 进一步，本申请实施例中的异常检测模型包括编码器和解码器，编码器将输入数据编码映射到低维度的特征向量中，解码器则是利用编码器输出的特征向量重构知识图
谱，异常检测模型通过重构误差大小衡量节点的异常程度。具体的，通过异常检测模型对邻
接矩阵和属性矩阵进行异常检测，得到异常节点，包括：

[0107] 通过异常检测模型中的编码器对邻接矩阵和属性矩阵进行编码处理，得到编码特征向量，并将编码特征向量和邻接矩阵输入到解码器；通过异常检测模型中的解码器结合
邻接矩阵和编码特征向量进行解码处理，得到重构邻接矩阵和重构属性矩阵；通过异常检
测模型基于邻接矩阵、属性矩阵和重构邻接矩阵、重构属性矩阵计算重构误差，并基于重构
误差确定异常节点。

[0108] (1)编码器

[0109] 本申请实施例中的编码器包括依次连接的图卷积网络(Graph Convolutional Network，GCN)和递归神经网络(RecurrentNeural Network，RNN)，GCN可以捕捉知识图谱中
实体之间的拓扑依赖关系，利用拉普拉斯矩阵将节点的属性进行降维，映射到低维空间中。
RNN每次都会将前一次的输出结果，带到下一次的隐藏层中一起训练，能够很好地建立起相
邻时刻的指标数据的关系。因此，采用GCN和RNN结合的方式可以有效从时间和空间两个方
面挖掘云原生系统知识图谱的信息，快速排查出异常节点。可以理解的是，也可以采用LSTM
(Long Short‑Term Memory，长短期记忆)网络替代RNN。

[0110] 将邻接矩阵A和属性矩阵X输入到异常检测模型后，通过异常检测模型中的编码器对邻接矩阵和属性矩阵进行编码处理，得到编码特征向量。具体的，通过图卷积网络将邻接
矩阵A和属性矩阵X映射到低维空间，得到低维特征向量；通过递归神经网络对低维特征向
量进行特征提取，得到编码特征向量Z。

[0111] 编码器第一部分为图卷积网络，图卷积网络通过公式(1)进行特征提取，将邻接矩阵A和属性矩阵X映射到低维空间：

[0112]

[0113] 其中，X(l+1)为第l+1层输出的低维特征向量， 是 的度矩阵，(l)
W 为第l层的权重矩阵，σ(·)为激活函数，具体可以选择ReLU或者sigmoid
等激活函数，本申请实施例优选采用ReLU激活函数，计算公式如下：

[0114]

[0115] 本申请实施例中的图卷积网络优选为2层，对于输入的邻接矩阵A和属性矩阵X，图(2)
卷积网络将输入数据映射到低维特征向量X ，计算过程如下：

[0116] X(0)＝X                           (3)

[0117]

[0118]

[0119] GCN将输出的低维特征向量X(2)输入到RNN进行特征提取，得到编码特征向量Z，RNN(2)
的输入数据X 中，每个节点对应的属性序列是一个具有时间序列特征的属性向量，RNN模
型的具体计算过程如下：

[0120] x(t)＝w(t)+s(t‑1)                        (6)

[0121] sj(t)＝f(∑ixi(t)uji)                       (7)

[0122] yk(t)＝g(∑jsj(t)vkj)                       (8)

[0123] 其中，x(t)为t时刻的输入，s(t)为t时刻的隐藏层状态，sj(t)为隐藏层第j个神经元的状态，y(t)为t时刻的输出结果，yk(t)为输出层第k个神经元的输出结果，u为输入层和
隐藏层之间的权重矩阵，v为隐藏层和输出层之间的权重矩阵，f(·)、g(·)为激活函数，分
别为sigmoid激活函数和softmax激活函数，计算公式如下：

[0124]

[0125]

[0126] (2)解码器

[0127] 解码器根据编码特征向量Z进行解码，重构输入的邻接矩阵A和属性矩阵X，得到重构邻接矩阵 和重构属性矩阵 解码处理包括两部分：一部分是邻接矩阵的解码，即拓扑
结构的重构；另一部分是属性矩阵的解码，即属性信息的重构。因此，解码器包括拓扑结构
重构模块和属性信息重构模块，其中，属性信息重构模块包括依次连接的递归神经网络和
图卷积网络。

[0128] 解码器的具体解码过程为：

[0129] S1、通过拓扑结构重构模块对编码特征向量Z进行解码处理，得到重构邻接矩阵具体计算公式为：

[0130]

[0131] 其中，σ(·)为激活函数，优选为sigmoid激活函数。

[0132] S2、通过属性信息重构模块中的递归神经网络对编码特征向量进行解码处理，得到输出结果；通过属性信息重构模块中的图卷积网络基于邻接矩阵对输出结果进行解码处
理，得到重构属性矩阵。

[0133] 属性信息重构模块采用的解码框架是一个RNN加上GCN，和编码器类似的结构。属性信息重构模块的输入包括两部分，一部分是编码特征向量Z，另一部分是邻接矩阵A，这里
需要借助编码器输入的邻接矩阵辅助属性矩阵的重构。可以理解的是，也可以采用LSTM替
换RNN。

[0134] 首先，将编码特征向量Z输入到RNN中，RNN的计算过程和上述编码过程相似。RNN的输出结果是一个属性矩阵X'，该属性矩阵X'和最初的邻接矩阵A作为GCN的输入，GCN的输出
结果即为重构属性矩阵 重构属性矩阵、重构邻接矩阵与原始输入数据的误差是后续异
常节点检测的关键。

[0135] 异常检测模型的训练过程是最小化输入数据和重构结果之间的重构误差，重构误差的计算公式为：

[0136]

[0137] 异常检测模型通过重构误差的大小来衡量节点的异常程度，节点i的重构误差通过欧几里得范数衡量，计算公式如下：

[0138]

[0139] 其中，ai为第i个节点对应的邻接向量， 为第i个节点对应的重构邻接向量，xi为第i个节点对应的属性向量， 为第i个节点对应的重构属性向量，Li为第i个节点对应的重
构误差。

[0140] 重构误差越大的节点，成为异常节点的可能性越大，将重构误差超过预置阈值θ的节点判定为异常节点，即：

[0141] Anomaly(v1,v2,…,vn)＝{vi|Li≥θ,θ＜Max(L1,L2,…,Ln),i∈[1,n]}       (14)

[0142] 步骤103、计算异常节点和异常节点对应的副本节点的相似度，并基于相似度进行故障根因定位，其中，异常节点对应的副本节点为与异常节点同类型的节点。

[0143] 通过异常检测模型可以检测得到发生异常的具体节点，本申请实施例进一步分析发生异常的根本原因。通常对外提供同种服务的实体pod副本之间有着一样的配置和表现，
因此，可以借助副本之间的相似度来比较发现故障根因。本申请实施例采用局部对比的方
法，将异常节点与其对应的副本节点进行比较，计算异常节点和异常节点对应的副本节点
的动态属性相似度、静态属性相似度，分别得到动态属性相似度分值和静态属性相似度分
值；基于动态属性相似度分值和静态属性相似度分值确定异常属性。其中，异常节点对应的
副本节点为与异常节点同类型的节点，即异常节点与其对应的副本节点对外提供同一服
务。

[0144] 计算异常节点和异常节点对应的副本节点的动态属性相似度，得到动态属性相似度分值的具体过程可以为：获取预置时间段内异常节点和异常节点对应的副本节点的动态
属性，生成异常节点动态属性向量和副本节点动态属性向量；计算异常节点动态属性向量
和副本节点动态属性向量的余弦相似度，得到动态属性相似度分值。具体的，可以计算异常
节点和异常节点对应的副本节点的CPU的使用率、网络的传输和接收带宽、内存使用率等动
态属性的相似度，本申请实施例优选采用余弦相似度计算方法，也可以采用其他的相似度
计算方法，在此不再一一列举。

[0145] 云原生系统中的异常也有可能是静态属性的改变引起的，比如配置文件的缺失、环境变量被篡改等。通常对外提供同种服务的实例pod副本之间有着一样的配置，因此，可
以借助副本之间的相似度比较来发现根因。对于静态属性，这些属性一般是文本类型的，可
以使用文本相似度进行比较，也可以采用其他的相似度计算方法，在此不再一一列举。本申
请实施例优选采用余弦相似度进行比较，具体过程为：

[0146] 对异常节点的静态属性、异常节点对应的副本节点的静态属性依次进行分词、停用词过滤和oneHot编码，分别得到异常节点文本向量和副本节点文本向量；计算异常节点
文本向量和副本节点文本向量的余弦相似度，得到静态属性相似度分值。

[0147] 基于动态属性相似度分值和静态属性相似度分值进行排序，相似度分值越低的属性，则是故障根因的可能性越高，因而可以定位具体的故障根因。异常检测模型和根因定位
的整体架构可以参考图5。

[0148] 本申请实施例中，通过获取云原生系统中的原始数据，根据原始数据中各实体的属性以及依赖关系构建知识图谱，得到图数据，再通过异常检测模型对带有属性信息和依
赖关系的图数据进行异常检测，得到异常节点，考虑了云原生系统中各实体之间的相互关
系，可以快速和准确地定位故障；并且本申请通过计算异常节点与异常节点为同类型的节
点的相似度，来进一步进行故障根因定位，可以更加细粒度和准确地定位到故障根因，解决
了现有技术忽略了实体之间的交互关系，只能定位到发生故障的实体，难以快速和准确地
定位云原生系统的故障根因的技术问题。

[0149] 进一步，本申请实施例采用非侵入式和轻量级的方式获取云原生系统中的原始数据，无需进行代码插桩或者agent的安装，对云原生系统的影响几乎可以忽略不计，更加安
全可靠；本申请实施例同时考虑云原生系统中的指标数据以及组件拓扑关系，可以更加准
确定位到故障根因；并且从时间和空间两个维度对各个异常组件的动态属性和静态属性进
行根因排查，可以更加细粒度地定位到故障的根因。

[0150] 在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅
仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结
合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的
相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通
信连接，可以是电性，机械或其它的形式。

[0151] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个
网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目
的。

[0152] 另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单
元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

[0153] 所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上
或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式
体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以通过一台计算机
设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全
部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文全称：Read‑Only 
Memory，英文缩写：ROM)、随机存取存储器(英文全称：RandomAccess Memory，英文缩写：
RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

[0154] 以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前
述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些
修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。