Microservice root cause positioning method and system fusing abnormal evidence and heterogeneous topology graph

Abstract

The application belongs to the technical field of cloud computing, micro-service system and intelligent operation and maintenance, and discloses a micro-service root cause positioning method and system fusing abnormal evidence and heterogeneous topological graphs. A multi-layer heterogeneous topological graph containing micro-service system running entities and dependency relationships is constructed. Multi-modal data in a fault time window is collected and aligned. Index abnormalities are mapped to node-level evidence, call chain abnormalities are mapped to edge-level propagation evidence, and log abnormalities are mapped to node or edge-level evidence. Edge weights are enhanced based on edge types and abnormal evidence. Graph propagation is performed with node-level evidence as an initial distribution to obtain candidate root cause ranking. Candidate root causes, multi-modal abnormal summaries and local topological subgraphs are organized into structured prompt information, which is input into a large language model to output the final root cause. The application improves the accuracy of micro-service fault root cause positioning, reduces abnormal noise interference, and reduces Token consumption and large language model reasoning cost.

Description

Technical Field

[0001] This invention belongs to the fields of cloud computing, microservice systems and intelligent operation and maintenance (AIOps) technology, and particularly relates to a microservice root cause localization method and system that integrates anomaly evidence and heterogeneous topology graphs. Background Technology

[0002] With the development of cloud-native technologies, microservice systems have been widely applied in enterprise applications, internet service platforms, and open-source experimental environments. Microservice systems typically consist of numerous service components, running instances, and underlying computing resources, with complex dependencies formed between different components through remote calls, message passing, and shared resource access. In cloud-native platforms such as Kubernetes, a business service is usually hosted by multiple Pod instances, which are deployed on different Node nodes. Therefore, failures can propagate across layers, including the business call layer, the instance runtime layer, and the underlying resource layer.

[0003] In complex microservice systems, a single failure often triggers a variety of phenomena, including abnormal metrics, log anomalies, call chain latency anomalies, and error code anomalies, which can then propagate along the service call path, generating numerous related alerts. Root Cause Analysis (RCA) is a key technology in AIOps, aiming to accurately pinpoint the root component or cause of a failure among a large number of anomalies. This helps operations personnel shorten the Mean Time To Repair (MTTR), reduce alert storms, and prevent recurrence of failures.

[0004] Currently, root cause analysis in microservices typically requires the comprehensive utilization of various observable data, including monitoring metrics, logs, call chains, and system topology. Metrics reflect the resource and business status of services, instances, or nodes; logs provide semantic information such as program exceptions, timeouts, module loading failures, and runtime errors; call chains reflect request paths, call durations, call statuses, and exception propagation directions between services; and the topology characterizes the dependencies between microservice components. How to integrate this multimodal data within a unified framework and combine it with system topology for accurate and efficient root cause analysis is a significant technical challenge in current cloud-native operations and maintenance scenarios.

[0005] (i) Single-modal RCA method; Single-modal RCA methods typically use only one data source, namely metrics, logs, or call chains, for root cause analysis. For example, metric-based methods usually collect time series of KPIs such as CPU utilization, memory utilization, request latency, error rate, and throughput, and calculate the degree of anomaly through threshold detection, statistical detection, time series prediction residuals, machine learning anomaly detection, etc., and then rank services, instances, or nodes according to the anomaly intensity; log-based methods usually perform template parsing, keyword matching, anomaly log frequency statistics, or log sequence anomaly detection on logs to identify suspected faulty components from log text and error semantics; call chain-based methods analyze the propagation of abnormal requests between services based on call time, status code, failure rate, number of timeouts, or changes in call path.

[0006] The drawback of this type of approach is that a single modality can only reflect one aspect of system anomalies, making it difficult to fully characterize the failure process of complex microservice systems. Metrics can reflect resource and performance status, but lack error semantics and call path information; logs can provide error semantics and contextual information, but cannot directly express the path of anomaly propagation along service dependencies; call chains can reflect the request propagation process, but usually cannot cover the underlying runtime environment, resource bottlenecks, or instance-level state changes. Therefore, when a failure involves multiple services, running instances, underlying resources, or external dependencies, the single-modality approach is prone to problems such as incomplete information, limited judgment scope, and insufficient stability in fault localization.

[0007] (II) Multimodal Fusion RCA Approach; The multimodal fusion RCA approach attempts to jointly utilize multi-source observable data such as metrics, logs, and traces for root cause localization. For example, methods such as Eadro have attempted to jointly model multi-source data such as traces, logs, and KPIs for microservice troubleshooting; methods such as MicroRCA-Agent also utilize metrics, logs, and traces for multimodal root cause analysis. Compared with single-modal methods, this type of approach can provide a more comprehensive system observation perspective. In publicly available information, Eadro is described as an end-to-end troubleshooting framework for multi-source data in microservices, aiming to jointly perform anomaly detection and root cause localization based on multi-source data such as traces, logs, and KPIs; MicroRCA-Agent is described as a microservice root cause analysis method based on a large language model agent, utilizing multimodal data fusion to generate structured root cause analysis results.

[0008] The drawback of this type of method is that, although it introduces multi-source data, the semantic and topological roles of different modalities are not sufficiently distinguished. Metric data typically reflects the entity's own operational status and is suitable for forming node-level anomaly evidence; call chain data typically reflects anomalies in interactions between services and is suitable for forming edge-level propagation evidence; log data may reflect internal entity errors, call anomalies, or external dependency anomalies, requiring mapping to node-level or edge-level evidence based on log source and semantics. Simply concatenating or uniformly inputting multimodal data into the model easily mixes "node-level anomalies" and "edge-propagation anomalies," leading to semantic confusion in the anomaly evidence.

[0009] (III) Graph Model-Based RCA Methods; Graph model-based RCA methods are an important technical approach in current microservice root cause localization. These methods typically abstract the system as a service call graph, dependency graph, or influence graph, and map anomaly information to graph nodes or edges. Candidate root cause scores are calculated through mechanisms such as random walks, PageRank, graph search, anomaly propagation, or graph ranking. Representative methods include MonitorRank, CloudRanger, MicroRCA, and AutoMAP. In publicly available information, MicroRCA is described as a root cause localization system for microservice performance problems, which infers root causes in real time by correlating application performance symptoms with system resource utilization.

[0010] The drawback of this approach is that existing graph models typically focus on Service-level call relationships, resulting in a relatively simple structural hierarchy. Many methods simplify microservice systems to a "Service-Service" call graph, failing to adequately represent the multi-layered dependencies between Services and running instances, running instances and their runtime environments, and services and external resources. In Kubernetes or containerized microservice systems, a business service is usually hosted by multiple Pods, Containers, processes, or running instances, which are deployed on Nodes, Hosts, virtual machines, physical machines, or other runtime environments. Anomalies in the underlying runtime environment may first affect the running instances, then the services they provide; anomalies in external databases, middleware, caches, registry centers, or external interfaces may also affect upper-layer services through dependencies. Schemes relying solely on Service call graphs struggle to depict this cross-layer propagation process.

[0011] (iv) RCA methods based on large language models; In recent years, large language models have been introduced into AIOps and microservice RCA scenarios. These methods typically organize metric summaries, log summaries, call chain summaries, alarm information, or candidate service information into prompt words, input them into the large language model for semantic reasoning, and then output the suspected root cause and explanation. These methods have strong capabilities in log semantic understanding, anomaly description and summarization, and cross-modal information integration. While large language models have advantages in semantic understanding and reasoning explanation, they may provide inference conclusions that do not conform to the actual dependencies if explicit system topology constraints are lacking, and the reasoning cost is high.

[0012] The drawback of this type of method is that directly inputting a large amount of raw metrics, logs, and call chain information into a large language model can lead to problems such as long prompt words, high token consumption, high response costs, and strong noise interference. Furthermore, if the large language model lacks a candidate root cause set, local topology subgraph, and propagation path constraints, it is easily affected by downstream symptom nodes, occasional logs, or irrelevant anomalies, resulting in root cause explanations that are inconsistent with the actual call relationships, deployment relationships, or dependency relationships.

[0013] In summary, while current microservice RCA methods have evolved from single-modal analysis to multimodal fusion, graph model, and large language model-assisted analysis, they still have the following key shortcomings: First, the system architecture modeling is too simplistic. Existing methods mostly construct service call graphs at the Service level, which makes it difficult to express the multi-layered relationships between running instances, the runtime environment, and external dependent resources. They also fail to accurately depict the cross-layer propagation process of faults between the business service layer, the running instance layer, the underlying runtime environment layer, and external resource dependencies.

[0014] Second, the fusion method of multimodal anomaly evidence is crude. Indicators, logs, and call chains have different data formats, sampling methods, and semantic positions. Existing methods often simply splice multimodal data or input them into the model in a unified manner, lacking a mechanism to map different modal anomaly evidence into node-level anomaly evidence and edge-level propagation evidence respectively, which can easily lead to semantic confusion between node state anomalies and edge propagation anomalies.

[0015] Third, anomaly detection for metrics lacks a type-aware mechanism. Existing methods typically assume that different KPIs can be detected using a uniform anomaly detection strategy. However, metrics in real-world microservice systems exhibit significant heterogeneity. For example, metrics such as CPU, memory, and latency usually show continuous and smooth changes, while metrics like error and timeout often exhibit sparse and bursty characteristics. Total and count metrics may have cumulative growth and reset characteristics, and capacity or status metrics may remain approximately constant over a long period. A uniform modeling approach is prone to false positives or false negatives, affecting the quality of subsequent node-level anomaly evidence.

[0016] Fourth, graph propagation edge weights lack real-time anomaly evidence enhancement. Some graph propagation methods rely mainly on static topology or fixed edge weights for propagation, and cannot dynamically adjust the importance of propagation paths based on call chain anomalies, log anomalies, or other edge-level propagation evidence within the fault window. This makes it difficult to distinguish high-risk propagation paths from ordinary dependency paths, and easily leads to misjudging symptom nodes with obvious anomalies as root cause nodes.

[0017] Fifth, large language models suffer from a lack of topological constraints and high costs in inference. Directly inputting large amounts of raw multimodal data into large language models for root cause analysis can easily introduce noise, increase token consumption, and reduce response efficiency. Furthermore, without the constraints of graph propagation candidate sets and local topological subgraphs, large language models may output interpretations that are inconsistent with the actual call relationships, deployment relationships, or dependency relationships of the system.

[0018] In summary, existing technologies have at least the following shortcomings: First, the system structure modeling is too simplistic, making it difficult to depict the cross-layer propagation relationships between the service layer, runtime instance layer, and runtime environment layer. Second, the multimodal anomaly evidence fusion method is relatively crude, lacking a mechanism to map indicators, logs, and call chains into node-level evidence or edge-level propagation evidence based on their semantic position. Third, the types of microservice monitoring indicators vary significantly, and existing unified anomaly detection methods are ill-suited to different statistical forms such as smooth, sparse, constant, and counter. Fourth, some graph propagation methods rely primarily on static topology or fixed edge weights, lacking real-time anomaly evidence within the fault window to enhance propagation edge weights. Fifth, large language model inference lacks topological constraints and has a large input context, easily leading to high costs, strong noise interference, and inconsistent interpretation structures. Summary of the Invention

