Cloud resource alarm integration optimization method and device based on multi-dimensional data

Abstract

This invention discloses a cloud resource alarm integration and optimization method based on multi-dimensional data, comprising the following steps: Step 1: constructing a cloud resource retrieval model; Step 2: establishing and storing historical alarm data; Step 3: historical alarm extraction; Step 4: multi-dimensional feature iterative update; Step 5: intelligent hierarchical classification; Step 6: deduplication post-processing; Step 7: real-time alarm weighted matching; and Step 8: alarm topology convergence. The invention also includes a cloud resource alarm integration and optimization device based on multi-dimensional data, comprising a topology model storage module, a topology model generation module, a historical alarm database, a historical alarm extraction unit, a reference alarm update module, a classification module, a post-processing module, a sorting and integration module, a topology convergence and positioning module, and an alarm output module. This invention, by constructing a three-layer cloud resource topology retrieval model, automatically merges and batch-converges alarms, and, combined with a dynamic suppression strategy for high-frequency repetitive alarms, can significantly reduce the number of redundant alarm pushes.

Description

Technical Field

[0001] This invention relates to the field of cloud computing operation and maintenance monitoring technology, and in particular to a method and apparatus for integrating and optimizing cloud resource alarms based on multi-dimensional data. Background Technology

[0002] With the widespread adoption of cloud computing, containerization, and microservice architecture, enterprise cloud resources are rapidly expanding in scale. The monitoring objects have expanded from traditional physical machines and virtual machines to diversified resources such as cloud servers, databases, middleware, containers, and service components, resulting in an exponential increase in alarm triggering frequency.

[0003] Current cloud resource alarm monitoring systems suffer from simplistic alarm classification rules and inaccurate priority determination. Traditional systems often use fixed thresholds or simple indicators to determine alarm levels without comprehensively considering multi-dimensional information such as resource importance, historical failure frequency, recovery difficulty, and business impact. This results in important alarms being overwhelmed while a large number of low-value alarms are pushed out, making it difficult for operations and maintenance personnel to allocate and process resources reasonably. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a cloud resource alarm integration and optimization method and apparatus based on multi-dimensional data.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] A method and apparatus for integrating and optimizing cloud resource alarms based on multi-dimensional data, comprising the following steps:

[0007] Step 1: Construct and store a three-layer cloud resource topology retrieval model. The first layer is the resource type query node, the second layer is the regional cluster query node, and the third layer is the instance container query node.

[0008] Step 2: Establish and store historical alarm data, which is used to store historical alarm entries. Historical alarm entries include resource information, alarm type, indicator characteristics, time series characteristics, topology characteristics, service level, processing status and processing duration information.

[0009] Step 3: Historical alarm extraction and reference alarm initialization. The historical alarm extraction unit extracts historical alarm data from the historical alarm database, randomly selects n historical alarms as reference alarms, maps the reference alarms to n² coordinate points in a two-dimensional coordinate system, and removes the reference alarms from the historical alarm data to generate the first alarm set.

[0010] Step 4: Iterative update of multi-dimensional features of reference alarms. Select a historical alarm from the first alarm set as the iterative alarm, calculate the multi-dimensional feature distance between the iterative alarm and each reference alarm, mark the reference alarm with the smallest distance as the core alarm, and dynamically update the multi-dimensional feature value of the core alarm based on the iterative alarm features.

[0011] Step 5: Intelligent classification and categorization of reference alarms. Based on the proportion of emergency alarms, business impact weight, and fault propagation range of historical alarms within the reference alarm neighborhood, reference alarms are divided into Level 1 core alarms, Level 2 important alarms, and Level 3 general alarms.

[0012] Step 6: Post-processing of reference alarms after deduplication. The categorized reference alarms are deduplicated, simplified and optimized. Redundant reference alarms of the same type and with too close coordinates are deleted to generate the final reference alarm set.

[0013] Step 7: Weighted matching and sorting integration of real-time alarms. The sorting and integration process extracts multi-dimensional features of real-time alarms, calculates the weighted distance parameter between the real-time alarm and each reference alarm in the final reference alarm set, assigns the level of the reference alarm with the smallest distance to the real-time alarm, and classifies them into the corresponding sending and processing sequence in the order of level 1, level 2, and level 3.

[0014] Step 8: Alarm topology convergence and automatic root cause location. Based on the three-layer cloud resource topology retrieval model, alarms with the same priority, the same resource link, and the same dependent nodes are merged and converged. The root cause resources are automatically located according to the alarm occurrence sequence, propagation direction, and impact range, and the integrated alarm list and root cause conclusions are output.

