CN112256401B - 基于Kubernetes环境下的Prometheus高可用***及实现方法 - Google Patents

基于Kubernetes环境下的Prometheus高可用***及实现方法 Download PDF

Info

Publication number
CN112256401B
CN112256401B CN202011186088.2A CN202011186088A CN112256401B CN 112256401 B CN112256401 B CN 112256401B CN 202011186088 A CN202011186088 A CN 202011186088A CN 112256401 B CN112256401 B CN 112256401B
Authority
CN
China
Prior art keywords
node
prometheus
pod
configuration
sidecar
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202011186088.2A
Other languages
English (en)
Other versions
CN112256401A (zh
Inventor
张建伟
魏金雷
张晖
孙思清
高传集
蔡卫卫
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Inspur Cloud Information Technology Co Ltd
Original Assignee
Inspur Cloud Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inspur Cloud Information Technology Co Ltd filed Critical Inspur Cloud Information Technology Co Ltd
Priority to CN202011186088.2A priority Critical patent/CN112256401B/zh
Publication of CN112256401A publication Critical patent/CN112256401A/zh
Application granted granted Critical
Publication of CN112256401B publication Critical patent/CN112256401B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了基于Kubernetes环境下的Prometheus高可用***及实现方法，属于元计算技术领域，本发明要解决的技术问题为如何保证多副本的Prometheus节点同时工作，避免单节点监控数据采集丢失的风险，采用的技术方案为：该***包括Manager端及Client端，Manager端和Client端均以Pod方式部署在Kubernetes中；其中，Manager端用于通过Kubernetes的Apiserver动态的获取到Client端Pod节点的访问地址，拉取对应地址的Client端监控数据并对数据去重，并发送对Prometheus配置更新的命令；Client端用于通过分布式的选举策略决定集群中Master角色的节点。本发明还公开了一种基于Kubernetes环境下的Prometheus高可用实现方法。

Description

基于Kubernetes环境下的Prometheus高可用***及实现方法
技术领域
本发明涉及云计算技术领域，具体地说是一种基于Kubernetes环境下的Prometheus高可用***及实现方法。
背景技术
Kubernetes是一种开源的容器集群管理工具，用于管理云平台中各类容器化的应用。而Prometheus是容器环境下的开源监控告警解决方案，是CNCF第二个毕业项目，成为了容器环境中监控告警方案的事实上的标准。但是Prometheus当前主要是单节点工作，没有较好的高可用方案。而一个成熟稳定的监控告警方案对于云平台来说至关重要。故如何保证多副本的Prometheus节点同时工作，避免单节点监控数据采集丢失的风险是目前亟待解决的技术问题。
发明内容
本发明的技术任务是提供一种基于Kubernetes环境下的Prometheus高可用***及实现方法，来解决如何保证多副本的Prometheus节点同时工作，避免单节点监控数据采集丢失的风险的问题。
本发明的技术任务是按以下方式实现的，一种基于Kubernetes环境下的Prometheus高可用***，该***包括Manager端(服务端)及Client端(客户端)，Manager端和Client端均以Pod方式部署在Kubernetes中；
其中，Manager端用于通过Kubernetes的Apiserver动态的获取到Client端Pod节点的访问地址，拉取对应地址的Client端监控数据并对数据去重，并发送对Prometheus配置更新的命令；
Client端用于通过分布式的选举策略决定集群中Master角色的节点。
作为优选，所述Manager端包括，
Metric模块，用于从多个Pod节点中获取到监控数据，并对监控数据去重后返回给监控数据请求者；
Configure模块，用于发送配置命令给Client端的Pod节点；
Alert模块，用于接收Client端Prometheus产生的告警。
更优地，每个Client端的Pod节点包括Prometheus以及Sidecar，Sidecar以容器方式与Prometheus部署在同一个Pod节点中；
其中，Sidecar用于接收Manager端的Configure模块发送的命令，执行Prometheus配置文件的更新操作，并将更新命令同步到除Master角色的节点外的Slave角色的节点；
Prometheus用于配置文件的更新操作，并发送产生的告警数据到Manager端。
更优地，该***的工作过程具体如下：
(一)Manager端通过Kubernetes的Apiserver动态的获取到Client端Pod节点的访问地址；
(二)Manager端拉取对应地址的Client端监控数据并对数据去重，同时Manager端发送对Prometheus配置更新的命令；
(三)Client端通过分布式的选举策略决定集群中Master角色的节点，Master角色的节点与Manager端交互，更新Prometheus的配置文件，并将产生的告警发送给Manger端；
(四)Master角色的节点将配置更新的命令同步Slave角色的节点，保证Prometheus的监控任务一致。
一种基于Kubernetes环境下的Prometheus高可用实现方法，该方法具体如下：
S1、在Kubernetes中以StatefulSet方式部署奇数个Pod节点，每个Pod节点打上标识标签为label＝{"prometheus_cluster":"true"}；
Manager端以Deployment方式部署，Pod数量不限；
S2、每个Client端的Pod节点存储使用持久化存储PersistentVolume，保证Pod节点重建之后，原Pod节点的数据不会丢失，进而保证其更新为增量更新；
S3、Client端的Sidecar启动后，进入到sleep状态，持续时间为Tsleep，并将Sidecar自身状态设置为候选者candidate；
S4、Sidecar通过Kubernetes的Apiserver以及Prometheus使用的Pod节点的标识标签获取并筛选出Prometheus集群各节点的Pod节点的IP地址；
S5、处于candidate状态的Sidecar进入选举投票阶段；
S6、Sidecar之间通过发送心跳信息保证其存活状态；其中，心跳信息包括本节点的角色及本地最新的日志文件索引号indexId；
S7、Master角色的节点的Sidecar会接收Manager端发送的配置更新命令并将Prometheus产生的告警发送给Manager端；同时Sidecar发送重新加载配置的命令给同属一个Pod节点的Prometheus，令其重新加载配置文件；
S8、Manager端通过Apiserver获取到运行中的Client端Pod节点的所有IP集合；具体如下：
(1)Configure模块发送配置命令给随机的Client端；
(2)判断Client端是否为Master角色的节点：
①若是，则其上的Sidecar会修改Prometheus的配置文件，并发送加载配置信号给Prometheus所在的容器；
②若否，则Slave角色的节点会将配置修改命令转发给Master节点；
S9、Master角色的节点的Prometheus配置更新完成后，Pod节点内的Sidecar会记录配置的更新操作并以日志文件形式持久化到PersistentVolume存储挂载的本地卷中，本地日志文件的索引号自动递增加1；同时将indexId置为最新的日志索引号并更新到心跳信息中；
S10、Manager端接收到用户请求查询监控数据后，调用Metric模块查询监控数据；
S11、Metric模块查询Kubernetes的Apiserver，根据Pod的label标签筛选并获取所有的Client节点及其IP地址；同时Metric模块通过获取到的Pod节点的IP以及获取监控数据的URL，拉取Client端的Prometheus中采集的监控数据；
S12、Metric模块获取到Prometheus中监控数据的时序数据后，在内存中构建最小堆，堆节点的key为数据的时间戳，value为其对应的时序数据；同样方式拉取其他Pod节点中Prometheus的监控数据，具体为：
若发现堆中有对应时间的数据，则丢弃该条记录，直到所有Prometheus的数据处理完成；
S13、用户通过Manager端的Metric模块，获取完整的监控数据，同时通过Alert模块获取到prometheus产生的告警数据。
作为优选，所述步骤S5中的处于candidate状态的Sidecar进入选举投票阶段具体如下：
S501、将票投给StatefulSet创建的编号最小的Pod；
S502、向所有的已知节点发送投票信息，并统计投票结果；
S503、判断是否有节点票数超过半数：
①、若有，则将该节点设置为Master角色的节点，剩余节点置为Slave角色的节点，下一步执行步骤S504；
②、若无，则跳转至步骤S505；
S504、Master角色的节点广播本地信息＜id,indexId＞；其中，id为唯一表示，每次更换Master角色的节点后其值递增加1；indexId表示本地日志索引更新后的最新值；
S505、在T＝(Tlow,Thigh)随机时间后，进入下次投票。
作为优选，所述步骤S6中的Sidecar之间通过发送心跳信息保证其存活状态包括如下两种情况如下：
(一)当Salve角色的节点崩溃，则Kubernetes会在时间Tgrace之后将其重建，具体如下：
①进入到candidate状态，Sidecar通过与集群Master角色的节点同步后，获取丢失的日志索引；
②更新本地配置文件以及心跳信息中的indexId后转入到Slave的状态；
(二)当崩溃节点为Master角色的节点，则剩下节点重新进入选举环节。
更优地，所述步骤S9中的将indexId置为最新的日志索引号并更新到心跳信息中具体如下：
S901、Master节点会将配置修改的命令以日志文件形式同步给其余的Slave角色的节点；
S902、Slave角色的节点的Sidecar接收到同步操作日志后解析命令并更新Prometheus的配置文件；
S903发送配置重新加载命令给其对应的Prometheus；
S904、Slave角色的节点更新其心跳信息中的最新索引号indexId。
一种电子设备，包括：存储器和至少一个处理器；
其中，所述存储器上存储有计算机程序；
所述至少一个处理器执行所述存储器存储的计算机程序，使得所述至少一个处理器执行如上述的基于Kubernetes环境下的Prometheus高可用实现方法。
一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序可被处理器执行以实现如上述的基于Kubernetes环境下的Prometheus高可用实现方法。
本发明的基于Kubernetes环境下的Prometheus高可用***及实现方法具有以下优点：
(一)本发明保证了多副本的Prometheus节点同时工作，避免单节点监控数据采集丢失的风险，同时基于分布式的选举策略，即保证只有一个节点能够发送告警，也保证了多副本Prometheus监控采集任务一致，再通过合并去重多副本的监控数据，保证了监控数据的准确完整；
(二)本发明通过Kubernetes的Apiserver动态获取到Prometheus节点所在的Client的Pod IP，保证了Pod重建之后即使IP地址变动，依然能够访问到集群所有的Client端；
(三)本发明的多节点的Prometheus集群，保证监控任务的高可用，采集数据的完整；
(四)本发明通过分布式的选举策略，保证多节点配置更新一致以及同一时间内只有Master节点能够发送告警反馈信息给Manager，避免了告警数据的重复发送；
(五)本发明的集群部署没有改变Prometheus***，无代码逻辑侵入，并且部署容易。
附图说明
下面结合附图对本发明进一步说明。
附图1为基于Kubernetes环境下的Prometheus高可用***结构框图。
具体实施方式
参照说明书附图和具体实施例对本发明的基于Kubernetes环境下的Prometheus高可用***及实现方法作以下详细地说明。
实施例1：
如附图1所示，本发明的基于Kubernetes环境下的Prometheus高可用***，该***包括Manager端(服务端)及Client端(客户端)，Manager端和Client端均以Pod方式部署在Kubernetes中；
其中，Manager端用于通过Kubernetes的Apiserver动态的获取到Client端Pod节点的访问地址，拉取对应地址的Client端监控数据并对数据去重，并发送对Prometheus配置更新的命令；
Client端用于通过分布式的选举策略决定集群中Master角色的节点。
本实施例中的Manager端包括，
Metric模块，用于从多个Pod节点中获取到监控数据，并对监控数据去重后返回给监控数据请求者；
Configure模块，用于发送配置命令给Client端的Pod节点；
Alert模块，用于接收Client端Prometheus产生的告警。
本实施例中的每个Client端的Pod节点包括Prometheus以及Sidecar，Sidecar以容器方式与Prometheus部署在同一个Pod节点中；具体如下：
(1)Sidecar通过分布式选举策略选出Master节点，同时为了避免多份Prometheus产生重复的告警，同一个时刻只有Master节点的Prometheus才会发送产生的告警给Manager端；
(2)Client端的Master节点的Sidecar接收Manager端Configure模块发送的命令，执行Prometheus配置文件的更新操作；
(3)、Master节点的Sidecar将更新命令同步到其他Salve节点，执行同样的更新操作。
该***的工作过程具体如下：
(一)Manager端通过Kubernetes的Apiserver动态的获取到Client端Pod节点的访问地址；
(二)Manager端拉取对应地址的Client端监控数据并对数据去重，同时Manager端发送对Prometheus配置更新的命令；
(三)Client端通过分布式的选举策略决定集群中Master角色的节点，Master角色的节点与Manager端交互，更新Prometheus的配置文件，并将产生的告警发送给Manger端；
(四)Master角色的节点将配置更新的命令同步Slave角色的节点，保证Prometheus的监控任务一致。
实施例2：
本发明的基于Kubernetes环境下的Prometheus高可用实现方法，该方法具体如下：
S1、在Kubernetes中以StatefulSet方式部署奇数个Pod节点，每个Pod节点打上标识标签为label＝{"prometheus_cluster":"true"}；
Manager端以Deployment方式部署，Pod数量不限；
S2、每个Client端的Pod节点存储使用持久化存储PersistentVolume，保证Pod节点重建之后，原Pod节点的数据不会丢失，进而保证其更新为增量更新；
S3、Client端的Sidecar启动后，进入到sleep状态，持续时间为Tsleep，并将Sidecar自身状态设置为候选者candidate；
S4、Sidecar通过Kubernetes的Apiserver以及Prometheus使用的Pod节点的标识标签获取并筛选出Prometheus集群各节点的Pod节点的IP地址；
S5、处于candidate状态的Sidecar进入选举投票阶段；
S6、Sidecar之间通过发送心跳信息保证其存活状态；其中，心跳信息包括本节点的角色及本地最新的日志文件索引号indexId；
S7、Master角色的节点的Sidecar会接收Manager端发送的配置更新命令并将Prometheus产生的告警发送给Manager端；同时Sidecar发送重新加载配置的命令给同属一个Pod节点的Prometheus，令其重新加载配置文件；
S8、Manager端通过Apiserver获取到运行中的Client端Pod节点的所有IP集合；具体如下：
(1)Configure模块发送配置命令给随机的Client端；
(2)判断Client端是否为Master角色的节点：
①若是，则其上的Sidecar会修改Prometheus的配置文件，并发送加载配置信号给Prometheus所在的容器；
②若否，则Slave角色的节点会将配置修改命令转发给Master节点；
S9、Master角色的节点的Prometheus配置更新完成后，Pod节点内的Sidecar会记录配置的更新操作并以日志文件形式持久化到PersistentVolume存储挂载的本地卷中，本地日志文件的索引号自动递增加1；同时将indexId置为最新的日志索引号并更新到心跳信息中；
S10、Manager端接收到用户请求查询监控数据后，调用Metric模块查询监控数据；
S11、Metric模块查询Kubernetes的Apiserver，根据Pod的label标签筛选并获取所有的Client节点及其IP地址；同时Metric模块通过获取到的Pod节点的IP以及获取监控数据的URL，拉取Client端的Prometheus中采集的监控数据；
S12、Metric模块获取到Prometheus中监控数据的时序数据后，在内存中构建最小堆，堆节点的key为数据的时间戳，value为其对应的时序数据；同样方式拉取其他Pod节点中Prometheus的监控数据，具体为：
若发现堆中有对应时间的数据，则丢弃该条记录，直到所有Prometheus的数据处理完成；
S13、用户通过Manager端的Metric模块，获取完整的监控数据，同时通过Alert模块获取到prometheus产生的告警数据。
本实施例中步骤S5中的处于candidate状态的Sidecar进入选举投票阶段具体如下：
S501、将票投给StatefulSet创建的编号最小的Pod；
S502、向所有的已知节点发送投票信息，并统计投票结果；
S503、判断是否有节点票数超过半数：
①、若有，则将该节点设置为Master角色的节点，剩余节点置为Slave角色的节点，下一步执行步骤S504；
②、若无，则跳转至步骤S505；
S504、Master角色的节点广播本地信息＜id,indexId＞；其中，id为唯一表示，每次更换Master角色的节点后其值递增加1；indexId表示本地日志索引更新后的最新值；
S505、在T＝(Tlow,Thigh)随机时间后，进入下次投票。
本实施例中步骤S6中的Sidecar之间通过发送心跳信息保证其存活状态包括如下两种情况如下：
(一)当Salve角色的节点崩溃，则Kubernetes会在时间Tgrace之后将其重建，具体如下：
①进入到candidate状态，Sidecar通过与集群Master角色的节点同步后，获取丢失的日志索引；
②更新本地配置文件以及心跳信息中的indexId后转入到Slave的状态；
(二)当崩溃节点为Master角色的节点，则剩下节点重新进入选举环节。
本实施例中步骤S9中的将indexId置为最新的日志索引号并更新到心跳信息中具体如下：
S901、Master节点会将配置修改的命令以日志文件形式同步给其余的Slave角色的节点；
S902、Slave角色的节点的Sidecar接收到同步操作日志后解析命令并更新Prometheus的配置文件；
S903发送配置重新加载命令给其对应的Prometheus；
S904、Slave角色的节点更新其心跳信息中的最新索引号indexId。
实施例3：
本发明实施例还提供了一种电子设备，包括：存储器和至少一个处理器；
其中，所述存储器存储计算机执行指令；
所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行本发明任一实施例中的基于Kubernetes环境下的Prometheus高可用实现方法。
实施例4：
本发明实施例还提供了一种计算机可读存储介质，其中存储有多条指令，指令由处理器加载，使处理器执行本发明任一实施例中的基于Kubernetes环境下的Prometheus高可用实现方法。具体地，可以提供配有存储介质的***或者装置，在该存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该***或者装置的计算机(或CPU或MPU)读出并执行存储在存储介质中的程序代码。
在这种情况下，从存储介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此程序代码和存储程序代码的存储介质构成了本发明的一部分。
用于提供程序代码的存储介质实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RYM、DVD-RW、DVD+RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上下载程序代码。
此外，应该清楚的是，不仅可以通过执行计算机所读出的程序代码，而且可以通过基于程序代码的指令使计算机上操作的操作***等来完成部分或者全部的实际操作，从而实现上述实施例中任意一项实施例的功能。
此外，可以理解的是，将由存储介质读出的程序代码写到***计算机内的扩展板中所设置的存储器中或者写到与计算机相连接的扩展单元中设置的存储器中，随后基于程序代码的指令使安装在扩展板或者扩展单元上的CPU等来执行部分和全部实际操作，从而实现上述实施例中任一实施例的功能。
最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (8)

1.一种基于Kubernetes环境下的Prometheus高可用***，其特征在于，该***包括Manager端及Client端，Manager端和Client端均以Pod方式部署在Kubernetes中；
其中，Manager端用于通过Kubernetes的Apiserver动态的获取到Client端Pod节点的访问地址，拉取对应地址的Client端监控数据并对数据去重，并发送对Prometheus配置更新的命令；其中，Manager端包括，
Metric模块，用于从多个Pod节点中获取到监控数据，并对监控数据去重后返回给监控数据请求者；
Configure模块，用于发送配置命令给Client端的Pod节点；
Alert模块，用于接收Client端Prometheus产生的告警；
Client端用于通过分布式的选举策略决定集群中Master角色的节点；其中，每个Client端的Pod节点包括Prometheus以及Sidecar，Sidecar以容器方式与Prometheus部署在同一个Pod节点中；
其中，Sidecar用于接收Manager端的Configure模块发送的命令，执行Prometheus配置文件的更新操作，并将更新命令同步到除Master角色的节点外的Slave角色的节点；
Prometheus用于配置文件的更新操作，并发送产生的告警数据到Manager端。
2.根据权利要求1所述的基于Kubernetes环境下的Prometheus高可用***，其特征在于，该***的工作过程具体如下：
(一)Manager端通过Kubernetes的Apiserver动态的获取到Client端Pod节点的访问地址；
(二)Manager端拉取对应地址的Client端监控数据并对数据去重，同时Manager端发送对Prometheus配置更新的命令；
(三)Client端通过分布式的选举策略决定集群中Master角色的节点，Master角色的节点与Manager端交互，更新Prometheus的配置文件，并将产生的告警发送给Manger端；
(四)Master角色的节点将配置更新的命令同步Slave角色的节点，保证Prometheus的监控任务一致。
3.一种基于Kubernetes环境下的Prometheus高可用实现方法，其特征在于，该方法具体如下：
S1、在Kubernetes中以StatefulSet方式部署奇数个Pod节点，每个Pod节点打上标识标签为label＝{"prometheus_cluster":"true"}；
Manager端以Deployment方式部署，Pod数量不限；
S2、每个Client端的Pod节点存储使用持久化存储PersistentVolume，保证Pod节点重建之后，原Pod节点的数据不会丢失，进而保证其更新为增量更新；
S3、Client端的Sidecar启动后，进入到sleep状态，持续时间为Tsleep，并将Sidecar自身状态设置为候选者candidate；
S4、Sidecar通过Kubernetes的Apiserver以及Prometheus使用的Pod节点的标识标签获取并筛选出Prometheus集群各节点的Pod节点的IP地址；
S5、处于candidate状态的Sidecar进入选举投票阶段；
S6、Sidecar之间通过发送心跳信息保证其存活状态；其中，心跳信息包括本节点的角色及本地最新的日志文件索引号indexId；
S7、Master角色的节点的Sidecar会接收Manager端发送的配置更新命令并将Prometheus产生的告警发送给Manager端；同时Sidecar发送重新加载配置的命令给同属一个Pod节点的Prometheus，令其重新加载配置文件；
S8、Manager端通过Apiserver获取到运行中的Client端Pod节点的所有IP集合；具体如下：
(1)Configure模块发送配置命令给随机的Client端；
(2)判断Client端是否为Master角色的节点：
①若是，则其上的Sidecar会修改Prometheus的配置文件，并发送加载配置信号给Prometheus所在的容器；
②若否，则Slave角色的节点会将配置修改命令转发给Master节点；
S9、Master角色的节点的Prometheus配置更新完成后，Pod节点内的Sidecar会记录配置的更新操作并以日志文件形式持久化到PersistentVolume存储挂载的本地卷中，本地日志文件的索引号自动递增加1；同时将indexId置为最新的日志索引号并更新到心跳信息中；
S10、Manager端接收到用户请求查询监控数据后，调用Metric模块查询监控数据；
S11、Metric模块查询Kubernetes的Apiserver，根据Pod的label标签筛选并获取所有的Client节点及其IP地址；同时Metric模块通过获取到的Pod节点的IP以及获取监控数据的URL，拉取Client端的Prometheus中采集的监控数据；
S12、Metric模块获取到Prometheus中监控数据的时序数据后，在内存中构建最小堆，堆节点的key为数据的时间戳，value为其对应的时序数据；同样方式拉取其他Pod节点中Prometheus的监控数据，具体为：
若发现堆中有对应时间的数据，则丢弃该条记录，直到所有Prometheus的数据处理完成；
S13、用户通过Manager端的Metric模块，获取完整的监控数据，同时通过Alert模块获取到prometheus产生的告警数据。
4.根据权利要求3所述的基于Kubernetes环境下的Prometheus高可用实现方法，其特征在于，所述步骤S5中的处于candidate状态的Sidecar进入选举投票阶段具体如下：
S501、将票投给StatefulSet创建的编号最小的Pod；
S502、向所有的已知节点发送投票信息，并统计投票结果；
S503、判断是否有节点票数超过半数：
①、若有，则将该节点设置为Master角色的节点，剩余节点置为Slave角色的节点，下一步执行步骤S504；
②、若无，则跳转至步骤S505；
S504、Master角色的节点广播本地信息＜id,indexId＞；其中，id为唯一表示，每次更换Master角色的节点后其值递增加1；indexId表示本地日志索引更新后的最新值；
S505、在T＝(Tlow,Thigh)随机时间后，进入下次投票。
5.根据权利要求3所述的基于Kubernetes环境下的Prometheus高可用实现方法，其特征在于，所述步骤S6中的Sidecar之间通过发送心跳信息保证其存活状态包括如下两种情况如下：
(一)当Salve角色的节点崩溃，则Kubernetes会在时间Tgrace之后将其重建，具体如下：
①进入到candidate状态，Sidecar通过与集群Master角色的节点同步后，获取丢失的日志索引；
②更新本地配置文件以及心跳信息中的indexId后转入到Slave的状态；
(二)当崩溃节点为Master角色的节点，则剩下节点重新进入选举环节。
6.根据权利要求3-5中任一所述的基于Kubernetes环境下的Prometheus高可用实现方法，其特征在于，所述步骤S9中的将indexId置为最新的日志索引号并更新到心跳信息中具体如下：
S901、Master节点会将配置修改的命令以日志文件形式同步给其余的Slave角色的节点；
S902、Slave角色的节点的Sidecar接收到同步操作日志后解析命令并更新Prometheus的配置文件；
S903发送配置重新加载命令给其对应的Prometheus；
S904、Slave角色的节点更新其心跳信息中的最新索引号indexId。
7.一种电子设备，其特征在于，包括：存储器和至少一个处理器；
其中，所述存储器上存储有计算机程序；
所述至少一个处理器执行所述存储器存储的计算机程序，使得所述至少一个处理器执行如权利要求3至6中任一项所述的基于Kubernetes环境下的Prometheus高可用实现方法。
8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序可被处理器执行以实现如权利要求3至6中任一所述的基于Kubernetes环境下的Prometheus高可用实现方法。
CN202011186088.2A 2020-10-30 2020-10-30 基于Kubernetes环境下的Prometheus高可用***及实现方法 Active CN112256401B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011186088.2A CN112256401B (zh) 2020-10-30 2020-10-30 基于Kubernetes环境下的Prometheus高可用***及实现方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011186088.2A CN112256401B (zh) 2020-10-30 2020-10-30 基于Kubernetes环境下的Prometheus高可用***及实现方法

Publications (2)

Publication Number Publication Date
CN112256401A CN112256401A (zh) 2021-01-22
CN112256401B true CN112256401B (zh) 2022-03-15

Family

ID=74268968

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011186088.2A Active CN112256401B (zh) 2020-10-30 2020-10-30 基于Kubernetes环境下的Prometheus高可用***及实现方法

Country Status (1)

Country Link
CN (1) CN112256401B (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112994935B (zh) * 2021-02-04 2022-06-17 烽火通信科技股份有限公司 prometheus管控方法、装置、设备及存储介质
CN112925612A (zh) * 2021-03-15 2021-06-08 浪潮软件科技有限公司 一种基于Kubernetes的监控服务静态配置管理方法
CN114598585A (zh) * 2022-03-07 2022-06-07 浪潮云信息技术股份公司 通过snmptrapd监控硬件的方法及***
CN115827393B (zh) * 2023-02-21 2023-10-20 德特赛维技术有限公司 一种服务器集群监控及告警***

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10528367B1 (en) * 2016-09-02 2020-01-07 Intuit Inc. Execution of workflows in distributed systems
CN111045901A (zh) * 2019-12-11 2020-04-21 东软集团股份有限公司 容器的监控方法、装置、存储介质和电子设备
CN111147596A (zh) * 2019-12-30 2020-05-12 ***通信集团江苏有限公司 Prometheus集群部署方法、装置、设备及介质
CN111176783A (zh) * 2019-11-20 2020-05-19 航天信息股份有限公司 容器治理平台的高可用方法、装置及电子设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10924398B2 (en) * 2018-09-25 2021-02-16 Ebay Inc. Time-series data monitoring with sharded server

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10528367B1 (en) * 2016-09-02 2020-01-07 Intuit Inc. Execution of workflows in distributed systems
CN111176783A (zh) * 2019-11-20 2020-05-19 航天信息股份有限公司 容器治理平台的高可用方法、装置及电子设备
CN111045901A (zh) * 2019-12-11 2020-04-21 东软集团股份有限公司 容器的监控方法、装置、存储介质和电子设备
CN111147596A (zh) * 2019-12-30 2020-05-12 ***通信集团江苏有限公司 Prometheus集群部署方法、装置、设备及介质

Also Published As

Publication number Publication date
CN112256401A (zh) 2021-01-22

Similar Documents

Publication Publication Date Title
CN112256401B (zh) 基于Kubernetes环境下的Prometheus高可用***及实现方法
CN108121782B (zh) 查询请求的分配方法、数据库中间件***以及电子设备
CN108804523B (zh) 数据同步方法、***及计算机可读存储介质
US10417103B2 (en) Fault-tolerant methods, systems and architectures for data storage, retrieval and distribution
CN112084258A (zh) 一种数据同步方法和装置
CN109145060B (zh) 数据处理方法及装置
CN112153133B (zh) 一种数据共享方法、设备以及介质
EP3818454B1 (en) Asynchronous cache coherency for mvcc based database systems
CN113094430B (zh) 一种数据处理方法、装置、设备以及存储介质
CN112015595B (zh) 主从数据库的切换方法、计算设备及存储介质
CN111352943A (zh) 实现数据一致性的方法和装置、服务器和终端
CN113360456A (zh) 数据归档方法、装置、设备以及存储介质
CN112000850B (zh) 进行数据处理的方法、装置、***及设备
CN106951443B (zh) 基于分布式***的副本同步的方法、设备和***
CN112187889A (zh) 一种数据同步方法、装置及存储介质
CN110554992B (zh) 一种分布式元数据路径管理方法、***、终端及存储介质
CN115004662A (zh) 数据同步方法、装置、数据存储***及计算机可读介质
CN113515574B (zh) 一种数据同步方法及装置
US10860580B2 (en) Information processing device, method, and medium
CN111399753A (zh) 写入图片的方法和装置
CN108376104B (zh) 节点调度方法及装置、计算机可读存储介质
CN112559568A (zh) 一种虚拟物品确定方法、装置及计算机可读存储介质
CN116893834B (zh) 负载更新方法、装置、***、电子设备及可读存储介质
CN112988905B (zh) 用于集群部署的节点内存同步方法及装置
CN110213314B (zh) 确定存储节点的方法、装置、服务器

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant