Fault root cause positioning and adjusting method and device based on micro-service structure system

Abstract

The embodiment of the invention discloses a fault root cause positioning and adjusting method and device based on a micro-service structure system. A specific embodiment of the method comprises the following steps: determining micro-service application deployment scene information; performing link generation on the multi-source micro-service operation and maintenance information set to obtain a micro-service calling topological link set; performing anomaly detection on the micro-service calling topological link set to obtain an abnormal micro-service node set; pruning the micro-service calling topological link set to obtain a pruned micro-service calling topological link set; performing fault root cause positioning on the pruned micro-service calling topological link set to obtain a micro-service fault root cause node set; performing multi-dimensional analysis on the micro-service fault root cause node set to obtain a target fault root cause information set; and micro-service fault response information and system fault report information are generated, and system adjustment is carried out. According to the embodiment, the accuracy, timeliness and scene coverage of fault root cause positioning can be improved, and the safety and performance of a micro-service structure system can be improved.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to a method and apparatus for troubleshooting and adjusting the root cause of failures in a microservice architecture system. Background Technology

[0002] With the rapid development of computer technology, server microservice architectures, characterized by loose coupling and high scalability, have seen rapid growth. However, when faults occur within these architectures, the complex call relationships make it difficult to quickly and accurately pinpoint the fault, reducing the stability and performance of the microservice architecture. The typical approach for root cause analysis and adjustment is as follows: upon detecting a fault alarm, system monitoring data is obtained. Then, a root cause analysis method based on trace anomaly detection is used to locate the root cause in the system monitoring data, obtaining a root cause analysis information set. Finally, the system is dynamically adjusted based on this information set.

[0003] However, in practice, it has been found that when using the above methods to locate and adjust the root cause of a fault, the following technical problems often exist: Since the root cause is located only through system monitoring data, the factors that cause the system failure are relatively singular. In addition, the root cause location method of trace anomaly detection has problems such as incomplete coverage and link interruption. Furthermore, trace requires a lot of system resources and has root cause location latency in high-concurrency scenarios, resulting in low accuracy of root cause location, long location time, low stability and performance of microservice architecture systems, and increased failure rate of system equipment.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the present disclosure concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure propose a method and apparatus for troubleshooting and adjusting the root cause of failures in a microservice architecture system, in order to solve one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a method for troubleshooting and adjusting fault root cause analysis of a microservice architecture system, comprising: in response to detecting fault alarm information of the microservice architecture system, determining microservice application deployment scenario information associated with the fault alarm information; obtaining a multi-source microservice operation and maintenance information set of the microservice application deployment scenario information; dynamically generating topology links from the multi-source microservice operation and maintenance information set to obtain a microservice call topology link set; and performing adjacency dependency anomaly detection on the microservice call topology link set based on the multi-source microservice operation and maintenance information set to obtain an abnormal microservice node. The system first identifies a set of abnormal microservice nodes. Then, it performs link pruning on the microservice call topology link set to obtain a pruned microservice call topology link set. Next, it performs root cause analysis on the pruned microservice call topology link set to obtain a microservice fault root cause node set. Finally, it performs rule-based multidimensional analysis on the microservice fault root cause node set to obtain a target fault root cause information set. Based on this target fault root cause information set, it generates and stores microservice fault response information and system fault report information. Finally, based on the microservice fault response information, it performs system adjustments on the microservice architecture system.

[0008] Secondly, some embodiments of this disclosure provide a fault root cause localization and adjustment device based on a microservice architecture system, comprising: a determining unit configured to determine microservice application deployment scenario information associated with the fault alarm information in response to detecting fault alarm information of the microservice architecture system; an acquiring unit configured to acquire a multi-source microservice operation and maintenance information set of the microservice application deployment scenario information; a topology link generation unit configured to dynamically generate topology links from the multi-source microservice operation and maintenance information set to obtain a microservice call topology link set; and an adjacency dependency anomaly detection unit configured to perform adjacency dependency anomaly detection on the microservice call topology link set based on the multi-source microservice operation and maintenance information set to obtain an abnormal microservice node. The system comprises: a node set; a link pruning unit, configured to perform link pruning on the microservice call topology link set based on the abnormal microservice node set, to obtain a pruned microservice call topology link set; a fault root cause localization unit, configured to perform fault root cause localization on the pruned microservice call topology link set, to obtain a microservice fault root cause node set; a rule multidimensional analysis unit, configured to perform rule multidimensional analysis on the microservice fault root cause node set, to obtain a target fault root cause information set; and a generation unit, configured to generate and store microservice fault response information and system fault report information based on the target fault root cause information set, and to perform system adjustments on the microservice structure system based on the microservice fault response information.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, such that when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any implementation of the first aspect.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0011] The above embodiments of this disclosure have the following beneficial effects: The fault root cause localization and adjustment method for microservice architecture systems in some embodiments of this disclosure can improve the accuracy, timeliness, and scenario coverage of fault root cause localization, thereby improving the security and performance of microservice architecture systems. Specifically, the reasons for the low accuracy, long localization time, low stability and performance of microservice architecture systems, and increased system equipment failure rate are as follows: Since root cause localization is performed solely through system monitoring data, the factors influencing system failures are relatively singular. Furthermore, the root cause localization method using trace anomaly detection suffers from incomplete coverage and link interruption issues. Additionally, trace requires significant system resources and suffers from root cause localization latency in high-concurrency scenarios, resulting in low accuracy, long localization time, low stability and performance of microservice architecture systems, and increased system equipment failure rate. Based on this, the fault root cause localization and adjustment method for microservice architecture systems in some embodiments of this disclosure can first, in response to the detection of fault alarm information in the microservice architecture system, determine the microservice application deployment scenario information associated with the aforementioned fault alarm information. Here, determining the microservice application deployment scenario information effectively establishes a strong binding relationship between data, microservices, and the scenario, avoiding data chaos in subsequent multi-source microservice operation and maintenance information sets. Secondly, a multi-source microservice operation and maintenance information set is obtained based on the aforementioned microservice application deployment scenario information. This multi-source information set improves data comprehensiveness and the correlation of multimodal data, avoiding the monotony of a single data source. Thirdly, dynamic topology link generation is performed on the aforementioned multi-source information set to obtain a microservice call topology link set. This dynamic topology link generation allows for timely updates to the microservice call topology link set, improving the real-time nature of the links and the accuracy of the dependencies between microservices. Next, based on the aforementioned multi-source information set, adjacency dependency anomaly detection is performed on the microservice call topology link set to obtain an abnormal microservice node set. Anomaly detection using the multi-source information set improves the accuracy of anomaly detection, facilitating subsequent link pruning. Finally, based on the abnormal microservice node set, link pruning is performed on the microservice call topology link set to obtain a pruned microservice call topology link set. Here, by pruning normal microservice nodes, we can better focus on the abnormal links, effectively eliminate interference from normal microservice nodes, shorten the data scope for subsequent root cause localization, and improve the efficiency of root cause analysis. Next, we perform root cause localization processing on the pruned microservice call topology link set to obtain the microservice fault root cause node set. Here, performing root cause localization on the pruned links can increase the processing scope of root cause localization, improve the efficiency of root cause localization, and reduce the resources required for root cause localization. Then, we perform rule-based multidimensional analysis on the above microservice fault root cause node set to obtain the target fault root cause information set.Here, combining expert experience with rule-based multidimensional analysis based on root cause localization can further improve the accuracy of root cause localization. Finally, based on the aforementioned target root cause information set, microservice fault response information and system fault report information are generated and stored. Furthermore, based on the aforementioned microservice fault response information, system adjustments are made to the microservice architecture system. This improves the timeliness of microservice architecture system fault recovery, enhances the quality of system fault report information, and prevents the recurrence of the same fault through system fault reports, thereby improving system stability and security, enhancing the security of the servers included in the system, and reducing server failure rates. Therefore, this root cause localization and adjustment method for microservice architecture systems can improve the accuracy, timeliness, and scenario coverage of root cause localization, and enhance the security and performance of microservice architecture systems. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0013] Figure 1 This is a flowchart of some embodiments of the fault root cause localization and adjustment method for microservice architecture systems according to the present disclosure; Figure 2 This is a schematic diagram of the entire process from detecting fault alarm information to generating system fault report information in some embodiments of the fault root cause localization and adjustment method for microservice architecture systems according to this disclosure. Figure 3 This is a structural schematic diagram of some embodiments of the fault root cause localization and adjustment device for a microservice architecture system according to the present disclosure; Figure 4 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0014] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0015] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0016] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0017] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0018] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0019] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] Figure 1 A flowchart 100 is shown, illustrating some embodiments of a fault root cause localization and adjustment method for a microservice-based system according to this disclosure. This fault root cause localization and adjustment method for a microservice-based system includes the following steps: Step 101: In response to the detection of fault alarm information in the microservice architecture system, determine the microservice application deployment scenario information associated with the aforementioned fault alarm information.

