Multi-dimensional alarm label labeling method, device and medium

Abstract

The application relates to the technical field of data optimization, and discloses a multi-dimensional alarm label marking method, equipment and medium, which comprises the following steps: obtaining target alarm data containing an alarm identity identifier; triggering conditions of label calculation plug-ins configured independently according to each alarm dimension are calculated, each plug-in calculates the label value of the target alarm data in each dimension, and a key-value pair composed of a dimension identifier and a label value is output; key-value pairs belonging to the same target alarm data are merged and serialized into a unified structure string to generate a full label field, and a current hash value and a historical hash value are calculated; if the current hash value and the historical hash value are inconsistent, an update message containing the alarm identity identifier and the full label field is pushed to a message queue, so that a target alarm data is located by a consumer end, and a full label is used to update and cover a label display state. The application can solve the technical problems that an existing alarm label marking method has poor expansibility, different time-sensitive labels cannot be dispatched as required, and label states are easy to be inconsistent in a high-concurrency scene.

Description

Technical Field

[0001] This invention relates to the field of data optimization technology, specifically to a multi-dimensional alarm labeling method, device, and medium. Background Technology

[0002] In large-scale IT operations and maintenance environments, multiple monitoring sources generate massive amounts of alarms, requiring multi-dimensional tags to assist in operational decision-making. However, existing alarm platforms have the following shortcomings: First, the tag calculation logic is mostly hard-coded, requiring modifications to the core code to add new dimensions, resulting in poor scalability; moreover, all tags share a common update frequency, making it impossible to schedule high-frequency time-sensitive tags and low-frequency statistical tags on demand, leading to resource waste or status lag. Second, in high-concurrency scenarios such as alarm storms, synchronous calls are prone to performance bottlenecks, while incremental push methods result in residual and inconsistent tag states on the consumer side due to message out-of-order or loss. Third, some solutions use a plug-in chain to serially aggregate alarms in a fixed order, with sequential dependencies between plug-ins; any change or anomaly in any plug-in may affect the entire processing chain.

[0003] Therefore, how to ensure flexible expansion of tag dimensions while taking into account the update efficiency of tags with different timeliness and the accuracy of tag status in high-concurrency scenarios is a technical problem that urgently needs to be solved. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention provide a multi-dimensional alarm tag labeling method, device and medium to solve the technical problem in the prior art of how to ensure the flexible expansion of tag dimensions while taking into account the update efficiency of tags with different timeliness and the accuracy of tag status in high-concurrency scenarios.

[0005] According to one aspect of the present invention, a multi-dimensional alarm tagging method is provided, comprising: Acquire target alarm data, wherein the target alarm data includes alarm identification; Based on multiple preset alarm dimensions, and according to the triggering conditions independently configured by the tag calculation plugins corresponding to each alarm dimension, each tag calculation plugin is triggered to calculate the tag value of the target alarm data in each corresponding alarm dimension, and outputs a key-value pair consisting of a dimension identifier and a tag value; wherein, each tag calculation plugin uses the alarm identity identifier as an input parameter; All key-value pairs belonging to the same target alarm data are merged into a key-value pair set, and the key-value pair set is serialized into a string with a uniform structure to generate the full tag field of the target alarm data; Calculate the current hash value of the full tag field and compare it with the historical hash value of the target alarm data; If the current hash value is inconsistent with the historical hash value, an update message containing the alarm identity identifier and the full tag field will be pushed to the message queue so that the consumer can locate the target alarm data based on the alarm identity identifier and update the tag display status of the alarm with the full tag.

[0006] Furthermore, the target alarm data includes one or more alarm records, which are obtained by performing structured parsing on the original alarm data. The acquisition of the target alarm data includes: The alarm content of the original alarm data is parsed in a structured manner to extract structured fields, and the original alarm content before parsing is saved to extended fields to obtain the current alarm record; the structured fields include at least the host identifier and the alarm title; Within a preset time window, based on the host identifier and alarm title, query whether there is any existing target alarm data with the same host identifier and alarm title as the current alarm record; If it does not exist, a current alarm identity identifier is generated, a new target alarm data is created based on the current alarm identity identifier, and the current alarm record is used as the alarm record of the new target alarm data; If it exists, the current alarm record will be added to the existing target alarm data.

[0007] Furthermore, the tag calculation plugin is an independently packaged plugin unit, and each tag calculation plugin is triggered separately by the differentiated frequency scheduler according to its own configured triggering conditions; the tag calculation plugin includes at least one of the following: The following plugins are used: a compression tag plugin, which outputs a compression tag recording the number of compressed events when the number of alarm events is greater than or equal to a preset compression threshold; an escape tag plugin, which outputs an escape tag when the original content before escaping exists in the extended field; a similar event tag plugin, which outputs a similar event tag based on matching the event number in the event management system with the business system and alarm title; a recurrence tag plugin, which counts the occurrence frequency of alarms of the same dimension within a preset time window, and outputs a recurrence tag when the occurrence frequency is greater than or equal to a preset recurrence threshold; a fast recovery tag plugin, which outputs a fast recovery tag when the alarm has been closed or resolved and the duration is less than a preset recovery threshold; and an alarm storm tag plugin, which outputs an alarm storm tag recording the number of storm compression events when the storm compression flag is true. The calculation logic and triggering conditions of the tag calculation plugins are defined through the plugin configuration file. When a new alarm dimension is added, expansion is achieved by developing a new tag calculation plugin and updating the plugin configuration file.

[0008] Further, the step of serializing the key-value pair set into a string with a uniform structure includes: Sort the tag keys in the key-value pair set according to a preset lexicographical order or field order; The tag values ​​in the key-value pair set are subjected to type normalization processing to obtain strings with a uniform structure; the type normalization processing includes at least one of converting null values ​​to preset empty strings, converting boolean values ​​to lowercase strings, and converting numbers to strings with a specified precision.

[0009] Furthermore, the method also includes: if the current hash value is consistent with the historical hash value, then skip pushing the update message.

[0010] Further, the step of calculating the current hash value of the full tag field and comparing it with the historical hash value of the target alarm data includes: The current hash value is obtained by calculating the full set of tag fields using a preset digest algorithm; Using the alarm identifier as the key, query the corresponding historical hash value in the distributed cache database; If the current hash value is inconsistent with the historical hash value, the method further includes: Update the distributed cache database with the current hash value as the new historical hash value, and set the expiration time.