[0019] To overcome the problems of complex entity hierarchy, heterogeneous multimodal observation data, difficulty in characterizing anomaly propagation paths, and high inference costs of large language models in existing microservice systems, especially cloud-native microservice systems such as Kubernetes, this invention discloses a method and system for root cause localization of microservice systems that integrates multimodal anomaly evidence and heterogeneous topology graphs. The technical solution is as follows: This invention is implemented as follows: a microservice root cause localization method that integrates anomaly evidence and heterogeneous topology graphs, the method comprising the following steps: S1. Obtain the system entities, service call relationships, service provision relationships, and runtime deployment relationships in the microservice system, and construct a multi-layer heterogeneous topology graph. The multi-layer heterogeneous topology graph includes at least service nodes, runtime instance nodes, and runtime environment nodes; as well as CALLS edges representing the call relationships between services, PROVIDES edges representing the capabilities of runtime instances to provide services, and DEPLOYED_IN edges representing the deployment of runtime instances in the runtime environment. S2. For the fault time window to be analyzed, collect the indicator data, log data, call chain data and system metadata of the microservice system, and perform segmentation, aggregation and time alignment according to the fault time window to obtain multimodal observation data under the same time window; S3. Extract abnormal evidence from the multimodal observation data and map the abnormal evidence to the multi-layer heterogeneous topology graph according to the semantic position of different modal data; wherein, the abnormal indicators reflecting the entity's own operating status are mapped to node-level abnormal evidence of service nodes, running instance nodes or running environment nodes, the abnormal call chain reflecting the abnormal interaction between services is mapped to edge-level propagation evidence on the CALLS edge, and the log abnormalities are mapped to node-level abnormal evidence or edge-level propagation evidence according to the log source, log template semantics and associated entities; S4. Set the structural prior weights according to the edge type in the multi-layer heterogeneous topology graph, and combine the log anomaly evidence, call chain anomaly evidence or edge-level propagation evidence mapped to the edge to enhance the propagation weights of the corresponding edges to obtain the evidence-enhanced propagation matrix. S5. Using the node-level anomaly evidence as the initial root cause distribution, perform graph propagation on the evidence-enhanced multi-layer heterogeneous topology graph to obtain the root cause score of each candidate node and generate a candidate root cause ranking. S6. Select Top-K candidate root causes from the candidate root cause ranking, organize the Top-K candidate root causes, corresponding indicator anomaly summaries, log anomaly summaries, call chain anomaly summaries, and local topology subgraphs into structured prompt information, input it into a large language model for topology-constrained auxiliary reasoning, and output the final root cause localization result; In the Kubernetes microservice system, the running instance node includes Pod, the running environment node includes Node, the PROVIDES edge includes the service provision relationship between Pod and Service, and the DEPLOYED_IN edge includes the deployment relationship between Pod and Node.

[0020] In step S1, the service node is used to represent a business service or service entry point in the microservice system, the running instance node is used to represent a running copy that carries service capabilities, and the running environment node is used to represent the host machine, virtual machine, physical machine, cluster node, or basic running environment that carries the running instance. The multi-layer heterogeneous topology graph also includes external resource nodes and DEPENDS_ON edges representing service dependencies on external resources. The external resource nodes are used to represent databases, middleware, caches, registry centers, message queues, or external interfaces. The multi-layer heterogeneous topology graph is dynamically updated according to the fault time window: for events such as restarting, scaling up or down, migration, rescheduling, or service instance change that occur within the fault time window, a topology snapshot of the corresponding time slice is generated according to the event occurrence time, or valid time attributes are attached to nodes and edges; during graph propagation, the topology snapshots before, during, or after the fault are selected for analysis, or propagation is performed on multiple time slice topology sequences.

[0021] In step S2, the metric data includes CPU, memory, disk, network, request latency, error rate, and throughput at the service level, runtime instance level, or runtime environment level. The log data includes runtime logs, exception logs, log templates, log levels, and log occurrence counts output by each service or Pod. The call chain data includes the caller, callee, call duration, call status code, call error information, and number of abnormal calls. The system metadata includes service name, runtime instance name, runtime environment name, deployment relationship, tag information, and service selector. The segmentation, aggregation, and time alignment according to the fault time window include: Define the fault analysis window and perform windowing processing on the records whose timestamps fall within the fault analysis window from the indicator data, log data, and call chain data. Window-level aggregation is performed on each modality of data: indicator data is aggregated into KPI time series by entity type, entity identifier, and KPI name; log data is aggregated into log anomaly summary by log source entity, log template, and anomaly keywords; and call chain data is aggregated into call chain anomaly summary by caller and callee. The aggregated index anomaly intensity, log anomaly summary, and call chain anomaly summary are uniformly mapped to nodes or edges in a multi-layered heterogeneous topology graph according to entity identifiers and topological relationships, forming node-level anomaly evidence and edge-level propagation evidence under the same fault analysis window.

[0022] In step S3, anomaly evidence extraction is performed on the multimodal observation data, and the anomaly evidence is mapped to the multi-layer heterogeneous topology graph according to the semantic position of different modal data, including: For the indicator data, anomaly detection methods are used to calculate the intensity of indicator anomalies for each entity node. Indicator anomalies are obtained through statistical thresholds, sliding windows, MAD, Isolation Forest, time series prediction residuals, deep learning anomaly detection models, or anomaly detection methods. For each entity node, the anomaly intensity of associated indicators is aggregated into node-level anomaly evidence to represent the initial degree of suspicion of the node as a root cause. For log data, abnormal log templates, error keywords, abnormal log frequency, or log semantic features are extracted to obtain log anomaly evidence; the log anomaly evidence is mapped to the service or running instance to which the log belongs, and is used to enhance the propagation edge weights related to that service or running instance; For call chain data, call chain anomalies are identified based on call time anomalies, call failure status, anomaly status codes, number of abnormal calls, or changes in call paths; the call chain anomaly evidence is mapped to service call edge CALLS to indicate the degree of risk of anomalies propagating along the call edge; Role-based modeling is performed based on the semantic position of different modal data; anomalies in metrics are prioritized as node-level anomaly evidence; anomalies in call chains are prioritized as edge-level propagation evidence; log anomalies are mapped to node-level or edge-level propagation evidence based on log source, log template semantics, and associated entities; in specific scenarios, some network-related metrics, connection-related metrics, or request-related metrics are used as edge-level propagation evidence, and some resource-related logs, crash logs, or OOM logs are used as node-level root cause evidence.

[0023] Furthermore, the following indicators are prioritized as evidence of node-level anomalies: Collect raw point-level metric data, aggregate it according to entity type, entity identifier and KPI name to obtain multiple KPI time series; For each KPI time series, a pre-trained indicator type recognizer is used to perform indicator type recognition, and the output type is smooth, sparse, constant or counter. The indicator type recognizer includes a machine learning classifier based on table features or a deep learning classifier based on raw time series data. The input of the indicator type recognizer includes at least one of KPI name semantics, entity type, keyword features, statistical features, raw time series or missing mask. Based on the identified indicator type, the corresponding branch is selected from multiple differential anomaly detection branches for anomaly detection, and an anomaly score is output. Specifically, when the indicator type is smooth, the continuous smooth indicator detection branch is entered, and prediction residual detection, moving statistical deviation detection, or historical baseline deviation detection is used; when the indicator type is sparse, the sparse burst indicator detection branch is entered, and moving median, MAD, or robust statistical detection is used; when the indicator type is constant, the near constant or horizontal offset detection branch is entered, and horizontal offset detection or state change detection is used; when the indicator type is counter, the counter detection branch is entered, and burst detection or rate anomaly detection is performed after resetting the perceptual differential transformation. The abnormal scores output by different detection branches are standardized to obtain the index abnormality intensity. Aggregate the intensity of abnormal indicators associated with the same service node, running instance node, or running environment node into node-level abnormal evidence.

[0024] In step S4, the propagation weights of the corresponding edges are enhanced to obtain the evidence-enhanced propagation matrix, where for any edge... The edge weights are expressed as: ； In the formula, For the edge The propagation weights are used to characterize the outlier scores along the edge. The intensity or probability of propagation; For the edge type To map to edges The edge-level anomaly evidence strength is used to characterize the impact of log anomaly evidence, call chain anomaly evidence, or edge-level propagation evidence on the edge. The degree of support for abnormal propagation; For the edge Starting node Point to target node , For the edge The starting node, For the edge The target node; Let be any heterogeneous relation edge in a multi-layered heterogeneous topology graph. For edge type The determined structural prior weights are used to characterize the fundamental influence of different types of topological relationships in anomaly propagation; Strength of evidence for boundary-level anomalies A defined enhancement factor is used to dynamically adjust the edges based on the strength of anomalous evidence. The propagation weights; the enhancement factor adopts a piecewise enhancement function, a linear function, a nonlinear function, a sigmoid function, attention weights, or a learned enhancement function; The piecewise enhancement function is expressed as follows: ； In the formula, , This is the threshold for the strength of edge-level anomalous evidence, used to distinguish between weak, moderate, and strong anomalous evidence. , , These are enhancement coefficients corresponding to different anomaly evidence strength intervals, used to control the enhancement magnitude of the edge weights for weak, moderate, and strong anomalies, respectively. ; For service call edges, edge-level anomaly evidence is calculated by fusing call chain anomaly evidence and log anomaly evidence related to the call relationship. For PROVIDES and DEPLOYED_IN edges, vertical propagation enhancement is performed based on instance-level or node-level anomalous evidence.

[0025] In step S5, a random walk model with restart is used for propagation: set up Given an initial distribution consisting of node-level anomaly evidence, then the... Round propagation is represented as: ; In the formula, For the first The root cause score distribution vector of each candidate node after round of iteration; For graph propagation iteration rounds; The restart probability is used to control the return to the initial root cause distribution during the propagation of the control graph. The proportion; The propagation matrix is ​​obtained by normalizing the edge weights after evidence enhancement. The elements in the matrix represent the probability or intensity of the anomalous score propagating along the corresponding heterogeneous edge. For the first The root cause score distribution vector of each candidate node after round of iteration; The initial root cause distribution vector is composed of node-level anomaly evidence from each node. Each element in the vector corresponds to the initial anomaly suspicion level of a candidate node within the fault analysis window. An out-degree penalty or adaptive topology correction mechanism is introduced, and the final score is adjusted by combining the node's out-degree, node type, the strength of the node's own abnormal evidence, log evidence, and call chain evidence. When a high-connectivity node lacks abnormal evidence, the artificially high score of the high-connectivity node due to topology centrality is reduced. When the strength of the abnormal evidence of a high-connectivity node exceeds a preset threshold, the out-degree penalty is weakened or canceled. After the graph propagation is completed, the candidate root causes are ranked according to the final scores of each node, and the Top-K candidate root causes are selected to enter the subsequent large language model-assisted reasoning stage.

[0026] In step S6, the structured prompt information is organized in JSON, table or key-value pair format, including candidate node field, indicator evidence field, log evidence field, call chain evidence field, topology context field and output format constraint field; The structured prompts also include system profiles, prior knowledge from operations and maintenance experts, or output format constraints, which are used as soft constraints to assist in reasoning in large language models, but not as hard-coded rules for specific service names.

[0027] The method also includes a confidence verification step for the output of the large language model; If the final root cause output by the large language model does not belong to the Top-K candidate set obtained by graph propagation, or if the difference between the selection result and the graph propagation score ranking exceeds a preset threshold, then a consistency check is triggered. The consistency check includes reorganizing candidate evidence, expanding the candidate set, requiring the large language model to output evidence, or marking the result as low confidence and prompting manual review.

