A cloud platform-assisted monitoring system

Abstract

This invention relates to the field of Internet technology, and in particular to a cloud platform assisted monitoring system, including a monitoring task management module, an anomaly judgment module, a link construction module, a root cause localization module, a confidence locking module, and a backend maintenance module. This invention sets up comprehensive monitoring tasks to collect service status data and computing resource index data of core components of control nodes and computing nodes. After preprocessing, time-series feature parameters are extracted and anomalies are judged. Simultaneously, based on a preset component relationship graph, upstream and downstream dependent components are traversed to construct an anomaly propagation link. Furthermore, candidate root cause components are screened through multi-dimensional scoring, and root cause confidence scores are calculated by combining deviation analysis of real-time behavioral data to determine the final root cause component and generate a root cause list. This automatically triggers corresponding maintenance or repair processes, thereby achieving accurate identification of cloud platform anomalies, propagation link tracing, and root cause localization, significantly improving the efficiency of cloud platform monitoring and management.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to a cloud platform-assisted monitoring system. Background Technology

[0002] With the widespread adoption and large-scale application of cloud computing technology, cloud platforms have become critical infrastructure for supporting core business operations, data storage, and computing power scheduling for government and enterprises. Their architectural complexity continues to increase, encompassing massive control nodes, computing nodes, and diverse core component services (such as object storage services, computing services, and network services). The stable operation of these core component services and the efficient utilization of computing resources (CPU, memory, disk, network bandwidth, etc.) directly determine the continuity, reliability, and user experience of the services carried by the cloud platform. However, existing cloud platform monitoring systems still face numerous technical bottlenecks in practical applications. Traditional monitoring often focuses on threshold-triggered alarms for single indicators, lacking comprehensive correlation analysis of service status data of core components and computing resource indicators. This makes it easy to misjudge normal fluctuations such as increased business load as abnormalities. At the same time, it is difficult to identify potential faults caused by the coordinated deviation of multiple indicators, resulting in alarm flooding or missed alarms. Moreover, after an anomaly occurs, it often spreads along the dependency link, making it impossible to trace the propagation path and scope of impact of the anomaly. This makes it difficult for operation and maintenance personnel to clarify the anomaly correlation, and also leads to long root cause location time and low accuracy. Furthermore, existing monitoring systems mostly only provide basic anomaly information after alarms, lacking automated maintenance or repair mechanisms that match the anomaly type. To address the aforementioned technical shortcomings, a solution is proposed. Summary of the Invention

[0003] The purpose of this invention is to provide a cloud platform-assisted monitoring system to address the aforementioned technical deficiencies. This invention sets up comprehensive monitoring tasks, extracts time-series feature parameters and performs anomaly determination. Simultaneously, it traverses upstream and downstream dependent components based on a preset component relationship graph to construct anomaly propagation links. Furthermore, it filters candidate root cause components through multi-dimensional scoring, calculates root cause confidence scores by combining deviation analysis of real-time behavioral data, determines the final root cause component, generates a root cause list, and automatically triggers corresponding maintenance or repair processes. This achieves accurate identification of cloud platform anomalies, propagation link tracing, and root cause location, significantly improving the efficiency of cloud platform monitoring and management, as well as the timeliness and accuracy of fault handling.

[0004] The objective of this invention can be achieved through the following technical solution: a cloud platform-assisted monitoring system, comprising a monitoring task management module, an anomaly determination module, a link construction module, a root cause localization module, a confidence locking module, and a backend maintenance module; The monitoring task management module includes: Monitoring Task Configuration Unit: Used to set the monitoring tasks for the control nodes and computing nodes of the monitoring cloud platform. The monitoring tasks include core component services and computing resource metrics. Data Acquisition and Preprocessing Unit: Collects and preprocesses the core component service status data and computing resource indicator data of the control node and computing node to obtain standardized status data and standardized resource indicator data; The anomaly detection module is used to segment standardized status data and standardized resource indicator data using a sliding window algorithm, while setting anomaly trend conditions, identifying potential anomalies, verifying and processing potential anomalies, and finally outputting alarm information. The link construction module is used to retrieve a preset component relationship graph and extract the initial node of the anomaly and construct the anomaly propagation link based on alarm information; The root cause localization module is used to perform time-series screening and multi-dimensional fusion analysis on abnormal propagation links, and output a list of suspected root cause components; The confidence locking module is used to analyze the behavioral data of suspected root cause components, and outputs root cause confidence scores, builds a list of root cause components, and builds a list of tracing root causes. The backend maintenance module is used to respond to the source tracing list, automatically trigger maintenance or recovery requests, and retrieve the pre-set maintenance or repair script set that matches the exception type of the final source component.

