Alarm management method and device, computer device, storage medium and program product

Abstract

This application relates to an alarm management method, apparatus, computer equipment, storage medium, and program product, belonging to the field of computer system monitoring technology. The method includes: acquiring pending alarms from different alarm sources and determining the service instance corresponding to each pending alarm; the service instance is used to maintain a currently active alarm set stored in each service instance; determining the activity status of the pending alarms corresponding to each service instance based on the currently active alarm set of each service instance; marking the pending alarms according to their activity status to obtain marked target alarms; updating each currently active alarm set according to the target alarms, and / or outputting alarms. This method can improve the management accuracy in scenarios with external alarm sources and large amounts of alarm data.

Description

Technical Field

[0001] This application relates to the field of computer system monitoring technology, and in particular to an alarm management method, device, computer equipment, storage medium, and program product. Background Technology

[0002] Currently, in information system monitoring and maintenance scenarios, managing alarms triggered by the information system is an indispensable part. Related technologies typically use thresholds to judge alarm data and use fields to mark whether the alarm has been resolved. However, these alarm management mechanisms struggle to accurately manage alarms from external sources and in scenarios with large amounts of alarm data. Summary of the Invention

[0003] Therefore, it is necessary to provide an alarm management method, device, computer equipment, computer-readable storage medium, and computer program product that can improve the management accuracy in scenarios with external alarm sources and large amounts of alarm data, in order to address the above-mentioned technical problems.

[0004] Firstly, this application provides an alarm management method, including:

[0005] Obtain pending alarms from different alarm sources and determine the service instance corresponding to each pending alarm; the service instance is used to maintain the currently active alarm set stored in each service instance;

[0006] The active status of the pending alarms corresponding to each service instance is determined by the current active alarm set of each service instance;

[0007] Based on the active status of each of the pending alarms, the pending alarms are marked to obtain the marked target alarms;

[0008] Based on the target alarm, update each of the currently active alarm sets and / or output alarms.

[0009] In one embodiment, determining the activity status of the pending alarms corresponding to each service instance through the current active alarm set of each service instance includes:

[0010] The pre-configured identifiers included in the pending alarms are compared with the currently active alarm set of the matching service instance to obtain the comparison result;

[0011] Based on the comparison results of each pending alarm, the active status of each pending alarm is determined.

[0012] In this embodiment, by simplifying the complex determination of the activity status of alarms into a set inclusion check based on a unique identifier, a clear and efficient determination is achieved. The determination logic standard adopted is objective and unambiguous, and only depends on the existence of the pre-configured identifier of the alarm to be processed. No complex rule configuration or manual intervention is required, thereby further improving the accuracy of alarm management.

[0013] In one embodiment, determining the activity status of the alarm to be processed based on the comparison result includes:

[0014] If the comparison result indicates that the pending alarm exists in the current active alarm set, the active state of the pending alarm is determined to be the current active state.

[0015] If the comparison result indicates that the pending alarm does not exist in the current active alarm set, the active state of the pending alarm is determined to be a newly generated state.

[0016] In this embodiment, the differential comparison mechanism based on unique identifiers effectively solves the black-box problem of external alarm sources lacking clear identifiers for newly generated or persistent alarm status. This enables the system to accurately distinguish the lifecycle stages of alarms, thereby achieving more accurate alarm management and laying a reliable data foundation for subsequent accurate calculation of alarm duration, execution of deduplication strategies, and trend analysis.

[0017] In one embodiment, the step of marking the alarms to be processed according to their activity status to obtain marked target alarms includes:

[0018] If the active state of the pending alarm is the current active state, the pending alarm is marked to obtain the marked target alarm as a duplicate alarm;

[0019] If the active state of the pending alarm is the newly generated state, the pending alarm is marked, and the marked target alarm is a newly generated alarm.

[0020] In this embodiment, by assigning clear and unique type labels to alarms in different active states, semantic enhancement of the original alarm data to be processed is achieved. The ambiguous existence information is transformed into clear binary labels for newly generated alarms or duplicate alarms, enabling downstream systems to accurately identify which alarms are new events requiring an initial response and which are known events that continue to exist, thereby solving the problem of not being able to effectively determine whether an alarm is newly generated. In addition, the target alarm after the labeling process carries clear type information, providing a reliable basis for subsequent alarm deduplication, aggregation strategy formulation, and alarm output rule matching.

[0021] In one embodiment, the current active alarm set includes at least one active alarm, and the active alarm is configured with a recovery counter.

[0022] The step of updating each of the currently active alarm sets according to the target alarm includes:

[0023] From the current active alarm set, the active alarms corresponding to the non-duplicate alarms are identified as target active alarms;

[0024] Update the value of the recovery counter for the target active alarm.

[0025] In this embodiment, by setting a recovery counter for each active alarm and performing an incrementing operation when each active alarm does not appear in the duplicate alarms, the persistent existence of alarms is transformed into a quantifiable numerical indicator, reflecting the number of processing rounds in which active alarms have not been reported. This provides an objective data basis for subsequent alarm lifecycle analysis, thereby further improving the accuracy of alarm management.

[0026] In one embodiment, the alarm management method further includes:

[0027] The recovery status of the active alarm is determined based on the value of the recovery counter of the active alarm and a preset threshold.

[0028] If the recovery status of the active alarm is "recovered", the active alarm will be updated to a recovered alarm.

