Fault diagnosis method and device, storage medium, equipment and program product

Abstract

The invention discloses a fault diagnosis method and device, a storage medium, equipment and a program product, and the method comprises the steps: constructing a component dependency relationship graph of a to-be-diagnosed system, the component dependency relationship graph being used for representing a calling relationship and / or a data interaction relationship between components of the to-be-diagnosed system; collecting real-time operation data of the to-be-diagnosed system, and generating a composite abnormal event containing context information according to the real-time operation data; a target fault entry matched with the composite abnormal event is determined, and the target fault entry comprises a target fault mode and a fault root cause and a repair strategy associated with the target fault mode; and performing inference analysis based on the component dependency graph, the real-time operation data, the composite abnormal event and the target fault entry by using the fault diagnosis model to generate a fault diagnosis report. According to the scheme provided by the invention, automatic fault diagnosis is realized, and the troubleshooting efficiency and accuracy of a complex software system are effectively improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a fault diagnosis method, apparatus, storage medium, device, and program product. Background Technology

[0002] With the rapid development of internet technology, the architecture of modern software systems is becoming increasingly complex. Microservices, distributed deployment, and multi-node collaborative operation have become the mainstream architectural patterns. These systems typically contain numerous business modules, with long service call chains and intricate dependencies between components.

[0003] In system operation and troubleshooting in related technologies, monitoring systems (such as Prometheus and Zabbix) are typically used to collect system infrastructure metrics or application operation logs. When a system failure occurs, the process often involves the monitoring system triggering discrete alarm messages based on preset thresholds, and then operations personnel manually locating the source of the fault upon receiving the alarms. This fault diagnosis method, which heavily relies on human experience, is inefficient and time-consuming, and cannot meet the requirements of high-availability systems for rapid fault recovery. Summary of the Invention

[0004] This application provides a fault diagnosis method, apparatus, storage medium, device, and program product. By constructing a dependency graph representing the topological relationship of components, and using composite abnormal events generated based on real-time operating data and matching historical fault knowledge entries as context, the fault diagnosis model is used for multi-dimensional reasoning analysis. This achieves automated fault diagnosis that integrates the entire link topology, real-time status, and historical experience, effectively improving the efficiency and accuracy of fault diagnosis in complex software systems.

[0005] On one hand, embodiments of this application provide a fault diagnosis method, the method comprising: Construct a component dependency graph of the system to be diagnosed, wherein the component dependency graph is used to characterize the calling relationship and / or data interaction relationship between the components of the system to be diagnosed; Collect real-time operating data of the system to be diagnosed, and generate a composite abnormal event containing contextual information based on the real-time operating data; Identify target fault entries that match the composite anomaly event, wherein the target fault entry includes a target fault mode and a fault root cause and remediation strategy associated with the target fault mode; The fault diagnosis model is used to perform reasoning analysis based on the component dependency graph, the real-time operation data, the composite abnormal events, and the target fault items to generate a fault diagnosis report.

[0006] On the other hand, embodiments of this application provide a fault diagnosis device, the device comprising: A construction unit is used to construct a component dependency graph of the system to be diagnosed, wherein the component dependency graph is used to characterize the calling relationship and / or data interaction relationship between the components of the system to be diagnosed; The acquisition unit is used to acquire real-time operating data of the system to be diagnosed, and generate composite abnormal events containing context information based on the real-time operating data. A determining unit is configured to determine a target fault entry that matches the composite abnormal event, wherein the target fault entry includes a target fault mode and a fault root cause and a remediation strategy associated with the target fault mode; The generation unit is used to generate a fault diagnosis report by performing reasoning analysis based on the component dependency graph, the real-time running data, the composite abnormal events, and the target fault entries using the fault diagnosis model.

[0007] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program adapted for loading by a processor to execute the fault diagnosis method as described in any of the above embodiments.

[0008] On the other hand, embodiments of this application provide a computer device, the computer device including a processor and a memory, the memory storing a computer program, and the processor executing the fault diagnosis method as described in any of the above embodiments by calling the computer program stored in the memory.

[0009] On the other hand, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the fault diagnosis method as described in any of the above embodiments.

