CN113938374B - 一种监控仪表盘的处理方法及装置 - Google Patents

Abstract

本发明提供了一种监控仪表盘的处理方法及装置，该方法为：确定通过指定监控报警框架收集到指标数据的各个微服务的第一服务名；确定在指定可视化工具中已存在监控仪表盘的各个微服务的第二服务名；将第一服务名和第二服务名进行匹配，确定发生变动的微服务的服务名；根据发生变动的微服务的服务名，在指定可视化工具中对发生变动的微服务的监控仪表盘进行处理。当检测到微服务架构中新增和/或删除微服务时，及时对发生变动的微服务的监控仪表盘进行处理，不需要等待技术人员对发生变动的微服务的监控仪表盘进行处理，提高监控仪表盘的处理时效性。

Description

一种监控仪表盘的处理方法及装置

技术领域

本发明涉及数据处理技术领域，具体涉及一种监控仪表盘的处理方法及装置。

背景技术

随着互联网的发展，微服务架构也被越来越多的公司所使用。微服务架构中通常包含大量的微服务，当微服务发生故障时，为保证业务的稳定运行，需要快速对故障进行定位。

目前通常采用由技术人员手动创建的监控仪表盘（如基于Grafana创建的监控仪表盘）来监控微服务的各项指标，从而在发生故障时能对故障进行定位。但是，由于每个技术人员需要手动维护自身创建的监控仪表盘，当微服务架构中新增或删除微服务时，无法及时对监控仪表盘进行处理，导致监控仪表盘无法即时落地匹配，监控仪表盘的处理时效性较差。

发明内容

有鉴于此，本发明实施例提供一种监控仪表盘的处理方法及装置，以解决现有对监控仪表盘进行处理的方式存在的处理时效性较差等问题。

为实现上述目的，本发明实施例提供如下技术方案：

本发明实施例第一方面公开一种监控仪表盘的处理方法，所述方法包括：

确定通过指定监控报警框架收集到指标数据的各个微服务的第一服务名，所述指定监控报警框架基于指定服务发现框架发现微服务，各个所述微服务所配置的指标数据地址与所述指定监控报警框架所配置的指标收集地址一致；

确定在指定可视化工具中已存在监控仪表盘的各个微服务的第二服务名，每个所述监控仪表盘对应一个微服务；

将所述第一服务名和所述第二服务名进行匹配，确定发生变动的微服务的服务名，所述发生变动的微服务为：在所述指定服务发现框架新注册的微服务，和/或，在所述指定服务发现框架注销的微服务；

根据所述发生变动的微服务的服务名，在所述指定可视化工具中对所述发生变动的微服务的监控仪表盘进行处理。

优选的，将所述第一服务名和所述第二服务名进行匹配，确定发生变动的微服务的服务名，包括：

将所述第一服务名和所述第二服务名进行匹配，得到在所述指定服务发现框架新注册的微服务的第三服务名，和/或，得到在所述指定服务发现框架注销的微服务的第四服务名。

优选的，根据所述发生变动的微服务的服务名，在所述指定可视化工具中对所述发生变动的微服务的监控仪表盘进行处理，包括：

对于所述第三服务名对应的微服务，根据所述第三服务名和预设的监控仪表盘模板，在所述指定可视化工具中创建所述第三服务名对应的微服务的监控仪表盘，所述监控仪表盘模板预先上传至所述指定可视化工具中；

对于所述第四服务名对应的微服务，从所述指定可视化工具中删除所述第四服务名对应的微服务的监控仪表盘。

优选的，对于所述第三服务名对应的微服务，根据所述第三服务名和预设的监控仪表盘模板，在所述指定可视化工具中创建所述第三服务名对应的微服务的监控仪表盘，包括：

获取预设的监控仪表盘模板；

对于所述第三服务名对应的微服务，将所述监控仪表盘模板中的服务名替换为所述第三服务名，并利用完成替换的所述监控仪表盘模板，在所述指定可视化工具中创建所述第三服务名对应的微服务的监控仪表盘。

优选的，将所述第一服务名和所述第二服务名进行匹配，得到在所述指定服务发现框架新注册的微服务的第三服务名，和/或，得到在所述指定服务发现框架注销的微服务的第四服务名，包括：

