Containerization deployment method and system for cluster

Abstract

The invention belongs to the technical field of monitoring deployment, and particularly relates to a containerization deployment method and system of a cluster, and the method comprises the steps: carrying out the cluster initialization of a restarted alarm calculation node, obtaining all current alarm states of the cluster after the cluster initialization is completed, and carrying out the merging, reading and loading all current alarm rules of the cluster; wherein the alarm state is an execution state of one alarm rule in a preset time period; using a consistent Hash algorithm to configure an alarm rule operated by the restarted alarm computing node; and when the restarted alarm computing node begins to periodically compute the configured alarm rule, judging whether data replay is needed or not according to the current computing time of the alarm rule and the last execution time of the alarm rule in the combined alarm state so as to supplement the data missing in the short time of the restarted alarm computing node.

Description

Technical Field

[0001] The present invention belongs to the technical field of monitoring deployment, and in particular relates to a containerized deployment method and system for a cluster. Background Art

[0002] At present, the existing monitoring and alarm systems have integrated simple alarm capabilities. Users can import alarm rules into the system, and the monitoring and alarm system will perform periodic monitoring based on the imported alarm rules and execute alarms when the trigger conditions are met.

[0003] However, when the monitoring level increases, there are stability risks because the alarm system uses a single-node deployment method, and containerized deployment cannot be achieved. If a single node is restarted, it will cause short-term alarm loss or global alarm jitter. Summary of the invention

[0004] In view of the shortcomings of the prior art described above, the purpose of the present invention is to propose a containerized deployment solution for a cluster, which can avoid the jitter caused to the monitoring alarm system when the node crashes or restarts, and prevent data loss, thereby ensuring the reliable and stable continuous operation of the monitoring alarm system.

[0005] To achieve the above-mentioned purpose and other related purposes, the present invention provides a containerized deployment method of a cluster, which is applied to a monitoring alarm system, wherein the monitoring alarm system includes at least one cluster, each cluster includes at least one alarm computing node, which is used to periodically calculate preset alarm rules so as to send a notification to an alarm management module when the triggering condition of the alarm rule is met. The method includes: performing cluster initialization on the restarted alarm computing node, and after the cluster initialization is completed, obtaining all current alarm states of the cluster for merging, and reading and loading all current alarm rules of the cluster; wherein the alarm state is the execution state of an alarm rule within a preset time period; configuring the alarm rules run by the restarted alarm computing node using a consistent hashing algorithm; when the restarted alarm computing node starts to periodically calculate the configured alarm rules, judging whether data replay is needed based on the current calculation time of the alarm rule and the last execution time of the alarm rule in the merged alarm state, so as to make up for the data missing from the restarted alarm computing node in a short time.

[0006] According to a specific embodiment of the present invention, a cluster is initialized for the restarted alarm computing node, and after the cluster initialization is completed, all current alarm states of the cluster are obtained for merging, and the steps of reading and loading all current alarm rules of the cluster include: detecting whether there are other alarm computing nodes: if so, joining the corresponding cluster, and sending an online notification to all alarm computing nodes in the cluster; if not, creating a cluster, waiting for the addition of alarm rules and other alarm computing nodes to join; when the restarted alarm computing node joins the cluster, obtaining all alarm states from other alarm computing nodes and merging them; when the restarted alarm computing node obtains the alarm state, reading and loading all alarm rules from the database.

[0007] According to a specific embodiment of the present invention, the step of configuring the alarm rules run by the restarted alarm computing node using a consistent hashing algorithm includes: for each of all alarm rules, determining whether the alarm rule should be run on the restarted alarm computing node according to the consistent hashing algorithm: if not, prohibiting the restarted alarm computing node from periodically calculating the alarm rule.

[0008] According to a specific embodiment of the present invention, the step of judging whether data replay is needed based on the current calculation time of the alarm rule and the last execution time of the alarm rule in the merged alarm state to make up for the missing data of the restarted alarm calculation node in a short time includes: if the difference between the last execution time and the current calculation time is greater than the preset timeout time, no replay is performed; if the difference between the last execution time and the current calculation time is less than the preset operating cycle of the alarm calculation node, no replay is performed; if the difference between the last execution time and the current calculation time is greater than the preset operating cycle of the alarm calculation node and less than the preset replayable time of the alarm calculation node, replay is performed; wherein, after the alarm calculation node completes the replay, it periodically calculates the alarm rule to update the local alarm state.