[0021] In some embodiments, the executing entity (e.g., an electronic device) of the above-described fault root cause localization and adjustment method based on a microservice architecture system can obtain fault alarm information in response to the detection of a fault in the microservice architecture system via a wired or wireless connection, and determine the microservice application deployment scenario information associated with the fault alarm information. The microservice architecture system can be a system comprising multiple (e.g., dozens to hundreds) microservices or services, each deployed on several servers. The fault alarm information can be an alarm message indicating an abnormal situation in the microservice architecture system, which sends the abnormal situation information to the corresponding associated personnel. The fault alarm information can be an alarm message issued by the UIOC (Urgent Incident Operation Center) associated with the microservice architecture system or by the microservice architecture system itself. When the fault alarm information is at the disaster level, the UIOC system and the monitoring system associated with the microservice architecture system interface to obtain the monitoring data of the microservice architecture system and initiate a UIOC event, enabling communication and maintenance among personnel from different aspects (e.g., operations, development, database, business, etc.). When the above fault alarm information is at the critical level, the alarm information will be sent to relevant personnel for fault repair. Alternatively, relevant personnel can briefly describe and analyze the alarm information and then initiate the UIOC process for fault repair. The brief description and analysis can include: the current resource classification output of the microservice architecture system, the current business monitoring output, and the scope of the fault's impact. The current resource classification output can include CPU (Central Processing Unit) utilization growth in the half hour before the fault occurred, abnormal service processes, Kafka topic partition message backlog, database large transaction list, and long-running SQL (Structured Query Language) statements. The current business monitoring output can include business volume growth in the half hour before the fault occurred (e.g., sudden increases and decreases). The monitoring system can be used to monitor system change information, common component information, and business system information within 24 hours of the microservice architecture system. The common component information can be the monitoring status information of components on which the microservice architecture system depends (e.g., database components, middleware, big data components, network components, and storage components). The aforementioned microservice application deployment scenario information can be information about the deployment unit and deployment environment associated with fault alarm information.The aforementioned microservice application deployment scenario information can be composed of deployment units (components) designed by the microservice architecture system designers on the canvas system, associated with fault alarm information, and the deployment environment (required resources of the components). This information is used to determine the attribution of the deployment environment and scenario information, i.e., the business scenario. This microservice application deployment scenario information can facilitate narrowing down the scope of faults and accelerate the efficiency and effectiveness of root cause analysis.

[0022] In some optional implementations of certain embodiments, the process of determining the microservice application deployment scenario information associated with the detected fault alarm information in the microservice architecture system may include the following steps: The first step is to perform information parsing processing on the above fault alarm information to obtain fault parsing alarm information. This fault parsing alarm information can be information extracted from the above fault alarm information and transformed into standardized, computer-readable structured data.

[0023] The second step is to identify the microservice application deployment canvas information that is associated with the aforementioned fault analysis alarm information within the microservice application deployment canvas information set, and use this information as the target microservice application deployment canvas information. This microservice application deployment canvas information within the aforementioned microservice application deployment canvas information set can be information about the deployment units and deployment environments involved in the canvas system under different business scenarios designed by the microservice architecture system designers.

[0024] The third step involves mapping and associating resource scenarios for the set of microservice components included in the aforementioned target microservice application deployment canvas information to obtain microservice application deployment scenario information. This resource scenario mapping and association can involve mapping and associating microservice components with the component resources they require, thus determining the attribution information of resources and business scenarios. The aforementioned component resources can be isolated resources associated with the same component in different business scenarios.

[0025] Step 102: Obtain a multi-source microservice operation and maintenance information set containing microservice application deployment scenario information.

[0026] In some embodiments, the aforementioned execution entity can obtain a multi-source microservice operation and maintenance information set of the aforementioned microservice application deployment scenario information. The multi-source microservice operation and maintenance information in the aforementioned multi-source microservice operation and maintenance information set can be monitoring data from different aspects associated with the microservice architecture system. The aforementioned multi-source microservice operation and maintenance information set can include, but is not limited to, at least one of the following: microservice access log information set, microservice performance information set, microservice call information set, component resource information, network information, and interface call load information. The microservice access log information in the aforementioned microservice access log information set can be access logs of each microservice collected in real time by a collector, and the access logs are in a standard format. The aforementioned standard format can include, but is not limited to, at least one of the following: microservice identification information, access request time, response time, access status code, global identifier (TraceID) of the access request chain, and local identifier (SpanID) of a single operation of a single microservice in the access request chain. The microservice performance information in the aforementioned microservice performance information set can be information obtained from the CMDB (Configuration Management Database) system, including microservice-server mapping information, application system affiliation information, version information, dependency configuration information, and business owner information. The microservice call information in the aforementioned microservice call information set can be trace tree structure data, span hierarchy information, microservice name, parent-child span relationship information, call time information, and error identification information obtained from the APM (Application Performance Management) system.

[0027] Step 103: Dynamically generate topology links from the multi-source microservice operation and maintenance information set to obtain the microservice call topology link set.

[0028] In some embodiments, the aforementioned execution entity can dynamically generate topology links from the aforementioned multi-source microservice operation and maintenance information set to obtain a microservice call topology link set. The microservice call topology links in the aforementioned microservice call topology link set can be information representing the call relationship links, composed of interface call relationships between multiple service components included in multiple microservices associated with fault alarm information, and represented by a topology graph. The relationship between the aforementioned microservices and service components can be a one-to-many relationship. Service components can be independent software units constituting a microservice, and each component is used to run a single business function. The aforementioned service components can be, but are not limited to, at least one of the following: Kafka component, Redis (RemoteDictionary Server) component, and MySQL component.

[0029] In some optional implementations of certain embodiments, the aforementioned multi-source microservice operation and maintenance information set includes: microservice access log information set, microservice performance information set, and microservice call information set.

[0030] The above-mentioned dynamic topology link generation of the multi-source microservice operation and maintenance information set to obtain the microservice call topology link set may include the following steps: The first step involves preprocessing the aforementioned microservice access log information set, microservice performance information set, and microservice call information set to obtain the target microservice access log information set, target microservice performance information set, and target microservice call information set. In practice, the executing entity can first use regular expression validation to verify and process invalid data in the aforementioned multi-source microservice operation and maintenance information set, resulting in a validated multi-source microservice operation and maintenance information set. Then, the validated multi-source microservice operation and maintenance information set undergoes data completion processing and data format unification processing to obtain the target microservice access log information set, target microservice performance information set, and target microservice call information set.

[0031] The second step involves recursively parsing the target microservice call information set to obtain a set of microservice call triples. These microservice call triples can be composed of triples representing parent-child call relationships within directed edges constructed using `parent_span_id`.

[0032] The third step involves performing a dual match between the aforementioned microservice call triple set and the target microservice performance information set to obtain a microservice call matching triple set. Specifically, the microservice call matching triples in this set can be obtained by performing a dual match between the microservice call triple set and the target microservice performance information set using the microservice name and microservice IP (Internet Protocol Address) information to complete and verify the microservice call triples.

[0033] The fourth step involves performing window deduplication on the aforementioned microservice call matching triplet set to obtain a deduplicated microservice call triplet set. This window deduplication can be achieved by adaptively adjusting the time window based on the call frequency of the microservices included in the microservice call matching triplet set, thus deduplicating the call edges within the adaptive window. The adaptive call time window can be a 2-minute window for high-frequency microservices (e.g., more than 1000 calls per second) and a 10-minute window for low-frequency microservices.

[0034] Fifth, based on the target microservice access log information set, determine the call-side indicator information set of the deduplicated microservice call triple set. The call-side indicator information in this set can be information used to characterize the performance of the call side. This call-side indicator information may include, but is not limited to, at least one of the following: call frequency information, average call time information, call error rate, and call change frequency. In practice, the executing entity can extract and statistically analyze the target microservice access log information set to obtain the call-side indicator information set of the deduplicated microservice call triple set.

[0035] Step 6: Construct a topology graph using the aforementioned set of call edge metric information and the deduplicated microservice call triples to obtain an initial call topology link set. The initial call topology links in this set can be initially determined call links, and each microservice node and call edge included in the initial call topology link contains attribute information representing the performance of the microservice node and call edge. In practice, the executing entity can first determine the set of metric weight values ​​for each metric included in the aforementioned set of call edge metric information. Secondly, it can determine the weighted sum of the aforementioned set of metric weight values ​​and the various metrics included in the aforementioned set of call edge metric information to obtain a call edge weight information set. Then, it can input the aforementioned set of call edge weight information and the deduplicated microservice call triples into the graph database to obtain the initial call topology link set.

[0036] Step 7: Incrementally update the initial call topology link set to obtain the microservice call topology link set. In practice, the execution entity can first incrementally and synchronously update the initial call topology link set at preset intervals to obtain the updated call topology link set. The preset interval can be a pre-defined time, such as 20 seconds. Next, perform conflict handling on the updated call topology link set to obtain the conflict-handled call link set. Conflict handling can be triggered when the weight fluctuation of the same call edge exceeds 0.5 (e.g., the error rate suddenly increases from 1% to 50%), triggering secondary verification (re-matching and verifying with the target microservice access log information set and the target microservice call information set). Then, perform node lifecycle processing on the conflict-handled call link set to obtain the microservice call topology link set. Node lifecycle processing can include: marking microservice nodes with no call records for more than 30 minutes as gray nodes; removing gray nodes with no calls for 1 hour from the conflict-handled call link set; and automatically restoring and updating the status of removed microservice nodes when they resume calls.