将所述第一服务名和所述第二服务名进行匹配；

将匹配不到所述第二服务名的所述第一服务名，作为在所述指定服务发现框架新注册的微服务的第三服务名；

将匹配不到所述第一服务名的所述第二服务名，作为在所述指定服务发现框架注销的微服务的第四服务名。

优选的，确定通过指定监控报警框架收集到指标数据的各个微服务的第一服务名之前，还包括：

基于每个所述微服务的框架版本，配置每个所述微服务依赖于所述指定监控报警框架的指标收集库。

优选的，所述指定监控报警框架为Prometheus。

优选的，所述指定服务发现框架为Eureka。

优选的，所述指定可视化工具为Grafana。

本发明实施例第二方面公开一种监控仪表盘的处理装置，所述装置包括：

第一确定单元，用于确定通过指定监控报警框架收集到指标数据的各个微服务的第一服务名，所述指定监控报警框架基于指定服务发现框架发现微服务，各个所述微服务所配置的指标数据地址与所述指定监控报警框架所配置的指标收集地址一致；

第二确定单元，用于确定在指定可视化工具中已存在监控仪表盘的各个微服务的第二服务名，每个所述监控仪表盘对应一个微服务；

匹配单元，用于将所述第一服务名和所述第二服务名进行匹配，确定发生变动的微服务的服务名，所述发生变动的微服务为：在所述指定服务发现框架新注册的微服务，和/或，在所述指定服务发现框架注销的微服务；

处理单元，用于根据所述发生变动的微服务的服务名，在所述指定可视化工具中对所述发生变动的微服务的监控仪表盘进行处理。

基于上述本发明实施例提供的一种监控仪表盘的处理方法及装置，该方法为：确定通过指定监控报警框架收集到指标数据的各个微服务的第一服务名；确定在指定可视化工具中已存在监控仪表盘的各个微服务的第二服务名；将第一服务名和第二服务名进行匹配，确定发生变动的微服务的服务名；根据发生变动的微服务的服务名，在指定可视化工具中对发生变动的微服务的监控仪表盘进行处理。本方案中，确定能够收集到指标数据的各个微服务的第一服务名，以及确定已存在监控仪表盘的各个微服务的第二服务名。通过比对第一服务名和第二服务名，确定发生变动的微服务的服务名，在指定可视化工具中对发生变动的微服务的监控仪表盘进行处理。当检测到微服务架构中新增和/或删除微服务时，及时对发生变动的微服务的监控仪表盘进行处理，不需要等待技术人员对发生变动的微服务的监控仪表盘进行处理，提高监控仪表盘的处理时效性。

附图说明

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

图1为本发明实施例提供的一种监控仪表盘的处理方法的流程图；

图2为本发明实施例提供的上传监控仪表盘模板的示例图；

图3为本发明实施例提供的一种监控仪表盘的处理方法的另一流程图；

图4为本发明实施例提供的一种监控仪表盘的处理装置的结构框图。

具体实施方式

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

在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

由背景技术可知，为保证微服务架构所提供的业务的稳定运行，当微服务发生故障时，需要快速对故障进行定位。目前是采用由技术人员手动创建的监控仪表盘来监控微服务的各项指标，从而在发生故障时能对故障进行定位。但是由于每个技术人员需要手动维护自身创建的监控仪表盘，当微服务架构中新增或删除微服务时，无法及时对监控仪表盘进行处理，导致监控仪表盘无法即时落地匹配，监控仪表盘的处理时效性较差。

因此，本发明实施例提供一种监控仪表盘的处理方法及装置，确定能够收集到指标数据的各个微服务的第一服务名，以及确定已存在监控仪表盘的各个微服务的第二服务名。通过比对第一服务名和第二服务名，确定发生变动的微服务的服务名，在指定可视化工具中对发生变动的微服务的监控仪表盘进行处理。当检测到微服务架构中新增和/或删除微服务时，及时对发生变动的微服务的监控仪表盘进行处理，不需要等待技术人员对发生变动的微服务的监控仪表盘进行处理，以提高监控仪表盘的处理时效性。