[0009] According to a specific embodiment of the present invention, the step of replaying data by the alarm computing node includes: starting from the last execution time, for each time period, calling the corresponding data from the cached data for replay, and calculating the alarm rules to determine whether the alarm rules are triggered until the current calculation time.

[0010] According to a specific embodiment of the present invention, each alarm computing node in the cluster is used to manage and maintain all current alarm states of the cluster, and regularly pushes the stored alarm states to other alarm computing nodes in the cluster in TCP form, and / or regularly pulls the alarm states from other alarm computing nodes in TCP form.

[0011] According to a specific embodiment of the present invention, each alarm computing node in the cluster sends the stored alarm status to other alarm computing nodes in the cluster in the form of UDP after the alarm status is updated.

[0012] According to a specific embodiment of the present invention, any alarm computing node in the cluster only stores the alarm status of the latest time of the same alarm rule; wherein, after the alarm computing node obtains the alarm status from other alarm computing nodes, it determines whether it has stored the alarm status of the alarm rule: if not, the alarm status is directly merged; if yes, the alarm status and the alarm status stored by itself with the latest time are retained, and the other is cleared.

[0013] According to a specific embodiment of the present invention, each alarm computing node uses a rumor protocol to synchronously share the alarm status.

[0014] A containerized deployment system for a cluster is applied to a monitoring alarm system. The monitoring alarm system includes at least one cluster, each of which includes at least one alarm computing node for periodically computing preset alarm rules so as to send a notification to an alarm management module when the triggering condition of the alarm rule is met. The system includes: a cluster initialization module for performing cluster initialization on the restarted alarm computing node, and obtaining all current alarm states of the cluster for merging after the cluster initialization is completed, and reading and loading all current alarm rules of the cluster; wherein the alarm state is the execution state of an alarm rule within a preset time period; a load balancing module for configuring the alarm rules run by the restarted alarm computing node using a consistent hashing algorithm; a data replay module for judging whether data replay is required based on the current calculation time of the alarm rule and the last execution time of the alarm rule in the merged alarm state when the restarted alarm computing node starts to periodically calculate the configured alarm rule, so as to make up for the data missing from the restarted alarm computing node in a short time. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 A schematic diagram of a specific embodiment of a cluster container deployment method provided by the present invention; Figure 2 A schematic diagram of a flow chart of another specific embodiment of a cluster container deployment method provided by the present invention; Figure 3 A schematic diagram of a specific embodiment of short-term data loss provided by the present invention; Figure 4 The present invention provides a schematic diagram of a cluster container deployment system according to a specific embodiment of the present invention. DETAILED DESCRIPTION

[0016] In order to facilitate understanding of the present application, the present application will be described more fully below with reference to the relevant drawings. Embodiments of the present application are provided in the drawings. However, the present application can be implemented in many different forms and is not limited to the embodiments described herein. On the contrary, the purpose of providing these embodiments is to make the disclosure of the present application more thorough and comprehensive.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application.

[0018] The following describes the embodiments of the present invention by specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0019] In the following description, numerous details are discussed to provide a more thorough explanation of the embodiments of the present invention. However, it is obvious to those skilled in the art that the embodiments of the present invention can be implemented without these specific details. In other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in detail to avoid making the embodiments of the present invention difficult to understand.

[0020] Example 1 See also Figure 1 A cluster container deployment method is shown, which is applied to a monitoring alarm system, and includes: Step S100, performing cluster initialization for the restarted alarm computing node, and after the cluster initialization is completed, obtaining all current alarm states of the cluster for merging, and reading and loading all current alarm rules of the cluster; wherein the alarm state is the execution state of an alarm rule within a preset time period.

[0021] It should be noted that in order to cope with complex scenarios with a large monitoring scale, the monitoring alarm system can be composed of multiple clusters, and each cluster includes at least one alarm computing node, which is used to periodically calculate the alarm rules to detect whether the alarm rules are triggered and send notifications to the alarm management module when the alarm rules are triggered.

[0022] The alarm status is the execution context of the alarm rule in a timeline, including: last_exec_at (last execution time), last_updated_at (last update time of the rule), firing (firing), resolved (recovered), pending (pending), happened_at (start time), end_at (end time), etc.