[0028] Another objective of this invention is to provide a microservice root cause localization system that integrates anomaly evidence and heterogeneous topology graphs. This system is used to implement the aforementioned microservice root cause localization method that integrates anomaly evidence and heterogeneous topology graphs. The system includes: The heterogeneous topology graph construction module is used to obtain system entities, service call relationships, service provision relationships, runtime deployment relationships, and external resource dependencies in the microservice system, and construct a multi-layer heterogeneous topology graph. The multi-layer heterogeneous topology graph includes at least service nodes, runtime instance nodes, and runtime environment nodes, as well as CALLS edges representing call relationships between services, PROVIDES edges representing the ability of runtime instances to provide services, and DEPLOYED_IN edges representing the deployment of runtime instances in the runtime environment. The multimodal data acquisition and alignment module is used to collect indicator data, log data, call chain data and system metadata for the fault time window to be analyzed, and to perform segmentation, aggregation and time alignment according to the fault time window to obtain multimodal observation data under the same time window; An anomaly evidence extraction module is used to extract anomaly evidence from the multimodal observation data and map the anomaly evidence to the multi-layer heterogeneous topology graph according to the semantic position of different modal data. The anomaly evidence extraction module includes: a node-level evidence extraction unit, used to map anomalies reflecting the entity's own operational status to node-level anomaly evidence of service nodes, running instance nodes, running environment nodes, or external resource nodes; and an edge-level evidence extraction unit, used to map call chain anomalies reflecting inter-service interaction anomalies to edge-level propagation evidence on CALLS edges, and to map log anomalies to node-level anomaly evidence or edge-level propagation evidence according to log source, log template semantics, and associated entities. The evidence-enhancing edge weight modeling module is used to set structural prior weights according to the edge type in the multi-layer heterogeneous topology graph, and to enhance the propagation weights of the corresponding edges by combining log anomaly evidence, call chain anomaly evidence or edge-level propagation evidence mapped to the edges, so as to obtain the evidence-enhanced propagation matrix. The graph propagation root cause ranking module is used to perform graph propagation on the evidence-enhanced multi-layer heterogeneous topology graph using the node-level anomaly evidence as the initial root cause distribution, to obtain the root cause score of each candidate node, and to generate a candidate root cause ranking. The candidate root cause filtering module is used to select Top-K candidate root causes from the candidate root cause ranking, and organize the Top-K candidate root causes, the corresponding indicator anomaly summary, log anomaly summary, call chain anomaly summary, and local topology subgraph into structured prompt information; The large language model-assisted reasoning module is used to input the structured prompt information into the large language model, perform topologically constrained assisted reasoning, and output the final root cause localization result. The results output module is used to output the final root cause localization results, candidate root cause ranking, relevant abnormal evidence and reasoning explanation information, and generate alarm summaries or maintenance work orders.

[0029] Compared with the prior art, the present invention has at least the following beneficial effects: First, this invention constructs a multi-layered heterogeneous topology graph containing Services, Pods, and Nodes, simultaneously depicting business call relationships, service instance relationships, and underlying resource deployment relationships, thereby more accurately describing cross-layer fault propagation paths in Kubernetes microservice systems. This invention distinguishes and models different modal anomaly evidence according to its semantic position, typically prioritizing indicator anomalies as node-level evidence and call chain anomalies as edge-level propagation evidence. Furthermore, based on the specific meaning of log semantics, network indicators, or resource-related anomalies, it flexibly maps them to node-level or edge-level propagation evidence, avoiding semantic confusion caused by simple concatenation of multimodal data and improving the efficiency of anomaly evidence utilization. This invention uses an edge-weighted modeling approach combining structural priors and anomaly evidence enhancement, making it easier for anomaly scores to propagate along high-risk paths, thereby improving the ability of candidate root cause ranking to express the actual fault propagation path. This invention employs a graph propagation mechanism with restart capabilities, enabling the propagation process to utilize the topology while maintaining its association with the original anomaly evidence, reducing the excessive diffusion of anomalies in irrelevant subgraphs.

[0030] Secondly, to reduce the artificially high scores of high-connectivity nodes due to topological centrality, this invention can optionally introduce out-degree penalties or adaptive topology correction mechanisms. This mechanism can dynamically adjust the penalty level based on the strength of node anomaly evidence, node type, log evidence, and call chain evidence. When a high-connectivity node has sufficient anomaly evidence, the out-degree penalty can be weakened or canceled to avoid excessive suppression of the true hub root cause. This invention uses a large language model-assisted reasoning system with candidate root cause screening and topological constraints. Only candidate nodes and their structured evidence after graph propagation screening are input into the large language model, reducing irrelevant raw data input and lowering token consumption and reasoning costs. This invention can output root cause ranking, final root cause, and evidence explanation, facilitating maintenance personnel's understanding of fault propagation paths and root cause judgment criteria. It can be further extended to alarm summaries, fault tickets, or SRE handling suggestions. This invention first uses graph propagation to screen candidate root causes, and then the large language model performs semantic discrimination within the candidate range. Therefore, it can improve root cause localization indicators such as Top-1 and MRR while reducing the scale of irrelevant raw data input to the large language model, thus reducing single-case Prompt Token and total Token consumption. Attached Figure Description

[0031] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the disclosure of this invention and, together with the description, serve to explain the principles of the disclosure of this invention. Figure 1 This is a flowchart of the microservice root cause localization method that integrates abnormal evidence and heterogeneous topology graphs provided in this embodiment of the invention. Figure 2This is a schematic diagram of multimodal anomaly evidence mapping provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the evidence enhancement graph propagation process provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of topological constraints-assisted reasoning using a large language model provided in an embodiment of the present invention. Detailed Implementation

[0032] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention can be practiced in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0033] The innovation of this invention lies in: (1) This invention proposes a multi-layer heterogeneous topology modeling method for microservice runtime environments. This invention abstracts the microservice system into multiple entities such as Service, RuntimeInstance, ExecutionEnvironment and ExternalResource, and uses relationships such as CALLS, PROVIDES, DEPLOYED_IN and DEPENDS_ON to uniformly describe service calls, instance provisioning, runtime deployment and external dependencies.

[0034] In the Kubernetes scenario, `RuntimeInstance` can be specifically represented as a `Pod`, and `ExecutionEnvironment` can be specifically represented as a `Node`. Therefore, the Service-Pod-Node three-layer structure is the specific application of this general topology modeling method in a Kubernetes microservice system. Through this approach, the present invention can cover the multi-layered dependency relationships of Service, Pod, and Node in Kubernetes scenarios, and can also adapt to ordinary containerized, semi-containerized, or non-standard Kubernetes microservice systems with incomplete fields.

[0035] (2) This invention proposes a fault window-driven method for aligning and mapping multimodal anomaly evidence and topology. This invention adopts a processing approach of unified fault window segmentation, intramodal aggregation, entity / edge binding, and anomaly evidence alignment to uniformly convert observation data with different sampling frequencies and data forms, such as metric, log, and trace, into anomaly evidence under the same fault window.

[0036] Specifically, indicator anomalies are primarily mapped to node-level anomaly evidence, call chain anomalies are primarily mapped to edge-level propagation evidence, and log anomalies are mapped to either node-level anomaly evidence or edge-level propagation evidence based on log source and log semantics. This method avoids semantic confusion caused by simply concatenating multimodal data, enabling anomaly evidence to be injected into heterogeneous topology graphs in a structurally consistent manner.

[0037] (3) This invention proposes a trainable type recognition and differentiated anomaly detection routing method for microservice monitoring metrics. This invention uses a trainable metric type recognizer to identify the type of KPI time series, outputs the type as smooth, sparse, constant or counter, and automatically routes to the corresponding anomaly detection branch based on the recognition result.

[0038] Specifically, the smooth type enters the continuous smoothness indicator detection branch, the sparse type enters the sparse burst indicator detection branch, the constant type enters the near-constant or horizontal offset detection branch, and the counter type enters the counter detection branch. The anomaly scores output from different branches are uniformly standardized and then aggregated into node-level anomaly evidence. This method can reduce false positives, false negatives, and boundary sample misclassification problems caused by relying solely on rules or a unified anomaly detection model.

[0039] (4) This invention proposes a graph propagation root cause ranking method based on structural priors and edge-level anomaly evidence enhancement. When performing graph propagation on a multi-layer heterogeneous topology graph, this invention uses node-level anomaly evidence as the initial root cause distribution, and dynamically enhances the edge weights based on edge type structural priors and edge-level propagation evidence such as log anomalies and call chain anomalies mapped to the edges.

[0040] In this way, the graph propagation process not only considers the system topology, but also strengthens high-risk propagation paths by using real-time anomaly evidence within the fault window, thereby reducing the risk of misjudging symptom nodes based solely on local anomaly intensity or static topology propagation.

[0041] (5) This invention proposes a root cause reasoning method assisted by a large language model with topological constraints. Instead of directly inputting all the original metric, log, and trace data into the large language model, this invention first generates Top-K candidate root causes through evidence enhancement graph propagation, and then organizes the candidate root causes, structured abnormal evidence summaries, and local topological subgraphs into prompt information, which is then input into the large language model for constrained root cause discrimination and interpretation generation.

[0042] This method can reduce the input context size of large language models, reduce inference costs and noise interference, and improve the structural consistency of the output results through local topological subgraph constraints.

[0043] (6) This invention proposes a consistency verification mechanism between graph propagation results and the output results of a large language model. When the final root cause selected by the large language model is significantly lower in the graph propagation candidate ranking, or its graph propagation score differs significantly from the first candidate node in the ranking, or the root cause propagation path output by the large language model does not belong to a valid path in the input local topological subgraph, a low confidence mark, re-inference, or manual review prompt is triggered.

[0044] This mechanism is used to reduce the risk of inconsistency between the output of a large language model and the actual topology of the system, thereby improving the reliability of the final root cause localization results.

[0045] Example 1: Overall Process; As shown in Table 1, the overall process of the microservice root cause localization method that integrates anomalous evidence and heterogeneous topology graphs provided in this embodiment of the invention includes: heterogeneous topology graph construction, multimodal data collection and time window alignment, anomalous evidence extraction, anomalous evidence mapping, evidence enhancement graph propagation, candidate root cause screening, and large language model-assisted reasoning with topological constraints.

[0046] Table 1 Overall Flowchart and Main Inputs and Outputs S1 Heterogeneous topology graph construction Kubernetes metadata, service call relationships, deployment relationships Heterogeneous topology graph containing Services, Pods, Nodes, and various types of edges S2 Multimodal data acquisition and alignment Metrics, logs, call chains, and fault time windows Multimodal observation data under a unified time window S3 Abnormal evidence extraction Aligned metrics, logs, and call chain data Node-level anomaly evidence, edge-level propagation evidence S4 Evidence-enhanced edge weight modeling Multi-layer heterogeneous topology graph, edge types, node-level anomaly evidence, edge-level propagation evidence Evidence-enhanced edge weights and propagation matrix S5 Root Cause Ranking and Candidate Selection in Graph Propagation Node-level anomaly evidence, enhanced propagation matrix, multi-layer heterogeneous topology graph Candidate node root cause score, candidate root cause ranking, Top-K candidate root cause list S6 Large language model-assisted reasoning Candidate root causes, topological subgraphs, and summaries of anomalous evidence Final root cause localization results and explanation like Figure 1 As shown, the microservice root cause localization method that integrates anomaly evidence and heterogeneous topology graphs provided in this embodiment of the invention specifically includes the following steps: S1. Heterogeneous Topology Graph Construction: Obtain system entities and dependencies in the Kubernetes microservice system and construct a heterogeneous topology graph. ,in, Represents a set of entity nodes. Represents a set of heterogeneous relationships between entities.

