CN112994935B - prometheus管控方法、装置、设备及存储介质 - Google Patents

Abstract

本发明公开了一种prometheus管控方法、装置、设备及存储介质，所述方法通过从分布式watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个prometheus服务中；使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例；在故障转移完成后，通过目标主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化；能够实现prometheus集群高可用性和数据一致性，也做到了数据的持久性；灵活性安全性高，效率更高，并且扩展性更好。

Description

prometheus管控方法、装置、设备及存储介质

技术领域

本发明涉及云原生容器术领域，尤其涉及一种prometheus管控方法、装置、设备及存储介质。

背景技术

目前在很多容器编排引擎kubernetes容器平台场景下，***监控和报警框架prometheus采用单点部署，单点部署如果prometheus服务出现异常或者下线，则会导致数据不完整或者数据丢失情况。

针对单点问题，目前常见的有以下解决方法：1、基本高可用(High Availability，HA)，即服务可用性，此方案用户只需要部署多套prometheus服务实例，并且采集相同的出口Exporter目标即可；基本的HA模式只能确保prometheus服务的可用性问题，但是不解决prometheus服务之间的数据一致性问题以及持久化问题，即数据丢失后无法恢复，也无法进行动态的扩展。因此这种部署方式适合监控规模不大，prometheus服务也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景。

官方推荐使用联邦方式，就是部署多个prometheus实例，再部署根实例管理其他prometheus实例，这种方法虽然解决了单点问题和数据不一致问题，但是如果根实例有问题，那么监控***还是不能正常运行，同时也不能保证数据持久化。

发明内容

本发明的主要目的在于提供一种prometheus管控方法、装置、设备及存储介质，旨在解决现有技术中prometheus服务之间数据不一致且不能保证数据持久化的技术问题。

第一方面，本发明提供一种prometheus管控方法，所述prometheus管控方法包括以下步骤：

从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中；

使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例；

在故障转移完成后，通过所述目标主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化。

可选地，所述从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中，包括：

获取每个监控告警框架prometheus服务的各prometheus实例，将各prometheus实例部署在容器编排引擎kubernetes集群中；

从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在各prometheus实例的数据结构pod中。

可选地，所述使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例，包括：

使用gossip协议从prometheus服务中获取主实例和从实例信息，根据所述主实例和从实例信息判断所述主实例是否故障或服务异常；

在监测到prometheus的主实例故障或服务异常时，生成主实例状态异常命令；

将所述主实例状态异常命令发送至其他watcher实例，接收投票信息，并根据所述投票信息进行故障转移，并确定新的主实例作为目标主实例。

可选地，所述使用gossip协议从prometheus服务中获取主实例和从实例信息，根据所述主实例和从实例信息判断所述主实例是否故障或服务异常，包括：

使用gossip协议从prometheus服务中读取prometheus的配置文件，从所述配置文件中获取各实例的实例标识符，选取实例标识符中编号最小的标识符对应的实例为主实例；

将所述主实例的主实例信息写入至目标watcher实例的监测配置文件中，在所述目标watcher实例启动时加载所述监测配置文件；

在检测到所述目标watcher实例正常启动后，连接其他watcher实例以及所述prometheus服务中除了主实例外的其他从实例；

所述目标watcher实例定期从所述prometheus服务对应的集群中获取主实例和从实例信息；

根据所述主实例和从实例信息确定所述主实例的当前状态，根据所述当前状态判断所述主实例是否故障或服务异常。

可选地，所述在监测到prometheus的主实例故障或服务异常时，生成主实例状态异常命令，包括：

在监测到prometheus的主实例故障或服务异常时，将所述主实例对应的当前watcher实例作为发起者；

生成询问其他watcher实例是否同意所述当前watcher实例作为发起者的主实例状态异常命令。

可选地，所述将所述主实例状态异常命令发送至其他watcher实例，接收投票信息，并根据所述投票信息进行故障转移，并确定新的主实例作为目标主实例，包括：

将所述主实例状态异常命令发送至其他watcher实例，接收其他watcher实例反馈的投票信息；

在所述投票信息显示同意占比大于预设占比时，通过作为发起者的当前watcher实例排除异常的prometheus实例，获得剩余的prometheus实例集群；

从剩余的prometheus实例集群中选取实例标识符最小的实例作为新的主实例，或者从剩余的prometheus实例集群中选取复制偏移量最大的实例作为新的主实例，并将新的主实例作为目标主实例。

可选地，所述在故障转移完成后，通过所述主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化，包括：

