CN113342618B - 分布式监控集群管理方法、设备及计算机可读存储介质 - Google Patents

Abstract

本发明涉及金融科技(Fintech)技术领域。本发明公开了一种分布式监控集群管理方法、设备及介质，该方法通过采用分布式的思想，对整个监控集群的状态和任务分配进行统一管理，将原本由单个监控实例完成的针对采集目标集合的采集任务，分配给包含多个监控实例的监控集群来完成，减轻了单个监控实例的压力；并通过周期性跟进监控集群所监控的采集目标集合的待采集目标情况，按照均衡分配的原则将各个采集目标定期重新分配给各个监控实例，使得采集目标集合中采集任务较重的采集目标能够及时打散分配到不同的监控实例中，保证了监控集群中各个监控实例的压力和数据量的均衡，从而避免因单个监控实例的采集压力和数据处理压力过大而出现性能瓶颈的情况。

Description

分布式监控集群管理方法、设备及计算机可读存储介质

技术领域

本发明涉及金融科技(Fintech)技术领域，尤其涉及分布式监控集群管理方法、设备及计算机存储介质。

背景技术

随着计算机技术的发展，越来越多的技术(大数据、分布式、区块链Blockchain、人工智能等)应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性、实时性要求，也对监控技术和容器技术提出了更高的要求。

作为一个开源的服务监控系统和时间序列数据库，prometheus通常用以解决监控容器的问题。但原始的prometheus只支持单机模式部署，当监控规模庞大时，单机的prometheus的存储空间、系统资源消耗等容易达到瓶颈。为解决这一问题，当前常见的解决方案为：使用prometheus的relabel(标签重写)机制以及保留策略，使得不同的prometheus实例存储不同的指标数据，达到分片存储监控指标数据的目的，进而降低单个prometheus实例的瓶颈。但上述解决方案在现今海量的监控采集规模下，依旧会达到prometheus的瓶颈，因此该解决方案在监控规模快速增长的情况下也并非长久之计。上述情况反映出现有的基于prometheus的指标数据分片存储方式依旧难以打破prometheus的性能瓶颈的问题。

发明内容

本发明的主要目的在于提出一种分布式监控集群管理方法、设备及计算机可读存储介质，旨在解决现有的基于prometheus的指标数据分片存储方式依旧难以打破prometheus的性能瓶颈的技术问题。

为实现上述目的，本发明提供一种分布式监控集群管理方法，所述分布式监控集群管理方法应用于分布式监控集群管理系统，所述分布式监控集群管理方法包括：

获取与监控集群所监控的采集目标集合相关的配置文件，基于所述配置文件周期性统计所述采集目标集合中的采集目标对应的当前待采数据量；

根据获取到的所述当前待采数据量，按照预设的均衡分配原则确定所述采集目标集合的目标分配方式，其中，所述均衡分配原则基于预设的单个监控实例的数据量承载上限以及数据均衡程度评估标准所设置；

按照所述目标分配方式，将各所述采集目标分配给所述监控集群中的各监控实例，以供各所述监控实例针对当前分配到的采集目标进行监控采集。

可选地，所述根据获取到的所述当前待采数据量，按照预设的均衡分配原则确定所述采集目标集合的目标分配方式的步骤包括：

按照预设分类方式对各所述采集目标进行分类，以得到分类结果；

根据所述分类结果和每一次获取到的每一所述当前待采数据量，按照所述均衡分配原则确定每一次的所述目标分配方式。

可选地，所述按照预设分类方式对各所述采集目标进行分类，以得到分类结果的步骤包括：

根据所述配置信息获取各所述采集目标的所属任务信息，其中，每一所述所属任务信息对应一个或多个所述采集目标；

将同一所述所属任务信息对应的多个所述采集目标归为同一类别；和/或，

获取同一所述所属任务信息对应的单个所述采集目标的访问频次，并根据预设频次等级映射表确定所述访问频次对应的等级信息，以将相同等级信息所对应的所述采集目标归为同一类别。

可选地，所述根据所述分类结果和每一次获取到的每一所述当前待采数据量，按照所述均衡分配原则确定每一次的所述目标分配方式的步骤包括：

根据所述分类结果和每一次获取到的每一所述当前待采数据量，采用预设均衡算法模拟计算出不同分配方式下每一所述监控实例所承载的待采数据量以及对应的数据均衡程度，其中，所述待采数据量为将同一类别或不同类别下的若干所述采集目标分配给同一所述监控实例时，同一所述监控实例所承载的数据量；

分析每一次的不同分配方式下的数据均衡程度以及所述待采数据量，从不同分配方式中确定出符合所述均衡分配标准的分配方式作为所述目标分配方式。

可选地，所述预设均衡算法基于一致性哈希和标准差所设计，

所述采用预设均衡算法模拟计算出不同分配方式下每一所述监控实例所承载的待采数据量以及对应的数据均衡程度的步骤包括：

在不同分配方式下，针对所述分类结果中的每一类别，采用一致性哈希算法为每一所述监控实例分配同一类别的若干所述采集目标，分配完成后得到每一所述监控实例所承载的待采数据量；

根据每一所述待采数据量得到每一类别的采集目标所对应的标准差，以表示所述数据均衡程度；

所述分析每一次的不同分配方式下的数据均衡程度以及所述待采数据量，从不同分配方式中确定出符合所述均衡分配标准的分配方式作为所述目标分配方式的步骤包括：

对于每一分配方式，判断每一所述监控实例所承载的待采数据量是否均未超过预设的数据承载上限，且每一类别的所述标准差是否满足预设数据均衡程度评估标准；