[0011] Furthermore, when a recovery or clearing message for the target alarm data is received, the historical hash value corresponding to the alarm identity identifier in the distributed cache database is cleared, and a tag clearing message is pushed to the message queue so that the consumer can clear the tag display status of the target alarm data.

[0012] Furthermore, updating the label display status of the alarm with the full set of labels includes: The consumer subscribes to and consumes the updated messages from the message queue; Parse the full tag field in the update message to obtain all currently valid tag key-value pairs; The target alarm data is located based on the alarm identity identifier, and the current tag display status of the target alarm data is directly overwritten using all tag key-value pairs.

[0013] According to another aspect of the present invention, a computer device is provided, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction, which causes the processor to perform the operation of the multi-dimensional alarm tag labeling method described above.

[0014] According to another aspect of the present invention, a computer-readable storage medium is provided, the storage medium storing at least one executable instruction, the executable instruction causing a computer device to perform the operation of the multi-dimensional alarm tag labeling method described in any of the above embodiments.

[0015] The multi-dimensional alarm tagging method provided in this invention encapsulates the tag calculation logic for different alarm dimensions into independent plugins. Each plugin takes the alarm identity identifier as input and uses key-value pairs containing dimension identifiers and tag values ​​as a unified output format. When adding a new tag dimension, only a new plugin needs to be developed and the configuration file updated, without modifying the core scheduling, aggregation, deduplication, and push links. This achieves flexible expansion of tag dimensions, significantly reducing expansion costs and maintenance difficulty. Differential triggering is achieved through independent configuration of each plugin. High-frequency timeliness tags and low-frequency statistical tags can be configured with different update frequencies according to their respective needs, balancing timeliness and resource efficiency, and avoiding resource waste or status lag caused by a uniform frequency. Furthermore, by analyzing the full set of tag characters… The algorithm calculates hash values ​​for each segment and compares them with historical hash values. Update messages are only pushed when the tag content has actually changed; otherwise, pushes are skipped, effectively reducing the impact of invalid pushes on message queue bandwidth and consumer processing resources. Asynchronous push via message queue decouples the tag calculation engine from the alarm display platform, avoiding request backlog and performance bottlenecks caused by a large number of simultaneous update requests in synchronous call methods. This ensures the availability and stability of the display platform under high load. Furthermore, each push includes all currently valid tags for the alarm, allowing the consumer to directly overwrite and update the tag display status without maintaining incremental states. This effectively avoids tag residue and status inconsistencies caused by message out-of-order or lost messages in incremental push methods.

[0016] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0017] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating the multi-dimensional alarm tagging method provided in an embodiment of the present invention is shown. Figure 2 A schematic diagram of the structure of a computer device provided in an embodiment of the present invention is shown. Detailed Implementation

[0018] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0019] Figure 1 A flowchart illustrating a multi-dimensional alarm tagging method provided in an embodiment of the present invention is shown. This method is executed by a computer device. The computer device can be a desktop computer, laptop computer, tablet computer, smart terminal, distributed device, etc. Figure 1 As shown, the method includes the following steps: S110. Obtain target alarm data, wherein the target alarm data includes alarm identification.

[0020] To provide standardized data input for subsequent multi-dimensional tag calculations and to retain the original alarm content for source tracing and escaping judgment, this step first acquires the target alarm data. Specifically, the original alarm data is generated by each monitoring system (monitoring source layer) and reported to the data platform. The original alarm data includes at least the following fields: alarm identifier (id), alarm title (title), alarm content (content), source system (location), host (host), and alarm time (arriveTime). The data platform cleans the original alarm data: unstructured alarm content (e.g., "Host 10.10.1.100 Port 3306Error: Connection timeout") is parsed into structured fields (e.g., IP address, component name, error code, business system, etc.), and the original alarm content before parsing is saved to the extended field (extend13). After being cleaned by the data platform, the structured alarm data is written to the alarm platform, becoming the target alarm data available for subsequent tag calculation and processing. This target alarm data contains an alarm identity identifier (i.e., alarm identifier (id)) used to uniquely identify an alarm record in the system.

[0021] Specifically, the system reads or receives cleaned structured alarm data from the alarm platform's data storage, extracts the alarm identification identifiers, and uses them as input parameters for subsequent tag calculation plugins. This target alarm data forms the data foundation for all subsequent tag calculation, aggregation, and push operations.

[0022] This step, through preprocessing by the data platform, provides a unified data input format for subsequent tag calculation plugins, avoiding repeated alarm parsing operations by each plugin and improving overall processing efficiency; at the same time, by saving the original alarm content to the extended field, it preserves the basis for determining escape tags.

[0023] S120. Based on multiple preset alarm dimensions, and according to the triggering conditions independently configured by the tag calculation plugins corresponding to each alarm dimension, each tag calculation plugin is triggered to calculate the tag value of the target alarm data in each corresponding alarm dimension, and outputs a key-value pair consisting of a dimension identifier and a tag value; wherein, each tag calculation plugin uses the alarm identity identifier as an input parameter.

[0024] In existing alarm platforms, the tag calculation logic is usually implemented using hard-coded methods, which requires modifying the core system code and redeploying to add new tag dimensions, resulting in poor scalability; moreover, all tags use a uniform update frequency, which cannot take into account the differentiated scheduling needs of high-frequency time-sensitive tags and low-frequency statistical tags.

[0025] In this step, the tag calculation logic for different alarm dimensions is encapsulated into independent tag calculation plugins. The tag calculation layer consists of multiple independent tag calculation plugins, each responsible for calculating one type or a group of tags. The plugins are not directly coupled and there is no direct data call or transmission relationship between them. Each plugin uses the alarm identity identifier as input parameter, obtains data from the alarm platform, event management system, related scenario interface, or historical statistics database, independently performs tag calculation according to its configured trigger conditions, and outputs key-value pairs consisting of dimension identifier and tag value.

[0026] Specifically, each plugin is triggered separately by a differentiated frequency scheduler according to its configured triggering conditions. The differentiated frequency scheduler reads the triggering conditions (such as cron expressions) in the configuration file and calculates the triggering conditions independently configured for each plugin to trigger the corresponding plugin execution. In one embodiment, the differentiated frequency scheduler is implemented based on Quartz, SpringScheduled, or a distributed task scheduling platform. It reads the cron expressions in the configuration file and triggers the corresponding plugin execution according to the execution cycle independently configured for each plugin. For example, time-sensitive tags such as compression tags, escape tags, similar event tags, and alarm storm tags can be configured to trigger every 2 minutes; statistical tags such as recurrence tags and quick recovery tags can be configured to trigger every day. There is no direct data call or transmission relationship between the plugins; they are triggered and executed independently by the scheduler.