[0015] Preferably, the construction rules of the three-layer cloud resource topology retrieval model are as follows: a first-layer query node is generated based on the cloud resource type, including computing, storage, network, database, middleware, container, security, and application services; a second-layer query node is generated based on the region, availability zone, cluster, project, and environment to which the cloud resource belongs; a third-layer query node is generated based on the cloud resource instance ID, container Pod ID, virtual network card ID, and storage volume ID; one first-layer node is associated with multiple second-layer nodes, one second-layer node is associated with 1000 third-layer nodes, and one third-layer node is associated with 100 resource storage bits. The resource storage bits store the dependencies, upstream and downstream links, business affiliation, and alarm gateway information of the corresponding cloud resources.

[0016] Preferably, the multi-dimensional alarm features include a resource urgency feature T. o Recovery time characteristics T t Frequent stable characteristics T s The business impact feature Tᵧ is calculated using the following formulas:

[0017] Resource urgency characteristics:

[0018]

[0019] Where L is the total number of all historical alarm entries associated with the resource, L1 is the number of historical emergency alarm entries for the resource, L2 is the number of historical important alarm entries for the resource, B is the business level weight of the resource, and k1, k2, and k3 are custom weights greater than 0.

[0020] Recovery time characteristics:

[0021]

[0022] Among them, T h T represents the average recovery time for similar historical alarms currently triggering the alarm. a ᵥᵍ represents the average recovery time for alarms across the entire platform;

[0023] Frequent stable characteristics:

[0024]

[0025] Where Tⱼ is the time interval between consecutive occurrences of the current alarm, and Tstd is the standard deviation of the alarm interval for this resource;

[0026] Business impact characteristics:

[0027]

[0028] Where Cᵤ represents the number of users or service instances affected by the alarm. This refers to the total number of users or the total number of service instances in this business chain.

[0029] Preferably, the formula for calculating the multidimensional feature Euclidean distance D1 between the iterative alarm and the reference alarm is: Where Fᵢ is the i-th eigenvalue of the iterative alarm, Gᵢ is the i-th eigenvalue of the reference alarm, and i=1, 2, 3, 4 correspond to T respectively. o T t T s 、Tᵧ.

[0030] Preferably, the formula for iteratively updating the core alarm feature value is:

[0031]

[0032] Where Gⱼ(t) is the j-th eigenvalue of the core alarm before the update, Gⱼ(t+1) is the j-th eigenvalue of the core alarm after the update, Pⱼ(t) is the j-th eigenvalue of the iterative alarm, and Wⱼ is the adaptive weight of the j-th eigenvalue;

[0033] The learning coefficient hⱼ(t) satisfies:

[0034]

[0035] D2 represents the coordinate distance between the reference alarm and the core alarm in a two-dimensional coordinate system, and t represents the number of iterations.

[0036] Preferably, the classification rule for reference alarms is as follows:

[0037] For a single reference alarm, historical alarms whose multi-dimensional feature distance is less than a first distance threshold are extracted from the first alarm set to form a second alarm set;

[0038] Level 1 core alarms: Emergency alarms account for ≥60% of the second alarm set, and their business impact weight is ≥0.7;

[0039] Level 2 Important Alarms: Emergency alarms account for less than 60%, and important alarms account for more than 30%, with the proportion of important alarms being greater than that of general alarms;

[0040] Level 3 general alarms: Emergency alarms account for less than 60%, general alarms account for more than 30%, and the proportion of general alarms is greater than that of critical alarms; reference alarms that do not meet the above conditions are directly removed.

[0041] Preferably, the weighted distance parameter D3 between the real-time alarm and the reference alarm is calculated using the following formula: Where Zᵢ is the i-th dimension feature value of the real-time alarm, and Gᵢ is the i-th dimension feature value of the reference alarm. For reference, the alarm cluster weighting parameters, These are the topological association weighting coefficients;

[0042] Reference alarm cluster weighted parameters satisfy:

[0043] q represents the total number of alarms within the associated cluster to which the reference alarm belongs, and the two-dimensional coordinate distance between alarms within the associated cluster is ≤√2; topological association weighting coefficient. Satisfy: Same topology link =0.6~0.8, cross-topology link =1.0~1.2.

[0044] Preferably, the topological convergence and root cause localization steps include:

[0045] Based on the alarm-associated resource ID, query layer by layer along the three-layer cloud resource topology retrieval model to locate the resource type, regional cluster, and instance node;

[0046] Multiple real-time alarms that meet any of the following conditions will be merged into one integrated alarm: repeated triggering by the same instance in a short period of time, shared dependency in the same cluster, upstream and downstream of the same business link, or the same fault propagation path.

[0047] Determine the root cause resource based on the earliest alarm occurrence time, the largest impact range, and the lowest dependent node;

[0048] The integrated alarm output information includes: alarm level, number of integrated alarms, scope of affected resources, root cause node, suggested handling path, and estimated recovery time.