[0029] In this embodiment, a configurable recovery counter is introduced and compared with a preset threshold to determine whether an active alarm has been recovered. The active alarm is only considered to have been recovered when it has been missing for a preset number of consecutive times. This enhances the system's fault tolerance for abnormal scenarios such as momentary failures and network fluctuations, and avoids frequent alarm reversals caused by brief data interruptions. At the same time, combined with differentiated threshold management based on alarm severity, it ensures that severe alarms are not prematurely misjudged and recovered, while mild alarms are reasonably maintained. This improves the accuracy, stability, and reliability of alarm status determination and operation and maintenance decisions while ensuring the real-time nature of alarms.

[0030] In one embodiment, updating each of the currently active alarm sets according to the target alarm, and / or outputting an alarm, includes:

[0031] For the newly generated alarm, set a corresponding recovery counter and add the newly generated alarm to the current active alarm set;

[0032] For both newly generated alarms and recovered alarms, alarm output is performed.

[0033] In this embodiment, a closed-loop alarm status tracking mechanism is constructed by initializing a recovery counter for newly generated alarms and including them in the current active set for full lifecycle maintenance. This ensures that the system can continuously monitor the fault status and provide an accurate counting benchmark for subsequent recovery determination. At the same time, alarm output is only performed for two types of key status change events: newly generated alarms and recovered alarms. This effectively filters out duplicate reporting noise in the intermediate process. Furthermore, by accurately capturing the start and end times of alarms, it provides high-value data support for visually displaying the complete alarm lifecycle and subsequent trend analysis. Thus, efficient and clear closed-loop management from fault discovery to recovery confirmation is achieved.

[0034] In one embodiment, determining the service instance corresponding to each of the pending alarms includes:

[0035] The hash value of each of the pending alarms is determined based on the pre-configured identifiers included in the pending alarms;

[0036] Based on the hash value and hash ring corresponding to the pending alarm, determine the service instance corresponding to each pending alarm.

[0037] In this embodiment, by distributing a large amount of alarm data to multiple parallel service instances, horizontal scaling of processing capacity is achieved. Each instance only needs to maintain and compare local data, significantly reducing the computational and memory pressure on individual nodes and substantially improving the overall throughput and processing efficiency of the system. Furthermore, the hash-based routing strategy ensures that the unique identifier of the same alarm is always routed to the same service instance, allowing the service instance to continuously and consistently maintain the alarm's state without cross-node coordination, guaranteeing the correctness of state tracking and the simplicity of processing logic. When processing larger-scale alarm data, simply adding new service instances to the hash ring linearly scales the system's processing capacity without requiring major modifications to the existing system, thus improving scalability.

[0038] Secondly, this application also provides an alarm management device, including:

[0039] The alarm acquisition module is used to acquire alarms to be processed from different alarm sources and determine the service instance corresponding to each alarm to be processed; the service instance is used to maintain the currently active alarm set stored in each service instance;

[0040] The status determination module is used to determine the active status of the pending alarms corresponding to each service instance by using the current active alarm set of each service instance;

[0041] The alarm marking module is used to mark the alarms to be processed according to their activity status, so as to obtain the marked target alarms.

[0042] The alarm processing module is used to update each of the currently active alarm sets according to the target alarm, and / or output alarms.

[0043] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0044] Obtain pending alarms from different alarm sources and determine the service instance corresponding to each pending alarm; the service instance is used to maintain the currently active alarm set stored in each service instance;

[0045] The active status of the pending alarms corresponding to each service instance is determined by the current active alarm set of each service instance;

[0046] Based on the active status of each of the pending alarms, the pending alarms are marked to obtain the marked target alarms;

[0047] Based on the target alarm, update each of the currently active alarm sets and / or output alarms.

[0048] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0049] Obtain pending alarms from different alarm sources and determine the service instance corresponding to each pending alarm; the service instance is used to maintain the currently active alarm set stored in each service instance;

[0050] The active status of the pending alarms corresponding to each service instance is determined by the current active alarm set of each service instance;

[0051] Based on the active status of each of the pending alarms, the pending alarms are marked to obtain the marked target alarms;

[0052] Based on the target alarm, update each of the currently active alarm sets and / or output alarms.

[0053] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0054] Obtain pending alarms from different alarm sources and determine the service instance corresponding to each pending alarm; the service instance is used to maintain the currently active alarm set stored in each service instance;

[0055] The active status of the pending alarms corresponding to each service instance is determined by the current active alarm set of each service instance;

[0056] Based on the active status of each of the pending alarms, the pending alarms are marked to obtain the marked target alarms;

[0057] Based on the target alarm, update each of the currently active alarm sets and / or output alarms.

[0058] The aforementioned alarm management method, apparatus, computer equipment, computer-readable storage medium, and computer program product acquire pending alarms from different alarm sources and determine the service instance corresponding to each pending alarm. The service instance maintains a currently active alarm set stored within it, enabling it to handle large volumes of alarm data inflows and perform parallel processing, thereby reducing server performance pressure. Furthermore, the activity status of the pending alarms corresponding to each service instance is determined using the currently active alarm set of each service instance. Based on the activity status of each pending alarm, the pending alarms are marked to obtain marked target alarms, which serve as the basis for subsequent alarm processing. Based on the target alarms, the currently active alarm sets are updated, and / or alarms are output. Clear markings characterize the activity status of alarms from different alarm sources, thereby maintaining and outputting alarms, thus improving the accuracy of alarm management. Attached Figure Description

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