[0010] This application provides a method for constructing a component dependency graph of a system to be diagnosed. The component dependency graph represents the calling relationships and / or data interaction relationships between the components of the system. Real-time operational data of the system to be diagnosed is collected, and composite anomaly events containing contextual information are generated based on the real-time operational data. Target fault entries matching the composite anomaly events are determined, whereby the target fault entries include target fault modes, associated root causes, and remediation strategies. A fault diagnosis report is generated by using a fault diagnosis model to perform reasoning analysis based on the component dependency graph, real-time operational data, composite anomaly events, and target fault entries. This method constructs a graph representing the calling and data interaction relationships between components. The component dependency graph of the system provides a global topological structure foundation for fault analysis. Based on this, the method transforms the collected real-time runtime data into composite abnormal events with contextual information, and combines them with the matched target fault entries containing fault modes, root causes, and repair strategies. This enables the fault diagnosis model to comprehensively utilize the system's static dependencies, current dynamic abnormal characteristics, and historically accumulated fault knowledge for multi-dimensional reasoning analysis. This reasoning mechanism, which integrates graph correlation, real-time contextual information, and historical prior knowledge, can effectively improve the depth and breadth of fault analysis, thereby automatically generating fault diagnosis reports containing accurate root cause location and corresponding repair strategies, realizing intelligent diagnosis of software system faults. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating the fault diagnosis method provided in an embodiment of this application.

[0013] Figure 2 This is a schematic diagram of a first application scenario of the fault diagnosis method provided in the embodiments of this application.

[0014] Figure 3 This is a schematic diagram of a second application scenario for the fault diagnosis method provided in the embodiments of this application.

[0015] Figure 4 This is a schematic diagram of a third application scenario for the fault diagnosis method provided in the embodiments of this application.

[0016] Figure 5 This is a schematic diagram of the fault diagnosis device provided in the embodiments of this application.

[0017] Figure 6 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0019] This application provides a fault diagnosis method, apparatus, storage medium, device, and program product. Specifically, the fault diagnosis method of this application can be executed by a computer device, which can be a terminal or a server. The terminal can be a smartphone, tablet, laptop, smart TV, wearable smart device, smart vehicle terminal, etc. The terminal can also include a client, which can be a browser client, an operation and maintenance management platform client, an instant messaging client, or a visual monitoring client. The server can be an independent physical server, a server cluster composed of multiple physical servers, or a distributed system. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0020] Please see Figures 1 to 4 , Figure 1 This is a flowchart illustrating the fault diagnosis method provided in an embodiment of this application. Figures 2 to 4 These are all schematic diagrams illustrating application scenarios of the fault diagnosis method provided in the embodiments of this application. It should be noted that the steps shown may be executed in a logical order different from that shown in the flowchart. The method may include the following steps: Step 110: Construct a component dependency graph of the system to be diagnosed, wherein the component dependency graph is used to characterize the calling relationship and / or data interaction relationship between the components of the system to be diagnosed.

[0021] Among them, components refer to the smallest independently manageable or operational functional units that constitute the system to be diagnosed, including but not limited to computing nodes, storage nodes, network transmission nodes, and various middleware services, such as gateway services, business microservices, database instances, caching middleware, message queues, load balancers, and storage systems.

[0022] A component dependency graph is a topological data structure used to describe the relationship between components in a system to be diagnosed. It is usually represented as a directed graph, where nodes represent components and edges represent dependencies between components. Dependencies can include multiple dimensions such as service calls, data access, message passing, and network connectivity.

[0023] In one specific embodiment provided in this application, the component dependency graph can be a comprehensive view that includes inter-service HTTP / gRPC remote call links, database read / write connection relationships, message queue production / consumption topology, and network partition deployment relationships.

[0024] In some embodiments, constructing a component dependency graph of the system to be diagnosed includes the following steps 111 to 112: Step 111: Parse the metadata of the service registry and / or configuration management center of the system to be diagnosed to obtain the service registration information of each component of the system to be diagnosed and / or the call chain data between components.

[0025] A service registry is a directory service system used in a system to be diagnosed to dynamically maintain the network addresses and status information of service instances. It is responsible for receiving registration, heartbeat keep-alive, and deregistration requests for service instances and providing clients with a query function for the list of available services, such as Eureka and Kubernetes Service Registry.

[0026] A configuration management center refers to a storage and distribution system used for centralized management, version control, and dynamic push of application configuration information in a system to be diagnosed. Examples include Nacos and Consul.

[0027] Specifically, in step 111, the service registration information and call chain data of each component are automatically extracted by connecting to the API interface or metadata interface of the service registry and / or configuration management center. This approach utilizes the metadata of the existing infrastructure, avoiding the high cost and high error rate of manually drawing topology diagrams.

[0028] Service registration information includes, for example, the service name, IP address, port number, and instance ID. Call chain data includes, for example, the defined RPC interface, the subscribed message topic, and the configured database connection string.

[0029] Step 112: Construct a component dependency graph based on service registration information and / or call chain data.

[0030] After obtaining service registration information and / or call chain data, the discrete information is integrated into a connected graph to obtain a component dependency graph.

[0031] Specifically, the construction process includes: creating corresponding component nodes in the graph based on service registration information; and parsing the dependency directions and types between components based on call chain data. For example, if component A configures the RPC interface address of component B, an RPC call edge from A to B is established; if component C subscribes to a topic published by component D, an information consumption edge from D to C is established. Then, network area deployment relationships (such as availability zones and data centers) are injected into the graph as attributes of nodes or edges.

