Alarm synchronization method and notification deduplication method

Abstract

The application provides an alarm synchronization method and a notification deduplication method, and relates to the technical field of data synchronization. The method comprises the following steps: in the case that the network state is a degraded state, generating report sequence information according to the order of a plurality of alarm events reported to a center node, wherein the degraded state is a network state in which the reporting between the edge node and the center node is not interrupted, but the reporting quality does not meet the preset condition; obtaining the receiving sequence information sent by the center node, wherein the receiving sequence information is sequence information generated by the center node after receiving the alarm events reported by the edge node; matching the report sequence information and the receiving sequence information, determining the alarm events that fail to be reported during the degraded state, and reporting the alarm events that fail to be reported to the center node.

Description

Technical Field

[0001] This application relates to the field of data synchronization technology, and in particular to an alarm synchronization method and a notification deduplication method. Background Technology

[0002] Alarm synchronization is widely used in distributed systems to ensure that alarms on all sides remain consistent. After an alarm is generated locally, it needs to be transmitted to the server via a link. However, links can fail, so devices usually have local storage space to temporarily store alarms in case of link failure.

[0003] In related technologies, the device writes the alarms generated during a link failure to the local storage space. After the link is restored, the alarms in the local storage space are transmitted to the server to complete the alarm synchronization.

[0004] However, during link failures, a large number of alarms are generated and are difficult to synchronize efficiently with the central system, resulting in low alarm consistency. Summary of the Invention

[0005] In view of the above problems, this application provides an alarm synchronization method and a notification deduplication method.

[0006] This application provides an alarm synchronization method applied to edge nodes, comprising: generating reporting sequence information according to the order in which multiple alarm events are reported to the central node when the network state is in a degraded state, wherein the degraded state is a network state in which the reporting between the edge node and the central node is uninterrupted but the reporting quality does not meet preset conditions; obtaining receiving sequence information sent by the central node, wherein the receiving sequence information is the sequence information generated by the central node after receiving alarm events reported by the edge node; matching the reporting sequence information and the receiving sequence information to determine the alarm events that failed to be reported during the degraded state, and reporting the alarm events that failed to be reported to the central node.

[0007] By adopting the above technical solutions, this application identifies the degraded state, ensuring that the interval where the link is not disconnected but can no longer reliably carry reports is no longer mistaken for normal communication, thus preventing alarm losses in this interval from remaining unnoticed for a long time. By generating reporting sequence information according to the reporting order in the degraded state, each reporting action has a traceable location identifier, providing a basis for determining the scope of loss afterward. By introducing the receiving sequence information generated by the central node after actually receiving the alarm event and matching it with the reporting sequence information on the edge node side, the basis for determining whether a loss has occurred changes from the request return result of the sending end to the actual receiving result of the receiving end. This enables the identification of alarm events where the edge node side did not receive any failure signal but was not actually received by the central node, solving the problem that such losses are unknown to the edge node side. By only supplementing the reporting of alarm events that are determined to be reporting failures after matching, the amount of data for the recovery action is converged to the truly missing part, avoiding the secondary impact of full retransmission on the already degraded link and the alarm noise caused by repeated reporting, thus ensuring the final integrity of alarm data during the degraded period without increasing the link burden.

[0008] Furthermore, based on the reported sequence information and the received sequence information, the alarm events that failed to be reported during the degraded state are identified, and the alarm events are reported to the central node, including: determining the data missing interval based on the reported sequence information and the received sequence information; dividing the data missing interval into multiple intervals according to a preset number of alarm events for each interval; and compressing the alarm events in the multiple intervals sequentially before reporting them to the central node.

[0009] By adopting the above technical solution, this application first converges the missing data intervals from the matching results of the two types of sequence information, and then divides the missing intervals into multiple intervals according to the preset number of alarm events for each interval and compresses and reports them interval by interval, so that the amount of data reported at one time is always within a controllable range, avoiding repeated timeout failures due to excessively large single packets on links with reduced carrying capacity; at the same time, using intervals as the basic unit of supplementary reporting makes the supplementary reporting process have a structure that can be promoted and confirmed in segments, and the compression further reduces the bandwidth occupation of supplementary reporting on the link, so that the data catch-up in the degraded state can be completed smoothly at a pace that is adapted to the current carrying capacity of the link.

[0010] Furthermore, alarm events within multiple intervals are compressed sequentially and reported to the central node, including: merging multiple alarm events within an interval whose occurrence time is within the same time window and whose indicated event type is the same, to obtain a merged event; compressing the merged event and the alarm events within the interval that were not merged according to the order of the reporting sequence information to obtain a data packet corresponding to the interval, wherein the data packet carries the range of the reporting sequence information corresponding to the interval; and reporting the data packet sequentially to the central node.

[0011] By adopting the above technical solutions, this application first merges multiple alarm events that occur within the same time window and have the same event type before compression. This allows repeated alarms caused by the same fault source within a short period of time to be converged into merged events during the supplementary reporting stage. This reduces the amount of data that needs to be transmitted and also reduces the possibility of a large number of duplicate notifications being generated downstream after the supplementary reporting is completed. By compressing the merged events and the alarm events that did not participate in merging into data packets according to the order of the reporting sequence information, the event order within the data packets is kept consistent with the original reporting order, which facilitates the central node to process them in sequence. By making the data packets carry the range of the corresponding reporting sequence information, the central node can clearly know the sequence range that the data packets should cover, providing a comparable benchmark for the integrity verification of the receiving side and subsequent confirmation and secondary supplementary reporting.

[0012] Furthermore, after the data packets are sequentially reported to the central node, the process also includes: receiving confirmation information returned by the central node, wherein the confirmation information includes the received sequence information of the target alarm events from the edge nodes that the central node has stored; determining the target reporting sequence information that the central node has not stored within the range based on the range of the reporting sequence information carried by the data packets and the received sequence information; and, if there is an alarm event corresponding to the target reporting sequence information among the alarm events stored by the edge nodes, re-reporting the alarm event corresponding to the target reporting sequence information to the central node.

[0013] By adopting the above technical solutions, this application further receives the confirmation information returned by the central node containing the stored events after the supplementary reporting action is completed, and compares it again with the sequence range carried by the data packet. This ensures that the supplementary reporting process itself can also detect the possible loss on the degraded link, forming a closed loop of reporting, verification, and rereporting. By clarifying the judgment standard as whether the central node has stored the data rather than whether the edge node has successfully sent it, the determination of data consistency is always based on the landing result of the receiving end, avoiding misjudgment caused by considering successful transmission as synchronization completion. By performing rereporting only when the corresponding alarm event still exists locally, the rereporting action is limited to the range that can be truly supplemented, avoiding invalid retries for events that have been cleared.

[0014] Furthermore, it also includes: recording synchronization progress information during the process of sequentially reporting alarm events in multiple intervals, wherein the synchronization progress information includes the reporting sequence information of the intervals that have been reported and the reporting sequence information of the alarm events reported in the currently reported interval; in the event of an interruption in reporting, the synchronization progress information is retained, and after the network status switches back to online or degraded status, the reporting breakpoint is determined based on the synchronization progress information, and alarm events are continued to be reported to the central node from the breakpoint.

[0015] By adopting the above technical solution, this application simultaneously records the reporting sequence information of completed intervals and reported events in the current interval during the interval-by-interval supplementary reporting process, so that the synchronization progress is refined to the granularity of individual events within the interval; by retaining the synchronization progress information when the reporting is interrupted and determining the breakpoint position to continue reporting after the network status recovers to online or degraded status, the supplementary reporting process has the ability to resume transmission from the breakpoint, avoiding repeated transmission and time waste caused by having to start over from the starting point of the missing interval due to interruption, so that the synchronization progress can still accumulate unidirectionally and gradually converge even in scenarios with repeated network fluctuations.

[0016] Furthermore, the network status includes online status, degraded status, and offline status; the method also includes: switching the network status to degraded status when the network status is online and the number of consecutive timeouts between the network and the central node exceeds a first preset number; switching the network status to offline status when the network status is degraded and the alarm events fail to be reported for a second preset number of consecutive times or the number of alarm events waiting to be reported in the retry queue exceeds a preset threshold, wherein the retry queue is a queue for caching alarm events that need to be re-reported; switching the network status to degraded status when the network status is offline and the network probe of the central node is successful; and switching the network status to online status when the network status is degraded, communication returns to normal, and alarm events are synchronized.

[0017] By adopting the above technical solutions, this application provides specific triggering conditions for the transition between online, degraded, and offline states, based on the number of consecutive reporting timeouts, the number of consecutive reporting failures, the backlog of the retry queue, and the network probe results. This allows state determination to be based on objective quantities that edge nodes can observe themselves without relying on external commands. By switching from offline to degraded state first after a successful probe, rather than directly switching to online state, a dedicated transition phase is provided for backlogged alarm events during offline periods to catch up, avoiding the situation where the state is considered completely normal immediately after connectivity is restored, thus leaving backlogged data behind. By requiring the degraded state to switch to online state only when both conditions are met—communication is restored to normal and alarm events are completed synchronously—the meaning of online state is constrained to data recovery, avoiding data loss caused by prematurely setting the state to online before link indicators are restored and missing data is replenished.

[0018] Furthermore, it also includes: when a network state switching request is received, determining the time interval between the current time and the last time the network state switching was performed; if the time interval is less than a preset interval, recording the target network state indicated by the switching request and starting a jitter timer, and switching the network state to the target network state after the jitter timer expires; if the time interval is greater than or equal to the preset interval, responding to the switching request and performing a network state switch.

[0019] By adopting the above technical solution, this application examines the time interval between the current moment and the last handover moment before responding to the handover request. When the interval is too short, the handover is completed by recording the target network status, starting the anti-jitter timer, and delaying the execution. This prevents the network status from frequently flipping when the network quality fluctuates around the judgment threshold, avoiding resource consumption and repeated alarms caused by the constant starting and stopping of synchronization tasks, retry strategies, and notification channels due to repeated state changes. At the same time, the handover request is responded to immediately when the interval reaches the preset interval, so that jitter suppression does not come at the expense of the timeliness of state tracking, thus balancing the stability and sensitivity of state judgment.

[0020] Furthermore, it also includes: when the network status is degraded, retrying to report the alarm event to the central node; if the reporting still fails after the number of retries reaches a preset number, transferring the alarm event to the local database; when the network status is offline, stopping reporting to the central node, storing the alarm event in the local database, and sending alarm notifications through the local notification channel.

[0021] By adopting the above technical solutions, this application configures differentiated handling strategies for degraded and offline states: In the degraded state, retrying the report is performed first, and the report is only transferred to the local database after the number of retries reaches a preset number. This ensures that alarms are still reported in real time when the link still has some carrying capacity, and are only transferred to local storage when they are truly unreachable, thus balancing the timeliness and non-loss of alarms. In the offline state, reporting to the central node is stopped, avoiding resource consumption and queue expansion caused by continuously launching invalid requests to links that have been confirmed to be unreachable. At the same time, alarm notifications are sent through local database storage and local notification channels, so that alarms can still be perceived by operation and maintenance personnel during the period when the central node is unreachable, avoiding complete silence of alarms during this period.

[0022] This application also provides a notification deduplication method applied to a central node, comprising: obtaining the notification status of an alarm event, the notification status including the notification status reported by edge nodes and the notification status of the central node; and, in the case of triggering an alarm notification for an alarm event, determining whether to send an alarm notification for the alarm event based on the notification status.

[0023] By adopting the above technical solutions, this application enables the notification status used by the central node when triggering an alarm notification to simultaneously cover the notification status reported by the edge nodes and the notification status of the central node itself. This allows information on whether an alarm event has been notified on the edge side to participate in the notification decision on the central side, solving the problem of repeated notification of the same fault caused by the edge node sending a notification through the local notification channel in a degraded or offline state, and the corresponding alarm event being notified again by the central node after being supplemented and reported to the central node. By placing the deduplication determination in the notification triggering stage rather than the event storage stage, the alarm event itself is still completely preserved for traceability, while the notification presented to the outside is no longer repeated, thereby suppressing cross-node notification redundancy while ensuring data integrity.

[0024] Furthermore, based on the notification status, it is determined whether to send an alarm notification for the alarm event, including: if either the notification status reported by the edge node of the alarm event or the notification status of the central node indicates that the alarm event has been notified, skip sending the alarm notification for the alarm event; if both the notification status reported by the edge node of the alarm event and the notification status of the central node indicate that the alarm event has not been notified, send the alarm notification for the alarm event.

[0025] By adopting the above technical solution, this application uses the rule of skipping the sending if either of the two notification states has been notified, and sending only if both states have not been notified, so that the same alarm event is notified at most once on both the edge and center sides. This avoids the same fault being repeatedly notified due to the transfer of notification responsibility before and after the network state switch. At the same time, since the sending is only done when neither side has been notified, the alarm will still be sent normally even if neither side has completed the notification, ensuring that deduplication will not turn into missed notification, thus achieving a definite balance between duplicate notification and missed notification. Attached Figure Description

[0026] The above and other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0027] Figure 1 This illustration schematically depicts an application scenario of the alarm synchronization method and notification deduplication method according to embodiments of this application.

[0028] Figure 2 A flowchart illustrating an alarm synchronization method according to an embodiment of this application is shown schematically.

[0029] Figure 3 This illustration shows the principle of sequence information matching, missing interval division, and merging and compression reporting according to an embodiment of this application;

[0030] Figure 4This illustration schematically shows the principle of confirmation information verification retransmission and breakpoint resumption according to an embodiment of this application;

[0031] Figure 5 A schematic diagram illustrating the principle of network state switching according to an embodiment of this application is shown.

[0032] Figure 6 A flowchart illustrating the anti-shake determination process according to an embodiment of this application is shown schematically.

[0033] Figure 7 A flowchart illustrating a notification deduplication method according to an embodiment of this application is shown. Detailed Implementation

[0034] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0035] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0036] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0037] Regarding the issue of alarm data being difficult to keep consistent with the central node in distributed deployment scenarios, such as cloud-edge collaborative monitoring and alarm systems, the shortcomings of existing technologies are summarized as follows, based on the data synchronization scheme mentioned in the background technology, which involves local storage during link failures and overall back transmission after link recovery:

[0038] (1) The network status is binarized, lacking intermediate states that correspond to the actual carrying capacity of the links. Existing technologies describe the communication between edge nodes and central nodes using only two states: link connectivity and disconnection. As long as the link is not disconnected, it is considered to be in normal communication and is reported in the normal manner. Once the link is determined to be disconnected, reporting is completely stopped and all data is written to the local storage space.

[0039] (2) A synchronization surge occurs instantly upon recovery, and the synchronization range cannot converge. In existing technologies, all data generated during the disconnection period is accumulated in local storage space and then transmitted back in one go after the link is restored. The amount of data transmitted back is positively correlated with the duration of the disconnection. When the disconnection time is long, the amount of data that needs to be pushed to the central node at the moment of recovery is extremely large, which can easily cause the newly restored link to become congested again, the central node's receiving queue to accumulate, or even trigger timeouts again, resulting in a cycle of recovery, congestion, and re-interruption.

[0040] (3) Using the sending end's result as the criterion for determining synchronization completion can lead to unnoticed silent data loss. Current technology uses the success of the reporting request at the edge node as the criterion for determining whether data synchronization is complete. However, in situations such as link degradation, half-open connections at intermediate devices, overflow of the central node's receiving queue, or failure to store the data, the edge node may not receive any failure signal, even though the data has not actually been stored by the central node. Such losses are undetectable at the edge node and will not trigger any retransmission process, ultimately resulting in a long-term lack of alarms at the central node without anyone being aware of it.

[0041] (4) The notification responsibility is transferred before and after the state switch, resulting in the same fault being notified repeatedly. In order to avoid the alarms being completely silent during the period when the central node is unreachable, the edge nodes usually have the notification capability locally. However, after the link is restored, these alarms will be transmitted back to the central node and the central node will reissue the notification according to the unified policy. As a result, the same fault is notified twice or even more. It is difficult for the operation and maintenance personnel to determine whether it is a new fault or a repeated presentation of historical alarms, and the credibility of the alarms is weakened.

[0042] In view of this, this application proposes an alarm synchronization method and a notification deduplication method. By identifying a degraded state between online and offline states, edge nodes generate reporting sequence information in the order of reporting, and the central node generates receiving sequence information after actually receiving an alarm event. The two types of sequence information are matched to identify alarm events that failed to be reported during the degraded state and to supplement them, so that the synchronization range converges to the truly missing part, and the basis for determining synchronization changes from the request return result of the sender to the actual reception result of the receiver. At the same time, by enabling the central node to determine the alarm notification based on both the notification status reported by the edge nodes and the notification status of the central node itself, the duplicate notification of the same alarm event between the edge side and the central side is suppressed.

[0043] Figure 1 The diagram illustrates an application scenario of the alarm synchronization method and notification deduplication method according to embodiments of this application.

[0044] like Figure 1As shown, the application scenario according to this embodiment may include a central node 101, a network 102, and multiple edge nodes 103. The network 102 is used as a medium to provide communication links between the central node 101 and each edge node 103. The network 102 may include various connection types, such as wired or wireless communication links or fiber optic cables, and may also include public networks, leased lines, and wide area links across regions.

[0045] Edge node 103 can be a server, edge server, edge computing box, or edge cluster composed of several devices deployed in field locations such as data centers, parks, factories, stores, and base stations. It runs data collection and alarm generation components to collect data on field-side devices, hosts, containers, network links, and business metrics, and generates alarm events when the collected values ​​trigger preset alarm rules. Alarm events can include fields such as event identifier, alarm object identifier, alarm metric, alarm level, alarm content, and generation time. Edge node 103 is also configured with a local database and a local notification channel. The local database is used to retain alarm events when they cannot be delivered to the central node 101, and the local notification channel is used by edge node 103 to directly send alarm notifications to field-side maintenance personnel when the central node 101 is unreachable.

[0046] The central node 101 can be a server providing various services, such as a management server that provides alarm aggregation and storage, unified alarm display, unified alarm notification, and cross-node data consistency maintenance for the distributed monitoring system (this is just an example). The central node 101 receives alarm events reported by multiple edge nodes 103 and stores them in the central database, while simultaneously sending alarm notifications to the recipients according to a unified notification strategy. Alarm reporting between edge nodes 103 and the central node 101 is conducted via network 102, and fluctuations in the quality of network 102 directly determine the network status of the edge nodes 103.

[0047] It should be noted that the alarm synchronization method provided in this application embodiment can generally be executed by the edge node 103, and the notification deduplication method provided in this application embodiment can generally be executed by the central node 101. The alarm synchronization method provided in this application embodiment can also be executed by a node in the edge cluster where the edge node 103 is located, which plays the role of a reporting agent, and the notification deduplication method provided in this application embodiment can also be executed by a server or server cluster that is different from the central node 101 and can communicate with both the central node 101 and the edge node 103.

[0048] It should be understood that Figure 1 The number of central nodes, networks, and edge nodes shown is merely illustrative. Depending on implementation needs, there can be any number of central nodes, networks, and edge nodes.

[0049] The following will be based on Figure 1 The described scene, through Figures 2-7 The alarm synchronization method and notification deduplication method according to the embodiments of this application are described in detail.

[0050] Figure 2 A flowchart illustrating an alarm synchronization method according to an embodiment of this application is shown.

[0051] like Figure 2 As shown, the alarm synchronization method according to this embodiment is applied to an edge node and may include operations S210 to S230.

[0052] In operation S210, when the network status is in a degraded state, a reporting sequence information is generated according to the order in which multiple alarm events are reported to the central node. The degraded state is a network status in which the reporting between the edge node and the central node is not interrupted but the reporting quality does not meet the preset conditions.

[0053] According to embodiments of this application, network state is a representation of the communication status between edge nodes and the central node. It can be determined by the edge nodes based on objective quantities observed during the reporting process, without relying on external instructions. Degraded state is a network state identified in embodiments of this application, meaning that the reporting action between the edge nodes and the central node is still in progress and has not been interrupted, but the reporting quality no longer meets preset conditions. The reporting quality can be characterized by one or more indicators such as round-trip latency, reporting success rate, and reporting timeout occurrence. The preset conditions can correspondingly be that the round-trip latency is lower than a latency threshold, the reporting success rate is not lower than a ratio threshold, and the number of reporting timeouts per unit time does not exceed a number threshold. These thresholds can be configured according to the actual quality of the link and the timeliness requirements of alarms. In a degraded state, although the link can carry some reporting, it can no longer guarantee that every report will be reliably received by the central node. Therefore, this state is different from both the situation where reporting can be reliably carried and the situation where reporting is completely impossible.

[0054] In degraded state, edge nodes generate reporting sequence information for each alarm event according to the order in which multiple alarm events are reported to the central node. The reporting sequence information identifies the position of a particular alarm event within the reporting order of that edge node. For example, it can be implemented as a monotonically increasing and non-repeating sequence number within the edge node. When an edge node delivers an alarm event for reporting, it assigns the current sequence number and then increments it, thus ensuring a one-to-one correspondence between the reporting sequence information and the reporting action, strictly reflecting the order of reporting. The reporting sequence information and the corresponding alarm event are persistently stored on the edge node and reported to the central node along with the alarm event, enabling the central node to identify which edge node the alarm event originated from and its position in the reporting order of that edge node. In some embodiments, the reported sequence information can also be composed of edge node identifiers and incremental sequence numbers, so that the reported sequence information generated by multiple edge nodes will not be confused with each other on the central node side; in other embodiments, the reported sequence information can also be generated by a distributed identifier generation method that integrates timestamps and node identifiers, as long as it remains monotonically increasing within the same edge node.

[0055] Because the reported sequence information is persisted at the time of generation, the exact reports initiated by the edge node in the degraded state, and the continuous sequence intervals covered by these reports, can be completely restored afterward, thus giving each reporting action a traceable location identifier.

[0056] In operation S220, the received sequence information sent by the central node is obtained. The received sequence information is the sequence information generated by the central node after receiving the alarm event reported by the edge node.

[0057] According to embodiments of this application, the received sequence information is the sequence information generated by the central node after it actually receives the alarm event reported by the edge node. It is generated after the alarm event is received and stored on the central node's side, not when the central node receives the reporting request. In one implementation, the central node records the reporting sequence information reported along with the alarm event as the received sequence information of that alarm event, thus placing the two types of sequence information in the same sequence space and allowing direct comparison. In another implementation, the central node generates central-side sequence information for the stored alarm event, establishes a correspondence between it and the reporting sequence information carried by the alarm event, and records them together. The central node summarizes the received sequence information of the stored alarm events according to the edge node identifier to obtain the set of sequence information that the edge node has actually received and stored by the central node.

[0058] Edge nodes can acquire the received sequence information in two ways: First, they can actively request it, sending a query request to the central node along with their own identifier and the range of sequences to be queried. The central node then returns the stored received sequence information within that range. Second, they can passively receive the information, periodically or when a change in reception is detected, sending the stored received sequence information to the corresponding edge nodes. The received sequence information can be organized as a list of sequences, an endpoint representation of several consecutive intervals, or a bitmap representation to reduce transmission overhead.

[0059] In operation S230, the reported sequence information and the received sequence information are matched to determine the alarm events that failed to be reported during the degraded state, and the alarm events that failed to be reported are reported to the central node.

[0060] According to an embodiment of this application, the edge node matches the locally persisted reporting sequence information with the acquired receiving sequence information item by item: for a certain reporting sequence information, if a corresponding item exists in the receiving sequence information, it indicates that the alarm event corresponding to the reporting sequence information has been actually received and stored by the central node; if no corresponding item exists in the receiving sequence information, it indicates that although the alarm event corresponding to the reporting sequence information has been initiated for reporting, it has not been received and stored by the central node, that is, the alarm event failed to be reported during the degraded state. Based on this, the edge node reads the aforementioned failed alarm events from the locally stored alarm events and reports them to the central node, thereby enabling the central node to complete the alarm events.

[0061] The aforementioned matching transforms the judgment criterion from the sender's request return result to the receiver's actual reception result. For alarm events caused by link degradation, half-open connections of intermediate devices, overflow of the central node's receiving queue, or failure to submit data to the database, where the edge node does not receive any failure signal but is not actually received by the central node, their reporting sequence information is inevitably missing in the receiving sequence information. Therefore, they will also be identified by the matching process and included in the supplementary reporting scope, solving the problem that such data loss is unknown to the edge node. At the same time, since the supplementary reporting object is limited to alarm events that are determined to have failed to be reported after matching, alarm events that have successfully reached the central node are no longer retransmitted, and the amount of supplementary data is converged to the truly missing part.

[0062] By adopting the above technical solutions, this application identifies the degraded state, ensuring that the interval where the link is not disconnected but can no longer reliably carry reports is no longer mistaken for normal communication, thus preventing alarm losses in this interval from remaining unnoticed for a long time. By generating reporting sequence information according to the reporting order in the degraded state, each reporting action has a traceable location identifier, providing a basis for determining the scope of loss afterward. By introducing the receiving sequence information generated by the central node after actually receiving the alarm event and matching it with the reporting sequence information on the edge node side, the basis for determining whether a loss has occurred changes from the request return result of the sending end to the actual receiving result of the receiving end. This enables the identification of alarm events where the edge node side did not receive any failure signal but was not actually received by the central node, solving the problem that such losses are unknown to the edge node side. By only supplementing the reporting of alarm events that are determined to be reporting failures after matching, the amount of data for the recovery action is converged to the truly missing part, avoiding the secondary impact of full retransmission on the already degraded link and the alarm noise caused by repeated reporting, thus ensuring the final integrity of alarm data during the degraded period without increasing the link burden.

[0063] In order to adapt the supplementary reporting process to the current carrying capacity of the degraded link, and to further reduce the amount of supplementary reporting data and suppress repeated notifications from downstream after the supplementary reporting is completed, the embodiments of this application make further designs for the determination and reporting process of alarm events that fail to be reported.

[0064] Based on this Figure 3 The illustration shows a schematic diagram illustrating the principle of sequence information matching, missing interval division, and merging and compression reporting according to an embodiment of this application.

[0065] like Figure 3As shown, the diagram illustrates the processing layers from matching to reporting along the sequence direction from top to bottom: one layer uses multiple grids arranged sequentially along the sequence direction to represent the reporting sequence information generated by edge nodes during the degradation state. Each grid corresponds to an alarm event and its reporting sequence information, and the order of the grids indicates the order of reporting. The other layer uses the presence or absence of a marker at the corresponding grid to represent the received sequence information returned by the central node. A marked grid indicates that the reported sequence information has a corresponding item in the received sequence information, that is, the corresponding alarm event has been received and stored by the central node. An unmarked grid indicates that the reported sequence information has a corresponding item in the received sequence information. The bit indicates that the reported sequence information does not have a corresponding item in the received sequence information; the next layer uses segments defined by unmarked grid bits to indicate the data missing intervals converged from the above differences; the next layer uses several adjacent segments to indicate the division of the data missing intervals according to a preset number of alarm events for each interval; the bottom layer uses merge boxes and data packet frames to indicate the merging of alarm events of the same type within the same time window in the interval and the data packet formed after the content in the interval is compressed, and the range label on the data packet frame indicates the range of the reported sequence information of the interval carried by the data packet. Figure 3 The number of cells, the distribution of marked cells, and the number of intervals are all illustrative and do not represent specific sequence numbers and values.