[0037] Step 104: Based on the multi-source microservice operation and maintenance information set, perform adjacency dependency anomaly detection on the microservice call topology link set to obtain the abnormal microservice node set.

[0038] In some embodiments, the aforementioned execution entity can perform adjacency dependency anomaly detection on the aforementioned microservice call topology link set based on the aforementioned multi-source microservice operation and maintenance information set, thereby obtaining an abnormal microservice node set. The abnormal microservice nodes in the aforementioned abnormal microservice node set can be microservice nodes exhibiting single-point local anomalies and system-wide cascading anomalies. These anomalies can include, but are not limited to, at least one of the following: CPU anomalies, thread pool anomalies, JVM (Java Virtual Machine) anomalies, microservice node interface call failures, and call response time anomalies. The aforementioned system-wide cascading anomalies can be anomalies where an anomaly has a chain reaction.

[0039] As an example, the aforementioned execution entity can utilize the isolated forest algorithm to perform adjacency dependency anomaly detection on the aforementioned microservice call topology link set based on the aforementioned multi-source microservice operation and maintenance information set, thereby obtaining an abnormal microservice node set.

[0040] In some optional implementations of certain embodiments, the above-mentioned method of performing adjacency dependency anomaly detection on the microservice call topology link set based on the multi-source microservice operation and maintenance information set to obtain an abnormal microservice node set may include the following steps: The first step involves extracting time-series performance features from each microservice node within the aforementioned multi-source microservice operation and maintenance information set, based on the microservice call topology link set. This yields a microservice node feature vector set. The microservice node feature vectors in this set characterize the time-series features and call information of the microservice nodes. The time-series features may include: the maximum, minimum, and average values ​​of the metrics within the adaptive time window; the magnitude of metric mutations; and the fluctuation coefficient of the time-series metrics. The call information may include: call response time, call error rate, call error rate growth rate, and call response time variance. This time-series performance feature extraction can be performed using a bidirectional long short-term memory neural network model.

[0041] The second step involves aggregating the adjacency topology features of each microservice node to obtain a set of node adjacency topology aggregated feature vectors. These feature vectors characterize the average latency, error rate, adjacency structure importance, and topological dependency strength of the microservice node's aggregated one-hop or two-hop neighboring nodes. The adjacency structure importance information may include the number of upstream and downstream nodes and the call chain depth. The topological dependency strength information can be the proportion of call frequencies between the microservice node and its neighboring nodes; a higher proportion indicates a stronger dependency. In practice, the execution entity can first perform adjacency node sampling processing on each microservice node to obtain a set of sampled adjacency nodes. This set of sampled adjacency nodes can be obtained using a random sampling method with replacement, centered on the microservice node and consisting of one-hop and two-hop neighboring nodes. Then, using GCN (Graph Convolutional Networks), the above-mentioned set of adjacent sampled nodes is subjected to adjacency topology feature aggregation processing to obtain a set of node adjacency topology aggregated feature vectors.

[0042] The third step involves performing feature filtering and concatenation on the aforementioned node adjacency topology aggregated feature vector set and the aforementioned microservice node feature vector set to obtain a node concatenated feature vector set. The node concatenated feature vectors in this set can be feature vectors obtained by concatenating the aforementioned node adjacency topology aggregated feature vectors and the corresponding microservice node feature vectors. In practice, the executing entity can first perform information filtering on the aforementioned node adjacency topology aggregated feature vector set and the aforementioned microservice node feature vector set using mutual information methods to obtain a filtered aggregated feature vector set and a filtered node feature vector set. Then, the filtered aggregated feature vector set and the filtered node feature vector set are concatenated to obtain the node concatenated feature vector set.

[0043] The fourth step involves inputting the aforementioned node concatenation feature vector set into the node structured anomaly detection model to obtain the initial abnormal microservice node set. The initial abnormal microservice nodes in this set can be the abnormal nodes output by the node structured anomaly detection model. This node structured anomaly detection model can be a machine learning model that performs unsupervised anomaly detection and auxiliary fault location on the input node concatenation feature vector set using multi-source microservice operation and maintenance information sets, and outputs the initial abnormal microservice node set. For example, this node structured anomaly detection model could be an improved isolated forest model. The model parameters of this improved isolated forest model can include: adjusting the isolated forest parameters for core microservices to a tree depth of 10 and a sample size threshold of 50 to improve anomaly detection sensitivity; adjusting the isolated forest parameters for non-core microservices to a tree depth of 8 and a sample size threshold of 100 to reduce the false detection rate; and introducing historical anomaly comparison features, i.e., the similarity between the current feature vector and historical feature vectors, to compensate for the data sparsity deficiency in low-frequency service detection. The anomaly score of the output node in the improved isolated forest model can be dynamically adjusted by combining service level and node change information. For example, the anomaly score of a core microservice needs to be greater than or equal to 40 to be considered an anomaly node, and the anomaly score of a non-core microservice needs to be greater than or equal to 50 to be considered an anomaly node.

[0044] The fifth step is to perform anomaly propagation reasoning on the initial abnormal microservice node set based on the microservice call topology link set mentioned above, and obtain the abnormal microservice node set.

[0045] As an example, the aforementioned execution entity can first map the initial abnormal microservice nodes to the aforementioned microservice call topology link set, obtaining an abnormally marked call link set. The abnormally marked call links can be call links that mark the abnormal nodes based on their microservice level, dependency strength, and abnormal occurrence timestamp. Then, a weighted sum is performed on the microservice level, dependency strength, and call frequency ratio to determine the edge weight set of the call edge set included in the abnormally marked call link set, and a directed weighted graph is constructed according to the call order of the abnormally marked call links, resulting in a weighted propagation graph. Next, the abnormal nodes in the weighted propagation graph are sorted from largest to smallest according to the product of the edge weight set and the abnormal occurrence time difference, resulting in an abnormal node sorting result set. Finally, the top preset number of abnormal nodes are selected from the abnormal node sorting result set as the abnormal microservice node set. The preset number can be a pre-defined number, which can be determined according to specific circumstances and will not be elaborated further here.

[0046] Step 105: Based on the abnormal microservice node set, perform link pruning on the microservice call topology link set to obtain the pruned microservice call topology link set.

[0047] In some embodiments, the execution entity may perform link pruning on the microservice call topology link set based on the abnormal microservice node set, to obtain a pruned microservice call topology link set. The pruned microservice call topology links in the pruned microservice call topology link set may be links obtained by removing nodes located at the starting position and those in a normal state from the original microservice call topology links.

[0048] In some optional implementations of certain embodiments, the process of performing link pruning on the microservice call topology link set based on the abnormal microservice node set to obtain a pruned microservice call topology link set may include the following steps: The first step involves identifying the node status of each microservice node within the aforementioned microservice call topology chain, resulting in a microservice node status information set. This set of microservice node status information characterizes the degree of anomaly of each microservice node. This set can include: abnormal node status information, risky node status information, and normal node status information. Risky node status information might indicate a microservice node whose query rate per second is abnormally high or low, but whose call failure rate and response time are normal; that is, the status of a microservice node that underwent relevant change operations near the time of the failure. This node status identification can be performed using a rule engine, which can be an engine formed from node status rule information.

[0049] The second step involves performing anomaly clustering on the aforementioned set of abnormal microservice nodes to obtain a set of abnormal microservice node clusters. These clusters can be composed of multiple neighboring abnormal microservice nodes. The anomaly clustering process can be performed using a density-based clustering algorithm that extracts the topological distance from the topological hierarchy depth and the number of call edges between microservice nodes.

[0050] The third step is to determine the central microservice node set and the target microservice node set of the aforementioned abnormal microservice node cluster set, which will be used as the abnormal cluster microservice node set. The central microservice node in the central microservice node set can be the microservice node located at the center point of the aforementioned abnormal microservice node cluster. The target cluster microservice node in the target cluster microservice node set can be the microservice node among the microservice nodes included in the aforementioned abnormal microservice node cluster that has the most connections to upstream microservice nodes.

[0051] The fourth step involves multi-threaded parallel traversal of the aforementioned set of abnormal cluster microservice nodes and leaf nodes to obtain a set of abnormal cluster node sequences and a set of leaf nodes. The set of leaf nodes is a collection of leaf nodes within a set of microservice nodes. The sequence of abnormal cluster nodes in the sequence set can be obtained by performing a breadth-first search (BFS) traversal on the aforementioned abnormal cluster microservice nodes. Similarly, the sequence of leaf nodes can be obtained by performing a BFS traversal on the aforementioned set of leaf nodes. In practice, the execution entity can first determine the corresponding cluster traversal thread set and leaf traversal thread set for the aforementioned set of abnormal cluster microservice nodes and leaf nodes. Then, using the Grey Wolf heuristic algorithm, thread scheduling is performed on the cluster traversal thread set and leaf traversal thread set to obtain the scheduled cluster traversal thread set and the scheduled leaf traversal thread set. Finally, using the post-scheduled cluster traversal thread set and the post-scheduled leaf traversal thread set, the above-mentioned abnormal cluster microservice node set and microservice leaf node set are traversed in parallel by multiple threads to obtain the abnormal cluster node sequence set and leaf node sequence.

