监测数据的关联方法、装置、计算机设备和存储介质

技术领域

本申请涉及运维技术领域，特别是涉及一种监测数据的关联方法、装置、计算机设备、存储介质和计算机程序产品。

背景技术

随着互联网的发展，产品和服务的规模呈线性增长，相应的运维监控系统也随之增多，由此产生了海量的监测数据。现有的监测数据在各自独立的监控系统中，运维人员在发现问题和查找问题的原因时，需要前往各个监控系统分别查看指标、调用链和日志，再结合人工关联分析来定位根因，运维效率低下。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高运维效率的监测数据的关联方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。

第一方面，本申请提供了一种监测数据的关联方法。所述方法包括：

分别收集来源于监测对象集群的多个维度的监测数据，每个维度的监测数据携带有对应于相应维度的至少一个数据标签；

基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系；

基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系；

根据所述第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，相互关联的各个维度的监测数据用于进行运维关联分析。

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

确定待监控的至少一个监测对象；

按照预先设置的对应于各个维度的数据模型，确定监测对象所采集的监测数据中内置的数据标签。

在其中一个实施例中，所述维度至少包括指标维度、日志维度、以及调用链维度中的一种；每个维度均对应于时间戳标签，且所述指标维度至少对应于与监测对象相对应的数据标签，所述日志维度至少对应于与应用服务相对应的数据标签，所述调用链维度至少对应于与链路相对应的数据标签。

在其中一个实施例中，所述基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系，包括：

基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立携带有与应用服务相对应的数据标签的监测数据，与携带有与监测对象相对应的数据标签的监测数据之间的第二关联关系。

在其中一个实施例中，所述分别收集来源于监测对象集群的各个维度的监测数据，包括：

针对不同的维度，分别利用适配于相应维度的数据采集适配器，收集监测对象集群中各监测对象采集的监测数据。

在其中一个实施例中，所述分别收集来源于监测对象集群的各个维度的监测数据之后，还包括：

根据各监测数据携带的数据标签中的时间戳标签，按照所述监测数据分别所属的维度，将处于预设时间范围内的监测数据分别存储至对应于各个维度的分布式存储主题中；

将处于预设时间范围外的监测数据存储至分布式文件系统中。

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

利用分布式查询引擎，对分布式存储主题中所存储的各个维度的监测数据进行关联查询，所关联查询到的监测数据用于运维分析。

第二方面，本申请还提供了一种监测数据的关联装置。所述装置包括：

收集模块，用于分别收集来源于监测对象集群的多个维度的监测数据，每个维度的监测数据携带有对应于相应维度的至少一个数据标签；

关联模块，用于基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系；

所述关联模块，还用于基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系；

所述关联模块，还用于根据所述第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，相互关联的各个维度的监测数据用于进行运维关联分析。

第三方面，本申请还提供了一种计算机设备。所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

分别收集来源于监测对象集群的多个维度的监测数据，每个维度的监测数据携带有对应于相应维度的至少一个数据标签；

基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系；

基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系；

根据所述第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，相互关联的各个维度的监测数据用于进行运维关联分析。

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

分别收集来源于监测对象集群的多个维度的监测数据，每个维度的监测数据携带有对应于相应维度的至少一个数据标签；

基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系；

基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系；

根据所述第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，相互关联的各个维度的监测数据用于进行运维关联分析。

第五方面，本申请还提供了一种计算机程序产品。所述计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：

分别收集来源于监测对象集群的多个维度的监测数据，每个维度的监测数据携带有对应于相应维度的至少一个数据标签；

基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系；

基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系；

根据所述第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，相互关联的各个维度的监测数据用于进行运维关联分析。

上述监测数据的关联方法、装置、计算机设备、存储介质和计算机程序产品，通过为各个维度的监测数据添加标签，在分别收集来源于监测对象集群的多个维度的监测数据后，基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系，再基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系，由此即可根据所述第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，实现将各种维度的监测数据融合和关联在一起，由此能够对统一收集的监测数据进行关联分析，无需再人工逐一排查与定位，提高了运维效率。