[0023] It can be understood that the last execution time refers to the time when the alarm rule was last triggered, the last update time of the rule refers to the time when the alarm rule was last readjusted, triggering, restored, and waiting to be triggered are all the execution results corresponding to the alarm rule, and the start time and end time indicate the start and end times of the timeline.

[0024] It can also be understood that different alarm computing nodes can be configured to calculate the same alarm rule to detect whether it is triggered. Correspondingly, different alarm computing nodes may save alarm status of different time versions. For example, if one of the alarm computing nodes abnormally crashes at a certain moment, the real-time nature of the alarm status it saves will lag behind that saved by another alarm computing node.

[0025] It should also be added that each alarm computing node in the cluster can be used to manage and maintain all alarm states of the current cluster. When any alarm computing node runs the alarm rule calculation regularly, it will propagate the alarm state corresponding to the alarm rule to other alarm computing nodes, and other alarm computing nodes will merge the alarm state with their own stored data after receiving it.

[0026] It can be understood here that the alarm computing node will store the alarm status of different alarm rules, and for the alarm status corresponding to the same alarm rule, the alarm computing node will only save the one with the best timeliness. For example, in different alarm statuses of the same alarm rule, the execution time of the alarm rule in one alarm status is earlier than the execution time of the alarm rule in another alarm status, then the alarm computing node will only save the latter and discard the former. Similarly, if the alarm computing node saves multiple alarm statuses, only the alarm status with the latest time will be retained. Therefore, when the alarm computing node merges the received alarm status, it will first determine whether it has stored the alarm status of the alarm rule. If the alarm status of the alarm rule has not been stored before, then the alarm status can be directly merged. However, if it has stored the alarm status of the alarm rule itself and obtains another alarm status of the alarm rule through other means, then it is necessary to identify the timeliness of the two alarm statuses to determine which one to retain, that is, to retain the alarm status with the latest time.

[0027] Specifically, in actual applications, an alarm computing node periodically runs the calculation of an alarm rule to detect whether it is triggered, and sends the corresponding detection result, that is, the alarm status of the alarm rule, to other alarm computing nodes to synchronously update the status of the alarm rule. In addition, since the alarm computing node needs to send synchronously every time the alarm status is updated, the execution frequency of this sending method is relatively high. Therefore, the alarm computing node can send data in the form of UDP (User Datagram Protocol) and merge the data into the MTU (Maximum Transmission Unit) size as much as possible for sending. In addition, since each alarm computing node will store the alarm status of all alarm rules, it will be regularly pushed to other alarm computing nodes in batches, or pulled from other alarm computing nodes in batches. In addition, since the execution frequency of this sending method is relatively low, the alarm computing node can send data in the form of TCP (Transmission Control Protocol).

[0028] In one embodiment, different alarm computing nodes may use a gossip protocol to synchronously update the alarm status of the alarm rule according to the above method.

[0029] Based on the above content, when an alarm computing node abnormally crashes, data loss occurs, so it needs to be redeployed after restart. In this regard, for the restarted alarm computing node, the cluster needs to be initialized first, that is, to detect whether there are other alarm computing nodes. If so, try to connect to other alarm computing nodes in the current cluster to join the cluster, and after joining, send the online notification to each alarm computing node in the cluster synchronously. Of course, if there are no other alarm computing nodes, it means that the cluster initialization has failed, and the cluster is created alone, and the cluster size is set to 1, waiting to add the corresponding alarm rules and other alarm computing nodes to join.

[0030] For the alarm computing node that has successfully initialized the cluster, it can obtain all the alarm status from other alarm computing nodes and merge them to start synchronizing data. In addition, since the restarted alarm computing node will obtain the alarm status from different alarm computing nodes, it will obtain the alarm status of different time versions of the same alarm rule. According to the above method, the newer version, that is, the latest alarm status, is retained, and the expired alarm status is discarded.

[0031] At the same time, after synchronizing the alarm status, the restarted alarm calculation node will read all the alarm rules from the database or file and load them to import the alarm rules and start running the calculation.

[0032] Step S200: Use a consistent hashing algorithm to configure the alarm rules executed by the restarted alarm computing node.