[0060] Figure 1 This is a flowchart illustrating an alarm management method in one embodiment;

[0061] Figure 2 This is a flowchart illustrating the steps for determining the status of an alarm to be processed in one embodiment.

[0062] Figure 3 This is a schematic diagram of the alarm management system in one embodiment;

[0063] Figure 4 This is a structural block diagram of an alarm management device in one embodiment;

[0064] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0066] As described in the background section, the alarm management methods of related technologies suffer from difficulties in accurately managing alarms in scenarios with external alarm sources and large amounts of alarm data. Research has found that this problem arises because, currently, in information system monitoring and maintenance scenarios, managing alarms triggered by the information system is an indispensable part. In related technologies, alarm management mechanisms typically use thresholds to judge alarm data and use fields to mark whether the alarm has been recovered. However, these alarm management mechanisms struggle to accurately manage alarms in scenarios with external alarm sources and large amounts of alarm data. Specifically, for external alarm sources, the raw rules governing the generated data are black-box, and the rules for generating alarm data are diverse, making it impossible for alarm source access parties to achieve unified access. Furthermore, the boundaries for new alarm generation from external alarm sources are unclear; typically, there is no clear identifier or field indicating whether the alarm is newly generated or previously reported. This prevents our system access parties from effectively determining whether an alarm is newly generated and from tracking its lifecycle. Moreover, the boundaries for alarm recovery from external alarm sources are also unclear. Usually, there is no clear identifier or field indicating whether an alarm has been recovered; it only informs the access party what alarms currently exist. The difficulty for alarm access providers in determining whether alarms within an information system have been resolved poses a significant challenge. Furthermore, in scenarios with large volumes of alarm data, the amount of data that needs to be processed simultaneously is substantial. Especially for alarm data, which demands high timeliness and processing efficiency, traditional alarm management mechanisms struggle to meet the demands of handling large volumes of alarm data. Moreover, when the volume of incoming alarm data is large, false alarms or fluctuations may occur due to network issues or other problems at the access provider, leading to frequent alarm generation and recovery. Additionally, the lack of clear identifiers for alarm generation and recovery makes it difficult to deduce the time of alarm generation and recovery, thus hindering the determination of the alarm's complete lifecycle and posing a problem for subsequent alarm generation and recovery trend analysis.

[0067] Based on the above reasons, this application provides an alarm management method that distributes pending alarms from different alarm sources to their respective service instances for processing, thereby reducing the performance burden under a large amount of alarm data. Each service instance maintains its own set of currently active alarms. The method then determines the activity status of pending alarms for each service instance based on its current active alarm set, and marks the pending alarms according to their activity status to obtain the marked target alarms. Based on the target alarms, the current active alarm sets are updated, and / or alarms are output. By explicitly representing the activity status of alarms from different alarm sources with markings, alarm maintenance and output are improved, thereby enhancing the accuracy of alarm management.

[0068] In one exemplary embodiment, such as Figure 1 As shown, an alarm management method is provided. This embodiment illustrates the method applied to a server, but it is understood that the method can also be applied to terminals, and to systems including terminals and servers, and is implemented through the interaction between the terminal and the server. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. In this embodiment, the method includes the following steps S102 to S108. Wherein:

[0069] Step S102: Obtain the pending alarms from different alarm sources and determine the service instance corresponding to each pending alarm.

[0070] The alarm source can refer to an external system or device that generates alarm data, such as a monitoring platform, network device, or server in an IT system. In this embodiment, the alarm source is an external system to the execution entity server, meaning that it is impossible to directly obtain a clear indication of whether the alarm reported by the alarm source is newly generated or has been recovered.

[0071] Among them, pending alarms can refer to a batch of new raw alarm data that has not yet been processed by the server, which is captured in real time or periodically from various alarm source systems.

[0072] The service instance is used to maintain the current active alarm set stored in each service instance. The service instance can be a shard pre-deployed on the server, such as a container, process, or compute node. Each service instance is responsible for processing a portion of alarm data, maintaining a current active alarm set, and determining the activity status of alarms to be processed through a differential comparison algorithm.

[0073] The currently active alarm set can refer to the set of alarms that are currently active and maintained by the service instance before the current round of processing.

[0074] Optionally, the server can capture a batch of new pending alarms from different alarm sources in real time or at regular intervals, determine the service instance corresponding to each pending alarm, and then distribute the pending alarms to each service instance for independent and parallel subsequent processing to meet the performance requirements of a large amount of pending alarm data.

[0075] Step S104: Determine the active status of the pending alarms corresponding to the service instance by using the current active alarm set of the service instance.

[0076] The active status can refer to the status reflected by the comparison result of the alarm to be processed relative to the current active alarm set. It includes the current active status, that is, the alarm has been maintained in the active set, and the newly generated status, that is, the alarm is not in the active set. It is the basis for judging whether the alarm to be processed is newly added or duplicated.

[0077] Optionally, the server determines the active status of the pending alarms corresponding to each server instance by using the alarm records that are already in the current active alarm set maintained by each service instance, thereby laying the groundwork for the subsequent processing method of the pending alarms.

[0078] Step S106: According to the active status of each alarm to be processed, the alarms to be processed are marked to obtain the marked target alarms.