附图说明

图1为一个实施例中监测数据的关联方法的应用环境图；

图2为一个实施例中监测数据的关联方法的流程示意图；

图3A为一个实施例中指标维度的数据标签示意图；

图3B为一个实施例中调用链维度的数据标签示意图；

图3C为一个实施例中日志维度的数据标签示意图；

图4为一个实施例中实体联系图的示意图；

图5为一个实施例中添加标签的步骤的流程示意图；

图6为一个实施例中存储步骤的流程示意图；

图7为一个实施例中运维分析的整体框架的示意图；

图8为一个实施例中监测数据的关联装置的结构框图；

图9为一个实施例中计算机设备的内部结构图。

具体实施方式

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

在运维领域，运维人员通常会基于运维的目的搭建相应的监测系统，从而监测系统/应用的运行。比如通过监测各项指标并分析各项指标的数据，由此判定基础设施的运行状况。又如，通过日志平台监测日志数据，当业务出现问题时通过排查日志分析原因。再如，通过链路监测平台监测拓扑依赖和各节点的响应时间，从而监测业务是否出现延迟问题等。然而现有的运维监控方式中，采集到的各种监测数据存在于各自独立的监控系统中，无法实现统一的关联分析和可视化。譬如，当运维人员收到一条告警信息时，要想定位问题所在，运维人员需要逐一打开各个平台/系统，分别查看指标数据、调用链数据和日志数据，再结合人工关联分析来定位根因。随着线上系统日益复杂，海量的数据和复杂的系统导致运维人员难以有效定位问题，运维效率十分低下。

有鉴于此，本申请提供一种检测数据的关联方法，通过给监测数据添加标签，根据标签并结合预先配置的应用服务与基础设施之间的关系，将三种监测数据关联起来，由此可供运维人员统一进行关联分析，极大地提高了运维效率。

本申请实施例提供的监测数据的关联方法，可以应用于如图1所示的应用环境中。其中，监测对象102通过网络与服务器104进行通信。数据存储系统可以存储服务器104需要处理的数据，例如监测数据。数据存储系统可以集成在服务器104上，也可以放在云上或其他网络服务器上。其中，监测对象102采集监测数据，由服务器104分别收集各个监测对象102所采集的各个维度的监测数据。服务器104根据监测数据中携带的数据标签，以及预先建立的应用服务与监测对象之间的实体联系，将各个维度的监测数据互相关联起来，以实现统一的运维关联分析。

其中，监测对象102可以为基础设施，包括软件基础设施和硬件基础设施中的至少一种，例如可以是终端、服务器，也可以是数据库、系统、以及应用服务等中的一种或多种。相应地，监测对象102所采集的监测数据可以是终端的性能数据、以及监测数据等中的一种或多种，也可以是应用运行性能数据、应用日志数据、业务数据、以及服务调用信息等中的一种或多种，亦可以是操作系统、CPU(Central Processing Unit，中央处理器)、内存、缓存、以及I/O(Input/Output，输入输出)信息等中的一种或多种。通常设置有多个监测对象102来进行运维监控，多个监测对象102可以构成监测对象集群。示例性地，监测对象102为终端时，可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑、物联网设备、以及便携式可穿戴设备等中的一种或多种。其中，物联网设备可为智能音箱、智能电视、智能空调、以及智能车载设备等中的一种或多种。便携式可穿戴设备可为智能手表、智能手环、以及头戴设备等中的一种或多种。

其中，服务器104可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。示例性地，服务器104可以是Puslar(一种云原生架构的分布式消息流平台)。

在一个实施例中，如图2所示，提供了一种监测数据的关联方法，该方法可以应用于终端或服务器，或由终端和服务器协同执行。本申请实施例中以该方法应用于图1中的服务器为例进行说明，包括以下步骤：

步骤S202，分别收集来源于监测对象集群的多个维度的监测数据，每个维度的监测数据携带有对应于相应维度的至少一个数据标签。

