CN118550601A - 一种分布式监控系统注册方法、装置、设备及介质 - Google Patents

Abstract

本申请提供了一种分布式监控系统注册方法、装置、设备及介质，该方法包括：响应被监控服务的启动，对被监控服务相关联的数据标签进行整合处理，得到整合格式的目标标签；基于目标标签对被监控服务进行注册，以及在注册成功后，通过自动服务发现机制和预设的配置格式获取被监控服务的注册数据，以对被监控服务的监控数据进行采集；其中，配置格式与整合格式相匹配。本申请能够提高注册效率。

Description

一种分布式监控系统注册方法、装置、设备及介质

技术领域

本申请涉及分布式监控技术领域，尤其涉及一种分布式监控系统注册方法、装置、设备及介质。

背景技术

Consul是专门设计的来做服务发现工具，在微服务架构及Devops配置中心，分布式监控系统中有重要应用。Prometheus是分布式监控系统，支持Consul的服务发现机制，注册中心可以说是服务监控关系的“动态通讯录”，通过注册服务数据的上下线，触发Prometheus对服务的监控报警、展示及监控下线。服务数据注册需要包含对应服务的特征属性标签，属性标签主要来源为CMDB，应用系统，用户系统及自定义字段。同时服务数据标签调整也是非常重要和高频的操作，运维或研发人员需要频繁的更新注册的监控数据标签，分布式Prometheus监控系统也需要频繁适配注册元数据标签的变化。

但是，现有技术具有以下缺点：(1)监控注册数据服务种类繁多，关联CMDB、应用系统、用户系统及自定义标签，人工数据整合繁琐及效率较低。(2)已注册监控服务数据存在多种标签，存在高频增加/修改/删除指定某个或多个标签数据需求，目前服务注册方式只支持服务维度标签组的整体删除或增加，不支持针对某个或多个特定标签调整功能。(3)监控数据服务注册格式不一，Prometheus需要频繁调整配置，适配不同种类监控服务的注册数据变化。

发明内容

有鉴于此，本申请实施例提供了一种分布式监控系统注册方法、装置、设备及介质，能够提高注册效率。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供一种分布式监控系统注册方法，包括以下步骤：

响应被监控服务的启动，对所述被监控服务相关联的数据标签进行整合处理，得到整合格式的目标标签；

基于所述目标标签对所述被监控服务进行注册，以及在注册成功后，通过自动服务发现机制和预设的配置格式获取所述被监控服务的注册数据，以对所述被监控服务的监控数据进行采集；其中，所述配置格式与所述整合格式相匹配。

第二方面，本申请实施例还提供一种分布式监控系统注册装置，所述装置包括：

整合模块，用于响应被监控服务的启动，对所述被监控服务相关联的数据标签进行整合处理，得到整合格式的目标标签；

处理模块，用于基于所述目标标签对所述被监控服务进行注册，以及在注册成功后，通过自动服务发现机制和预设的配置格式获取所述被监控服务的注册数据，以对所述被监控服务的监控数据进行采集；其中，所述配置格式与所述整合格式相匹配。

第三方面，本申请实施例还提供一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行第一方面任一项所述的分布式监控系统注册方法。

第四方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行第一方面任一项所述的分布式监控系统注册方法。

本申请实施例具有以下有益效果：

(1)简化数据整合流程，提升效率：针对监控注册数据服务种类繁多的问题，本方案通过自动服务发现机制，实现了对CMDB、应用系统、用户系统以及自定义标签等多元化数据的自动整合。这大大减少了人工整合数据的繁琐步骤，提高了数据整合的效率和准确性。用户可以更加便捷地查看和管理各种监控服务的数据，无需手动进行繁琐的数据整合工作。

(2)支持灵活调整标签，满足个性化需求：针对已注册监控服务数据标签调整的需求，本方案提供了针对特定标签的灵活调整功能。玩家可以方便地增加、修改或删除指定的一个或多个标签数据，而无需进行整体标签组的操作。使得用户能够根据实际需要，灵活调整监控服务的标签设置，更好地满足个性化的监控需求。