[0005] Preferably, the analysis process of the anomaly detection module is as follows: A sliding window is set up, and the sliding window algorithm is used to segment the standardized state data and standardized resource index data. The time series characteristic parameters of data change slope, fluctuation amplitude and mean deviation in each sliding window are calculated. A preset linear regression model is selected to fit and analyze the time series characteristic parameters. Abnormal trend conditions are set. If any abnormal trend condition is met, it is initially determined to be a potential anomaly. Different resource metrics of the same component and corresponding related metrics of upstream and downstream dependent components are selected as the correlation verification dimensions. If the related metric data corresponding to a potential anomaly simultaneously deviates abnormally or does not meet the normal correlation logic within a preset time period, the verification passes, and it is ultimately determined to be an anomaly, generating alarm information.

[0006] Preferably, the analysis process of the link construction module is as follows: Retrieve the preset component relationship graph. The preset component relationship graph is a directed graph structure with components as nodes and relationships as edges. Based on the alarm information, extract the first component that triggered the abnormal alarm, mark it as the abnormal initial node, and obtain the time of the abnormal occurrence and the core abnormal indicators of the abnormal initial node. Starting from the initial node of the anomaly, the downstream dependent components of the initial node of the anomaly are traversed based on the directed edges of the preset component relationship graph to obtain the downstream failure probability of each downstream dependent component. The downstream failure probability is then judged. If the downstream failure probability is greater than the preset downstream failure probability threshold, it is judged as an associated anomaly. A complete downstream anomaly propagation chain is formed based on the initial node of the anomaly and the downstream dependent components corresponding to the associated anomaly.

[0007] Preferably, the downstream failure probability analysis process for the downstream dependent components is as follows: Obtain the propagation pattern of the initial node of the anomaly and its downstream components. The propagation patterns include point-to-point pattern and relational pattern. Point-to-point mode: ε downstream = ε initial × rs upstream and downstream × pc initial, where ε downstream represents the downstream failure probability, ε initial is the initial node failure probability, rs upstream and downstream is the dependency of upstream and downstream components, and pc initial is the preset propagation capability of the initial abnormal node. Relationship pattern: ε downstream = max{ε upstream 1 × rs1 × pc1, ε upstream 2 × rs2 × pc2, ..., ε upstream n × rsn × pcn}, where n is a natural number greater than zero, taking the maximum value of the propagation probability of all upstream components; Traverse the component relationship graph, query the upstream dependent components of the abnormal initial node, obtain the dependency degree between the upstream dependent components and the abnormal initial node, remove the upstream dependent components whose dependency degree is lower than the preset dependency degree threshold, and build a pool of remaining valid upstream dependent components.

[0008] Preferably, for each valid upstream dependent component, check whether the exception triggering timestamp TU of the valid upstream dependent component and the exception triggering timestamp TX of the exception initiation node satisfy: TU≤TX+ΔT, where ΔT is a preset time tolerance window; If none of the valid upstream dependent components satisfy TU≤TX+ΔT, then the abnormal initial node is set as the suspected root source node; If at least one valid upstream dependent component satisfies TU≤TX+ΔT, then obtain the anomaly type of the initial node and the anomaly type of the valid upstream dependent component that satisfies TU≤TX+ΔT. At the same time, retrieve the preset anomaly type matching rule table. Based on the preset anomaly type matching rule table, determine whether the anomaly type of the initial node and the anomaly type of the valid upstream dependent component satisfy the anomaly type of the valid upstream dependent component. If they satisfy, then set the corresponding valid upstream dependent component as a suspected root source node. If they do not satisfy, then set the initial node as a suspected root source node. A complete anomaly propagation chain is formed based on the suspected root cause node and the downstream dependent components corresponding to the associated anomalies.