其中，监测数据又称可观察性数据，可划分为多个维度，包括但不限于指标维度、日志维度、以及调用链维度中的一种或多种。其中，指标维度的监测数据为指标性数据(Metrics)，用于展示某个指标在某个时段的运行状态，以判断运行状态和趋势。日志维度的监测数据为日志数据(Logging)，通常为记录的非结构化的文本内容，用于提供系统/进程中精细化的信息，例如某个事件、访问记录等。调用链维度的监测数据为调用链数据(Tracing)，用于提供从接收请求到处理完毕整个生命周期的跟踪路径，例如服务调用情况等。

具体地，服务器分别收集来源于监测对象集群中各个监测对象所采集的监测数据，并确定各监测数据所携带的数据标签。由于监测对象的不同，所采集的监测数据也具有多个维度，每个维度的监测数据携带有对应于相应维度的至少一个数据标签。

为了不改变监测数据原有的采集方式，而原有的监测数据采集可能是由各个相互独立的监控采集代理(Agent)或监控管理系统分别采集的，采集到的监测数据不仅分散、缺乏关联性，并且采集数据的格式、冗余情况等都不尽相同。为此，在一些实施例中，分别收集来源于监测对象集群的各个维度的监测数据，包括：针对不同的维度，分别利用适配于相应维度的数据采集适配器，收集监测对象集群中各监测对象采集的监测数据。

具体地，对于每个维度的监测数据，服务器通过自定义的数据采集适配器收集监测对象集群中各监测对象采集的监测数据，以适配多样化的采集方式或采集系统。同时，在收集的过程中，通过数据采集适配器对采集到的原始的监测数据进行初步的处理，例如冗余平整化处理、反范式处理等。示例性地，数据采集适配器通过利用ETL(Extract-Transform-Load，抽取、转换、装载)工具对比较复杂的调用链数据(例如树、图结构)进行冗余平整化处理。由此，无需改变监测数据原有的采集方式，也无需专门设置新的监控系统或平台来统一采集监测数据，只需在原有的监控系统的基础上采用适配于各维度的数据采集适配器，即可将各种各样的监控系统所采集的监测数据统一地收集起来，用于后续进行统一的运维分析。

为了实现各个维度的监测数据的关联与融合，关键在于建立各个维度的监测数据相互之间的关联关系。最基础的信息可以用于定位问题的发生时间和发生位置，例如通过时间戳来定位发生时间、通过主机名或IP来定位发生位置。为此，本申请实施例中通过为监测数据添加数据标签，通过数据标签的方式实现各个维度的监测数据之间的初步关联。

其中，监测数据中的数据标签是预先添加的，每个维度对应设置有相应的至少一个数据标签。对于各个维度的监测数据，需要在时间上进行定位，因此每个维度均应设置相应的时间戳标签。

其中，由于指标维度可以用于监测一或多个监测对象的运行状态，因此指标维度至少包括与监测对象相对应的数据标签，以便于定位发生问题的具体监测对象。举例而言，如图3A所示，可以为指标维度相应设置设施名、或者设施实例名等数据标签。其中，监测对象由一或多个设施实例构成，例如分布式数据库为监测对象，构成分布式数据库的各个节点即为其设施实例。在一些情况下，根据实际需求还可以为指标维度设置例如主机名、IP(Internet Protocol，网际互连协议)、以及实例IP端口等数据标签。

其中，由于调用链维度可以用于监控服务的调用等链路运行情况，因此调用链维度至少对应于与链路相对应的数据标签，以便于在问题发生时定位具体的调用链、以及该调用链所调用的应用服务。例如，如图3B所示，可以为调用链维度设置调用链ID(traceID)、应用服务名等数据标签，在一些情况下，根据实际需求还可以为调用链维度设置例如应用服务实例名、端点URL(Uniform Resource Locator，统一资源定位器)、以及调用链跨度ID(span ID)等中的一种或多种。其中，调用链ID是由调用链中的第一个被调用的应用服务而产生，且附加在调用链的消息中传递至调用链中的各个节点。例如，系统向应用服务A发起一个调用请求，应用服务A即生成全局唯一的trace ID。