需要说明的是，为更方便理解以下各个实施例的内容，先通过以下内容对本发明实施例所涉及到的英文名称进行解释说明。

Eureka：为java服务的服务发现框架，主要用于服务注册和发现服务。

Grafana：为开源的数据可视化工具，可以用于数据监控和数据统计。

Prometheus：为开源的监控报警框架，可以用于监控目标数据。

Springboot：主流java微服务框架。

Micrometer：开源的指标收集框架。

参见图1，示出了本发明实施例提供的一种监控仪表盘的处理方法的流程图，该处理方法包括：

步骤S101：确定通过指定监控报警框架收集到指标数据的各个微服务的第一服务名。

需要说明的是，指定监控报警框架基于指定服务发现框架发现微服务，各个微服务所配置的指标数据地址与指定监控报警框架所配置的指标收集地址一致。

在一些具体实施例中，指定监控报警框架可以是Prometheus，指定服务发现框架可以是Eureka。

可以理解的是，指定监控报警框架（Prometheus）通过指定服务发现框架（Eureka）来发现在指定服务发现框架上注册的微服务，进而收集所发现的各个微服务的指标数据（也就是监控数据）。指定监控报警框架在通过指定服务发现框架发现微服务之前，需要预先完成针对指定监控报警框架的配置，例如：预先调用Prometheus配置基于Eureka的服务发现。需要说明的是，Prometheus能够配置支持多种方式的服务发现，前述配置基于Eureka的服务发现仅仅是其中一个示例。

进一步需要说明的是，基于Eureka的服务发现具体是指：微服务上线或下线时会通知Eureka，Prometheus可以通过Eureka来确定哪些微服务上线以及确定哪些微服务下线。

针对指定监控报警框架的配置的过程中，至少配置了指定监控报警框架的指标收集地址，例如：Prometheus配置基于Eureka的服务发现时，所配置的指标收集地址为“metrics_path: /actuator/Prometheus”，“metrics_path”配置中的内容即为指标收集地址。指定监控报警框架在从指定服务发现框架中发现微服务时，请求所配置的指标收集地址来收集微服务的指标数据。由于不同的微服务可能将指标数据地址配置成不同内容，为保证指定监控报警框架能够拉取到各个微服务的指标数据，需要使各个微服务所配置的指标数据地址与指定监控报警框架所配置的指标收集地址一致，即使微服务所配置的指标数据地址与“metrics_path”配置中的内容一致。

由上述内容可知，指定监控报警框架可以收集已在指定服务发现框架上注册的各个微服务的指标数据，在具体实现步骤S101的过程中，确定由指定监控报警框架收集到指标数据的各个微服务的第一服务名，所确定得到的各个第一服务名即为：在指定服务发现框架上注册的各个微服务的服务名，或者说，指定服务发现框架中上线的各个微服务的服务名。

具体而言，可通过指定监控报警框架的API确定收集到指标数据的各个微服务的第一服务名，例如：利用Prometheus的API（如“/api/v1/query”），以PromQL查询语句确定收集到指标数据的各个微服务的第一服务名，PromQL查询语句可以是：PromQL：sum(up{job="eureka-server"})by(application)。

步骤S102：确定在指定可视化工具中已存在监控仪表盘的各个微服务的第二服务名。

需要说明的是，每个监控仪表盘对应一个微服务，即每个在指定服务发现框架中注册的微服务都需要生成一个相应的监控仪表盘；对于某个生成监控仪表盘的微服务，可通过该监控仪表盘监控该微服务的指标数据。

在一些具体实施例中，指定可视化工具可以是Grafana。

在具体实现步骤S102的过程中，通过指定可视化工具的API，查询得到在指定可视化工具中已存在监控仪表盘的各个微服务的第二服务名，即查询已经生成监控仪表盘的各个微服务的第二服务名。

例如：利用Grafana的API（如/api/search），查询已经生成监控仪表盘的各个微服务的第二服务名。

通过上述步骤S101和步骤S102的内容可知，每个在指定服务发现框架中注册的微服务，都需要在指定可视化工具中生成相应的监控仪表盘。但是在指定服务发现框架中注册且需要生成监控仪表盘的微服务，都需要遵循以下两条配置。