[0033] It should be noted here that the alarm computing node restarted based on the above steps needs to read and load all the rules. However, in fact, each alarm computing node is not used to calculate all the alarm rules. It is only responsible for the operation and calculation of some alarm rules. All alarm computing nodes in the cluster work together to maintain the query monitoring of all alarm rules. Therefore, for each alarm rule loaded by the restarted alarm computing node, the consistent hash algorithm is used to determine whether the alarm rule should be run on the alarm computing node. For example, if a certain alarm rule has been redundantly run and calculated by one or more other alarm computing nodes, other alarm computing nodes are no longer needed to be responsible. In this regard, when the hash algorithm is used to determine that the alarm rule does not meet expectations, that is, it should not be run on the restarted alarm computing node, the alarm computing node is prohibited from performing the corresponding action.

[0034] It should also be added that, based on the load balancing strategy, when the alarm computing nodes in the cluster are online or offline, that is, when they are down or restarted, a large number of alarm rules will be redirected, causing unnecessary jitter. However, the use of a consistent hash algorithm on each alarm computing node can achieve a better balancing effect and avoid jitter. When an alarm computing node is down and removed from the cluster, or restarted and added to the cluster, the use of a consistent hash algorithm will only affect the node's adjacent successor nodes on the hash ring, and will not cause jitter to other nodes in the cluster. Therefore, the consistent hash algorithm can not only reasonably configure the alarm rules running on the alarm computing node when it is restarted and online, but also distribute the alarm rules running on it to other alarm computing nodes when it is down and offline, thereby ensuring the stable operation of the entire monitoring alarm system.

[0035] Step S300, when the restarted alarm calculation node starts to periodically calculate the configured alarm rules, it is determined whether data replay is needed based on the current calculation time of the alarm rule and the last execution time of the alarm rule in the merged alarm status to make up for the data that is missing in the restarted alarm calculation node in a short period of time.

[0036] Based on the above steps S100 and S200, the redeployment of the restarted alarm computing node has been basically completed. Furthermore, considering that in various scenarios such as system release, pod migration, storage jitter, etc., the relevant data of the alarm computing node running the calculation alarm rules may be temporarily missing, and it is necessary to supplement its own data. For example, Figure 3As shown in the figure, assuming that for a certain alarm rule, the alarm calculation node runs the calculation regularly every 30 seconds. However, after the alarm calculation node crashes and restarts, the migration of the alarm rule is triggered, and the data of the three time points in the middle are omitted, which easily leads to data jitter and loss.

[0037] Therefore, after reconfiguring the alarm rules using the hash algorithm, it is necessary to identify the alarm rules currently running and calculating on the restarted alarm computing node. Specifically, it is determined whether data replay is required based on the current calculation time of an alarm rule and the last execution time of the alarm rule in the alarm state previously merged by the alarm computing node. In this regard, if the last execution time is too long, that is, the difference between the last execution time and the current calculation time is greater than the preset timeout time, then there is no need to replay the data. It can be understood here that since the data has been missing for a long time, the significance of data completion is not great, and there is no need to replay the data accordingly. If the difference between the last execution time and the current calculation time is less than the preset operation cycle of the alarm computing node, it can be seen that the data missing does not exceed one cycle of the alarm computing node running and calculating the alarm rule, and there is no need to replay it, and it is enough to wait for the next operation to calculate the alarm rule. If the difference between the last execution time and the current calculation time is greater than the preset operation cycle of the alarm computing node, and less than the preset replayable time of the alarm computing node, then replay can be performed to make up for the short-term missing data.

[0038] During replay, starting from the last execution time of the alarm rule, for each missing time period, the data corresponding to the missing time period is called from the cached data for replay, and the calculation alarm rule is run during data replay to detect whether the alarm rule is triggered, thereby completing the data filling of the alarm calculation node until the current calculation time is replayed, and the alarm status corresponding to the alarm rule in the missing time can be obtained. It should also be added here that the expired alarm status can be shielded during the data replay process to avoid invalid noise affecting data replay.

[0039] After the data replay is completed, the alarm computing node can run the calculation normally, and after each calculation, the corresponding result will be updated in the locally stored alarm status. At the same time, the alarm status will be stored in the buffer to be merged into the MTU size and sent to other alarm computing nodes in the cluster in the form of UDP.

[0040] Based on the above steps, the containerized deployment of the restarted alarm computing node can be realized. In addition, the containerized deployment provided by this embodiment still needs to introduce certain external dependencies, such as MySQL storage medium (MySQL storage medium does not affect the sharding effect of the alarm rule), and apply load balancing to realize alarm service discovery, otherwise the restarted alarm computing node cannot obtain all nodes in the cluster.

[0041] It should be noted that the step division of the above methods is only for clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they contain the same logical relationship, they are all within the scope of protection of this application; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this application.