其中，由于日志维度可以用于监控应用服务运行过程中的事件情况，因此日志维度至少对应于与应用服务相对应的数据标签，以便于在问题发生时定位具体的应用服务。例如，如图3C所示，可以为日志维度设置应用服务名等数据标签，在一些情况下，根据实际需求还可以为日志维度设置例如关联所请求的调用链ID、调用链跨度ID等中的一种或多种。

需要说明的是，由于所添加的数据标签是全局唯一的，为调用链维度所设置的应用服务名标签与为日志维度设置的应用服务名标签虽然均指向应用服务，但具体的数据标签的形式可以不同，此时称两个数据标签为相匹配的。例如，为调用链维度设置的应用服务名标签通过“serv_name”的字段进行标识，为日志维度设置的应用服务名标签通过“app_name”的字段进行标识，而尽管二者的具体字段不同，但应用服务名标签均是用于指向相应运行的应用服务。

步骤S204，基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系。

通过为各个维度设置标签，由此采集到的监测数据携带有对应于其所属维度的数据标签，根据各监测数据所携带的数据标签中均指向的同一对象(例如应用服务、调用链等)即可实现不同维度的监测数据的初步关联。

具体地，对于所收集的各个维度的监测数据，服务器在确定各监测数据所携带的数据标签后，根据不同维度的监测数据携带的相匹配的数据标签，建立携带有该相匹配的数据标签的监测数据之间的关联关系，称为第一关联关系。

示例性地，对于所获取的日志维度的监测数据A和调用链维度的监测数据B，根据监测数据A和监测数据B均携带的应用服务名标签，根据数据标签所指向的具体应用服务，即可建立监测数据A和监测数据B之间的关联关系。

步骤S206，基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系。

若各个维度均设置有相匹配的数据标签，则在获取监测数据后，服务器即可根据所携带的相匹配的数据标签，建立各个维度的监测数据之间的相互关联关系。在一些情况下，仅有部分维度的监测数据可以根据相匹配的数据标签进行关联，例如日志维度的监测数据与调用链维度的监测数据，可以通过为调用链维度设置应用服务名标签，实现调用链维度的监测数据与日志维度的监测数据之间的关联，或者，也可以通过为日志维度设置调用链ID标签，实现调用链维度的监测数据与日志维度的监测数据之间的关联。在一些情况下，由于各个维度所监测的目标/方式不同，可能存在没有相匹配的数据标签的多个维度。例如，指标维度可能无法添加有应用服务名的数据标签。

为了实现各个维度的监测数据之间的相互关联关系，本申请实施例中，通过预先建立应用服务与监测对象之间的实体联系，从而将相应维度的监测数据关联起来。

具体地，服务器基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，再根据为各个维度所设置的数据标签，确定应用服务与对应的数据标签之间的关联关系、以及监测对象与相应的数据标签之间的关联关系，即可建立相应多个维度的监测数据之间的关联关系，称为第二关联关系，由此间接地将多个维度的监测数据关联起来。

在一些实施例中，可以通过获取配置管理数据库(Configuration ManagementDatabase，CMDB)中的配置信息，获取应用服务与监测对象集群中各监测对象之间的实体联系。举例而言，如图4提供的实体联系图所示，通过在部署应用服务或基础设施，或在添加监测对象的阶段，建立业务(Bussiness)数据、应用服务(Application)、基础设施(Facility)、以及设施实例(Facility_Instance)相互之间关系，从而用于除数据标签外进一步描述各个维度的监测数据之间的关联关系。其中，不同的业务具有各自唯一的ID(标识)信息和Name(名称)信息，每个业务下包括一或多个应用服务，每个应用服务也具有各自唯一的ID信息和Name信息。而每个应用服务与基础设施相关联，每个基础设施也具有各自唯一的ID信息和Name信息。每个基础设施下具有一或多个设施实例，每个设施实例也具有各自唯一的ID信息和具体的实例(Instance)信息。