(3)统一注册格式，降低配置调整频率：对于监控数据服务注册格式不一的问题，本方案通过整合处理被监控服务的相关数据标签，实现了注册格式的标准化和规范化。这降低了Prometheus等监控工具频繁调整配置的需求，减少了适配不同种类监控服务的注册数据变化的成本。用户可以更加顺畅地使用Prometheus等监控工具，无需频繁调整配置来适应不同的监控服务。这使得用户能够更加专注于监控数据的分析和处理。

综上所述，本方案通过简化数据整合流程、支持灵活调整标签以及统一注册格式等有益效果，为用户提供了更加便捷、高效和个性化的监控体验，使得用户能够更好地管理和利用监控数据。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1是本申请实施例提供的步骤S101-S102的流程示意图；

图2是本申请实施例提供的分布式监控系统注册方法的原理框图；

图3是本申请实施例提供的步骤S301-S305的流程示意图；

图4a是本申请实施例提供的代码图其一；

图4b是本申请实施例提供的代码图其二；

图5是本申请实施例提供的步骤S501-S502的流程示意图；

图6是本申请实施例提供的分布式监控系统注册装置的结构示意图；

图7是本申请实施例提供的电子设备的组成结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语是为了描述本申请实施例的目的，不是在限制本申请。

参见图1，图1是本申请实施例提供的分布式监控系统注册方法步骤S101-S102的流程示意图，将结合图1示出的步骤S101-S102进行说明。

步骤S101、响应被监控服务的启动，对所述被监控服务相关联的数据标签进行整合处理，得到整合格式的目标标签；

步骤S102、基于所述目标标签对所述被监控服务进行注册，以及在注册成功后，通过自动服务发现机制和预设的配置格式获取所述被监控服务的注册数据，以对所述被监控服务的监控数据进行采集；其中，所述配置格式与所述整合格式相匹配。

下面分别对本申请实施例的上述示例性的各步骤进行说明。

在步骤S101中，响应被监控服务的启动，对所述被监控服务相关联的数据标签进行整合处理，得到整合格式的目标标签。

在步骤S102中，基于所述目标标签对所述被监控服务进行注册，以及在注册成功后，通过自动服务发现机制和预设的配置格式获取所述被监控服务的注册数据，以对所述被监控服务的监控数据进行采集；其中，所述配置格式与所述整合格式相匹配。

请参见图2，图2是本申请实施例提供的分布式监控系统注册方法的原理框图，如图2所示，当一个新的被监控服务(例如exporterA服务)启动时，该方法开始执行。该方法从多个系统接口(如CMDB接口、用户系统接口、应用系统接口及自定义方式)获取与被监控服务相关联的数据标签，并进行整合处理。整合处理包括标准化格式、去除冗余数据、核对数据一致性等步骤，最终得到整合格式的目标标签。使用整合得到的目标标签，通过调用Consul等注册中心的注册接口，将被监控服务的数据注册到注册中心。注册中心负责存储和管理这些注册数据，以供其他系统(如监控系统)查询和使用。

一旦服务注册成功，监控系统(如Prometheus)通过自动服务发现机制(如定期轮询注册中心或监听注册中心的变更事件)从注册中心获取被监控服务的注册数据。同时，监控系统使用预设的配置格式来解析和处理这些注册数据。这个预设的配置格式与前面提到的整合格式相匹配，确保监控系统能够正确理解和处理注册数据。监控系统按照定义的间隔(如每15秒)自动采集被监控服务的监控数据。这些数据可以是性能指标、事件日志等，用于评估服务的运行状态和性能。对监控数据进行存储、报警和展示：监控系统可以将采集到的监控数据进行存储，以便后续分析和查询。同时，根据预设的报警规则，监控系统可以向Alert系统等推送报警信息，以及通过Grafana等系统对外展示监控详情。