[0047] The heterogeneous topology diagram of the microservice system shows three layers of nodes: Service, Pod, and Node, as well as three types of edges: CALLS, PROVIDES, and DEPLOYED_IN.

[0048] Among them, entity nodes include at least the following three types: Service node: Represents a business service or service entry point in a microservice system, such as frontend, cartservice, paymentservice, etc.

[0049] Pod node: Represents the running unit in Kubernetes that hosts a specific service instance.

[0050] Node: Represents a physical machine, virtual machine, or compute node in a Kubernetes cluster.

[0051] Heterogeneous edges include at least the following three types: CALLS edge: Indicates the calling relationship between Services, used to describe the propagation path of business requests between services.

[0052] PROVIDES edge: Indicates the service provision relationship between Pod and Service, used to describe a running instance hosting or providing a certain service.

[0053] The DEPLOYED_IN edge indicates the relationship between a Pod and a Node, and is used to describe the dependency between the running instance and the underlying computing resources.

[0054] Through the aforementioned nodes and edges, this invention can uniformly represent business call relationships, running instance relationships, and underlying resource deployment relationships in a heterogeneous topology graph, thereby supporting cross-layer fault propagation analysis. In an optional implementation, a corresponding topology snapshot can be selected based on the fault time window to adapt to dynamic changes such as Pod restarts, migrations, or scaling up / down.

[0055] S2. Multimodal Data Acquisition and Time Window Alignment: For the time window of the fault to be analyzed, multimodal observability data of the microservice system is collected. This multimodal observability data includes, but is not limited to: Metrics data include service-level, instance-level, or node-level metrics such as CPU, memory, disk, network, request latency, error rate, and throughput.

[0056] Log data includes runtime logs, exception logs, log templates, log levels, and the number of times logs occur, etc., output by each service or Pod.

[0057] Call chain data includes the caller, callee, call duration, call status code, call error information, and number of abnormal calls.

[0058] System metadata includes service name, Pod name, Node name, deployment relationship, tag information, and service selector.

[0059] During data processing, metric, log, and trace are uniformly segmented, intramodal aggregated, entity / edge bound, and anomaly evidence aligned according to the fault window to obtain node-level anomaly evidence and edge-level propagation evidence under the same fault window.

[0060] Furthermore, time window alignment specifically includes: Multimodal data acquisition and time window alignment include unified fault window segmentation, intramodal aggregation, entity / edge binding, and anomaly evidence alignment.

[0061] First, based on the fault labeling file, alarm trigger time, anomaly detection time, or manually confirmed fault occurrence time, determine the fault analysis window W=[t_start,t_end] corresponding to the fault event to be analyzed. Then, extract records from the indicator data table, log data table, and call chain data table whose timestamps fall within the fault analysis window W, or overlap with the fault analysis window W in time. Simultaneously, combine the service metadata table, resource relationship table, or Kubernetes resource table to determine the valid services, running instances, operating environments, external resources, and their topology relationships within the fault analysis window W.

[0062] For the indicator data, the point-level metric data within the fault analysis window W are aggregated according to entity type, entity identifier, and KPI name to form the KPI time series of the corresponding entity within the fault analysis window W. The indicator anomaly intensity is then calculated based on the KPI time series. The indicator anomaly intensity is used to characterize the degree of abnormality in the operating status of service nodes, running instance nodes, running environment nodes, or external resource nodes within the fault analysis window W.

[0063] For log data, log events within the fault analysis window W are extracted according to log timestamps, and window-level aggregation is performed based on the log source entity, log template, log level, error keywords, abnormal keywords, and the number of times the log occurs to form a log anomaly summary. The log anomaly summary is mapped to node-level anomaly evidence for the corresponding node, or to edge-level propagation evidence related to service calls, service dependencies, instance hosting, or deployment relationships, based on the log source and log semantics.

[0064] For call chain data, relevant call records are filtered based on the overlap between the start time, end time, or duration of the trace or span and the fault analysis window W. Window-level aggregation is then performed, using the caller, callee, or call edge as units. Call time, exception status codes, number of call failures, number of timeouts, proportion of abnormal calls, or changes in call paths are statistically analyzed to form a call chain exception summary. This call chain exception summary is mapped to edge-level propagation evidence on service call edges, used to characterize the risk level of exception propagation along service call relationships.

[0065] Furthermore, the anomaly intensity of the indicators, anomaly summaries of logs, and anomaly summaries of call chains after windowing are uniformly mapped to a multi-layered heterogeneous topology graph according to entity identifiers and topological relationships, forming node-level anomaly evidence and edge-level propagation evidence under the same fault analysis window W. Node-level anomaly evidence is used to initialize the root cause suspicion level of the corresponding candidate nodes, while edge-level propagation evidence is used to enhance the propagation weight of the corresponding heterogeneous edges.

[0066] In this way, the present invention unifies the scattered indicator data, log data, and call chain data, which are distributed in different data tables, have different sampling frequencies, and different data forms, into abnormal evidence with a clear topological position under the same fault analysis window. This ensures that the multimodal abnormal evidence used in subsequent evidence enhancement graph propagation and large language model-assisted reasoning corresponds to the same fault event in time and can distinguish between node state abnormalities and edge propagation abnormalities in semantics. This avoids the confusion of evidence caused by simply splicing together abnormalities from different time periods, different entities, or different propagation paths.

[0067] S3. Anomaly Evidence Extraction and Graph Mapping: Extract anomaly evidence from multimodal data within the same time window and map the anomaly evidence to a heterogeneous topology graph.

[0068] A schematic diagram of multimodal anomaly evidence mapping is shown below. Figure 2 As shown, indicator anomalies are mapped to node-level evidence, log anomalies and call chain anomalies are mapped to edge-level propagation evidence, and topology is used as structural prior.

[0069] For metric data, anomaly detection methods are used to calculate the anomaly intensity of each entity node. Metric anomalies can be identified through statistical thresholds, sliding windows, MAD (Multi-Aspect Divergence), Isolation Forest, time-series prediction residuals, deep learning anomaly detection models, or other anomaly detection methods. For each entity node, the anomaly intensity of its associated metrics is aggregated into node-level anomaly evidence, representing the initial suspicion level of that node as a root cause. For log data, anomaly log templates, error keywords, anomaly log frequencies, or log semantic features are extracted to obtain log anomaly evidence. Log anomaly evidence can be mapped to the service or Pod to which the log belongs and further used to enhance the propagation edge weights related to that service or Pod.

[0070] This improvement avoids the false alarms and false negatives caused by using a uniform detection model for all indicators in traditional methods, and improves the quality of the initial scores of nodes entering the graph propagation stage.

[0071] For call chain data, call chain anomalies are identified based on abnormal call duration, call failure status, exception status code, number of abnormal calls, or changes in the call path. Evidence of call chain anomalies is mapped to call relationship edges to indicate the degree of risk of the anomaly propagating along those edges.

[0072] Call chain anomalies can be identified based on span call relationships, call duration, status codes, and the number of abnormal calls, and mapped as edge-level propagation evidence on CALLS edges for subsequent edge weight enhancement.

[0073] A key feature of this invention is its role-based modeling based on the primary semantic function of different modalities of data. Typically, anomalies in metrics primarily reflect the entity's own state, thus they are prioritized as node-level anomaly evidence; call chain anomalies primarily reflect inter-service interaction anomalies, thus they are prioritized as edge-level propagation evidence; log anomalies can reflect both internal entity errors and service interaction anomalies, therefore they can be mapped to node-level or edge-level propagation evidence based on log source, log template semantics, and associated entities. Furthermore, in specific scenarios, some network metrics, connection metrics, or request metrics can also serve as edge-level propagation evidence, and some resource logs, crash logs, or OOM logs can also serve as node-level root cause evidence.

[0074] In one implementation, for indicator data, this invention does not uniformly apply the same anomaly detection algorithm to all KPIs. Instead, it first identifies the type of each KPI time series, and then selects a differentiated anomaly detection strategy based on the identified type. The indicator processing flow is as follows: Collect raw point-level metric data and aggregate it according to entity type, entity identifier, and KPI name to obtain multiple KPI time series; Perform indicator type identification for each KPI time series to obtain the smooth, sparse, constant, or counter type; Select the corresponding anomaly detection branch according to the type of indicator. For example, smooth indicators use prediction residual or sliding statistical deviation detection, sparse indicators use robust statistical detection, count indicators use reset-aware diff before detection, and near-constant indicators use level shift detection. The abnormal scores output by different detection branches are standardized to obtain comparable index abnormality intensity. Aggregate the intensity of abnormal metrics associated with the same Service, Pod, or Node into node-level anomaly evidence, which serves as the initial root cause distribution for subsequent heterogeneous topology graph propagation.

[0075] The improvement in the above process lies in: automatically learning KPI-type routing strategies through a trainable classifier, reducing misclassification caused by relying solely on manual rules, and improving the accuracy of subsequent anomaly detection branch selection, thereby improving the quality of node-level anomaly evidence.

[0076] S4. Edge weight modeling enhanced by structural prior and anomaly evidence: Set structural prior weights based on the edge types in the heterogeneous topology graph, and enhance the edge weights by combining log anomaly evidence and call chain anomaly evidence.

[0077] For any edge Its edge weights can be expressed as: ; in, This represents the structural prior weights in a heterogeneous topology of Kubernetes microservices, determined by the edge type, such as CALLS, PROVIDES, and DEPLOYED_IN. Indicates the edge type; This indicates the strength of the multimodal anomaly evidence mapped to this edge; The enhancement factor, determined by the strength of the anomalous evidence, is used to represent the dynamic enhancement effect of log anomalies, call chain anomalies, and other anomalous evidence that can be mapped to edges on the propagation edge weights within the failure time window.

[0078] This can be represented using a piecewise enhancement function: ; in, , The threshold for the strength of evidence. , , For the enhancement coefficient, and Through the aforementioned piecewise enhancement function, weak anomaly evidence only slightly enhances the propagation edge weights, moderate anomaly evidence moderately enhances them, and strong anomaly evidence significantly enhances them, thus making it easier for anomaly scores to propagate along high-risk paths. The piecewise function described above is only one possible implementation; in other implementations… Linear functions, nonlinear functions, sigmoid functions, attention weights, or learned enhancement functions can also be used. The improvement of this invention lies in segmenting and enhancing propagation edge weights based on the strength of edge-level anomaly evidence, rather than simply linearly superimposing all anomaly evidence onto the edge weights. Weak anomaly evidence generates only minor enhancement, moderate anomaly evidence generates moderate enhancement, and strong anomaly evidence generates higher enhancement, thereby highlighting high-risk propagation paths and reducing the interference of weak noise anomalies on graph propagation. Therefore, this formula can serve as a specific implementation of the dynamic edge weight enhancement mechanism of this application. Its inventiveness lies not in the mathematical form of the piecewise function itself, but in the fact that this piecewise function is used to fuse multimodal edge-level evidence such as call chain anomalies and log anomalies, and serves root cause propagation ranking in microservice heterogeneous topology graphs.