类似地，服务器可以通过与CMDB相适配的数据采集适配器来获取其中配置的实体联系等信息。示例性地，服务器通过利用Flink CDC连接器(Flink-CDC-Connector)作为数据采集适配器，收集配置在CMDB中的应用服务、设施、以及设施实例等中的一种或多种数据。在一个具体的示例中，针对于CMDB中数据，服务器通过利用Pulsar-Flink连接器的upsert(更新插入)机制，将增量数据转化为全量数据，以供后续进行关联分析。

在一个实施例中，基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系，包括：基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立携带有与应用服务相对应的数据标签的监测数据，与携带有与监测对象相对应的数据标签的监测数据之间的第二关联关系。

具体地，服务器在获取多个维度的监测数据后，确定其中一个维度的监测数据携带的数据标签为与应用服务相对应的数据标签，且另一个维度的监测数据携带的数据标签为与监测对象相对应的数据标签时，根据预先建立的应用服务与监测对象之间的实体联系，即可建立两个维度的监测数据之间的第二关联关系。

举例而言，指标维度中设置有设施名或设施实例名的数据标签，而根据该数据标签，相应维度的指标数据可以定位至对应的监测对象。而根据预先建立的应用服务与监测对象之间的实体联系，指标维度即可根据与监测对象之间的对应关系，间接与应用服务建立联系。而日志维度中设置有应用服务名的数据标签，该数据标签指向应用服务，由此，指标维度的监测数据即可与日志维度的监测数据建立关联关系。

本实施例中，通过结合预先建立的应用服务与监测对象集群中各监测对象之间实体联系，间接将多个维度的检测数据关联起来，再结合所建立的第一关联关系，即可实现将各个维度的监测数据均相互关联，由此实现对监测数据的统一关联分析。

步骤S208，根据第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，相互关联的各个维度的监测数据用于进行运维关联分析。

具体地，在根据多个维度下相匹配的数据标签确定各监测数据之间的第一关联关系、和根据预先建立的实体联系确定各监测数据之间的第二关联关系之后，结合第一关联关系和第二关联关系，服务器即可确定各个维度的监测数据相互之间的目标关联关系。

举例而言，根据日志维度的监测数据与调用链维度的监测数据之间的关联关系，以及指标维度的监测数据与日志维度的监测数据之间的关联关系，服务器即可将日志维度、指标维度、调用链维度这三者关联起来，实现三个维度的监测数据的融合。由此，相互关联的各个维度的监测数据可以用于后续进行统一的运维关联分析、查询、以及可视化展示等。

上述监测数据的关联方法中，通过为各个维度的监测数据添加标签，在分别收集来源于监测对象集群的多个维度的监测数据后，基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系，再基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系，由此即可根据第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，实现将各种维度的监测数据融合和关联在一起，由此能够对统一收集的监测数据进行关联分析，无需再人工逐一排查与定位，提高了运维效率。同时，通过统一收集各自分散的监测数据并进行关联，能够为下游的关联查询做好充分的准备。

在一些实施例中，如图5所示，本申请实施例提供的监测数据的关联方法还包括添加标签的步骤，包括：

步骤S502，确定待监控的至少一个监测对象。

步骤S504，按照预先设置的对应于各个维度的数据模型，确定监测对象所采集的监测数据中内置的数据标签。

具体地，服务器首先确定待监控的一或多个监测对象，例如确定待监控的具体的应用服务、数据库、内存、缓存等。根据预先为各个维度设置的数据模型，服务器即可确定每个维度的监测数据所需添加的数据标签，从而确定监测对象所采集的监测数据汇总内置的数据标签。其中，各个维度的数据模型规定了相应维度的监测数据携带的数据标签的标签名、字段(或字符串)、描述、以及是否必选等中的一种或多种。

示例性地，服务器可以提供统一的运维平台，运维人员在该运维平台中添加监控任务时，确定所要监控的基础设施(即监测对象)，并为指标维度设置相应的数据标签。由此，该基础设施在采集监测数据时即添加相应的标签，服务器收集的监测数据即携带有对应于相应维度的数据标签。