[0032] Because the system to be diagnosed is constantly changing, a static component dependency graph cannot reflect the real-time state; therefore, a dynamic update mechanism is needed. In some embodiments, the method further includes: Detect change events of the system to be diagnosed. Change events include at least one of the following: component launch event, configuration update event, and component decommissioning event. In response to the detection of a change event, the component dependency graph is updated.

[0033] Change events of a system to be diagnosed refer to state transitions that occur during the system's operational lifecycle, altering its topology or configuration attributes.

[0034] In some embodiments, updating the component dependency graph includes incrementally updating the component dependency graph. This means that only the affected local nodes and edges need to be updated, without rebuilding the entire graph, thus ensuring that the topology always reflects the true operating state of the system with low latency and solving the problem of delayed perception of topology changes.

[0035] Step 120: Collect real-time operating data of the system to be diagnosed, and generate a composite abnormal event containing contextual information based on the real-time operating data.

[0036] This step establishes a unified data access layer to aggregate multi-source heterogeneous monitoring data and transform it into logically related composite events, providing high-quality input for subsequent large-scale model inference.

[0037] Real-time operational data refers to a collection of digital records that reflect the instantaneous state or state change process of the system under diagnosis during operation.

[0038] Specifically, it can integrate multiple monitoring systems (such as Prometheus, Zabbix, ELK, SkyWalking, etc.) through the adapter mode, and can also clean and normalize the collected raw real-time running data to solve the problem of inconsistent data formats among various monitoring systems.

[0039] In some embodiments, real-time runtime data includes at least one of infrastructure metrics, application-layer metrics, log data, and distributed tracing data.

[0040] Among them, infrastructure metrics are used to measure the utilization of hardware and operating system resources that support the operation of the system under diagnosis, such as CPU utilization, memory utilization, disk I / O throughput, network latency, and packet loss rate; application layer metrics are used to measure the processing capacity and service quality of business services, such as request latency P99, error rate, queries per second, and thread pool blocking status; log data refers to text information generated by the system during operation that records specific events or states, such as exception stack information and specific error keyword matching (such as Timeout, Connection Refused); distributed tracing data is used to record the trajectory of requests across multiple service nodes in a distributed system, such as Span exception status and Trace success rate decline trend.

[0041] In some embodiments, generating a composite exception event containing context information based on real-time runtime data includes: Anomaly analysis is performed on real-time operational data to obtain multiple discrete raw alarm messages; Based on the contextual relationships of multiple original alarm messages, the original alarm messages are aggregated and deduplicated to generate composite abnormal events.

[0042] Raw alarm information refers to the initial abnormal notification triggered for a single data source based on a preset threshold or statistical model. It is usually isolated and lacks a global perspective.

[0043] Composite anomalies refer to high-dimensional data objects that have undergone structured processing and describe system-level failure phenomena. They not only contain anomaly indicators but also aggregate relevant contextual information, such as concurrent anomalies within a time window and the affected topology locations.

[0044] The contextual relevance of raw alarm information includes temporal synchronization (e.g., occurring at the same time), topological proximity (e.g., occurring on interdependent components), and causal probability. Through aggregation and deduplication, redundant alarms caused by network jitter are filtered out, and multiple related alarm messages are merged. For example, multiple HTTP error alarms and gateway failure alarms received within a short period can be merged into a single composite anomaly event, accompanied by a relevant topology snapshot. This processing method provides high-quality input for subsequent analysis.

[0045] Specifically, a joint analysis mechanism based on rule engines and graph algorithms can be used to identify the contextual relationships between multiple original alarm messages.

[0046] Step 130: Determine the target fault entry that matches the composite abnormal event, wherein the target fault entry includes the target fault mode and the root cause and remediation strategy associated with the target fault mode.

[0047] Specifically, target fault entries (or historical similar cases) that match the composite anomaly events are identified. Target fault entries include target fault modes and the root causes and remediation strategies associated with the target fault modes.

[0048] In some embodiments, determining a target fault entry that matches a composite abnormal event includes the following steps 131 to 133: Step 131: Extract the abnormal feature vector of the composite abnormal event. The abnormal feature vector includes at least one of the following: indicator fluctuation pattern, log keyword combination, and call chain abnormal features.

[0049] The indicator fluctuation pattern refers to the change pattern of the monitored indicator over time, such as a sudden increase in CPU utilization, a step-like increase in memory leaks, or a periodic drop in network traffic.

[0050] Log keyword combinations refer to a set of words with significant distinguishability extracted from log text, such as combinations of "Deadlock" and "Timeout" with specific service names.

[0051] Call chain anomaly characteristics refer to the status indicators of a Span in a distributed chain, such as a surge in latency or error code distribution for a specific interface.