[0079] Tagging can refer to the operation of assigning a corresponding tag to an alarm based on its activity status.

[0080] Among them, target alarms can refer to alarm data with clear status labels after being marked, which is the basis for subsequent updates to the active set or alarm output.

[0081] Optionally, the server can mark the alarms to be processed according to their activity status, such as creating an enumeration field for the alarms to be processed to obtain the marked target alarms.

[0082] Step S108: Update each currently active alarm set according to the target alarm, and / or output the alarm.

[0083] Alarm output can refer to the process of sending target alarms marked as newly generated alarms or recovered alarms to downstream systems, such as sending notifications or displaying them through a visualization platform.

[0084] Optionally, the server collects and integrates the target alarms corresponding to each service instance. If the target alarms include newly generated alarms, the newly generated alarms are updated to the current active alarm set, and alarm output is performed for the newly generated alarms. If the target alarms involve duplicate alarms, it is confirmed whether the duplicate alarms have been recovered. If there are recovered alarms among the duplicate alarms, the server will output alarms for both the newly generated alarms and the duplicate alarms so that the downstream can understand the lifecycle of the alarms. If there are no recovered alarms among the duplicate alarms, there is no need to output alarms for the duplicate alarms.

[0085] In the aforementioned alarm management method, pending alarms from different alarm sources are acquired, and the corresponding service instance for each pending alarm is determined. Each service instance maintains its own currently active alarm set, enabling it to handle large volumes of incoming alarm data and process them in parallel, thus reducing server performance pressure. Furthermore, the activity status of pending alarms corresponding to each service instance is determined using its current active alarm set. Based on the activity status of each pending alarm, the pending alarms are marked to obtain the marked target alarms, which serve as the basis for subsequent alarm processing. Based on the target alarms, each currently active alarm set is updated, and / or alarms are output. Clear markings characterize the activity status of alarms from different alarm sources, thereby maintaining and outputting alarms and improving the accuracy of alarm management.

[0086] In one exemplary embodiment, such as Figure 2 As shown, step S104 determines the active status of the pending alarms corresponding to each service instance by using the current active alarm set of each service instance, including steps S202 to S204. Wherein:

[0087] Step S202: Compare the pre-configured identifiers included in the alarms to be processed with the current active alarm set of the matching service instance to obtain the comparison result.

[0088] The pre-configured identifier can refer to a field or combination of fields carried in the alarm data of each alarm to be processed that can uniquely identify the characteristics of the alarm.

[0089] Among them, the comparison processing can refer to the process of matching the unique identifier of the alarm to be processed with the alarm identifiers in the current active alarm set.

[0090] The comparison result can refer to the output result after comparison processing, which is used to determine whether the alarm exists in the current active alarm set. The comparison result is either present or absent, which is the basis for determining the active status.

[0091] Optionally, the server extracts the pre-configured identifier of the alarm to be processed, i.e., the unique identifier of the alarm, through each service instance. For example, it extracts the alert_id (the unique identifier of the alarm record in the database or log system) or a unique key value generated by combining key fields such as alarm source, alarm type, and alarm object. Then, it matches and compares the pre-configured identifier of the alarm to be processed with the unique pre-configured identifier of all active alarms in the current active alarm set maintained by the corresponding service instance. For example, a differential comparison algorithm is used for comparison to obtain the comparison result.

[0092] Step S204: Determine the active status of each pending alarm based on the comparison results of each pending alarm.

[0093] The active status can refer to an alarm that is currently active or a newly generated status, indicating that it already exists in the current active alarm set.

[0094] Optionally, the server determines the activity status corresponding to the comparison result of the alarm to be processed based on the comparison result of the alarm to be processed. If the comparison result is that the alarm to be processed is the same as a certain active alarm in the current active alarm set, then the activity status of the alarm to be processed is determined to be currently active. If the comparison result is that there is no matching active alarm in the current active alarm set, then the activity status of the alarm to be processed is determined to be newly generated.

[0095] In this embodiment, by simplifying the complex determination of the activity status of alarms into a set inclusion check based on a unique identifier, a clear and efficient determination is achieved. The determination logic standard adopted is objective and unambiguous, and only depends on the existence of the pre-configured identifier of the alarm to be processed. No complex rule configuration or manual intervention is required, thereby further improving the accuracy of alarm management.

[0096] In an exemplary embodiment, step S204 determines the active status of each alarm to be processed based on the comparison results of each alarm to be processed, including:

[0097] If the comparison result shows that there are pending alarms in the current active alarm set, the active status of the pending alarms is determined to be the current active status; if the comparison result shows that there are no pending alarms in the current active alarm set, the active status of the pending alarms is determined to be the newly generated status.

[0098] The current active status can refer to the situation where the pending alarm already exists in the current active alarm set, indicating that the pending alarm is not a new occurrence, but a persistent alarm that existed in the previous alarm processing round and continues to be reported in this alarm processing round.

[0099] The newly generated state can refer to the situation where the pending alarm does not exist in the current active alarm set, indicating that the pending alarm is the first one captured in this alarm round and belongs to the newly added alarm.