[0027] The plugin output is uniformly formatted as key-value pairs containing dimension identifiers and tag values. In one embodiment, the key-value pairs also include tag source and validity period. Tag source identifies which plugin or data source calculated the tag (e.g., "compression plugin," "event management system," etc.), facilitating maintenance personnel to trace the calculation basis of the tag; validity period identifies the expiration date of the tag. When the validity period expires, the consumer can mark the tag as expired or no longer display it. In one embodiment, the plugin output uses a Map...<AlarmId, LabelMap> The LabelMap format contains the label field name (i.e., dimension identifier) ​​and label value. For example, in the key-value pairs output by the compression label plugin, the dimension identifier is "compressed" and the label value is the compression quantity (e.g., 3); in the key-value pairs output by the similar event label plugin, the dimension identifier is "hasHistoryItsm" and the label value is "true" or "false".

[0028] This step decouples the calculation logic of each dimension's tags through a plug-in architecture. Adding a new tag dimension only requires developing a new plugin and adding the corresponding configuration item to the configuration file; there's no need to modify the core scheduling, aggregation, deduplication, and push processes. This is because the scheduler dynamically loads and triggers plugins based on configuration files, the aggregation module uniformly processes the key-value pairs output by each plugin, and the deduplication and push modules only rely on alarm identity identifiers and full tag fields, all decoupled from specific tag types. Therefore, adding a plugin will not affect the core process code. A differentiated frequency scheduler allows each plugin to independently configure trigger conditions according to its needs, ensuring high-frequency and low-frequency tags are properly configured, avoiding resource waste or status lag caused by a uniform frequency. Simultaneously, each plugin outputs in a unified key-value pair format, providing standardized data input for subsequent aggregation and serialization.

[0029] S130. Merge all key-value pairs belonging to the same target alarm data into a key-value pair set, and serialize the key-value pair set into a string with a unified structure to generate the full tag field of the target alarm data.

[0030] After each tag calculation plugin independently completes its calculation and outputs key-value pairs, the result is multiple scattered key-value pairs under the same alarm identity. It is necessary to integrate the scattered tag data into a unified data structure for subsequent hash deduplication and asynchronous push. At the same time, to ensure the stability of the hash comparison results, the integrated data needs to be standardized.

[0031] To address the aforementioned requirements, this step utilizes a full tag aggregation module to merge all key-value pairs belonging to the same target alarm data into a single key-value pair set. This set contains all valid tags for the alarm at the current moment. Subsequently, the aggregation module serializes this key-value pair set into a string with a uniform structure (e.g., JSON string format), generating the full tag field (i.e., the alarm_label field) for the target alarm data. This full tag field contains the tag status for all dimensions of the alarm at the current moment and serves as the data object for subsequent hash deduplication and push notifications.

[0032] For example, the aggregation module iterates through the output of all tag calculation plugins, collects tag key-value pairs for the same alarm based on the alarm identity, constructs a key-value pair set, and then serializes this set into a JSON-formatted string as the value of the alarm_label field. Assuming the compressed tag plugin outputs {"compressed":3}, the similar event tag plugin outputs {"hasHistoryItsm":true}, and the alarm storm tag plugin outputs {"alertStorm":true}, the aggregation module merges these key-value pairs into {"compressed":3,"hasHistoryItsm":true,"alertStorm":true}, and then serializes it into a string.

[0033] To ensure stable hash comparison results, the aggregation module sorts the tag keys according to a preset field order or lexicographical order before serialization, and performs normalization processing on null values, boolean values, numbers, and strings. For example, null values ​​are uniformly converted to empty strings, boolean values ​​are uniformly converted to lowercase strings, and numbers are uniformly converted to strings with a specified precision.

[0034] This step integrates the scattered tag data into a unified full tag field, solving the problem of fragmented tag data generated by independent calculations by various plugins. This provides a complete data foundation for subsequent hash deduplication, asynchronous push, and consumer-side coverage updates. Simultaneously, a structured string format is used to organize the full tags, facilitating subsequent network transmission and consumer-side parsing.

[0035] S140. Calculate the current hash value of the full tag field and compare it with the historical hash value of the target alarm data.

[0036] In existing alarm tag processing solutions, tag calculation results are pushed downstream regardless of whether they have changed, resulting in unnecessary consumption of message queue bandwidth and consumption resources, which is particularly prominent in high-concurrency scenarios. Furthermore, there is a lack of effective tag content change detection mechanisms.

[0037] To address the aforementioned issues, this step introduces a hash-based deduplication mechanism. First, the full tag field generated in S130 (i.e., the string form of the `alarm_label` field) is standardized, and its current hash value is calculated using a preset digest algorithm (such as SHA-256). Then, using the alarm identifier as the key, the historical hash value of the alarm from the last push is retrieved from a distributed cache database (such as Redis). If the current hash value matches the historical hash value, it means that the full tag content of the alarm has not changed since the last push, and the current push is skipped; if they do not match, it means that the tag content has changed, and an update push is required. Through hash comparison, it is possible to quickly and accurately determine whether the tag content has actually changed, avoiding invalid pushes due to unchanged tag values.

[0038] For example, the system stores historical hash values ​​in Redis using `alarm_label_hash:{alarm id}` as the key and sets an expiration time (e.g., 7 days). Each time the current hash value is calculated, the corresponding historical hash value is retrieved using this key for comparison.

[0039] This step achieves accurate detection of tag changes through hash comparison, solving the resource waste caused by repeated pushes when tags have not changed in existing technologies. The hash value comparison method is efficient and accurate, and can quickly complete deduplication in large-scale alarm scenarios, providing a basis for decision-making for subsequent on-demand pushes.

[0040] S150. If the current hash value is inconsistent with the historical hash value, an update message containing the alarm identity identifier and the full tag field will be pushed to the message queue so that the consumer can locate the target alarm data based on the alarm identity identifier and update the tag display status of the alarm with the full tag.