[0052] These multi-dimensional features are mapped into a high-dimensional anomalous feature vector.

[0053] Step 132: Retrieve target fault modes in the anomaly knowledge base that meet the preset conditions for similarity with the anomaly feature vector. The anomaly knowledge base is constructed based on the historical fault information of the system to be diagnosed. The anomaly knowledge base includes multiple fault entries, and each fault entry includes a fault mode and the root cause and repair strategy associated with the fault mode.

[0054] An anomaly knowledge base is a structured collection of knowledge used to support intelligent decision-making in fault diagnosis. It records historical fault cases and expert experience accumulated during the past operation of the system to be diagnosed. Specifically, the anomaly knowledge base stores multiple fault entries. Each fault entry is a complete knowledge unit, containing the following three parts: Fault mode refers to the typical manifestation of a fault on the system interface, which is a combination of the above-mentioned indicators, logs and link characteristics, used to describe "what happened"; The root cause of a failure refers to the underlying reason that causes the failure mode to occur, such as "the database connection pool is configured too small" or "a microservice code has an infinite loop", which describes "why it happened"; The remediation strategy refers to the set of recommended operations to resolve the fault, such as "expanding the instance" or "rolling back the version", which describes "how to resolve".

[0055] The preset conditions can be, for example, the fault mode with the highest similarity to the abnormal feature vector in the abnormal knowledge base, or the fault mode with a similarity exceeding a preset similarity threshold.

[0056] Step 133: Determine the fault entry corresponding to the target fault mode as the target fault entry.

[0057] To ensure the timeliness and accuracy of the anomaly knowledge base, this application also provides an adaptive update mechanism for the anomaly knowledge base.

[0058] In some embodiments, after generating a fault diagnosis report, the method further includes: Obtain feedback results for this fault diagnosis, including verified root causes and remediation strategies. Characteristic abstraction is performed on complex abnormal events to generate new failure modes; The new failure modes are associated with the validated root causes and remediation strategies in the feedback results to construct new failure entries; Store new fault entries in the anomaly knowledge base.

[0059] In this embodiment, whenever a new fault is successfully handled, the anomaly characteristics, the finally confirmed root cause of the fault, and the effective repair methods are automatically saved to the anomaly knowledge base. Through this feedback loop, the anomaly knowledge base can continuously accumulate intelligent assets as the system operates, and continuously improve its ability to identify unknown faults.

[0060] Step 140: Use the fault diagnosis model to perform reasoning analysis based on the component dependency graph, real-time running data, composite abnormal events and target fault items to generate a fault diagnosis report.

[0061] In step 140, the aim is to utilize the reasoning capabilities of the artificial intelligence model, combined with the static topology and dynamic operating status of the system, to achieve automated fault root cause localization and analysis.

[0062] In this context, a fault diagnosis model refers to a pre-trained artificial intelligence neural network model with contextual understanding and causal reasoning capabilities. For example, this fault diagnosis model can be built on the Transformer architecture, fine-tuned for the IT operations and maintenance (AIOps) domain, and integrate the graph data processing capabilities of a Graph Neural Network (GNN). Specifically, this fault diagnosis model can be a Large Language Model (LLM) integrating a graph attention mechanism, or a dedicated deep learning model trained for a specific operations and maintenance scenario.

[0063] In some embodiments, a fault diagnosis report is generated by using a fault diagnosis model to perform inference analysis based on component dependency graphs, complex abnormal events, real-time operational data, and target fault entries, including the following steps 141 to 143: Step 141: Input the component dependency graph, composite abnormal events, real-time running data and target fault entries as contextual prompts into the fault diagnosis model.

[0064] In order for the fault diagnosis model to handle multi-source heterogeneous data, it is necessary to perform data vectorization and serialization processing and build a context prompt.

[0065] Specifically, the component dependency graph is converted into an adjacency matrix or graph embedding vector to preserve topological information; composite abnormal events and real-time operational data are serialized into temporal feature vectors or descriptive text; and prior knowledge from target fault entries is extracted as key features. These data collectively constitute the input space, guiding the fault diagnosis model to reason within the specific fault context.

[0066] Step 142: By combining the fault diagnosis model with the reasoning mechanism of the graph neural network, the root cause component that leads to the compound abnormal event is identified in the component dependency graph.

[0067] A root cause component is the initial functional unit or node that triggers a chain of failures. For example, a root cause component can be a service instance at the application layer, a physical node at the infrastructure layer, or a management item at the configuration layer. More specifically, root cause components may include a database instance that has run out of connections, a microservice container that experiences a memory overflow, or a gateway node configured with incorrect routing rules.