[0009] Preferably, the analysis process of the root cause localization module is as follows: Based on the abnormal propagation chain, the first abnormal trigger time of all abnormal components is extracted, sorted in ascending order of time, and the top 5 components with the earliest time are selected as candidate root cause components. The historical failure frequency, abnormal duration, preset impact weight of the component, and dimension score Wi (i = 1, 2, 3, 4) and preset proportional coefficient Bi corresponding to the position of the propagation chain of each candidate root cause component in the past 3 months are obtained. The final score of a component is calculated based on Σ (the score for each dimension Wi × the preset proportional coefficient Bi). The components are then sorted in descending order of their final scores to generate a list of suspected root cause components.

[0010] Preferably, the analysis process of the confidence locking module is as follows: Based on the list of suspected root cause components, the behavior data of each suspected root cause component is collected in real time during the time of the failure. The real-time behavior data is preprocessed to generate the current behavior dataset. Based on the current behavior dataset, calculate the deviation Dg between the current behavior and the preset baseline features for each indicator, where g is a natural number greater than zero and g represents the indicator. Calculate the comprehensive deviation S = Σ (single indicator deviation Dg × indicator weight Cg). Retrieve the preset comprehensive deviation range [Smin, Smax], compare and analyze the comprehensive deviation S with the preset comprehensive deviation range [Smin, Smax], and output the high confidence deviation, medium confidence deviation, or low confidence deviation. Obtain the confidence scores corresponding to high, medium, or low confidence bias. Calculate the root cause confidence score based on the component's final score + the real-time confidence score of the suspected root cause component × a preset confidence coefficient. Sort the root cause components in descending order of their confidence scores to generate a list of root cause components. Based on the root cause component list, the first suspected root cause component is set as the final root cause component, and a source tracing root cause list is constructed based on the final root cause component, root cause confidence score, abnormal propagation path and other information.

[0011] The beneficial effects of this invention are as follows: (1) This invention analyzes multi-dimensional data of service status and computing resource indicators of core components, and combines linear regression model fitting analysis and correlation verification to achieve anomaly judgment, significantly improve the accuracy and reliability of anomaly identification, reduce the interference of invalid alarms on operation and maintenance work, and at the same time, with the help of the preset component relationship graph, it can start from the initial node of the anomaly, traverse the upstream and downstream dependent components, and build a complete anomaly propagation link. It can not only clearly present the path and scope of the anomaly from the root component to the downstream, but also trace the upstream potential triggering components, thus solving the problem of ambiguous anomaly correlation and difficulty in defining the boundary of influence in the prior art. (2) This invention achieves initial root cause location through multi-dimensional quantitative analysis, and then integrates the deviation analysis of real-time behavioral data and preset baseline features to achieve in-depth root cause location. It realizes the automation and quantitative decision-making of root cause location, greatly shortens the fault investigation time, improves the accuracy and efficiency of root cause location, and triggers automated maintenance or recovery process based on the root cause list, effectively improving the availability and monitoring and management efficiency of the cloud platform. Attached Figure Description

[0012] The invention will now be further described with reference to the accompanying drawings; Figure 1 This is a flowchart of the system of the present invention; Figure 2 This is a reference diagram for analyzing the list of suspected root cause components of the present invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments; Example 1:

[0015] Please see Figures 1 to 2 As shown, the present invention is a cloud platform-assisted monitoring system, including a monitoring task management module, an anomaly judgment module, a link construction module, a root cause localization module, a confidence locking module, and a backend maintenance module. The monitoring task management module and the anomaly judgment module have a one-way communication connection, the anomaly judgment module and the link construction module have a one-way communication connection, the link construction module and the root cause localization module have a one-way communication connection, the root cause localization module and the confidence locking module have a one-way communication connection, and the confidence locking module and the backend maintenance module have a one-way communication connection. The monitoring task management module includes a monitoring task configuration unit and a data acquisition preprocessing unit; The monitoring task configuration unit is used to set the monitoring tasks for the control nodes and computing nodes of the monitoring cloud platform. The monitoring tasks include core component services and computing resource indicators. Core component services include object storage services, computing services, network services, etc., and computing resource indicators include CPU utilization, memory utilization, etc. The data acquisition and preprocessing unit is responsible for collecting and preprocessing the core component service status data and computing resource indicator data of the control node and computing node to obtain standardized status data and standardized resource indicator data, specifically including: Collect status data and computing resource metrics data of the core component services of control nodes and computing nodes; The status data of core component services includes component running status, service response time, connection success rate, etc. Computing resource metrics include key indicators such as CPU utilization, memory usage, disk space utilization, and network bandwidth usage. The collected status data and computing resource index data of core component services are preprocessed (such as noise reduction and cleaning) to obtain standardized status data and standardized resource index data; The anomaly detection module uses a sliding window algorithm to segment standardized status data and standardized resource indicator data, sets anomaly trend conditions, identifies potential anomalies, verifies and processes these anomalies, and finally outputs alarm information, including: A sliding window is set up, and the sliding window algorithm is used to segment the standardized state data and standardized resource index data, and the time series characteristic parameters such as the slope of data change, fluctuation amplitude, and mean deviation in each sliding window are calculated. The length of the sliding window can be customized according to the data acquisition frequency, with a value range of 5-30 acquisition cycles. A preset linear regression model is selected to fit and analyze the time series characteristic parameters. Abnormal trend conditions are set, including the slope of data change exceeding the preset slope threshold, the fluctuation amplitude exceeding the preset fluctuation threshold, and the duration of abnormal trend reaching the preset duration threshold. If any abnormal trend condition is met, it is initially judged as a potential anomaly. Different resource metrics of the same component (such as CPU utilization and memory usage) and corresponding related metrics of upstream and downstream dependent components (such as the response time of the service caller and the processing time of the callee) are selected as the correlation verification dimensions. If the related metric data corresponding to a potential anomaly simultaneously deviates abnormally or does not meet the normal correlation logic within a preset time period, the verification passes, and it is finally determined to be an anomaly, generating alarm information. The alarm information includes time-series characteristic parameters, anomaly trend type, correlation verification results, etc., which makes it easier for operation and maintenance personnel to trace the anomaly evolution process. For example, a cloud server (component A) serves as a core business computing node. Its normal correlation logic is that "when CPU utilization increases, memory usage also increases synchronously, and the ratio of their increases is between 1:0.8 and 1:1.2". If the CPU utilization of component A increases from 30% to 85% (exceeding the preset fluctuation threshold, initially judged as a potential anomaly), and its memory usage increases from 25% to 78%, the increase ratio is 1:0.92, which conforms to the normal correlation logic. Therefore, the potential anomaly is judged as a normal fluctuation caused by the increase in business load, and no alarm is generated. If the memory usage remains unchanged at 25%, the increase ratio is 1:0, which violates the normal correlation logic. The verification passes, and it is judged as an anomaly (possibly due to issues such as wasted CPU resources or abnormal task scheduling). Example 2:

[0016] The link construction module is used to retrieve a preset component relationship graph and, based on alarm information, extract the initial node of the anomaly and construct the anomaly propagation link, specifically including: Retrieve the preset component relationship graph. The preset component relationship graph is a directed graph structure with components as nodes and relationships as edges (e.g., API gateway - application service - database, with edges labeled with call dependencies (e.g., dependency degree) and influence weights (e.g., 0.8)). Based on the alarm information, extract the first component that triggered the abnormal alarm, mark it as the abnormal initial node, and obtain the time of the abnormal occurrence and core abnormal indicators of the abnormal initial node; Starting from the initial node of the anomaly, and based on the directed edges of the preset component relationship graph, the downstream dependent components of the initial node of the anomaly (i.e., the components called / affected by this node) are traversed to obtain the downstream failure probability of each downstream dependent component. The downstream failure probability is then judged and processed. If the downstream failure probability is greater than the preset downstream failure probability threshold, it is judged as an associated anomaly. A complete downstream anomaly propagation chain is formed based on the initial node of the anomaly and the downstream dependent components corresponding to the associated anomaly (e.g., database connection pool exhaustion - application service query failure - API gateway request backlog - front-end access timeout). The downstream failure probability analysis process for downstream dependent components is as follows: Obtain the propagation pattern of the initial node of the anomaly and its downstream components. The propagation patterns include point-to-point pattern and relational pattern. Point-to-point mode: ε downstream = ε initial × rs upstream and downstream × pc initial, where ε downstream represents the downstream failure probability, ε initial is the initial node failure probability, rs upstream and downstream is the dependency of upstream and downstream components, and pc initial is the preset propagation capability of the initial abnormal node (determined by component importance and resource utilization). Relationship pattern: ε downstream = max{ε upstream 1 × rs1 × pc1, ε upstream 2 × rs2 × pc2, ..., ε upstream n × rsn × pcn}, where n is a natural number greater than zero, taking the maximum value of the propagation probability of all upstream components; Traverse the component relationship graph, query the upstream dependent components of the abnormal initial node (i.e. the components that call the abnormal initial node), obtain the dependency degree between the upstream dependent components and the abnormal initial node, remove the upstream dependent components whose dependency degree is lower than the preset dependency degree threshold, and build a pool of remaining valid upstream dependent components. For each valid upstream dependent component, check whether the exception trigger timestamp TU of the valid upstream dependent component and the exception trigger timestamp TX of the exception initial node satisfy: TU≤TX+ΔT, where ΔT is a preset time tolerance window; If none of the valid upstream dependent components satisfy TU≤TX+ΔT, then the abnormal initial node is set as the suspected root source node; If at least one valid upstream dependent component satisfies TU≤TX+ΔT, then obtain the anomaly type of the initial node and the anomaly type of the valid upstream dependent component that satisfies TU≤TX+ΔT. At the same time, retrieve the preset anomaly type matching rule table. Based on the preset anomaly type matching rule table, determine whether the anomaly type of the initial node and the anomaly type of the valid upstream dependent component satisfy the anomaly type of the valid upstream dependent component. If they satisfy, then set the corresponding valid upstream dependent component as a suspected root source node. If they do not satisfy, then set the initial node as a suspected root source node. A complete anomaly propagation chain is formed based on the suspected root source node (valid upstream dependent component or abnormal initial node) and the downstream dependent component corresponding to the associated anomaly; For example: if the initial node of an exception is of exception type Y, then the effective upstream dependent components will have a mapping relationship of exception type Z; If the initial node of the exception actually experiences exception type Y, and the effective upstream dependent component experiences exception type Z, then the exception is considered to be successfully matched, that is, the preset exception type matching rule table is satisfied. If the initial node of the exception actually experiences exception type Y, and the effective upstream dependent component experiences exception type K, then the exception matching is deemed unsuccessful, meaning the preset exception type matching rule table is not met. Example 3:

[0017] The root cause localization module is used to perform time-series screening and multi-dimensional fusion analysis on abnormal propagation links, and outputs a list of suspected root cause components, specifically including: Based on the anomaly propagation path, the first anomaly trigger time of all anomaly components is extracted and sorted in ascending order of time; The five earliest components were selected as candidate root cause components, and components that were triggered later than the core anomaly time window (e.g., within 5 minutes after the earliest anomaly) were excluded. The historical failure frequency, anomaly duration, preset impact weight, and propagation chain position of each candidate root cause component were obtained over the past three months. Obtain the historical failure frequency, anomaly duration, preset impact weight of each component, and dimension score Wi (i = 1, 2, 3, 4) and preset proportional coefficient Bi corresponding to the position of the propagation chain for each candidate root cause component in the past 3 months. For example: the score W1 for the dimension of historical failure frequency in the past 3 months: if the historical failure frequency in the past 3 months is >3 times, W1 = 10 points; if the historical failure frequency in the past 3 months is 2 or 3 times, W1 = 5 points; if the historical failure frequency in the past 3 months is 1 time, W1 = 3 points; if the historical failure frequency in the past 3 months is 0 times, W1 = 0 points. The score for the duration of an anomaly is W2: if the duration of an anomaly is >30 minutes, W2 = 10 points; if the duration of an anomaly is 10 minutes ≤ the duration of an anomaly is ≤30 minutes, W2 = 5 points; if the duration of an anomaly is <10 minutes, W2 = 3 points. Component preset influence weight dimension score W3: W3 is scored directly according to the component preset influence weight (e.g., weight 1.0 gets 10 points, 0.5 gets 5 points). W4 scoring for the position in the propagation chain: The first node in the abnormal propagation chain gets 10 points, and each downstream node loses 2 points. The final score of the component is calculated based on Σ (the score of each dimension Wi × the preset proportional coefficient Bi). The components are sorted in descending order of their final scores to generate a list of suspected root cause components. The confidence locking module analyzes behavioral data of suspected root cause components, outputting a root cause confidence score, constructing a list of root cause components, and constructing a list of tracing root causes. Specifically, it includes: Based on the list of suspected root cause components, the behavior data of each suspected root cause component during the fault occurrence period is collected in real time, including memory usage, CPU usage, service response time, etc. The real-time behavior data is preprocessed (missing values ​​are removed and the format is standardized) to generate the current behavior dataset. Based on the current behavior dataset, the deviation between the current behavior and the preset baseline features is calculated for each indicator (using the standardized deviation formula): Deviation D = |Current indicator value - Baseline mean| / Baseline standard deviation; Calculate the overall deviation S = Σ(single index deviation Dg × index weight Cg), where g is a natural number greater than zero, and g represents the index. Retrieve the preset comprehensive deviation range [Smin, Smax], compare the comprehensive deviation S with the preset comprehensive deviation range [Smin, Smax], and if the comprehensive deviation S > Smax, it is determined to be a high confidence deviation; if the comprehensive deviation ∈ [Smin, Smax], it is determined to be a medium confidence deviation; if the comprehensive deviation S < Smin, it is determined to be a low confidence deviation. Obtain the confidence score corresponding to high, medium, or low confidence bias. For example, a confidence score of 50 points corresponds to high confidence bias, a confidence score of 10 points corresponds to medium confidence bias, and a confidence score of -20 points corresponds to low confidence bias. The root cause confidence score is calculated by multiplying the final component score by the real-time confidence score of the suspected root cause component by the preset confidence coefficient. The root cause components are then sorted in descending order by their root cause confidence scores to generate a list of root cause components. Based on the root cause component list, the first suspected root cause component is set as the final root cause component, and a source tracing root cause list is constructed based on the final root cause component, root cause confidence score, abnormal propagation link and other information. The backend maintenance module is used to respond to the root cause list, automatically trigger maintenance or recovery requests, and retrieve the pre-set maintenance or repair script set that matches the exception type of the final root cause component, so as to maintain or repair the final root cause component based on the pre-set maintenance or repair script set, thereby improving the monitoring and management efficiency of the cloud platform. In summary, this invention analyzes multi-dimensional data on the service status and computing resource indicators of core components, combined with linear regression model fitting analysis and correlation verification, to achieve anomaly detection. This significantly improves the accuracy and reliability of anomaly identification, reduces the interference of invalid alarms on operation and maintenance work, and, with the help of a preset component relationship graph, can start from the initial node of the anomaly and traverse upstream and downstream dependent components to construct a complete anomaly propagation chain. This not only clearly presents the path and scope of the anomaly's spread downstream from the root component, but also traces upstream potential triggering components, solving the problems of ambiguous anomaly relationships and difficulty in defining impact boundaries in existing technologies. Furthermore, multi-dimensional quantitative analysis enables preliminary root cause location, followed by in-depth root cause location by integrating deviation analysis of real-time behavioral data and preset baseline features. This achieves automated and quantitative decision-making for root cause location, significantly shortens fault diagnosis time, improves the accuracy and efficiency of root cause location, and triggers automated maintenance or recovery processes based on the root cause list, effectively improving the availability and monitoring and management efficiency of the cloud platform.

