A method, apparatus and device for monitoring deployment

Abstract

The application relates to a monitoring deployment method, device and apparatus, which comprises the following steps: grouping to-be-monitored nodes according to the current Prometheus node quantity and the to-be-monitored node quantity, and assigning a Prometheus master service to each group; deploying at least one active Prometheus master service on each Prometheus node and configuring at least one Prometheus backup service for each Prometheus master service, wherein the Prometheus backup service is not on the same Prometheus node as the corresponding Prometheus master service; and starting the corresponding Prometheus backup service when the Prometheus master service cannot work. The application can solve the scheduling and balancing problems among multiple Prometheus services in a large-scale node device scenario.

Description

Technical Field

[0001] This invention relates to the field of monitoring deployment technology, and in particular to a monitoring deployment method, device, and apparatus based on Prometheus service. Background Technology

[0002] Currently, based on cloud computing platforms, more and more vendors not only have their own cloud products but also migrate their businesses to cloud platforms for easier management and maintenance, and to save costs. The ensuing challenge is how to monitor the nodes of a large-scale cloud computing platform. Commonly used monitoring platforms include the open-source Prometheus (an open-source system monitoring and alerting toolkit), which can then be configured with time-series databases and related software such as AlertManager to form a comprehensive monitoring and alerting solution.

[0003] Among related technologies, Prometheus is deployed as a single node, lacking reliability and unable to meet the monitoring reliability and performance requirements of large-scale node devices. Some deployments use clusters, but essentially only one Prometheus node works; if Prometheus fails, a new master node is selected, failing to address the scheduling and load balancing issues among multiple Prometheus services in large-scale node monitoring scenarios. Other technologies propose task distribution across different Prometheus nodes, but lack consideration for the reliability of the Prometheus nodes themselves and the balance of services, resulting in poor overall monitoring reliability when facing massive cloud platform nodes. Summary of the Invention

[0004] This invention provides a monitoring deployment method, device, and apparatus. It can solve the scheduling and load balancing problems among multiple Prometheus services in scenarios with large-scale node devices.

[0005] In a first aspect, embodiments of the present invention provide a monitoring deployment method, characterized in that it includes the following steps: Based on the current number of Prometheus nodes and the number of nodes to be monitored, the nodes to be monitored are grouped, and a Prometheus master service is assigned to each group; Deploy at least one active Prometheus master service on each Prometheus node and configure at least one Prometheus backup service for each Prometheus master service, wherein the Prometheus backup service and the corresponding Prometheus master service are not on the same Prometheus node; When the primary Prometheus service fails, its corresponding backup Prometheus service is started.

[0006] In some embodiments, the step of grouping the nodes to be monitored based on the current number of Prometheus nodes and the number of nodes to be monitored includes the following steps: The number of groups is determined based on the current number of Prometheus nodes; The nodes to be monitored are evenly distributed into each group; If the remainder after dividing the number of nodes to be monitored by the number of groups is not zero, then the remaining nodes that cannot be evenly distributed will be placed into different groups in sequence.

[0007] In some embodiments, the step of deploying at least one active Prometheus master service on each Prometheus node and configuring at least one Prometheus backup service for each Prometheus master service includes the following steps: Fault tolerance is determined based on the minimum number of Prometheus nodes required to ensure that all Prometheus services function properly. Configure a corresponding Prometheus backup service for each Prometheus primary service based on the fault tolerance and the current total number of Prometheus nodes; Configure all Prometheus backup services corresponding to a Prometheus master service on different Prometheus nodes.

[0008] In some embodiments, starting the corresponding Prometheus backup service when the primary Prometheus service fails includes the following steps: If the Prometheus primary service is configured with two or more Prometheus backup services, then the node with the fewest active Prometheus services among the current Prometheus nodes is identified, and the Prometheus backup service corresponding to the Prometheus primary service on that node is started.

[0009] In some embodiments, starting the corresponding Prometheus backup service when the primary Prometheus service fails includes the following steps: If the Prometheus primary service is configured with two or more Prometheus backup services, and the number of Prometheus services in operation on all Prometheus nodes is the same, then the Prometheus node with the lowest load is selected and the Prometheus backup service corresponding to the Prometheus primary service is started on that node.