[0068] Specifically, the fault diagnosis model uses graph neural networks to perform reverse source analysis on the component dependency graph. Combining the historical root cause patterns provided by the target fault entries, it calculates the conditional probability of each component causing the composite abnormal event in the nodes of the graph, and identifies the node with the highest probability as the root cause component.

[0069] Step 143: Generate a fault diagnosis report based on the root cause components, the root causes of the faults in the target fault entries, and the remediation strategies.

[0070] A fault diagnosis report is a report that includes fault analysis conclusions and handling solutions. For example, a fault diagnosis report may include the basis for judgment, root cause location information, and repair suggestions. More specifically, a fault diagnosis report includes: the matching degree score between the abnormal behavior and the knowledge base (basis for judgment), the name and IP address of the root cause component (root cause location), and specific operating instructions (repair suggestions).

[0071] In some embodiments, the method further includes: By using a fault diagnosis model based on a component dependency graph, a fault impact propagation simulation is performed starting from the root cause component to obtain the propagation simulation results; Based on the propagation simulation results, first-level components that have a direct dependency on root cause components and second-level components that are indirectly dependent on root cause components through first-level components are identified. A list of affected areas is determined based on the first-level and second-level components.

[0072] This embodiment quantifies the global impact of a fault on the system under diagnosis by simulating the fault propagation process. Specifically, the model starts with the root cause component and traverses the dependency edges of the component dependency graph (i.e., the opposite direction of the call direction). It identifies the first-level components that directly call the root cause component, as well as the second-level components that call the first-level components, and aggregates these components to generate an impact scope list. This impact scope list is used to assess the affected service scope and potential business losses.

[0073] Among them, fault propagation simulation refers to a computational analysis method that predicts the transmission and diffusion of fault states among components based on component dependency graphs. For example, this fault propagation simulation includes dependency propagation analysis based on deterministic rules and cascading failure prediction based on probabilistic graphical models. More specifically, for example, simulating a core database outage and calculating how the resulting read / write failure states propagate along the call chain to upstream business services and the front-end user interface.

[0074] In some embodiments, the fault diagnosis report includes at least one repair suggestion, and the method further includes: Rank at least one remediation suggestion based on at least one of the following: operational complexity, risk level, and business priority. Execute at least one repair instruction corresponding to a repair suggestion based on the sorting results.

[0075] The repair recommendations refer to specific operational plans used to eliminate the root cause of the failure and restore the system to normal operation. For example, repair recommendations include resource adjustment operations, service lifecycle management operations, and configuration change operations. More specifically, repair recommendations may include "restarting the service instance," "expanding the database connection pool," "rolling back the configuration version," or "enabling the circuit breaker mechanism."

[0076] Operational complexity refers to the time and computing resources required to perform the repair; risk level refers to the probability that the repair operation may cause data loss or secondary failure; business priority refers to the importance of the affected business in the system.

[0077] In some embodiments, low-risk, high-priority repair instructions are executed first, or high-risk instructions are pushed to manual review, thereby improving the system's self-healing capability while ensuring security.

[0078] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0079] This application provides a method for constructing a component dependency graph of a system to be diagnosed. The component dependency graph represents the calling relationships and / or data interaction relationships between the components of the system. Real-time operational data of the system to be diagnosed is collected, and composite anomaly events containing contextual information are generated based on the real-time operational data. Target fault entries matching the composite anomaly events are determined, whereby the target fault entries include target fault modes, associated root causes, and remediation strategies. A fault diagnosis report is generated by using a fault diagnosis model to perform reasoning analysis based on the component dependency graph, real-time operational data, composite anomaly events, and target fault entries. This method constructs a graph representing the calling and data interaction relationships between components. The component dependency graph of the system provides a global topological structure foundation for fault analysis. Based on this, the method transforms the collected real-time runtime data into composite abnormal events with contextual information, and combines them with the matched target fault entries containing fault modes, root causes, and repair strategies. This enables the fault diagnosis model to comprehensively utilize the system's static dependencies, current dynamic abnormal characteristics, and historically accumulated fault knowledge for multi-dimensional reasoning analysis. This reasoning mechanism, which integrates graph correlation, real-time contextual information, and historical prior knowledge, can effectively improve the depth and breadth of fault analysis, thereby automatically generating fault diagnosis reports containing accurate root cause location and corresponding repair strategies, realizing intelligent diagnosis of software system faults.