[0018] The threshold is set for comparative analysis of results to determine whether they are good or bad. The value of the threshold is determined by a combination of large-scale model analysis of sample data and human experience. It can also be adjusted appropriately based on seasonal or common-sense influencing factors.

[0019] 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 platform-assisted monitoring system, characterized in that, It includes a monitoring task management module, an anomaly detection module, a link construction module, a root cause localization module, a confidence locking module, and a backend maintenance module; The monitoring task management module includes: Monitoring Task Configuration Unit: Used to set the monitoring tasks for the control nodes and computing nodes of the monitoring cloud platform. The monitoring tasks include core component services and computing resource metrics. Data Acquisition and Preprocessing Unit: Collects and preprocesses the core component service status data and computing resource indicator data of the control node and computing node to obtain standardized status data and standardized resource indicator data; The anomaly detection module is used to segment standardized status data and standardized resource indicator data using a sliding window algorithm, while setting anomaly trend conditions, identifying potential anomalies, verifying and processing potential anomalies, and finally outputting alarm information. The link construction module is used to retrieve a preset component relationship graph and extract the initial node of the anomaly and construct the anomaly propagation link based on alarm information; The root cause localization module is used to perform time-series screening and multi-dimensional fusion analysis on abnormal propagation links, and output a list of suspected root cause components; The confidence locking module is used to analyze the behavioral data of suspected root cause components, and outputs root cause confidence scores, builds a list of root cause components, and builds a list of tracing root causes. The backend maintenance module is used to respond to the source tracing list, automatically trigger maintenance or recovery requests, and retrieve the pre-set maintenance or repair script set that matches the exception type of the final source component.

2. The cloud platform-assisted monitoring system according to claim 1, characterized in that, The analysis process of the anomaly detection module is as follows: A sliding window is set up, and the sliding window algorithm is used to segment the standardized state data and standardized resource index data. The time series characteristic parameters of data change slope, fluctuation amplitude and mean deviation in each sliding window are calculated. A preset linear regression model is selected to fit and analyze the time series characteristic parameters. Abnormal trend conditions are set. If any abnormal trend condition is met, it is initially determined to be a potential anomaly. Different resource metrics of the same component and corresponding related metrics of upstream and downstream dependent components are selected as the correlation verification dimensions. If the related metric data corresponding to a potential anomaly simultaneously deviates abnormally or does not meet the normal correlation logic within a preset time period, the verification passes, and it is ultimately determined to be an anomaly, generating alarm information.

3. The cloud platform-assisted monitoring system according to claim 1, characterized in that, The analysis process of the link construction module is as follows: Retrieve the preset component relationship graph. The preset component relationship graph is a directed graph structure with components as nodes and relationships as edges. Based on the alarm information, extract the first component that triggered the abnormal alarm, mark it as the abnormal initial node, and obtain the time of the abnormal occurrence and the core abnormal indicators of the abnormal initial node. Starting from the initial node of the anomaly, the downstream dependent components of the initial node of the anomaly are traversed based on the directed edges of the preset component relationship graph to obtain the downstream failure probability of each downstream dependent component. The downstream failure probability is then judged. If the downstream failure probability is greater than the preset downstream failure probability threshold, it is judged as an associated anomaly. A complete downstream anomaly propagation chain is formed based on the initial node of the anomaly and the downstream dependent components corresponding to the associated anomaly.