[0100] Optionally, if the comparison result shows that there is a matching currently active alarm in the current active alarm set for the alarm to be processed, that is, the unique identifier of the alarm to be processed can be matched in the current active alarm set, then the server can determine that the active state of the alarm to be processed is the current active state, which means that the alarm to be processed already existed in the previous processing round and is still in a continuously active state in this round of alarm management. If the comparison result shows that there is no matching currently active alarm in the current active alarm set for the alarm to be processed, then the server can determine that the alarm to be processed is a newly generated state, indicating that the alarm is newly generated after the previous alarm processing round.

[0101] In this embodiment, the differential comparison mechanism based on unique identifiers effectively solves the black-box problem of external alarm sources lacking clear identifiers for newly generated or persistent alarm status. This enables the system to accurately distinguish the lifecycle stages of alarms, thereby achieving more accurate alarm management and laying a reliable data foundation for subsequent accurate calculation of alarm duration, execution of deduplication strategies, and trend analysis.

[0102] In an exemplary embodiment, step S106 marks the alarms to be processed according to their activity status to obtain the marked target alarms, including:

[0103] If the active state of the pending alarm is "currently active", the pending alarm is marked, and the marked target alarm is a duplicate alarm; if the active state of the pending alarm is "newly generated", the pending alarm is marked, and the marked target alarm is a newly generated alarm.

[0104] Duplicate alarms can refer to alarms that already exist in the current active alarm set. The system can ignore their repeated reporting. For example, if the previous round of the current active alarm set had an alarm for "CPU overload", and the alarm for "CPU overload" is still reported in this round, it will be marked as a duplicate alarm.

[0105] Newly generated alarms can refer to alarms that do not exist in the current active alarm set and are identified by the system as being generated for the first time.

[0106] Optionally, if the active state of the pending alarm is "currently active", the pending alarm is marked, and the marked target alarm is a duplicate alarm. For example, the server adds a status field to the alarm data structure of the pending alarm and assigns it the value of "duplicate alarm". If the active state of the pending alarm is "newly generated", the pending alarm is marked, and the marked target alarm is a newly generated alarm. For example, the server adds a status field to the alarm data structure and assigns it the value of "newly generated alarm". All pending alarms that have completed the marking operation are output as marked target alarms for subsequent steps, such as counter maintenance and alarm output.

[0107] In this embodiment, by assigning clear and unique type labels to alarms in different active states, semantic enhancement of the original alarm data to be processed is achieved. The ambiguous existence information is transformed into clear binary labels for newly generated alarms or duplicate alarms, enabling downstream systems to accurately identify which alarms are new events requiring an initial response and which are known events that continue to exist. This solves the problem of not being able to effectively determine whether an alarm is newly generated. In addition, the target alarm after the labeling process carries clear type information, providing a reliable basis for subsequent alarm deduplication, aggregation strategy formulation, and alarm output rule matching.

[0108] In an exemplary embodiment, the current active alarm set includes at least one active alarm, and each active alarm is equipped with a recovery counter. For example, each active alarm that is added to the current active alarm set for the first time is equipped with a corresponding recovery counter, and the value of the recovery counter is set to zero.

[0109] Step S108 involves updating the content of each currently active alarm set based on the target alarm, including:

[0110] From the current active alarm set, identify the active alarm corresponding to the non-repeating alarm as the target active alarm; update the value of the recovery counter of the target active alarm.

[0111] The recovery counter can be a counter set for each active alarm to record the number of times the alarm is missing from the new alarm set consecutively. The recovery counter can be used to prevent false recovery due to network jitter, etc. For example, if the alarm "CPU overload" already exists in the current active alarm set, the recovery counter = 1 if it is not reported in the first round of pending alarm set, and the recovery counter = 2 if it is still not reported in the second round of pending alarm set.

[0112] Among them, target active alarms can refer to alarm records that correspond to newly captured duplicate alarms in the current active alarm set.

[0113] Optionally, the server filters out alarm entries marked as duplicate alarms from the target alarms through the service instance. For each duplicate alarm, the service instance searches in the current active alarm set according to its unique identifier to locate the active alarm that matches its unique identifier. Then, the active alarms in the current active alarm set that cannot match the preset identifier of duplicate alarms (i.e., non-duplicate alarms) are identified as target active alarms. Then, the server performs an update operation on the recovery counter corresponding to the target active alarm. Specifically, the update operation can be to increment the value of the recovery counter. For example, if the current value of the recovery counter of the target active alarm is 2, it is updated to 3. Understandably, for other active alarms in the current active alarm set that match any duplicate alarm, their recovery counter values ​​remain unchanged or are set to zero during this process, awaiting further judgment in subsequent processing rounds. For example, if the active alarm "high communication latency" already exists in the current active alarm set maintained by a certain service instance, and since "high communication latency" was not reported in the previous round of pending alarms, it is judged as a target active alarm that may have been recovered, and its recovery counter is set to 1. However, during the alarm data processing in this round, if the duplicate alarm "high communication latency" is found, its recovery counter is set to 0 to avoid misjudging whether it has been recovered.

[0114] In this embodiment, by setting a recovery counter for each active alarm and performing an incrementing operation when each active alarm does not appear in the duplicate alarms, the persistent existence of alarms is transformed into a quantifiable numerical indicator, reflecting the number of processing rounds in which active alarms have not been reported. This provides an objective data basis for subsequent alarm lifecycle analysis, thereby further improving the accuracy of alarm management.

[0115] In one exemplary embodiment, the alarm management method described above further includes:

[0116] The recovery status of an active alarm is determined based on the value of its recovery counter and a preset threshold. If the recovery status of an active alarm is "recovered," the active alarm is updated to a "recovered alarm."