若每一所述监控实例所承载的待采数据量均未超过预设的数据承载上限，且每一类别的所述标准差满足预设数据均衡程度评估标准，则将当前分配方式作为所述目标分配方式。

可选地，所述系统中每一所述监控实例对应配置一代理模块，

所述获取与监控集群所监控的采集目标集合相关的配置文件，基于所述配置文件周期性统计所述采集目标集合中的采集目标对应的当前待采数据量的步骤包括：

在接收到分布式采集指令时，根据所述分布式采集指令获取所述配置文件，并对所述配置文件进行解析，以确定所述监控集群所监控的采集目标集合；

访问所述采集目标集合中的每一所述采集目标，以统计每一所述采集目标对应的全量采集数据量；

周期性向每一所述代理模块发送数据量查询请求，以接收由每一所述代理模块基于所述数据量查询请求返回的每一所述监控实例对应的已采集数据量；

对比每一所述全量采集数据量和所述已采集数据量，周期性统计出每一所述采集目标对应的当前未采数据量。

可选地，所述按照所述目标分配方式，将各所述采集目标分配给所述监控集群中的各监控实例的步骤包括：

按照每一次确定的所述目标分配方式，从所述配置文件中提取出各所述监控实例对应的采集目标信息；

将各所述采集目标信息发送给对应的各所述代理模块，以供各所述代理模块基于所述采集目标信息对应生成各实例配置文件，并将各所述实例配置文件对应注入各所述监控实例。

可选地，所述周期性向每一所述代理模块发送数据量查询请求的步骤之前，还包括：

检测所述采集目标集合中是否存在新增采集目标，其中，所述新增采集目标已自动添加至所述采集目标集合；

若是，则基于已添加所述新增采集目标的采集目标集合执行周期性向每一所述代理模块发送数据量查询请求的步骤。

此外，为实现上述目的，本发明还提供一种分布式监控集群管理系统，所述分布式监控集群管理系统包括：

此外，为实现上述目的，本发明还提供一种分布式监控集群管理设备，所述分布式监控集群管理设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的分布式监控集群管理程序，所述分布式监控集群管理程序被所述处理器执行时实现如上所述的分布式监控集群管理方法的步骤。

此外，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有分布式监控集群管理程序，所述分布式监控集群管理程序被处理器执行时实现如上所述的分布式监控集群管理方法的步骤。

此外，为实现上述目的，本发明还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上述的分布式监控集群管理方法的步骤。

本发明采用分布式的思想，对整个监控集群的状态和任务分配进行统一管理，将原本由单个监控实例完成的针对采集目标集合的采集任务，分配给包含多个监控实例的监控集群来完成，并通过周期性跟进监控集群所监控的采集目标集合的待采集目标情况，按照均衡分配的原则将各个采集目标定期重新分配给监控集群中的各个监控实例，使得采集目标集合中采集任务较重的采集目标能够及时打散分配到不同的监控实例中，保证了监控集群中各个监控实例的压力和数据量的均衡，避免因单个监控实例的采集压力和数据处理压力过大而出现性能瓶颈的情况，从而解决了现有的基于prometheus的指标数据分片存储方式依旧难以打破prometheus的性能瓶颈的技术问题。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的设备结构示意图；

图2为本发明分布式监控集群管理方法第一实施例的流程示意图；

图3为本发明分布式监控集群管理方法第三实施例中一具体实施例的系统组织架构示意图；

图4为本发明分布式监控集群管理方法第三实施例中另一具体实施例的时序流程图；

图5为本发明分布式监控集群管理系统的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，图1是本发明实施例方案涉及的硬件运行环境的设备结构示意图。

如图1所示，该分布式监控集群管理系统可以包括：处理器1001，例如CPU，用户接口1003，网络接口1004，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的设备结构并不构成对设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及分布式监控集群管理程序。

在图1所示的设备中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端(程序员端)，与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的分布式监控集群管理程序，并执行下述分布式监控集群管理方法中的操作。

基于上述硬件结构，提出本发明分布式监控集群管理方法实施例。

作为一个开源的服务监控系统和时间序列数据库，prometheus通常用以解决监控容器的问题。但原始的prometheus只支持单机模式部署，当监控规模庞大时，单机的prometheus的存储空间、系统资源消耗等容易达到瓶颈。为解决这一问题，当前常见的解决方案为：使用prometheus本身的标签重写机制和保留规则，不同的prometheus实例存储不同的指标数据。

举例：假设当前采集目标上报的指标有以下时序数据：

Name1{label＝“1”}

Name2{label＝“2”}

prometheus可以通过将标签label的值与prometheus实例的个数进行取模，这里假设实例数为2，再利用prometheus的标签重写机制，将取模的结果存放到新的标签‘mod’中，能够得到新的时序数据：

Name1{label＝“1”,mod＝“1”}

Name2{label＝“2”,mod＝“0”}

再利用prometheus的保留机制，prometheus的实例1只保留mod为0的指标，实例2只保留mod为1的指标，从而达到分片存储监控指标数据的目的，进而降低单个prometheus实例的瓶颈。

但上述解决方案在现今海量的监控采集规模下，依旧会达到prometheus的瓶颈，因此该解决方案在监控规模快速增长的情况下也并非长久之计。上述情况反映出现有的基于prometheus的指标数据分片存储方式依旧难以打破prometheus的性能瓶颈的问题。