[0010] In some embodiments, after a Prometheus node that failed to function as the primary Prometheus service recovers, the following steps are also included: Enables the Prometheus master service on the restored Prometheus node to resume operation.

[0011] In some embodiments, the steps further include: When the current number of Prometheus nodes changes, the nodes to be monitored are grouped according to the changed number of Prometheus nodes and the number of nodes to be monitored, and a Prometheus master service is assigned to each group.

[0012] Secondly, embodiments of the present invention also provide an apparatus, characterized in that the apparatus includes: at least one processor; and a memory coupled to the at least one processor, the memory containing instructions stored therein, the instructions being loaded and executed by the processor to implement any method.

[0013] Thirdly, embodiments of the present invention also provide a monitoring and deployment device based on the Prometheus service, characterized in that it includes a node grouping module, which is used for: Based on the current number of Prometheus nodes and the number of nodes to be monitored, the nodes to be monitored are grouped, and a Prometheus master service is assigned to each group; Deploy at least one active Prometheus master service on each Prometheus node and configure at least one Prometheus backup service for each Prometheus master service, wherein the Prometheus backup service and the corresponding Prometheus master service are not on the same Prometheus node; The Prometheus service load balancing module is used for: When the primary Prometheus service fails, its corresponding backup Prometheus service is started.

[0014] In some embodiments, the node grouping module is further configured to: The number of groups is determined based on the current number of Prometheus nodes; The nodes to be monitored are evenly distributed into each group; If the remainder after dividing the number of nodes to be monitored by the number of groups is not zero, then the remaining nodes that cannot be evenly distributed will be placed into different groups in sequence.

[0015] This invention provides a monitoring deployment method, device, and apparatus based on Prometheus services. Monitoring metrics (all monitored objects) are grouped and monitored at the node level, ensuring that each Prometheus service handles different monitoring tasks. This solves the scheduling and load balancing problems among multiple Prometheus services in scenarios with large-scale node devices. It also considers the reliability of the Prometheus nodes themselves and the balance of services provided. For massive cloud platform nodes, this effectively improves the overall reliability of monitoring. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A monitoring deployment method provided in this embodiment of the invention; Figure 2 A monitoring deployment device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a scheduling component for implementing a monitoring deployment method, provided in an embodiment of the present invention. Figure 4 This is a schematic diagram illustrating the monitoring deployment based on Prometheus service provided in an embodiment of the present invention. Figure 5 This is a schematic diagram of the expanded monitoring deployment based on the Prometheus service provided in an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] like Figure 1 As shown, this embodiment of the invention provides a monitoring deployment method, which includes the following steps: S100: Based on the current number of Prometheus nodes and the number of nodes to be monitored, the nodes to be monitored are grouped into groups, and a Prometheus master service is assigned to each group; S200: Deploy at least one active Prometheus primary service on each Prometheus node and configure at least one Prometheus backup service for each Prometheus primary service, wherein the Prometheus backup service and the corresponding Prometheus primary service are not on the same Prometheus node; S300: When the primary Prometheus service fails, start the corresponding backup Prometheus service.

[0020] It should be noted that a monitoring agent client is typically installed to obtain information about the nodes to be monitored. This agent client can collect monitoring data from the nodes and report node data, such as CPU, memory, and disk usage. The Prometheus service deployed on the Prometheus node is responsible for collecting monitoring data from each node to be monitored. An agent client can be deployed on the Prometheus node to execute instructions issued by the scheduler. There can be one or more Prometheus services on a Prometheus node.

[0021] It is understood that, in this embodiment of the invention, by grouping monitoring nodes (monitored objects) and assigning at least one Prometheus master service to each group, multiple Prometheus master services can be enabled to work simultaneously when monitoring all monitored objects, thereby improving the throughput in scenarios with large-scale node devices. Simultaneously, to ensure high reliability, for each Prometheus master service, at least one Prometheus backup service (generally inactive) is configured, and these backup services are located on different Prometheus nodes. This ensures that when the currently running Prometheus service malfunctions or fails, the system can promptly switch to the node where the backup service resides (at which point the corresponding backup service will be activated).

