CN117112799A - 运维知识图谱的确定方法、装置、设备和存储介质 - Google Patents

Abstract

本申请涉及一种运维知识图谱的确定方法、装置、设备和存储介质，方法包括：通过分别获取服务系统中的各应用的调用链信息和硬件部署信息。对于各应用，根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系，并根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱；其中，运维知识图谱用于监控服务系统的运行情况。本申请实施例，实现了结合应用的软硬件维度的运维信息可以确定关联度更高的运维知识图谱，以便于根据本申请实施例的运维知识图谱可以更加快速精准地监控服务系统，从而有利于满足整个服务系统的监控要求。

Description

运维知识图谱的确定方法、装置、设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种运维知识图谱的确定方法、装置、设备和存储介质。

背景技术

随着计算机技术的发展，越来越多的企业的很多业务通过线上执行。为了保证业务的正常执行，需要运维人员对整个服务系统进行监控。

通常情况下，运维人员通过对整个服务系统的日志分析等方式进行监控。但是考虑到整个服务系统的运维信息的数量比较庞大，并且不同系统服务之间的关系复杂，通过传统的日志分析等方式无法满足整个服务系统的监控要求。

发明内容

本申请实施例提供一种运维知识图谱的确定方法、装置、设备和存储介质，有利于满足整个服务系统的监控要求。

第一方面，本申请提供了一种运维知识图谱的确定方法，方法包括：

分别获取服务系统中的各应用的调用链信息和硬件部署信息；

对于各应用，根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系；

根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱；其中，运维知识图谱用于监控服务系统的运行情况。

在其中一个实施例中，根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系，包括：

根据应用的调用链信息确定至少一个实体对象的指示信息；

根据指示信息和应用的硬件部署信息，确定各实体对象之间的硬件部署关系。

在其中一个实施例中，硬件部署信息包括以下至少一项：节点Node信息、容器组Pod信息、服务信息；

其中，节点Node信息用于指示节点Node的标识信息以及节点Node所属的业务系统的标识信息；容器组Pod信息用于指示容器组Pod的标识信息，以及容器组Pod所属的节点Node的标识信息；服务信息用于指示应用服务的标识信息以及用于提供应用服务的容器组Pod的标识信息。

在其中一个实施例中，若应用包括应用服务，指示信息包括应用服务的标识信息，根据指示信息和应用的硬件部署信息，确定各实体对象之间的硬件部署关系，包括：

根据应用服务的标识信息从应用服务的硬件部署信息中确定用于提供应用服务的容器组Pod的标识信息、容器组Pod所属的节点Node的标识信息，以及节点Node所属的业务系统的标识信息；其中，节点Node所属的业务系统与应用服务所属的业务系统相同。

在其中一个实施例中，若应用包括应用组件，指示信息包括与应用组件关联的节点Node的指示信息，根据指示信息和应用的硬件部署信息，确定各实体对象之间的硬件部署关系，包括：

根据节点Node的指示信息从应用组件的硬件部署信息中确定应用组件部署在的节点Node的标识信息，以及节点Node所属的业务系统的标识信息。

在其中一个实施例中，分别获取服务系统中的各应用的调用链信息和硬件部署信息，包括：

从应用性能管理系统APM获取各应用的调用链信息；

从监控系统和/或容器集群管理系统获取各应用的硬件部署信息。

在其中一个实施例中，若应用包括应用服务，应用的硬件部署信息包括节点Node信息、容器组Pod信息以及应用服务的服务信息，其中，服务信息包括第一服务信息和第二服务信息，从监控系统和/或容器集群管理系统获取各应用的硬件部署信息，包括：

从监控系统获取各应用服务的第一服务信息、节点Node信息、容器组Pod信息，其中，第一服务信息用于指示应用服务的标识信息；

从容器集群管理系统获取各应用服务的第二服务信息，其中，第二服务信息用于指示用于提供应用服务的容器组Pod的标识信息。

在其中一个实施例中，若应用包括应用组件，应用的硬件部署信息包括节点Node信息，从监控系统和/或容器集群管理系统获取各应用的硬件部署信息，包括：

从监控系统获取各应用组件的节点Node信息。

在其中一个实施例中，分别获取服务系统中的各应用的调用链信息和硬件部署信息，包括：

分别基于定时任务流获取各应用的调用链信息和硬件部署信息；

对应地，根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系，并根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱，包括：

根据应用的调用链信息和硬件部署信息基于定时任务流，确定与应用关联的各实体对象之间的硬件部署关系，并根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱。

在其中一个实施例中，方法还包括：

根据服务系统的运维知识图谱和待查询应用，确定待查询应用的运行情况，其中，运行情况用于指示待查询应用的调用链中的各实体对象之间的硬件部署关系，和/或运行状态。

在其中一个实施例中，方法还包括：

若根据待查询应用的运行情况确定待查询应用的调用链运行异常，则输出告警信息，其中，告警信息用于指示待查询应用的运行情况。

第二方面，本申请还提供了一种运维知识图谱的确定装置，装置包括：

获取模块，用于分别获取服务系统中的各应用的调用链信息和硬件部署信息；

第一确定模块，用于对于各应用，根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系；

第二确定模块，用于根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱；其中，运维知识图谱用于监控服务系统的运行情况。

第三方面，本申请还提供了一种服务器，包括：存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述第一方面中任一项的方法的步骤。

第四方面，本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述第一方面中任一项的方法的步骤。

第五方面，本申请还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述第一方面中任一项的方法的步骤。

上述运维知识图谱的确定方法、装置、设备和存储介质，通过根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系，并根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱的方式，实现了结合应用的软硬件维度的运维信息可以确定关联度更高的运维知识图谱，以便于根据本申请实施例的运维知识图谱可以更加快速精准地监控服务系统，从而有利于满足整个服务系统的监控要求。

附图说明

图1为本申请实施例提供的一种运维知识图谱的确定方法的应用场景示意图；

图2为本申请一个实施例中运维知识图谱的确定方法的流程示意图；

图3为本申请实施例提供的不同关联关系的示意图；

图4为本申请另一个实施例中运维知识图谱的确定方法的流程示意图；

图5为本申请另一个实施例中运维知识图谱的确定方法的流程示意图；

图6为本申请另一个实施例中运维知识图谱的确定方法的流程示意图；