[0049] Preferably, the integrated alarm is also configured with dynamic suppression rules. If the same integrated alarm is triggered more than 3 times within 5 minutes, it will automatically enter the suppression state, and only the status will be updated without repeated push notifications. When the root cause fault is recovered or the alarm level changes, the suppression will be automatically lifted and a recovery notification will be pushed.

[0050] An apparatus for integrating and optimizing cloud resource alarms based on multi-dimensional data includes:

[0051] The topology model storage module is used to store the three-layer cloud resource topology retrieval model;

[0052] The topology model generation module connects to the historical alarm database and is used to automatically generate three-layer topology query nodes and resource storage locations based on the cloud resource structure.

[0053] Historical alarm database is used to store all historical alarm entries and feature data;

[0054] The historical alarm extraction unit is used to extract reference alarms and generate the first alarm set;

[0055] The reference alarm update module is used to iteratively update the multi-dimensional features of core alarms.

[0056] The classification module is used to perform three-level intelligent classification of reference alarms;

[0057] The post-processing module is used to deduplicate and simplify the reference alarms to generate the final reference alarm set;

[0058] The sorting and integration module is used to calculate the weighted distance of real-time alarms and complete the level matching and queue sorting.

[0059] The topology convergence and root cause localization module is used for alarm merging convergence, automatic root cause localization, and dynamic suppression.

[0060] The alarm output module is used to push integrated alarms according to priority, and display root cause conclusions and handling suggestions.

[0061] The present invention has the following beneficial effects:

[0062] 1. By comprehensively calculating and clustering four features—resource urgency, recovery timeliness, frequency of occurrence and business impact—it abandons the rigid approach of traditional single thresholds and manual rules, enabling automatic, dynamic, and accurate prioritization of massive cloud resource alarms. This ensures that core business and high-impact faults are handled first, significantly improving the rationality and effectiveness of operation and maintenance response.

[0063] 2. By constructing a three-layer cloud resource topology retrieval model, alarms with the same root cause, the same link, the same dependency, and the same instance are automatically merged and batch converged. Combined with a dynamic suppression strategy for high-frequency repetitive alarms, the number of redundant alarm pushes can be greatly reduced, avoiding alarm storms caused by fault propagation, reducing the pressure of operation and maintenance monitoring, and preventing critical fault information from being overwhelmed by massive invalid alarms.

[0064] 3. A continuous optimization closed loop is formed through historical alarm extraction, feature iterative update, intelligent classification, and deduplication post-processing. The reference alarm set can continuously self-correct with resource changes, business growth, and changes in fault modes, without the need for a large amount of manual configuration and rule maintenance. It can be adapted to various complex cloud environments such as public cloud, private cloud, container cloud, and hybrid cloud, with outstanding versatility and scalability.

[0065] 4. By combining topology, alarm timing, and fault impact range into a triple judgment logic, the system can automatically locate the root cause of the fault and restore the propagation path within seconds, and directly output the integrated alarm information and handling suggestions. This transforms the inefficient traditional manual review and investigation into an automated, one-stop process, significantly shortening the fault location and recovery time and ensuring stable business operation. Attached Figure Description

[0066] Figure 1 This is a schematic diagram of the cloud resource data collection logic of the cloud resource alarm integration and optimization method based on multi-dimensional data proposed in this invention.

[0067] Figure 2 This is a schematic diagram of the module function operation logic of the device for the cloud resource alarm integration and optimization method based on multi-dimensional data proposed in this invention. Detailed Implementation

[0068] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0069] Reference Figure 1 The cloud resource alarm integration and optimization method based on multi-dimensional data includes the following steps:

[0070] First, the overall infrastructure relies on a multi-cloud management server cluster, equipped with distributed storage units, data computing units, topology parsing units, and alarm push units. It connects to cloud resource management interfaces of multiple platforms, including public cloud, private cloud, and hybrid cloud, and connects to the platform's internal alarm collection gateway to achieve unified access and processing of alarms from all cloud resources. The distributed storage unit is used to build a historical alarm database, the data computing unit is used to complete multi-dimensional feature calculation, distance calculation, and iterative updates, the topology parsing unit is used to construct and parse a three-layer cloud resource topology retrieval model, and the alarm push unit is used to connect to notification channels such as operation and maintenance terminals, SMS, and email.

[0071] Step 1: Construct and store a three-layer cloud resource topology retrieval model

[0072] Based on the actual deployment architecture of cloud resources, a three-layer cloud resource topology retrieval model is built and persistently stored, strictly following hierarchical association rules. The first layer consists of resource type query nodes, covering eight core cloud resource categories: computing, storage, network, database, middleware, container, security, and application services. Each resource category corresponds to an independent query node. The second layer consists of regional cluster query nodes, divided according to the availability zone, cluster, project, and production / testing environment to which the cloud resource belongs. Each regional cluster node is assigned to the corresponding resource type node. The third layer consists of instance and container query nodes, generated using the cloud resource instance ID, container Pod ID, virtual network interface ID, and storage volume ID as unique identifiers.