[0022] This invention groupes monitoring metrics (all monitored objects) according to node granularity for monitoring, ensuring that each Prometheus service handles different monitoring tasks. This solves the scheduling and balancing problem among multiple Prometheus services in scenarios with large-scale node devices. It also considers the reliability of the Prometheus nodes themselves and the balance of services. Facing a massive number of nodes on a cloud platform, it can effectively improve the overall reliability of monitoring.

[0023] In some embodiments, S100 includes the step of: S110: Determine the number of groups based on the current number of Prometheus nodes; S120: Distribute the nodes to be monitored evenly into each group; S130: If the remainder after dividing the number of nodes to be monitored by the number of groups is not zero, then the remaining nodes to be monitored that cannot be evenly distributed are placed into different groups in sequence.

[0024] In some embodiments, S200 further includes the step of: S210: Determine the fault tolerance based on the minimum number of Prometheus nodes required to ensure that all Prometheus services function properly; S220: Configure a corresponding Prometheus backup service for each Prometheus primary service based on the fault tolerance and the current total number of Prometheus nodes; S230: Configure all Prometheus backup services corresponding to a Prometheus primary service on different Prometheus nodes.

[0025] Understandably, fault tolerance can be set manually. If the fault tolerance (represented by N) is set to N=1, it means that at least one node out of all Prometheus nodes needs to be normal to ensure that all Prometheus services can function properly.

[0026] Preferably, if the total number of Prometheus nodes (represented by T) in S220 is 3, then the number of Prometheus backup services can be calculated by T(3)-N(1), and the number of Prometheus backup services can be configured to be 2.

[0027] In some embodiments, in S300, if the Prometheus primary service is configured with two or more Prometheus backup services, the node with the fewest currently active Prometheus services is identified, and the Prometheus backup service corresponding to the Prometheus primary service on that node is started.

[0028] In some embodiments, in S300, if the Prometheus primary service is configured with two or more Prometheus backup services, and the number of Prometheus services in working state on all Prometheus nodes is the same, then the Prometheus node with the lowest load is selected and the Prometheus backup service corresponding to the Prometheus primary service on that node is started.