图7为本申请实施例提供的运维知识图谱的确定系统的示意图一；

图8为本申请实施例提供的定时模块的结构示意图；

图9为本申请实施例提供的运维知识图谱的确定系统的示意图二；

图10为相关技术提供的知识图谱的构建系统的示意图；

图11为本申请实施例提供的运维知识图谱的确定方法的整体流程示意图；

图12为本申请一个实施例中运维知识图谱的确定装置的结构示意图；

图13为本申请一个实施例中服务器的结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

考虑到整个服务系统的运维信息的数量比较庞大并且日益增加，以及不同系统服务之间的关系复杂，通过传统的日志分析等方式无法窥其全貌，一旦出现运维问题，通常无法快速定位问题，以便于及时解决故障。可见，通过传统的日志分析等方式无法满足整个服务系统的监控要求。

本申请实施例提供的运维知识图谱的确定方法、装置、设备和存储介质，可以应用于服务系统的运维管理应用场景；当然，还可以应用于其他应用场景。

图1为本申请实施例提供的一种运维知识图谱的确定方法的应用场景示意图，如图1所示，本申请实施例的应用场景中可以包括但不限于：服务器10、应用性能管理系统(Application Performance Management，APM)11、监控系统12和容器集群管理系统13。示例性地，本申请实施例中的服务器10中可以设置有运维知识图谱的确定应用程序。

本申请实施例中，服务器10可以采用本申请实施例提供的运维知识图谱的确定方法，从应用性能管理系统APM 11获取软件运维信息，以及从监控系统12和/或容器集群管理系统13获取硬件运维信息，并根据获取的软硬件运维信息确定服务系统的运维知识图谱。

本申请实施例中的应用性能管理系统APM 11可以用于负责日志(Logs)、链路追踪(Traces)以及报表统计(Metrics)等。

示例性地，本申请实施例中的应用性能管理系统APM 11可以包括但不限于Skywalking或者Pinpoint。需要说明的是，本申请下述实施例中以应用性能管理系统APM11为Skywalking为例实现应用的链路监控的；当然，应用性能管理系统APM也可以为其他管理系统。

通常情况下，对于大型企业需要引入一个有效的监控系统，可以涵盖业务和基础设施的所有领域，例如，服务器、数据库、服务、存储、应用等。一个高效的监控系统应该为指标的收集、存储、计算、预测、可视化和告警提供服务。

示例性地，本申请实施例中的监控系统12可以包括但不限于Prometheus或者Zabbix。需要说明的是，本申请下述实施例中以监控系统12为Prometheus为例示出的；当然，监控系统也可以为其他监控系统。

本申请实施例中的容器集群管理系统13可以用于管理云平台中多个主机上的容器化的应用。示例性地，本申请实施例中的容器集群管理系统13可以包括但不限于Kubernetes。

本申请实施例提供的运维知识图谱的确定方法、装置、设备和存储介质，通过根据获取的服务系统中的应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系，并根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱的方式，实现了结合应用的软硬件维度的运维信息可以确定关联度更高的运维知识图谱，以便于根据本申请实施例的运维知识图谱可以更加快速精准地监控服务系统，从而有利于满足整个服务系统的监控要求。

需要说明的是，本申请实施例所带来的有益效果或者所解决的技术问题并不限定于这一个，还可以是其它隐含或者关联的问题，具体可以参见下述实施例的描述。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

在一个实施例中，图2为本申请一个实施例中运维知识图谱的确定方法的流程示意图，本申请实施例中以该方法应用于图1中的服务器为例进行说明。

如图2所示，本申请实施例的方法可以包括以下步骤：

步骤S201、分别获取服务系统中的各应用的调用链信息和硬件部署信息。本申请实施例中的任意应用的调用链信息(或者称之为拓扑图)可以用于指示与应用关联的至少一个实体对象。示例性地，本申请实施例中的各实体对象可以包括但不限于以下至少一项：业务系统(Business)、部署单元(Unit)、节点(Node)、容器组(Pod)、应用服务(Service)。本申请实施例中的节点Node可以是指主机，其中，主机可以为虚拟主机或者物理主机。应理解，多个节点Node可以构成集群，例如，kafka集群或者elasticsearch集群。

需要说明的是，部署单元(Unit)可以包括但不限于拓扑图中的节点，例如，部署单元(Unit)可以包括但不限于应用服务、应用组件、节点(Node)，或者容器组(Pod)。

应理解，在容器集群管理系统包括Kubernetes的情况下，本申请实施例中的容器组Pod可以为Kubernetes Pod，对应地，应用服务可以为Kubernetes Service服务。

本申请实施例中的任意应用的硬件部署信息可以用于指示与应用关联的各实体对象对应的硬件部署关系。

本步骤中，服务器可以分别获取服务系统中的各应用的调用链信息和硬件部署信息，其中，任意应用的调用链信息属于软件运维信息，任意应用的硬件部署信息属于硬件运维信息。

一种可能的实现方式中，服务器可以实时地分别获取各应用的调用链信息和硬件部署信息。

另一种可能的实现方式中，服务器可以在检测到满足预设触发条件的情况下，分别获取各应用的调用链信息和硬件部署信息；预设触发条件可以包括但不限于：接收到获取指令，或者达到预设获取时间；其中，获取指令可以为运维人员触发的，或者可以为软件自动触发的。

当然，服务器还可以通过其他方式，分别获取各应用的调用链信息和硬件部署信息。

步骤S202、对于各应用，根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系。

示例性地，本申请实施例中涉及的实体对象之间的关联关系可以包括但不限于以下至少一项：属于(belong)关系、调用(call)关系、部署(deploy in)关系、提供(provide)关系。

为了便于理解，本申请下述实施例中以部署单元为例，对不同的关联关系进行说明。

图3为本申请实施例提供的不同关联关系的示意图，如图3所示，本申请实施例中的任意部署单元(Unit)可以属于对应的业务系统(Business)、调用其他部署单元，和/或，部署在对应的节点Node或者容器组Pod；其中，容器组Pod可以提供对应的应用服务，容器组Pod可以属于对应的节点Node。

当然，本申请实施例中的关联关系还可以包括除上述关联关系之外的其他关系。

本申请实施例中的各实体对象之间的硬件部署关系可以用于指示各实体对象对应的硬件信息之间的关联关系。