[0117] The preset threshold can refer to the comparison threshold of the recovery counter, which serves as a critical value for determining whether an alarm has truly been recovered. It can be set according to actual needs. When the value of the recovery counter is greater than or equal to the threshold, the alarm is determined to have been recovered.

[0118] The recovery status refers to the judgment result of whether the alarm has been truly recovered after comparing the recovery counter with the preset threshold. The recovery status includes not recovered and recovered.

[0119] Optionally, in a complete round of pending alarm processing, the server performs the following operations through each service instance: receiving newly captured pending alarms, comparing the pending alarms with the currently active alarm set maintained by their corresponding service instances, marking pending alarms that do not exist in the current active alarm set as newly generated alarms, and marking pending alarms that exist in the current active alarm set as duplicate alarms. Simultaneously, the recovery counters of the target active alarms corresponding to these duplicate alarms in the current active alarm set are incremented, and the recovery counter value of each active alarm in the current active alarm set is traversed. It is determined whether the recovery counter value is greater than or equal to a preset threshold. If the recovery counter value is greater than or equal to the preset threshold, the active alarm's recovery status is determined to be recovered, the active alarm is updated to a recovered alarm, and it is deleted from the current active alarm set. If the recovery counter value is less than the preset threshold, the active alarm's recovery status is determined to be unrecovered. Thus, all recovered alarms are collected from the current active alarm set for subsequent alarm output.

[0120] It should be noted that the server can configure recovery timers and / or recovery counters for each active alarm in the current active alarm set maintained by the service instance, and can also classify and manage the current active alarms according to the severity of the alarms. Different levels of active alarms correspond to different preset time thresholds and / or different preset numerical thresholds, thereby enabling differentiated management and preventing serious alarms with long durations from being mistakenly judged as recovered, while minor alarms are continuously maintained, further improving the accuracy of alarm management.

[0121] In this embodiment, a configurable recovery counter is introduced and compared with a preset threshold to determine whether an active alarm has been recovered. The active alarm is only considered to have been recovered when it has been missing for a preset number of consecutive times. This enhances the system's fault tolerance for abnormal scenarios such as momentary failures and network fluctuations, and avoids frequent alarm reversals caused by brief data interruptions. At the same time, combined with differentiated threshold management based on alarm severity, it ensures that severe alarms are not prematurely misjudged and recovered, while mild alarms are reasonably maintained. This improves the accuracy, stability, and reliability of alarm status determination and operation and maintenance decisions while ensuring the real-time nature of alarms.

[0122] In an exemplary embodiment, step S108 updates each currently active alarm set according to the target alarm, and / or outputs an alarm, including:

[0123] For newly generated alarms, set a corresponding recovery counter and add the newly generated alarms to the current active alarm set; output alarms for both newly generated alarms and recovered alarms.

[0124] Among them, a recovered alarm can refer to an alarm whose recovery counter value has reached a preset threshold and has been determined by the system to be recovered. This indicates that the alarm has been handled at the fault point or that there is no need to continue to issue alarms.

[0125] Optionally, the server sets a corresponding recovery counter for each newly generated alarm on each service instance, sets the value of the recovery counter to zero, and adds the newly generated alarm to the current active alarm set of the service instance for maintenance as an active alarm. Further, the server collects newly generated and recovered alarms identified by each service instance and outputs alarms, such as visually displaying the alarm lifecycle or sending alarm notifications. It is understood that each newly generated alarm and each recovered alarm can be output separately or together; there is no specific limitation, and the output can be based on actual needs.

[0126] In this embodiment, a closed-loop alarm status tracking mechanism is constructed by initializing a recovery counter for newly generated alarms and including them in the current active set for full lifecycle maintenance. This ensures that the system can continuously monitor the fault status and provide an accurate counting benchmark for subsequent recovery determination. At the same time, alarm output is only performed for two types of key status change events: newly generated alarms and recovered alarms. This effectively filters out duplicate reporting noise in the intermediate process. Furthermore, by accurately capturing the start and end times of alarms, it provides high-value data support for visually displaying the complete alarm lifecycle and subsequent trend analysis. Thus, efficient and clear closed-loop management from fault discovery to recovery confirmation is achieved.

[0127] In an exemplary embodiment, step S102, determining the service instance content corresponding to each alarm to be processed, includes:

[0128] Based on the pre-configured identifiers included in the pending alarms, determine the hash value of each pending alarm; based on the hash value and hash ring of the pending alarm, determine the service instance corresponding to each pending alarm.

[0129] The hash value can refer to the value calculated by a hash function based on the unique identifier of the alarm; the hash ring can be a commonly used data routing structure in a distributed system, used to map data to the corresponding service instance based on the hash value. In this embodiment, the server distributes the alarm to the shards of the corresponding service instance based on the hash value and hash ring of the alarm to be processed, thereby achieving load balancing and horizontal scaling.

[0130] Optionally, the server is responsible for periodically or in real-time capturing a batch of new pending alarms from various alarm sources. For each pending alarm, the server extracts its pre-configured identifier, calculates the hash value of each pending alarm using a preset hash algorithm, and then searches for the corresponding service instance on the hash ring based on the calculated hash value of each pending alarm. Specifically, the hash value is mapped to a certain position on the ring, and then the nearest available service instance is found clockwise (or counterclockwise) along the ring as the processing target for that alarm. The server delivers the pending alarm to its corresponding service instance, which then performs the subsequent status comparison and judgment logic.