第一条配置：基于每个微服务的框架版本，配置每个微服务依赖于指定监控报警框架的指标收集库；即在指定服务发现框架上注册的微服务，需要依赖于指定监控报警框架的指标收集库以暴露数据端点。例如：假设指定监控报警框架为Prometheus，对于Springboot 1.x版本（微服务的框架版本）的微服务，需要依赖micrometer-spring-legacy类库提供指标数据收集功能，再依赖micrometer-registry-prometheus兼容类库将指标数据转为prometheus指标。又例如：假设指定监控报警框架为Prometheus，对于Springboot2.x版本的微服务，只需要依赖micrometer-registry-prometheus兼容类库即可。

第二条配置：保持prometheus指标的端点路径（也就是微服务配置的指标数据地址的地址路径）的统一。由于prometheus的数据端点会注册在springboot-actuator组件下的端点路径，需要保证该端点路径与指定监控报警框架所配置的指标收集地址一致。也就是保证端点路径（微服务配置的指标数据地址的地址路径）与metrics_path路径一致。

需要说明的是，对于上述步骤S101和步骤S102的内容，可通过搭建一个具有定时检测功能的定时服务，定时确定各个第一服务名和各个第二服务名。

进一步需要说明的是，上述步骤S101和步骤S102的执行顺序仅为一个示例，可同时执行步骤S101和步骤S102，也可先执行步骤S102再执行步骤S101，在此对于步骤S101和步骤S102的执行顺序不做限定。

步骤S103：将第一服务名和第二服务名进行匹配，确定发生变动的微服务的服务名。

需要说明的是，发生变动的微服务为：在指定服务发现框架新注册的微服务，和/或，在指定服务发现框架注销的微服务。

由上述内容可知，每个在指定服务发现框架中注册的微服务，都需要在指定可视化工具中生成相应的监控仪表盘。第一服务名为：在指定服务发现框架上注册且当前能够收集到指标数据的微服务的服务名；第二服务名为：在指定服务发现框架上注册且已生成监控仪表盘的微服务的服务名。

在具体实现步骤S103的过程中，将确定得到的各个第一服务名和各个第二服务名进行匹配，确定发生变动的微服务的服务名，即确定在指定服务发现框架新注册的微服务和/或在指定服务发现框架注销的微服务。

需要说明的是，在指定服务发现框架新注册的微服务具体是指：当前能收集到指标数据但未生成监控仪表盘的微服务；在指定服务发现框架注销的微服务具体是指：已生成监控仪表盘但当前未能收集到指标数据的微服务，或者说，已生成监控仪表盘但已在指定服务发现框架注销（或者下线）的微服务。第一服务名和第二服务名相匹配具体是指：第一服务名和第二服务名相同，例如：假设某一第一服务名为a，某一第二服务名也为a，则该第一服务名和该第二服务名相匹配。

在一些具体实施例中，将第一服务名和第二服务名进行匹配，得到在指定服务发现框架新注册的微服务的第三服务名，和/或，得到在指定服务发现框架注销的微服务的第四服务名。具体而言，将各个第一服务名和各个第二服务名进行匹配；将匹配不到第二服务名的第一服务名，作为在指定服务发现框架新注册的微服务的第三服务名；将匹配不到第一服务名的第二服务名，作为在指定服务发现框架注销的微服务的第四服务名。

也就是说，第三服务名（查询不到监控仪表盘的第一服务名）为：当前能收集到指标数据但未生成（或者说未查询到）监控仪表盘的微服务的服务名。第四服务名（未能收集到指标数据的第二服务名）为：已生成监控仪表盘但当前未能收集到指标数据的微服务的服务名，即未能收集到第四服务名对应的指标数据。

例如：假设所确定得到的第一服务名分别为A1、A2、A3和B，所确定得到的第二服务名分别为A1、A2、A3和C；将各个第一服务名和第二服务名进行匹配，确定在指定服务发现框架新注册的微服务的第三服务名为B，以及确定在指定服务发现框架注销的微服务的第四服务名为C。

步骤S104：根据发生变动的微服务的服务名，在指定可视化工具中对发生变动的微服务的监控仪表盘进行处理。