在一些实施例中，根据预先设置的数据模型确定每个维度的监测数据所需添加的数据标签之后，可以通过各种工具实现添加标签的步骤。例如，可以通过APM(ApplicationPerformance Management，即应用性能管理)日志工具包为日志维度设置包括trace Id和span Id等数据标签。

本实施例中，通过为各个维度的监测数据添加标签，可以将多个维度的监测数据进行初步关联，以便于后续将各个维度的监测数据全部相互关联起来。

传统的数据关联分析都是通过OLAP(Online analytical processing，联机分析处理)数据仓库实现，通过建立数据仓库，并在收集了监测数据后将监测数据存入数据仓库中。但随着数据规模的日益增长，将数据搬运到数据仓库的过程中硬件/软件成本、以及维护管理成本都是巨大的。并且，数据仓库方式十分笨重且耗时，为了查询想要的监测数据，运维人员不得不耗费较长的时间，想要快速进行运维关联分析对于运维人员而言一直是待解的难题。为此，在一个实施例中，如图6所示，分别收集来源于监测对象集群的各个维度的监测数据之后，还包括：

步骤S602，根据各监测数据携带的数据标签中的时间戳标签，按照监测数据分别所属的维度，将处于预设时间范围内的监测数据分别存储至对应于各个维度的分布式存储主题中。

步骤S604，将处于预设时间范围外的监测数据存储至分布式文件系统中。

具体地，服务器在分布式存储平台中，为各个维度分别建立相应的分布式存储主题，对于所收集的监测数据，服务器按照各监测数据各自所属的维度，分别将监控数据存储至相应的分布式存储主题中。同时，在存储过程中，服务器根据各监测数据携带的时间戳标签，确定监测数据的采集时间，将将处于预设时间范围内的监测数据(较新的监测数据)存储至分布式存储主题，将较旧的数据移动到分布式文件系统中。示例性地，通过Pulsar平台实时存储监测数据，并针对不同的维度建立不同的主题(Topic)，能够提高存储的效率，同时将较旧的数据移动到长期存储介质中，减少了存储成本，提高了资源利用率。

本实施例中，通过分布式平台存储监测数据，有效地保障了运维数据的实时性，在关联查询时的速度较快，提高了运维分析的效率。

在利用分布式存储平台的基础上，在一个实施例中，方法还包括：利用分布式查询引擎，对分布式存储主题中所存储的各个维度的监测数据进行关联查询，所关联查询到的监测数据用于运维分析。具体地，本申请实施例中通过利用分布式查询引擎对分布式存储主题中所存储的各个维度的监测数据进行关联查询，而非通过传统的数据库查询语句逐一进行查询，能够提高查询效率，保证了数据关联查询的实时性。示例性地，通过利用OpenLookeng分布式实时查询引擎，能够快速地查询想要的监测数据，提高了运维分析的效率。

在一个具体的示例中，通过架设Pulsar分布式存储平台结合OpenLookeng分布式实时查询引擎的框架，不仅保证了数据查询的实时性，还能避免数据孤岛的问题，实现了监测数据的关联分析。

在一些实施例中，本申请实施例还可以应用在面向AIOps(Algorithmic ITOperations，智能运维)的场景中，相互关联的监测数据可以以在线或离线的方式输入至机器学习模型中，以供机器学习模型自动进行问题定位和检测。机器学习模型可以部署在上述实施例中的服务器中，或者部署在其他分布式平台中，对此本申请实施例不做限制。

为了便于更好地理解本发明的技术构思，下面以一个具体的示例进行举例说明。如图7所示，以Metrics、Tracing、Logging三个维度为例，针对不同的维度，采用不同的数据采集适配器进行收集。譬如，对于Metrics维度的监测数据，采用prom-pulsar-remote-write(即Prometheus pulsar远程写适配器)数据采集适配器进行收集。对于Tracing维度的监测数据，采用pulsar-reporter-plugin(APM server的上报插件)数据采集适配器进行收集。对于Logging维度的监测数据，采用logstash-output-pulsar(Logstash的输出插件)数据采集适配器进行收集。对于CMDB中的配置数据，采用flink-cdc-connector(Flink CDC连接器)数据采集适配器进行收集。