[0029] In some embodiments, when the Prometheus primary service on a Prometheus node becomes unusable due to multiple node restarts or other anomalies, a Prometheus node may have multiple Prometheus services (its own primary Prometheus service and other nodes' backup Prometheus services) working simultaneously. In such cases, automatic load balancing can be performed based on the number of Prometheus services on each Prometheus node. Automatic load balancing includes switching the primary Prometheus service on a node with more than a preset threshold to the node where its corresponding backup Prometheus service is located. In some embodiments, when a Prometheus node whose primary Prometheus service was down recovers, the primary Prometheus service on that node resumes operation. This further ensures balanced Prometheus service across all Prometheus nodes.

[0030] In some embodiments, when the current number of Prometheus nodes changes, the nodes to be monitored are grouped according to the changed number of Prometheus nodes and the number of nodes to be monitored, and a Prometheus master service is assigned to each group.

[0031] Understandably, in this embodiment, the load on the nodes can be reduced and monitoring performance improved by scaling up the Prometheus nodes (increasing the number of nodes). The pressure on each Prometheus service node can be balanced by regrouping them.

[0032] like Figure 2 As shown, based on the same inventive concept, this embodiment of the invention also provides a monitoring and deployment device based on the Prometheus service, which includes, The node grouping module is used for: Based on the current number of Prometheus nodes and the number of nodes to be monitored, the nodes to be monitored are grouped, and a Prometheus master service is assigned to each group; Deploy at least one active Prometheus master service on each Prometheus node and configure at least one Prometheus backup service for each Prometheus master service, wherein the Prometheus backup service and the corresponding Prometheus master service are not on the same Prometheus node; The Prometheus service load balancing module is used for: When the primary Prometheus service fails, its corresponding backup Prometheus service is started.

[0033] In some embodiments, the node grouping module is also used for: The number of groups is determined based on the current number of Prometheus nodes; The nodes to be monitored are evenly distributed into each group; If the remainder after dividing the number of nodes to be monitored by the number of groups is not zero, then the remaining nodes that cannot be evenly distributed will be placed into different groups in sequence.

[0034] In some embodiments, the node grouping module is further configured to: Fault tolerance is determined based on the minimum number of Prometheus nodes required to ensure that all Prometheus services function properly. Configure a corresponding Prometheus backup service for each Prometheus primary service based on the fault tolerance and the current total number of Prometheus nodes; Configure all Prometheus backup services corresponding to a Prometheus master service on different Prometheus nodes.

[0035] In some embodiments, the Prometheus service auto-balancing module is further configured to: If the Prometheus primary service is configured with two or more Prometheus backup services, then the node with the fewest active Prometheus services among the current Prometheus nodes is identified, and the Prometheus backup service corresponding to the Prometheus primary service on that node is started.

[0036] In some embodiments, the Prometheus service auto-balancing module is further configured to: If the Prometheus primary service is configured with two or more Prometheus backup services, and the number of Prometheus services in operation on all Prometheus nodes is the same, then the Prometheus node with the lowest load is selected and the Prometheus backup service corresponding to the Prometheus primary service is started on that node.

[0037] In some embodiments, when a Prometheus node that was unable to function as the primary Prometheus service recovers, the Prometheus service auto-balancing module is also used to restore the primary Prometheus service on the recovered Prometheus node.

[0038] In some embodiments, the node grouping module is further configured to group the nodes to be monitored according to the changed number of Prometheus nodes and the number of nodes to be monitored when the current number of Prometheus nodes changes, and to assign a Prometheus master service to each group.

[0039] like Figure 3 As shown, in a specific embodiment, the monitoring deployment method is implemented through a scheduling component. The scheduling component includes four functional modules: a Prometheus service detection module, a node grouping module, a Prometheus service automatic load balancing module, and a scaling module.

[0040] The node grouping module is used to group a large number of nodes to be monitored according to the current number of Prometheus nodes and the number of nodes to be monitored. At least one active Prometheus master service is deployed on each Prometheus node and at least one Prometheus backup service is configured for each Prometheus master service. The Prometheus backup service and the corresponding Prometheus master service are not on the same Prometheus node.

[0041] The Prometheus service auto-balancing module is used to start the corresponding Prometheus backup service when the primary Prometheus service fails. If the primary Prometheus service is configured with two or more backup services, it finds the node with the fewest active Prometheus services and starts the backup service corresponding to the primary Prometheus service on that node. If the primary Prometheus service is configured with two or more backup services, and the number of active Prometheus services is the same on all current Prometheus nodes, it selects the Prometheus node with the lowest load and starts the backup service corresponding to the primary Prometheus service on that node. Furthermore, when the primary Prometheus service recovers, it restores the primary Prometheus service on the recovered node.

[0042] When the scheduling component detects a newly added Prometheus node, it notifies the scaling module. Upon receiving the message, the scaling module instructs the node grouping module to reconfigure the grouping and Prometheus node configurations based on the increased number of nodes after scaling.

[0043] The Prometheus service monitoring module periodically monitors the status and distribution of Prometheus nodes and the Prometheus service, saving the real-time monitoring data and providing it to other modules. Understandably, all monitoring data is stored in a time-series database, which can use open-source software such as VictoriaMetrics.

[0044] like Figure 4As shown, in a specific embodiment, node1…node12 represents the node information to be monitored, and this information will expand as business grows. The nodes where the Prometheus service resides are called Prometheus nodes. Currently, we'll use three Prometheus nodes as an example; the number of Prometheus nodes can be increased or decreased depending on the scale of the monitored nodes. Each Prometheus node needs to deploy an active Prometheus service, and these active Prometheus services operate simultaneously. Each active Prometheus service is configured with two backup Prometheus services. These backup services are normally disabled and reside on different Prometheus nodes than the active Prometheus service. For example, active Prometheus1 resides on Prometheus node 1, and has backup nodes on Prometheus nodes 2 and 3, both of which are disabled. The number of backup services configured for each Prometheus service can be determined based on the fault tolerance N of the Prometheus nodes, where fault tolerance N represents the number of Prometheus nodes required to ensure that all Prometheus services function correctly.

[0045] like Figure 4 As shown, there are 3 Prometheus nodes and 12 nodes to be monitored. The Prometheus node information (such as IP addresses) has been registered with the scheduler. The Prometheus service detection module in the scheduling component detects the Prometheus services on each Prometheus node based on the registered Prometheus node information, identifying which are the active primary Prometheus services and which are the backup Prometheus services. It also obtains which Prometheus nodes host the active primary Prometheus services and which host the backup Prometheus services. After detecting this information, the Prometheus service detection module in the scheduling component stores this information.

[0046] After obtaining information about all Prometheus services through the Prometheus service detection module, the scheduling component also registers the IP information of the nodes to be monitored with the scheduler and saves the information of the nodes to be monitored. Nodes to be monitored can register with the scheduler by actively reporting or by registering manually.

[0047] The Prometheus service monitoring module periodically checks and obtains the status of the Prometheus service and the Prometheus nodes. The status of the Prometheus nodes is "active" or "inactive". "Inactive" indicates that the Prometheus node is abnormal and cannot function properly.

[0048] The node grouping module of the scheduling component groups nodes based on the saved information about the Prometheus service and the nodes to be monitored. For example... Figure 4 As shown, each group contains 4 nodes to be monitored. When grouping, if all nodes cannot be evenly distributed, the remaining nodes (after dividing the number of nodes by the number of groups) can be added based on the Prometheus node usage load. Nodes are preferentially added to groups corresponding to nodes with lower Prometheus load. Nodes within each group can also be scheduled using a scheduling component based on the real-time usage load of the Prometheus nodes.

[0049] After grouping, the scheduling component saves the group information and distributes it to the Prometheus nodes. This allows the Prometheus nodes to configure the monitoring node information in the Prometheus service's configuration file, including all active and standby Prometheus services. This enables the Prometheus service to monitor the nodes within the corresponding group. Therefore, three Prometheus nodes can simultaneously monitor three groups of nodes, improving monitoring efficiency and performance. Specifically, nodes in Group 1 are assigned to the Prometheus1 service for monitoring, nodes in Group 2 are assigned to the Prometheus2 service, and nodes in Group 3 are assigned to the Prometheus3 service.

[0050] If Prometheus node 1 fails, the Prometheus service load balancer will detect that the node's status is "inactive," meaning the Prometheus1 service on that node is no longer functioning correctly. The scheduler will select an available Prometheus node based on the recorded backup node information for the Prometheus1 service. Priority will be given to nodes with the fewest active Prometheus services. If all nodes have the same number of active Prometheus services, the node with the lowest load will be selected. If Prometheus node 2 is selected, the Prometheus1 service on Prometheus node 2 will be restarted and continue operating. Therefore, even if some Prometheus nodes fail, all Prometheus services can still function normally.

[0051] If Prometheus node 1 fails and is subsequently repaired, and the scheduling component detects that both the Prometheus 1 backup service and the Prometheus 2 primary service are on Prometheus node 2, it will switch the Prometheus 1 backup service back to Prometheus node 1. This will reduce the load on Prometheus node 2. This is because after Prometheus node 1 recovers, only the operating system recovers; the Prometheus 1 primary service does not automatically recover and requires the scheduler to issue commands to resume operation.

[0052] like Figure 5 As shown, if a Prometheus node 4 is added, after receiving the notification to add Prometheus node 4, the scaling module of the scheduling component will, based on the pre-set fault tolerance N==1 for the Prometheus nodes, deploy Prometheus1 to Prometheus3 backup services on Prometheus node 4, and deploy Prometheus4 backup service on Prometheus nodes 1 to Prometheus node 3. Since a Prometheus node has been added, the scaling module will also notify the node grouping module to regroup. The number of nodes to be monitored remains 12, the number of groups becomes 4, and the number of nodes to be monitored in each group becomes 3. The scaling module will iterate through the original groups, remove one node from each group, and then place it into Group4 (node4, node8, node12). This forms a new node group. Then the node grouping module will assign Group4 to the Prometheus4 service for monitoring, and at the same time update the configuration files of Prometheus nodes 1 to 4 to the new group information, including the active Prometheus service and the backup Prometheus service.

[0053] Based on the same inventive concept, embodiments of the present invention also provide an apparatus comprising: at least one processor; and a memory coupled to the at least one processor, the memory containing instructions stored therein, the instructions being loaded and executed by the processor to implement the method as described in any one of the method embodiments.

[0054] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer-readable storage media (or non-transitory media) and communication media (or transient media).

[0055] It should be noted that in this invention, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0056] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A monitoring deployment method, characterized in that, It includes the following steps: The nodes to be monitored are grouped according to the current number of Prometheus nodes and the number of nodes to be monitored, and a Prometheus master service is assigned to each group. When the current number of Prometheus nodes changes, the nodes to be monitored are grouped according to the changed number of Prometheus nodes and the number of nodes to be monitored, and a Prometheus master service is assigned to each group. Deploy at least one active Prometheus master service on each Prometheus node and configure at least one Prometheus backup service for each Prometheus master service, wherein the Prometheus backup service and the corresponding Prometheus master service are not on the same Prometheus node; When the primary Prometheus service fails, its corresponding backup Prometheus service is started.