[0079] In one implementation, for service call edges, edge-level anomaly evidence can be calculated by fusing call chain anomaly evidence and log anomaly evidence. For example, call chain anomalies can be obtained from the proportion of abnormal call time, the number of abnormal calls, or statistics on abnormal status codes; log anomalies can be obtained from the hit rate of the abnormal log template of the called service, the frequency of error logs, or the results of log semantic analysis. Subsequently, enhancement factors are set in segments according to the strength of evidence, so that edges corresponding to strong anomaly evidence receive higher propagation weights, while edges corresponding to weak anomaly evidence receive only minor enhancements or no enhancements.

[0080] In other alternative implementations, the edge weights can be further corrected by combining historical fault data or lightweight causal analysis results, but such correction is not a necessary step in this embodiment.

[0081] Furthermore, for the PROVIDES and DEPLOYED_IN edges, this invention can also enhance vertical propagation based on instance-level or node-level anomaly evidence. For example, when a Node experiences abnormal CPU utilization, memory pressure, disk I / O, or network anomalies within a fault time window, the propagation weight of the DEPLOYED_IN edge between that Node and its hosting Pod can be increased, enabling underlying resource anomalies to propagate to its upper-layer Pods and Services. When a Pod experiences a restart, OOM, CrashLoopBackOff, instance unavailability, or critical log anomalies, the propagation weight of the PROVIDES edge between that Pod and its providing Service can be increased, enabling instance-level anomalies to influence root cause analysis of the corresponding service. Thus, this invention can not only characterize horizontal call propagation between Services but also vertical cross-layer fault propagation between Nodes, Pods, and Services.

[0082] The segmented enhancement method described above can highlight high-risk propagation paths and avoid the graph propagation process from spreading only along the static topology, thereby improving the sensitivity of candidate root cause ranking to the actual direction of fault propagation.

[0083] S5. Graph Propagation Root Cause Localization Based on Multimodal Evidence Enhancement: Using node-level anomaly evidence as the initial root cause distribution, graph propagation is performed on the heterogeneous topology graph to obtain the root cause score of each candidate node.

[0084] A schematic diagram of the evidence enhancement graph propagation process is shown below. Figure 3 As shown, the edge weights are jointly determined by the structural prior and the anomalous evidence enhancement factor, and the candidate root cause ranking is generated through propagation with a restart graph.

[0085] In one implementation, a random walk model with restart is used for propagation. Let... Given an initial distribution consisting of node-level anomaly evidence, then the th Round propagation is represented as: ; In the formula, For the first The root cause score distribution vector of each candidate node after round of iteration; For graph propagation iteration rounds; The restart probability is used to control the return to the initial root cause distribution during the propagation of the control graph. The proportion; The propagation matrix is ​​obtained by normalizing the edge weights after evidence enhancement. The elements in the matrix represent the probability or intensity of the anomalous score propagating along the corresponding heterogeneous edge. For the first The root cause score distribution vector of each candidate node after round of iteration; The initial root cause distribution vector is composed of node-level anomaly evidence from each node. Each element in the vector corresponds to the initial anomaly suspicion level of a candidate node within the fault analysis window. The first term represents the propagation of anomaly scores along heterogeneous topological edges, and the second term represents the probability of returning to the original anomaly evidence distribution. Through the restart mechanism, the propagation process can both utilize the topological structure to discover relevant nodes and maintain the correlation with the original anomaly observations, reducing the excessive diffusion of anomaly scores in irrelevant subgraphs.

[0086] To reduce the artificially inflated scores of high-connectivity nodes due to topological centrality, this invention can further introduce out-degree penalties or adaptive topology correction mechanisms. This mechanism adjusts the final score based on the propagation score, taking into account node out-degree, node type, the strength of anomaly evidence for the node itself, log evidence, and call chain evidence. When a high-connectivity node lacks sufficient anomaly evidence, its ranking score can be appropriately reduced; when a high-connectivity node possesses sufficient anomaly evidence, the penalty can be weakened or eliminated to prevent genuine hub nodes from being excessively undervalued.

[0087] After the graph propagation is completed, the candidate root causes are ranked according to the final scores of each node, and the Top-K candidate root causes are selected to enter the subsequent large language model-assisted reasoning stage.

[0088] S6. Topologically Constrained Large Language Model-Assisted Root Cause Reasoning: The candidate root cause list, candidate node indicator anomaly summary, related log anomaly summary, call chain anomaly summary, and local topological subgraphs near candidate nodes are organized into structured prompt information and input into the large language model for auxiliary reasoning.

[0089] A schematic diagram of large language model-assisted reasoning with topological constraints is shown below. Figure 4 As shown, the structured prompt words consist of Top-K candidate root causes, indicator summaries, log summaries, call chain summaries, and local topological subgraphs. The input to the large language model outputs the final root cause.

[0090] The structured prompts may include: a list of candidate root causes and their graph propagation scores; key anomaly indicators and anomaly strength associated with each candidate root cause; anomaly log templates, error keywords, or anomaly log counts associated with the candidate root cause; anomaly call chains associated with the candidate root cause, including the caller, callee, anomaly duration, status code, and anomaly count; a local topology subgraph of the candidate root cause, including upstream services, downstream services, Pod instances, and deployed Nodes; and format requirements for constraining model output, such as outputting the final root cause, supporting evidence, and a brief explanation.

[0091] In one implementation, the structured prompt information can be organized in JSON, table, or key-value pair format. For example, the structured prompt information may include the following fields: candidate_nodes: used to represent the Top-K candidate root cause nodes and their graph propagation scores, node types, and ranking positions; metric_evidence: used to represent the key anomaly indicators, anomaly strength, anomaly time windows, and indicator types associated with the candidate nodes; log_evidence: used to represent the anomaly log template, log summary, error keywords, log occurrence count, and log source entity associated with the candidate node or candidate edge; trace_evidence: used to represent the evidence of the anomaly call chain, and the call chain data template summary includes the caller, callee, call duration changes, anomaly status code, number of anomaly calls, and call direction; topology_context: used to represent the local topology relationships near the candidate node, including upstream nodes, downstream nodes, corresponding Pods, deployed Nodes, and related edge types; in optional implementations, system profiles, operation and maintenance expert priors, or output format constraints may also be added, but not as hard-coded rules for specific service names; output_format: used to constrain the large language model output of the final root cause, judgment basis, related evidence, and confidence information.

[0092] In optional implementations, expert prior knowledge may include prior knowledge of the gold signal or RED observation signal, prior knowledge of the call chain path, prior knowledge of log semantic confidence, prior knowledge of multi-source observation consistency, and prior knowledge of cross-layer propagation. These prior knowledge are only used as soft constraint fields in the structured prompt information to assist the large language model in understanding the relationships between candidate nodes, anomaly evidence, and local topology, and are not used as hard-coded rules for specific service names.

[0093] The aforementioned expert prior knowledge is incorporated into structured prompts in the form of soft constraint functions or structured constraint fields to guide the large language model in making root cause judgments under the joint constraints of candidate sets, topological structure, and multimodal evidence, rather than replacing graph propagation ranking results or forming fixed service name rules.

[0094] By first performing graph propagation to filter the candidate set and then calling the large language model for semantic discrimination, this invention can avoid directly inputting a large amount of raw data into the large language model, reducing the length of prompt words and token consumption. At the same time, the topological subgraph and candidate ranking provide structured constraints for the large language model, which can reduce the interference of noise anomalies and downstream symptoms on the final judgment.

[0095] This invention also includes a confidence verification step for the output of the large language model. If the final root cause output by the large language model does not belong to the Top-K candidate set obtained by graph propagation, or if the difference between its selection result and the graph propagation score ranking exceeds a preset threshold, a consistency verification is triggered. The consistency verification may include reorganizing candidate evidence, expanding the candidate set, requiring the large language model to output evidence, or marking the result as low confidence and prompting manual review. Through the above methods, the risk of the large language model making erroneous root cause judgments due to the influence of noisy logs, occasional anomalies, or hallucinations can be reduced.

[0096] Furthermore, the consistency verification conditions mainly include three categories: deviation of candidate sorting position, deviation of graph propagation score, and inconsistency of topology propagation path.

[0097] If the final root cause selected by the large language model belongs to the Top-K candidate set, but its position in the graph propagation candidate ranking is greater than the preset ranking threshold K_check, it indicates that the selection result deviates significantly from the graph propagation ranking, which can trigger a consistency check. Alternatively, if the difference between the graph propagation score corresponding to the final root cause selected by the large language model and the score of the candidate node ranked first in the graph propagation ranking exceeds the preset score difference threshold δ_score, it indicates that the selection result differs significantly from the graph propagation score, which can also trigger a consistency check. Or, if the root cause propagation path output by the large language model does not belong to a valid path in the input local topology subgraph, or if the direction of the propagation path conflicts with the direction of edges such as CALLS, PROVIDES, DEPLOYED_IN, or DEPENDS_ON in the local topology subgraph, a consistency check is triggered.

[0098] K_check and δ_score can be determined using default empirical values ​​or based on a historical failure case validation set. In one example implementation, when the candidate set size is K, K_check can be min(5,K), and δ_score can be 0.3. Furthermore, the distribution of graph propagation ranking positions and score differences corresponding to correct output samples of the large language model can be statistically analyzed on the historical failure case validation set. K_check can be set as a preset quantile of the ranking position of the correct output sample, and δ_score can be set as a preset quantile, such as the 90th quantile, of the score difference between the correct output sample and the top-1 node in graph propagation. In this way, the consistency verification threshold can be adaptively determined according to different system sizes, candidate set sizes, and graph propagation score distributions.

[0099] Example 2: Intelligent Classification Process for Indicator Types 1. Method for generating indicator type labels The indicator type reflects the overall statistical pattern and business meaning of a KPI time series, rather than the instantaneous value at a specific point in time. Therefore, when constructing training samples, the original point-level metric data is aggregated into KPI time series, and each KPI series is assigned a type label.

[0100] Initial labels can be generated from KPI name semantics and sequence morphology rules, and then combined with expert review and anomaly detection effect verification to form expert labels, which are used for offline training of indicator type recognizers.

[0101] In a preferred embodiment, expert labels are used as training labels for the indicator type classifier. These labels are not inherent to the original data, but rather are corrected labels obtained by combining expert knowledge and verification of anomaly detection performance with weak rule labels. The goal of the classifier is to learn the routing strategy of these expert labels, enabling the model to automatically determine whether a KPI sequence belongs to the smooth, sparse, constant, or counter type.

[0102] 2. Two implementation methods for trainable index type classifiers (1) Table feature classifier based on machine learning In one implementation, the index type classifier is implemented using a tabular machine learning model, such as CatBoost, LightGBM, XGBoost, Random Forest, Logistic Regression, or other supervised classification models. The following explanation uses the CatBoost classifier as an example.

[0103] The input to the CatBoost classifier includes raw semantic information and some statistical information. Raw semantic information includes entity_type, kpi_name, and keyword features parsed from the KPI names. Statistical information may include the missing percentage, the percentage of valid points, the mean of the differences, the standard deviation of the differences, the coefficient of variation of the differences, and non-negative labels.