[0042] Example 2 Based on the technical solution provided in the above-mentioned embodiment 1, this embodiment is also used to provide its specific application scenario.

[0043] In practical applications, the above monitoring and alarm system can be built based on Prometheus. Of course, it is not only applicable to Prometheus, and there is no limitation on this. Only Prometheus is taken as an example.

[0044] For any cluster in Prometheus, when the alarm computing node in it crashes abnormally and restarts, the cluster can be initialized.

[0045] For new nodes that have completed cluster initialization, all Alert States can be obtained from other nodes and merged. At the same time, all alarm rules can be read from the database or file and loaded, and based on the consistent hash algorithm, it can be determined whether the rule should be run on the current node to complete the configuration of the alarm rules.

[0046] Furthermore, the new node will also determine whether the running alarm rules need to be replayed, that is, based on the current calculation time of the alarm rule and the last execution time of the alarm rule in the Alert State merged by the alarm calculation node. During replay, it starts running from last_exec_at, increases one running cycle each time, and then performs a time series query until the current time. After the replay is completed, the alarm rules configured in the new node run regularly. After each run, the execution results of the rules are updated to the local Alert State and stored in the buffer. After being merged into the MTU, they are sent to other nodes in the cluster in the form of UDP packets.

[0047] In addition, the new node will regularly push all its Alert States to other nodes in the cluster in the form of TCP, and regularly pull all Alert States from other nodes in the cluster in the form of TCP. After receiving the Alert States returned by other nodes, it will update them to its own Alert State records.

[0048] At the same time, when the alarm rule is triggered, the new node will also send a notification to the Alert Manager.

[0049] In the above process, when other nodes detect that a new node is online or offline, they will update the cluster member list and trigger the real-time rule load balancing strategy to maintain the stable operation of the cluster and the entire Prometheus.

[0050] Example 3 See also Figure 4 As shown, this implementation also provides a cluster container deployment system, including: The cluster initialization module 10 is used to perform cluster initialization for the restarted alarm computing node, and after the cluster initialization is completed, obtain all current alarm states of the cluster for merging, and read and load all current alarm rules of the cluster; wherein the alarm state is the execution state of an alarm rule within a preset time period.

[0051] The load balancing module 20 is used to configure the alarm rules executed by the restarted alarm computing node by using a consistent hashing algorithm.

[0052] The data replay module 30 is used to determine whether data replay is needed when the restarted alarm calculation node starts to periodically calculate the configured alarm rules based on the current calculation time of the alarm rule and the last execution time of the alarm rule in the merged alarm status, so as to make up for the data missing in the restarted alarm calculation node in a short period of time.

[0053] It should be noted that the containerized deployment system of the cluster provided in the above embodiment and the containerized deployment method of the cluster provided in the above embodiment 1 belong to the same concept, wherein the specific manner in which each module and unit performs the operation has been described in detail in the method embodiment and will not be repeated here. In actual application, the containerized deployment method of the cluster provided in the above embodiment 1 can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not limited here.

[0054] In summary, the present invention provides a containerized deployment method for a cluster, which can automatically balance the load when the alarm computing node crashes and restarts, so as not to affect the normal operation of the existing nodes, and use the Gossip protocol to complete the synchronization of the execution status of the alarm rules in the cluster, and avoid data through the replay mechanism, thereby ensuring the reliable and stable continuous operation of the monitoring alarm system.

[0055] The above embodiments are merely illustrative of the principles and effects of the present invention, and are not intended to limit the present invention. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present invention. Therefore, all equivalent modifications or changes made by a person of ordinary skill in the art without departing from the spirit and technical ideas disclosed by the present invention shall still be covered by the claims of the present invention.

Claims

1. A containerized deployment method for a cluster, characterized in that: Applied to a monitoring alarm system, the monitoring alarm system includes at least one cluster, each cluster includes at least one alarm calculation node, which is used to periodically calculate preset alarm rules to send a notification to an alarm management module when the triggering condition of the alarm rule is met. The method includes: Initialize the cluster for the restarted alarm computing node, and after the cluster initialization is completed, obtain all the current alarm states of the cluster for merging, and read and load all the current alarm rules of the cluster; wherein the alarm state is the execution state of an alarm rule within a preset time period; Use the consistent hashing algorithm to configure the alarm rules running on the restarted alarm computing node; When the restarted alarm calculation node starts to periodically calculate the configured alarm rules, it determines whether data replay is needed based on the current calculation time of the alarm rule and the last execution time of the alarm rule in the merged alarm status to make up for the data that is missing in the restarted alarm calculation node in a short period of time.