[0041] Current alarm tag updates mostly use synchronous API calls or incremental push methods. Synchronous calls can easily cause a large backlog of requests in high-concurrency scenarios such as alarm storms, affecting the processing performance of the alarm display platform; incremental push requires the consumer to maintain and merge incremental states, which can easily lead to tag residue or inconsistent states when messages are out of order or lost.

[0042] This step employs an asynchronous push mechanism based on a message queue and a full-coverage update method. When the hash comparison result in S140 is inconsistent, the system pushes an update message containing the alarm identity identifier and full tag fields to a message queue (such as Kafka Topic). The message queue buffers and distributes the update message, decoupling the tag calculation engine from the alarm display platform.

[0043] Specifically, the update message includes an alarm identity identifier and a full set of tag fields. The alarm display platform, acting as a consumer of the message queue, subscribes to tag update messages in real time. Upon receiving an update message, the consumer locates the corresponding target alarm data based on the alarm identity identifier, parses the full set of tag fields, obtains all currently valid tag key-value pairs, and then directly overwrites the current tag display status of that alarm.

[0044] This step replaces synchronous API calls with asynchronous message queues. In alarm storm scenarios, the buffering capacity of message queues is utilized to avoid performance bottlenecks caused by a large number of update requests arriving at the display platform simultaneously. At the same time, full tag overwrite updates are used instead of incremental updates. The consumer receives the current tag status of the alarm every time, directly overwriting the old status. There is no need to maintain incremental status, which effectively avoids tag residue and status inconsistency issues caused by message out-of-order or loss.

[0045] In summary, the multi-dimensional alarm tagging method provided by this invention first obtains target alarm data that has been structured and cleaned by a data platform through S110, unifying the input data format for subsequent tag calculation, and retaining the basis for escaping tag determination by saving the original alarm content to an extended field; through S120, the tag calculation logic of different alarm dimensions is encapsulated into independent plug-ins, each plug-in using the alarm identity identifier as input parameter, and is triggered separately by a differentiated frequency scheduler according to its independently configured trigger conditions, solving the problems of poor scalability caused by hard coding in the prior art and the inability to balance timeliness and resource efficiency between high-frequency and low-frequency tags due to unified frequency; through S130, all tag key-value pairs of the same alarm are merged into a set and serialized into a unified structure word. The string generates a full tag field, providing a complete data foundation for subsequent hash deduplication and full coverage by the consumer. The current hash value of the full tag field is calculated by S140 and compared with the historical hash value to accurately detect whether the tag content has actually changed, solving the resource waste caused by repeated pushes when the tags have not changed in the existing technology. The update message containing the alarm identity and full tag field is pushed by the asynchronous message queue through S150. The consumer locates the target alarm data based on the alarm identity and updates the tag display status by covering it with the full tag, solving the performance bottleneck problem of synchronous calls in high-concurrency scenarios. At the same time, the full coverage update mechanism effectively avoids the tag residue and status inconsistency problems caused by message out-of-order or loss in incremental push.

[0046] In large-scale IT operations and maintenance environments, the massive amounts of alarms generated by multiple monitoring sources often require repeated switching between alarm platforms, event management systems, CMDBs, log platforms, and monitoring systems to piece together a complete alarm profile. This invention, through the aforementioned steps, automatically labels multi-dimensional attributes such as compression, escaping, historical association, storms, recurrence, and rapid recovery onto alarm data using unified tags. Operations and maintenance personnel can directly obtain a complete alarm profile from the alarm platform without switching between multiple systems, significantly improving operational decision-making efficiency. A plug-in architecture enables flexible expansion of tag dimensions; adding new tags only requires developing new plugins and updating configuration files, without modifying the core pipeline. Differentiated frequency scheduling allows high-frequency and low-frequency tags to be independently scheduled according to their respective needs, balancing timeliness and resource efficiency. Asynchronous message queues and a full-coverage update mechanism ensure the consistency of tag states and the stability of the display platform under high-concurrency scenarios such as alarm storms. This invention effectively solves the technical problems of poor tag scalability, low scheduling efficiency, insufficient high-concurrency performance, and inconsistent states in existing technologies, and is suitable for multi-dimensional alarm tag labeling scenarios in large-scale IT operations and maintenance environments.

[0047] In one embodiment, the target alarm data includes one or more alarm records, which are obtained by performing structured parsing on the original alarm data. The acquisition of the target alarm data includes: S111. Perform structured parsing on the alarm content of the original alarm data, extract structured fields, and save the original alarm content before parsing to extended fields to obtain the current alarm record; the structured fields include at least host identifier and alarm title; S112. Within a preset time window, based on the host identifier and alarm title, query whether there is any existing target alarm data with the same host identifier and alarm title as the current alarm record; S113. If it does not exist, generate a current alarm identity identifier, create a new target alarm data based on the current alarm identity identifier, and use the current alarm record as the alarm record of the new target alarm data; S114. If it exists, the current alarm record is added to the existing target alarm data.

[0048] In this embodiment, raw alarm data reported by various monitoring systems is first received. This raw alarm data is generated by the monitoring source layer, which includes various monitoring systems deployed by the enterprise, such as Zabbix, Prometheus, and application performance monitoring systems. Each system generates raw alarm data independently according to its own rules. The raw alarm data includes at least the following fields: alarm identifier (id), alarm title (title), alarm content (content), source system (location), host (host), and alarm time (arriveTime).

[0049] The alarm content in the raw alarm data is usually unstructured text information (e.g., "Host10.10.1.100 Port 3306 Error: Connection timeout"). Alarm content generated by different monitoring systems has varying formats and cannot be directly processed uniformly by subsequent tag calculation plugins. To unify the data format for subsequent processing and preserve the original information for source tracing, a data platform performs structured parsing of the raw alarm content. Specifically, the data platform extracts fields and performs semantic parsing on the alarm content, extracting structured key fields such as IP address, component name, error code, and business system. These structured fields include at least the host identifier (host) and alarm title (title). Simultaneously, the raw alarm content before parsing is completely saved in the extended field (extend13) for subsequent source tracing and escape tag judgment. After the above structured parsing, the raw alarm data is converted into a current alarm record containing structured fields and a backup of the original content, serving as the basic unit for subsequent querying and merging processing.