在故障转移完成后，通过所述主实例从配置服务器读取监控服务的配置信息；

根据所述配置信息采集所述监控服务的各监控指标，并将各监控指标复制同步至其他prometheus实例；

将各监控指标写到时序数据库influxdb中进行持久化。

第二方面，为实现上述目的，本发明还提出一种prometheus管控装置，所述prometheus管控装置包括：

部署模块，用于从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中；

异常监测模块，用于使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例；

持久化模块，用于在故障转移完成后，通过所述主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化。

第三方面，为实现上述目的，本发明还提出一种prometheus管控设备，所述prometheus管控设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的prometheus管控程序，所述prometheus管控程序配置为实现如权利要求上文所述的prometheus管控方法的步骤。

第四方面，为实现上述目的，本发明还提出一种存储介质，所述存储介质上存储有prometheus管控程序，所述prometheus管控程序被处理器执行时实现如上文所述的prometheus管控方法的步骤。

本发明提出的prometheus管控方法，通过从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中；使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例；在故障转移完成后，通过所述主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化；能够在主实例服务异常时进行故障转移，确定新的主实例，整个集群可以做到不下线，解决了单点问题和数据不一致的问题，通过时序数据库实现了远端存储，实现了prometheus集群高可用性，既保证了数据一致性，也做到了数据的持久性；与依赖第三方组件的方案相比，本方案更加灵活，安全性高，不易受第三方组件影响、效率更高，并且扩展性更好。

附图说明

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

图2为本发明prometheus管控方法第一实施例的流程示意图

图3为本发明prometheus管控方法中watcher获取prometheus主从实例配置信息的架构示意图；

图4为本发明prometheus管控方法中各watcher实例之间进行prometheus主实例状态信息同步以及watcher自身状态的同步架构示意图；

图5为本发明prometheus管控方法第二实施例的流程示意图；

图6为本发明prometheus管控方法中watcher实例和各prometheus实例进行心跳保活的架构；

图7为本发明prometheus管控方法第三实施例的流程示意图；

图8为本发明prometheus管控方法第四实施例的流程示意图；

图9为本发明prometheus管控方法中prometheus集群协作流程示意图；

图10为本发明prometheus管控方法中prometheus主实例服务异常或下线检测示意图；

图11为本发明prometheus管控方法第五实施例的流程示意图；

图12为本发明prometheus管控方法第六实施例的流程示意图；

图13为本发明prometheus管控方法中故障转移流程图；

图14为本发明prometheus管控方法第七实施例的流程示意图；

图15为本发明prometheus管控装置第一实施例的功能模块图。

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

具体实施方式

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

本发明实施例的解决方案主要是：通过从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中；使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例；在故障转移完成后，通过所述目标主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化；能够在主实例服务异常时进行故障转移，确定新的主实例，整个集群可以做到不下线，解决了单点问题和数据不一致的问题，通过时序数据库实现了远端存储，实现了prometheus集群高可用性，既保证了数据一致性，也做到了数据的持久性；与依赖第三方组件的方案相比，本方案更加灵活，安全性高，不易受第三方组件影响、效率更高，并且扩展性更好，解决了现有技术中prometheus服务之间数据不一致且不能保证数据持久化的技术问题。

参照图1，图1为本发明实施例方案涉及的硬件运行环境的prometheus管控设备结构示意图。

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

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

如图1所示，作为一种存储介质的存储器1005中可以包括操作***、网络通信模块、用户接口模块以及prometheus管控程序。

本发明设备通过处理器1001调用存储器1005中存储的prometheus管控程序，所述prometheus管控程序被处理器执行时实现如上文所述的prometheus管控方法实施例的步骤。

本实施例通过上述方案，通过从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中；使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例；在故障转移完成后，通过所述目标主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化；能够在主实例服务异常时进行故障转移，确定新的主实例，整个集群可以做到不下线，解决了单点问题和数据不一致的问题，通过时序数据库实现了远端存储，实现了prometheus集群高可用性，既保证了数据一致性，也做到了数据的持久性；与依赖第三方组件的方案相比，本方案更加灵活，安全性高，不易受第三方组件影响、效率更高，并且扩展性更好。

基于上述硬件结构，提出本发明prometheus管控方法实施例。

参照图2，图2为本发明prometheus管控方法第一实施例的流程示意图。

在第一实施例中，所述prometheus管控方法包括以下步骤：

步骤S10、从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中。

需要说明的是，所述观察者watcher***为预先设置的一套分布式watcher***，watcher***中存在若干个watcher实例，可以将将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中，从而达到实时监控prometheus服务的目的。