[0052] Fifth, based on the above abnormal cluster node sequence set, the above leaf node sequence, and the above microservice node status information set, perform parallel link pruning on the above microservice call topology link set to obtain the pruned microservice call topology link set.

[0053] As an example, the aforementioned execution entity can utilize a link pruning rule engine to perform parallel link pruning on the aforementioned microservice call topology link set based on the aforementioned abnormal cluster node sequence set, the aforementioned leaf node sequence, and the aforementioned microservice node status information set, thereby obtaining a pruned microservice call topology link set. The aforementioned link pruning rule engine can be a rule engine composed of multiple microservice node pruning rule information. The aforementioned multiple microservice node pruning information can include, but is not limited to, at least one of the following: deleting leaf nodes whose microservice node status is normal; retaining the upstream and downstream first-level call links (including normal nodes) of high-risk nodes (risk value ≥ 70 points); retaining only directly associated abnormal node links of low-risk nodes (risk value < 70 points); and retaining microservice nodes whose status is normal and whose microservice nodes are connected to microservice nodes whose status is abnormal or non-existent.

[0054] Step 106: Perform root cause location processing on the pruned microservice call topology link set to obtain the microservice fault root cause node set.

[0055] In some embodiments, the aforementioned execution entity may perform root cause localization processing on the pruned microservice call topology link set to obtain a microservice fault root cause node set. The microservice fault root cause nodes in the aforementioned microservice fault root cause node set can be used to identify the root cause of the fault alarm information occurring in the microservice architecture system.

[0056] In some optional implementations of certain embodiments, the above-described root cause localization processing of the pruned microservice call topology link set to obtain a microservice fault root cause node set may include the following steps: The first step is to extract business components from the pruned microservice call topology set to obtain an abnormal business component information set. This abnormal business component information set can be composed of multiple service components extracted from the pruned microservice call topology set, representing the abnormality of components in a specific business scenario.

[0057] The second step involves identifying the abnormal functional component information set based on the aforementioned abnormal business component information set, using a call graph model to analyze the pruned microservice call topology link set, thereby obtaining the abnormal functional component information set. The abnormal functional component information in this set can be information about each service component included in the aforementioned abnormal business component information set. In practice, the executing entity can utilize a TCG (Transaction Call Graph) to identify the abnormal functional component information set based on the aforementioned abnormal business component information set, using a call graph model to analyze the pruned microservice call topology link set.

[0058] The third step involves determining the component business weight value set, component anomaly timing information set, and propagation path characteristic information set of the aforementioned abnormal functional component information set, which serve as the multi-source information set for functional components. The component business weight values ​​in the aforementioned component business weight value set represent the weight of the abnormal functional component. These component business weight values ​​can be obtained by quantifying the level information and business type information of the aforementioned business components, multiplying them, and then normalizing the results. The component anomaly timing information in the aforementioned component anomaly timing information set can be the anomaly time difference between the anomaly occurrence timestamp of the abnormal functional component and the alarm timestamp of the business component; the smaller the time difference, the faster the anomaly propagates and the more likely it is to be root cause information. The propagation path characteristic information in the aforementioned propagation path characteristic information set can be the shortest propagation path length from the functional component to the business component and the number of downstream components affected, i.e., the breadth of propagation.

[0059] The fourth step involves filtering the aforementioned abnormal functional component information set based on the multi-source information set of the functional components, resulting in a candidate abnormal functional component information set. The candidate abnormal functional component information in this set can be component information that meets the filtering criteria selected from the aforementioned abnormal functional component information set. These filtering criteria may include, but are not limited to, at least one of the following: the component's business weight value is greater than or equal to a preset weight value; the abnormal time difference is less than or equal to a preset time threshold; and the propagation breadth information is greater than or equal to a preset propagation breadth threshold. The preset weight value, preset time threshold, and preset propagation breadth threshold can all be pre-set values, and can take values ​​of 2, 30 minutes, and 1.

[0060] The fifth step involves performing transaction vector encoding on the aforementioned candidate abnormal functional component information set to obtain a component alarm transaction vector set. The component alarm transaction vectors in this set can be vectors obtained by genetically encoding the component's business weight value, abnormal time difference, propagation breadth information, and shortest propagation path length based on the encoding length.

[0061] Step 6: Based on the aforementioned component alarm transaction vector set, generate a frequent transaction support mining function. This frequent transaction support mining function can be a weighted sum that minimizes the sequence support, component business weight value, anomaly time difference, propagation breadth information, and shortest propagation path length of the aforementioned component alarm transaction vector set.

[0062] Step 7: Based on the aforementioned frequent transaction support mining function, perform heuristic frequent mining on the aforementioned component alarm transaction vector set to obtain the component frequent alarm transaction set. The component frequent alarm transactions in the aforementioned component frequent alarm transaction set can be a set of functional component anomaly events or an ordered sequence whose support for component anomaly transactions is greater than or equal to a preset support threshold. The aforementioned component anomaly transactions can be a set of functional component anomaly events or an ordered sequence. For example, the aforementioned component anomaly transactions could be: sixth cache component anomaly → fourth service gateway component anomaly → first business interface component anomaly. The aforementioned preset support threshold can be a pre-set threshold used to determine whether something is frequent. The aforementioned support can be the ratio of the number of occurrences of functional component anomaly events to the total number of functional component anomaly events.

[0063] As an example, the aforementioned execution entity can use a greedy heuristic algorithm to perform heuristic frequent mining on the aforementioned component alarm transaction vector set based on the aforementioned frequent transaction support mining function, thereby obtaining the component frequent alarm transaction set.

[0064] Step 8: Based on the set of frequent alarm transactions of the above components, perform root cause location processing on the pruned microservice call topology link set to obtain the microservice fault root cause node set.

[0065] As an example, the aforementioned execution entity can first input the set of frequently alarming transactions of the aforementioned components into the frequent transaction support mining function to obtain a set of transaction support function values. Then, it can filter out the set of frequently alarming transactions of the components corresponding to the top preset number of transaction support function values ​​from the set of transaction support function values, and use this as the target component's frequently alarming transaction set. The preset number of transactions can be a pre-defined number, such as 10. Finally, it can perform deduplication processing on the set of functional components included in the target component's frequently alarming transaction set to obtain the microservice failure root cause node set.

[0066] In addressing the technical challenges mentioned above, the application scenario—internet data centers during promotional periods—often presents the following issues: root cause analysis of pruned microservice call topology only considers single-step dependencies, neglecting the impact of historical traversal processes and upstream / downstream nodes on anomaly propagation probabilities. Furthermore, the presence of numerous microservice nodes in the pruned microservice call topology results in low accuracy of root cause analysis, prolonging the time required for dynamic adjustments to the microservice architecture, increasing system loss rates, and reducing system stability and performance. Based on the characteristics of this application scenario—complex topology, dynamically distributed data with easily changing metric correlations, diverse component types, dynamically changing business scenarios, and the need for timely and real-time root cause analysis—we have decided to adopt the following solution: Optionally, the above-mentioned root cause location processing of the pruned microservice call topology link set to obtain the microservice fault root cause node set may include the following steps: The first step is to determine the initial edge weight value set of the target topology link edge set in the pruned microservice call topology link set. The target topology link edge is a call edge present in both the pruned microservice call topology link set and the microservice call topology link set. The initial edge weight values ​​in the initial edge weight value set can be determined using the Pearson correlation coefficient to determine the correlation values ​​between two corresponding microservice nodes regarding latency, bandwidth, and storage metrics.

[0067] The second step is to add the initial set of weight values ​​to the pruned microservice call topology link set to obtain the microservice weighted call topology link set.

[0068] The third step is to generate a first-order abnormal walk probability matrix based on the aforementioned microservice weighted call topology link set. This first-order abnormal walk probability matrix represents the probability of an anomaly propagating from a microservice node in the aforementioned microservice weighted call topology link set to an adjacent microservice node.

[0069] As an example, the aforementioned execution entity can first determine the target topology link edge groups with in-degree values ​​associated with each microservice node in the aforementioned microservice weighted call topology link set, and use these as in-degree link edge groups to obtain an in-degree link edge group set. Then, it determines the mean of the initial edge weight values ​​corresponding to each in-degree link edge group in the in-degree link edge group set, and uses this as the mean edge weight, to obtain a set of mean edge weights. Finally, it determines the ratio of the initial edge weight value to the mean edge weight of the in-degree link edge group set, and uses this as the first-order abnormal walk probability value to obtain a first-order abnormal walk probability matrix.

[0070] Fourth, for each abnormal microservice node in the abnormal microservice node set, perform the following generation steps: Sub-step 1: Based on the first-order anomaly walk probability matrix, perform a single-step forward random walk on the anomaly microservice nodes to obtain a forward anomaly walk node set. The forward anomaly walk nodes in this set can be microservice nodes with an in-degree relationship to the anomaly microservice node. In practice, the executing entity can first determine the microservice nodes with an in-degree relationship to the anomaly microservice node as the target microservice node set. Then, according to the descending order of the first-order anomaly walk probability values ​​corresponding to the target microservice node set, select target microservice nodes within a predetermined number of nodes from the target microservice node set to obtain the forward anomaly walk node set. This predetermined number of nodes can be a pre-determined value, such as 10.