需要说明的是，预先根据微服务的通用技术栈在指定可视化工具中创建标准的监控仪表盘模板，该监控仪表盘模板至少包含：请求量、接口耗时、线程池和内存等内容。例如：根据微服务的通用技术栈在Grafana中创建标准的监控仪表盘模板。

进一步需要说明的是，诸如Grafana的指定可视化工具可提供监控仪表盘模板的上传功能，将监控仪表盘模板上传到指定可视化工具中会得到该监控仪表盘模板的模板ID，在创建监控仪表盘的时候，可通过模板ID选择相应的监控仪表盘模板来创建监控仪表盘。如图2示出的上传监控仪表盘模板的示例图，图2为Grafana提供的监控仪表盘模板上传界面，可通过该上传界面将监控仪表盘模板上传到Grafana的模板社区（需要预先注册Grafana的账号），图2仅用于举例说明。

在具体实现步骤S104的过程中，对于第三服务名对应的微服务（也就是在指定服务发现框架新注册的微服务），根据第三服务名和预设的监控仪表盘模板，在指定可视化工具中创建第三服务名对应的微服务的监控仪表盘，监控仪表盘模板预先上传至指定可视化工具中。具体而言，通过指定可视化工具的API，利用模板ID获取预设的监控仪表盘模板；对于第三服务名对应的微服务，将监控仪表盘模板中的服务名替换为该第三服务名，并利用完成替换的监控仪表盘模板，在指定可视化工具中创建第三服务名对应的微服务的监控仪表盘。

例如：调用Grafana的API（如/api/gnet/dashboards/ +模板 ID），基于模板ID获取得到监控仪表盘模板（json格式），再利用java提供的replace方法，将监控仪表盘模板中的服务名替换为第三服务名；调用Grafana的API（如/api/dashboards/import），使用完成替换的监控仪表盘模板（已将服务名替换为第三服务名）在Grafana中创建第三服务名对应的微服务的监控仪表盘。

对于第四服务名对应的微服务（也就是在指定服务发现框架注销的微服务），从指定可视化工具中删除第四服务名对应的微服务的监控仪表盘。

可利用具有定时检测功能的定时服务定时执行上述各个步骤，即定时检测在指定服务发现框架新注册的微服务和已注销的微服务，并创建新注册的微服务对应的监控仪表盘，以及删除已注销的微服务对应的监控仪表盘，当微服务架构中新增或删除微服务时，能够及时对监控仪表盘进行处理。

在本发明实施例中，确定能够收集到指标数据的各个微服务的第一服务名，以及确定已存在监控仪表盘的各个微服务的第二服务名。通过比对第一服务名和第二服务名，确定发生变动的微服务的服务名，在指定可视化工具中对发生变动的微服务的监控仪表盘进行处理。当检测到微服务架构中新增和/或删除微服务时，及时对发生变动的微服务的监控仪表盘进行处理，不需要等待技术人员对发生变动的微服务的监控仪表盘进行处理，提高监控仪表盘的处理时效性。

为更好解释说明上述本发明实施例图1中各个步骤的内容，通过图3示出的一种监控仪表盘的处理方法的另一流程图进行举例说明，需要说明的是，图3是以创建新注册的微服务的监控仪表盘为示例进行举例说明，其中，指定监控报警框架为Prometheus，指定服务发现框架为Eureka，指定可视化工具为Grafana，TaskService为定时服务，MicroService为微服务，图3包含以下步骤：

步骤S301：触发定时服务，从Prometheus获取收集到指标数据的各个微服务的第一服务名。

需要说明的是，Prometheus基于Eureka发现各个在Eureka上注册的微服务，Prometheus收集所发现的各个微服务的指标数据。

步骤S302：从Grafana获取已存在监控仪表盘的各个微服务的第二服务名。

步骤S303：从Grafana的模板社区中获取监控仪表盘模板。

步骤S304：确定在Eureka新注册的微服务，并在Grafana中创建新注册的微服务对应的监控仪表盘。