[0066] In some embodiments, the above operation S230, which matches the reported sequence information and the received sequence information to determine the alarm events that failed to be reported during the degraded state, and reports the alarm events that failed to be reported to the central node, can be further implemented as follows.

[0067] According to an embodiment of this application, firstly, a data missing interval is determined based on the reported sequence information and the received sequence information. The data missing interval is defined by sequence information present in the reported sequence information but not in the received sequence information. Edge nodes can use the locally persisted reported sequence information as the complete set and the acquired received sequence information as the arrived set, calculate the difference between the two, and group the sequence information in the difference set into one or more continuous intervals according to the continuity of the sequence information, thus obtaining the data missing interval.

[0068] Secondly, the data missing interval is divided into multiple intervals according to a preset number of alarm events per interval. The preset number is the upper limit of the number of alarm events that can be accommodated in a single interval, and its value can be configured and adjusted according to the link quality: when the link quality is good, the preset number can be configured to be larger, for example, 500, to reduce the number of interactions; the higher the degree of link degradation, the smaller the preset number can be configured, for example, adjusted to 100, so that the single reported message is smaller and easier to be successfully carried. During the division, the edge node arranges each alarm event in the data missing interval according to the order of the reported sequence information, and divides it sequentially by dividing it into intervals after each preset number of alarm events is reached. The number of alarm events contained in the last interval can be less than the preset number. In some embodiments, the data missing interval can also be divided into intervals according to the preset number within each consecutive segment, so that the reported sequence information within each interval remains continuous.

[0069] Secondly, alarm events within multiple intervals are compressed sequentially and reported to the central node. Edge nodes compress alarm events within intervals and report them to the central node, with multiple intervals progressing sequentially in ascending order of the reporting sequence information. The next interval is only advanced after the previous one is reported and confirmed, ensuring that the amount of supplementary data on the link at any given time never exceeds one interval. Compression can employ lossless compression methods, such as serializing the content within an interval into a text format (e.g., JSON) and then compressing it using the gzip algorithm, or using other lossless compression algorithms such as zstd. Because alarm events have high similarity in field structure and values, the compressed message size is usually significantly smaller than the uncompressed size. In some embodiments, a sending interval can be set between intervals, or the preset number of subsequent intervals can be dynamically adjusted based on the reporting time of the previous interval, further aligning the supplementary reporting rhythm with the current carrying capacity of the link.

[0070] By adopting the above technical solution, this application first converges the missing data intervals from the matching results of the two types of sequence information, and then divides the missing intervals into multiple intervals according to the preset number of alarm events for each interval and compresses and reports them interval by interval, so that the amount of data reported at one time is always within a controllable range, avoiding repeated timeout failures due to excessively large single packets on links with reduced carrying capacity; at the same time, using intervals as the basic unit of supplementary reporting makes the supplementary reporting process have a structure that can be promoted and confirmed in segments, and the compression further reduces the bandwidth occupation of supplementary reporting on the link, so that the data catch-up in the degraded state can be completed smoothly at a pace that is adapted to the current carrying capacity of the link.

[0071] Furthermore, such as Figure 3 As shown in the bottom layer, in some embodiments, the above-mentioned process of compressing alarm events in multiple intervals sequentially and reporting them to the central node can be further implemented as follows.

[0072] According to an embodiment of this application, firstly, multiple alarm events within an interval whose occurrence time falls within the same time window and indicate the same event type are merged to obtain a merged event. The time window is used to define the length of a short period; its value can be configured according to the alarm generation density. Alarm events within an interval are assigned to the corresponding time window based on their occurrence time. The event type is used to characterize the fault condition reflected by the alarm event and can be identified by one or more of the alarm object identifier, alarm indicator, and alarm level. For example, multiple alarm events on the same host with the same indicator exceeding the limit and the same level are considered to indicate the same event type. For multiple alarm events whose occurrence time falls within the same time window and indicate the same event type, the edge node merges them into a single merged event, such as... Figure 3 The merged event is represented by a group of adjacent cells converging into a single frame. The merged event can include common event type information shared by the group of alarm events, the occurrence times of the first and last alarm events in the group, the number of alarm events participating in the merge, and the reporting sequence information of each alarm event participating in the merge. This reduces the number of transmitted data entries while retaining the necessary information for reconstruction. The alarm content of the merged event can be represented in summary form, such as "[Alarm Object][Alarm Indicator] occurred N times within X minutes".

[0073] In some embodiments, the above-mentioned merging can be implemented in any one or more of the following ways.

[0074] The first method is to merge by full match, which means merging multiple alarm events within the interval that have the same data source identifier, alarm object identifier, alarm index and alarm level, and whose generation time is within the same time window into a single merged event. The time window can be a fixed time window of 1 minute, for example.

[0075] The second method is to merge by identifier pattern, that is, to match the alarm object identifiers according to a preset character pattern, and merge multiple alarm events that match the same character pattern and have the same alarm index and alarm level into a single merged event within the same time window. The character pattern can be, for example, the regular expression ^web-server-\d+$, and the time window can be, for example, a 5-minute sliding time window. In this case, the content of the merged event can include a list of affected alarm objects and the number of alarm objects, thereby expressing the same fault of the same batch of similar alarm objects as a single merged event.

[0076] The third method is to merge based on relationships. This involves using configuration information describing the upstream and downstream relationships between alarm objects (such as topological relationships maintained by the configuration management database) to determine the root cause alarm object along the upstream direction among multiple alarm events within an interval. If the root cause alarm object has alarm events, then the alarm events of its downstream alarm objects are merged into the alarm events of the root cause alarm object as derived alarm events. The content of the merged event can be represented in the form of "[root cause alarm object] failure caused N downstream alarm objects to be abnormal", thus expressing a cluster of alarms caused by the same root cause as a single merged event.

[0077] The above three methods can also be executed in sequence: first merge by exact match, then merge the merged results by identifier pattern, and finally merge by association.

[0078] Secondly, the merged events and the alarm events within the interval that were not merged are compressed according to the order of the reported sequence information to obtain the data packets corresponding to the interval. The data packets carry the range of the reported sequence information corresponding to the interval. Alarm events that were not merged within the interval refer to alarm events for which no other alarm events of the same type exist within their respective time windows; these alarm events are processed as is. The edge nodes then compress the merged events and the alarm events that were not merged according to the order of the reported sequence information to obtain the data packets corresponding to that interval.

[0079] Next, the data packets are reported sequentially to the central node. The edge nodes report the data packets corresponding to each interval to the central node in interval order. After receiving the data packets, the central node decompresses them, restores and stores the alarm events represented by the merged events, and verifies the integrity of the received data based on the range of the reporting sequence information carried by the data packets.

[0080] By adopting the above technical solutions, this application first merges multiple alarm events that occur within the same time window and have the same event type before compression. This allows repeated alarms caused by the same fault source within a short period of time to be converged into merged events during the supplementary reporting stage. This reduces the amount of data that needs to be transmitted and also reduces the possibility of a large number of duplicate notifications being generated downstream after the supplementary reporting is completed. By compressing the merged events and the alarm events that did not participate in merging into data packets according to the order of the reporting sequence information, the event order within the data packets is kept consistent with the original reporting order, which facilitates the central node to process them in sequence. By making the data packets carry the range of the corresponding reporting sequence information, the central node can clearly know the sequence range that the data packets should cover, providing a comparable benchmark for the integrity verification of the receiving side and subsequent confirmation and secondary supplementary reporting.

[0081] In order to ensure that the re-reporting process itself can also detect the possible loss on the degraded link, and to make the re-reporting progress accumulate unidirectionally when the network fluctuates repeatedly, the embodiments of this application make further designs on the processing after the data packet is reported.

[0082] Based on this Figure 4 The illustration shows a schematic diagram illustrating the principle of confirmation information verification retransmission and breakpoint resumption according to an embodiment of this application.

[0083] like Figure 4 As shown, Part A of the diagram uses bidirectional arrows between edge nodes and the central node to illustrate the reporting of data packets and the return of acknowledgment information, as well as the verification and retransmission based on this: an arrow from the edge node to the central node indicates that a data packet corresponding to a certain interval is reported; an arrow from the central node to the edge node indicates the acknowledgment information returned by the central node after decompression and storage; the verification diagram between the two indicates that the edge node compares the range of the reported sequence information carried by the data packet with the received sequence information in the acknowledgment information item by item, and marks the cell within that range where there is still no corresponding received sequence information. This cell is the target reported sequence information. Subsequently, another arrow from the edge node to the central node indicates the re-reporting initiated for the alarm event corresponding to the target reported sequence information. Part B of the diagram uses a progress diagram extending along the sequence direction to represent the synchronization progress information. The intervals that have been reported and the reported positions within the currently reported interval are marked respectively. An interruption mark indicates that the reporting was interrupted at that position and the progress is retained. The subsequent breakpoint mark and the continue reporting arrow indicate that the progress will continue from that breakpoint position after the network status is restored. Figure 4 The grid positions, intervals, interruption positions, and breakpoint positions shown are for illustrative purposes only and do not represent specific sequence numbers.