[0104] Furthermore, for cases where there are insufficient counter-type samples or the classifier confidence is low, this invention adds a counter consistency check and a secondary routing mechanism based on the output of the indicator type classifier. The counter consistency check can combine at least one of the following information from the KPI name (e.g., total, count, bytes_total, packets_total, requests_total), sequence non-negativity, approximately monotonically non-decreasing proportion, negative difference proportion, reset features, and the morphology of the incremental sequence after reset-awarediff to determine whether the indicator conforms to the characteristics of the original accumulating counter.

[0105] When the classifier outputs "counter" and the counter consistency check passes, the indicator is routed to the counter detection branch. After performing a reset-aware diff transformation, it is used for burst detection, rate anomaly detection, or robust statistical anomaly detection. When the classifier does not output "counter" but the counter consistency check score is high, the indicator is marked as a candidate indicator for "counter" and can be further judged or anomaly detected after performing a reset-aware diff transformation. When the classifier outputs "counter" but the counter consistency check fails, it is not forced to enter the "counter" branch. Instead, it is routed to the corresponding detection branch of "smooth," "sparse," or "constant" based on the second-highest confidence type or sequence morphology.

[0106] Through the above-mentioned "classifier output + counter consistency check + reset-aware diff + secondary routing" mechanism, this invention can avoid mistakenly sending total / count type indicators that have been rated, throughput-type or fluctuating into the counter branch, while ensuring that the real original cumulative counter indicators can still enter the counter detection process when the classification confidence is insufficient, thereby improving the integrity and robustness of the indicator type identification and differential anomaly detection process.

[0107] The above-mentioned auxiliary judgment mechanism can prevent the true cumulative counter index from being missed when there are few training samples for the counter class or the classifier confidence is insufficient. At the same time, it can prevent the indexes with names containing "total" or "count" but which do not actually conform to the cumulative counting feature from being mistakenly sent to the counter branch.

[0108] 3. The connection between classification results and the differential anomaly detection branch The type result output by the indicator type classifier is used to drive the subsequent differential anomaly detection branch. In one implementation, when the classifier outputs a smooth type, it enters the continuous smooth indicator detection branch; when it outputs a sparse type, it enters the sparse burst indicator detection branch; when it outputs a constant type, it enters the near constant or horizontal offset detection branch; and when it outputs a counter type and the counter consistency check passes, it enters the counter-specific detection branch.

[0109] Table 2 Correspondence between indicator types and anomaly detection branches smooth CPU utilization, memory utilization, request latency, RTT, etc. Predictive residual detection, moving statistical deviation detection, or historical baseline deviation detection sparse Indicators related to sparse events such as error, timeout, and process. rolling median, MAD, or robust statistical test constant memtotal, filesystem size / free, capacity, limit, quota, etc. Level shift detection or state change detection counter Indicators such as total and count are approximately monotonically cumulative. After reset-aware diff conversion, sudden increase detection or rate anomaly detection is performed. As shown in Table 2, the classifier does not directly replace anomaly detection through the above method, but rather serves as a pre-routing module for anomaly detection, guiding KPIs with different statistical forms to more suitable detection branches and reducing false positives and false negatives caused by a unified detection model. The anonymization experiment results show that both the table classifier and the deep learning classifier achieve high overall hit rates and can effectively complete KPI type routing; for a few classes such as counters, rule fallback and consistency checks are used to ensure executability.

[0110] Example 3: System Modules; The microservice root cause localization system that integrates anomaly evidence and heterogeneous topology graphs provided in this embodiment of the invention includes: The heterogeneous topology graph construction module is used to obtain system entities, service call relationships, service provision relationships, runtime deployment relationships, and external resource dependencies in the microservice system, and construct a multi-layer heterogeneous topology graph. The multi-layer heterogeneous topology graph includes at least service nodes, runtime instance nodes, and runtime environment nodes, as well as CALLS edges representing call relationships between services, PROVIDES edges representing the ability of runtime instances to provide services, and DEPLOYED_IN edges representing the deployment of runtime instances in the runtime environment. The multimodal data acquisition and alignment module is used to collect indicator data, log data, call chain data and system metadata for the fault time window to be analyzed, and to perform segmentation, aggregation and time alignment according to the fault time window to obtain multimodal observation data under the same time window; An anomaly evidence extraction module is used to extract anomaly evidence from the multimodal observation data and map the anomaly evidence to the multi-layer heterogeneous topology graph according to the semantic position of different modal data. The anomaly evidence extraction module includes: a node-level evidence extraction unit, used to map anomalies reflecting the entity's own operational status to node-level anomaly evidence of service nodes, running instance nodes, running environment nodes, or external resource nodes; and an edge-level evidence extraction unit, used to map call chain anomalies reflecting inter-service interaction anomalies to edge-level propagation evidence on CALLS edges, and to map log anomalies to node-level anomaly evidence or edge-level propagation evidence according to log source, log template semantics, and associated entities. The evidence-enhancing edge weight modeling module is used to set structural prior weights according to the edge type in the multi-layer heterogeneous topology graph, and combine log anomaly evidence, call chain anomaly evidence or other edge-level propagation evidence mapped to the edge to enhance the propagation weights of the corresponding edge, so as to obtain the evidence-enhanced propagation matrix. The graph propagation root cause ranking module is used to perform graph propagation on the evidence-enhanced multi-layer heterogeneous topology graph using the node-level anomaly evidence as the initial root cause distribution, to obtain the root cause score of each candidate node, and to generate a candidate root cause ranking. The candidate root cause filtering module is used to select Top-K candidate root causes from the candidate root cause ranking, and organize the Top-K candidate root causes, the corresponding indicator anomaly summary, log anomaly summary, call chain anomaly summary, and local topology subgraph into structured prompt information; The large language model-assisted reasoning module is used to input the structured prompt information into the large language model, perform topologically constrained assisted reasoning, and output the final root cause localization result. The results output module is used to output the final root cause localization results, candidate root cause ranking, relevant abnormal evidence and reasoning explanation information, and generate alarm summaries or maintenance work orders.

[0111] Example 4: Validation process based on the AIOps2025 dataset The following uses AIOps2025 microservice failure data as an example to illustrate the application process of this invention in a Kubernetes microservice failure scenario. This embodiment is only used to illustrate the specific application of this invention and does not constitute a limitation on the scope of protection of this invention.

[0112] The fault data used in this embodiment includes metric data, log data, trace data, Service-Pod-Node topology information, and fault annotation files collected during the operation of the Kubernetes microservice system. The fault annotation files provide the root cause and fault time window for each fault event; metric data reflects the resource and business status of entities such as Services, Pods, and Nodes within the fault window; log data reflects error information and abnormal events during service operation; and trace data reflects the call relationships between services, call duration, call status, and exception propagation paths.

[0113] For each failure case, the failure time window is first determined based on the failure annotation file, and data within the corresponding time range is extracted from the metric, log, and trace data tables. Simultaneously, a heterogeneous topology graph is constructed by combining Kubernetes metadata and call chain relationships, containing three types of nodes: Service, Pod, and Node, and three types of edges: CALLS, PROVIDES, and DEPLOYED_IN. Specifically, the CALLS edge is generated from the service call relationship, the PROVIDES edge is generated from the service provision relationship between Pod and Service, and the DEPLOYED_IN edge is generated from the deployment relationship between Pod and Node.

[0114] Subsequently, root cause localization is performed according to the overall process described in Example 1: anomaly evidence is extracted and mapped from the multimodal data within the fault window; anomalies in the indicators are aggregated into node-level anomaly evidence for Services, Pods, or Nodes; call chain anomalies are mapped into edge-level propagation evidence on CALLS edges; and log anomalies are mapped into node-level anomaly evidence or edge-level propagation evidence based on log source and log semantics. Then, edge weights are enhanced based on edge type structure priors and edge-level anomaly evidence, and graph propagation with restart is performed on the heterogeneous topology graph after evidence enhancement to obtain a Top-K candidate root cause set. Finally, the Top-K candidate root causes, structured anomaly evidence summary, and local topology subgraph are input into a large language model for constrained reasoning to output the final root cause and explanation.

[0115] This embodiment demonstrates that the present invention can complete the entire application process on Kubernetes microservice fault data, from fault window extraction, multimodal evidence mapping, heterogeneous graph propagation and sorting to large language model-assisted reasoning. Specific comparative experimental results are shown in the experimental verification embodiment below.

[0116] Example 5: Application methods under typical fault scenarios To further illustrate the application of this invention under different fault scenarios and its positive effects, the following description uses typical fault scenarios in a Kubernetes microservice system as an example.

[0117] (1) Scenarios where Node resource anomalies cause Pod and Service anomalies. In a Kubernetes microservice system, if a Node experiences resource-related issues such as increased CPU usage, abnormal memory consumption, disk I / O blocking, or network anomalies within a fault time window, the Pods deployed on that Node may experience slow response, restart, or become unavailable, thereby affecting the service capabilities of the corresponding Service. To address this scenario, this invention uses the DEPLOYED_IN edge to represent the deployment relationship between the Pod and the Node, and the PROVIDES edge to represent the provision relationship between the Pod and the Service. In the anomaly evidence mapping, abnormal Node resource metrics are mapped to Node-level anomaly evidence, Pod restarts, crashes, or error logs are mapped to Pod-level anomaly evidence, and Service call delays, error status codes, or timeout anomalies are mapped to edge-level propagation evidence on the CALLS edge. Furthermore, evidence-enhanced graph propagation and large language model-assisted reasoning are used to identify cross-layer fault propagation caused by underlying Node resource anomalies, thereby reducing the risk of misjudging upper-layer symptom Services as the root cause.

[0118] (2) Scenario where Service call anomalies cause upstream service performance degradation. In a Kubernetes microservice system, if a Service calls a downstream Service and experiences a significant increase in call time, an increase in exception status codes, or an increase in timeouts, the anomaly may propagate along the call chain, causing the upstream Service to also exhibit an increase in error rate, request latency, or alarms. To address this scenario, this invention constructs CALLS edges between Services based on trace data and maps call chain anomalies such as call time, exception status codes, failure counts, and anomaly call ratios to edge-level propagation evidence on the CALLS edges. Simultaneously, it combines service-specific metric anomalies and log anomalies to form node-level anomaly evidence or edge-level propagation evidence. By enhancing the weight of the corresponding CALLS edges through edge-level anomaly evidence, the graph propagation process pays more attention to the actual anomaly propagation path, thereby reducing misjudgments of upstream symptom services caused by sorting solely based on node anomaly intensity.

[0119] (3) Application Scenarios for Multi-Type KPI Anomaly Detection. In Kubernetes microservice systems, the statistical forms of different monitoring metrics vary significantly. For example, CPU utilization, memory utilization, and response time typically exhibit continuous and smooth changes, while metrics such as error and timeout usually show sparse bursts. Metrics such as requests_total and network_receive_bytes_total may have cumulative growth and reset characteristics, and some status-related metrics are approximately constant over a long period. To address this scenario, this invention employs a trainable metric type recognizer to identify the type of KPI time series, outputting smooth, sparse, constant, or counter types, and automatically routes the results to the corresponding anomaly detection branch. The anomaly scores output by different detection branches are standardized and aggregated into node-level anomaly evidence for Services, Pods, or Nodes, thereby improving the quality of node-level anomaly evidence and enhancing the stability and accuracy of subsequent graph propagation root cause ranking.