[0050] Next, within a preset time window, the system queries whether existing target alarm data exists based on the host identifier and alarm title. In alarm storm scenarios, the same fault may trigger multiple monitoring systems to generate a large number of alarms with similar content within a short period of time. If target alarm data is created independently for each original alarm, the number of alarms will explode, increasing the burden on subsequent tag calculation and display. Therefore, it is necessary to merge multiple original alarms caused by the same fault into the same target alarm data for unified management. Specifically, the system uses the host identifier (host) and alarm title (title) of the current alarm record as a composite key to query the alarm platform's data storage for whether existing target alarm data exists. The existing target alarm data contains alarm records with the same host identifier and alarm title as the current alarm record. The query time range is limited to a preset time window (e.g., 30 to 60 minutes, configurable), that is, only target alarm data generated within the preset time window before the current alarm occurred is queried. If an existing target alarm with the same host identifier and alarm title as the current alarm record exists within the time window, it indicates that the current alarm and the existing target alarm are related alarms caused by the same fault and should be grouped into the same target alarm data. If no target alarm exists, it indicates that the current alarm is a new fault event and a new target alarm data needs to be created. By limiting the time window, the system avoids erroneously merging alarms that are far apart in time and are actually unrelated into the same target alarm data, ensuring the accuracy of alarm merging. The specific value of the preset time window can be flexibly configured according to the operation and maintenance scenario.

[0051] If no existing target alarm data with the same host identifier and alarm title as the current alarm record is found within the preset time window, it indicates that the current alarm belongs to a new fault event. In this case, the system generates a current alarm identifier (e.g., an auto-incrementing serial number or a universally unique identifier), creates a new target alarm data based on this identifier, and stores the current alarm record as the first alarm record in this new target alarm data. If existing target alarm data with the same host identifier and alarm title as the current alarm record is found within the preset time window, it indicates that the current alarm and the existing target alarm data belong to the same fault-related alarm. In this case, the system does not create a new target alarm data, but instead directly adds the current alarm record to the existing target alarm data as a new alarm record. The number of alarm records in the target alarm data will increase accordingly, and the compression tag plugin can then use this number to assign compression tags during subsequent calculations.

[0052] The above processing achieves the merging of multiple original alarms caused by the same fault into the same target alarm data, avoiding redundant storage and duplicate processing of alarm data. The merged target alarm data contains alarm identification and one or more alarm records, which can be directly used for subsequent tag calculation plugin processing.

[0053] In one embodiment, the tag calculation plugin is an independently packaged plugin unit, and each tag calculation plugin is triggered by a differentiated frequency scheduler according to its respective configured triggering conditions; the tag calculation plugin includes at least one of the following: The following plugins are used: a compression tag plugin, which outputs a compression tag recording the number of compressed events when the number of alarm events is greater than or equal to a preset compression threshold; an escape tag plugin, which outputs an escape tag when the original content before escaping exists in the extended field; a similar event tag plugin, which outputs a similar event tag based on matching the event number in the event management system with the business system and alarm title; a recurrence tag plugin, which counts the occurrence frequency of alarms of the same dimension within a preset time window, and outputs a recurrence tag when the occurrence frequency is greater than or equal to a preset recurrence threshold; a fast recovery tag plugin, which outputs a fast recovery tag when the alarm has been closed or resolved and the duration is less than a preset recovery threshold; and an alarm storm tag plugin, which outputs an alarm storm tag recording the number of storm compression events when the storm compression flag is true. The calculation logic and triggering conditions of the tag calculation plugins are defined through the plugin configuration file. When a new alarm dimension is added, expansion is achieved by developing a new tag calculation plugin and updating the plugin configuration file.

[0054] In this embodiment, the tag calculation plugin is an independently encapsulated plugin unit. Each tag calculation plugin is an independent software module or component (e.g., a Java class or dynamic link library), encapsulating the calculation logic for a specific alarm dimension. There is no direct data call or transmission relationship between the plugins; that is, the plugins are independent of each other and do not affect each other, allowing for independent development, testing, and deployment. Each tag calculation plugin is triggered separately by a differentiated frequency scheduler according to its configured triggering conditions. The differentiated frequency scheduler reads the plugin configuration file (e.g., a YAML format configuration file), obtains the triggering conditions (e.g., cron expressions) for each plugin from the configuration file, and triggers the corresponding plugin execution according to its independently configured triggering conditions. For example, the compressed tag plugin, escaped tag plugin, and similar event tag plugin can be configured to trigger every 2 minutes, while the repeated tag plugin and fast recovery tag plugin can be configured to trigger every 1 day. Through the above configuration, time-sensitive tags can be updated at a higher frequency, while statistical tags are updated at a lower frequency, thereby saving computing resources while ensuring timeliness.

[0055] The tag calculation plugin includes at least one of the following: The compression tag plugin is used to output compression tags (dimension identifier: compressed, tag value: compression count) when the number of alarm events (eventCount) is greater than or equal to a preset compression threshold (e.g., default value is 2, configurable). Specifically, the compression tag plugin uses the alarm identity as input parameter, queries the number of alarm records with the same host identity and alarm title as the alarm within a preset time window, and when the number reaches the preset compression threshold, it marks the alarm with a compression tag and records the compression count.

[0056] The escape tag plugin outputs escape tags (dimension identifier: escaped) when the original content before escaping exists in the extended field (extend13). Specifically, the escape tag plugin takes the alarm identity identifier as input parameter, checks whether the original alarm content before parsing exists in the extended field (extend13) of the alarm. If it exists, it means that the alarm content has been processed by structured parsing and is marked with escape tags.

[0057] The Similar Event Tagging plugin is used to match event numbers in the event management system based on the business system and alarm title, and output similar event tags (the dimension identifier is hasHistoryItsm). Specifically, the similar event tagging plugin takes the alarm identity as input parameter, obtains the business system and alarm title of the alarm, uses them as combined query conditions, and searches in the event management system to see if there is a matching historical event number. If a match is found, a similar event tag is added, with the tag value being the matched event number.

[0058] The repetitive tagging plugin is used to count the number of times alarms of the same dimension occur within a preset time window. When the number of occurrences is greater than or equal to a preset repetitive threshold (e.g., the default value is 3 times, which can be configured), a repetitive tag (with the dimension identifier being repetitive) is output. Specifically, the repetitive tagging plugin uses the alarm identity identifier as input parameter, groups alarms according to dimensions such as business system, component, and alarm title, counts the number of times alarms of the same dimension occur within a preset time window (e.g., 1 day), and marks the alarms with a repetitive tag when the statistical results reach the preset repetitive threshold.