[0084] First, the central node receives confirmation information. According to embodiments of this application, the confirmation information includes the received sequence information of target alarm events from edge nodes that the central node has stored. After completing the decompression and storage of a data packet, the central node returns confirmation information to the edge node. The content of the confirmation information is not a general result that the data packet has been received, but rather the received sequence information of target alarm events from the edge node that the central node has stored. That is, the received sequence information corresponding to those alarm events that the central node has indeed stored within the sequence range covered by the data packet. The target alarm events are the alarm events that have been stored by the central node, and their received sequence information can be carried in the confirmation information in the form of a list, continuous interval endpoints, or a bitmap.

[0085] Secondly, based on the range of reported sequence information carried by the data packet and the received sequence information, the target reported sequence information that the central node has not stored within the range is determined. According to an embodiment of this application, the edge node uses the range of reported sequence information carried by the data packet as the scope to be verified, and compares each reported sequence information within this range with the received sequence information in the confirmation information item by item. Reported sequence information that still does not have a corresponding received sequence information within this range after comparison is the target reported sequence information, and the corresponding alarm event is the alarm event that was again not stored by the central node during this supplementary reporting process. Figure 4 As shown in the diagram, the target can report one or more sequence information within the range covered by the data packet.

[0086] Secondly, if an alarm event corresponding to the target reported sequence information exists in the alarm events stored at the edge node, the alarm event corresponding to the target reported sequence information is re-reported to the central node. The edge node searches for the alarm event corresponding to the target reported sequence information in the alarm events stored locally. If it exists, it re-reports it to the central node. After re-reporting, it continues to receive confirmation information, verify, and re-report again if necessary, in the manner described above, until no more target reported sequence information exists within that range.

[0087] By adopting the above technical solutions, this application further receives the confirmation information returned by the central node containing the stored events after the supplementary reporting action is completed, and compares it again with the sequence range carried by the data packet. This ensures that the supplementary reporting process itself can also detect the possible loss on the degraded link, forming a closed loop of reporting, verification, and rereporting. By clarifying the judgment standard as whether the central node has stored the data rather than whether the edge node has successfully sent it, the determination of data consistency is always based on the landing result of the receiving end, avoiding misjudgment caused by considering successful transmission as synchronization completion. By performing rereporting only when the corresponding alarm event still exists locally, the rereporting action is limited to the range that can be truly supplemented, avoiding invalid retries for events that have already been cleared.

[0088] In some embodiments, in addition to the aforementioned direction of filling in missing data from the edge node to the central node, the edge node can also perform a continuity check on the reporting sequence information corresponding to the alarm events stored locally to repair data loss on the local side. After synchronization is complete, the edge node can sequentially traverse the local reporting sequence information. If there is a gap between two adjacent reporting sequence information, the reporting sequence information corresponding to that gap is determined as the locally missing reporting sequence information. For example, if the local reporting sequence information is 100, 101, 103, and 104, then the locally missing reporting sequence information is determined to be 102 (the numbering here is only an example). The edge node initiates a pull request to the central node, carrying the locally missing reporting sequence information. The central node returns the alarm events it has stored corresponding to the reporting sequence information, and the edge node writes them to its local database. Thus, data loss caused locally by edge nodes due to write anomalies, local storage media failures, etc., can be repaired using data from the central node, ensuring bidirectional consistency between the data on both the edge node and the central node.

[0089] Furthermore, such as Figure 4 As shown in the progress diagram, in some embodiments, the above method can be further implemented as the following process.

[0090] During the sequential reporting of alarm events across multiple intervals, synchronization progress information is recorded. This synchronization progress information includes the reporting sequence information of completed intervals and the reporting sequence information of reported alarm events within the currently reporting interval. According to embodiments of this application, the synchronization progress information is used to characterize the current position of the supplementary reporting process, with its granularity refined to individual alarm events within the interval. The synchronization progress information records, on the one hand, the reporting sequence information of completed intervals, for example, the range of the reporting sequence information of completed intervals or the last reported sequence information; on the other hand, it records the reporting sequence information of reported alarm events within the currently reporting interval, for example, the reporting sequence information of the most recently confirmed completed alarm event within the current interval. This record is equivalent to a checkpoint left locally by the supplementary reporting process. The synchronization progress information is updated as the supplementary reporting progresses and is persistently stored on the edge node (e.g., in the aforementioned local database), thus preventing loss due to process restarts.

[0091] In the event of a reporting interruption, the synchronization progress information is retained. Once the network status switches back to online or degraded state, the reporting breakpoint is determined based on the synchronization progress information, and alarm events are continued to be reported to the central node from that breakpoint. According to embodiments of this application, the reporting interruption can be caused by factors such as complete link unreachability, edge node restart, or network status switching. When reporting is interrupted, the edge node does not clear the synchronization progress information but retains it completely. Once the network status switches back to online or degraded state, i.e., reporting becomes feasible again, the edge node reads the retained synchronization progress information, skips the already reported intervals, and determines the breakpoint within the current reporting interval as the position corresponding to the next alarm event after the previously reported alarm event. Figure 4 The breakpoint position after the interrupt marker indicates that alarm events will continue to be reported to the central node from this breakpoint position, and previously confirmed content will not be transmitted again.

[0092] By adopting the above technical solution, this application simultaneously records the reporting sequence information of completed intervals and reported events in the current interval during the interval-by-interval supplementary reporting process, so that the synchronization progress is refined to the granularity of individual events within the interval; by retaining the synchronization progress information when the reporting is interrupted and determining the breakpoint position to continue reporting after the network status recovers to online or degraded status, the supplementary reporting process has the ability to resume transmission from the breakpoint, avoiding repeated transmission and time waste caused by having to start over from the starting point of the missing interval due to interruption, so that the synchronization progress can still accumulate unidirectionally and gradually converge even in scenarios with repeated network fluctuations.

[0093] In order to make network status determination based on objective quantities that edge nodes can observe themselves, to provide a transitional phase specifically for catching up on alarm events that have accumulated during offline periods, and to match alarm handling strategies under different network statuses with the link carrying capacity corresponding to that status, this application embodiment makes further designs on the composition of network status, switching conditions and handling actions under each status.

[0094] Based on this Figure 5 A schematic diagram illustrating the principle of network state switching according to an embodiment of this application is shown.

[0095] like Figure 5As shown, the diagram uses three state elements to represent online, degraded, and offline states, with transition arrows labeled with conditions indicating the switching relationships between states: The transition arrow from online to degraded state indicates that the number of consecutive reporting timeouts has exceeded a first preset number; the transition arrow from degraded state to offline state indicates that the number of consecutive alarm event reporting failures has exceeded a second preset number, or the number of alarm events waiting to be reported in the retry queue has exceeded a preset threshold; the transition arrow from offline to degraded state indicates that network detection of the central node has been successful; and the transition arrow from degraded state to online state indicates that communication has returned to normal and alarm events have been synchronously completed. Each state element also indicates the action performed in that state: in online state, reporting is performed in real-time as usual; in degraded state, reporting sequence information is generated and reporting is retried; if the number of retries reaches a preset number and still fails, the information is transferred to the local database and the matching and supplementary reporting process described above begins; in offline state, reporting stops, information is stored in the local database, and alarm notifications are sent through the local notification channel.

[0096] In some embodiments, the network state includes an online state, a degraded state, and an offline state. According to embodiments of this application, the online state is a network state in which reporting between edge nodes and the central node can be reliably carried; the degraded state is a network state in which reporting is uninterrupted but the reporting quality does not meet preset conditions; and the offline state is a network state in which edge nodes have stopped reporting to the central node. The above method may further include the following state switching process.

[0097] If the network is in an online state and the number of consecutive timeouts between the network and the central node exceeds a first preset number, the network state will be switched to a degraded state. Edge nodes, while in an online state, statistically analyze each reported result. When the number of consecutive timeouts exceeds the first preset number, it indicates that the link, although still connected, can no longer stably support reporting. Therefore, the network switches to a degraded state and begins generating reporting sequence information as described above. Using the number of consecutive timeouts, rather than a single timeout, as the trigger condition avoids state changes caused by occasional single timeouts. The value of the first preset number can be configured according to the link's jitter characteristics; for example, it can be 3 times. As mentioned earlier, the number of timeouts can be accumulated from the response results of reporting requests carrying alarm events or from the response results of periodic probe messages. For example, if the probe period is 30 seconds, three consecutive probes without a response correspond to approximately 90 seconds of continuous degradation, at which point the network switches to a degraded state.

[0098] When the network status is degraded and alarm events fail to be reported consecutively for the second preset number of times, or the number of alarm events waiting to be reported in the retry queue exceeds a preset threshold, the network status is switched to offline status. The retry queue is a queue that caches alarm events that need to be re-reported. The retry queue caches alarm events that failed to be reported in the degraded state and need to be re-reported. When the number of consecutively failed alarm events reaches the second preset number (e.g., 5), or the number of alarm events waiting to be reported in the retry queue exceeds a preset threshold (e.g., 1000), it indicates that the link is substantially unusable or the backlog has exceeded the capacity of the degraded state. Continuing to attempt reporting will only exacerbate the backlog, so the network is switched to offline status. The above two conditions are related as an OR condition; the former reflects the immediate status of the link, and the latter reflects the cumulative degree of backlog. Both conditions cover both sudden link deterioration and long-term link weakness. The values ​​of the second preset number of times and the preset threshold can be configured according to the resource specifications of the edge nodes.