本步骤中，对于各应用，服务器可以根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系。

示例性地，假设应用为应用组件，应用对应的调用链信息可以用于指示与应用组件关联的节点Node，则服务器可以根据应用的调用链信息和硬件部署信息，确定与应用组件关联的节点Node和业务系统等实体对象之间的硬件部署关系。其中，与应用组件关联的各实体对象可以包括但不限于：业务系统和节点Node。

又一示例性地，假设应用为应用服务，应用对应的调用链信息可以用于指示应用服务(应用服务也属于与应用关联的实体对象)，则服务器可以根据应用服务的调用链信息和硬件部署信息，确定与应用服务关联的容器组Pod、节点Node和业务系统等等实体对象之间的硬件部署关系。其中，与应用服务关联的各实体对象可以包括但不限于：业务系统、节点Node、容器组Pod以及应用服务。

当然，本申请实施例中的应用还可以为其他类型的应用，服务器确定与应用关联的各实体对象之间的硬件部署关系的可实现方式，可以参考上述实施例中的相关内容。

可见，本申请实施例中，通过根据应用的调用链信息和硬件部署信息实现了结合应用的软硬件运维信息对与应用关联的各实体对象进行识别抽取，以及对各实体对象之间的硬件部署关系进行识别关联，以便于后续可以确定服务系统的运维知识图谱。

步骤S203、根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱；其中，运维知识图谱用于监控服务系统的运行情况。

本步骤中，服务器可以根据各应用的各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱；其中，运维知识图谱用于监控服务系统的运行情况。

示例性地，服务器根据各应用的各实体对象之间的硬件部署关系，可以通过预设知识图谱构建方法确定服务系统的运维知识图谱；其中，预设知识图谱构建方法可以包括但不限于以下任一项：基于规则引擎和知识库构建方法、基于图数据库构建方法、基于机器学习构建方法、基于规则引擎和机器学习结合方法。

一种可能的实现方式中，服务器可以根据各应用的各实体对象之间的硬件部署关系，一并得到服务系统的运维知识图谱。

另一种可能的实现方式中，对于各应用，服务器可以根据该应用的各实体对象之间的硬件部署关系，确定该应用的运维知识图谱；进一步地，服务器可以对各应用的运维知识图谱进行汇总，得到服务系统的运维知识图谱。

可见，本申请实施例中，通过根据各应用的各实体对象之间的硬件部署关系确定服务系统的运维知识图谱的方式，实现了结合各应用的各实体对象的软硬件维度的运维信息确定运维知识图谱。由于本申请实施例中的运维知识图谱结合了软硬件维度的运维信息，因此，本申请实施例的运维知识图谱的关联度更高，以及根据本申请实施例的运维知识图谱可以更加快速精准地监控服务系统，以便于在出现运维问题时，根据运维知识图谱可以快速精准地定位软硬件问题，从而可以及时地解决故障。

需要说明的是，若服务器中之前未构建有服务系统的运维知识图谱，则服务器可以根据各应用的各实体对象之间的硬件部署关系，构建服务系统的运维知识图谱；若服务器中之前已经构建有服务系统的运维知识图谱，则服务器可以根据各应用的各实体对象之间的硬件部署关系，更新服务系统的运维知识图谱。

上述运维知识图谱的确定方法，通过分别获取服务系统中的各应用的调用链信息和硬件部署信息。进一步地，对于各应用，根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系，并根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱；其中，运维知识图谱用于监控服务系统的运行情况。可见，本申请实施例中，通过根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系，并根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱的方式，实现了结合应用的软硬件维度的运维信息可以确定关联度更高的运维知识图谱，以便于根据本申请实施例的运维知识图谱可以更加快速精准地监控服务系统，从而有利于满足整个服务系统的监控要求。

在一个实施例中，图4为本申请另一个实施例中运维知识图谱的确定方法的流程示意图，在上述实施例的基础上，本申请实施例中对上述步骤S202中“根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系”的相关内容进行说明。如图4所示，本申请实施例的上述步骤S202可以包括以下步骤：

步骤S2021、根据应用的调用链信息确定至少一个实体对象的指示信息。

本步骤中，对于各应用，服务器可以根据应用的调用链信息确定与应用关联的至少一个实体对象的指示信息。

一种可能的实现方式中，若应用包括应用服务，调用链信息可以用于指示应用服务(应用服务也属于与应用关联的实体对象)的标识信息，服务器可以通过对应用服务的调用链信息进行识别抽取，得到应用服务的指示信息，其中，指示信息可以包括但不限于应用服务的标识信息。示例性地，应用服务的标识信息可以包括但不限于应用服务的名称。

例如，应用服务的调用链信息可以用于指示应用服务的名称.命名空间：端口；当然，应用服务的调用链信息还可以用于指示其他信息。

另一种可能的实现方式中，若应用包括应用组件，调用链信息可以用于指示与应用组件关联的节点Node的指示信息，服务器可以通过对应用服务的调用链信息进行识别抽取，得到节点Node的指示信息，其中，节点Node的指示信息可以包括但不限于节点Node的互联网协议地址(Internet Protocol Address，IP)。

例如，应用组件的调用链信息可以用于指示与应用组件关联的节点Node的IP和端口；当然，应用组件的调用链信息还可以用于指示其他信息。

步骤S2022、根据指示信息和应用的硬件部署信息，确定各实体对象之间的硬件部署关系。

本申请实施例中的任意应用的硬件部署信息可以用于指示与应用关联的各实体对象对应的硬件部署关系。

示例性地，本申请实施例中的硬件部署信息可以包括但不限于以下至少一项：节点Node信息、容器组Pod信息、服务信息。

示例性地，节点Node信息可以用于指示节点Node的标识信息以及节点Node所属的业务系统的标识信息。例如，节点Node的标识信息可以包括但不限于节点Node的名称和/或节点Node的IP；业务系统的标识信息可以包括但不限于业务系统的名称。

示例性地，容器组Pod信息可以用于指示容器组Pod的标识信息，以及容器组Pod所属的节点Node的标识信息。例如，容器组Pod的标识信息可以包括但不限于容器组Pod的名称和/或容器组Pod的IP。

需要说明的是，本申请实施例中的容器组Pod信息还可以用于指示容器组Pod所属的节点Node所属的业务系统的标识信息；当然还可以用于指示其他信息。