[0059] The Quick Recovery Tag plugin outputs a Quick Recovery tag (with the dimension identifier "quick") when an alarm is closed or resolved and the duration is less than a preset recovery threshold (e.g., the default is 300 seconds, configurable). Specifically, the Quick Recovery Tag plugin takes the alarm identifier as input parameter, obtains the alarm's closed or resolved status and duration, and if the alarm is closed or resolved, the duration is less than the preset recovery threshold, and it was not manually closed, then a Quick Recovery tag is applied.

[0060] The associated alarm tag plugin is used to output associated alarm tags (with the dimension identifier being hasIncident) when the alarm identity matches the associated alarm list returned by the associated scenario interface. Specifically, the associated alarm tag plugin uses the alarm identity as input parameter, calls the associated scenario interface, queries whether the alarm exists in the associated alarm list returned by the interface, and if it exists, marks it with an associated alarm tag.

[0061] The Alarm Storm Tag plugin outputs alarm storm tags (with the dimension identifier "alertStorm") that record the number of storm compressions when the storm compression flag ("stormCompress") is true. Specifically, the alarm storm tag plugin uses the alarm identity as input parameter to detect whether the current system is in an alarm storm state (i.e., whether the total number of global alarms exceeds the preset storm threshold in a short period of time). If so, it marks the alarm storm and records the number of storm compressions.

[0062] The product comes with a built-in tagging plugin to output product tags based on historical frequency, trend changes, and periodic statistical characteristics. These tags include at least one of the following: new event tags, occasional event tags, surge event tags, high-frequency event tags, and periodic event tags. Specifically, the new event tag is output when the alarm is a newly appearing alarm type (dimensional identifier: newEvent); the occasional event tag is output when the alarm frequency is below a preset occasional threshold (dimensional identifier: rare); the surge event tag is output when the alarm frequency surges compared to the same period in history within a preset time window (dimensional identifier: sharpIncrease); the high-frequency event tag is output when the alarm frequency is above a preset high-frequency threshold (dimensional identifier: highFrequencyEvent); and the periodic event tag is output when the alarm exhibits periodic occurrence characteristics (dimensional identifier: periodicEvent). For example, Fourier transform or autocorrelation analysis is used to detect the recurrence of alarms within fixed time intervals, and the tag is applied when a significant periodic pattern is detected. This plugin also uses the alarm identity as input parameter, retrieves the historical frequency data, trend change data and periodic detection results of the corresponding dimension of the alarm from the alarm platform or historical statistics database, and outputs the corresponding product-specific tags according to the preset judgment logic.

[0063] The calculation logic and triggering conditions of the tag calculation plugin are defined through a plugin configuration file. In one embodiment, the plugin configuration file adopts YAML format, and the configuration content includes the plugin name, activation status, execution cycle, query window, threshold parameter, grouping dimension, and plugin implementation class. For example, the configuration file of the compressed tag plugin may contain the following: plugin name is "compressed_plugin", activation status is true, execution cycle is "120s", query window is "30m", threshold parameter is "2", grouping dimension is "host+title", and plugin implementation class is "com.guosen.CompressedPlugin". Through the above configuration file, the system can flexibly adjust the running parameters and activation status of each plugin without modifying the core code. When adding an alarm dimension, it is only necessary to develop a new tag calculation plugin and update the plugin configuration file to achieve expansion, without modifying the code of the core scheduling, aggregation, deduplication, and push links. This is because the scheduler dynamically loads plugins based on configuration files, the aggregation module uniformly processes the key-value pair outputs of each plugin, the deduplication module only relies on the hash value of the full tag field for judgment, and the push module is only responsible for sending update messages to the message queue. Each core module is decoupled from specific tag types, so adding a plugin will not affect the code logic of the core link.

[0064] In one embodiment, serializing the set of key-value pairs into a string with a uniform structure includes: S211. Sort the tag keys in the key-value pair set according to a preset lexicographical order or field order; S212. Perform type normalization processing on the tag values ​​in the key-value pair set to obtain strings with a unified structure; the type normalization processing includes at least one of converting null values ​​to preset empty strings, converting boolean values ​​to lowercase strings, and converting numbers to strings with a specified precision.

[0065] In this embodiment, after merging all key-value pairs belonging to the same target alarm data into a key-value pair set, the aggregation module needs to serialize this set into a string with a unified structure to generate the full tag field. However, since each plugin executes independently, the order of its output key-value pairs and the format of the tag values ​​may be inconsistent—for example, the compression tag plugin may output {"compressed":3}, the similar event tag plugin may output {"hasHistoryItsm":true}, and the alarm storm tag plugin may output {"alertStorm":true}, and the order of the results returned by each plugin is not fixed. If these key-value pairs are directly serialized, the same tag content may produce different strings due to different key orders (such as {"alertStorm":true,"compressed":3} and {"compressed":3,"alertStorm":true}), resulting in unstable hash comparison results. Meanwhile, inconsistent tag value formats (e.g., null values ​​may be represented as null, empty strings, or missing fields; boolean values ​​may be represented as True / False or true / false; numbers may be represented as integers or floating-point numbers) can also lead to different string representations for tags with the same semantics, thus affecting the accuracy of hash comparisons. To address these issues, the aggregation module performs the following standardization processing before serialization: First, it sorts the tag keys in the key-value pair set according to a preset lexicographical or field order to ensure that the same tag content is arranged in the same order during each serialization, avoiding different strings for the same content due to different key ordering. In one embodiment, the aggregation module sorts according to the lexicographical order of the tag keys (i.e., alphabetical order, such as alertStorm, compressed, hasHistoryItsm); in another embodiment, the aggregation module sorts according to a preset fixed field order. Then, the tag values ​​in the key-value pair collection are subjected to type normalization processing, including at least one of the following: converting null values ​​(e.g., null or missing values) to preset empty strings (e.g., empty string ""), converting boolean values ​​to lowercase strings (e.g., converting True / False or true / false to "true" / "false"), and converting numbers to strings with a specified precision (e.g., keeping two decimal places for floating-point numbers or converting them to their original precision to avoid hash value changes due to precision differences). In a specific application scenario, the aggregation module first collects all key-value pairs belonging to the same alarm identity, for example, the compression tag plugin outputs {"compressed":3}, the similar event tag plugin outputs {"hasHistoryItsm":true}, and the alarm storm tag plugin outputs {"alertStorm":true}.The aggregation module merges the aforementioned key-value pairs into a key-value pair set, sorts the keys lexicographically, resulting in a key-value pair set in the order of alertStorm, compressed, and hasHistoryItsm. Then, the tag values ​​are normalized (e.g., the boolean value 'true' is uniformly converted to the lowercase string "true"), and finally serialized into a JSON string with a uniform structure: {"alertStorm":"true","compressed":3,"hasHistoryItsm":"true"}. The serialized string will serve as the full tag field for the target alarm data, used for subsequent hash comparison and push processing. Through the above sorting and type normalization, tags with the same content generate the same string in each serialization, ensuring the stability of subsequent hash comparison results. The hash value only changes when the tag content (dimension or value) actually changes, avoiding misjudgments caused by different key orders or inconsistent value formats. This significantly improves the accuracy and reliability of the hash deduplication mechanism, while the uniform string structure facilitates subsequent network transmission and parsing by the consumer.