可以理解的是，开源的***监控和报警框架prometheus是由SoundCloud开源监控告警解决方案；prometheus存储的是时序数据，即按相同时序(相同名称和标签)，以时间维度存储连续的数据的集合。

在具体实现中，如图3所示，图3为本发明prometheus管控方法中watcher获取prometheus主从实例配置信息的架构示意图；参照图3，master为prometheus主实例，slave0和slave1为prometheus从实例，每个watcher固定周期向prometheus主实例发送实例信息请求InstanceInfo请求获取其他从实例的配置，即请求获取其他从实例的配置信息及主从实例监控指标的本地存储信息，watcher的配置主要包括主实例的信息，通过向主实例发送InstanceInfo，获取所有从实例信息，并当有新的从实例加入集群时可以感知。

步骤S20、使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标实施例。

需要说明的是，gossip协议是一个通信协议，一种传播消息的方式，gossip协议基本思想就是：一个节点想要分享一些信息给网络中的其他的一些节点。于是，它周期性的随机选择一些节点，并把信息传递给这些节点；这些收到信息的节点接下来会做同样的事情，即把这些信息传递给其他一些随机选择的节点。

在具体实现中，prometheus服务：负责采集数据，存储到本地，同步到远端存储，查询数据，并提供告警通知；各个watcher实例之间会同步prometheus主实例的状态和各个watcher的状态；如图4所示，图4为本发明prometheus管控方法中各watcher实例之间进行prometheus主实例状态信息同步以及watcher自身状态的同步架构示意图；参照图4，每个watcher(watcher0，watcher1，watcher2)固定周期会向其他watcher(watcher0，watcher1，watcher2)发送主实例状态以及watcher配置信息，并进行prometheus主实例状态信息同步。

可以理解的是，通过使用gossip协议可以监控prometheus服务中的各实例，在监测到prometheus的主实例出现故障或者服务异常时，可以通过投票进行故障转移，并且确定新的主实例作为目标实施例，即在发现主实例故障或异常时，通过各实例的投票决定是否进行故障转移，以及根据投票决定确定以哪个实例作为新的主实例。

在具体实现中，通过gossip协议每个watcher都会定期的向prometheus主实例和从实例发送实例信息InstanceInfo，从而请求获得其他实例的配置，从而实现监测到prometheus的目的。

步骤S30、在故障转移完成后，通过所述目标主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化。

应当理解的是，在故障转移完成后，可以通过新的主实例，采集监控服务的各项监控指标，同时把这些指标复制到其他prometheus实例，并且通过写到时序数据库influxdb中来实现持久化。

进一步的，在完成持久化操作后，如果需要观测监控数据，可以通过客户端从时序数据库influxdb中读取监控数据进行展示，也可以对监控数据中的各监控指标分析后再进行展示，本实施例对此不加以限制。

本实施例通过上述方案，通过从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中；使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例；在故障转移完成后，通过所述目标主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化；能够在主实例服务异常时进行故障转移，确定新的主实例，整个集群可以做到不下线，解决了单点问题和数据不一致的问题，通过时序数据库实现了远端存储，实现了prometheus集群高可用性，既保证了数据一致性，也做到了数据的持久性；与依赖第三方组件的方案相比，本方案更加灵活，安全性高，不易受第三方组件影响、效率更高，并且扩展性更好。

进一步地，图5为本发明prometheus管控方法第二实施例的流程示意图，如图5所示，基于第一实施例提出本发明prometheus管控方法第二实施例，在本实施例中，所述步骤S10具体包括以下步骤：

步骤S11、获取每个监控告警框架prometheus服务的各prometheus实例，将各prometheus实例部署在容器编排引擎kubernetes集群中。

需要说明的是，容器编排引擎kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，在获取了每个监控告警框架prometheus服务的各prometheus实例后，可以将各prometheus实例部署在容器编排引擎kubernetes集群中，从而通过内置的负载均衡策略，实现各prometheus实例的管理、发现和访问。

步骤S12、从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在各prometheus实例的数据结构pod中。

可以理解的是，watcher***为预先设计的一套分布式watcher***，其中，watcher***中的每个watcher实例都可以作为sidecar部署在prometheus服务中，即部署在各prometheus实例的数据结构pod中。