[0071] Sub-step 2: For each forward abnormal walk node in the forward abnormal walk node set, perform the following node walk determination steps: The first sub-step involves determining the second-order traversal probability value of the forward-going abnormal traversal node based on its first-order abnormal traversal probability value. This second-order traversal probability value can be the probability that the forward-going abnormal traversal node will continue traversing along microservice nodes with out-degree relationships. In practice, the executing entity can first determine the first-order abnormal traversal probability value group corresponding to the microservice node group with out-degree relationships to the aforementioned forward-going abnormal traversal node, as the target forward propagation probability value group. Then, the second-order traversal probability determination formula is used to determine the second-order traversal probability value of the forward-going abnormal traversal node. This second-order traversal probability determination formula can be expressed as: .

[0072] in, This represents the numerical value of the second-order forward walk probability determined by the formula for determining the second-order forward walk probability. This indicates the degree of influence of the traversal of abnormal microservice nodes on the forward abnormal traversal nodes. The value range is [0, 1]. When the value is 1, only the one-way transition probability of the forward abnormal traversal node to the next node is considered. When the value is 0, it depends on the transition probability from the abnormal microservice node to the forward abnormal traversal node. Indicates an abnormal microservice node Wander to the forward abnormal wander node The first-order abnormal walk probability value. Indicates a forward abnormal walk node Walk to the microservice node with an out-degree relationship The forward propagation probability value of the target.

[0073] The second sub-step, in response to determining that the second-order walk probability value satisfies the first preset walk condition, determines the second-order forward propagation probability value of the next walk node of the abnormal forward walk node. The first preset walk condition can be a condition where the second-order walk probability value is greater than or equal to a preset walk probability threshold. This preset walk probability threshold can be a pre-set probability threshold for determining whether to perform a reverse walk, a forward walk, or remain in place. For example, the preset walk probability threshold can be 0.6. The next walk node of the abnormal forward walk node can be a microservice node obtained by the abnormal forward walk node traversing according to its out-degree relationship, i.e., a forward walk node. The second-order forward propagation probability value can be the probability value of the abnormal forward walk node traversing according to its out-degree relationship. In practice, the executing entity can use the second-order forward walk probability determination formula to determine the second-order forward propagation probability value of the next walk node of the abnormal forward walk node. The formula for determining the second-order forward walk probability can be expressed as follows: .

[0074] in, This represents a group of microservice nodes that have an out-degree relationship. This represents the index, or traversal variable, used to identify microservice node groups with out-degree relationships. Since the second-order traversal probability values ​​satisfy the first preset traversal condition... Therefore Represented as a forward anomalous walk node The first-order abnormal walk probability value is the probability of walking to any microservice node in the group of microservice nodes with an out-degree relationship. The second-order forward walk probability is determined by the formula... The implementation principle can be: by weighted fusion of historical transfer path probabilities Direct transition probability with the current node This describes how anomalies occur in the centralized microservice call topology after pruning, "from historical nodes". Propagate to the current node Then it spreads to downstream nodes. The propagation pattern of "" avoids the shortcoming of traditional single-step random walk algorithms that ignore historical propagation paths. The formula for determining the probability of the second-order forward walk is based on... The normalization process ensures that the sum of the transition probabilities from the current node to all out-degree nodes is 1, which conforms to the basic properties of probability distribution. After normalization, it can be directly used for path selection in random walks. The higher the probability value of an out-degree node, the higher the probability that it will be selected as the next hop.

[0075] The third sub-step, in response to determining that the second-order walk probability value satisfies the second preset walk condition, determines the second-order backpropagation probability value of the next walk node of the forward abnormal walk node. The second preset walk condition can be a condition less than a preset walk probability threshold. The next walk node of the forward abnormal walk node can be a microservice node obtained by the forward abnormal walk node walking according to its in-degree relationship, i.e., the backwalk node. The second-order backpropagation probability value can be the probability value of the forward abnormal walk node walking according to its in-degree relationship. In practice, the executing entity can first determine the first-order abnormal walk probability value group corresponding to the microservice node group that has an in-degree relationship with the forward abnormal walk node, as the target backpropagation probability value group. Then, using the second-order contravariant walk formula, the second-order backpropagation probability value of the next walk node of the forward abnormal walk node is determined. The second-order contravariant walk formula can be expressed as: .

[0076] in, This represents the second-order backpropagation probability value determined by the second-order inverse walk formula. This represents the probability used to control the reverse walk, in order to avoid excessive backtracking of the random walk and resulting in decreased efficiency. The smaller the value, the lower the probability of reverse transition, which encourages the walk to move in the downstream direction. The larger the value, the more flexible the reverse walk. This represents a group of microservice nodes that have an in-degree relationship. Since the second-order walk probability value satisfies the second preset walk condition, i.e. Therefore Represented as a forward anomalous walk node The first-order anomaly walk probability value is the walk path to any microservice node in a group of microservice nodes with an in-degree relationship. The implementation principle of the second-order contravariant walk formula is as follows: when the transition probability from the current node to all out-degree nodes is low (i.e., the anomaly is difficult to propagate downstream), the walk is allowed to backtrack to an upstream in-degree node to avoid getting stuck in an infinite loop. Control the intensity of reverse transfer, balance the ratio of downstream propagation and upstream backtracking, and adapt to scenarios in abnormal propagation where "there may be errors in the propagation path, requiring backtracking and re-searching".

[0077] The fourth sub-step, in response to the determination that both the second-order forward propagation probability value and the second-order backward propagation probability value satisfy the third preset walking condition, determines the second-order dwell propagation probability value of the next walking node of the abnormal forward walking node. The third preset walking condition can be that both the second-order forward propagation probability value and the second-order backward propagation probability value are less than or equal to a preset walking probability threshold. The next walking node of the abnormal forward walking node can be a microservice node obtained by the abnormal forward walking node remaining in place. The second-order dwell propagation probability value can be the probability value of the abnormal forward walking node remaining in the original microservice node. In practice, the executing entity can use the second-order dwell formula to determine the second-order dwell propagation probability value of the next walking node of the abnormal forward walking node. The second-order dwell formula can be expressed as: .

[0078] in, This represents the second-order stationary propagation probability value determined by the second-order stationary propagation formula, and the value is a non-negative value. Indicates from abnormal microservice node Wander to the forward abnormal wander node Furthermore, the probability of stopping at a forward abnormal walk node is determined by the abnormality intensity of the forward abnormal walk node itself; for example, the higher the abnormality score of the forward abnormal walk node, the greater the value. Indicates from abnormal microservice node Wander to the forward abnormal wander node Then navigate to the microservice node The probability value of (i.e., the adjacent nodes that have a one-hop relationship with the forward abnormal walk node, including nodes with in-degree and out-degree relationships) is taken as the second-order forward propagation probability value or the second-order backward propagation probability value. This represents the maximum transition probability of a forward-going abnormal traversal node moving to any microservice node with a one-hop relationship. The principle behind the second-order in-place stay formula is that the transition probability of a forward-going abnormal traversal node to any microservice node with a one-hop relationship is low (i.e., the maximum transition probability is less than its own base stay probability). When the forward abnormal walk node is considered to be more likely to be the root cause of the abnormality, the walk is encouraged to stay at this node. If the maximum transition probability is greater than the basic stay probability, the basic stay probability is set to 0, and the walk is preferentially selected to transfer to the associated node.

[0079] As an example, the pruned microservice call topology can be: Microservice node 1 → Microservice node 2 → Microservice node 3, and The value is 0.3. The value is 0.2. The out-degree node set of microservice node 1 is microservice node 2, and the in-degree node set is empty. The out-degree node set of microservice node 2 is microservice node 3, and the in-degree node set is microservice node 1. The out-degree node set of microservice node 3 is empty, and the in-degree node set is microservice node 3. The first-order abnormal walk probability of microservice node 1 walking to microservice node 2 can be 0.8, and the base probability of reverse walk is 0.4 (reflecting that the reverse relationship is taken as half of the first-order abnormal walk probability of the forward relationship). The first-order abnormal walk probability of microservice node 2 walking to microservice node 3 can be 0.6, and the probability value of microservice node 2 staying at the origin, i.e., its own abnormality, can be 0.5. The forward abnormal walk node is now microservice node 2, and the abnormal microservice node is microservice node 1. Then the second-order forward propagation probability value of the next walk node can be: for , Then the second-order backpropagation probability value of the next walking node can be: In the second-order in-place propagation formula, the direct associated nodes of microservice node 2 are microservice node 1 and microservice node 3, with corresponding transition probabilities of 0.7*0.8+0.3*0.6=0.74 and 0.7*0.8+0.3*0.4=0.68 respectively. Therefore, the maximum transition probability is 0.74, and the second-order in-place propagation probability is: Since the maximum migration probability of microservice node 2 (0.74) is greater than its own basic dwell probability (0.5), the second-order dwell propagation probability is 0, and dwelling is discouraged.