在一些实施例中，参见图3，图3是本申请实施例提供的步骤S301-S305的流程示意图，所述对所述被监控服务相关联的数据标签进行整合处理，得到整合格式的目标标签，可以通过步骤S301-S305实现，将结合各步骤进行说明。

在步骤S301中，获取所述被监控服务的注册参数，所示注册参数包括服务类型、目标ip信息和自定义标签信息。

在步骤S302中，基于所述目标ip信息从CMDB系统中获取主机相关数据标签。

在步骤S303中，基于所述CMDB返回的服务树信息，从用户系统中获取用户相关数据标签。

在步骤S304中，基于所述服务类型和所述目标ip信息从应用系统获取应用相关数据标签。

在步骤S305中，基于自定义的所述整合格式对所述主机相关数据标签、用户相关数据标签、所述应用相关数据标签进行整合，得到目标Json数据，并将所述目标Json数据作为所述目标标签。

这里，请继续参见图2，注册参数包括服务类型、目标IP信息以及自定义标签信息。这些信息是识别和管理被监控服务的基础。使用目标IP信息作为查询条件，从CMDB系统中检索与该IP关联的主机信息。主机相关数据标签可能包括主机名、操作系统、硬件配置等。CMDB系统通常会返回服务树信息，该信息描述了服务之间的层次关系和依赖关系。根据服务树信息，可以从用户系统中获取与用户权限、角色等相关的数据标签。根据服务的类型(例如Web服务、数据库服务等)和目标IP信息，从应用系统中检索与应用相关的数据标签。应用相关数据标签可能包括应用的版本、部署状态、关联的业务等。根据预定义的整合格式(如JSON格式)，将获取到的主机相关数据标签、用户相关数据标签和应用相关数据标签进行组合和整理。整合过程中可能需要进行数据清洗、去重、转换等操作，以确保数据的一致性和准确性。经过整合处理后的数据以JSON格式呈现，作为目标标签。这个目标Json数据包含了被监控服务的所有相关信息，并且格式统一，便于后续的注册和监控操作。

通过上述步骤，对被监控服务相关联的数据标签进行了整合处理，得到了整合格式的目标标签。这个目标标签不仅包含了服务本身的信息，还融合了主机、用户和应用等多个维度的数据，为后续的注册和监控提供了全面而准确的数据支持。

在一些实施例中，所述整合格式包括：

id、name、address、port、tags、meta；其中，所述id表示所述被监控服务的唯一标识符；所述name表示所述被监控服务的名称；所述address表示所述被监控服务的地址；所述port表示所述被监控服务的监听端口号；所述tags表示一组描述所述被监控服务的标签或关键字，所述标签或关键字为至少一个；所述meta表示所述被监控服务的源数据或附加信息。

整合格式是一个用于标准化表示被监控服务信息的结构，它确保了数据的一致性和可读性，便于后续的注册和监控操作。该整合格式具体包括以下字段：

id：表示被监控服务的唯一标识符。这个字段用于在注册中心和其他系统中唯一地标识和识别每个被监控服务。通过id，可以确保每个服务在系统中的唯一性，便于管理和查询。

name：表示被监控服务的名称。这个字段提供了服务的简短描述或标识，方便用户理解和识别不同的服务。

address：表示被监控服务的地址。这通常是被监控服务的IP地址或主机名，用于标识服务在网络中的位置。通过address，监控系统可以确定如何连接到服务，并收集其监控数据。

port：表示被监控服务的监听端口号。这个字段指定了服务在哪些端口上监听请求或提供数据。通过port，监控系统可以知道如何与服务进行通信，并获取所需的监控信息。

tags：表示一组描述被监控服务的标签或关键字。这些标签或关键字用于进一步描述服务的属性、功能或分类。tags字段可以包含多个标签，每个标签都是一个描述性的字符串。通过tags，监控系统可以对服务进行更细粒度的分类和筛选，以满足不同的监控需求。