[0073] The hierarchical association rules are set as follows: one first-level resource type node is associated with multiple second-level regional cluster nodes, one second-level regional cluster node is associated with 1000 third-level instance container nodes, and one third-level instance container node is associated with 100 resource storage slots. Each resource storage slot stores the upstream and downstream dependencies of the corresponding cloud resources, the business link affiliation, alarm gateway binding information, and resource association information in the same link, providing topology data support for subsequent alarm topology convergence and root cause localization.

[0074] Step 2: Establish and store historical alarm data

[0075] A distributed historical alarm database was built, and standardized historical alarm data was imported into the database. Each historical alarm entry in the database uniformly includes eight categories of information: resource information, alarm type, indicator characteristics, time series characteristics, topology characteristics, business level, processing status, and processing duration. Resource information includes resource ID and its corresponding topology level; alarm types include CPU overload, memory overflow, network packet loss, service downtime, and storage failure; indicator characteristics include various alarm thresholds and real-time indicator values; time series characteristics include alarm occurrence time, duration, and recurrence interval; topology characteristics include the resource's topology links and dependent nodes; business levels are divided into three levels: core business, important business, and general business, with corresponding weights set to 0.9, 0.6, and 0.3 respectively; processing status is divided into processed, unprocessed, and processing, and processing duration is the total time from alarm triggering to fault recovery. The database supports real-time data writing, historical data retrieval, feature data statistics, and batch data filtering, providing a data foundation for subsequent alarm analysis.

[0076] Step 3: Historical Alarm Extraction and Reference Alarm Initialization

[0077] The historical alarm extraction unit retrieves all valid historical alarm data from the past 90 days in the historical alarm database. After removing expired and invalid test alarms, it randomly selects 50 historical alarms as initial reference alarms. These 50 reference alarms are then mapped one by one to 2500 coordinate points in a two-dimensional Cartesian coordinate system. The coordinate mapping follows a uniform distribution rule to avoid excessive concentration of initial reference alarm coordinates. After mapping, the 50 reference alarms are removed from the fully extracted historical alarm data, generating the first alarm set, which serves as the base dataset for subsequent iterative updates. The unit also supports custom adjustment of the number of reference alarms selected, n, to adapt to the alarm processing needs of cloud platforms of different sizes.

[0078] Step 4: Iterative update based on multi-dimensional features of alarms

[0079] The reference alarm update module is activated to iteratively optimize and update the initial reference alarms. The iterative process is executed repeatedly until the preset iteration termination condition is met (the number of iterations reaches 1000 or the feature value update magnitude is less than 0.01). During each iteration, a historical alarm is randomly selected from the first alarm set as the iterative alarm. Based on preset multidimensional features, the multidimensional feature Euclidean distance between the iterative alarm and each initial reference alarm is calculated. The reference alarm with the smallest distance is selected and marked as the core alarm.

[0080] Alarm multidimensional features include resource urgency feature T o Recovery time characteristics T t Frequent stable characteristics T s The business impact characteristic Tᵧ is calculated strictly according to the following formula:

[0081] Resource urgency characteristics:

[0082]

[0083] Where L is the total number of all historical alarm entries associated with the resource, L1 is the number of historical emergency alarm entries for the resource, L2 is the number of historical important alarm entries for the resource, and B is the service level weight of the resource. In this embodiment, k1, k2, and k3 are set to 0.4, 0.3, and 0.3 respectively (all are custom weights greater than 0).

[0084] Recovery time characteristics:

[0085]

[0086] Among them, T h T represents the average recovery time for similar historical alarms currently triggering the alarm. a ᵥᵍ represents the average recovery time for alarms across the entire platform;

[0087] Frequent stable characteristics:

[0088]

[0089] Where Tⱼ is the time interval between consecutive occurrences of the current alarm. This is the standard deviation of the alarm interval for this resource;

[0090] Business impact characteristics:

[0091]

[0092] Where Cᵤ represents the number of users or service instances affected by the alarm. This refers to the total number of users or the total number of service instances in this business chain.

[0093] Multidimensional feature Euclidean distance between iterative alarms and reference alarms Strictly follow the formula

[0094]

[0095] The calculation involves Fᵢ, where Fᵢ is the i-th dimension feature value of the iterative alarm, and Gᵢ is the i-th dimension feature value of the reference alarm. i = 1, 2, 3, and 4 correspond to resource urgency, recovery timeliness, frequency stability, and business impact features, respectively. After marking core alarms, the core alarm feature value is iteratively updated according to the formula.

[0096]

[0097] Execution is performed, where Gⱼ(t) is the j-th dimension feature value of the core alarm before the update, Gⱼ(t+1) is the j-th dimension feature value of the core alarm after the update, Pⱼ(t) is the j-th dimension feature value of the iterative alarm, and Wⱼ is the adaptive weight of the j-th dimension feature (W1-W4 are set to 0.4, 0.2, 0.2, 0.2 respectively); the learning coefficient hⱼ(t) satisfies:

[0098]

[0099] The reference alarm and the core alarm are compared in a two-dimensional coordinate system. t is the number of iterations. This ensures that the feature updates closely match the actual alarm data patterns and improves the representativeness of the reference alarm.

[0100] Step 5: Refer to the intelligent classification and categorization of alarms.

[0101] After the iterative update is completed, the classification module is activated to perform neighborhood data statistics and three-level intelligent classification on all reference alarms. For a single reference alarm, historical alarms with multi-dimensional feature distances less than a preset first distance threshold are extracted from the first alarm set to form a second alarm set; in this embodiment, the first distance threshold is set to 0.8, which can be customized and adjusted according to the business needs of the cloud platform in the future. The classification rules are strictly implemented according to the preset standards: alarms with an emergency alarm ratio ≥60% and a business impact weight ≥0.7 in the second alarm set are classified as first-level core alarms; alarms with an emergency alarm ratio <60%, an important alarm ratio >30%, and an important alarm ratio greater than a general alarm ratio are classified as second-level important alarms; alarms with an emergency alarm ratio <60%, a general alarm ratio >30%, and a general alarm ratio greater than an important alarm ratio are classified as third-level general alarms; invalid reference alarms that do not meet the above three conditions are directly removed to ensure the accuracy of subsequent alarm matching.

[0102] Step Six: Processing after deduplication based on alarms

[0103] The post-processing module is activated to perform refined post-processing optimization on the reference alarms that have completed the three-level classification. The module compares the two-dimensional coordinate distances of reference alarms of the same alarm level and the same topology link one by one, and filters out redundant reference alarms with too close coordinate distances and highly overlapping features. According to the principles of alarm representativeness and coverage priority, a single typical alarm is retained and the remaining redundant alarms are deleted. At the same time, feature completion and coordinate optimization are performed on the remaining reference alarms, and finally a final reference alarm set without redundancy, covering the whole scenario and with strong representativeness is generated, which reduces the amount of computation for subsequent real-time alarm matching and improves alarm processing efficiency.

[0104] Step 7: Real-time alarm weighted matching and sorting integration

[0105] Real-time alarm data generated by the cloud platform is uploaded to the sorting and integration module. The module first extracts four-dimensional feature values ​​of real-time alarms: resource urgency, recovery time, frequency and stability, and business impact (feature value calculation is the same as the formula in step four), and then applies the weighted distance parameter formula.

[0106]

[0107] Calculate the weighted distance between real-time alarms and all alarms in the final reference alarm set. The reference alarm cluster weighting parameters are as follows. satisfy:

[0108]

[0109] q represents the total number of alarms within the associated cluster to which the reference alarm belongs, and the two-dimensional coordinate distance between alarms within the associated cluster is ≤√2; topological association weighting coefficient. The value is set to 0.7 for links within the same topology and 1.1 for links across topologies.

[0110] The reference alarm with the smallest weighted distance is selected, and its corresponding alarm level is assigned to a real-time alarm to complete the intelligent classification of real-time alarms. Then, according to the priority order of first-level core alarms, second-level important alarms, and third-level general alarms, each real-time alarm is assigned to its corresponding sending and processing sequence to realize the priority processing and priority push of high-priority alarms, and avoid the dispersion of operation and maintenance resources and the omission of core alarms.

[0111] Step 8: Alarm Topology Convergence and Automatic Root Cause Location

[0112] The topology convergence and root cause analysis module is activated, relying on a three-layer cloud resource topology retrieval model to perform topology convergence and root cause analysis on sorted real-time alarms. First, based on the resource ID associated with the alarm, the topology model is queried layer by layer upwards to accurately locate the type of alarm resource, the regional cluster, and the instance node. Then, multiple alarms that are repeatedly triggered by the same instance in a short period of time, share dependencies in the same cluster, are in the same upstream and downstream of the same business link, or have the same fault propagation path are merged and converged into a single integrated alarm, significantly reducing the number of redundant alarms.

[0113] After convergence, the root cause resource is automatically located based on three criteria: earliest alarm occurrence time, largest impact range, and lowest-level dependent node. Simultaneously, dynamic suppression rules are configured: if the same integrated alarm is triggered more than three times within 5 minutes, it automatically enters suppression mode, only updating the alarm status without repeated pushes, reducing the pressure of alarm bombardment for operations and maintenance. When the root cause fault is recovered or the alarm level changes, suppression is automatically lifted and a fault recovery notification is pushed. Finally, the integrated alarm list is output, containing full information such as alarm level, number of integrated alarms, scope of affected resources, root cause node, suggested handling path, and estimated recovery time, providing operations and maintenance personnel with accurate handling guidelines.