示例性地，服务信息可以用于指示应用服务的服务标识信息以及用于提供应用服务的容器组Pod的标识信息。例如，应用服务的标识信息可以包括但不限于应用服务的名称。

需要说明的是，本申请实施例中的服务信息还可以用于指示应用服务所属的业务系统的标识信息；当然还可以用于指示其他信息。

本步骤中，对于各应用，服务器可以根据与应用关联的至少一个实体对象的指示信息和应用的硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系。

一种可能的实现方式中，若应用包括应用服务，与应用服务关联的实体对象的指示信息可以包括但不限于应用服务的标识信息，应用服务的硬件部署信息可以包括但不限于节点Node信息、容器组Pod信息以及应用服务的服务信息，服务器可以根据应用服务的标识信息从应用服务的硬件部署信息中确定用于提供应用服务的容器组Pod的标识信息、容器组Pod所属的节点Node的标识信息，以及节点Node所属的业务系统的标识信息；其中，节点Node所属的业务系统与应用服务所属的业务系统相同。

本实现方式中，服务器可以通过应用服务的标识信息与应用服务的硬件部署信息进行匹配，确定出用于提供应用服务的容器组Pod的标识信息、容器组Pod所属的节点Node的标识信息，以及节点Node所属的业务系统的标识信息，从而得到了应用服务->容器组Pod->节点Node->业务系统等实体对象的软硬件关联关系。

例如，假设应用服务的标识信息为应用服务A的名称，则服务器可以通过应用服务A的名称与应用服务的硬件部署信息进行匹配，将应用服务的硬件部署信息中与应用服务A的名称对应的应用服务的容器组Pod B的标识信息作为用于提供应用服务A的容器组Pod的标识信息、将应用服务的硬件部署信息中与容器组Pod B所属的节点Node C的标识信息作为与应用服务A关联的Node的标识信息，以及将应用服务的硬件部署信息中与节点Node C所属的业务系统的标识信息作为与应用服务A关联的业务系统的标识信息。

另一种可能的实现方式中，若应用包括应用组件，与应用服务关联的实体对象的指示信息可以包括但不限于与应用组件关联的节点Node的指示信息，应用组件的硬件部署信息可以包括但不限于节点Node信息，服务器可以根据节点Node的指示信息从应用组件的硬件部署信息中确定应用组件部署在的节点Node的标识信息，以及节点Node所属的业务系统的标识信息。

本实现方式中，服务器可以通过节点Node的指示信息与应用组件的硬件部署信息进行匹配，确定出应用组件部署在的节点Node的标识信息，以及节点Node所属的业务系统的标识信息，从而得到了应用组件->节点Node->业务系统等实体对象的软硬件关联关系。

例如，假设节点Node的指示信息为节点Node的IP 0，则服务器可以通过节点Node的IP 0与应用组件的硬件部署信息进行匹配，将应用组件的硬件部署信息中与节点Node的IP 0对应的Node D的标识信息作为与应用组件关联的Node的标识信息，以及将应用服务的硬件部署信息中与节点Node D所属的业务系统的标识信息作为与应用组件关联的业务系统的标识信息。

综上，本申请实施例中，通过根据应用的调用链信息确定至少一个各实体对象的指示信息，并根据指示信息和应用的硬件部署信息，确定各实体对象之间的硬件部署关系。可见，本申请实施例实现了对应用的软件运维信息和硬件运维信息进行关联处理，得到各实体对象之间的软硬件关联关系，以便于根据各实体对象之间的软硬件关联关系可以得到关联度更高的运维知识图谱，从而可以提高运维知识图谱的监控定位效率。

在一个实施例中，图5为本申请另一个实施例中运维知识图谱的确定方法的流程示意图，在上述实施例的基础上，本申请实施例中对上述步骤S201中“分别获取服务系统中的各应用的调用链信息和硬件部署信息”的相关内容进行说明。如图5所示，本申请实施例的上述步骤S201可以包括以下步骤：

步骤S2011、从应用性能管理系统APM获取各应用的调用链信息。

本步骤中，服务器可以从应用性能管理系统APM获取各应用的调用链信息，以便于对各应用的调用链信息进行识别抽取，得到与各应用分别关联的实体对象的标识信息和/或属性信息等。其中，任意实体对象的标识信息用于唯一地标识该实体对象；任意实体对象的属性信息可以用于指示该实体对象的类型等信息。例如，任意实体对象的类型可以包括但不限于tomcat或者mysql。

示例性地，服务器可以通过超文本传输协议(Hypertext Transfer Protocol，HTTP)应用程序编程接口(Application Programming Interface，API)从应用性能管理系统APM获取各应用的调用链信息；当然，还可以通过其他方式从应用性能管理系统APM获取各应用的调用链信息。

步骤S2012、从监控系统和/或容器集群管理系统获取各应用的硬件部署信息。

一种可能的实现方式中，服务器可以从监控系统获取各应用的第一部分硬件部署信息，以及从容器集群管理系统获取各应用的第二部分硬件部署信息。

另一种可能的实现方式中，服务器可以从监控系统或者容器集群管理系统获取各应用的硬件部署信息。

示例性地，服务器可以通过HTTP API从监控系统获取各应用的硬件部署信息；当然，还可以通过其他方式从监控系统获取各应用的硬件部署信息。

示例性地，服务器可以通过命令脚本(例如，Shell脚本等)从容器集群管理系统获取各应用的硬件部署信息；当然，还可以通过其他方式从容器集群管理系统获取各应用的硬件部署信息。

一种可能的实现方式中，若应用包括应用服务，应用的硬件部署信息可以包括但不限于节点Node信息、容器组Pod信息以及应用服务的服务信息，其中，服务信息可以包括但不限于第一服务信息和第二服务信息；服务器可以从监控系统获取各应用服务的第一服务信息、节点Node信息、容器组Pod信息，其中，第一服务信息可以用于指示应用服务的标识信息。

进一步地，服务器可以从容器集群管理系统获取各应用服务的第二服务信息，其中，第二服务信息可以用于指示用于提供应用服务的容器组Pod的标识信息。

应理解，本申请实施例中的第一部分硬件部署信息可以包括但不限于第一服务信息、节点Node信息和容器组Pod信息；第二部分硬件部署信息可以包括但不限于第二服务信息。