meta：表示被监控服务的源数据或附加信息。这个字段用于存储与服务相关的其他重要信息，这些信息可能不是直接用于监控的，但对于理解和管理服务很有帮助。meta字段可以包含各种类型的数据，如服务的版本信息、部署状态、关联的业务等。通过meta，监控系统可以提供更全面的服务信息，帮助用户更好地了解和管理服务。

通过定义这样的整合格式，可以确保被监控服务的信息在注册和监控过程中保持一致性和可读性。同时，该格式也具有一定的灵活性，可以根据实际需求进行扩展和定制。这有助于简化监控系统的开发和维护工作，提高监控的效率和准确性。

示例的，请参见图4a和图4b，图4a是本申请实施例提供的代码图其一，图4b是本申请实施例提供的代码图其二，如图4a所示，所整合的目标标签可以是图4a示出的格式，id、name、address、port、tags、meta为整合后的变量，每个变量包括一条或多条实际数据，这些实际数据是从CMDB系统、用户系统和应用系统中获取的，并被重新赋值给id、name、address、port、tags、meta这些变量。对应的，如图4b所示，在监控侧，无需再针对具体的数据进行监控，而是针对定义的这些“固定”的变量，例如host、address。由于在监控侧直接引用该变量，所以，即便在对这些变量的值进行了调整，监控侧也无需做出调整，即可获得调整后的值。

具体来说，在一些实施例中，参见图5，图5是本申请实施例提供的步骤S501-S502的流程示意图，所述方法还包括步骤S501-S502，将结合各步骤进行说明。

在步骤S501中，响应针对所述目标标签的调整操作，获取调整参数；其中，所述调整操作包括增加、删除、修改中的至少一种。

在步骤S502中，基于所述调整参数对所述被监控服务进行重新注册，以及在重新注册成功后且不修改所述配置格式的情况下，通过所述自动服务发现机制获取所述被监控服务的所述注册数据。

这里，当用户或系统需要对已注册的被监控服务的目标标签进行调整时，会触发调整操作。这些调整操作可以包括增加新的标签、删除现有的标签或对标签进行修改等。方法会接收并解析这些调整操作，获取相应的调整参数。这些参数将用于后续的重新注册过程。

使用获取到的调整参数，方法会更新目标标签，并基于更新后的目标标签对被监控服务进行重新注册。重新注册的过程与初始注册过程类似，会通过调用注册中心的注册接口来更新服务的注册信息。

一旦重新注册成功，监控系统会通过自动服务发现机制再次从注册中心获取被监控服务的注册数据。由于配置格式在重新注册过程中并未修改，因此监控系统仍然能够正确解析和处理这些注册数据。

上述的方式，用户可以灵活地调整被监控服务的标签信息，以适应不同的监控需求或场景变化。同时，由于自动服务发现机制和配置格式的一致性，这些调整不会影响监控系统的正常运行和数据采集。这一功能的实现，提高了监控系统的灵活性和可维护性，使得用户能够更加方便地管理和调整被监控服务的信息。

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

对所述监控数据进行存储，以及，按照预设的报警规则向Alter系统推送报警信息或通过Grafana系统展示监控详情。

这里，监控系统会定期或实时地将采集到的监控数据进行存储。这通常通过将数据写入数据库或存储系统来实现，以便后续的分析、查询和追溯。存储的监控数据可以包括各种性能指标、事件日志等，用于评估服务的运行状态、性能瓶颈以及潜在问题。

监控系统会根据预设的报警规则对监控数据进行分析和判断。这些报警规则可以基于阈值、趋势、事件等条件来定义。当监控数据满足报警规则时，监控系统会生成相应的报警信息，并通过API调用或其他方式将报警信息推送给Alert系统。Alert系统负责接收、处理和管理这些报警信息，可以通过邮件、短信、Slack等方式通知相关人员，以便及时响应和处理潜在问题。