[0120] Through applications in the aforementioned different scenarios, this invention combines the multi-layered structural relationships of Service, Pod, and Node in a Kubernetes microservice system with multi-modal anomaly evidence such as metrics, logs, and traces, enabling cross-layer fault propagation analysis, service call anomaly propagation analysis, and multi-type metric anomaly detection. This method reduces false positives for symptom nodes, improves candidate root cause recall, and provides structured, low-noise input for large language model-assisted reasoning.

[0121] The present invention is not limited to the specific embodiments described above. Without departing from the core idea of ​​the present invention, the following optional embodiments or equivalent alternatives may be adopted.

[0122] In terms of node types, in addition to Service, Pod, Node or their higher-level generalizations Service, RuntimeInstance, ExecutionEnvironment, they can also be extended to entities such as Container, Deployment, Host, Database, MessageQueue, Cache, ExternalAPI, etc., depending on the specific deployment environment. In terms of edge types, in addition to CALLS, PROVIDES, DEPLOYED_IN, DEPENDS_ON, they can also be extended to access relationships, message passing relationships, resource sharing relationships, read-write relationships, or configuration dependency relationships.

[0123] In anomaly detection, statistical detection, threshold detection, time series prediction residuals, machine learning anomaly detection, or deep learning anomaly detection methods can be used for indicator anomaly detection; log anomaly analysis can employ keyword matching, log templates, log clustering, semantic vectors, or large language model summarization; and call chain anomaly identification can utilize features such as call duration, anomaly status codes, failure counts, timeout ratios, or anomaly span ratios. The anomaly scores output by different anomaly detection methods can be standardized and uniformly converted into node-level anomaly evidence or edge-level propagation evidence.

[0124] For graph propagation, in addition to random walks with restarts, PageRank, PersonalizedPageRank, shortest path propagation, message passing, graph neural networks, or other graph ranking methods can be used to rank candidate root causes. For large language model-assisted reasoning, locally deployed models, cloud-based large language models, domain-specific models, or lightweight language models can be used, and offline analysis, online alarm-triggered analysis, or streaming continuous analysis methods can be selected according to actual deployment needs.

[0125] With the aforementioned optional extensions, this invention can be adapted to Kubernetes, general containerization, semi-containerization, or other microservice runtime environments, and can be integrated into existing monitoring platforms, logging platforms, tracing systems, or AIOps platforms. Systems typically contain multiple layers of runtime entities such as Services, Pods, and Nodes, and faults may propagate along service call relationships, instance hosting relationships, and underlying deployment relationships.

[0126] To further verify the technical effectiveness of the embodiments of the present invention, a comparative experiment was conducted between the method of the present invention and the existing RCA method based on multiple microservice failure cases.

[0127] The experimental verification of this invention includes verification of root cause localization accuracy and verification of large language model inference efficiency. Root cause localization accuracy can be evaluated using metrics such as Top-K and MRR; inference efficiency can be evaluated using metrics such as single-case Prompt Token, total Token consumption, and average inference latency.

[0128] Experimental data includes metric data, log data, call chain data, and system topology or metadata information collected during the operation of the microservice system. Fault annotation files provide the true root cause and fault time window for each fault event. In the experiment, multimodal data within the corresponding range is extracted based on the fault time window, and a heterogeneous topology graph is constructed by combining it with system metadata. Subsequently, the method of this invention is used for anomaly evidence extraction, node-level evidence and edge-level propagation evidence mapping, evidence enhancement graph propagation, and large language model-assisted root cause reasoning.

[0129] The experiment used Top-1, Top-3, Top-5, Top-10, and MRR as evaluation metrics. Among them, Top-K indicates whether the true root cause appears in the top K candidate results, and MRR indicates the average regression of the true root cause in the candidate ranking. The higher the MRR value, the higher the true root cause ranks in the ranking results.

[0130] To verify the effectiveness of this invention compared to existing RCA techniques, several comparative methods were set up in the experiment: MicroRCA-Agent, representing a root cause analysis method based on multimodal data and a large language model; TraceRCA, representing a method for root cause localization mainly based on call chain information; CauseLens-reproduction, representing a cause-effect graph and counterfactual RCA method that reproduces the core process of CauseLens; RWR-only, representing an ablation method that only uses evidence-enhancing graph propagation for candidate root cause ranking without introducing large language model fine ranking; and RWR+LLM, representing the complete method of "evidence-enhancing graph propagation candidate screening + large language model constrained reasoning" in this invention.

[0131] Among them, CauseLens-reproduction represents the causal graph and counterfactual RCA method that reproduces the core idea of ​​CauseLens, and it integrates the reconstruction error score and the counterfactual contribution score to output the root cause candidate ranking. The experimental results are shown in Table 3.

[0132] Table 3 Comparison of Root Cause Localization Results of Various RCA Methods TraceRCA 9.09% 18.18% 22.73% 22.73% 0.1212 CauseLens-reproduction, RE+CF 27.78% 33.33% 38.89% 61.11% 0.3374 MicroRCA-Agent 40.91% 45.45% 50.00% 50.00% 0.4009 RWR-only 31.82% 59.09% 86.36% 100.00% 0.5123 RWR+LLM, the method of this invention 63.63% 68.18% 90.91% 100.00% 0.7013 The results above show that the RWR-only method using graph propagation alone achieves a Top-10 accuracy of 100.00%, indicating that graph propagation based on heterogeneous topological graphs and enhanced anomalous evidence can effectively filter the candidate root cause set, ensuring that the true root cause is covered within the candidate range. Furthermore, by introducing constrained reasoning using a large language model, the Top-1 accuracy of the method improved to 63.63%, and the MRR improved to 0.7013. This demonstrates that the large language model, under the constraints of the candidate set, structured anomalous evidence, and local topological subgraphs, can further enhance the refinement of candidate root causes and the final root cause judgment effect.

[0133] Compared to TraceRCA, this invention utilizes indicators, logs, call chains, and multi-layered heterogeneous topology to avoid the problem of insufficient information from a single call chain. Compared to CauseLens-reproduction, this invention maps node-level evidence and edge-level propagation evidence by roles and performs propagation ranking on the evidence-enhanced heterogeneous topology graph, which can better characterize the anomaly propagation path. Compared to MicroRCA-Agent, this invention first filters candidate root causes through graph propagation, and then inputs structured anomaly evidence and local topology subgraphs into a large language model for constrained inference, thus improving the localization effect while reducing the inference context size.

[0134] Furthermore, to verify the effectiveness of this invention in reducing the inference cost of large language models, the token consumption of MicroRCA-Agent and the method of this invention was compared. The results are shown in Table 4.

[0135] Table 4 Comparison of Inference Costs for Large Language Models Single-case Prompt Token 3380 1177 Reduced by approximately 65% Total Token Consumption 83046 31853 A decrease of approximately 61.6% The above results demonstrate that this invention, by first performing evidence enhancement graph propagation candidate screening and then inputting Top-K candidate root causes, structured anomaly evidence summaries, and local topological subgraphs into a large language model, can reduce contextual redundancy caused by directly inputting the full amount of original multimodal data and lower the inference cost of the large language model. Simultaneously, the candidate set and local topological subgraph constrain the inference process of the large language model, helping to reduce the interference of irrelevant anomalies and downstream symptom nodes on the final judgment.

[0136] In summary, the experimental results demonstrate that this invention has at least the following positive effects: First, graph propagation based on multi-layer heterogeneous topology and enhanced anomaly evidence can improve the recall capability of candidate root causes; second, the node / edge role mapping of multimodal anomaly evidence can improve the input quality of graph propagation; third, large language models can improve the final root cause ranking quality under candidate sets and local topological constraints; fourth, structured evidence summarization and candidate screening mechanisms can reduce the input scale and inference cost of large language models; fifth, compared with call chain-based, causal graph-based, and direct large language model-based RCA methods, this invention demonstrates better root cause localization performance and engineering deployment value in experimental fault cases.

[0137] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications, equivalent substitutions, and improvements made by those skilled in the art within the scope of the technology disclosed in the present invention, and within the spirit and principles of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A microservice root cause localization method that integrates anomalous evidence and heterogeneous topology graphs, characterized in that, The method includes the following steps: S1. Obtain the system entities, service call relationships, service provision relationships, and runtime deployment relationships in the microservice system, and construct a multi-layer heterogeneous topology graph. The multi-layer heterogeneous topology graph includes at least service nodes, runtime instance nodes, and runtime environment nodes; as well as CALLS edges representing the call relationships between services, PROVIDES edges representing the capabilities of runtime instances to provide services, and DEPLOYED_IN edges representing the deployment of runtime instances in the runtime environment. S2. For the fault time window to be analyzed, collect the indicator data, log data, call chain data and system metadata of the microservice system, and perform segmentation, aggregation and time alignment according to the fault time window to obtain multimodal observation data under the same time window; S3. Extract abnormal evidence from the multimodal observation data and map the abnormal evidence to the multi-layer heterogeneous topology graph according to the semantic position of different modal data; wherein, the abnormal indicators reflecting the entity's own operating status are mapped to node-level abnormal evidence of service nodes, running instance nodes or running environment nodes, the abnormal call chain reflecting the abnormal interaction between services is mapped to edge-level propagation evidence on the CALLS edge, and the log abnormalities are mapped to node-level abnormal evidence or edge-level propagation evidence according to the log source, log template semantics and associated entities; Among them, prioritizing abnormal indicators as evidence of node-level anomalies includes: Collect raw point-level metric data, aggregate it according to entity type, entity identifier and KPI name to obtain multiple KPI time series; For each KPI time series, a pre-trained indicator type recognizer is used to perform indicator type recognition, and the output type is smooth, sparse, constant or counter. The indicator type recognizer includes a machine learning classifier based on table features or a deep learning classifier based on raw time series data. The input of the indicator type recognizer includes at least one of KPI name semantics, entity type, keyword features, statistical features, raw time series or missing mask. Based on the identified indicator type, the corresponding branch is selected from multiple differential anomaly detection branches for anomaly detection, and an anomaly score is output. Specifically, when the indicator type is smooth, the continuous smooth indicator detection branch is entered, and prediction residual detection, moving statistical deviation detection, or historical baseline deviation detection is used; when the indicator type is sparse, the sparse burst indicator detection branch is entered, and moving median, MAD, or robust statistical detection is used; when the indicator type is constant, the near constant or horizontal offset detection branch is entered, and horizontal offset detection or state change detection is used; when the indicator type is counter, the counter detection branch is entered, and burst detection or rate anomaly detection is performed after resetting the perceptual differential transformation. The abnormal scores output by different detection branches are standardized to obtain the index abnormality intensity. Aggregate the intensity of abnormal indicators associated with the same service node, running instance node, or running environment node into node-level abnormal evidence; S4. Set the structural prior weights according to the edge type in the multi-layer heterogeneous topology graph, and combine the log anomaly evidence, call chain anomaly evidence or edge-level propagation evidence mapped to the edge to enhance the propagation weights of the corresponding edges to obtain the evidence-enhanced propagation matrix. Specifically, the propagation weights of the corresponding edges are enhanced to obtain the evidence-enhanced propagation matrix, where for any edge... The edge weights are expressed as: ； In the formula, For the edge The propagation weights are used to characterize the outlier scores along the edge. The intensity or probability of propagation; For the edge type To map to edges The edge-level anomaly evidence strength is used to characterize the impact of log anomaly evidence, call chain anomaly evidence, or edge-level propagation evidence on the edge. The degree of support for abnormal propagation; For the edge Starting node Point to target node , For the edge The starting node, For the edge The target node; Let be any heterogeneous relation edge in a multi-layered heterogeneous topology graph. For edge type The determined structural prior weights are used to characterize the fundamental influence of different types of topological relationships in anomaly propagation; Strength of evidence for boundary-level anomalies A defined enhancement factor is used to dynamically adjust the edges based on the strength of anomalous evidence. The propagation weights; the enhancement factor adopts a piecewise enhancement function, a linear function, a nonlinear function, a sigmoid function, attention weights, or a learned enhancement function; The piecewise enhancement function is expressed as follows: ； In the formula, , This is the threshold for the strength of edge-level anomalous evidence, used to distinguish between weak, moderate, and strong anomalous evidence. , , These are enhancement coefficients corresponding to different anomaly evidence strength intervals, used to control the enhancement magnitude of the edge weights for weak, moderate, and strong anomalies, respectively. ; For service call edges, edge-level anomaly evidence is calculated by fusing call chain anomaly evidence and log anomaly evidence related to the call relationship. For PROVIDES edges and DEPLOYED_IN edges, vertical propagation enhancement is performed based on instance-level or node-level anomaly evidence. S5. Using the node-level anomaly evidence as the initial root cause distribution, perform graph propagation on the evidence-enhanced multi-layer heterogeneous topology graph to obtain the root cause score of each candidate node and generate a candidate root cause ranking. S6. Select Top-K candidate root causes from the candidate root cause ranking, organize the Top-K candidate root causes, corresponding indicator anomaly summaries, log anomaly summaries, call chain anomaly summaries, and local topology subgraphs into structured prompt information, input it into a large language model for topology-constrained auxiliary reasoning, and output the final root cause localization result; In the Kubernetes microservice system, the running instance node includes Pod, the running environment node includes Node, the PROVIDES edge includes the service provision relationship between Pod and Service, and the DEPLOYED_IN edge includes the deployment relationship between Pod and Node.