另一种可能的实现方式中，若应用包括应用组件，应用的硬件部署信息可以包括但不限于节点Node信息，服务器可以从监控系统获取各应用组件的节点Node信息。

当然，服务器还可以通过其他方式从监控系统和/或容器集群管理系统获取各应用的硬件部署信息。

上述运维知识图谱的确定方法，通过从应用性能管理系统APM获取各应用的调用链信息，以及从监控系统和/或容器集群管理系统获取各应用的硬件部署信息的方式，不仅可以提高软硬件运维信息的采集效率，还可以提高软硬件运维信息的采集及时性，从而有利于根据采集的软硬件运维信息得到更加精准的运维知识图谱。

在一个实施例中，在上述实施例的基础上，为了进一步地提高运维知识图谱的精准性，上述步骤S201可以包括：分别基于定时任务流获取各应用的调用链信息和硬件部署信息。对应地，上述步骤S202和步骤S203可以包括：根据应用的调用链信息和硬件部署信息基于定时任务流，确定与应用关联的各实体对象之间的硬件部署关系，并根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱。

本申请实施例中，服务器可以分别基于定时任务流，定时获取各应用的调用链信息和硬件部署信息。

示例性地，服务器可以基于定时任务流1从应用性能管理系统APM获取各应用的调用链信息。

又一示例性地，服务器可以基于定时任务流2从监控系统获取各应用的硬件部署信息，和/或，可以基于定时任务流3从容器集群管理系统获取各应用的硬件部署信息。

进一步地，对于各应用，服务器可以根据应用的调用链信息和硬件部署信息基于定时任务流(例如定时任务流4)，定时确定与应用关联的各实体对象之间的硬件部署关系，并根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱。

综上，本申请实施例中，通过定时获取各应用的调用链信息和硬件部署信息，并定时根据应用的调用链信息和硬件部署信息确定服务系统的运维知识图谱的方式，可以提高软硬件运维信息的采集实时性，从而有利于根据采集的软硬件运维信息可以更加及时地得到更加精准的运维知识图谱。

在一个实施例中，图6为本申请另一个实施例中运维知识图谱的确定方法的流程示意图，在上述实施例的基础上，本申请实施例中对根据运维知识图谱进行服务系统监控的相关内容进行说明。如图6所示，本申请实施例的方法还可以包括以下步骤：

步骤S204、根据服务系统的运维知识图谱和待查询应用，确定待查询应用的运行情况。

本步骤中，服务器可以根据服务系统的运维知识图谱和待查询应用，确定待查询应用的运行情况。示例性地，运行情况可以用于指示与待查询应用关联的各实体对象之间的硬件部署关系，和/或运行状态；其中，运行状态可以包括但不限于运行正常或者运行异常；硬件部署关系可以用于快速地定位到待查询应用的具体运行位置。当然，运行情况还可以用于指示其他信息。

一种可能的实现方式中，服务器可以在接收到查询指令的情况下，根据服务系统的运维知识图谱和查询指令所指示的待查询应用，确定待查询应用的运行情况。其中，查询指令可以为运维人员触发的，或者可以为软件自动触发的。

另一种可能的实现方式中，服务器可以在检测到达预设查询时间的情况下，根据服务系统的运维知识图谱和待查询应用列表中的待查询应用，确定待查询应用的运行情况。

应理解，服务器还可以显示待查询应用的运行情况，或者可以将待查询应用的运行情况发送给显示终端进行显示，以便于运维人员可以查看待查询应用的运行情况，从而可以及时地发现运维问题。

步骤S205、若根据待查询应用的运行情况确定待查询应用的调用链运行异常，则输出告警信息，其中，告警信息用于指示待查询应用的运行情况。

本步骤中，若根据待查询应用的运行情况确定待查询应用的调用链运行异常，则服务器可以输出告警信息，其中，告警信息可以用于指示待查询应用的运行情况，以便于运维人员可以根据告警信息及时地发现运维问题，并快速地定位到出现异常的待查询应用的运行位置、关联关系和运行状态等，从而可以辅助运维人员及时地解决故障。

综上，本申请实施例中，通过根据服务系统的运维知识图谱和待查询应用，确定待查询应用的运行情况。进一步地，若根据待查询应用的运行情况确定待查询应用的调用链运行异常，则输出用于指示待查询应用的运行情况的告警信息，以便于运维人员可以根据告警信息及时地发现运维问题，并快速地定位到出现异常的待查询应用的运行位置、关联关系和运行状态等，从而可以辅助运维人员及时地解决故障，实现了更加快速精准地监控服务系统。

在一个实施例中，在上述实施例的基础上，本申请实施例对运维知识图谱的确定方法的整体流程进行介绍。

图7为本申请实施例提供的运维知识图谱的确定系统的示意图一，如图7所示，本申请实施例的运维知识图谱的确定系统可以包括但不限于：集成模块701、配置模块702、知识抽取模块703、指标收集模块704、服务采集模块705、存储模块706、确定模块707和定时模块708。

其中，集成模块701可以是指各应用可以通过集成有APM agent框架，使得各应用可以集成到应用性能管理系统APM，便于后续应用性能管理系统APM可以获取各应用的调用链信息。其中，任意应用的调用链信息可以用于指示与应用关联的至少一个实体对象。

配置模块702可以设置于监控系统，使得监控系统可以对各应用进行标签配置，以添加业务系统的标签和/或所属集群等自定义标签等，便于后续获取硬件部署信息。

应理解，知识抽取模块703、指标收集模块704、服务采集模块705、确定模块707和定时模块708可以设置于服务器；其中，存储模块706可以设置于服务器，或者可以独立设置。

其中，知识抽取模块703可以用于对集成模块701获取的调用链信息进行实体对象的识别、属性抽取和关联关系抽取等。

指标收集模块704可以用于通过配置模块702从监控系统获取第一部分硬件部署信息，其中，第一部分硬件部署信息可以包括但不限于节点Node信息、容器组Pod信息以及应用服务的第一服务信息。

服务采集模块705可以用于从容器集群管理系统获取第二部分硬件部署信息，作为指标收集模块704的数据补充；其中，第二部分硬件部署信息可以包括但不限于应用服务的第二服务信息。