[0114] Furthermore, refer to Figure 2 The optimization device is an integrated unit combining hardware and software. The modules work together and communicate with each other to fully realize the entire process of the above method. The specific module functions and operating logic are as follows:

[0115] Topology model storage module:

[0116] This module is a distributed storage unit used to persistently store the completed three-layer cloud resource topology retrieval model. It has the capabilities of model query, fast reading, caching acceleration and version management. It supports second-level retrieval by three dimensions: resource type, regional cluster and instance ID. It responds to topology data retrieval requests from other modules in real time, ensuring the stability and timeliness of topology data calls. At the same time, it retains historical versions of the model and supports rollback operations after model anomalies.

[0117] Topology model generation module:

[0118] The module has a bidirectional connection between the historical alarm database and the cloud resource management interface, which can retrieve the real deployment architecture data of cloud resources in real time, automatically parse the resource hierarchy and relationship, and generate three-layer topology query nodes, hierarchical relationship and corresponding resource storage location. It has dynamic adaptation capability. When cloud resources are added, deleted or the architecture is changed, the module automatically detects and completes the real-time refresh and hierarchical reconstruction of the topology model, ensuring that the topology model is completely synchronized with the real architecture of cloud resources, without the need for manual maintenance of the model.

[0119] Historical alarm database:

[0120] As the core data support unit of the device, it adopts a distributed database architecture to persistently store all historical alarm entries, four-dimensional and multi-dimensional feature data, alarm processing records and recovery time statistics. It supports single and batch data addition, deletion, modification and query operations, supports batch import and real-time writing of historical alarm data, and has built-in feature calculation underlying algorithms to provide comprehensive support for data retrieval, feature calculation and data statistics for each module, ensuring the accuracy and efficiency of data processing.

[0121] Historical alarm retrieval unit:

[0122] The unit directly connects to the historical alarm database, extracts historical alarm samples that meet the requirements according to the preset random sampling strategy, automatically completes the initial two-dimensional coordinate mapping of reference alarms, and removes reference alarms to generate the first alarm set; it supports operation and maintenance personnel to dynamically configure the number of alarm samples, coordinate mapping rules, and filtering conditions, adapts to the processing needs of different cloud platforms and different data volumes, and ensures the rationality of the initial selection of reference alarms.

[0123] Reference alarm update module:

[0124] As one of the core computing units, it is responsible for the entire process of iteratively selecting alarms, calculating multi-dimensional feature distances, marking core alarms, and dynamically updating feature values. It supports operations and maintenance personnel to customize the configuration of iteration termination conditions, feature update magnitudes, and various weight parameters, and adjust the iteration logic according to actual business scenarios to ensure that core alarm features conform to the platform's alarm patterns and improve the accuracy of subsequent alarm matching.

[0125] Categorization module:

[0126] The module incorporates neighborhood sample statistics logic and a three-level classification algorithm. After completing the statistics of reference alarm neighborhood alarm data, it performs intelligent classification according to preset classification thresholds. It supports custom configuration of emergency alarm proportion threshold, business impact weight threshold, and distance threshold to adapt to cloud platforms with different business sensitivities. At the same time, it automatically identifies and removes invalid reference alarms, simplifying the subsequent data processing process.

[0127] Post-processing module:

[0128] For the categorized reference alarms, a process of coordinate distance comparison, redundancy judgment, and representative sample screening is initiated to accurately eliminate redundant alarms with overlapping features or too close coordinates. The remaining samples are then optimized and organized to generate a concise final reference alarm set that comprehensively covers alarm scenarios. This ensures alarm matching accuracy while reducing computational load and improving device operating efficiency.

[0129] Sorting and integration module:

[0130] The module connects to the real-time alarm collection gateway, accesses all real-time alarms from the cloud platform, and completes the entire process of four-dimensional feature extraction, weighted distance parameter calculation, alarm level matching, and processing sequence allocation. It strictly sorts the alarm queues according to the first, second, and third level alarm priorities, so as to prioritize the handling of high-level alarms and optimize the operation and maintenance alarm handling process.

[0131] Topology Convergence and Root Cause Localization Module:

[0132] The module relies on the topology model to perform resource location, merge alarms with the same root cause, and analyze the fault propagation path to automatically determine the root cause of the fault. It integrates the dynamic suppression and automatic recovery functions for high-frequency repetitive alarms to solve the problems of alarm storms and repeated pushes. The module has a built-in root cause location algorithm that combines multiple factors such as alarm timing, propagation direction, and impact range to improve the accuracy of root cause location and reduce the difficulty of fault diagnosis for operation and maintenance personnel.

[0133] Alarm output module:

[0134] As the device's external output unit, it pushes integrated alarm information to maintenance terminals, SMS, emails, and other channels according to the alarm priority strategy; it supports the visualization of alarm level, convergence quantity, impact range, root cause conclusions and handling suggestions; at the same time, it completes the persistent retention of alarm logs, the archiving of handling records, and the export of data reports, meeting the needs of maintenance review and data statistics, and realizing a closed loop of the entire alarm handling process.

[0135] By implementing the above methods, steps, and device structure, the redundancy of cloud resource alarms can be reduced by more than 60%, the accuracy of alarm root cause location can be increased to more than 92%, and the efficiency of alarm handling and response can be increased by more than 50%. This effectively solves the pain points of traditional cloud alarms, such as dispersion, redundancy, high false alarm rate, and difficulty in root cause location, and is suitable for the alarm management needs of various enterprise-level multi-cloud and hybrid cloud platforms.

[0136] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A cloud resource alarm integration and optimization method based on multi-dimensional data, characterized in that, Includes the following steps: Step 1: Construct and store a three-layer cloud resource topology retrieval model. The first layer is the resource type query node, the second layer is the regional cluster query node, and the third layer is the instance container query node. Step 2: Establish and store historical alarm data, which is used to store historical alarm entries. Historical alarm entries include resource information, alarm type, indicator characteristics, time series characteristics, topology characteristics, service level, processing status and processing duration information. Step 3: Historical alarm extraction and reference alarm initialization. The historical alarm extraction unit extracts historical alarm data from the historical alarm database, randomly selects n historical alarms as reference alarms, maps the reference alarms to n² coordinate points in a two-dimensional coordinate system, and removes the reference alarms from the historical alarm data to generate the first alarm set. Step 4: Iterative update of multi-dimensional features of reference alarms. Select a historical alarm from the first alarm set as the iterative alarm, calculate the multi-dimensional feature distance between the iterative alarm and each reference alarm, mark the reference alarm with the smallest distance as the core alarm, and dynamically update the multi-dimensional feature value of the core alarm based on the iterative alarm features. Step 5: Intelligent classification and categorization of reference alarms. Based on the proportion of emergency alarms, business impact weight, and fault propagation range of historical alarms within the reference alarm neighborhood, reference alarms are divided into Level 1 core alarms, Level 2 important alarms, and Level 3 general alarms. Step 6: Post-processing of reference alarms after deduplication. The categorized reference alarms are deduplicated, simplified and optimized. Redundant reference alarms of the same type and with too close coordinates are deleted to generate the final reference alarm set. Step 7: Weighted matching and sorting integration of real-time alarms. The sorting and integration process extracts multi-dimensional features of real-time alarms, calculates the weighted distance parameter between the real-time alarm and each reference alarm in the final reference alarm set, assigns the level of the reference alarm with the smallest distance to the real-time alarm, and classifies them into the corresponding sending and processing sequence in the order of level 1, level 2, and level 3. Step 8: Alarm topology convergence and automatic root cause location. Based on the three-layer cloud resource topology retrieval model, alarms with the same priority, the same resource link, and the same dependent nodes are merged and converged. The root cause resources are automatically located according to the alarm occurrence sequence, propagation direction, and impact range, and the integrated alarm list and root cause conclusions are output.

2. The cloud resource alarm integration and optimization method based on multi-dimensional data according to claim 1, characterized in that, The construction rules of the three-layer cloud resource topology retrieval model are as follows: first-layer query nodes are generated based on cloud resource type, including computing, storage, network, database, middleware, container, security, and application services; second-layer query nodes are generated based on the region, availability zone, cluster, project, and environment to which the cloud resource belongs. A third-level query node is generated based on the cloud resource instance ID, container Pod ID, virtual network interface ID, and storage volume ID; A first-level node is associated with multiple second-level nodes, a second-level node is associated with 1,000 third-level nodes, and a third-level node is associated with 100 resource storage slots. The resource storage slots store the dependencies of the corresponding cloud resources, upstream and downstream links, business affiliation, and alarm gateway information.

3. The cloud resource alarm integration and optimization method based on multi-dimensional data according to claim 1, characterized in that, The alarm's multi-dimensional features include the resource urgency feature T. o Recovery time characteristics T t Frequent stable characteristics T s The business impact feature Tᵧ is calculated using the following formulas: Resource urgency characteristics: Where L is the total number of all historical alarm entries associated with the resource, L1 is the number of historical emergency alarm entries for the resource, L2 is the number of historical important alarm entries for the resource, B is the business level weight of the resource, and k1, k2, and k3 are custom weights greater than 0. Recovery time characteristics: Among them, T h T represents the average recovery time for similar historical alarms currently triggering the alarm. a ᵥᵍ represents the average recovery time for alarms across the entire platform; Frequent stable characteristics: Where Tⱼ is the time interval between consecutive occurrences of the current alarm, and Tstd is the standard deviation of the alarm interval for this resource; Business impact characteristics: Where Cᵤ represents the number of users or service instances affected by the alarm. This refers to the total number of users or the total number of service instances in this business chain.