[0099] If the network status is offline and network probe to the central node is successful, the network status is switched to a degraded state. In the offline state, edge nodes have stopped reporting, and therefore cannot perceive link status through reporting results. At this time, edge nodes can periodically initiate network probes to the central node. The probe period can be, for example, 30 seconds. Probe methods can include initiating a lightweight Hypertext Transfer Protocol (HTTP) request to the central node's health check interface, connectivity probes based on Internet Control Message Protocol (ICP), or using the Transmission Control Protocol (TCP) keepalive mechanism to determine if the connection is still available. A successful probe indicates that the link has regained its carrying capacity. Instead of directly switching to an online state, it first switches to a degraded state, providing a dedicated transition phase for catching up on alarm events that accumulated in the local database during the offline period.

[0100] When the network status is in a degraded state, and communication has returned to normal and alarm events have been synchronized, the network status will be switched to online. Normal communication can be demonstrated by the reporting quality meeting preset conditions again, such as multiple consecutive successful reports and reporting round-trip latency below a latency threshold. Alarm event synchronization can be demonstrated by the absence of missing data intervals according to the above matching process and the clearing of the retry queue. The network will only switch to online status when both of these conditions are met simultaneously, thus constraining the meaning of online status to include a normal link and data recovery.

[0101] By adopting the above technical solutions, this application provides specific triggering conditions for the transition between online, degraded, and offline states, based on the number of consecutive reporting timeouts, the number of consecutive reporting failures, the backlog of the retry queue, and the network probe results. This allows state determination to be based on objective quantities that edge nodes can observe themselves without relying on external commands. By switching from offline to degraded state first after a successful probe, rather than directly switching to online state, a dedicated transition phase is provided for backlogged alarm events during offline periods to catch up, avoiding the situation where the state is considered completely normal immediately after connectivity is restored, thus leaving backlogged data behind. By requiring the degraded state to switch to online state only when both conditions are met—communication is restored to normal and alarm events are completed synchronously—the meaning of online state is constrained to data recovery, avoiding data loss caused by prematurely setting the state to online before link indicators are restored and missing data is replenished.

[0102] Furthermore, such as Figure 5 As indicated by the actions marked within each state element, in some embodiments, the above method may further include: when the network status is in a degraded state, retrying to report the alarm event to the central node; if the reporting still fails after a preset number of retries, transferring the alarm event to the local database; when the network status is offline, stopping reporting to the central node, storing the alarm event in the local database, and sending an alarm notification through the local notification channel.

[0103] In degraded mode, edge nodes can still primarily report newly generated alarm events in real time. Alarm events that fail to be reported are placed in a retry queue and retried a preset number of times, such as 3 times. The retry interval can be progressively increased, for example, 1 second, 2 seconds, and 4 seconds, to avoid further exacerbating link congestion with frequent retries. Alarm events that still fail to be reported after the preset number of retries are transferred to a local database, awaiting replenishment according to the matching and supplementary reporting process described above. This ensures that the retry queue is not occupied for an extended period, nor are they discarded. In offline mode, edge nodes stop reporting to the central node to avoid continuously initiating invalid requests to links that have been confirmed as unreachable. Newly generated alarm events are directly stored in the local database, and alarm notifications are sent to on-site maintenance personnel through a local notification channel. The recipients can be determined based on the receiving object configuration information cached locally on the edge node, and the sending exit can be a backup gateway on the on-site side (e.g., an internal mail server).

[0104] By adopting the above technical solutions, this application configures differentiated handling strategies for degraded and offline states: In the degraded state, retrying the report is performed first, and the report is only transferred to the local database after the number of retries reaches a preset number. This ensures that alarms are still reported in real time when the link still has some carrying capacity, and are only transferred to local storage when they are truly unreachable, thus balancing the timeliness and non-loss of alarms. In the offline state, reporting to the central node is stopped, avoiding resource consumption and queue expansion caused by continuously launching invalid requests to links that have been confirmed to be unreachable. At the same time, alarm notifications are sent through local database storage and local notification channels, so that alarms can still be perceived by operation and maintenance personnel during the period when the central node is unreachable, avoiding complete silence of alarms during this period.

[0105] To prevent the network state from frequently switching when the network quality fluctuates around the judgment threshold, this application also designs an anti-jitter mechanism for network state switching.

[0106] Based on this Figure 6 A flowchart illustrating the anti-shake determination process according to an embodiment of this application is shown.

[0107] like Figure 6 As shown, in some embodiments, the above method may further include: when a network state switching request is received, determining the time interval between the current time and the last time the network state switching was performed; if the time interval is less than a preset interval, recording the target network state indicated by the switching request and starting a jitter timer, and switching the network state to the target network state after the jitter timer expires; if the time interval is greater than or equal to the preset interval, responding to the switching request and performing a network state switching.

[0108] Edge nodes can maintain the time of the last network state transition, whenever... Figure 5 When any of the switching conditions shown is met and a network state switching request is generated, the process enters... Figure 6The determination process is as follows: First, calculate the time interval between the current moment and the previous moment, and compare it with a preset interval. The value of the preset interval can be configured according to the jitter period of the link, for example, 30 seconds. If the time interval is less than the preset interval, the handover is not performed immediately. Instead, the target network state indicated by the handover request is recorded and a jitter timer is started. The duration of the timer can be the difference between the preset interval and the current time interval. After the jitter timer expires, the network state is switched to the recorded target network state. If another handover request is generated during the jitter timer's operation, the target network state indicated by the latest handover request can be used to overwrite the previously recorded target network state, so that the delayed handover is based on the latest observation result. If the time interval is greater than or equal to the preset interval, the handover request is responded to immediately, and the network state is switched, and the time of this handover is updated to the time of the last network state switch, so that the state keeps up-to-date.

[0109] By adopting the above technical solution, this application examines the time interval between the current moment and the last handover moment before responding to the handover request. When the interval is too short, the handover is completed by recording the target network status, starting the anti-jitter timer, and delaying the execution. This prevents the network status from frequently flipping when the network quality fluctuates around the judgment threshold, avoiding resource consumption and repeated alarms caused by the constant starting and stopping of synchronization tasks, retry strategies, and notification channels due to repeated state changes. At the same time, the handover request is responded to immediately when the interval reaches the preset interval, so that jitter suppression does not come at the expense of the timeliness of state tracking, thus balancing the stability and sensitivity of state judgment.

[0110] In cases where an edge node sends an alarm notification through a local notification channel while the central node is unreachable, the corresponding alarm event will still be reported to the central node after the network status recovers. If the central node sends a notification again according to the unified notification policy, the same fault will be reported repeatedly. To address this, this application also provides a notification deduplication method.

[0111] Figure 7 A flowchart illustrating a notification deduplication method according to an embodiment of this application is shown.

[0112] like Figure 7 As shown, the notification deduplication method according to this embodiment is applied to the central node and may include operations S710 to S720.

[0113] When operating the S710, obtain the notification status of alarm events. The notification status includes the notification status reported by edge nodes and the notification status of the central node.

[0114] According to embodiments of this application, the notification status is used to characterize whether an alarm event has been notified to the operations and maintenance personnel. It encompasses two sources: first, the notification status reported by the edge node, i.e., the status generated by the edge node after issuing an alarm notification for the alarm event through its local notification channel during a period when the central node is unreachable, and reported to the central node along with the alarm event; second, the notification status of the central node, i.e., whether the central node itself has previously issued an alarm notification for the alarm event. The central node can maintain a notification status record for alarm events, which includes an event identifier, a notification status field reported by the edge node, and a notification status field of the central node. The values ​​of these two fields indicate whether the alarm event has been notified on the edge side and the central side, respectively. In some embodiments, the notification status record may also include a source field to identify which side ultimately completed the notification, for traceability. When the central node receives an alarm event reported by an edge node, it writes the notification status carried by the edge node into the corresponding field; after issuing its own alarm notification, it updates the notification status field of the central node.

[0115] When operating the S720, if an alarm notification for an alarm event is triggered, the system determines whether to send an alarm notification for the alarm event based on the notification status.

[0116] According to an embodiment of this application, when a central node triggers an alarm notification for a specific alarm event according to a unified notification strategy, it first obtains the aforementioned notification status of the alarm event and determines whether to actually send an alarm notification for that alarm event, instead of unconditionally sending it simply based on whether the alarm event has newly arrived at the central node. Thus, information about whether the alarm event has already been notified at the edge can participate in the notification decision at the central side. It should be noted that the aforementioned deduplication determination is placed in the notification triggering stage; the alarm event itself is still fully stored at the central node for querying, statistics, and tracing. Only duplicate notifications sent externally are suppressed.

[0117] By adopting the above technical solutions, this application enables the notification status used by the central node when triggering an alarm notification to simultaneously cover the notification status reported by the edge nodes and the notification status of the central node itself. This allows information on whether an alarm event has been notified on the edge side to participate in the notification decision on the central side, solving the problem of repeated notification of the same fault caused by the edge node sending a notification through the local notification channel in a degraded or offline state, and the corresponding alarm event being notified again by the central node after being supplemented and reported to the central node. By placing the deduplication determination in the notification triggering stage rather than the event storage stage, the alarm event itself is still completely preserved for traceability, while the notification presented to the outside is no longer repeated, thereby suppressing cross-node notification redundancy while ensuring data integrity.