存储模块706可以用于存储知识抽取模块703、指标收集模块704和服务采集模块705所获取的软硬件运维信息，并可以实时地或者定时地更新存储到数据库中。需要说明的是，存储模块706在将新软硬件运维信息存储到数据库之前可以自动删除相应的历史软硬件运维信息，以使数据库中存储的均为最新的软硬件运维信息。

确定模块707可以用于根据存储模块706中的软硬件运维信息对各实体对象进行识别抽取，以及对各实体对象之间的硬件部署关系进行识别关联，从而可以根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱。

定时模块708可以用于将确定模块707在确定服务系统的运维知识图谱过程中的各任务放到定时任务流系统中，以便于可以定时运行，从而可以动态更新软硬件运维信息和动态更新服务系统的运维知识图谱。

图8为本申请实施例提供的定时模块的结构示意图，如图8所示，本申请实施例的定时模块可以包括但不限于调度器(Scheduler)801、任务(job)802和触发器(Trigger)803。应理解，任务802为统称，其可以为一个或者多个任务。

其中，调度器801用于将任务802和触发器803整合起来，以基于触发器803设定的时间来执行任务802。示例性地，本申请实施例中的任务802可以包括但不限于：从应用性能管理系统APM获取各应用的调用链信息的任务；从监控系统获取第一部分硬件部署信息的任务；从容器集群管理系统获取第二部分硬件部署信息的任务；其中，不同任务之间可以并行的关系。

示例性地，触发器803可以包括但不限于：简单触发器(SimpleTrigger)8031和Cron触发器8032。简单触发器8031是基于指定的重复次数和指定的重复间隔来触发；Cron触发器8032是基于Cron表达式的作业调度器；其中，Cron又可以称之为计划任务，是在约定的时间执行既定的任务。

本申请实施例中的任务调度方式可以包括但不限于以下至少一项：开始(start)、停止(stop)、暂停(pause)、恢复(resume)、定时、重跑。其中，开始可以是指启动新任务、从当前任务开始执行、从失败任务开始执行；停止可以是指停止当前任务；暂停可以是指暂停当前任务；恢复可以是指恢复暂停任务。

图9为本申请实施例提供的运维知识图谱的确定系统的示意图二，如图9所示，本申请实施例的运维知识图谱的确定系统可以包括但不限于：预处理单元901、数据采集单元902、数据处理单元903、数据存储单元904和数据应用单元905。应理解，预处理单元901与上述集成模块701和配置模块702相对应，数据采集单元902与上述知识抽取模块703、指标收集模块704和服务采集模块705相对应，数据处理单元903与上述确定模块707和定时模块708相对应，数据存储单元904与上述存储模块706相对应。

本申请实施例中，为了实现软硬件维度的运维知识图谱的实时更新，通过预处理单元901将应用程序中集成APM agent以及监控系统部署时预设自定义标签(例如，主机标签和/或所属业务系统的标签等)。进一步地，通过数据采集单元902中从应用性能管理系统APM、监控系统，和/或，容器集群管理系统获取软硬件运维信息。进一步地，通过数据处理单元基于定时任务可以从软件维度和硬件维度进行自动知识抽取和软硬件信息关联等，以自动地确定软硬件维度的运维知识图谱，以便于通过数据应用单元可以进行运维知识图谱的显示、运维知识图谱的查询以及实时告警等。其中，数据存储单元可以用于存储软硬件运维信息和/或运维知识图谱等。

图10为相关技术提供的知识图谱的构建系统的示意图，如图10所示，相关技术中通过数据采集单元人工导入Excel运维信息，然后数据处理单元根据导入的运维信息进行知识抽取以识别实体对象，并在数据存储单元中存储识别的各实体对象，以便于根据各实体对象构建知识图谱，其中，运维信息包括软件运维信息。进一步地，通过数据应用单元可以显示知识图谱，以便于运维人员可以查看知识图谱。可见，相关技术中通过人工导入软件运维信息的方式，不仅运维信息的采集不够及时，采集效率较低，而且无法全面获取软硬件运维信息，使得基于软件运维信息构建的知识图谱无法精准快速地定位问题。

综上，相对于相关技术，本申请实施例中，通过动态地自动获取各应用的调用链信息和硬件部署信息，并根据各应用的调用链信息和硬件部署信息进行实体对象识别和软硬件关联关系的抽取。进一步地，根据各实体对象和软硬件关联关系，动态地自动确定运维知识图谱。可见，本申请实施例中可以及时地采集软硬件运维信息，采集效率较高，而且本申请实施例中还可以及时地动态更新运维知识图谱，且运维知识图谱的关联度更高，使得运维知识图谱的精准度更高，以便于精准地关系追溯，从而可以实现根据运维知识图谱更加方便快速地定位软硬件问题，以及及时地解决故障，提高了运维知识图谱的监控定位效率。

在上述实施例的基础上，为了便于理解，本申请下述实施例中以应用包括应用服务、应用性能管理系统APM为Skywalking、监控系统为Prometheus，以及容器集群管理系统为Kubernetes为例，对运维知识图谱的确定方法的整体流程进行说明。

图11为本申请实施例提供的运维知识图谱的确定方法的整体流程示意图，如图11所示，本申请实施例的方法可以包括如下步骤：

1)服务器可以从监控系统获取第一部分硬件部署信息，其中，第一部分硬件部署信息可以包括但不限于节点Node信息、容器组Pod信息以及应用服务的第一服务信息；第一服务信息可以用于指示应用服务的标识信息。例如，第一服务信息可以包括但不限于应用服务的名称和/或所属的业务系统的名称等信息。

示例性地，服务器可以通过API分别从监控系统1、监控系统2和监控系统3获取节点Node信息、容器组Pod信息以及第一服务信息。其中，第一服务信息无法获知应用服务与容器组Pod之间的关系。

2)服务器可以从容器集群管理系统获取第二部分硬件部署信息，其中，第二部分硬件部署信息可以包括但不限于应用服务的第二服务信息；第二服务信息可以用于指示用于提供应用服务的容器组Pod的标识信息。例如，第二服务信息可以包括但不限于应用服务的名称和Pod IP。