为解决上述问题，本发明提供一种分布式监控集群管理方法，即采用分布式的思想，对整个监控集群的状态和任务分配进行统一管理，将原本由单个监控实例完成的针对采集目标集合的采集任务，分配给包含多个监控实例的监控集群来完成，并通过周期性跟进监控集群所监控的采集目标集合的待采集目标情况，按照均衡分配的原则将各个采集目标定期重新分配给监控集群中的各个监控实例，使得采集目标集合中采集任务较重的采集目标能够及时打散分配到不同的监控实例中，保证了监控集群中各个监控实例的压力和数据量的均衡，避免因单个监控实例的采集压力和数据处理压力过大而出现性能瓶颈的情况，从而解决了现有的基于prometheus的指标数据分片存储方式依旧难以打破prometheus的性能瓶颈的技术问题。

参照图2，图2为本发明分布式监控集群管理方法第一实施例的流程示意图。所述分布式监控集群管理方法应用于分布式监控集群管理系统，所述分布式监控集群管理方法包括；

步骤S10，获取与监控集群所监控的采集目标集合相关的配置文件，基于所述配置文件周期性统计所述采集目标集合中的采集目标对应的当前待采数据量；

在本实施例中，本方法基于Prometheus实现。监控集群，指的是系统中所管理的所有监控实例(即prometheus实例)的集合，系统通过管理若干个监控实例来对采集目标进行监控以及指标数据采集，一个监控实例可以对应一个或多个采集目标。采集目标集合指的是采集目标的集合，通常集合中采集目标的个数为多个。采集目标指的是支持prometheus指标格式的应用程序，prometheus实例能够对其进行指标采集，每个采集目标返回的数据格式即为series的格式，一个采集目标中一般存在许多series，其中，series意为时序，指的是prometheus时序数据库存储的数据单元，时序由名称name及对应的标签label来唯一确定。配置文件为用于指明当前的若干采集任务，以及每一采集任务对应的一个或多个采集目标的相关信息的文件。统计周期可根据实际需求灵活设定，本实施例不做具体限制。当前待采数据量指的是采集目标集合中的每一采集目标在当前采集任务中对应的全部需要采集的数据量，与监控集群当前已经对其进行采集的数据量之前的差值。可以理解的是，在系统在一次采集任务中首次获取到当前待采数据量时，此时的当前待采数据量等同于每一采集目标在当前采集任务中对应的全部需要采集的数据量。

具体地，系统在开始执行当前的采集任务后，获取当前采集任务的配置文件，然后对该配置文件进行解析，以明确当前采集任务中所涉及的所有的采集目标，将其归为上述采集目标集合。需要说明的是，该配置文件中涵盖了采集目标集合中所有采集目标的相关信息，而不同于现有的一个prometheus实例维护对应的一个配置文件的做法，本实施例中的配置文件涵盖了所有采集目标的相关信息，也即是将监控集群中每一监控实例所需要监控采集的采集目标的相关信息汇总到一个配置文件中，从而达到高效统一管理的效果。

步骤S20，根据获取到的所述当前待采数据量，按照预设的均衡分配原则确定所述采集目标集合的目标分配方式，其中，所述均衡分配原则基于预设的单个监控实例的数据量承载上限以及数据均衡程度评估标准所设置；

在本实施例中，均衡分配原则基于预设的单个监控实例的数据承载上限，和预设的数据均衡程度评估标准所设置，用于在将采集目标分配到各个监控实例时，得到数据量和采集压力的均衡分配的效果，且分配完成后每一监控实例所对应的采集任务数据量不会超出数据承载上限，以避免出现性能瓶颈。目标分配方式指的是符合上述均衡分配原则的分配方式，也即是在目标分配方式下，能同时满足单个监控实例的实际承载数据量不超出上限，且实际数据均衡程度满足数据均衡程度评估标准。数据均衡程度可通过一个或多个指标来衡量，例如平均值、方差、标准差等。

具体地，系统根据上一步骤获取到的每一采集目标的当前待采数据量，按照均衡分配原则多次模拟设计不同的分配方式，以判断何种分配方式能满足均衡分配原则。对于目标分配方式的确定方式，既可以是系统通过设计一定数量的分配方式，并在这些分配方式中存在多个都可以满足均衡分配原则时，选择其中的数据均衡程度最高的方式作为目标分配方式；或是每设计一种分配方式即判断其是否能够符合均衡分配原则，直至设计出能够满足该均衡分配原则的分配方式，将其直接作为目标分配方式。

步骤S30，按照所述目标分配方式，将各所述采集目标分配给所述监控集群中的各监控实例，以供各所述监控实例针对当前分配到的采集目标进行监控采集。

在本实施例中，系统按照上一步骤所确定的目标分配方式，将采集目标集合中的各个采集目标分配给相应的监控实例，一个监控实例中可能对应分配一个或多个采集目标。由于本实施例中系统获取到的配置文件为一个总的配置文件，因此对于各个监控实例而言，在每次自身对应的采集目标发生变更时，系统需要根据总的配置文件为每一个监控实例生成一个新的子配置文件，然后将子配置文件注入对应的监控实例中，以使目标分配方式在每个监控实例中生效。每个子配置文件中仅涵盖该监控实例在当前分配方式中对应的采集目标的相关信息，而不会涉及其他监控实例所对应的采集目标。且对于总的配置文件而言，只要在更新分配方式的过程中，采集目标集合中没有出现采集目标的新增或是删减，分配方式的改变并不会影响配置文件的内容。