[0118] To ensure that the same alarm event is notified at most once on both the edge and center sides and that no false alarms are missed, this application embodiment further designs the notification determination rules.

[0119] like Figure 7 As shown, in some embodiments, determining whether to send an alarm notification for an alarm event based on the notification status in the above operation S5 may further include: skipping the sending of an alarm notification for an alarm event if either the notification status reported by the edge node of the alarm event or the notification status of the central node indicates that the alarm event has been notified; and sending an alarm notification for an alarm event if both the notification status reported by the edge node of the alarm event and the notification status of the central node indicate that the alarm event has not been notified.

[0120] When a central node triggers an alarm notification, it can examine two notification states sequentially: if the central node's notification state indicates that the alarm event has been notified, it means that the central side has previously issued a notification for the event, and the sending is skipped; if the central node's notification state indicates that it has not been notified, but the notification state reported by the edge node indicates that the alarm event has been notified, it means that the event has been notified to the operations and maintenance personnel on the edge side through the local notification channel, and the sending is also skipped. In this case, the notification state field of the central node can be kept as not notified and the source field can be recorded as the edge side, so as to distinguish later which side completed the notification of the alarm; only when both notification states indicate that the alarm event has not been notified will the central node actually send the alarm notification for the alarm event, and after sending, update the notification state of the central node to be notified and record the source field as the central side.

[0121] In some embodiments, the central node can also write the determination result of sent notifications into a cache according to the combination of event identifier, notification channel, and recipient to accelerate subsequent determinations. A deduplication key is constructed using the combination of event identifier, notification channel, and recipient. For example, a key name like "dedup:{event identifier}:{notification channel}:{recipient}" can be written to an in-memory database (e.g., Redis), and a retention period is set for this key, such as 24 hours. When a notification is triggered, the central node first checks if the deduplication key exists; if it does, the sending is skipped. Because the deduplication key contains both the notification channel and the recipient, the same alarm event sent through different notification channels or to different recipients is determined separately. The fact that a notification has been sent through one channel does not lead to the false suppression of notifications from other channels, while duplicate notifications from the same channel and to the same recipient are suppressed. Correspondingly, when edge nodes send alarm notifications through local notification channels, they can also maintain the same form of judgment results locally. For example, they can use a least recently used cache with a capacity limit of 10,000 entries. When the capacity reaches the limit, the least recently used entries are evicted, thereby achieving fast deduplication on the local side under the condition of limited edge node resources. The edge-side cache and the central-side cache together constitute a two-level deduplication system at the edge and the center. The aforementioned notification status record serves as a persistent judgment basis, ensuring that the judgment results remain consistent even after the cache expires or the node restarts.

[0122] By adopting the above technical solution, this application uses the rule of skipping the sending if either of the two notification states has been notified, and sending only if both states have not been notified, so that the same alarm event is notified at most once on both the edge and center sides. This avoids the same fault being repeatedly notified due to the transfer of notification responsibility before and after the network state switch. At the same time, since the sending is only done when neither side has been notified, the alarm will still be sent normally even if neither side has completed the notification, ensuring that deduplication will not turn into missed notification, thus achieving a definite balance between duplicate notification and missed notification.

[0123] The following combination Figures 1 to 7 The above embodiments will be further explained with a complete implementation process. It should be noted that the sequence information numbers, number of entries, time points, and parameter values ​​appearing in the following process are merely examples for ease of understanding, and the specific values ​​are not shown in the accompanying drawings.

[0124] A distributed monitoring system, such as Figure 1As shown, the system includes a central node 101 and several edge nodes 103 distributed across multiple campuses. Edge node E1 communicates with the central node 101 via a cross-regional wide area link in network 102. The system is configured as follows: the preset conditions for reporting quality are that the round-trip latency is less than 1 second and the number of consecutive reporting timeouts does not exceed a threshold; the first preset number of attempts is 3; the second preset number of attempts is 5; the preset threshold for the retry queue is 1000 entries; the preset number of retry attempts in degraded state is 3; the network detection cycle in offline state is 30 seconds; the preset interval is 30 seconds; the preset number of entries in each interval is 100; the time window for merging is 60 seconds; and the retention period for alarm events in the local database is 7 days.

[0125] Starting at a certain time on a certain day, the wide area link experienced severe packet loss due to a failure of intermediate network equipment. Edge node E1, while online, reported timeouts four times consecutively, exceeding the first preset limit by three times. Therefore, [the following was executed / triggered]. Figure 5 The migration relationship shown generates a handover request to switch the network state to a degraded state; according to Figure 6 The determination process shown indicates that the time interval between the current moment and the last time the network state switch was performed is 11 minutes, which is greater than the preset interval of 30 seconds. Therefore, the switch request is responded to immediately, and the network state is switched to a degraded state.

[0126] After entering the degraded state, edge node E1 generates reporting sequence information for each alarm event according to the order in which multiple alarm events are reported to central node 101. During this degraded state, a total of 500 reporting sequence information (1001 to 1500 in this example) are generated, corresponding to 500 alarm events. Among them, alarm events that fail to be reported first enter the retry queue and are retried 3 times according to a preset number of times, with intervals of 1 second, 2 seconds, and 4 seconds. If they still fail after the retry, they are transferred to the local database. After about 20 minutes, the link packet loss rate decreases, and edge node E1 initiates a query request to central node 101 and obtains the received sequence information. In this example, the received sequence information indicates that central node 101 has stored alarm event sequence information corresponding to 1001 to 1180, 1245 to 1300, and 1390 to 1500, totaling 347. Edge node E1 according to Figure 3 The principle shown is to match the local reported sequence information with it item by item, and determine the segment defined by the grid position where there is no corresponding received sequence information in the sequence direction. That is, a total of 153 alarm events corresponding to 1181 to 1244 (64 items) and 1301 to 1389 (89 items) are alarm events that failed to be reported during the degraded state. Among them are several alarm events where the reporting request returned successfully, but were not actually stored by the central node 101.

[0127] Edge node E1 determines that the missing data interval consists of the two segments mentioned above, and divides it into two intervals with a preset number of 100 entries per interval: the first interval corresponds to reported sequence information 1181 to 1244 and 1301 to 1336, and the second interval corresponds to reported sequence information 1337 to 1389. For the first interval, edge node E1 finds that 10 alarm events (corresponding to reported sequence information 1181 to 1190 in this example) occurred within the same 60-second time window, and all indicated the same event type (the same metric exceeding the limit on the same host) and of the same level. Therefore, it proceeds according to... Figure 3 The alarms are merged into one merge event in the manner indicated by the merging box. This merge event records the first and last occurrence times, the number of merged events (10), and the reporting sequence information of each alarm event participating in the merge. Then, this merged event and the remaining alarm events in the interval that did not participate in the merge are compressed according to the order of the reporting sequence information to obtain the data packet corresponding to the interval. The range of the reporting sequence information carried by the data packet is 1181 to 1336 in this example, and the data packet is reported to the central node 101.

[0128] according to Figure 4 As illustrated, after decompressing, restoring, and storing the data, the central node 101 returns an acknowledgment message. This message indicates that the received sequence information of the target alarm event it has stored covers all sequence information within the range except for a certain location (1205 in this example). Based on this, the edge node E1 determines that the reported sequence information corresponding to that location is the target reported sequence information. It then finds the corresponding alarm event in its locally stored alarm events and confirms that it is still within the retention period. Therefore, it re-reports the alarm event to the central node 101. After re-reporting, the acknowledgment message is checked again to confirm that there is no longer any target reported sequence information within the range.

[0129] During the sequential reporting of the two intervals, edge node E1 continuously records synchronization progress information. When the first interval reporting is completed and the second interval has been reported to a certain position (reporting sequence information 1350 in this example), the link deteriorates again, and edge node E1 fails to report for 6 consecutive times, exceeding the second preset number of 5 times. Therefore, a switching request to switch the network status to offline status is generated. Figure 6 The determination process shown is as follows: at this moment, only 18 seconds have passed since the last network state switch, which is less than the preset interval of 30 seconds. Edge node E1 records the target network state as offline and starts the anti-jitter timer. After 12 seconds, the timer expires, and the network state switches to offline. The current reporting is then interrupted. Edge node E1 retains the synchronization progress information, which includes the reporting sequence information of the first interval that has been reported and the reporting sequence information of the alarm events reported in the second interval that is currently being reported.

[0130] In offline mode, edge node E1 stops reporting to central node 101. Newly generated alarm events are stored in the local database, and alarm notifications are sent to on-duty personnel in the park via the local notification channel. The notification status of these alarm events on the edge side is also recorded. Approximately ten minutes later, edge node E1 successfully initiates a network probe against central node 101 at a 30-second interval, and the network status switches to degraded state. After switching to degraded state, edge node E1 reads the retained synchronization progress information and proceeds according to... Figure 4 The progress diagram shows that the first reported interval is skipped, and the next alarm event in the second interval after the reported position is identified as the reporting breakpoint (corresponding to reporting sequence information 1351 in this example). Reporting continues from this breakpoint, and previously confirmed content is not retransmitted. At the same time, alarm events accumulated in the local database during offline periods are gradually filled in according to the above process of identifying missing data intervals, dividing intervals, merging and compressing, reporting sequentially, and verifying retransmission. The edge-side notification status carried is written into the notification status record of the corresponding alarm event by the central node 101. After the reporting quality meets the preset conditions again, there are no more missing data intervals after matching, and the retry queue is cleared, the edge node E1 switches the network status to online status.