在具体实现中，如图6所示，图6为本发明prometheus管控方法中watcher实例和各prometheus实例进行心跳保活的架构；参照图6，master为prometheus主实例，slave0和slave1为prometheus从实例，每个watcher(watcher0，watcher1，watcher2)固定周期会向主实例、从实例及其它watcher实例做一次心跳heartbeat检测，来对各个实例进行保活；即每个watcher实例都会固定周期向其他watcher实例发送主实例状态以及watcher实例配置信息，并且固定周期会向主实例、从实例及其它watcher实例做一次心跳检测，来实现对各个实例的状态监测，保持活性。

本实施例通过上述方案，通过获取每个监控告警框架prometheus服务的各prometheus实例，将各prometheus实例部署在容器编排引擎kubernetes集群中；从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在各prometheus实例的数据结构pod中；能够提高prometheus服务的数据稳定性，实现了prometheus集群高可用性，与依赖第三方组件的方案相比，本方案更加灵活，安全性高，不易受第三方组件影响、效率更高，并且扩展性更好。

进一步地，图7为本发明prometheus管控方法第三实施例的流程示意图，如图7所示，基于第一实施例提出本发明prometheus管控方法第三实施例，在本实施例中，所述步骤S20具体包括以下步骤：

步骤S21、使用gossip协议从prometheus服务中获取主实例和从实例信息，根据所述主实例和从实例信息判断所述主实例是否故障或服务异常。

需要说明的是，使用gossip协议每个watcher会不断定期检查prometheus服务的主实例和从实例是否运作正常，即watcher实例使用gossip协议接收prometheus主实例是否下线的信息，所述主实例和从实例信息为prometheus主实例信息和从实例信息，根据所述主实例和从实例信息判断所述主实例是否故障或服务异常。

可以理解的是，每个watcher实例(例如watcher0、watcher1、watcher2。。。)会以固定周期向prometheus主实例和从实例发送实例信息InstanceInfo请求，从而获取主实例和其他从实例的配置信息，即通过watcher实例向主实例发送InstanceInfo，获取所有从实例信息；而当有新的从实例加入集群时可以通过watcher实例感知。

应当理解的是，通过所述主实例和从实例信息能够确定主实例的主实例状态，可以确定主实例是否出现下线等其他异常状态。

步骤S22、在监测到prometheus的主实例故障或服务异常时，生成主实例状态异常命令。

可以理解的是，在监测到prometheus的主实例故障或服务异常时，能够相应生成对应的主实例状态异常命令，所述主实例状态异常命令中包含当前主实例状态异常的相关信息，还包含请求其他从实例进行投票的请求信息。

步骤S23、将所述主实例状态异常命令发送至其他watcher实例，接收投票信息，并根据所述投票信息进行故障转移，并确定新的主实例作为目标主实例。

应当理解的是，每个在线的watcher实例都可以发起故障转移流程，当某一watcher实例确认主实例异常时，会向其它watcher实例发送主实例状态异常命令，并要求将自己设置为发起者，由发起者处理故障转移；当其它watcher收到此命令时，可以同意或者拒绝它成为发起者；当大多数watcher都同意时，此时由发起的watcher进行故障转移操作，并确定新的主实例作为目标主实例。

在具体实现中，在监测到prometheus的主实例故障或服务异常时，会将主实例异常事件同步到其他watcher实例，并停止prometheus主实例的同步复制状态；prometheus***启动时，可以按照prometheus自身配置文件的实例优先级编号来确定哪个Prometheus实例作为主实例，watcher获取到prometheus主实例的主实例信息后，可以把prometheus主实例信息写入watcher的配置信息中；每个watcher固定周期会向其他watcher发送主实例状态以及watcher信息，并且每个watcher固定周期会向主实例、从实例及其它watcher实例做一次心跳检测；当大部分watcher都认为prometheus主实例故障或服务异常时，watcher投票选出的发起者会进行故障转移，选出新的主实例，原来的从实例会向新的主节点发起复制；当故障转移完成后，主实例开始从配置服务器读取监控服务的配置信息；主实例开始采集监控服务的各项监控指标，同时把这些指标复制到其他prometheus实例；同时主实例会把采集到的指标远程写到influxdb中进行持久化。

本实施例通过上述方案，通过使用gossip协议从prometheus服务中获取主实例和从实例信息，根据所述主实例和从实例信息判断所述主实例是否故障或服务异常；在监测到prometheus的主实例故障或服务异常时，生成主实例状态异常命令；将所述主实例状态异常命令发送至其他watcher实例，接收投票信息，并根据所述投票信息进行故障转移，并确定新的主实例作为目标主实例；能够在主实例服务异常时，快速进行故障转移，确定新的主实例，整个集群可以做到不下线，解决了单点问题和数据不一致的问题，本方案更加灵活，安全性高，不易受第三方组件影响、效率更高，并且扩展性更好。