2. The microservice root cause localization method based on the fusion of anomaly evidence and heterogeneous topology graphs according to claim 1, characterized in that, In step S1, the service node is used to represent a business service or service entry point in the microservice system, the running instance node is used to represent a running copy that carries service capabilities, and the running environment node is used to represent the host machine, virtual machine, physical machine, cluster node, or basic running environment that carries the running instance. The multi-layer heterogeneous topology graph also includes external resource nodes and DEPENDS_ON edges representing service dependencies on external resources. The external resource nodes are used to represent databases, middleware, caches, registry centers, message queues, or external interfaces. The multi-layer heterogeneous topology graph is dynamically updated according to the fault time window: for events such as restarting, scaling up or down, migration, rescheduling, or service instance change that occur within the fault time window, a topology snapshot of the corresponding time slice is generated according to the event occurrence time, or valid time attributes are attached to nodes and edges; during graph propagation, the topology snapshots before, during, or after the fault are selected for analysis, or propagation is performed on multiple time slice topology sequences.

3. The microservice root cause localization method based on the fusion of anomaly evidence and heterogeneous topology graphs according to claim 1, characterized in that, In step S2, the metric data includes CPU, memory, disk, network, request latency, error rate, and throughput at the service level, runtime instance level, or runtime environment level. The log data includes runtime logs, exception logs, log templates, log levels, and log occurrence counts output by each service or Pod. The call chain data includes the caller, callee, call duration, call status code, call error information, and number of abnormal calls. The system metadata includes service name, runtime instance name, runtime environment name, deployment relationship, tag information, and service selector. The segmentation, aggregation, and time alignment according to the fault time window include: Define the fault analysis window and perform windowing processing on the records whose timestamps fall within the fault analysis window from the indicator data, log data, and call chain data. Window-level aggregation is performed on each modality of data: indicator data is aggregated into KPI time series by entity type, entity identifier, and KPI name; log data is aggregated into log anomaly summary by log source entity, log template, and anomaly keywords; and call chain data is aggregated into call chain anomaly summary by caller and callee. The aggregated index anomaly intensity, log anomaly summary, and call chain anomaly summary are uniformly mapped to nodes or edges in a multi-layered heterogeneous topology graph according to entity identifiers and topological relationships, forming node-level anomaly evidence and edge-level propagation evidence under the same fault analysis window.

4. The microservice root cause localization method based on the fusion of anomaly evidence and heterogeneous topology graphs according to claim 1, characterized in that, In step S3, anomaly evidence extraction is performed on the multimodal observation data, and the anomaly evidence is mapped to the multi-layer heterogeneous topology graph according to the semantic position of different modal data, including: For the indicator data, anomaly detection methods are used to calculate the intensity of indicator anomalies for each entity node. Indicator anomalies are obtained through statistical thresholds, sliding windows, MAD, Isolation Forest, time series prediction residuals, deep learning anomaly detection models, or anomaly detection methods. For each entity node, the anomaly intensity of associated indicators is aggregated into node-level anomaly evidence to represent the initial degree of suspicion of the node as a root cause. For log data, abnormal log templates, error keywords, abnormal log frequency, or log semantic features are extracted to obtain log anomaly evidence; the log anomaly evidence is mapped to the service or running instance to which the log belongs, and is used to enhance the propagation edge weights related to that service or running instance; For call chain data, call chain anomalies are identified based on call time anomalies, call failure status, anomaly status codes, number of abnormal calls, or changes in call paths; the call chain anomaly evidence is mapped to service call edge CALLS to indicate the degree of risk of anomalies propagating along the call edge; Role-based modeling is performed based on the semantic position of different modal data; anomalies in metrics are prioritized as node-level anomaly evidence; anomalies in call chains are prioritized as edge-level propagation evidence; log anomalies are mapped to node-level or edge-level propagation evidence based on log source, log template semantics, and associated entities; some network-related metrics, connection-related metrics, or request-related metrics are used as edge-level propagation evidence, and some resource-related logs, crash logs, or OOM logs are used as node-level root cause evidence.

5. The microservice root cause localization method based on the fusion of anomaly evidence and heterogeneous topology graphs according to claim 1, characterized in that, In step S5, a random walk model with restart is used for propagation: set up Given an initial distribution consisting of node-level anomaly evidence, then the th Round propagation is represented as: ； In the formula, For the first The root cause score distribution vector of each candidate node after round of iteration; For graph propagation iteration rounds; The restart probability is used to control the return to the initial root cause distribution during the propagation of the control graph. The proportion; The propagation matrix is ​​obtained by normalizing the edge weights after evidence enhancement. The elements in the matrix represent the probability or intensity of the anomalous score propagating along the corresponding heterogeneous edge. For the first The root cause score distribution vector of each candidate node after round of iteration; The initial root cause distribution vector is composed of node-level anomaly evidence from each node. Each element in the vector corresponds to the initial anomaly suspicion level of a candidate node within the fault analysis window. An out-degree penalty or adaptive topology correction mechanism is introduced, and the final score is adjusted by combining node out-degree, node type, strength of node's own abnormal evidence, log evidence, and call chain evidence. When there is a lack of evidence of anomalous behavior in high-connectivity nodes, reduce the artificially high scores of high-connectivity nodes caused by topological centrality. When the strength of abnormal evidence of a high-connectivity node exceeds a preset threshold, the out-degree penalty is reduced or canceled. After the graph propagation is completed, the candidate root causes are ranked according to the final scores of each node, and the Top-K candidate root causes are selected to enter the subsequent large language model-assisted reasoning stage.

6. The microservice root cause localization method based on the fusion of anomaly evidence and heterogeneous topology graphs according to claim 1, characterized in that, In step S6, the structured prompt information is organized in JSON, table or key-value pair format, including candidate node field, indicator evidence field, log evidence field, call chain evidence field, topology context field and output format constraint field; The structured prompts also include system profiles, prior knowledge from operations and maintenance experts, or output format constraints, which are used as soft constraints to assist in reasoning in large language models, but not as hard-coded rules for service names.

7. The microservice root cause localization method based on the fusion of anomaly evidence and heterogeneous topology graphs according to claim 1, characterized in that, The method also includes a confidence verification step for the output of the large language model; If the final root cause output by the large language model does not belong to the Top-K candidate set obtained by graph propagation, or if the difference between the selection result and the graph propagation score ranking exceeds a preset threshold, then a consistency check is triggered. The consistency check includes reorganizing candidate evidence, expanding the candidate set, requiring the large language model to output evidence, or marking the result as low confidence and prompting manual review.

8. A microservice root cause localization system that integrates anomalous evidence and heterogeneous topology graphs, characterized in that, This system is used to implement the microservice root cause localization method that fuses anomaly evidence and heterogeneous topology graphs as described in any one of claims 1 to 7. The system comprises: The heterogeneous topology graph construction module is used to obtain system entities, service call relationships, service provision relationships, runtime deployment relationships, and external resource dependencies in the microservice system, and construct a multi-layer heterogeneous topology graph. The multi-layer heterogeneous topology graph includes at least service nodes, runtime instance nodes, and runtime environment nodes, as well as CALLS edges representing call relationships between services, PROVIDES edges representing the ability of runtime instances to provide services, and DEPLOYED_IN edges representing the deployment of runtime instances in the runtime environment. The multimodal data acquisition and alignment module is used to collect indicator data, log data, call chain data and system metadata for the fault time window to be analyzed, and to perform segmentation, aggregation and time alignment according to the fault time window to obtain multimodal observation data under the same time window; An anomaly evidence extraction module is used to extract anomaly evidence from the multimodal observation data and map the anomaly evidence to the multi-layer heterogeneous topology graph according to the semantic position of different modal data. The anomaly evidence extraction module includes: a node-level evidence extraction unit, used to map anomalies reflecting the entity's own operational status to node-level anomaly evidence of service nodes, running instance nodes, running environment nodes, or external resource nodes; and an edge-level evidence extraction unit, used to map call chain anomalies reflecting inter-service interaction anomalies to edge-level propagation evidence on CALLS edges, and to map log anomalies to node-level anomaly evidence or edge-level propagation evidence according to log source, log template semantics, and associated entities. The evidence-enhancing edge weight modeling module is used to set structural prior weights according to the edge type in the multi-layer heterogeneous topology graph, and to enhance the propagation weights of the corresponding edges by combining log anomaly evidence, call chain anomaly evidence or edge-level propagation evidence mapped to the edges, so as to obtain the evidence-enhanced propagation matrix. The graph propagation root cause ranking module is used to perform graph propagation on the evidence-enhanced multi-layer heterogeneous topology graph using the node-level anomaly evidence as the initial root cause distribution, to obtain the root cause score of each candidate node, and to generate a candidate root cause ranking. The candidate root cause filtering module is used to select Top-K candidate root causes from the candidate root cause ranking, and organize the Top-K candidate root causes, the corresponding indicator anomaly summary, log anomaly summary, call chain anomaly summary, and local topology subgraph into structured prompt information; The large language model-assisted reasoning module is used to input the structured prompt information into the large language model, perform topologically constrained assisted reasoning, and output the final root cause localization result. The results output module is used to output the final root cause localization results, candidate root cause ranking, relevant abnormal evidence and reasoning explanation information, and generate alarm summaries or maintenance work orders.

Images