在具体实现步骤S304的过程中，比对步骤S301和步骤S302中获取的第一服务名和第二服务名，确定在Eureka新注册的微服务；并利用步骤S303中获取的监控仪表盘模板，在Grafana中创建新注册的微服务对应的监控仪表盘。用户可以在Grafana中查看各个微服务对应的监控仪表盘。

需要说明的是，步骤S301至步骤S304的执行原理，可参见上述本发明实施例图1中的内容，在此不再赘述。

与上述本发明实施例提供的一种监控仪表盘的处理方法相对应，参见图4，本发明实施例还提供了一种监控仪表盘的处理装置的结构框图，该处理装置包括：第一确定单元401、第二确定单元402、匹配单元403和处理单元404；

第一确定单元401，用于确定通过指定监控报警框架收集到指标数据的各个微服务的第一服务名，指定监控报警框架基于指定服务发现框架发现微服务，各个微服务所配置的指标数据地址与指定监控报警框架所配置的指标收集地址一致。

第二确定单元402，用于确定在指定可视化工具中已存在监控仪表盘的各个微服务的第二服务名，每个监控仪表盘对应一个微服务。

匹配单元403，用于将第一服务名和第二服务名进行匹配，确定发生变动的微服务的服务名，发生变动的微服务为：在指定服务发现框架新注册的微服务，和/或，在指定服务发现框架注销的微服务。

在具体实现中，匹配单元403具体用于：将所述第一服务名和所述第二服务名进行匹配，得到在所述指定服务发现框架新注册的微服务的第三服务名，和/或，得到在所述指定服务发现框架注销的微服务的第四服务名。

在具体实现中，匹配单元403具体用于：将第一服务名和第二服务名进行匹配；将匹配不到第二服务名的所述第一服务名，作为在指定服务发现框架新注册的微服务的第三服务名；将匹配不到第一服务名的第二服务名，作为在指定服务发现框架注销的微服务的第四服务名。

处理单元404，用于根据发生变动的微服务的服务名，在指定可视化工具中对发生变动的微服务的监控仪表盘进行处理。

在具体实现中，处理单元404具体用于：对于第三服务名对应的微服务，根据第三服务名和预设的监控仪表盘模板，在指定可视化工具中创建第三服务名对应的微服务的监控仪表盘，监控仪表盘模板预先上传至指定可视化工具中；对于第四服务名对应的微服务，从指定可视化工具中删除第四服务名对应的微服务的监控仪表盘。

在具体实现中，处理单元404具体用于：获取预设的监控仪表盘模板；对于第三服务名对应的微服务，将监控仪表盘模板中的服务名替换为第三服务名，并利用完成替换的监控仪表盘模板，在指定可视化工具中创建第三服务名对应的微服务的监控仪表盘。

在一些具体实施例中，指定监控报警框架为Prometheus，指定服务发现框架为Eureka，指定可视化工具为Grafana。

在本发明实施例中，确定能够收集到指标数据的各个微服务的第一服务名，以及确定已存在监控仪表盘的各个微服务的第二服务名。通过比对第一服务名和第二服务名，确定发生变动的微服务的服务名，在指定可视化工具中对发生变动的微服务的监控仪表盘进行处理。当检测到微服务架构中新增和/或删除微服务时，及时对发生变动的微服务的监控仪表盘进行处理，不需要等待技术人员对发生变动的微服务的监控仪表盘进行处理，提高监控仪表盘的处理时效性。

优选的，结合图4示出的内容，该处理装置还包括：

配置单元，用于基于每个微服务的框架版本，配置每个微服务依赖于指定监控报警框架的指标收集库。

综上所述，本发明实施例提供一种监控仪表盘的处理方法及装置，定时检测在指定服务发现框架新注册的微服务和注销的微服务，并创建新注册的微服务对应的监控仪表盘，以及删除注销的微服务对应的监控仪表盘，当微服务架构中新增或删除微服务时，能够及时对监控仪表盘进行处理，不需要等待技术人员对发生变动的微服务的监控仪表盘进行处理，提高监控仪表盘的处理时效性。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种监控仪表盘的处理方法，其特征在于，所述方法包括：

确定通过指定监控报警框架收集到指标数据的各个微服务的第一服务名，所述指定监控报警框架基于指定服务发现框架发现微服务，各个所述微服务所配置的指标数据地址与所述指定监控报警框架所配置的指标收集地址一致；