进一步地，图8为本发明prometheus管控方法第四实施例的流程示意图，如图8所示，基于第三实施例提出本发明prometheus管控方法第四实施例，在本实施例中，所述步骤S21具体包括以下步骤：

步骤S211、使用gossip协议从prometheus服务中读取prometheus的配置文件，从所述配置文件中获取各实例的实例标识符，选取实例标识符中编号最小的标识符对应的实例为主实例。

应当理解的是，使用gossip协议能够从prometheus服务中读取prometheus的配置文件，所述配置文件中有对应各prometheus实例的实例标识符，例如ins0，ins1，ins2等，一般默认标识符编号最小的为主实例，当然也可以以其他要素选取主实例，例如选取复制偏移量最大的实例作为主实例，本实施例对此不加以限制；所述配置文件中除了包含实例标识符之外，还包括其他实例的配置信息。

步骤S212、将所述主实例的主实例信息写入至目标watcher实例的监测配置文件中，在所述目标watcher实例启动时加载所述监测配置文件。

可以理解的是，所述目标watcher实例为当前正在检测所述主实例的watcher实例，prometheus主实例将主实例信息写入到目标watcher的配置文件中，目标watcher实例启动时会加载配置文件，该配置文件中包含prometheus主实例信息，以及watcher实例优先级编号sid＝0，1，2等作为标识符，所述watcher实例优先级编号sid为进行索引标识的编号。

步骤S213、在检测到所述目标watcher实例正常启动后，连接其他watcher实例以及所述prometheus服务中除了主实例外的其他从实例。

应当理解的是，watcher实例正常启动后，会连接其他watcher和prometheus实例，从而方便各watcher实例之间的数据互通，当被监控的某个实例出现问题时，watcher通过超文本传输协议(Hyper Text Transfer Protocol，HTTP)协议把有问题的实例的状态通知给其他watcher；前述的gossip协议是watch监控主实例采用的协议，这里的HTTP协议是各个watch之间对监控到prometheus实例状态信息的传输协议。

在具体实现中，如图9所示，图9为本发明prometheus管控方法中prometheus集群协作流程示意图，参见图9，S400、prometheus开始启动时读取prometheus的配置文件，每个配置文件有实例标识符ins0，ins1，ins2，默认标识符编号最小的为主实例，以及其他实例的配置信息；S401、prometheus主实例将主实例信息写入到watcher的配置文件；watcher实例启动时加载配置文件(prometheus主实例信息，以及watcher实例优先级编号sid＝0，1，2等，作为标识符)；S402、watcher实例正常启动，连接其他watcher和prometheus实例；S403、watcher定时从prometheus集群获取主实例和从实例信息，watcher实例周期性动态监控prometheus主实例的状态；即在主实例被检测到故障或服务异常时，就需要开始进行新主实例的选举，而从实例信息则是必要的，其配置信息及状态成为是构成为新主实例的关键；S404、各个watcher实例之间同步prometheus主实例的状态和各个watcher的状态；S405、prometheus主实例从配置文件获取需要采集的监控对象服务，即发现服务(SVCdiscover)；S406、prometheus主实例开始采集服务service(SVC1、SVC2)的指标，指标保存到本地时序数据库，可以理解的是，prometheus提供了本地存储；本地存储的优势就是运维简单,缺点就是无法海量的metrics持久化和数据存在丢失的风险；时序数据库influxdb是为了解决单节点故障及存储的限制，作为prometheus远端存储***，实现prometheus的扩展性；S407、prometheus主实例复制同步监控指标到其他prometheus从实例；S408、prometheus主实例再将本地指标远程同步到后端时序数据库influxdb集群；S409、客户端client从时序数据库influxdb获取指标进行，展示和分析。

步骤S214、所述主实例定期从所述prometheus服务对应的集群中获取主实例和从实例信息。

需要说明的是，所述主实例会定期向所述prometheus服务对应的集群中的prometheus主实例和从实例发送实例信息InstanceInfo请求，从而获得主实例和从实例信息，所述主实例和从实例信息中包含主实例和从实例的标签、IP以及端口等。

步骤S215、根据所述主实例和从实例信息确定所述主实例的当前状态，根据所述当前状态判断所述主实例是否故障或服务异常。

可以理解的是，所述主实例和从实例信息中会记载prometheus主实例的状态信息，watcher实例会定时从prometheus集群获取主实例和从实例信息，从而实现watcher实例周期性动态监控prometheus主实例的状态，通过所述主实例的当前状态能够判断prometheus主实例状态是否异常，在主实例状态为服务异常或主实例故障或实例下线时，可以判断所述主实例是否故障或服务异常。