[0131] In this embodiment, by distributing a large amount of alarm data to multiple parallel service instances, horizontal scaling of processing capacity is achieved. Each instance only needs to maintain and compare local data, significantly reducing the computational and memory pressure on individual nodes and substantially improving the overall throughput and processing efficiency of the system. Furthermore, the hash-based routing strategy ensures that the unique identifier of the same alarm is always routed to the same service instance, allowing the service instance to continuously and consistently maintain the alarm's state (e.g., recovery counter) without cross-node coordination, guaranteeing the correctness of state tracking and the simplicity of processing logic. When processing larger-scale alarm data, simply adding new service instances to the hash ring linearly scales the system's processing capacity without requiring major modifications to the existing system, thus improving scalability.

[0132] In one exemplary embodiment, such as Figure 3 As shown, an alarm management system is provided to implement the alarm management method described in any of the above embodiments, including:

[0133] A front-end coordinator is used to coordinate alarms from various source systems (such as...) Figure 3 Alarm source system 1, alarm source system 2, and alarm source system 3) periodically and cyclically capture a batch of new alarm data in real time and send the captured alarm data to [the relevant authority / organization]. Figure 3 The alarm collection module in the system distributes alarm data to the service instance corresponding to the hash ring based on a unique key (pre-configured identifier).

[0134] At least one service instance is used to receive the alarm set (pending alarms, corresponding to) delivered by the front coordinator. Figure 3 After the alarm receiving queue is entered, the newly captured alarm set is compared with the currently active alarm record set (current active alarm set) maintained during the previous round of processing. Figure 3The differential comparison algorithm module shown compares the alarm against a pre-stored differential comparison algorithm, based on the alarm's unique identifier (pre-configured identifier). For newly captured alarms, if their unique identifier does not exist in the current active alarm record set, the alarm is determined to be a newly generated alarm (corresponding to...). Figure 3 The alarm (generated in the record) is recorded as a new alarm; if its unique identifier exists in the current active alarm record set, it is determined to be a duplicate alarm and ignored. When a real-time alarm is suspected of recovery for the first time, a recovery counter is maintained for the alarm, and the counter is cleared when the alarm is actually recovered.

[0135] Among them, alarm recovery identification: For an alarm in the current active alarm record set, if its unique identifier does not exist in the newly captured alarm set, the alarm is determined to be a suspected "recovered" alarm (target active alarm, corresponding to...). Figure 3 The alarm is listed under "Recovered Alarm". The recovery counter (count) for the repeated alarm is incremented by 1. Then, it is checked whether the count is greater than or equal to N (N is configurable). If the count is greater than or equal to N, the real-time alarm is considered recovered, its recovery counter is cleared, and the alarm is recorded as "recovered". If the count does not meet the condition of being greater than or equal to N, the alarm is considered suspected of being recovered and no recovery processing is performed. This is done to prevent false alarms or jitter. If its unique identifier exists in the newly captured alarm set, the alarm is considered "unrecovered" and can be ignored. The newly captured alarm set is used as the new set of currently active alarm records for the next comparison.

[0136] The post-coordinator is used to aggregate and process the recorded "new alarms" and "recovered" alarms after all service instances have finished processing the alarm data in this round, and then distribute them to the alarm processing module for alarm or recovery processing. The identified "new alarms" and "recovered" alarms are output separately for subsequent alarm aggregation, alarm notification, visualization, and other system uses; alarm outputs can also be sent to the storage unit for alarm storage.

[0137] In this embodiment, when an external alarm source is accessed, this differential comparison algorithm has universal applicability. It adopts a sharded processing approach, which can solve the performance problem under large-volume alarm data. Furthermore, sharding can be horizontally expanded, clearly distinguishing whether the current alarm is a newly generated alarm or a duplicate alarm, making the alarm generation boundary clear. It can also clearly distinguish whether alarms generated in the system have been recovered, making the alarm recovery boundary clear. It can accurately record the generation and recovery events of alarms, providing reliable data for alarm lifecycle management and post-event analysis. The recovery counter can solve the problems of false alarms and jitter, avoiding frequent alarms and recovery.

[0138] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0139] Based on the same inventive concept, this application also provides an alarm management device for implementing the alarm management method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more alarm management device embodiments provided below can be found in the limitations of the alarm management method described above, and will not be repeated here.

[0140] In one exemplary embodiment, such as Figure 4 As shown, an alarm management device 400 is provided, including: an alarm acquisition module 401, a status determination module 402, an alarm marking module 403, and an alarm processing module 404, wherein:

[0141] The alarm acquisition module 401 is used to acquire alarms to be processed from different alarm sources and determine the service instance corresponding to each alarm to be processed; the service instance is used to maintain the currently active alarm set stored in each service instance;

[0142] The status determination module 402 is used to determine the active status of the pending alarms corresponding to each service instance by using the current active alarm set of each service instance;

[0143] The alarm marking module 403 is used to mark the alarms to be processed according to the activity status of each alarm to be processed, so as to obtain the marked target alarms;

[0144] The alarm processing module 404 is used to update each currently active alarm set according to the target alarm, and / or output alarms.