本实施例提供一种分布式监控集群管理方法。所述分布式监控集群管理方法通过获取与监控集群所监控的采集目标集合相关的配置文件，基于所述配置文件周期性统计所述采集目标集合中的采集目标对应的当前待采数据量；根据获取到的所述当前待采数据量，按照预设的均衡分配原则确定所述采集目标集合的目标分配方式，其中，所述均衡分配原则基于预设的单个监控实例的数据量承载上限以及数据均衡程度评估标准所设置；按照所述目标分配方式，将各所述采集目标分配给所述监控集群中的各监控实例，以供各所述监控实例针对当前分配到的采集目标进行监控采集。本实施例采用分布式的思想，对整个监控集群的状态和任务分配进行统一管理，将原本由单个监控实例完成的针对采集目标集合的采集任务，分配给包含多个监控实例的监控集群来完成，并通过周期性跟进监控集群所监控的采集目标集合的待采集目标情况，按照均衡分配的原则将各个采集目标定期重新分配给监控集群中的各个监控实例，使得采集目标集合中采集任务较重的采集目标能够及时打散分配到不同的监控实例中，保证了监控集群中各个监控实例的压力和数据量的均衡，避免因单个监控实例的采集压力和数据处理压力过大而出现性能瓶颈的情况，从而解决了现有的基于prometheus的指标数据分片存储方式依旧难以打破prometheus的性能瓶颈的技术问题。

另外，现有技术中还存在配置管理复杂(现有技术中prometheus的实例个数需要提前规划，每个prometheus都需要单独定制配置文件)以及重复带宽消耗(多个prometheus实例虽然能够利用保留策略减小本身存储的数据量，但在拉取指标数据时，多个prometheus实例对相同的采集目标依旧是全量拉取，这就可能导致在一个采集周期内，会有多个prometheus拉取采集目标的全量数据，再选择性保留数据，这个过程中会产生重复的带宽消耗)的问题。对于配置管理复杂这一问题，本实施例通过系统对各个prometheus实例统一管理配置，从而简化了prometheus的配置管理；对于重复带宽消耗的问题，本实施例通过让多个prometheus实例采集不同的目标，每个采集目标只会被一个prometheus实例采集，减少了以往集群部署方式的重复带宽。

进一步地，基于上述图2所示的第一实施例，提出本发明分布式监控集群管理方法的第二实施例。在本实施例中，步骤S20包括：

步骤S21，按照预设分类方式对各所述采集目标进行分类，以得到分类结果；

步骤S22，根据所述分类结果和每一次获取到的每一所述当前待采数据量，按照所述均衡分配原则确定每一次的所述目标分配方式。

在本实施例中，分类方式可基于每一采集目标的访问频次来设计，通过分类使得相同量级访问频次对应的若干采集目标能够归为一类，以便后续分配，也可以基于用户预设标识来设计，用户可自定义采集目标的类别，在采集目标的相关信息中添加自定义标识，以便系统识别到标识后将相同标识或同类型标识的采集目标自动归类。

具体地，系统中可基于Kubernetes(一款开源的容器编排系统)设置监控调度器Monitor Controller(以下简称调度器)调度器负责分析配置文件、探测采集目标的数据量大小，以及对采集目标进行分类。系统中的调度器按照预设的分类方式将采集目标集合中的各个采集目标进行分类，得到分类结果(例如一共分为几类，每一类别中包含哪些采集目标)。然后再结合周期性更新的每一监控实例对应的当前待采数据量来确定符合均衡分配原则的目标分配方式。

需要说明的是，若是在周期性确定目标分配方式的过程中没有采集目标的新增或删减，则首次分类结果可沿用至后续的更新过程，只需每次更新时获取当前时刻最新的当前待采数据量即可；若过程中存在采集目标的新增或删减，则需要将新增的采集目标根据进行分类，或是将删减的采集目标从对应分类中剔除即可，而对于其他没有更改的采集目标，则无需改变其分类结果。

本实施例通过实现了一个controller模块，负责对采集任务进行分析，按照一定的规则将采集的任务进行分类，并将分类后采集任务分配给多个prometheus，实现采集任务的合理分发和分布式采集。

进一步地，步骤S21包括：

步骤S211，根据所述配置信息获取各所述采集目标的所属任务信息，其中，每一所述所属任务信息对应一个或多个所述采集目标；

步骤S212，将同一所述所属任务信息对应的多个所述采集目标归为同一类别；和/或，

步骤S213，获取同一所述所属任务信息对应的单个所述采集目标的访问频次，并根据预设频次等级映射表确定所述访问频次对应的等级信息，以将相同等级信息所对应的所述采集目标归为同一类别。

在本实施例中，由于在总的配置文件对应的整体采集任务中可能会细化到多个不同的采集任务job，因此对于采集目标的分类方式具体可为(对应步骤S211-S212)：若同一个job中存在多个采集目标，则属于同一个job的采集任务归属为一类，例如cadvisor/node-exporter等采集任务，这些采集任务虽然在配置文件中只有一个job，但通过Kubernetes服务发现，可能会存在许多的采集目标，这类目标所暴露的时序一般为同一种类型，在查询时频度基本是相同的，因此类似于cadvisor、node-exporter的采集任务可归为一类。

分类方式还可为：根据人为预设标识来分类。用户可预先在配置文件所记录的采集目标所属的job名称中添加标识以作为前缀，调度器识别到此标识后，则可确定该采集目标为人为分类的采集目标。

分类方式还可为(对应步骤S213)：若存在采集目标未经人为指定的预设标识分类，其所属的job中也未对应其他的采集目标的，则归为其他类别。当其他类别中的采集目标数量达到预设个数阈值时，获取其他类别当中每一采集目标对应的访问频度，将访问频度按照数值大小划分为多个等级，以将其他类别中的众多采集目标根据访问频度再进行分类，每一等级对应一独立的类别。

作为一具体实施方式，Agent端的操作流程如下：

第一步，缓存中保存一个以采集目标信息为key，请求次数为value的键值对；