在具体实现中，如图10所示，图10为本发明prometheus管控方法中prometheus主实例服务异常或下线检测示意图；参见图10，S500、各个watcher实例之间同步prometheus主实例的状态和各个watcher的状态；S501、watcher实例周期性动态监控prometheus主实例的状态；S502、watcher0实例发现prometheus主实例状态异常，并将主实例异常事件同步到其他watcher实例；S503、停止prometheus主实例的同步复制状态。

本实施例通过上述方案，通过使用gossip协议从prometheus服务中读取prometheus的配置文件，从所述配置文件中获取各实例的实例标识符，选取实例标识符中编号最小的标识符对应的实例为主实例；将所述主实例的主实例信息写入至目标watcher实例的监测配置文件中，在所述目标watcher实例启动时加载所述监测配置文件；在检测到所述目标watcher实例正常启动后，连接其他watcher实例以及所述prometheus服务中除了主实例外的其他从实例；所述目标watcher实例定期从所述prometheus服务对应的集群中获取主实例和从实例信息；根据所述主实例和从实例信息确定所述主实例的当前状态，根据所述当前状态判断所述主实例是否故障或服务异常；能够快速确定主实例服务异常，提高主实例故障或服务异常确定的准确性，缩短故障判断时间，提高了故障判断的速度，进而提升了在主实例服务异常时进行故障转移的速度和效率。

进一步地，图11为本发明prometheus管控方法第五实施例的流程示意图，如图11所示，基于第三实施例提出本发明prometheus管控方法第五实施例，在本实施例中，所述步骤S22具体包括以下步骤：

步骤S221、在监测到prometheus的主实例故障或服务异常时，将所述主实例对应的当前watcher实例作为发起者。

需要说明的是，在监测到prometheus的主实例故障或服务异常时，可以默认将当前watcher实例作为发起者，从而通知其他watcher实例；各个watcher实例之间同步prometheus主实例的状态和各个watcher的状态；并且watcher实例周期性动态监控prometheus主实例的状态。

步骤S222、生成询问其他watcher实例是否同意所述当前watcher实例作为发起者的主实例状态异常命令。

可以理解的是，在监测到prometheus的主实例故障或服务异常时，可以生成询问其他watcher实例的主实例状态异常命令，所述主实例状态异常命令中包含主实例状态异常的相关信息，以及询问是否同意所述当前watcher实例作为发起者的请求信息。

在具体实现中，当前watcher实例发现prometheus主实例下线后，当前watcher实例会通知其他watcher实例主实例状态，并且询问其他watcher实例反馈是否赞同；如果大部分watcher实例表示同意；那么这个时候由当前watcher实例开始进行选主实例。

本实施例通过上述方案，通过在监测到prometheus的主实例故障或服务异常时，将所述主实例对应的当前watcher实例作为发起者；生成询问其他watcher实例是否同意所述当前watcher实例作为发起者的主实例状态异常命令；能够通过投票机制，在主实例服务异常时进行故障转移，确定新的主实例，整个集群可以做到不下线，解决了单点问题和数据不一致的问题；与依赖第三方组件的方案相比，本方案更加灵活，安全性高，不易受第三方组件影响、效率更高，并且扩展性更好。

进一步地，图12为本发明prometheus管控方法第六实施例的流程示意图，如图12所示，基于第三实施例提出本发明prometheus管控方法第六实施例，在本实施例中，所述步骤S23具体包括以下步骤：

步骤S231、将所述主实例状态异常命令发送至其他watcher实例，接收其他watcher实例反馈的投票信息。

需要说明的是，每个在线的watcher都可以发起故障转移流程，当某一watcher实例确认主实例异常时，会向其它watcher发主实例状态异常命令，并要求将自己设置为发起者，由发起者处理故障转移，所述投票信息为其他watcher实例反馈的同意或否定当前watcher为发起者的信息。

步骤S232、在所述投票信息显示同意占比大于预设占比时，通过作为发起者的当前watcher实例排除异常的prometheus实例，获得剩余的prometheus实例集群。

可以理解的是，所述预设占比为预先设置的投票占比，其他watcher实例在收到主实例状态异常命令后，可以同意或者拒绝当前watcher实例成为发起者；当大多数watcher实例都同意时，此时由发起的当前watcher实例进行故障转移操作；故障转移操作的第一步是排除之前异常的prometheus主实例，再确定剩余的prometheus实例集群。