除了报警功能外，监控系统还会将监控数据集成到Grafana等可视化工具中，以便直观地展示监控详情。通过Grafana系统，用户可以自定义仪表盘、图表和面板，展示关键指标、趋势分析、事件日志等信息。这有助于用户更好地了解服务的运行状态和性能，发现潜在问题，并制定相应的优化策略。

上述的方式，通过存储监控数据、推送报警信息和通过Grafana系统展示监控详情，该方法提供了一个全面的分布式监控系统，帮助用户及时发现问题、追踪原因并进行相应的处理，提高了系统的稳定性和可用性。

在一些实施例中，所述被监控服务的监控数据基于pull方式按预设的间隔自动采集。

这里，监控系统会按照预先设定的时间间隔，主动从被监控服务中拉取监控数据。具体来说，监控系统会配置一个定时器或调度器，用于定期触发数据采集任务。当采集任务被触发时，监控系统会发送请求到被监控服务的指定接口，获取该服务在上一时间段的监控数据。被监控服务在接收到请求后，会返回相应的监控数据给监控系统。

这种基于pull方式的自动采集机制具有一些优点。首先，它可以根据实际需求灵活设置采集间隔，以满足不同监控场景的需求。其次，由于监控系统主动发起请求，可以确保数据的实时性和准确性。此外，pull方式还可以减轻被监控服务的负担，因为它只在接收到请求时才需要返回数据。

需要说明的是，在采用pull方式进行监控数据采集时，应确保被监控服务提供了稳定的接口和可靠的数据返回机制，以确保数据采集的准确性和可靠性。同时，监控系统也需要具备处理异常情况的能力，比如被监控服务不可用或返回的数据格式不正确等情况。

综上所述，通过本申请实施例具有以下有益效果：

(1)简化数据整合流程，提升效率：针对监控注册数据服务种类繁多的问题，本方案通过自动服务发现机制，实现了对CMDB、应用系统、用户系统以及自定义标签等多元化数据的自动整合。这大大减少了人工整合数据的繁琐步骤，提高了数据整合的效率和准确性。用户可以更加便捷地查看和管理各种监控服务的数据，无需手动进行繁琐的数据整合工作。

(2)支持灵活调整标签，满足个性化需求：针对已注册监控服务数据标签调整的需求，本方案提供了针对特定标签的灵活调整功能。玩家可以方便地增加、修改或删除指定的一个或多个标签数据，而无需进行整体标签组的操作。使得用户能够根据实际需要，灵活调整监控服务的标签设置，更好地满足个性化的监控需求。

(3)统一注册格式，降低配置调整频率：对于监控数据服务注册格式不一的问题，本方案通过整合处理被监控服务的相关数据标签，实现了注册格式的标准化和规范化。这降低了Prometheus等监控工具频繁调整配置的需求，减少了适配不同种类监控服务的注册数据变化的成本。用户可以更加顺畅地使用Prometheus等监控工具，无需频繁调整配置来适应不同的监控服务。这使得用户能够更加专注于监控数据的分析和处理。

综上所述，本方案通过简化数据整合流程、支持灵活调整标签以及统一注册格式等有益效果，为用户提供了更加便捷、高效和个性化的监控体验，使得用户能够更好地管理和利用监控数据。

基于同一发明构思，本申请实施例中还提供了与第一实施例中分布式监控系统注册方法对应的分布式监控系统注册装置，由于本申请实施例中的装置解决问题的原理与上述分布式监控系统注册方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

如图6所示，图6是本申请实施例提供的分布式监控系统注册装置600的结构示意图。分布式监控系统注册装置600包括：

整合模块601，用于响应被监控服务的启动，对所述被监控服务相关联的数据标签进行整合处理，得到整合格式的目标标签；