4. The cloud resource alarm integration and optimization method based on multi-dimensional data according to claim 1, characterized in that, The formula for calculating the multidimensional feature Euclidean distance D1 between iterative alarms and reference alarms is: Where Fᵢ is the i-th eigenvalue of the iterative alarm, Gᵢ is the i-th eigenvalue of the reference alarm, and i=1, 2, 3, 4 correspond to T respectively. o T t T s 、Tᵧ.

5. The cloud resource alarm integration and optimization method based on multi-dimensional data according to claim 4, characterized in that, The formula for iteratively updating the core alarm feature value is: Where Gⱼ(t) is the j-th eigenvalue of the core alarm before the update, Gⱼ(t+1) is the j-th eigenvalue of the core alarm after the update, Pⱼ(t) is the j-th eigenvalue of the iterative alarm, and Wⱼ is the adaptive weight of the j-th eigenvalue; The learning coefficient hⱼ(t) satisfies: D2 represents the coordinate distance between the reference alarm and the core alarm in a two-dimensional coordinate system, and t represents the number of iterations.

6. The cloud resource alarm integration and optimization method based on multi-dimensional data according to claim 1, characterized in that, The classification rules for reference alarms are as follows: For a single reference alarm, historical alarms whose multi-dimensional feature distance is less than a first distance threshold are extracted from the first alarm set to form a second alarm set; Level 1 core alarms: Emergency alarms account for ≥60% of the second alarm set, and their business impact weight is ≥0.7; Level 2 Important Alarms: Emergency alarms account for less than 60%, and important alarms account for more than 30%, with the proportion of important alarms being greater than that of general alarms; Level 3 general alarms: Emergency alarms account for less than 60%, general alarms account for more than 30%, and the proportion of general alarms is greater than that of critical alarms; reference alarms that do not meet the above conditions are directly removed.

7. The cloud resource alarm integration and optimization method based on multi-dimensional data according to claim 1, characterized in that, The formula for calculating the weighted distance parameter D3 between real-time alarms and reference alarms is: Where Zᵢ is the i-th dimension feature value of the real-time alarm, and Gᵢ is the i-th dimension feature value of the reference alarm. For reference, the alarm cluster weighting parameters, These are the topological association weighting coefficients; Reference alarm cluster weighted parameters satisfy: q represents the total number of alarms within the associated cluster to which the reference alarm belongs, and the two-dimensional coordinate distance between alarms within the associated cluster is ≤√2; topological association weighting coefficient. Satisfy: Same topology link =0.6~0.8, cross-topology link =1.0~1.

2.

8. The cloud resource alarm integration and optimization method based on multi-dimensional data according to claim 1, characterized in that, Topological convergence and root cause localization steps include: Based on the alarm-associated resource ID, query layer by layer along the three-layer cloud resource topology retrieval model to locate the resource type, regional cluster, and instance node; Multiple real-time alarms that meet any of the following conditions will be merged into one integrated alarm: repeated triggering by the same instance in a short period of time, shared dependency in the same cluster, upstream and downstream of the same business link, or the same fault propagation path. Determine the root cause resource based on the earliest alarm occurrence time, the largest impact range, and the lowest dependent node; The integrated alarm output information includes: alarm level, number of integrated alarms, scope of affected resources, root cause node, suggested handling path, and estimated recovery time.

9. The cloud resource alarm integration and optimization method based on multi-dimensional data according to claim 8, characterized in that, The integrated alarm is also configured with dynamic suppression rules. If the same integrated alarm is triggered more than 3 times within 5 minutes, it will automatically enter the suppression state, and only the status will be updated without repeated push notifications. When the root cause fault is recovered or the alarm level changes, the suppression will be automatically lifted and a recovery notification will be pushed.

10. An apparatus for implementing the cloud resource alarm integration and optimization method based on multi-dimensional data as described in any one of claims 1-9, characterized in that, include: The topology model storage module is used to store the three-layer cloud resource topology retrieval model; The topology model generation module connects to the historical alarm database and is used to automatically generate three-layer topology query nodes and resource storage locations based on the cloud resource structure. Historical alarm database is used to store all historical alarm entries and feature data; The historical alarm extraction unit is used to extract reference alarms and generate the first alarm set; The reference alarm update module is used to iteratively update the multi-dimensional features of core alarms. The classification module is used to perform three-level intelligent classification of reference alarms; The post-processing module is used to deduplicate and simplify the reference alarms to generate the final reference alarm set; The sorting and integration module is used to calculate the weighted distance of real-time alarms and complete the level matching and queue sorting. The topology convergence and root cause localization module is used for alarm merging convergence, automatic root cause localization, and dynamic suppression. The alarm output module is used to push integrated alarms according to priority, and display root cause conclusions and handling suggestions.

Images