[0080] The fifth sub-step, in response to the determination that the number of times the node traversal determination step has been executed is greater than or equal to a preset execution threshold, generates a microservice failure root cause node set based on the average set of node access counts of the abnormal microservice node set, and performs system adjustments on the aforementioned microservice structure system based on the microservice failure root cause node set. The preset execution number can be the maximum number of times the node traversal determination step can be executed, a pre-set value, such as 10. The node access counts in the node access count set can be the access count set of the node access path set formed by the abnormal microservice node and the next traversal node set corresponding to the preset execution threshold. The system adjustments can be adjustments to repair microservice node failures. In practice, the execution entity can sort the node access count sets in descending order of their average values, select the microservice node sets corresponding to the first few preset average values ​​as the microservice failure root cause node set, and perform system adjustments on the aforementioned microservice structure system based on the microservice failure root cause node set. The preset average value can be a pre-set value, such as 3.

[0081] Sub-step 4: In response to determining that the number of executions is greater than or equal to a preset execution threshold, the next set of traversing nodes is determined as a forward abnormal traversing node, and the sum of the number of executions and the preset value is determined as the number of executions, so as to execute the above node traversal determination step again.

[0082] The above-described technical solution and its related content, as an inventive point of this disclosure, solve the technical problem of "low accuracy in anomaly root cause localization, prolonged dynamic adjustment time for microservice architecture systems, increased system loss rate, and reduced system stability and performance." The factors leading to low accuracy in anomaly root cause localization, prolonged dynamic adjustment time for microservice architecture systems, increased system loss rate, and reduced system stability and performance are often as follows: When performing root cause localization on the pruned microservice call topology link set, only single-step dependencies are considered, ignoring the impact of historical traversal processes and upstream / downstream nodes on the anomaly propagation probability. Furthermore, the pruned microservice call topology link set contains a large number of microservice nodes, resulting in low accuracy in anomaly root cause localization, prolonged dynamic adjustment time for microservice architecture systems, increased system loss rate, and reduced system stability and performance. Solving these factors can improve the accuracy of anomaly root cause localization, shorten the dynamic adjustment time for microservice architecture systems, reduce system loss rate, and improve system stability and performance. To achieve this effect, this disclosure first determines an initial set of weight values ​​and, by combining the physical and regular topologies of the microservice architecture system, determines a first-order anomaly walk probability matrix. This improves the accuracy of the microservice weight call topology link set, reduces redundant conditional independence judgments, and provides transition probabilities for subsequent second-order walks. Secondly, for each anomaly microservice node, a forward anomaly walk node set is determined. This allows for preliminary exploration of the direct root cause nodes of anomaly propagation, reducing the search space, improving root cause efficiency, and avoiding unnecessary computation by focusing on high-probability nodes, thus providing a foundation for second-order walks. Then, for each forward anomaly walk node, second-order walks are performed, satisfying different preset walk conditions, including forward, reverse, and origin-based stops, to search for root causes. Considering the anomaly propagation probabilities of the previous, current, and next nodes, deeper root causes can be captured, avoiding the limitations of focusing only on direct dependencies. Reverse second-order walks expand the search direction, to some extent preventing forward walks from getting trapped in local optima, while origin-based stops avoid directional errors caused by forced forward walks, improving the stability and completeness of second-order walks. Subsequently, when the number of executions exceeds or equals a preset execution threshold, a set of microservice failure root cause nodes is generated. This improves the accuracy of root cause localization, shortens the time required for dynamic adjustments to the microservice architecture, reduces system loss rate, and enhances system stability and performance. Finally, when the number of executions exceeds or equals the preset execution threshold, the node traversal determination step is executed again. This fully explores possible paths, avoids premature termination of the traversal, and further improves the accuracy of root cause localization, system stability, and performance.

[0083] Step 107: Perform rule-based multidimensional analysis on the microservice failure root cause node set to obtain the target failure root cause information set.

[0084] In some embodiments, the aforementioned execution entity can perform rule-based multidimensional analysis on the aforementioned microservice failure root cause node set to obtain a target failure root cause information set. The target failure root cause information in the aforementioned target failure root cause information set can be the root cause information obtained by re-sorting the aforementioned microservice failure root cause node set after adding expert experience. The aforementioned expert experience may include, but is not limited to, at least one of the following: detecting anomalies in the query rate per second of the entry microservice node and each microservice node at the entry point; if the query rate per second of the entry microservice node increases, or if the query rate per second of a large number of nodes increases, then it is considered a root cause of increased traffic; detecting anomalies in network metrics; if network problems are identified, then there is a root cause of network anomalies; if there are anomalies in storage node calls, then it is considered a root cause of storage component anomalies; analyzing the data distribution of anomaly metrics; if the anomalies are concentrated on one or more machines or data centers, then there is a root cause of a single machine or data center; if a microservice node experiences an abnormal increase in call failures when calling multiple downstream microservice nodes, then that microservice node is considered the root cause.

[0085] In addressing the technical challenges mentioned above, the application scenario—a holiday e-commerce platform based on hybrid deployment and cloud-native environments—often presents the following issues: Root cause analysis using the RCSF (Random Itemset Mining) algorithm can only pinpoint faults caused by specific microservice nodes, neglecting faults caused by non-microservice nodes. This results in low accuracy of root cause analysis and low efficiency in fault location, leaving the microservice architecture system in a faulty state for extended periods, reducing system security and stability, and increasing the likelihood of damage to microservice components. Based on the characteristics of this application scenario—complex topology and long call chains, timely system response, diverse component types, dynamically changing business scenarios, and wide fault propagation—we have decided to adopt the following solution: In some optional implementations of certain embodiments, the above-mentioned rule-based multidimensional analysis of the microservice failure root cause node set to obtain the target failure root cause information set may include the following steps: The first step is to adaptively strengthen and adjust the fault root cause rule engine to obtain the adjusted fault root cause rule engine. This fault root cause rule engine can be a rule engine composed of expert experience related to root cause localization. It can be a rule engine composed of six types of expert rules, including traffic anomaly root cause analysis, network anomaly root cause analysis, storage component anomaly root cause analysis, anomaly propagation impact scope root cause analysis, and call relationship directionality fault attribution logic root cause analysis. For example, the call relationship directionality fault attribution logic root cause analysis could be that if multiple microservice nodes calling the same microservice node all experience an abnormal increase in failures, then that microservice node is the root cause. In practice, the executing entity can first determine the basic rule layer, dynamic rule layer, and self-learning rule layer of the fault root cause rule engine. The basic rule layer can be a hierarchy of the rule engine composed of the six types of expert rules. The dynamic rule layer can be a priority determination layer composed of the business priority weights corresponding to the microservice fault root cause node set and the historical frequency weights of related historical microservice fault root cause nodes being called. The aforementioned self-learning rule layer can be a hierarchy composed of adjustment thresholds for the root cause solutions corresponding to the root cause nodes of microservice failures determined by reinforcement learning algorithms.

[0086] The second step is to use the adjusted root cause rule engine to adaptively sort the above microservice fault root cause node set to obtain the sorted microservice fault root cause node set.

[0087] In practice, the aforementioned execution entity can first use a lightweight classification model to map the microservice failure root cause node set and the failure root cause analysis information set included in the adjusted failure root cause rule engine, obtaining a set of failure root cause analysis information groups and matching degrees that match the microservice failure root cause node set, which serves as the target failure root cause analysis information group set and matching degree group set. The lightweight classification model can be the MobileNetV1 model. Then, the product of the mean, business priority weight, and historical frequency weight of the matching degree group set is determined, serving as the root cause node ranking score set. Finally, the microservice failure root cause node set is self-ranked according to the root cause node ranking score set from largest to smallest, resulting in a ranked microservice failure root cause node set.

[0088] The third step involves performing network root cause analysis on the aforementioned sorted microservice root cause node set to obtain a root cause node network information set. This root cause node network information set can be used to characterize system failures caused by network problems within the sorted microservice root cause node set. In practice, the executing entity can perform the following first root cause analysis step for each sorted microservice root cause node in the sorted microservice root cause node set: First, determine at least one pruned microservice call topology link in the pruned microservice call topology link set containing the sorted microservice root cause node, as the target call link set. Then, input the network indicator information included in the sorted microservice root cause node set into the autoencoder for network anomaly detection to obtain a network anomaly information set. This network indicator information may include, but is not limited to, at least one of the following: network packet loss rate, network latency, and network jitter. Finally, using a Bayesian network model, determine the causal information of the network anomalies in the network anomaly information set and the target call link set, as the root cause node network information set.