[0080] To facilitate better implementation of the fault diagnosis method of this application, this application also provides a fault diagnosis system. The fault diagnosis system can execute the fault diagnosis method provided in this application. The system includes: a component dependency acquisition module, a multi-source monitoring data aggregation and processing module, an anomaly knowledge base management module, a fault diagnosis inference engine, and an interaction and execution module. Wherein: The component dependency acquisition module is used to construct a component dependency graph of the system to be diagnosed. This graph represents the call relationships and / or data interaction relationships between the components of the system (such as microservices, databases, message queues, etc.). Specifically, the module is configured to act as the configuration management center and service registry of the system to be diagnosed. Configuration management centers include, for example, Nacos and Consul; service registries include, for example, Eureka and Kubernetes Service Registry. By parsing the metadata provided by these centers, the module automatically extracts the registration information of each component and the call chain data between components. Registration information includes, for example, IP address, port, and service name; call chain data includes, for example, HTTP / gRPC call relationships, database read / write dependencies, and message queue producer-consumer topology. The module also has a change monitoring mechanism. When a change event is detected in the system to be diagnosed (e.g., component deployment, configuration update, or component decommissioning), an incremental update of the component dependency graph is automatically triggered to ensure that the topology of the component dependency graph always reflects the real-time operating status of the system to be diagnosed.

[0081] The multi-source monitoring data aggregation and processing module is used to collect real-time operational data from the system under diagnosis and generate composite anomaly events containing contextual information. Specifically, this module integrates data interfaces from various monitoring systems (such as Prometheus, Zabbix, ELK, and SkyWalking) through an adapter pattern. The collected data types cover: infrastructure metrics, application-layer metrics, log data, and distributed tracing data. Infrastructure metrics include CPU, memory, and disk I / O; application-layer metrics include latency, error rate, and QPS; log data includes exception stack traces and keywords; and distributed tracing data includes Span anomalies and Trace status. The collected raw data is first cleaned and normalized before being stored in a central data warehouse. Subsequently, the module uses a rule engine and graph algorithms to deduplicate, perform correlation analysis, and enhance the context of multiple discrete raw alarm messages, aggregating isolated alarms into high-level composite anomaly events.

[0082] The anomaly knowledge base management module is used to build, maintain, and retrieve anomaly knowledge bases, providing prior knowledge support for fault diagnosis. Specifically, the anomaly knowledge base stores multiple structured fault entries. Each entry includes, for example, a fault mode, root cause, propagation path, scope of impact, and recommended remediation strategies. Fault modes may include, for example, specific metric fluctuation combinations. When a complex anomaly event is generated, the anomaly knowledge base management module is configured to extract the anomaly feature vector of the complex anomaly event and retrieve target fault entries in the anomaly knowledge base that meet preset similarity criteria. Anomaly feature vectors may include, for example, metric fluctuation patterns and log keyword combinations. Furthermore, the anomaly knowledge base management module supports a feedback loop mechanism. Specifically, after fault handling is completed, the module obtains the verified root cause and remediation strategy, performs feature abstraction on the complex anomaly event, generates new fault entries, and stores them in the anomaly knowledge base, using machine learning algorithms to achieve continuous evolution of the knowledge base.

[0083] The fault diagnosis inference engine is the core decision-making unit of this system, embedding a fault diagnosis model. Specifically, the fault diagnosis model is a large model with strong reasoning capabilities. The fault diagnosis inference engine is configured to input the component dependency graph, real-time generated composite anomaly events, real-time runtime data, and retrieved target fault entries as contextual prompts. This model, combined with the reasoning mechanism of graph neural networks, performs causal inference within the complex component dependency graph, accurately identifying the root cause component leading to the composite anomaly event. Based on the located root cause component, the model also performs fault impact propagation simulation on the component dependency graph, identifying directly dependent first-level components and indirectly dependent second-level components, thereby determining a complete list of impact scopes. Finally, the fault diagnosis inference engine generates a fault diagnosis report containing the judgment criteria, root cause location, impact scope, and remediation suggestions.

[0084] The interaction and execution module is used to display diagnostic results to users or automatically execute repair operations. Specifically, the fault diagnosis report contains at least one repair suggestion, and the interaction and execution module is configured to sort the at least one repair suggestion based on at least one of the following: operational complexity, risk level, and business priority. Diagnostic results can be displayed through a visual console or pushed to operations and maintenance personnel via message notifications, such as email and Enterprise Instant Messaging (EIM). In fully automated mode, the interaction and execution module can interface with an automated operations and maintenance platform to directly execute repair instructions based on the sorting results. Repair instructions include, for example, restarting services, enabling circuit breakers, and scaling up instances.