示例性地，服务器可以通过命令脚本获取第二服务信息，以便于根据第二服务信息可以获取到应用服务与容器组Pod之间的关系，从而可以得到应用服务->容器组Pod->节点Node三者的关系；其中，第二服务信息可以包括但不限于选择器(selector)信息和端点(endpoints)信息；选择器信息可以用于指示应用服务的名称，端点信息可以用于指示PodIP。

3)服务器可以从应用性能管理系统APM获取应用的调用链信息。

示例性地，服务器可以通过API从应用性能管理系统APM获取应用的调用链信息(或者称之为软件部署信息，或者软件运维信息)，以便于主要根据调用链信息和上述硬件部署信息(或者称之为硬件运维信息)进行绘制运维知识图谱。

4)服务器可以根据应用的调用链信息和硬件部署信息确定与应用关联的各实体对象之间的硬件部署关系，并根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱。

示例性地，若调用链信息所指示的任意实体对象为应用组件，且以IP和端口组合形式指示的，则服务器可以根据IP从硬件部署信息确定应用组件部署在的节点Node和所属的业务系统。

又一示例性地，若调用链信息所指示的任意实体对象为应用服务，且以“应用服务的名称.命名空间：端口”形式指示的，则服务器可以根据“应用服务的名称”从硬件部署信息确定用于提供应用服务的容器组Pod，容器组Pod所属的节点Node和业务系统。

需要说明的是，若调用链信息所指示的是域名，则服务器可以将域名作为单独的部署单元，没有所属的业务系统和节点Node等。

若调用链信息所指示的是虚机集群，则服务器可以根据各节点Node的端口和type是否都一致来判断访问的是否是同一个集群；进一步地，若确定访问的是同一个集群，则服务器在显示运维知识图谱的过程中，可以将各节点Node进行合并，以便于运维人员在点击集群的情况下再展开各节点Node。

应该理解的是，虽然上述流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，上述流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，图12为本申请一个实施例中运维知识图谱的确定装置的结构示意图，本申请实施例中的运维知识图谱的确定装置可以部署在服务器中。如图12所示，本申请实施例的运维知识图谱的确定装置可以包括：获取模块1201、第一确定模块1202和第二确定模块1203。

其中，获取模块1201，用于分别获取服务系统中的各应用的调用链信息和硬件部署信息；

第一确定模块1202，用于对于各应用，根据应用的调用链信息和硬件部署信息，确定与应用关联的各实体对象之间的硬件部署关系；

第二确定模块1203，用于根据各实体对象之间的硬件部署关系，确定服务系统的运维知识图谱；其中，运维知识图谱用于监控服务系统的运行情况。

在一个实施例中，第一确定模块1202，包括：

第一确定单元，用于根据应用的调用链信息确定至少一个实体对象的指示信息；

第二确定单元，用于根据指示信息和应用的硬件部署信息，确定各实体对象之间的硬件部署关系。

在一个实施例中，硬件部署信息包括以下至少一项：节点Node信息、容器组Pod信息、服务信息；

其中，节点Node信息用于指示节点Node的标识信息以及节点Node所属的业务系统的标识信息；容器组Pod信息用于指示容器组Pod的标识信息，以及容器组Pod所属的节点Node的标识信息；服务信息用于指示应用服务的标识信息以及用于提供应用服务的容器组Pod的标识信息。

在一个实施例中，若应用包括应用服务，指示信息包括应用服务的标识信息，，第二确定单元具体用于：

根据应用服务的标识信息从应用服务的硬件部署信息中确定用于提供应用服务的容器组Pod的标识信息、容器组Pod所属的节点Node的标识信息，以及节点Node所属的业务系统的标识信息；其中，节点Node所属的业务系统与应用服务所属的业务系统相同。

在一个实施例中，若应用包括应用组件，指示信息包括与应用组件关联的节点Node的指示信息，第二确定单元具体用于：

根据节点Node的指示信息从应用组件的硬件部署信息中确定应用组件部署在的节点Node的标识信息，以及节点Node所属的业务系统的标识信息。

在一个实施例中，获取模块1201，包括：

第一获取单元，用于从应用性能管理系统APM获取各应用的调用链信息；

第二获取单元，用于从监控系统和/或容器集群管理系统获取各应用的硬件部署信息。

在一个实施例中，若应用包括应用服务，应用的硬件部署信息包括节点Node信息、容器组Pod信息以及应用服务的服务信息，其中，服务信息包括第一服务信息和第二服务信息，第二获取单元具体用于：

从监控系统获取各应用服务的第一服务信息、节点Node信息、容器组Pod信息，其中，第一服务信息用于指示应用服务的标识信息；

从容器集群管理系统获取各应用服务的第二服务信息，其中，第二服务信息用于指示用于提供应用服务的容器组Pod的标识信息。

在一个实施例中，若应用包括应用组件，应用的硬件部署信息包括节点Node信息，第二获取单元具体用于：

从监控系统获取各应用组件的节点Node信息。

在一个实施例中，获取模块1201具体用于：

分别基于定时任务流获取各应用的调用链信息和硬件部署信息；

对应地，第一确定模块1202具体用于：

根据应用的调用链信息和硬件部署信息基于定时任务流，确定与应用关联的各实体对象之间的硬件部署关系；

第二确定模块1203具体用于：

根据各实体对象之间的硬件部署关系基于定时任务流，确定服务系统的运维知识图谱。

在一个实施例中，运维知识图谱的确定装置还包括：

第三确定模块，用于根据服务系统的运维知识图谱和待查询应用，确定待查询应用的运行情况，其中，运行情况用于指示待查询应用的调用链中的各实体对象之间的硬件部署关系，和/或运行状态。

在一个实施例中，运维知识图谱的确定装置还包括：

输出模块，用于若根据待查询应用的运行情况确定待查询应用的调用链运行异常，则输出告警信息，其中，告警信息用于指示待查询应用的运行情况。

本申请实施例中，关于运维知识图谱的确定装置的具体限定可以参见上文中对于运维知识图谱的确定方法的限定，其实现原理和技术效果类似，此处不再赘述。上述运维知识图谱的确定装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于服务器中的处理器中，也可以以软件形式存储于服务器中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，图13为本申请一个实施例中服务器的结构示意图，如图13所示，本申请实施例提供的服务器可以包括通过系统总线连接的处理器、存储器和网络接口。其中，该服务器的处理器用于提供计算和控制能力。该服务器的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该服务器的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现本申请上述运维知识图谱的确定方法实施例中的技术方案，其实现原理和技术效果类似，此处不再赘述。