[0145] Furthermore, in one embodiment, the status determination module 402 is also used to compare the pre-configured identifiers included in the alarms to be processed with the current active alarm set of the matching service instance to obtain a comparison result; and determine the active status of each alarm to be processed based on the comparison result of each alarm to be processed.

[0146] Furthermore, in one embodiment, the state determination module 402 is further configured to determine the active state of the pending alarm as the current active state when the comparison result shows that there is a pending alarm in the current active alarm set; and to determine the active state of the pending alarm as the newly generated state when the comparison result shows that there is no pending alarm in the current active alarm set.

[0147] Furthermore, in one embodiment, the alarm marking module 403 is also used to mark the alarm to be processed when the active state of the alarm to be processed is the current active state, so that the marked target alarm is a duplicate alarm; and to mark the alarm to be processed when the active state of the alarm to be processed is the newly generated state, so that the marked target alarm is a newly generated alarm.

[0148] Furthermore, in one embodiment, the alarm processing module 404 is also used to determine from the current active alarm set the active alarm corresponding to the non-repeating alarm as the target active alarm; and update the value of the recovery counter of the target active alarm.

[0149] Furthermore, in one embodiment, the alarm processing module 404 is also used to determine the recovery status of the active alarm based on the value of the recovery counter of the active alarm and a preset threshold; if the recovery status of the active alarm is recovered, the active alarm is updated to a recovered alarm.

[0150] Furthermore, in one embodiment, the alarm processing module 404 is also used to set a corresponding recovery counter for newly generated alarms and add the newly generated alarms to the currently active alarm set; and to output alarms for newly generated alarms and recovered alarms.

[0151] Furthermore, in one embodiment, the alarm collection module 401 is also used to determine the hash value of each alarm to be processed based on the pre-configured identifier included in the alarm to be processed; and to determine the service instance corresponding to each alarm to be processed based on the hash value and hash ring corresponding to the alarm to be processed.

[0152] Each module in the alarm management device 400 described above can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0153] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data such as pending alarms, currently active alarm sets, and active status. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements an alarm management method.

[0154] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0155] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0156] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0157] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0158] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0159] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0160] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An alarm management method, characterized in that, The method includes: Obtain pending alarms from different alarm sources and determine the service instance corresponding to each pending alarm; the service instance is used to maintain the currently active alarm set stored in each service instance; The active status of the pending alarms corresponding to each service instance is determined by the current active alarm set of each service instance; Based on the active status of each of the pending alarms, the pending alarms are marked to obtain the marked target alarms; Based on the target alarm, update each of the currently active alarm sets and / or output alarms.

2. The method according to claim 1, characterized in that, The step of determining the activity status of the pending alarms corresponding to each service instance through the current active alarm set of each service instance includes: The pre-configured identifiers included in the pending alarms are compared with the currently active alarm set of the matching service instance to obtain the comparison result; Based on the comparison results of each pending alarm, the active status of each pending alarm is determined.

3. The method according to claim 2, characterized in that, Determining the activity status of the alarm to be processed based on the comparison result includes: If the comparison result indicates that the pending alarm exists in the current active alarm set, the active state of the pending alarm is determined to be the current active state. If the comparison result indicates that the pending alarm does not exist in the current active alarm set, the active state of the pending alarm is determined to be a newly generated state.

4. The method according to claim 3, characterized in that, The step of marking the pending alarms according to their activity status to obtain the marked target alarms includes: If the active state of the pending alarm is the current active state, the pending alarm is marked to obtain the marked target alarm as a duplicate alarm; If the active state of the pending alarm is the newly generated state, the pending alarm is marked, and the marked target alarm is a newly generated alarm.

5. The method according to claim 4, characterized in that, The current active alarm set includes at least one active alarm, and each active alarm is configured with a recovery counter. The step of updating each of the currently active alarm sets according to the target alarm includes: From the current active alarm set, the active alarms corresponding to the non-duplicate alarms are identified as target active alarms; Update the value of the recovery counter for the target active alarm.

6. The method according to claim 5, characterized in that, The method further includes: The recovery status of the active alarm is determined based on the value of the recovery counter of the active alarm and a preset threshold. If the recovery status of the active alarm is "recovered", the active alarm will be updated to a recovered alarm.

7. The method according to claim 6, characterized in that, The step of updating each of the currently active alarm sets according to the target alarm, and / or outputting alarms, includes: For the newly generated alarm, set a corresponding recovery counter and add the newly generated alarm to the current active alarm set; For both newly generated alarms and recovered alarms, alarm output is performed.

8. The method according to any one of claims 1 to 7, characterized in that, The determination of the service instance corresponding to each of the pending alarms includes: The hash value of each of the pending alarms is determined based on the pre-configured identifiers included in the pending alarms; Based on the hash value and hash ring corresponding to the pending alarm, determine the service instance corresponding to each pending alarm.

9. An alarm management device, characterized in that, The device includes: The alarm acquisition module is used to acquire alarms to be processed from different alarm sources and determine the service instance corresponding to each alarm to be processed; the service instance is used to maintain the currently active alarm set stored in each service instance; The status determination module is used to determine the active status of the pending alarms corresponding to each service instance by using the current active alarm set of each service instance; The alarm marking module is used to mark the alarms to be processed according to their activity status, so as to obtain the marked target alarms. The alarm processing module is used to update each of the currently active alarm sets according to the target alarm, and / or output alarms.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images