[0131] After the above supplementary reporting is completed, central node 101 will proceed as follows: Figure 7 The illustrated process triggers alarm notifications for each alarm event that arrives as a supplementary report. For alarm events that were already notified to on-duty personnel by edge node E1 through the local notification channel during the offline period, the notification status reported by the edge node indicates that notification has been received. Even though the notification status of the central node does not indicate that notification has been received, central node 101 still skips sending an alarm notification for this alarm event and records the notification source as the edge side. For alarm events that occurred during the degraded state and were not notified by either side, the notification status reported by the edge node and the notification status of the central node both indicate that notification has not been received. Central node 101 sends an alarm notification for this alarm event and updates the notification status of the central node to "notified" after sending. Thus, maintenance personnel receive at most one notification for each alarm during this fault period, and the alarm events on the central node 101 side are completely consistent with those on the edge node E1 side, which can be used for subsequent querying and statistics.

[0132] The above is merely an illustrative example, and the embodiments of this application are not limited thereto. For example, the type of alarm event can be any form such as host alarm, container alarm, network link alarm, or service indicator alarm; the reported sequence information and received sequence information can adopt monotonically increasing sequence numbers, logical clocks, or other forms that can reflect the order; the local database can be any database that supports persistent storage and range query; the local notification channel can be any channel that can still work when the central node is unreachable, such as local email, local SMS, audio-visual prompts, or local callbacks; the above-mentioned thresholds, preset number of times, preset quantity, time window, preset interval, detection period, and retention time parameters can all be configured by the administrator according to the link quality and service requirements.

[0133] As can be seen from the above description, the embodiments of this application achieve at least the following technical effects:

[0134] (1) Silent loss can be detected. By introducing the received sequence information generated by the central node after actually receiving the alarm event, and matching it with the reported sequence information on the edge node side, the judgment criterion for synchronization is changed from the request return result of the sender to the actual reception result of the receiver. This allows alarm events that were successfully reported but were not actually stored by the central node to be identified and filled in, eliminating the blind spot where such loss is unknown on the edge node side.

[0135] (2) Reduced synchronization data volume and link impact. The supplementary reporting range is narrowed to the data missing interval obtained by matching the two types of sequence information. Alarm events that have reached the central node are no longer transmitted repeatedly. With the help of dividing intervals according to a preset number, merging the same type of alarm events within the same time window within the interval, and compressing the reporting interval by interval, the amount of data to be transmitted for supplementary reporting in some implementation scenarios can be reduced by more than an order of magnitude compared to the method of transmitting all data during the disconnection period as a whole. This avoids the synchronization flood at the moment of recovery causing a secondary impact on the newly restored link.

[0136] (3) The synchronization process can continue to advance even under repeated network fluctuations. By recording the synchronization progress information including the completed interval and the reported events in the current interval, and retaining it when the reporting is interrupted and continuing to report from the breakpoint after recovery, the synchronization progress can be accumulated in one direction without returning to the starting point due to midway interruption; by entering the degraded state first after the offline state detection is successful, and requiring the communication to return to normal and the alarm event to be synchronized before entering the online state, the backlog data can obtain a dedicated catch-up stage, avoiding the loss and residue caused by setting the state to online in advance; by switching control based on time interval and anti-jitter timer, the state can be kept stable when the network quality fluctuates near the threshold, avoiding the repeated start and stop of the synchronization task and retry strategy.

[0137] (4) No duplicate or missed alarm notifications. By having the central node determine the alarm notification status based on both the notification status reported by the edge nodes and the notification status of the central node itself when triggering the alarm notification, the alarm is skipped if either status indicates that it has been notified, and is only sent if both indicate that it has not been notified. This ensures that the same alarm event is notified at most once on both the edge and central sides. In some implementation scenarios, the proportion of duplicate notifications can be suppressed to an extremely low level. At the same time, since the deduplication determination is located at the notification triggering stage rather than the event storage stage, the alarm event itself is still completely preserved, thus balancing data integrity and notification simplicity.

[0138] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0139] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0140] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of this application, those skilled in the art can make various substitutions and modifications, all of which should fall within the scope of this application.

Claims

1. An alarm synchronization method, characterized in that, Applied to edge nodes, including: When the network status is in a degraded state, a reporting sequence information is generated according to the order in which multiple alarm events are reported to the central node. The degraded state is a network status in which the reporting between the edge node and the central node is not interrupted but the reporting quality does not meet the preset conditions. Obtain the received sequence information sent by the central node, wherein the received sequence information is the sequence information generated by the central node after receiving the alarm event reported by the edge node; The reported sequence information and the received sequence information are matched to determine the alarm events that failed to be reported during the degraded state, and the alarm events that failed to be reported are reported to the central node.

2. The method according to claim 1, characterized in that, The step of matching the reported sequence information and the received sequence information to determine the alarm events that failed to be reported during the degraded state, and reporting the alarm events that failed to be reported to the central node, includes: The missing data interval is determined based on the reported sequence information and the received sequence information; The data missing interval is divided into multiple intervals according to a preset number of alarm events for each interval; The alarm events within the multiple intervals are compressed sequentially and then reported to the central node.

3. The method according to claim 2, characterized in that, The step of sequentially compressing alarm events within the multiple intervals and reporting them to the central node includes: Multiple alarm events within the interval whose occurrence time is within the same time window and whose indicated event type is the same are merged to obtain a merged event; The merged event and the alarm events within the interval that were not merged are compressed according to the order of the reported sequence information to obtain the data packet corresponding to the interval, wherein the data packet carries the range of the reported sequence information corresponding to the interval; The data packets are reported sequentially to the central node.

4. The method according to claim 3, characterized in that, After the data packets are sequentially reported to the central node, the process also includes: Receive confirmation information returned by the central node, wherein the confirmation information includes the received sequence information of target alarm events from the edge node that the central node has stored; Based on the range of the reported sequence information carried by the data packet and the received sequence information, determine the target reported sequence information that the central node has not stored within the range; If an alarm event corresponding to the target reporting sequence information exists in the alarm events stored at the edge node, the alarm event corresponding to the target reporting sequence information will be re-reported to the central node.

5. The method according to claim 2, characterized in that, Also includes: During the process of sequentially reporting alarm events within the multiple intervals, synchronization progress information is recorded, wherein the synchronization progress information includes the reporting sequence information of the intervals that have been reported and the reporting sequence information of the alarm events that have been reported within the currently reported interval. In the event of an interruption in the reporting process, the synchronization progress information is retained. After the network status is switched back to online or degraded status, the breakpoint location of the reporting is determined based on the synchronization progress information, and the alarm event is continued to be reported to the central node from the breakpoint location.

6. The method according to claim 1, characterized in that, The network status includes online status, degraded status, and offline status; the method further includes: If the network status is online and the number of consecutive timeouts reported with the central node exceeds a first preset number, the network status will be switched to a degraded state. If the network status is in a degraded state and alarm events fail to be reported consecutively for a second preset number of times, or if the number of alarm events to be reported in the retry queue exceeds a preset threshold, the network status will be switched to an offline state. The retry queue is a queue that caches alarm events that need to be re-reported. If the network status is offline and the network detection of the central node is successful, the network status will be switched to a degraded state. If the network status is in a degraded state, communication is restored to normal, and the alarm event is completed synchronously, the network status will be switched to an online state.

7. The method according to claim 6, characterized in that, The method further includes: Upon receiving a network state switching request, determine the time interval between the current moment and the last time a network state switching was performed; If the time interval is less than a preset interval, the target network state indicated by the switching request is recorded and a jitter timer is started. After the jitter timer expires, the network state is switched to the target network state. If the time interval is greater than or equal to the preset interval, the network state is switched in response to the switching request.

8. The method according to claim 6, characterized in that, The method further includes: If the network status is in a degraded state, the alarm event will be retried and reported to the central node. If the reporting still fails after the number of retries reaches a preset number, the alarm event will be transferred to the local database. If the network status is offline, stop reporting to the central node, store the alarm event in the local database, and send the alarm notification through the local notification channel.

9. A method for deduplicating notifications, characterized in that, Applied to the central node, including: Obtain the notification status of alarm events, including the notification status reported by edge nodes and the notification status of the central node; When an alarm notification for an alarm event is triggered, the system determines whether to send an alarm notification for the alarm event based on the notification status.

10. The method according to claim 9, characterized in that, The step of determining whether to send an alarm notification for the alarm event based on the notification status includes: If either the notification status reported by the edge node of the alarm event or the notification status of the central node indicates that the alarm event has been notified, skip sending the alarm notification for the alarm event. If both the notification status reported by the edge node of the alarm event and the notification status of the central node indicate that the alarm event has not been notified, an alarm notification for the alarm event shall be sent.

Images