4. The cloud platform-assisted monitoring system according to claim 3, characterized in that, The downstream failure probability analysis process for the downstream dependent components is as follows: Obtain the propagation pattern of the initial node of the anomaly and its downstream components. The propagation patterns include point-to-point pattern and relational pattern. Point-to-point mode: ε downstream = ε initial × rs upstream and downstream × pc initial, where ε downstream represents the downstream failure probability, ε initial is the initial node failure probability, rs upstream and downstream is the dependency of upstream and downstream components, and pc initial is the preset propagation capability of the initial abnormal node. Relationship pattern: ε downstream = max{ε upstream 1 × rs1 × pc1, ε upstream 2 × rs2 × pc2, ..., ε upstream n × rsn × pcn}, where n is a natural number greater than zero, taking the maximum value of the propagation probability of all upstream components; Traverse the component relationship graph, query the upstream dependent components of the abnormal initial node, obtain the dependency degree between the upstream dependent components and the abnormal initial node, remove the upstream dependent components whose dependency degree is lower than the preset dependency degree threshold, and build a pool of remaining valid upstream dependent components.

5. The cloud platform-assisted monitoring system according to claim 4, characterized in that, For each valid upstream dependent component, check whether the exception trigger timestamp TU of the valid upstream dependent component and the exception trigger timestamp TX of the exception initial node satisfy: TU≤TX+ΔT, where ΔT is a preset time tolerance window; If none of the valid upstream dependent components satisfy TU≤TX+ΔT, then the abnormal initial node is set as the suspected root source node; If at least one valid upstream dependent component satisfies TU≤TX+ΔT, then obtain the anomaly type of the initial node and the anomaly type of the valid upstream dependent component that satisfies TU≤TX+ΔT. At the same time, retrieve the preset anomaly type matching rule table. Based on the preset anomaly type matching rule table, determine whether the anomaly type of the initial node and the anomaly type of the valid upstream dependent component satisfy the anomaly type of the valid upstream dependent component. If they satisfy, then set the corresponding valid upstream dependent component as a suspected root source node. If they do not satisfy, then set the initial node as a suspected root source node. A complete anomaly propagation chain is formed based on the suspected root cause node and the downstream dependent components corresponding to the associated anomalies.

6. The cloud platform-assisted monitoring system according to claim 1, characterized in that, The analysis process of the root cause localization module is as follows: Based on the abnormal propagation chain, the first abnormal trigger time of all abnormal components is extracted, sorted in ascending order of time, and the top 5 components with the earliest time are selected as candidate root cause components. The historical failure frequency, abnormal duration, preset impact weight of the component, and dimension score Wi (i = 1, 2, 3, 4) and preset proportional coefficient Bi corresponding to the position of the propagation chain of each candidate root cause component in the past 3 months are obtained. The final score of a component is calculated based on Σ (the score for each dimension Wi × the preset proportional coefficient Bi). The components are then sorted in descending order of their final scores to generate a list of suspected root cause components.

7. The cloud platform-assisted monitoring system according to claim 1, characterized in that, The analysis process of the confidence locking module is as follows: Based on the list of suspected root cause components, the behavior data of each suspected root cause component is collected in real time during the time of the failure. The real-time behavior data is preprocessed to generate the current behavior dataset. Based on the current behavior dataset, calculate the deviation Dg between the current behavior and the preset baseline features for each indicator, where g is a natural number greater than zero and g represents the indicator. Calculate the comprehensive deviation S = Σ (single indicator deviation Dg × indicator weight Cg). Retrieve the preset comprehensive deviation range [Smin, Smax], compare and analyze the comprehensive deviation S with the preset comprehensive deviation range [Smin, Smax], and output the high confidence deviation, medium confidence deviation, or low confidence deviation. Obtain the confidence scores corresponding to high, medium, or low confidence bias. Calculate the root cause confidence score based on the component's final score + the real-time confidence score of the suspected root cause component × a preset confidence coefficient. Sort the root cause components in descending order of their confidence scores to generate a list of root cause components. Based on the root cause component list, the first suspected root cause component is set as the final root cause component, and a source tracing root cause list is constructed based on the final root cause component, root cause confidence score, abnormal propagation path and other information.

Images