2. The containerized deployment method of a cluster according to claim 1, characterized in that: Initialize the cluster for the restarted alarm computing node, obtain all the current alarm status of the cluster for merging after the cluster initialization is completed, and read and load all the current alarm rules of the cluster. The steps include: Check whether there are other alarm computing nodes: If yes, join the corresponding cluster and send the online notification to all alarm computing nodes in the cluster; If not, create a cluster and wait for the addition of alarm rules and other alarm computing nodes to join; When the restarted alarm computing node joins the cluster, it obtains all alarm statuses from other alarm computing nodes and merges them; When the restarted alarm computing node obtains the alarm status, all alarm rules are read and loaded from the database.

3. The containerized deployment method of a cluster according to claim 1, characterized in that: The steps of configuring the alarm rules running on the restarted alarm computing node using the consistent hashing algorithm include: For each of the alarm rules, Determine whether the alarm rule should be run on the restarted alarm computing node based on the consistent hashing algorithm: If not, the restarted alarm calculation node is prohibited from periodically calculating the alarm rule.

4. The containerized deployment method of a cluster according to claim 1, characterized in that: The steps of judging whether data replay is needed based on the current calculation time of the alarm rule and the last execution time of the alarm rule in the merged alarm state to make up for the data missing in a short time of the restarted alarm calculation node include: If the difference between the last execution time and the current calculation time is greater than the preset timeout, no replay will be performed; If the difference between the last execution time and the current calculation time is less than the preset operation period of the alarm calculation node, no replay will be performed; If the difference between the last execution time and the current calculation time is greater than the preset operation cycle of the alarm calculation node and less than the preset replayable time of the alarm calculation node, replay is performed; After the alarm calculation node completes the replay, it periodically calculates the alarm rules to update the local alarm status.

5. The containerized deployment method of a cluster according to claim 1 or 4, characterized in that: The step of replaying data by the alarm computing node includes: Starting from the last execution time, for each time period, the corresponding data is called from the cache data for replay, and the alarm rules are calculated to determine whether the alarm rules are triggered until the current calculation time.

6. The method for containerized deployment of a cluster according to claim 1, characterized in that: Each alarm computing node in the cluster is used to manage and maintain all current alarm states of the cluster, and regularly push the stored alarm states to other alarm computing nodes in the cluster in TCP form, and / or regularly pull the alarm states from other alarm computing nodes in TCP form.

7. The method for containerized deployment of a cluster according to claim 6, characterized in that: Each alarm computing node in the cluster sends the stored alarm status to other alarm computing nodes in the cluster in the form of UDP after it is updated.

8. The containerized deployment method of a cluster according to claim 6 or 7, characterized in that: Any alarm computing node in the cluster only stores the latest alarm status of the same alarm rule; Among them, after the alarm computing node obtains the alarm status from other alarm computing nodes, it determines whether it has stored the alarm status of the alarm rule: If not, directly merge the alarm status; If yes, the latest one of the alarm state and the alarm state stored by itself is retained, and the other one is cleared.

9. The containerized deployment method of a cluster according to claim 6 or 7, characterized in that: Each alarm computing node uses the rumor protocol to synchronize and share the alarm status.

10. A cluster container deployment system, characterized in that: Applied to a monitoring alarm system, the monitoring alarm system includes at least one cluster, each cluster includes at least one alarm calculation node, which is used to periodically calculate preset alarm rules to send a notification to an alarm management module when the triggering condition of the alarm rule is met. The system includes: The cluster initialization module is used to perform cluster initialization for the restarted alarm computing node, and after the cluster initialization is completed, obtain all the current alarm states of the cluster for merging, and read and load all the current alarm rules of the cluster; wherein the alarm state is the execution state of an alarm rule within a preset time period; The load balancing module is used to configure the alarm rules running on the restarted alarm computing node using the consistent hashing algorithm; The data replay module is used to determine whether data replay is needed when the restarted alarm calculation node starts to periodically calculate the configured alarm rules based on the current calculation time of the alarm rule and the last execution time of the alarm rule in the merged alarm status, so as to make up for the data that is missing in the restarted alarm calculation node in a short period of time.

Images