第二步，接受到来自用户的查询请求；

第三步，解析请求，找到查询的指标所涉及的采集目标，并在键值对中更新对应采集目标的次数；；

第四步，响应用户请求：调用prometheus的查询接口，执行查询请求并将结果返回给用户；

第五步，定期向controller端上报每个采集目标的访问次数信息，上报完成后清零。

对于所有prometheus实例采集的目标，根据业务场景的不同，可能存在热点数据的情况，用户可能对部分指标的查询会更加频繁，若分布式采集的情况下，没有将这些热点数据打散，可能会导致部分prometheus实例的查询性能出现瓶颈。本实施例通过对每次的查询请求访问的采集目标进行了统计，并针对访问频度，对采集目标在多个prometheus中进行自动的均衡分布，实现计算压力的均衡。

进一步地，步骤S22包括：

步骤S221，根据所述分类结果和每一次获取到的每一所述当前待采数据量，采用预设均衡算法模拟计算出不同分配方式下每一所述监控实例所承载的待采数据量以及对应的数据均衡程度，其中，所述待采数据量为将同一类别或不同类别下的若干所述采集目标分配给同一所述监控实例时，同一所述监控实例所承载的数据量；

步骤S222，分析每一次的不同分配方式下的数据均衡程度以及所述待采数据量，从不同分配方式中确定出符合所述均衡分配标准的分配方式作为所述目标分配方式。

在本实施例中，系统中的调度器在每一次进行目标分配方式确定时，根据已得到的采集目标的分类结果以及每一采集目标的当前待采数据量来进行模拟分配，例如当前将采集目标集合中的所有采集目标分为三大类，而当前监控集群中有5个监控实例，则调度器在初次分配时会为每一类别创建一个默认的一致性哈希环，然后在对每一类采集目标进行分配时，对该类中的采集目标计算一个哈希值，根据计算出的哈希值在哈希环中按照一致性哈希算法找到对应的节点(一个节点相当于一个监控实例)，最后将与该哈希值对应的采集目标分配给对应的监控实例，如此为这5个监控实例逐类分配这三类采集目标。在此次模拟分配完成后，调度器根据每一采集目标的当前待采数据量计算按照此分配方式下每一监控实例所承载的待采数据量，以及该分配方式下各个监控实例之间的数据均衡程度，确定出每一监控实例所承载的待采数据量均不超出其上限值，且数据均衡程度符合预设均衡程度评估标准的分配方式以作为目标分配方式。

本实施例通过模拟计算的方式预先确定出符合数据上限以及均衡程度标准的的目标分配方式，然后再将此目标分配方式实际部署在监控集群中，从而避免了因采集目标多次迁移变动而导致的不必要的资源浪费以及用户请求查询失败的情况。

进一步地，所述预设均衡算法基于一致性哈希和标准差所设计，步骤S221包括：

步骤S2211，在不同分配方式下，针对所述分类结果中的每一类别，采用一致性哈希算法为每一所述监控实例分配同一类别的若干所述采集目标，分配完成后得到每一所述监控实例所承载的待采数据量；

步骤S2212，根据每一所述待采数据量得到每一类别的采集目标所对应的标准差，以表示所述数据均衡程度。

步骤S222包括：

步骤S2221，对于每一分配方式，判断每一所述监控实例所承载的待采数据量是否均未超过预设的数据承载上限，且每一类别的所述标准差是否满足预设数据均衡程度评估标准；

步骤S2222，若每一所述监控实例所承载的待采数据量均未超过预设的数据承载上限，且每一类别的所述标准差满足预设数据均衡程度评估标准，则将当前分配方式作为所述目标分配方式。

在本实施例中，均衡原则中除了上述的数据承载上限以及均衡程度之外，还可包括减少采集目标迁移次数的内容，因为将采集目标转移到其他prometheus实际进行采集时，当统计查询一定时间周期内的值时(如最近60s的平均值)，由于采集目标刚刚被划分到新的prometheus实例，可能无法查询成功，因此要尽量减少均衡过程中采集目标的移动次数。

具体地，对于上述均衡原则，可一致性哈希与标准差结合，并采用模拟计算的方式一次性计算到位，以减少采集目标在不同prometheus实例之间的反复移动。调度器逐类为每个prometheus实例进行采集目标分类，在分配某一类的target时，采用一致性哈希算法，保证每个prometheus实例所对应的采集目标的数据量大致相同，并减小prometheus实例扩容时target重分布的影响，且同一类别下的采集目标都维护一个一致性哈希环。在一致性哈希中，每个prometheus实例都设有对应权重，用于在分布不均衡的情况下对target进行重均衡。

作为一具体实施方式，通过调整每个prometheus实例的权重，来达到均衡的目的。每次调整，将承载数据量最多的prometheus实例的权重降低，将承载数据量最少的prometheus实例的权重调高。另外，调整时采用多次模拟计算的方式，达到均衡的标准后再进行实际的注入，减少采集目标的变动次数，一步到位。具体实施步骤如下：

第一步，设每个prometheus的初始权重为100；

第二步，每次调整时，每个prometheus实例需要对分配到的采集目标进行采集的时序数据量为S，最大的为Smax，最小的为Smin，平均的时序数据量为Savg；

第三步，计算权重的调整值：M＝(Smax-Smin)/Savg/2*100；

第四步，将采集时序数据量最多的prometheus实例的权重调整为Pmax-M，并采集压力最小的prometheus实例的权重调整为Pmin+M；

第五步，若标准差达没有达到标准且执行次数不超过20次，则重复第三步和第四步这两个步骤；否则执行第六步；

第六步，根据当前调整结果确定目标分配方式。