[0089] The fourth step involves performing root cause analysis on the service interface traffic of the sorted microservice root cause node set to obtain a root cause node interface traffic information set. This root cause node interface traffic information set can be used to characterize system failures caused by interface traffic issues of microservice nodes within the sorted microservice root cause node set. In practice, the execution entity can first use a GRU (Gated Recurrent Unit) to predict the interface traffic information set included in the sorted microservice root cause node set, obtaining an interface traffic prediction information set. Secondly, it determines the abnormal traffic deviation rate set between the interface traffic prediction information set and the interface traffic information set. Next, it analyzes the sorted microservice root cause node set based on upstream and downstream traffic limiting strategies to obtain a traffic limiting analysis result information set. Finally, it performs interface traffic profiling analysis on the sorted microservice root cause node set to obtain a node interface traffic profiling information set. This node interface traffic profiling information may include, but is not limited to, at least one of the following: peak traffic time period information, user group distribution information, abnormal interface information, and interface change information. Finally, the abnormal traffic deviation rate set, the traffic limiting analysis result information set, and the node interface traffic profile information set are identified as the root cause node interface traffic information set.

[0090] The fifth step involves performing root cause propagation range analysis on the sorted microservice root cause node set to obtain a root cause node propagation range information set. This root cause node propagation range information set can be used to characterize the extent of the impact of abnormal propagation within the sorted microservice root cause node set. In practice, the executing entity can first use the Peter-Clark (PC) algorithm to determine the set of pruned microservice call topology links associated with the sorted microservice root cause node set, as the target propagation link group set. Then, from each target propagation link group in the target propagation link group set, the link length of the longest target propagation link is selected as the target propagation depth set. Next, from each target propagation link group in the target propagation link group set, the set of the number of components affected by the sorted microservice root cause node set is selected as the abnormal propagation breadth information set. Finally, the target propagation link group set, the target propagation depth set, and the abnormal propagation breadth information set are combined to determine the root cause node propagation range information set.

[0091] Step 6: Perform root cause resource analysis on the sorted microservice root cause node set to obtain a root cause node resource load information set. This root cause node resource load information set can characterize system failures caused by resource issues in microservice nodes within the sorted microservice root cause node set. In practice, the executing entity can first use the XGBoost model to perform node resource prediction processing on the sorted microservice root cause node set, obtaining a node resource prediction information set. This node resource prediction information set can characterize the range of normal node resource usage in the sorted microservice root cause node set. Secondly, using the node resource prediction information set, determine whether the sorted microservice root cause node set has resource overload issues, as node resource overload information. Next, using Kubernetes resource configuration policy information, determine whether the sorted microservice root cause node set has resource scheduling anomalies, as a node resource scheduling information set. Finally, using correlation analysis, determine the node resource anomaly information set for nodes with resource anomalies in the sorted microservice root cause node set. Finally, the node resource overload information, node resource scheduling information set, and node resource anomaly information set are identified as the root cause node resource load information set.

[0092] Step 7: Based on the aforementioned root cause node network information set, root cause node interface traffic information set, root cause node propagation range information set, and root cause node resource load information set, perform multi-dimensional analysis on the sorted microservice failure root cause node set to obtain the target failure root cause information set. Then, based on the target failure root cause information set, adjust the aforementioned microservice structure system. In practice, the executing entity can construct a root cause analysis heterogeneous graph centered on the sorted microservice root cause node set, using the aforementioned root cause node network information set, root cause node interface traffic information set, root cause node propagation range information set, and root cause node resource load information set as node attribute information. The nodes in the root cause analysis heterogeneous graph can be composed of microservice node sets and the sorted microservice root cause node set associated with the aforementioned root cause node network information set, root cause node interface traffic information set, root cause node propagation range information set, and root cause node resource load information set. Edges can be causal relationships and dependencies. Then, using the GraphSAGE (Graph Sample and Aggregate) model, anomaly analysis is performed on the aforementioned heterogeneous graph of root cause analysis to obtain a set of component anomaly confidence scores. Next, the microservice root cause node corresponding to the component with the highest anomaly confidence score is selected from this set and ranked as the target failure root cause information set. Finally, referring to the specific implementation of step 108, the microservice architecture system is adjusted based on the target failure root cause information set.

[0093] The above-described technical solution and its related content, as an inventive point of this disclosure, solve the technical problem of "reducing system security and stability, and increasing the damage to microservice components." Factors leading to reduced system security and stability, and increased damage to microservice components often include: root cause analysis using the RCSF (Random Itemset Mining) algorithm can only pinpoint faults caused by specific microservice nodes, thus ignoring faults caused by non-microservice nodes. This results in low accuracy of root cause analysis and low efficiency in fault location, causing the microservice architecture system to remain in a faulty state for extended periods, reducing system security and stability, and increasing the damage to microservice components. Solving these factors can improve system security and stability and reduce the damage to microservice components. To achieve this effect, this disclosure first configures the static fault root cause rule engine to be dynamically adjustable, better suited to different business scenarios of the microservice architecture system, and improving sorting accuracy. Secondly, analyzing the network, service interface traffic, root cause propagation range, and root cause resources of the sorted microservice root cause node set can compensate for the inability to identify non-component call sequence-related faults in root cause analysis, improve the comprehensiveness of root cause analysis, and avoid subjective judgments due to expert experience, thereby improving the accuracy of root cause analysis. Specifically, network root cause analysis can improve the accuracy of network location and avoid misjudgments; service interface traffic root cause analysis can avoid one-sided traffic analysis and prevent secondary faults caused by subsequent traffic; root cause propagation range analysis can accurately determine the scope of anomaly propagation, further narrowing down the scope of the root cause; and root cause resource analysis can improve the accuracy of resource analysis. Finally, multi-dimensional analysis of the sorted microservice fault root cause node set can resolve cross-dimensional conflicts, improve the accuracy of fault location, enable timely dynamic adjustments to system faults, improve the security and stability of the microservice architecture system, and reduce the degree of damage to microservice components.

[0094] Step 108: Generate and store microservice fault response information and system fault report information based on the target fault root cause information set, and make system adjustments to the microservice architecture system based on the microservice fault response information.

[0095] In some embodiments, the aforementioned execution entity can generate and store microservice fault response information and system fault report information based on the aforementioned target fault root cause information set, and perform system adjustments on the aforementioned microservice architecture system based on the aforementioned microservice fault response information. The aforementioned microservice fault response information can be information on solutions to the fault provided by the aforementioned target fault root cause information set. The aforementioned system fault report information can be fault report information obtained by inputting the aforementioned target fault root cause information set, the aforementioned microservice application deployment scenario information, the multi-source microservice operation and maintenance information set, and the pruned microservice call topology link set into a fault template. Figure 2 As shown, Figure 2 This diagram illustrates the process of root cause analysis for the entire microservice architecture system, from determining microservice application deployment scenario information, acquiring multi-source microservice operation and maintenance information sets, generating dynamic topology links, detecting adjacency dependency anomalies, handling link pruning, locating root causes of faults, and performing multi-dimensional rule analysis. The system adjustments described above can include emergency fault repair and long-term system optimization adjustments to technically prevent the recurrence of the same faults. For example, emergency fault repair adjustments may include, but are not limited to, at least one of the following: temporary gateway switching routing policy information, push information based on Apache Dubbo temporary rate limiting rules, and dependency adjustment information for master-slave switching. Long-term system optimization adjustments may include, but are not limited to, at least one of the following: contingency plan rollback adjustments, and resource adjustment information based on K8s (Kubernetes) scaling. The microservice fault response information described above can be generated through a combination of large language models and expert experience.

[0096] Further reference Figure 3 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a fault root cause localization and adjustment device based on a microservice architecture system. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, this fault root cause localization and adjustment device based on microservice architecture systems can be specifically applied to various electronic devices.

[0097] like Figure 3As shown, a fault root cause localization and adjustment device 300 based on a microservice architecture system includes: a determination unit 301, an acquisition unit 302, a topology link generation unit 303, an adjacency dependency anomaly detection unit 304, a link pruning unit 305, a fault root cause localization unit 306, a rule multidimensional analysis unit 307, and a generation unit 308. The determination unit 301 is configured to: in response to detecting fault alarm information of the microservice architecture system, determine the microservice application deployment scenario information associated with the aforementioned fault alarm information. The acquisition unit 302 is configured to: acquire a multi-source microservice operation and maintenance information set of the aforementioned microservice application deployment scenario information. The topology link generation unit 303 is configured to: dynamically generate topology links from the aforementioned multi-source microservice operation and maintenance information set to obtain a microservice call topology link set. The adjacency dependency anomaly detection unit 304 is configured to: perform adjacency dependency anomaly detection on the aforementioned microservice call topology link set based on the aforementioned multi-source microservice operation and maintenance information set to obtain an abnormal microservice node set. Link pruning unit 305 is configured to: perform link pruning on the microservice call topology link set based on the aforementioned abnormal microservice node set, to obtain a pruned microservice call topology link set. Fault root cause localization unit 306 is configured to: perform fault root cause localization on the pruned microservice call topology link set, to obtain a microservice fault root cause node set. Rule multidimensional analysis unit 307 is configured to: perform rule multidimensional analysis on the aforementioned microservice fault root cause node set, to obtain a target fault root cause information set. Generation unit 308 is configured to: generate and store microservice fault response information and system fault report information based on the aforementioned target fault root cause information set, and perform system adjustments on the aforementioned microservice structure system based on the aforementioned microservice fault response information.