服务器通过分别收集各个维度的监测数据，并在Pulsar分布式存储平台中，分别为各个维度建立相应的分布式存储主题(Pulsar topics)，用以分门别类地存储各个监测数据。例如指标主题(Metrics)用于存储指标数据；调用链主题(Tracing)用于存储冗余平整化后的调用链数据；日志主题(Logging)用于存储日志数据；CMDB主题用于存储经过反范式处理的CMDB的应用服务、设施实例等数据，即CMDB Result。在一个具体的示例中，针对于CMDB中数据，服务器通过利用Pulsar-Flink连接器的upsert(更新插入)机制，将增量数据转化为全量数据，以供后续进行关联分析。

由于运维业务监测数据的实时性，近期的监测数据可以存储在Pulsar分布式存储平台中，而对于超过一定时长的旧数据，则存在分布式文件系统中，可供后续业务离线分析或用于机器学习的训练等。在后续的数据分析阶段，可以利用Openlookeng分布式查询引擎提供的Query Service(查询服务)进行及自定义的查询，并且通过Dashboard(商业智能仪表盘)仪表盘服务，对三个维度的可观察性数据进行关联分析、查询和展示。

结合上述示例，本申请实施例中提供了一种可观察性框架，通过给监测数据添加数据标签，结合CMDB对应用服务与设施及其实例进行一步的关联，将不同维度的监测数据进行了关联与融合。同时，通过与各维度对应的数据采集适配器进行统一收集，并通过分布式存储平台进行统一存储，再通过分布式查询引擎进行关联分析，以及自定义的查询服务及仪表盘进行查询展示，方便运维人员在受到告警后，即可在统一的平台(例如Pulsar平台)快速定位根因，而无需运维人员手动逐一排查各个监控代理或监控系统。此外，通过结合CMDB的数据，根据预先建立的业务、应用服务及设施等配置项数据，能够实现运维的全链路跟踪，更加高效快捷。

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

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的监测数据的关联方法的监测数据的关联装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个监测数据的关联装置实施例中的具体限定可以参见上文中对于监测数据的关联方法的限定，在此不再赘述。

在一个实施例中，如图8所示，提供了一种监测数据的关联装置800，包括：收集模块801和关联模块802，其中：

收集模块801，用于分别收集来源于监测对象集群的多个维度的监测数据，每个维度的监测数据携带有对应于相应维度的至少一个数据标签；

关联模块802，用于基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系。

关联模块802，还用于基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系。

关联模块802，还用于根据第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，相互关联的各个维度的监测数据用于进行运维关联分析。

在一些实施例中，监测数据的关联装置还包括添加模块，用于确定待监控的至少一个监测对象；按照预先设置的对应于各个维度的数据模型，确定监测对象所采集的监测数据中内置的数据标签。

在一些实施例中，维度至少包括指标维度、日志维度、以及调用链维度中的一种；每个维度均对应于时间戳标签，且指标维度至少对应于与监测对象相对应的数据标签，日志维度至少对应于与应用服务相对应的数据标签，调用链维度至少对应于与链路相对应的数据标签。

在一些实施例中，关联模块还用于基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立携带有与应用服务相对应的数据标签的监测数据，与携带有与监测对象相对应的数据标签的监测数据之间的第二关联关系。

在一些实施例中，收集模块还用于针对不同的维度，分别利用适配于相应维度的数据采集适配器，收集监测对象集群中各监测对象采集的监测数据。

在一些实施例中，监测数据的关联装置还包括存储模块，用于根据各监测数据携带的数据标签中的时间戳标签，按照监测数据分别所属的维度，将处于预设时间范围内的监测数据分别存储至对应于各个维度的分布式存储主题中；将处于预设时间范围外的监测数据存储至分布式文件系统中。

在一些实施例中，监测数据的关联装置还包括查询模块，用于利用分布式查询引擎，对分布式存储主题中所存储的各个维度的监测数据进行关联查询，所关联查询到的监测数据用于运维分析。