本领域技术人员可以理解，图13中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的服务器的限定，具体的服务器可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种服务器，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现本申请上述运维知识图谱的确定方法实施例中的技术方案，其实现原理和技术效果类似，此处不再赘述。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现本申请上述运维知识图谱的确定方法实施例中的技术方案，其实现原理和技术效果类似，此处不再赘述。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现本申请上述运维知识图谱的确定方法实施例中的技术方案，其实现原理和技术效果类似，此处不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (15)

1.一种运维知识图谱的确定方法，其特征在于，所述方法包括：

分别获取服务系统中的各应用的调用链信息和硬件部署信息；

对于各所述应用，根据所述应用的调用链信息和所述硬件部署信息，确定与所述应用关联的各实体对象之间的硬件部署关系；

根据所述各实体对象之间的硬件部署关系，确定所述服务系统的运维知识图谱；其中，所述运维知识图谱用于监控所述服务系统的运行情况。

2.根据权利要求1所述的方法，其特征在于，所述根据所述应用的调用链信息和所述硬件部署信息，确定与所述应用关联的各实体对象之间的硬件部署关系，包括：

根据所述应用的调用链信息确定至少一个所述实体对象的指示信息；

根据所述指示信息和所述应用的硬件部署信息，确定所述各实体对象之间的硬件部署关系。

3.根据权利要求2所述的方法，其特征在于，所述硬件部署信息包括以下至少一项：节点Node信息、容器组Pod信息、服务信息；

其中，所述节点Node信息用于指示所述节点Node的标识信息以及所述节点Node所属的业务系统的标识信息；所述容器组Pod信息用于指示所述容器组Pod的标识信息，以及所述容器组Pod所属的节点Node的标识信息；所述服务信息用于指示应用服务的标识信息以及用于提供所述应用服务的容器组Pod的标识信息。

4.根据权利要求3所述的方法，其特征在于，若所述应用包括应用服务，所述指示信息包括所述应用服务的标识信息，所述根据所述指示信息和所述应用的硬件部署信息，确定所述各实体对象之间的硬件部署关系，包括：

根据所述应用服务的标识信息从所述应用服务的硬件部署信息中确定用于提供所述应用服务的所述容器组Pod的标识信息、所述容器组Pod所属的所述节点Node的标识信息，以及所述节点Node所属的业务系统的标识信息；其中，所述节点Node所属的业务系统与所述应用服务所属的业务系统相同。

5.根据权利要求3所述的方法，其特征在于，若所述应用包括应用组件，所述指示信息包括与所述应用组件关联的节点Node的指示信息，所述根据所述指示信息和所述应用的硬件部署信息，确定所述各实体对象之间的硬件部署关系，包括：

根据所述节点Node的指示信息从所述应用组件的硬件部署信息中确定所述应用组件部署在的所述节点Node的标识信息，以及所述节点Node所属的业务系统的标识信息。

6.根据权利要求1-5中任一项所述的方法，其特征在于，所述分别获取服务系统中的各应用的调用链信息和硬件部署信息，包括：

从应用性能管理系统APM获取所述各应用的调用链信息；

从监控系统和/或容器集群管理系统获取各所述应用的硬件部署信息。

7.根据权利要求6所述的方法，其特征在于，若所述应用包括应用服务，所述应用的硬件部署信息包括节点Node信息、容器组Pod信息以及所述应用服务的服务信息，其中，所述服务信息包括第一服务信息和第二服务信息，所述从监控系统和/或容器集群管理系统获取各所述应用的硬件部署信息，包括：

从所述监控系统获取各所述应用服务的第一服务信息、节点Node信息、容器组Pod信息，其中，所述第一服务信息用于指示所述应用服务的标识信息；

从所述容器集群管理系统获取各所述应用服务的所述第二服务信息，其中，所述第二服务信息用于指示用于提供所述应用服务的容器组Pod的标识信息。

8.根据权利要求6所述的方法，其特征在于，若所述应用包括应用组件，所述应用的硬件部署信息包括节点Node信息，所述从监控系统和/或容器集群管理系统获取各所述应用的硬件部署信息，包括：

从所述监控系统获取各所述应用组件的节点Node信息。

9.根据权利要求1-5中任一项所述的方法，其特征在于，所述分别获取服务系统中的各应用的调用链信息和硬件部署信息，包括：

分别基于定时任务流获取所述各应用的调用链信息和硬件部署信息；

对应地，所述根据所述应用的调用链信息和所述硬件部署信息，确定与所述应用关联的各实体对象之间的硬件部署关系，并根据所述各实体对象之间的硬件部署关系，确定所述服务系统的运维知识图谱，包括：

根据所述应用的调用链信息和所述硬件部署信息基于定时任务流，确定与所述应用关联的各实体对象之间的硬件部署关系，并根据所述各实体对象之间的硬件部署关系，确定所述服务系统的运维知识图谱。

10.根据权利要求1-5中任一项所述的方法，其特征在于，所述方法还包括：

根据所述服务系统的运维知识图谱和待查询应用，确定所述待查询应用的运行情况，其中，所述运行情况用于指示所述待查询应用的调用链中的各实体对象之间的硬件部署关系，和/或运行状态。

11.根据权利要求10所述的方法，其特征在于，所述方法还包括：

若根据所述待查询应用的运行情况确定所述待查询应用的调用链运行异常，则输出告警信息，其中，所述告警信息用于指示所述待查询应用的运行情况。

12.一种运维知识图谱的确定装置，其特征在于，所述装置包括：

获取模块，用于分别获取服务系统中的各应用的调用链信息和硬件部署信息；

第一确定模块，用于对于各所述应用，根据所述应用的调用链信息和所述硬件部署信息，确定与所述应用关联的各实体对象之间的硬件部署关系；

第二确定模块，用于根据所述各实体对象之间的硬件部署关系，确定所述服务系统的运维知识图谱；其中，所述运维知识图谱用于监控所述服务系统的运行情况。

13.一种服务器，包括：存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1-11中任一项所述的方法的步骤。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-11中任一项所述的方法的步骤。

15.一种计算机程序产品，包括计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1-11中任一项所述的方法的步骤。