[0066] In one embodiment, the method further includes: S311. If the current hash value is consistent with the historical hash value, then skip pushing the update message.

[0067] In this embodiment, if the hash comparison result in S140 is that the current hash value is consistent with the historical hash value, it means that the full tag field of the alarm has not changed since the last push. At this time, the system skips the push and does not send any update message to the message queue, thereby avoiding invalid push due to the unchanged tag content and saving message queue bandwidth and consumer processing resources.

[0068] In one embodiment, calculating the current hash value of the full tag field and comparing it with the historical hash value of the target alarm data includes: S411. The current hash value is obtained by calculating the full tag field using a preset digest algorithm; S412. Using the alarm identity identifier as the key, query the corresponding historical hash value in the distributed cache database; S413. If the current hash value is inconsistent with the historical hash value, the method further includes: S414. Update the distributed cache database with the current hash value as the new historical hash value, and set the expiration time.

[0069] In this embodiment, the specific implementation of calculating the current hash value of the full label field and comparing it with the historical hash value in S140 is as follows: First, a preset digest algorithm is used to calculate the current hash value of the full label field (i.e., the string form of the alarm_label field) generated in S130. The preset digest algorithm can be a hash algorithm such as SHA-256. By performing a hash operation on the standardized full label field string, a fixed-length hash value is generated as a digital fingerprint of the current label status of the alarm, which is used for subsequent accurate comparison with the historical hash value. Then, using the alarm identity identifier of the alarm as the key, the historical hash value stored when the alarm was last pushed is queried in a distributed cache database (e.g., Redis). In one embodiment, the storage format of the historical hash value in the distributed cache database is alarm_label_hash:{alarm id}, that is, using the fixed prefix "alarm_label_hash:" plus the alarm identity identifier as the key name. If the current hash value does not match the historical hash value retrieved, it indicates that the full tag content of the alert has changed. The system then updates the corresponding key in the distributed cache database with the current hash value as the new historical hash value and sets an expiration time (e.g., 7 days by default, configurable) to prevent cached data from accumulating indefinitely and occupying storage space. If the current hash value matches the historical hash value, no cache update is required. Through this mechanism, the system can quickly obtain historical hash values ​​during each hash comparison and update the cache promptly when tag content changes, ensuring that the latest historical hash value is obtained for the next hash comparison. Simultaneously, setting an expiration time prevents cached data from growing indefinitely.

[0070] In one embodiment, the method further includes: S511. When a recovery or clear message for the target alarm data is received, the historical hash value corresponding to the alarm identity in the distributed cache database is cleared, and a tag clear message is pushed to the message queue so that the consumer can clear the tag display status of the target alarm data.

[0071] In this embodiment, when a recovery or clearing message for the target alarm data is received, it indicates that the alarm has ended its lifecycle. At this time, the system clears the historical hash value corresponding to the alarm identity in the distributed cache database to prevent the historical hash value of the alarm from occupying cache space for a long time. Simultaneously, the system pushes a tag clearing message to the message queue. This message contains at least the alarm identity, allowing the consumer to locate the corresponding target alarm data based on the alarm identity and clear the tag display status of the alarm. Specifically, after receiving the tag clearing message as a consumer of the message queue, the alarm display platform locates the corresponding alarm record based on the alarm identity and clears all currently displayed tags for that alarm, restoring it to the initial untagged display state. By proactively pushing tag clearing messages when alarms are recovered or cleared, the residual tags of ended alarms avoid misleading maintenance personnel and ensures the consistency between the alarm display status and the actual lifecycle of the alarm.

[0072] In one embodiment, updating the label display status of the alarm with the full set of labels includes: S611. The consumer subscribes to and consumes the update message from the message queue; S612. Parse the full tag field in the update message to obtain all currently valid tag key-value pairs; S613. Locate the target alarm data according to the alarm identity identifier, and use the current tag display status of the target alarm data to directly cover the all tag key-value pairs.

[0073] In this embodiment, the consumer (i.e., the alarm display platform) acts as a consumer of the message queue, pre-subscribing to topics related to tag updates in the message queue. When an update message is pushed to the message queue in S150, the consumer subscribes to and consumes the update message in real time from the message queue. After receiving the update message, the consumer parses the full tag field (i.e., the alarm_label field) in the update message, reconstructing and obtaining all currently valid tag key-value pairs from this field. Specifically, the full tag field carried in the update message is a string with a uniform structure (e.g., a JSON string). The consumer parses this string to restore it to a set of tag key-value pairs, which includes the current tag status of all dimensions of the alarm (e.g., compressed tags, similar event tags, alarm storm tags, etc.). Then, based on the alarm identity identifier carried in the update message, the consumer locates the corresponding target alarm data in the alarm platform's data storage, and directly overwrites the current tag display status of the target alarm data using the parsed full tag key-value pairs. Specifically, the consumer removes all old tags and then displays the newly acquired tag key-value pairs as the currently valid tag set, rather than incrementally modifying or merging tags based on the old ones. Through this full-coverage update method, the consumer receives the complete state of all tags for the current alarm each time, eliminating the need to maintain incremental states locally or merge multiple batches of messages. Even if messages are out of order or lost, the consumer can restore the complete and correct tag state after receiving the next full-update message, effectively avoiding tag residue and state inconsistencies caused by message out-of-order or lost messages in incremental push methods.

[0074] Figure 2 The diagram shows a structural schematic of a computer device provided in an embodiment of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the computer device.