2. The monitoring deployment method as described in claim 1, characterized in that, The process of grouping the nodes to be monitored based on the current number of Prometheus nodes and the number of nodes to be monitored includes the following steps: The number of groups is determined based on the current number of Prometheus nodes; The nodes to be monitored are evenly distributed into each group; If the remainder after dividing the number of nodes to be monitored by the number of groups is not zero, then the remaining nodes that cannot be evenly distributed will be placed into different groups in sequence.

3. The monitoring deployment method as described in claim 1, characterized in that, The steps of deploying at least one active Prometheus master service on each Prometheus node and configuring at least one Prometheus backup service on each Prometheus master service include: Fault tolerance is determined based on the minimum number of Prometheus nodes required to ensure that all Prometheus services function properly. Configure a corresponding Prometheus backup service for each Prometheus primary service based on the fault tolerance and the current total number of Prometheus nodes; Configure all Prometheus backup services corresponding to a Prometheus master service on different Prometheus nodes.

4. The monitoring deployment method as described in claim 1, characterized in that, The process of starting the corresponding Prometheus backup service when the primary Prometheus service fails includes the following steps: If the Prometheus primary service is configured with two or more Prometheus backup services, then the node with the fewest active Prometheus services among the current Prometheus nodes is identified, and the Prometheus backup service corresponding to the Prometheus primary service on that node is started.