处理模块602，用于基于所述目标标签对所述被监控服务进行注册，以及在注册成功后，通过自动服务发现机制和预设的配置格式获取所述被监控服务的注册数据，以对所述被监控服务的监控数据进行采集；其中，所述配置格式与所述整合格式相匹配。

本领域技术人员应当理解，图6所示的分布式监控系统注册装置600中的各单元的实现功能可参照前述分布式监控系统注册方法的相关描述而理解。图6所示的分布式监控系统注册装置600中的各单元的功能可通过运行于处理器上的程序而实现，也可通过具体的逻辑电路而实现。

在一种可能的实施方式中，整合模块601对所述被监控服务相关联的数据标签进行整合处理，得到整合格式的目标标签，包括：

获取所述被监控服务的注册参数，所示注册参数包括服务类型、目标ip信息和自定义标签信息；

基于所述目标ip信息从CMDB系统中获取主机相关数据标签；

基于所述CMDB返回的服务树信息，从用户系统中获取用户相关数据标签；

基于所述服务类型和所述目标ip信息从应用系统获取应用相关数据标签；

基于自定义的所述整合格式对所述主机相关数据标签、用户相关数据标签、所述应用相关数据标签进行整合，得到目标Json数据，并将所述目标Json数据作为所述目标标签。

在一种可能的实施方式中，所述整合格式包括：

id、name、address、port、tags、meta；其中，所述id表示所述被监控服务的唯一标识符；所述name表示所述被监控服务的名称；所述address表示所述被监控服务的地址；所述port表示所述被监控服务的监听端口号；所述tags表示一组描述所述被监控服务的标签或关键字，所述标签或关键字为至少一个；所述meta表示所述被监控服务的源数据或附加信息。

在一种可能的实施方式中，调整模块用于响应针对所述目标标签的调整操作，获取调整参数；其中，所述调整操作包括增加、删除、修改中的至少一种；

基于所述调整参数对所述被监控服务进行重新注册，以及在重新注册成功后且不修改所述配置格式的情况下，通过所述自动服务发现机制获取所述被监控服务的所述注册数据。

在一种可能的实施方式中，处理模块602还包括：

对所述监控数据进行存储，以及，按照预设的报警规则向Alter系统推送报警信息或通过Grafana系统展示监控详情。

在一种可能的实施方式中，所述被监控服务的监控数据基于pull方式按预设的间隔自动采集。

上述分布式监控系统注册装置具有以下有益效果：

(1)简化数据整合流程，提升效率：针对监控注册数据服务种类繁多的问题，本方案通过自动服务发现机制，实现了对CMDB、应用系统、用户系统以及自定义标签等多元化数据的自动整合。这大大减少了人工整合数据的繁琐步骤，提高了数据整合的效率和准确性。用户可以更加便捷地查看和管理各种监控服务的数据，无需手动进行繁琐的数据整合工作。

(2)支持灵活调整标签，满足个性化需求：针对已注册监控服务数据标签调整的需求，本方案提供了针对特定标签的灵活调整功能。玩家可以方便地增加、修改或删除指定的一个或多个标签数据，而无需进行整体标签组的操作。使得用户能够根据实际需要，灵活调整监控服务的标签设置，更好地满足个性化的监控需求。

(3)统一注册格式，降低配置调整频率：对于监控数据服务注册格式不一的问题，本方案通过整合处理被监控服务的相关数据标签，实现了注册格式的标准化和规范化。这降低了Prometheus等监控工具频繁调整配置的需求，减少了适配不同种类监控服务的注册数据变化的成本。用户可以更加顺畅地使用Prometheus等监控工具，无需频繁调整配置来适应不同的监控服务。这使得用户能够更加专注于监控数据的分析和处理。

综上所述，本方案通过简化数据整合流程、支持灵活调整标签以及统一注册格式等有益效果，为用户提供了更加便捷、高效和个性化的监控体验，使得用户能够更好地管理和利用监控数据。