[0085] To facilitate better implementation of the fault diagnosis method of this application, this application also provides a fault diagnosis device. Please refer to... Figure 5 , Figure 5 This is a schematic diagram of the fault diagnosis device provided in an embodiment of this application. The fault diagnosis device 200 may include: The construction unit 210 is used to construct a component dependency graph of the system to be diagnosed, wherein the component dependency graph is used to characterize the calling relationship and / or data interaction relationship between the components of the system to be diagnosed; The acquisition unit 220 is used to acquire real-time operating data of the system to be diagnosed and generate composite abnormal events containing context information based on the real-time operating data. The determining unit 230 is used to determine the target fault entry that matches the composite abnormal event, wherein the target fault entry includes the target fault mode and the root cause and repair strategy associated with the target fault mode; The generation unit 240 is used to generate a fault diagnosis report by performing reasoning analysis based on the component dependency graph, real-time running data, composite abnormal events and target fault entries using the fault diagnosis model. In some embodiments, when constructing a component dependency graph of the system to be diagnosed, the apparatus is specifically used for: Parse the metadata of the service registry and / or configuration management center of the system to be diagnosed to obtain the service registration information of each component of the system to be diagnosed and / or the call chain data between components. Construct a component dependency graph based on service registration information and / or call chain data.

[0086] In some embodiments, the device is further configured to: Detect change events of the system to be diagnosed. Change events include at least one of the following: component launch event, configuration update event, and component decommissioning event. In response to the detection of a change event, the component dependency graph is updated.

[0087] In some embodiments, real-time runtime data includes at least one of infrastructure metrics, application-layer metrics, log data, and distributed tracing data.

[0088] In some embodiments, when the apparatus generates a composite exception event containing context information based on real-time runtime data, it is specifically used for: Anomaly analysis is performed on real-time operational data to obtain multiple discrete raw alarm messages; Based on the contextual relationships of multiple original alarm messages, the original alarm messages are aggregated and deduplicated to generate composite abnormal events.

[0089] In some embodiments, when determining a target fault entry that matches a composite abnormal event, the apparatus specifically uses: Extract the abnormal feature vector of the composite abnormal event. The abnormal feature vector includes at least one of the following: indicator fluctuation pattern, log keyword combination, and call chain abnormal features. Retrieve target fault modes that meet preset conditions in the anomaly knowledge base with similarity to the anomaly feature vector. The anomaly knowledge base is constructed based on the historical fault information of the system to be diagnosed. The anomaly knowledge base includes multiple fault entries, and each fault entry includes a fault mode, the root cause of the fault associated with the fault mode, and the repair strategy. The fault entries corresponding to the target fault mode are identified as the target fault entries.

[0090] In some embodiments, after generating a fault diagnosis report, the apparatus is further configured to: Obtain feedback results for this fault diagnosis, including verified root causes and remediation strategies. Characteristic abstraction is performed on complex abnormal events to generate new failure modes; The new failure modes are associated with the validated root causes and remediation strategies in the feedback results to construct new failure entries; Store new fault entries in the anomaly knowledge base.

[0091] In some embodiments, when the device generates a fault diagnosis report by performing reasoning analysis based on a component dependency graph, composite abnormal events, real-time operational data, and target fault entries using a fault diagnosis model, it is specifically used for: Use the component dependency graph, composite abnormal events, real-time runtime data, and target fault entries as contextual prompts to input into the fault diagnosis model; By combining a fault diagnosis model with the reasoning mechanism of a graph neural network, the root cause components leading to complex abnormal events are identified in the component dependency graph. A fault diagnosis report is generated based on the root cause components, the root causes of the faults in the target fault entries, and the remediation strategies.

[0092] In some embodiments, the device is further configured to: By using a fault diagnosis model based on a component dependency graph, a fault impact propagation simulation is performed starting from the root cause component to obtain the propagation simulation results; Based on the propagation simulation results, first-level components that have a direct dependency on root cause components and second-level components that are indirectly dependent on root cause components through first-level components are identified. A list of affected areas is determined based on the first-level and second-level components.

[0093] In some embodiments, the fault diagnosis report includes at least one repair suggestion, and the device is further configured to: Rank at least one remediation suggestion based on at least one of the following: operational complexity, risk level, and business priority. Execute at least one repair instruction corresponding to a repair suggestion based on the sorting results.

[0094] Each unit in the aforementioned fault diagnosis device can be implemented entirely or partially through software, hardware, or a combination thereof. These units can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each unit.

[0095] The fault diagnosis device 200 can be integrated into a terminal or server that has storage and a processor and thus computing power, or the fault diagnosis device 200 can be the terminal or server.

[0096] Optionally, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0097] Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device may include: a communication interface 301, a memory 302, a processor 303, and a communication bus 304. The communication interface 301, memory 302, and processor 303 communicate with each other via the communication bus 304. The communication interface 301 is used for data communication between the computer device and external devices. The memory 302 can be used to store software programs and modules, and the processor 303 runs the software programs and modules stored in the memory 302, such as the software programs for corresponding operations in the aforementioned method embodiments.