且在本实施例中，用于衡量均衡程度的指标为标准差，则预设数据均衡程度评估标准具体可为：调度器采用标准差来衡量每一类采集目标的数据均衡程度，假设某一类采集目标的时序数据量为Total，理想情况下n个prometheus实例采集的时序数据量为Avg＝Total/n，根据每个prometheus实例实际采集的时序数据量算出标准差S；

当S<＝1/3*Avg时，调度器则判定此时达到数据均衡要求；

当S>Avg时则，调度器则判定此时还未达到数据均衡要求，需要考虑进行采集目标的分布调整，调整方式可参照上述具体实施方式中基于权重的调整方式。

本实施例通过基于一致性哈希和标准差来设计均衡算法，并采用模拟计算的方式一次性计算到位，既减少了采集目标的反复移动，同时也能保证优良的均衡分配效果。

进一步地，基于上述图2所示的第一实施例，提出本发明分布式监控集群管理方法的第三实施例。在本实施例中，所述系统中每一所述监控实例对应配置一代理模块，步骤S10包括：

步骤S11，在接收到分布式采集指令时，根据所述分布式采集指令获取所述配置文件，并对所述配置文件进行解析，以确定所述监控集群所监控的采集目标集合；

步骤S12，访问所述采集目标集合中的每一所述采集目标，以统计每一所述采集目标对应的全量采集数据量；

步骤S13，周期性向每一所述代理模块发送数据量查询请求，以接收由每一所述代理模块基于所述数据量查询请求返回的每一所述监控实例对应的已采集数据量；

步骤S14，对比每一所述全量采集数据量和所述已采集数据量，周期性统计出每一所述采集目标对应的当前未采数据量。

在本实施例中，系统包括监控调度器Monitor Controller和监控代理Monitoragent。对于分布式采集流程，在Monitor Controller端的执行步骤如下：

第一步，读取配置文件(可根据分布式采集指令读取)并解析配置文件内容；

第二步，服务发现：根据配置文件的内容，发现全部采集目标；

第三步，访问每个采集目标，将每个采集目标返回的全量时序数据量进行统计计算；

第四步，请求agent端，得到每一prometheus实例当前已经正在采集的时序数据量(即上述已采集数据量)；

第五步，对比所有采集目标的全量时序数据量以及当前已经采集的时序数据量，得到每个采集目标的未采集数据量，并将采集目标分配给prometheus实例；

第六步，将采集目标分发给已经注册到controller的Monitor Agent；

第七步，如果agent和prometheus数量不足以承载所有的分类，则创建新的prometheus及agent，等新的agent注册到controller后再将采集目标进行发送。

在配置文件没有变更的情况下，周期性执行第二至七步。

作为一具体实施例，基于Prometheus和Kubernetes的系统的组织架构如图3所示。整个系统主要包含3个组件：监控集群Prometheus、监控调度器Monitor Controller和监控代理Monitor Agent。对于Monitor Controller，其用于负责分析配置文件、探测采集目标的数据量大小，以及对采集目标进行分类；而对于Monitor agent，监控集群中的每个prometheus实例中都携带一个agent模块，负责接收来自controller采集目标信息，由此生成prometheus配置文件，并通知prometheus重加载配置，以及拦截来自用户对于采集目标的指标查询请求，定期将向Monitor Controller端反馈目标访问进度，在Kubernetes环境中，agent以sidecar的方式运行与prometheus实例运行在同一个容器集pod中；Prometheus用于负责实际指标的采集和数据的存储，并对位提供查询功能。

由于本实施例中的系统基于Kubernetes资源池所构建，因此还可利用Kubernetes容器编排技术，实现prometheus实例的自动扩容，从而解决了现有技术中因在扩容时需要对prometheus集群进行重新规划，并对每个prometheus实例重新进行配置的这一扩容困难的问题。

进一步地，步骤S30包括：

步骤S31，按照每一次确定的所述目标分配方式，从所述配置文件中提取出各所述监控实例对应的采集目标信息；

步骤S32，将各所述采集目标信息发送给对应的各所述代理模块，以供各所述代理模块基于所述采集目标信息对应生成各实例配置文件，并将各所述实例配置文件对应注入各所述监控实例。

在本实施例中，系统通过Monitor Agent端生成各实例配置文件，并使其生效，Monitor Agent端的流程步骤如下：

第一步，agent启动后，首先向controller发送自己的心跳报文，以通知controller已启动完成；

第二步，接收到来自controller分配的采集目标；

第三步，根据采集目标，生成prometheus配置文件；

第四步，将prometheus配置文件注入对应prometheus实例，并利用prometheus的config reload机制，热加载配置文件，使配置文件生效。

作为一具体实施例，Monitor Controller端和Monitor Agent端的时序图如图4所示。Controller端先读取配置文件并解析，以确定全部采集目标，并访问各采集目标以获取采集目标的相关数据量；Controller端分析采集目标数据量，并对各个采集目标进行分类，分类后向Agent端发送分类后的采集目标信息，并接受到Agent端返回的响应信息；Agent端根据Controller端发送的采集目标信息生成对应的实例配置文件，以向监控集群prometheus中对应的监控实例注入该实例配置文件并热加载，以使实例配置文件生效，生效后即可接受到来自监控集群prometheus返回的成功信息；在监控集群prometheus中的各监控实例针对各自的采集目标进行数据采集时，向采集目标发送采集数据请求，采集目标则将数据反馈结果返回给各监控实例。

本实施例通过在每次更新原有的分配方式时，基于代理模块来为各个监控实例生成并注入相应实例配置文件，而原有的总配置文件还是保持不变，从而加强了各监控实例统一管理的效果。