如图7所示，图7为本申请实施例提供的电子设备700的组成结构示意图，所述电子设备700，包括：

处理器701、存储介质702和总线703，所述存储介质702存储有所述处理器701可执行的机器可读指令，当电子设备700运行时，所述处理器701与所述存储介质702之间通过总线703通信，所述处理器701执行所述机器可读指令，以执行本申请实施例所述的分布式监控系统注册方法的步骤。

实际应用时，所述电子设备700中的各个组件通过总线703耦合在一起。可理解，总线703用于实现这些组件之间的连接通信。总线703除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图7中将各种总线都标为总线703。

上述电子设备具有以下有益效果：

(1)简化数据整合流程，提升效率：针对监控注册数据服务种类繁多的问题，本方案通过自动服务发现机制，实现了对CMDB、应用系统、用户系统以及自定义标签等多元化数据的自动整合。这大大减少了人工整合数据的繁琐步骤，提高了数据整合的效率和准确性。用户可以更加便捷地查看和管理各种监控服务的数据，无需手动进行繁琐的数据整合工作。

(2)支持灵活调整标签，满足个性化需求：针对已注册监控服务数据标签调整的需求，本方案提供了针对特定标签的灵活调整功能。玩家可以方便地增加、修改或删除指定的一个或多个标签数据，而无需进行整体标签组的操作。使得用户能够根据实际需要，灵活调整监控服务的标签设置，更好地满足个性化的监控需求。

(3)统一注册格式，降低配置调整频率：对于监控数据服务注册格式不一的问题，本方案通过整合处理被监控服务的相关数据标签，实现了注册格式的标准化和规范化。这降低了Prometheus等监控工具频繁调整配置的需求，减少了适配不同种类监控服务的注册数据变化的成本。用户可以更加顺畅地使用Prometheus等监控工具，无需频繁调整配置来适应不同的监控服务。这使得用户能够更加专注于监控数据的分析和处理。

综上所述，本方案通过简化数据整合流程、支持灵活调整标签以及统一注册格式等有益效果，为用户提供了更加便捷、高效和个性化的监控体验，使得用户能够更好地管理和利用监控数据。

本申请实施例还提供了一种计算机可读存储介质，所述存储介质存储有可执行指令，当所述可执行指令被至少一个处理器701执行时，实现本申请实施例所述的分布式监控系统注册方法。

在一些实施例中，存储介质可以是磁性随机存取存储器(FRAM，FerromagneticRandom Access Memory)、只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read Only Memory)、可擦除可编程只读存储器(EPROM，ErasableProgrammable Read Only Memory)、电可擦除可编程只读存储器(EEPROM，ElectricallyErasable Programmable Read Only Memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD ROM，Compact Disc Read Only Memory)等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，HyperTextMarkupLanguage)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

上述计算机可读存储介质具有以下有益效果：

(1)简化数据整合流程，提升效率：针对监控注册数据服务种类繁多的问题，本方案通过自动服务发现机制，实现了对CMDB、应用系统、用户系统以及自定义标签等多元化数据的自动整合。这大大减少了人工整合数据的繁琐步骤，提高了数据整合的效率和准确性。用户可以更加便捷地查看和管理各种监控服务的数据，无需手动进行繁琐的数据整合工作。

(2)支持灵活调整标签，满足个性化需求：针对已注册监控服务数据标签调整的需求，本方案提供了针对特定标签的灵活调整功能。玩家可以方便地增加、修改或删除指定的一个或多个标签数据，而无需进行整体标签组的操作。使得用户能够根据实际需要，灵活调整监控服务的标签设置，更好地满足个性化的监控需求。

(3)统一注册格式，降低配置调整频率：对于监控数据服务注册格式不一的问题，本方案通过整合处理被监控服务的相关数据标签，实现了注册格式的标准化和规范化。这降低了Prometheus等监控工具频繁调整配置的需求，减少了适配不同种类监控服务的注册数据变化的成本。用户可以更加顺畅地使用Prometheus等监控工具，无需频繁调整配置来适应不同的监控服务。这使得用户能够更加专注于监控数据的分析和处理。