确定在指定可视化工具中已存在监控仪表盘的各个微服务的第二服务名，每个所述监控仪表盘对应一个微服务；

将所述第一服务名和所述第二服务名进行匹配，确定发生变动的微服务的服务名，所述发生变动的微服务为：在所述指定服务发现框架新注册的微服务，和/或，在所述指定服务发现框架注销的微服务；

根据所述发生变动的微服务的服务名，在所述指定可视化工具中对所述发生变动的微服务的监控仪表盘进行处理。

2.根据权利要求1所述的方法，其特征在于，将所述第一服务名和所述第二服务名进行匹配，确定发生变动的微服务的服务名，包括：

将所述第一服务名和所述第二服务名进行匹配，得到在所述指定服务发现框架新注册的微服务的第三服务名，和/或，得到在所述指定服务发现框架注销的微服务的第四服务名。

3.根据权利要求2所述的方法，其特征在于，根据所述发生变动的微服务的服务名，在所述指定可视化工具中对所述发生变动的微服务的监控仪表盘进行处理，包括：

对于所述第三服务名对应的微服务，根据所述第三服务名和预设的监控仪表盘模板，在所述指定可视化工具中创建所述第三服务名对应的微服务的监控仪表盘，所述监控仪表盘模板预先上传至所述指定可视化工具中；

对于所述第四服务名对应的微服务，从所述指定可视化工具中删除所述第四服务名对应的微服务的监控仪表盘。

4.根据权利要求3所述的方法，其特征在于，对于所述第三服务名对应的微服务，根据所述第三服务名和预设的监控仪表盘模板，在所述指定可视化工具中创建所述第三服务名对应的微服务的监控仪表盘，包括：

获取预设的监控仪表盘模板；

对于所述第三服务名对应的微服务，将所述监控仪表盘模板中的服务名替换为所述第三服务名，并利用完成替换的所述监控仪表盘模板，在所述指定可视化工具中创建所述第三服务名对应的微服务的监控仪表盘。

5.根据权利要求2所述的方法，其特征在于，将所述第一服务名和所述第二服务名进行匹配，得到在所述指定服务发现框架新注册的微服务的第三服务名，和/或，得到在所述指定服务发现框架注销的微服务的第四服务名，包括：

将所述第一服务名和所述第二服务名进行匹配；

将匹配不到所述第二服务名的所述第一服务名，作为在所述指定服务发现框架新注册的微服务的第三服务名；

将匹配不到所述第一服务名的所述第二服务名，作为在所述指定服务发现框架注销的微服务的第四服务名。

6.根据权利要求1所述的方法，其特征在于，确定通过指定监控报警框架收集到指标数据的各个微服务的第一服务名之前，还包括：

基于每个所述微服务的框架版本，配置每个所述微服务依赖于所述指定监控报警框架的指标收集库。

7.根据权利要求1-6中任一所述的方法，其特征在于，所述指定监控报警框架为Prometheus。

8.根据权利要求1-6中任一所述的方法，其特征在于，所述指定服务发现框架为Eureka。

9.根据权利要求1-6中任一所述的方法，其特征在于，所述指定可视化工具为Grafana。

10.一种监控仪表盘的处理装置，其特征在于，所述装置包括：

第一确定单元，用于确定通过指定监控报警框架收集到指标数据的各个微服务的第一服务名，所述指定监控报警框架基于指定服务发现框架发现微服务，各个所述微服务所配置的指标数据地址与所述指定监控报警框架所配置的指标收集地址一致；

第二确定单元，用于确定在指定可视化工具中已存在监控仪表盘的各个微服务的第二服务名，每个所述监控仪表盘对应一个微服务；

匹配单元，用于将所述第一服务名和所述第二服务名进行匹配，确定发生变动的微服务的服务名，所述发生变动的微服务为：在所述指定服务发现框架新注册的微服务，和/或，在所述指定服务发现框架注销的微服务；

处理单元，用于根据所述发生变动的微服务的服务名，在所述指定可视化工具中对所述发生变动的微服务的监控仪表盘进行处理。

Images