上述监测数据的关联装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图9所示。该计算机设备包括处理器、存储器、输入/输出接口(Input/Output，简称I/O)和通信接口。其中，处理器、存储器和输入/输出接口通过系统总线连接，通信接口通过输入/输出接口连接到系统总线。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储监测数据。该计算机设备的输入/输出接口用于处理器与外部设备之间交换信息。该计算机设备的通信接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种监测数据的关联方法。

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

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：分别收集来源于监测对象集群的多个维度的监测数据，每个维度的监测数据携带有对应于相应维度的至少一个数据标签；基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系；基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系；根据第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，相互关联的各个维度的监测数据用于进行运维关联分析。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：确定待监控的至少一个监测对象；按照预先设置的对应于各个维度的数据模型，确定监测对象所采集的监测数据中内置的数据标签。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立携带有与应用服务相对应的数据标签的监测数据，与携带有与监测对象相对应的数据标签的监测数据之间的第二关联关系。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：针对不同的维度，分别利用适配于相应维度的数据采集适配器，收集监测对象集群中各监测对象采集的监测数据。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：根据各监测数据携带的数据标签中的时间戳标签，按照监测数据分别所属的维度，将处于预设时间范围内的监测数据分别存储至对应于各个维度的分布式存储主题中；将处于预设时间范围外的监测数据存储至分布式文件系统中。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：利用分布式查询引擎，对分布式存储主题中所存储的各个维度的监测数据进行关联查询，所关联查询到的监测数据用于运维分析。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：分别收集来源于监测对象集群的多个维度的监测数据，每个维度的监测数据携带有对应于相应维度的至少一个数据标签；基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系；基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系；根据第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，相互关联的各个维度的监测数据用于进行运维关联分析。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：确定待监控的至少一个监测对象；按照预先设置的对应于各个维度的数据模型，确定监测对象所采集的监测数据中内置的数据标签。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立携带有与应用服务相对应的数据标签的监测数据，与携带有与监测对象相对应的数据标签的监测数据之间的第二关联关系。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：针对不同的维度，分别利用适配于相应维度的数据采集适配器，收集监测对象集群中各监测对象采集的监测数据。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：根据各监测数据携带的数据标签中的时间戳标签，按照监测数据分别所属的维度，将处于预设时间范围内的监测数据分别存储至对应于各个维度的分布式存储主题中；将处于预设时间范围外的监测数据存储至分布式文件系统中。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：利用分布式查询引擎，对分布式存储主题中所存储的各个维度的监测数据进行关联查询，所关联查询到的监测数据用于运维分析。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：分别收集来源于监测对象集群的多个维度的监测数据，每个维度的监测数据携带有对应于相应维度的至少一个数据标签；基于各个维度的监测数据所携带的相匹配的数据标签，建立各个维度的监测数据之间的第一关联关系；基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立各个维度的监测数据之间的第二关联关系；根据第一关联关系和第二关联关系，确定各个维度的监测数据相互之间的目标关联关系，相互关联的各个维度的监测数据用于进行运维关联分析。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：确定待监控的至少一个监测对象；按照预先设置的对应于各个维度的数据模型，确定监测对象所采集的监测数据中内置的数据标签。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：基于预先建立的应用服务与监测对象集群中各监测对象之间的实体联系，建立携带有与应用服务相对应的数据标签的监测数据，与携带有与监测对象相对应的数据标签的监测数据之间的第二关联关系。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：针对不同的维度，分别利用适配于相应维度的数据采集适配器，收集监测对象集群中各监测对象采集的监测数据。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：根据各监测数据携带的数据标签中的时间戳标签，按照监测数据分别所属的维度，将处于预设时间范围内的监测数据分别存储至对应于各个维度的分布式存储主题中；将处于预设时间范围外的监测数据存储至分布式文件系统中。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：利用分布式查询引擎，对分布式存储主题中所存储的各个维度的监测数据进行关联查询，所关联查询到的监测数据用于运维分析。

需要说明的是，本申请所涉及的监测数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

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

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