[0075] like Figure 2 As shown, the computer device may include: a processor 402, a communications interface 404, a memory 406, and a communications bus 408.

[0076] The processor 402, communication interface 404, and memory 406 communicate with each other via communication bus 408. Communication interface 404 is used to communicate with other network elements, such as clients or other servers. Processor 402 executes program 410, specifically performing the relevant steps described in the embodiment of the multi-dimensional alarm tag labeling method.

[0077] Specifically, program 410 may include program code, which includes computer-executable instructions.

[0078] Processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The computer device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0079] Memory 406 is used to store program 410. Memory 406 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0080] Specifically, program 410 can be called by processor 402 to cause the computer device to perform the relevant steps in the embodiment of the multi-dimensional alarm label annotation method.

[0081] This invention provides a computer-readable storage medium storing at least one executable instruction. When the executable instruction is executed on a computer device, it causes the computer device to perform the multi-dimensional alarm tagging method described in any of the above method embodiments.

[0082] This invention provides a computer program that can be called by a processor to enable a computer device to execute the multi-dimensional alarm tag labeling method in any of the above method embodiments.

[0083] This invention provides a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions, which, when executed on a computer, cause the computer to perform the multi-dimensional alarm tag labeling method described in any of the above method embodiments.

[0084] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of the present invention are not directed to any particular programming language. It should be understood that the content of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0085] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0086] Similarly, it should be understood that, in order to streamline the invention and aid in understanding one or more of the various aspects of the invention, features of the embodiments of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of the invention. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim.

[0087] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0088] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A multi-dimensional alarm tag labeling method, characterized in that, include: Acquire target alarm data, wherein the target alarm data includes alarm identification; Based on multiple preset alarm dimensions, and according to the triggering conditions independently configured by the tag calculation plugins corresponding to each alarm dimension, each tag calculation plugin is triggered to calculate the tag value of the target alarm data in each corresponding alarm dimension, and outputs a key-value pair consisting of a dimension identifier and a tag value; wherein, each tag calculation plugin uses the alarm identity identifier as an input parameter; All key-value pairs belonging to the same target alarm data are merged into a key-value pair set, and the key-value pair set is serialized into a string with a uniform structure to generate the full tag field of the target alarm data; Calculate the current hash value of the full tag field and compare it with the historical hash value of the target alarm data; If the current hash value is inconsistent with the historical hash value, an update message containing the alarm identity identifier and the full tag field will be pushed to the message queue so that the consumer can locate the target alarm data based on the alarm identity identifier and update the tag display status of the alarm with the full tag.

2. The method according to claim 1, characterized in that, The target alarm data includes one or more alarm records, which are obtained by performing structured parsing on the original alarm data. The acquisition of the target alarm data includes: The alarm content of the original alarm data is parsed in a structured manner to extract structured fields, and the original alarm content before parsing is saved to extended fields to obtain the current alarm record; the structured fields include at least the host identifier and the alarm title; Within a preset time window, based on the host identifier and alarm title, query whether there is any existing target alarm data with the same host identifier and alarm title as the current alarm record; If it does not exist, a current alarm identity identifier is generated, a new target alarm data is created based on the current alarm identity identifier, and the current alarm record is used as the alarm record of the new target alarm data; If it exists, the current alarm record will be added to the existing target alarm data.

3. The method according to claim 1, characterized in that, The tag calculation plugin is an independently packaged plugin unit, and each tag calculation plugin is triggered by a differentiated frequency scheduler according to its own configured trigger conditions; the tag calculation plugin includes at least one of the following: The compression tag plugin is used to output compressed tags that record the number of compressed events when the number of alarm events is greater than or equal to a preset compression threshold. Escape tag plugin, used to output escape tags when the original content before escaping exists in the extended field; The similar event tag plugin is used to match event numbers in the event management system with business system and alarm titles, and output similar event tags; The repeat tag plugin is used to count the number of times alarms of the same dimension occur within a preset time window. When the number of occurrences is greater than or equal to a preset repeat threshold, a repeat tag is output. The Quick Recovery Tag plugin outputs a Quick Recovery tag when an alarm is closed or resolved and the duration is less than a preset recovery threshold. The Alarm Storm Tag plugin outputs an Alarm Storm tag that records the number of storm compressions when the storm compression flag is true. The calculation logic and triggering conditions of the tag calculation plugins are defined through the plugin configuration file. When a new alarm dimension is added, the plugin is expanded by developing a new tag calculation plugin and updating the plugin configuration file.

4. The method according to claim 1, characterized in that, The step of serializing the key-value pair set into a string with a uniform structure includes: Sort the tag keys in the key-value pair set according to a preset lexicographical order or field order; The tag values ​​in the key-value pair set are subjected to type normalization processing to obtain strings with a uniform structure; the type normalization processing includes at least one of converting null values ​​to preset empty strings, converting boolean values ​​to lowercase strings, and converting numbers to strings with a specified precision.

5. The method according to claim 1, characterized in that, The method further includes: if the current hash value is consistent with the historical hash value, then skip pushing the update message.

6. The method according to claim 1, characterized in that, The step of calculating the current hash value of the full tag field and comparing it with the historical hash value of the target alarm data includes: The current hash value is obtained by calculating the full set of tag fields using a preset digest algorithm; Using the alarm identifier as the key, query the corresponding historical hash value in the distributed cache database; If the current hash value is inconsistent with the historical hash value, the method further includes: Update the distributed cache database with the current hash value as the new historical hash value, and set the expiration time.

7. The method according to claim 6, characterized in that, When a recovery or clear message for the target alarm data is received, the historical hash value corresponding to the alarm identity in the distributed cache database is cleared, and a tag clear message is pushed to the message queue so that the consumer can clear the tag display status of the target alarm data.

8. The method according to claim 1, characterized in that, The step of updating the label display status of the alarm by covering the full set of labels includes: The consumer subscribes to and consumes the updated messages from the message queue; Parse the full tag field in the update message to obtain all currently valid tag key-value pairs; The target alarm data is located based on the alarm identity identifier, and the current tag display status of the target alarm data is directly overwritten using all tag key-value pairs.

9. A computer device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of the multi-dimensional alarm tag labeling method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The storage medium stores at least one executable instruction, which, when executed on a computer device, causes the computer device to perform the operation of the multi-dimensional alarm tag labeling method as described in any one of claims 1-8.

Images