5. The monitoring deployment method as described in claim 4, characterized in that, The process of starting the corresponding Prometheus backup service when the primary Prometheus service fails includes the following steps: If the Prometheus primary service is configured with two or more Prometheus backup services, and the number of Prometheus services in operation on all Prometheus nodes is the same, then the Prometheus node with the lowest load is selected and the Prometheus backup service corresponding to the Prometheus primary service is started on that node.

6. The monitoring deployment method as described in claim 1, characterized in that, Once the Prometheus node that was unable to function as the primary Prometheus service is restored to normal operation, the following steps are also included: Enables the Prometheus master service on the restored Prometheus node to resume operation.

7. A device, characterized in that, The device includes: at least one processor; and a memory coupled to the at least one processor, the memory containing instructions stored therein, the instructions being loaded and executed by the processor to implement the method as described in any one of claims 1-6.

8. A monitoring deployment device based on Prometheus service, characterized in that, It includes a node grouping module, which is used for: The nodes to be monitored are grouped according to the current number of Prometheus nodes and the number of nodes to be monitored, and a Prometheus master service is assigned to each group. When the current number of Prometheus nodes changes, the nodes to be monitored are grouped according to the changed number of Prometheus nodes and the number of nodes to be monitored, and a Prometheus master service is assigned to each group. Deploy at least one active Prometheus master service on each Prometheus node and configure at least one Prometheus backup service for each Prometheus master service, wherein the Prometheus backup service and the corresponding Prometheus master service are not on the same Prometheus node; The Prometheus service load balancing module is used for: When the primary Prometheus service fails, its corresponding backup Prometheus service is started.

9. A monitoring deployment device based on Prometheus service as described in claim 8, characterized in that, The node grouping module is also used for: The number of groups is determined based on the current number of Prometheus nodes; The nodes to be monitored are evenly distributed into each group; If the remainder after dividing the number of nodes to be monitored by the number of groups is not zero, then the remaining nodes that cannot be evenly distributed will be placed into different groups in sequence.

Images