[0098] It is understandable that the units and references described in the fault root cause localization and adjustment device 300 based on the microservice architecture system are... Figure 1 The steps in the described method correspond accordingly. Therefore, the operations, features, and beneficial effects described above for the method are also applicable to the fault root cause localization and adjustment device 300 and its constituent units in a microservice architecture system, and will not be repeated here.

[0099] The following is for reference. Figure 4 It shows a schematic diagram of the structure of an electronic device (e.g., an electronic device) 400 suitable for implementing some embodiments of the present disclosure. Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0100] like Figure 4As shown, electronic device 400 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from storage device 408 into random access memory (RAM) 403. RAM 403 also stores various programs and data required for the operation of electronic device 400. Processing device 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0101] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic device 400 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 An electronic device 400 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 4 Each box shown can represent a device or multiple devices as needed.

[0102] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 409, or installed from storage device 408, or installed from ROM 402. When the computer program is executed by processing device 401, it performs the functions defined above in the methods of some embodiments of this disclosure.

[0103] It should be noted that, in some embodiments of this disclosure, the computer-readable medium described above may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0104] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0105] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: in response to detecting fault alarm information of the microservice architecture system, determine the microservice application deployment scenario information associated with the fault alarm information; acquire a multi-source microservice operation and maintenance information set of the aforementioned microservice application deployment scenario information; perform dynamic topology link generation on the aforementioned multi-source microservice operation and maintenance information set to obtain a microservice call topology link set; and perform adjacency dependency anomaly detection on the aforementioned microservice call topology link set based on the aforementioned multi-source microservice operation and maintenance information set to obtain anomaly detection results. A set of microservice nodes is generated; based on the abnormal microservice node set, link pruning is performed on the microservice call topology link set to obtain a pruned microservice call topology link set; root cause location processing is performed on the pruned microservice call topology link set to obtain a microservice fault root cause node set; rule-based multidimensional analysis is performed on the microservice fault root cause node set to obtain a target fault root cause information set; based on the target fault root cause information set, microservice fault response information and system fault report information are generated and stored; and based on the microservice fault response information, system adjustments are made to the microservice architecture system.

[0106] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0108] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a determining unit, an acquiring unit, a topology link generation unit, an adjacency dependency anomaly detection unit, a link pruning unit, a fault root cause localization unit, a rule multidimensional analysis unit, and a generation unit. The names of these units do not necessarily limit the unit itself; for example, the determining unit may also be described as "a unit that, in response to detecting a fault alarm message in a microservice architecture system, determines microservice application deployment scenario information associated with the aforementioned fault alarm message."

[0109] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0110] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for troubleshooting and adjusting fault root causes in a microservice architecture system, comprising: In response to the detection of fault alarm information in the microservice architecture system, the microservice application deployment scenario information associated with the fault alarm information is determined; A multi-source microservice operation and maintenance information set for obtaining the microservice application deployment scenario information; Dynamic topology link generation is performed on the multi-source microservice operation and maintenance information set to obtain a microservice call topology link set; Based on the multi-source microservice operation and maintenance information set, adjacency dependency anomaly detection is performed on the microservice call topology link set to obtain the abnormal microservice node set. Based on the abnormal microservice node set, the microservice call topology link set is pruned to obtain the pruned microservice call topology link set. The pruned microservice call topology link set is subjected to fault root cause localization processing to obtain the microservice fault root cause node set; Perform rule-based multidimensional analysis on the microservice failure root cause node set to obtain the target failure root cause information set; Based on the target fault root cause information set, generate and store microservice fault response information and system fault report information, and adjust the microservice structure system based on the microservice fault response information.

2. The method according to claim 1, wherein, In response to detecting a fault alarm in the microservice architecture system, the process of determining the microservice application deployment scenario information associated with the fault alarm information includes: The fault alarm information is parsed to obtain fault parsing alarm information; The microservice application deployment canvas information associated with the fault analysis alarm information in the microservice application deployment canvas information set is identified as the target microservice application deployment canvas information; Resource scenario mapping and association are performed on the set of microservice components included in the target microservice application deployment canvas information to obtain microservice application deployment scenario information.

3. The method according to claim 1, wherein, The multi-source microservice operation and maintenance information set includes: a microservice access log information set, a microservice performance information set, and a microservice call information set; and The step of dynamically generating a microservice call topology link set from the multi-source microservice operation and maintenance information set includes: The microservice access log information set, the microservice performance information set, and the microservice call information set are subjected to verification preprocessing to obtain the target microservice access log information set, the target microservice performance information set, and the target microservice call information set. The target microservice call information set is recursively parsed to obtain a set of microservice call triples; The microservice call triple set and the target microservice performance information set are double-matched to obtain the microservice matching call triple set. The microservice call triplet set is deduplicated using a window to obtain the deduplicated microservice call triplet set. Based on the target microservice access log information set, determine the call edge indicator information set of the deduplicated microservice call triple set; A topology graph is constructed from the set of call edge indicator information and the set of deduplicated microservice call triples to obtain an initial call topology link set; The initial call topology link set is incrementally updated to obtain the microservice call topology link set.

4. The method according to claim 1, wherein, The step of performing adjacency dependency anomaly detection on the microservice call topology link set based on the multi-source microservice operation and maintenance information set to obtain an abnormal microservice node set includes: Based on the multi-source microservice operation and maintenance information set, time-series performance features are extracted from each microservice node included in the microservice call topology link set to obtain a microservice node feature vector set. The adjacency topology features of each microservice node are aggregated to obtain a set of node adjacency topology aggregated feature vectors. The node adjacency topology aggregation feature vector set and the microservice node feature vector set are subjected to feature filtering and concatenation to obtain the node concatenated feature vector set; The node concatenation feature vector set is input into the node structured anomaly detection model to obtain the initial set of abnormal microservice nodes; Based on the microservice call topology link set, perform exception propagation reasoning processing on the initial abnormal microservice node set to obtain the abnormal microservice node set.

5. The method according to claim 1, wherein, The step of performing link pruning on the microservice call topology link set based on the abnormal microservice node set to obtain the pruned microservice call topology link set includes: The node status of each microservice node in the microservice call topology link set is identified to obtain a set of microservice node status information. The abnormal microservice node set is subjected to abnormal clustering processing to obtain an abnormal microservice node cluster set; The central microservice node set and the target cluster microservice node set of the abnormal microservice node cluster set are determined as the abnormal cluster microservice node set; The abnormal cluster microservice node set and the microservice leaf node set are traversed in parallel by multiple threads to obtain the abnormal cluster node sequence set and the leaf node sequence, wherein the microservice leaf node set is the microservice node set of leaf nodes. Based on the abnormal cluster node sequence set, the leaf node sequence, and the microservice node status information set, the microservice call topology link set is subjected to parallel link pruning to obtain the pruned microservice call topology link set.

6. The method according to claim 1, wherein, The step of performing root cause analysis on the pruned microservice call topology link set to obtain a microservice fault root cause node set includes: The pruned microservice call topology link set is used to extract business components to obtain an abnormal business component information set; Based on the abnormal business component information set, the call graph model is used to identify the pruned microservice call topology link set to obtain the abnormal functional component information set. The component business weight value set, component anomaly timing information set, and propagation path feature information set of the abnormal functional component information set are determined as the multi-source information set of the functional component; Based on the multi-source information set of the functional components, the abnormal functional component information set is filtered to obtain a candidate abnormal functional component information set; The candidate abnormal functional component information set is processed by transaction vector encoding to obtain the component alarm transaction vector set; Based on the component alarm transaction vector set, a frequent transaction support mining function is generated; Based on the frequent transaction support mining function, heuristic frequent mining is performed on the component alarm transaction vector set to obtain the component frequent alarm transaction set. Based on the set of frequent alarm transactions of the components, the root cause of the fault is located in the set of pruned microservice call topology links to obtain the set of microservice fault root cause nodes.

7. A fault root cause localization and adjustment device for a microservice architecture system, comprising: The determining unit is configured to determine the microservice application deployment scenario information associated with the fault alarm information in response to the detection of fault alarm information in the microservice architecture system. The acquisition unit is configured to acquire a multi-source microservice operation and maintenance information set of the microservice application deployment scenario information; The topology link generation unit is configured to dynamically generate topology links from the multi-source microservice operation and maintenance information set to obtain a microservice call topology link set. The adjacency dependency anomaly detection unit is configured to perform adjacency dependency anomaly detection on the microservice call topology link set based on the multi-source microservice operation and maintenance information set, and obtain an abnormal microservice node set. The link pruning unit is configured to perform link pruning on the microservice call topology link set based on the abnormal microservice node set, to obtain the pruned microservice call topology link set. The root cause localization unit is configured to perform root cause localization processing on the pruned microservice call topology link set to obtain a microservice root cause node set. The rule-based multidimensional analysis unit is configured to perform rule-based multidimensional analysis on the microservice failure root cause node set to obtain the target failure root cause information set. The generation unit is configured to generate and store microservice fault response information and system fault report information based on the target fault root cause information set, and to perform system adjustments on the microservice architecture system based on the microservice fault response information.

8. An electronic device, comprising: One or more processors; Storage device, on which one or more programs are stored, When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-6.

9. A computer-readable medium having a computer program stored thereon, wherein, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-6.

Images