步骤S233、从剩余的prometheus实例集群中选取实例标识符最小的实例作为新的主实例，或者从剩余的prometheus实例集群中选取复制偏移量最大的实例作为新的主实例，并将新的主实例作为目标主实例。

应当理解的是，可以从剩余的prometheus实例集群中选取实例标识符最小的实例作为新的主实例，或者可以选择出复制偏移量最大的prometheus实例作为新的主实例，并将新的主实例作为目标主实例，因为复制偏移量越大则数据复制的越完整；选定主实例后，可以更新各prometheus实例状态，并开始数据同步。

在具体实现中，如图13所示，图13为本发明prometheus管控方法中故障转移流程图，参见图13，S600、各个watcher实例之间同步prometheus主实例的状态和各个watcher的状态；S601 watcher实例周期性动态监控prometheus主实例的状态(图中略掉了到prometheus1、prometheus2的S601)；S602、watcher0发现prometheus主实例下线，watcher0通知其他watcher实例，主实例状态。其他实例反馈是否赞同。如果大部分实例表示同意那么这个时候由watcher0开始进行选主；S603、watcher0开始进行选主，排除异常prometheus实例，选择标识符较小的实例，或者选择复制偏移量大的实例作为主实例；并更新各实例状态；S604 watcher选出prometheus2为主实例后，开始数据同步，此次是故障转移后的首次数据同步操作；S605、prometheus2实例获取监控服务的配置信息，即发现服务(SVCdiscover)；S606 promethues2实例开始采集监控服务service(SVC1、SVC2)的指标，同时保存到本地；S604、prometheus2实例开始复制监控数据，此次为主实例向从实例正常周期数据复制操作；S607、prometheus2实例开始远程同步数据到后端influxdb；S608、客户端client从时序数据库influxdb获取指标进行展示，分析。

本实施例通过上述方案，通过将所述主实例状态异常命令发送至其他watcher实例，接收其他watcher反馈的投票信息；在所述投票信息显示同意占比大于预设占比时，通过作为发起者的当前watcher排除异常的prometheus实例，获得剩余的prometheus实例集群；从剩余的prometheus实例集群中选取实例标识符最小的实例作为新的主实例，或者从剩余的prometheus实例集群中选取复制偏移量最大的实例作为新的主实例，并将新的主实例作为目标主实例；能够在主实例服务异常时进行故障转移，确定新的主实例，整个集群可以做到不下线，解决了单点问题和数据不一致的问题。

进一步地，图14为本发明prometheus管控方法第七实施例的流程示意图，如图14所示，基于第一实施例提出本发明prometheus管控方法第七实施例，在本实施例中，所述步骤S30具体包括以下步骤：

步骤S31、在故障转移完成后，通过所述目标主实例从配置服务器读取监控服务的配置信息。

需要说明的是，在故障转移完成后，可以通过所述目标主实例开始同步复制数据，即各个watcher实例之间同步prometheus主实例的状态和各个watcher的状态，通过所述目标主实例从配置服务器读取监控服务的配置信息，监控服务为prometheus主实例从配置文件获取需要采集的监控对象服务。

步骤S32、根据所述配置信息采集所述监控服务的各监控指标，并将各监控指标复制同步至其他prometheus实例。

可以理解的是，根据所述配置信息采集所述监控服务的各监控指标，即prometheus主实例开始采集指标，指标一般可以保存到本地，再复制同步监控指标至其他prometheus从实例。

步骤S33、将各监控指标写到时序数据库influxdb中进行持久化。

应当理解的是，通过所述目标主实例可以开始远程同步数据到后端时序数据库，即将各监控指标写到时序数据库influxdb中进行持久化，一般是将本地指标远程同步到后端时序数据库influxdb集群，从而实现持久化，客户端可以从influxdb获取指标进行，展示和分析。

本实施例通过上述方案，通过在故障转移完成后，通过所述目标主实例从配置服务器读取监控服务的配置信息；根据所述配置信息采集所述监控服务的各监控指标，并将各监控指标复制同步至其他prometheus实例；将各监控指标写到时序数据库influxdb中进行持久化；能够通过时序数据库实现了远端存储，实现了prometheus集群高可用性，既保证了数据一致性，也做到了数据的持久性。

相应地，本发明进一步提供一种prometheus管控装置。

参照图15，图15为本发明prometheus管控装置第一实施例的功能模块图。

本发明prometheus管控装置第一实施例中，该prometheus管控装置包括：

部署模块10，用于从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中。