综上所述，本方案通过简化数据整合流程、支持灵活调整标签以及统一注册格式等有益效果，为用户提供了更加便捷、高效和个性化的监控体验，使得用户能够更好地管理和利用监控数据。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种分布式监控系统注册方法，其特征在于，所述方法包括：

响应被监控服务的启动，对所述被监控服务相关联的数据标签进行整合处理，得到整合格式的目标标签；

基于所述目标标签对所述被监控服务进行注册，以及在注册成功后，通过自动服务发现机制和预设的配置格式获取所述被监控服务的注册数据，以对所述被监控服务的监控数据进行采集；其中，所述配置格式与所述整合格式相匹配。

2.根据权利要求1所述的分布式监控系统注册方法，其特征在于，所述对所述被监控服务相关联的数据标签进行整合处理，得到整合格式的目标标签，包括：

获取所述被监控服务的注册参数，所示注册参数包括服务类型、目标ip信息和自定义标签信息；

基于所述目标ip信息从CMDB系统中获取主机相关数据标签；

基于所述CMDB返回的服务树信息，从用户系统中获取用户相关数据标签；

基于所述服务类型和所述目标ip信息从应用系统获取应用相关数据标签；

基于自定义的所述整合格式对所述主机相关数据标签、用户相关数据标签、所述应用相关数据标签进行整合，得到目标Json数据，并将所述目标Json数据作为所述目标标签。

3.根据权利要求1所述的分布式监控系统注册方法，其特征在于，所述整合格式包括：

id、name、address、port、tags、meta；其中，所述id表示所述被监控服务的唯一标识符；所述name表示所述被监控服务的名称；所述address表示所述被监控服务的地址；所述port表示所述被监控服务的监听端口号；所述tags表示一组描述所述被监控服务的标签或关键字，所述标签或关键字为至少一个；所述meta表示所述被监控服务的源数据或附加信息。

4.根据权利要求1所述的分布式监控系统注册方法，其特征在于，所述方法还包括：

响应针对所述目标标签的调整操作，获取调整参数；其中，所述调整操作包括增加、删除、修改中的至少一种；

基于所述调整参数对所述被监控服务进行重新注册，以及在重新注册成功后且不修改所述配置格式的情况下，通过所述自动服务发现机制获取所述被监控服务的所述注册数据。

5.根据权利要求1所述的分布式监控系统注册方法，其特征在于，所述方法还包括：

对所述监控数据进行存储，以及，按照预设的报警规则向Alter系统推送报警信息或通过Grafana系统展示监控详情。

6.根据权利要求1所述的分布式监控系统注册方法，其特征在于，所述被监控服务的监控数据基于pull方式按预设的间隔自动采集。

7.一种分布式监控系统注册装置，其特征在于，所述装置包括：

整合模块，用于响应被监控服务的启动，对所述被监控服务相关联的数据标签进行整合处理，得到整合格式的目标标签；

处理模块，用于基于所述目标标签对所述被监控服务进行注册，以及在注册成功后，通过自动服务发现机制和预设的配置格式获取所述被监控服务的注册数据，以对所述被监控服务的监控数据进行采集；其中，所述配置格式与所述整合格式相匹配。

8.根据权利要求7所述的分布式监控系统注册装置，其特征在于，所述装置还包括：

调整模块，用于响应针对所述目标标签的调整操作，获取调整参数；其中，所述调整操作包括增加、删除、修改中的至少一种；基于所述调整参数对所述被监控服务进行重新注册，以及在重新注册成功后且不修改所述配置格式的情况下，通过所述自动服务发现机制获取所述被监控服务的所述注册数据。

9.一种电子设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如权利要求1至6任一项所述的分布式监控系统注册方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1至6任一项所述的分布式监控系统注册方法。