进一步地，步骤S13之前，还包括：

步骤A1，检测所述采集目标集合中是否存在新增采集目标，其中，所述新增采集目标已自动添加至所述采集目标集合；

步骤A2，若是，则基于已添加所述新增采集目标的采集目标集合执行周期性向每一所述代理模块发送数据量查询请求的步骤。

在本实施例中，在Controller端首次根据配置文件发现全部采集目标后，后面周期性执行时只需检测是否有采集目标新增即可，无需重复获取已确定的采集目标的信息。

本实施例通过定时检测是否有新的采集目标加入，使得能够在存在新增采集目标时及时为其分配对应的监控实例，从而将新增采集目标的及时纳入监控集群的监控范围。

如图5所示，本发明还提供一种分布式监控集群管理系统，所述分布式监控集群管理系统包括：

待采数据统计模块10，用于获取与监控集群所监控的采集目标集合相关的配置文件，基于所述配置文件周期性统计所述采集目标集合中的采集目标对应的当前待采数据量；

分配方式确定模块20，用于根据获取到的所述当前待采数据量，按照预设的均衡分配原则确定所述采集目标集合的目标分配方式，其中，所述均衡分配原则基于预设的单个监控实例的数据量承载上限以及数据均衡程度评估标准所设置；

采集目标分配模块30，用于按照所述目标分配方式，将各所述采集目标分配给所述监控集群中的各监控实例，以供各所述监控实例针对当前分配到的采集目标进行监控采集。

可选地，所述分配方式确定模块20包括：

分类结果获取单元，用于按照预设分类方式对各所述采集目标进行分类，以得到分类结果；

分配方式确定单元，用于根据所述分类结果和每一次获取到的每一所述当前待采数据量，按照所述均衡分配原则确定每一次的所述目标分配方式。

可选地，所述分类结果获取单元还用于：

根据所述配置信息获取各所述采集目标的所属任务信息，其中，每一所述所属任务信息对应一个或多个所述采集目标；

将同一所述所属任务信息对应的多个所述采集目标归为同一类别；和/或，

获取同一所述所属任务信息对应的单个所述采集目标的访问频次，并根据预设频次等级映射表确定所述访问频次对应的等级信息，以将相同等级信息所对应的所述采集目标归为同一类别。

可选地，所述分配方式确定单元还用于：

根据所述分类结果和每一次获取到的每一所述当前待采数据量，采用预设均衡算法模拟计算出不同分配方式下每一所述监控实例所承载的待采数据量以及对应的数据均衡程度，其中，所述待采数据量为将同一类别或不同类别下的若干所述采集目标分配给同一所述监控实例时，同一所述监控实例所承载的数据量；

分析每一次的不同分配方式下的数据均衡程度以及所述待采数据量，从不同分配方式中确定出符合所述均衡分配标准的分配方式作为所述目标分配方式。

可选地，所述预设均衡算法基于一致性哈希和标准差所设计，

所述分配方式确定单元还用于：

在不同分配方式下，针对所述分类结果中的每一类别，采用一致性哈希算法为每一所述监控实例分配同一类别的若干所述采集目标，分配完成后得到每一所述监控实例所承载的待采数据量；

根据每一所述待采数据量得到每一类别的采集目标所对应的标准差，以表示所述数据均衡程度；

对于每一分配方式，判断每一所述监控实例所承载的待采数据量是否均未超过预设的数据承载上限，且每一类别的所述标准差是否满足预设数据均衡程度评估标准；

若每一所述监控实例所承载的待采数据量均未超过预设的数据承载上限，且每一类别的所述标准差满足预设数据均衡程度评估标准，则将当前分配方式作为所述目标分配方式。

可选地，所述系统中每一所述监控实例对应配置一代理模块，

所述待采数据统计模块10包括：

在接收到分布式采集指令时，根据所述分布式采集指令获取所述配置文件，并对所述配置文件进行解析，以确定所述监控集群所监控的采集目标集合；

访问所述采集目标集合中的每一所述采集目标，以统计每一所述采集目标对应的全量采集数据量；

周期性向每一所述代理模块发送数据量查询请求，以接收由每一所述代理模块基于所述数据量查询请求返回的每一所述监控实例对应的已采集数据量；

对比每一所述全量采集数据量和所述已采集数据量，周期性统计出每一所述采集目标对应的当前未采数据量。

可选地，所述采集目标分配模块30包括：

按照每一次确定的所述目标分配方式，从所述配置文件中提取出各所述监控实例对应的采集目标信息；

将各所述采集目标信息发送给对应的各所述代理模块，以供各所述代理模块基于所述采集目标信息对应生成各实例配置文件，并将各所述实例配置文件对应注入各所述监控实例。

可选地，所述采集目标分配模块30包括：

新增目标检测单元，用于检测所述采集目标集合中是否存在新增采集目标，其中，所述新增采集目标已自动添加至所述采集目标集合；

新增目标执行单元，用于若是，则基于已添加所述新增采集目标的采集目标集合执行周期性向每一所述代理模块发送数据量查询请求的步骤。

本发明还提供一种分布式监控集群管理设备。

所述分布式监控集群管理设备包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的分布式监控集群管理程序，其中所述分布式监控集群管理程序被所述处理器执行时，实现如上所述的分布式监控集群管理方法的步骤。

其中，所述分布式监控集群管理程序被执行时所实现的方法可参照本发明分布式监控集群管理方法的各个实施例，此处不再赘述。

本发明还提供一种计算机可读存储介质。