异常监测模块20，用于使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例。

持久化模块30，用于在故障转移完成后，通过所述目标主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化。

其中，prometheus管控装置的各个功能模块实现的步骤可参照本发明prometheus管控方法的各个实施例，此处不再赘述。

此外，本发明实施例还提出一种存储介质，所述存储介质上存储有prometheus管控程序，所述prometheus管控程序被处理器执行时实现如上文所述的prometheus管控方法实施例的步骤。

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

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

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

Claims (9)

1.一种prometheus管控方法，其特征在于，所述prometheus管控方法包括：

从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中；

使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例；

在故障转移完成后，通过所述目标主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化。

2.如权利要求1所述的prometheus管控方法，其特征在于，所述从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中，包括：

获取每个监控告警框架prometheus服务的各prometheus实例，将各prometheus实例部署在容器编排引擎kubernetes集群中；

从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在各prometheus实例的数据结构pod中。

3.如权利要求1所述的prometheus管控方法，其特征在于，所述使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例，包括：

使用gossip协议从prometheus服务中读取prometheus的配置文件，从所述配置文件中获取各实例的实例标识符，选取实例标识符中编号最小的标识符对应的实例为主实例；

将所述主实例的主实例信息写入至目标watcher实例的监测配置文件中，在所述目标watcher实例启动时加载所述监测配置文件；

在检测到所述目标watcher实例正常启动后，连接其他watcher实例以及所述prometheus服务中除了主实例外的其他从实例；

所述目标watcher实例定期从所述prometheus服务对应的集群中获取主实例和从实例信息；

根据所述主实例和从实例信息确定所述主实例的当前状态，根据所述当前状态判断所述主实例是否故障或服务异常；

在监测到prometheus的主实例故障或服务异常时，生成主实例状态异常命令；

将所述主实例状态异常命令发送至其他watcher实例，接收投票信息，并根据所述投票信息进行故障转移，并确定新的主实例作为目标主实例，其中，所述其他watcher实例为除所述目标watcher实例之外的watcher实例。

4.如权利要求3所述的prometheus管控方法，其特征在于，所述在监测到prometheus的主实例故障或服务异常时，生成主实例状态异常命令，包括：

在监测到prometheus的主实例故障或服务异常时，将所述主实例对应的当前watcher实例作为发起者；

生成询问其他watcher实例是否同意所述当前watcher实例作为发起者的主实例状态异常命令。

5.如权利要求3所述的prometheus管控方法，其特征在于，所述将所述主实例状态异常命令发送至其他watcher实例，接收投票信息，并根据所述投票信息进行故障转移，并确定新的主实例作为目标主实例，包括：

将所述主实例状态异常命令发送至其他watcher实例，接收其他watcher实例反馈的投票信息；

在所述投票信息显示同意占比大于预设占比时，通过作为发起者的当前watcher实例排除异常的prometheus实例，获得剩余的prometheus实例集群；

从剩余的prometheus实例集群中选取实例标识符最小的实例作为新的主实例，或者从剩余的prometheus实例集群中选取复制偏移量最大的实例作为新的主实例，并将新的主实例作为目标主实例。

6.如权利要求1-5中任一项所述的prometheus管控方法，其特征在于，所述在故障转移完成后，通过所述主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化，包括：

在故障转移完成后，通过所述主实例从配置服务器读取监控服务的配置信息；

根据所述配置信息采集所述监控服务的各监控指标，并将各监控指标复制同步至其他prometheus实例；

将各监控指标写到时序数据库influxdb中进行持久化。

7.一种prometheus管控装置，其特征在于，所述prometheus管控装置包括：

部署模块，用于从分布式观察者watcher***中获取各watcher实例，将各watcher实例作为sidecar部署在每个监控告警框架prometheus服务中；

异常监测模块，用于使用gossip协议监控prometheus服务中的各实例，在监测到prometheus的主实例故障或服务异常时，投票进行故障转移，并确定新的主实例作为目标主实例；

持久化模块，用于在故障转移完成后，通过所述主实例采集监控服务的各监控指标，并将各监控指标写到时序数据库中进行持久化。

8.一种prometheus管控设备，其特征在于，所述prometheus管控设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的prometheus管控程序，所述prometheus管控程序配置为实现如权利要求1至6中任一项所述的prometheus管控方法的步骤。

9.一种存储介质，其特征在于，所述存储介质上存储有prometheus管控程序，所述prometheus管控程序被处理器执行时实现如权利要求1至6中任一项所述的prometheus管控方法的步骤。

Images