[0098] In some embodiments, the processor 303 may invoke software programs and modules stored in the memory 302 to perform the following operations: constructing a component dependency graph of the system to be diagnosed, wherein the component dependency graph is used to characterize the calling relationships and / or data interaction relationships between the components of the system to be diagnosed; collecting real-time operating data of the system to be diagnosed, and generating composite abnormal events containing contextual information based on the real-time operating data; determining target fault entries that match the composite abnormal events, wherein the target fault entries include target fault modes and the root causes and repair strategies associated with the target fault modes; and using a fault diagnosis model to perform reasoning analysis based on the component dependency graph, real-time operating data, composite abnormal events, and target fault entries to generate a fault diagnosis report.

[0099] In some embodiments, the computer device 300 may be integrated into a terminal or server that has storage and a processor, thus possessing computing capabilities; or the computer device 300 may be the terminal or server. The terminal may be a smartphone, tablet, laptop, smart TV, smart speaker, wearable smart device, personal computer, or other similar device. The server may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0100] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to a computer device, and the computer program causes the computer device to execute the corresponding processes in the fault diagnosis method of the embodiments of this application; for the sake of brevity, further details are omitted here.

[0101] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process in the fault diagnosis method described in the embodiments of this application. For simplicity, further details are omitted here.

[0102] This application also provides a computer program comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process in the fault diagnosis method of this application. For brevity, further details are omitted here.

[0103] It should be understood that the processor in this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0104] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0105] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0106] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0107] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0108] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0109] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0110] In addition, the functional units in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0111] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer or a server) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0112] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A fault diagnosis method, characterized in that, The method includes: Construct a component dependency graph of the system to be diagnosed, wherein the component dependency graph is used to characterize the calling relationship and / or data interaction relationship between the components of the system to be diagnosed; Collect real-time operating data of the system to be diagnosed, and generate a composite abnormal event containing contextual information based on the real-time operating data; Identify target fault entries that match the composite anomaly event, wherein the target fault entry includes a target fault mode and a fault root cause and remediation strategy associated with the target fault mode; The fault diagnosis model is used to perform reasoning analysis based on the component dependency graph, the real-time operation data, the composite abnormal events, and the target fault items to generate a fault diagnosis report.

2. The fault diagnosis method as described in claim 1, characterized in that, The component dependency graph of the system to be diagnosed is constructed as follows: Parse the metadata of the service registry and / or configuration management center of the system to be diagnosed to obtain the service registration information of each component of the system to be diagnosed and / or the call chain data between components. Construct a component dependency graph based on the service registration information and / or the call chain data.

3. The fault diagnosis method as described in claim 2, characterized in that, The method further includes: Detect change events of the system to be diagnosed, wherein the change events include at least one of component online events, configuration update events, and component offline events; In response to the detection of the change event, the component dependency graph is updated.

4. The fault diagnosis method as described in claim 1, characterized in that, The real-time operational data includes at least one of the following: infrastructure metrics, application layer metrics, log data, and distributed tracing data.

5. The fault diagnosis method as described in claim 1, characterized in that, The generation of a composite exception event containing context information based on the real-time runtime data includes: Anomaly analysis is performed on the real-time operating data to obtain multiple discrete original alarm messages; Based on the contextual correlation of the multiple original alarm messages, the multiple original alarm messages are aggregated and deduplicated to generate the composite abnormal event.

6. The fault diagnosis method as described in claim 1, characterized in that, The determination of the target fault entry matching the composite abnormal event includes: Extract the abnormal feature vector of the composite abnormal event, wherein the abnormal feature vector includes at least one of the following: indicator fluctuation pattern, log keyword combination, and call chain abnormal features; Retrieve target fault modes that meet preset conditions in the anomaly knowledge base with similarity to the anomaly feature vector. The anomaly knowledge base is constructed based on the historical fault information of the system to be diagnosed. The anomaly knowledge base includes multiple fault entries, and each fault entry includes a fault mode and the fault root cause and repair strategy associated with the fault mode. The fault entry corresponding to the target fault mode is determined as the target fault entry.

7. A fault diagnosis device, characterized in that, The device includes: A construction unit is used to construct a component dependency graph of the system to be diagnosed, wherein the component dependency graph is used to characterize the calling relationship and / or data interaction relationship between the components of the system to be diagnosed; The acquisition unit is used to acquire real-time operating data of the system to be diagnosed, and generate composite abnormal events containing context information based on the real-time operating data. A determining unit is configured to determine a target fault entry that matches the composite abnormal event, wherein the target fault entry includes a target fault mode and a fault root cause and a remediation strategy associated with the target fault mode; The generation unit is used to generate a fault diagnosis report by performing reasoning analysis based on the component dependency graph, the real-time running data, the composite abnormal events, and the target fault entries using the fault diagnosis model.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading by a processor to perform the fault diagnosis method as described in any one of claims 1-6.

9. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program, and the processor executing the fault diagnosis method according to any one of claims 1-6 by calling the computer program stored in the memory.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the fault diagnosis method according to any one of claims 1-6.

Images