本发明计算机可读存储介质上存储有分布式监控集群管理程序，所述分布式监控集群管理程序被处理器执行时实现如上所述的分布式监控集群管理方法的步骤。

其中，所述分布式监控集群管理程序被执行时所实现的方法可参照本发明分布式监控集群管理方法各个实施例，此处不再赘述。

本发明还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上述的分布式监控集群管理方法的步骤。

其中，所述计算机程序被执行时所实现的方法可参照本发明分布式监控集群管理方法各个实施例，此处不再赘述。

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

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (7)

1.一种分布式监控集群管理方法，其特征在于，所述分布式监控集群管理方法应用于分布式监控集群管理系统，所述分布式监控集群管理方法包括：

获取与监控集群所监控的采集目标集合相关的配置文件，基于所述配置文件周期性统计所述采集目标集合中的采集目标对应的当前待采数据量；

根据获取到的所述当前待采数据量，按照预设的均衡分配原则确定所述采集目标集合的目标分配方式，具体包括：

按照预设分类方式对各所述采集目标进行分类，以得到分类结果；

根据所述分类结果和每一次获取到的每一所述当前待采数据量，按照所述均衡分配原则确定每一次的所述目标分配方式；具体包括：

根据所述分类结果和每一次获取到的每一所述当前待采数据量，采用预设均衡算法模拟计算出不同分配方式下每一监控实例所承载的待采数据量以及对应的数据均衡程度，分析每一次的不同分配方式下的数据均衡程度以及所述待采数据量，从不同分配方式中确定出符合所述均衡分配原则的分配方式作为所述目标分配方式；

所述预设均衡算法基于一致性哈希和标准差所设计，

所述采用预设均衡算法模拟计算出不同分配方式下每一所述监控实例所承载的待采数据量以及对应的数据均衡程度的步骤包括：

在不同分配方式下，针对所述分类结果中的每一类别，采用一致性哈希算法为每一所述监控实例分配同一类别的若干所述采集目标，分配完成后得到每一所述监控实例所承载的待采数据量；

根据每一所述待采数据量得到每一类别的采集目标所对应的标准差，以表示所述数据均衡程度；

所述分析每一次的不同分配方式下的数据均衡程度以及所述待采数据量，从不同分配方式中确定出符合所述均衡分配标准的分配方式作为所述目标分配方式的步骤包括：

对于每一分配方式，判断每一所述监控实例所承载的待采数据量是否均未超过预设的数据承载上限，且每一类别的所述标准差是否满足预设数据均衡程度评估标准；

若每一所述监控实例所承载的待采数据量均未超过预设的数据承载上限，且每一类别的所述标准差满足预设数据均衡程度评估标准，则将当前分配方式作为所述目标分配方式；

按照所述目标分配方式，将各所述采集目标分配给所述监控集群中的各监控实例，以供各所述监控实例针对当前分配到的采集目标进行监控采集。

2.如权利要求1所述的分布式监控集群管理方法，其特征在于，所述按照预设分类方式对各所述采集目标进行分类，以得到分类结果的步骤包括：

根据配置信息获取各所述采集目标的所属任务信息，其中，每一所述所属任务信息对应一个或多个所述采集目标；

将同一所述所属任务信息对应的多个所述采集目标归为同一类别；和/或，

获取同一所述所属任务信息对应的单个所述采集目标的访问频次，并根据预设频次等级映射表确定所述访问频次对应的等级信息，以将相同等级信息所对应的所述采集目标归为同一类别。

3.如权利要求1所述的分布式监控集群管理方法，其特征在于，所述系统中每一所述监控实例对应配置一代理模块，

所述获取与监控集群所监控的采集目标集合相关的配置文件，基于所述配置文件周期性统计所述采集目标集合中的采集目标对应的当前待采数据量的步骤包括：

在接收到分布式采集指令时，根据所述分布式采集指令获取所述配置文件，并对所述配置文件进行解析，以确定所述监控集群所监控的采集目标集合；

访问所述采集目标集合中的每一所述采集目标，以统计每一所述采集目标对应的全量采集数据量；

周期性向每一所述代理模块发送数据量查询请求，以接收由每一所述代理模块基于所述数据量查询请求返回的每一所述监控实例对应的已采集数据量；

对比每一所述全量采集数据量和所述已采集数据量，周期性统计出每一所述采集目标对应的当前未采数据量。

4.如权利要求3所述的分布式监控集群管理方法，其特征在于，所述按照所述目标分配方式，将各所述采集目标分配给所述监控集群中的各监控实例的步骤包括：

按照每一次确定的所述目标分配方式，从所述配置文件中提取出各所述监控实例对应的采集目标信息；

将各所述采集目标信息发送给对应的各所述代理模块，以供各所述代理模块基于所述采集目标信息对应生成各实例配置文件，并将各所述实例配置文件对应注入各所述监控实例。

5.如权利要求3所述的分布式监控集群管理方法，其特征在于，所述周期性向每一所述代理模块发送数据量查询请求的步骤之前，还包括：

检测所述采集目标集合中是否存在新增采集目标，其中，所述新增采集目标已自动添加至所述采集目标集合；

若是，则基于已添加所述新增采集目标的采集目标集合执行周期性向每一所述代理模块发送数据量查询请求的步骤。

6.一种分布式监控集群管理设备，其特征在于，所述分布式监控集群管理设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的分布式监控集群管理程序，所述分布式监控集群管理程序被所述处理器执行时实现如权利要求1至5中任一项所述的分布式监控集群管理方法的步骤。

7.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有分布式监控集群管理程序，所述分布式监控集群管理程序被处理器执行时实现如权利要求1至5中任一项所述的分布式监控集群管理方法的步骤。