Root cause positioning method and device, equipment, medium and program product

Abstract

The invention provides a root cause positioning method which can be applied to the technical field of artificial intelligence. The root cause positioning method comprises the following steps: acquiring data in a configuration management database, a network topology tool, a monitoring system and a work order system to form a multi-source heterogeneous data set; performing knowledge extraction on the multi-source heterogeneous data set, extracting equipment attributes, network topological relations, fault event entities and timestamps, and storing the equipment attributes, the network topological relations, the fault event entities and the timestamps as structured knowledge; mapping real-time index data in the structured knowledge into dynamic attributes of an entity, and constructing a dynamic knowledge graph; based on a graph neural network and in combination with time sequence features, learning a time sequence dependency relationship and a propagation path between fault events in the dynamic knowledge graph; and outputting a root cause entity, a confidence score and a fault propagation path of the fault event through a causal inference algorithm in combination with the multi-dimensional evidence. The invention further provides a root cause positioning device and equipment, a storage medium and a program product.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of artificial intelligence, and more particularly to a root cause positioning method, device, equipment, medium and program product. BACKGROUND

[0002] With the rapid development of the digital era, data centers, as the core hub of information storage, processing and transmission, are increasing in size and complexity. Today's data centers not only carry massive data storage and processing tasks, but also support the stable operation of various critical business systems, playing a vital role in the normal operation of the economy and society. However, with the expansion of data center size and the diversification of equipment types, the operation and maintenance work is facing unprecedented challenges.

[0003] Data centers deploy a large number of complex types of equipment, including servers, storage devices, network devices, etc., which come from different manufacturers, use different technical architectures and protocols, making the operation and maintenance work extremely complex. Traditional manual operation and maintenance methods highly depend on the experience and skills of operation and maintenance personnel, not only inefficient, but also prone to human negligence or misjudgment, leading to delayed or improper handling of faults, and thus affecting the stable operation of the data center. In addition, the correlation between data center equipment is extremely strong, and a fault in one device can quickly spread to the entire system, causing multiple related devices or services to malfunction. However, due to the opacity of the fault propagation path, it is difficult for operation and maintenance personnel to quickly locate the root cause of the fault, greatly increasing the difficulty and time cost of fault handling.

[0004] At the same time, existing monitoring systems are also inadequate in dealing with the complex operation and maintenance needs of data centers. These systems mostly only monitor and alarm single indicators such as central processing unit (CPU) usage, memory occupancy, network traffic, etc., lacking cross-layer correlation analysis capabilities. In a highly complex system such as a data center, the abnormality of a single indicator often cannot directly reflect the full picture of the fault, let alone reveal the correlation and propagation path between faults. Therefore, when faced with complex faults, operation and maintenance personnel often need to spend a lot of time and effort to manually investigate and analyze, which not only reduces operation and maintenance efficiency, but also increases the risk of misjudgment and missed judgment.

[0005] In order to cope with these challenges, the industry has proposed some solutions, but these solutions still have many shortcomings in actual application. Although the alarm system based on rule engine can achieve automatic monitoring and alarm to a certain extent, due to the complexity and dynamics of the data center environment, the pre-set rules are often difficult to cover all possible fault scenarios, resulting in a high false alarm rate. In addition, the rule engine is not competent in handling complex correlation faults, and cannot accurately determine the root cause and propagation path of the fault.

[0006] On the other hand, as a powerful knowledge representation and reasoning tool, knowledge graph has certain application potential in the field of data center operation and maintenance. However, most existing knowledge graphs only statically describe the relationships between devices, such as which applications are carried by servers, the connection relationships between network devices, etc., and lack the combination of dynamic running data and fault propagation logic. This makes the application effect of knowledge graph in the fault analysis scene limited, and it is difficult to provide accurate root cause positioning and fault prediction capabilities. In addition, traditional knowledge graphs often lack an automatic updating mechanism and cannot reflect the changes in the running state of the data center in real time, further limiting their application value in operation and maintenance.

[0007] Specifically, the current technology has the following comprehensive defects: First, there is a disconnection between the static relationships in the knowledge graph and the real-time running data, which makes the graph unable to accurately reflect the real-time running state of the data center, reducing the accuracy of fault analysis. Second, the existing technology lacks automated root cause positioning capabilities, and operation and maintenance personnel still need to rely on manual troubleshooting and analysis when facing complex faults, which not only increases the operation and maintenance cost, but also reduces the efficiency and quality of fault handling. SUMMARY

[0008] In view of the above problems, the present application provides a root cause positioning method, device, equipment, medium and program product.

[0009] According to a first aspect of the present application, a root cause positioning method is provided, comprising: collecting device configuration data in a configuration management database, connection relationship data in a network topology tool, real-time index data in a monitoring system, and historical fault records and unstructured logs in a work order system to form a multi-source heterogeneous data set; performing knowledge extraction on the multi-source heterogeneous data set, extracting device attributes, network topology relationships, fault event entities and timestamps, and storing them as structured knowledge; defining entity types and relationship types of the knowledge graph, mapping the real-time index data in the structured knowledge to the dynamic attributes of the entities, and constructing a dynamic knowledge graph; learning the time sequence dependency relationship and propagation path between fault events in the dynamic knowledge graph based on a graph neural network combined with time sequence features; and based on the time sequence dependency relationship and the propagation path, outputting the root cause entity, confidence score and fault propagation path of the fault event through a causal inference algorithm combined with multi-dimensional evidence.

[0010] According to an embodiment of the present application, the knowledge extraction on the multi-source heterogeneous data set comprises: analyzing the fault description in the unstructured log through natural language processing technology to identify the fault event entity and timestamp; and extracting the device attribute, network topology relationship and fault event type based on a pre-defined rule template.

[0011] According to an embodiment of the present application, the entity types include physical devices, virtual resources and services; and the relationship types include hierarchical relationships, dependency relationships and logical connections.

[0012] According to the embodiment of the present application, the real-time index data in structured knowledge is mapped to dynamic attributes of entities, a dynamic knowledge graph is constructed, including: storing real-time index data through a time series database, converting the real-time index data into attribute values of entities in the knowledge graph according to a preset time window slicing, and marking a timestamp; in response to the real-time index data continuously exceeding a historical threshold, generating an abnormal event node and an abnormal level, and associating to a corresponding entity in the knowledge graph; using a stream processing framework to push the real-time index data to a graph engine in real time, to dynamically update the attribute values of the entities and mark the abnormal level.

[0013] According to the embodiment of the present application, based on the graph neural network combined with the time sequence characteristics, the time sequence dependency relationship and the propagation path between the fault events in the dynamic knowledge graph are learned, including: extracting fault events, repair actions and timestamps from fault tickets and logs; based on the fault events, repair actions and timestamps, establishing a propagation chain of "fault cause→affected device→final symptom"; based on the graph neural network, modeling the device topology and historical fault events in the knowledge graph, and learning the implicit propagation weight between nodes; based on the implicit propagation weight between nodes, combined with the time sequence characteristics, the time sequence dependency relationship and the propagation path of the fault events are captured.

[0014] According to the embodiment of the present application, through the causal inference algorithm combined with multi-dimensional evidence, the root cause entity, confidence score and fault propagation path of the fault event are output, including: monitoring real-time index data in real time, and identifying abnormal indicators; based on the topological connectivity state of the dynamic knowledge graph, analyzing the influence range of the abnormal indicators; combining the historical case similarity, the root cause entity, the confidence score and the fault propagation path are output through the causal inference algorithm.

[0015] According to the embodiment of the present application, further comprising: feeding back the newly occurring fault cases and repair results to the graph neural network and the causal inference algorithm, to optimize the parameters of the graph neural network.

[0016] The second aspect of the present application provides a root cause positioning device, comprising: a data acquisition module, configured to acquire device configuration data in a configuration management database, connection relationship data in a network topology tool, real-time index data in a monitoring system, and historical fault records and unstructured logs in a work order system, to form a multi-source heterogeneous data set; a knowledge extraction module, configured to perform knowledge extraction on the multi-source heterogeneous data set, extract device attributes, network topology relationships, fault event entities, and timestamps, and store them as structured knowledge; a graph construction module, configured to define entity types and relationship types of a knowledge graph, map real-time index data in the structured knowledge to dynamic attributes of entities, and construct a dynamic knowledge graph; a path learning module, configured to learn time sequence dependency relationships and propagation paths between fault events in the dynamic knowledge graph based on a graph neural network combined with time sequence features; and a fault prediction module, configured to output root cause entities, confidence scores, and fault propagation paths of the fault events based on the time sequence dependency relationships and the propagation paths, through a causal inference algorithm combined with multi-dimensional evidence.

[0017] The third aspect of the present application provides an electronic device, comprising: one or more processors; a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method.

[0018] The fourth aspect of the present application further provides a computer-readable storage medium having a computer program or instructions stored thereon, wherein the computer program or instructions are executed by a processor to implement the steps of the method.

[0019] The fifth aspect of the present application further provides a computer program product comprising a computer program or instructions, wherein the computer program or instructions are executed by a processor to implement the steps of the method. BRIEF DESCRIPTION OF DRAWINGS

[0020] The above and other objects, features and advantages of the present application will become more apparent from the following description of embodiments of the present application, taken in conjunction with the accompanying drawings, in which:

[0021] Figure 1 An application scenario diagram of a root cause positioning method, device, equipment, medium and program product according to an embodiment of the present application is schematically shown;

[0022] Figure 2 A flowchart of a root cause positioning method according to an embodiment of the present application is schematically shown;

[0023] Figure 3 A flowchart of mapping real-time index data in structured knowledge to dynamic attributes of entities, and constructing a dynamic knowledge graph according to an embodiment of the present application is schematically shown;

[0024] Figure 4 A flowchart is illustratively shown for learning the time sequence dependency relationship and propagation path between fault events in a dynamic knowledge graph based on a graph neural network combined with time sequence features according to an embodiment of the present application;

[0025] Figure 5 A flowchart is illustratively shown for outputting the root cause entity, confidence score and fault propagation path of a fault event by a causal inference algorithm combined with multi-dimensional evidence according to an embodiment of the present application;

[0026] Figure 6 A flowchart is illustratively shown for another root cause positioning method according to an embodiment of the present application;

[0027] Figure 7 A structural block diagram of a root cause positioning apparatus according to an embodiment of the present application is illustratively shown; and

[0028] Figure 8 A block diagram of an electronic device suitable for implementing the root cause positioning method according to an embodiment of the present application is illustratively shown. DETAILED DESCRIPTION

[0029] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. It should be understood, however, that the description which follows is merely illustrative and is not intended to limit the scope of the present application. In the following detailed description of embodiments of the present application, numerous specific details are set forth in order to provide a thorough understanding of the present application. However, it will be apparent to one skilled in the art that one or more embodiments of the present application can be practiced without these specific details. In other instances, well-known structures and functions have not been described in detail in order to avoid obscuring aspects of the present application.

[0030] The terms used herein are merely used to describe specific embodiments and are not intended to limit the present application. The terms "include", "comprise", and the like used herein indicate the presence of the features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0031] All terms used herein (including technical and scientific terms) have meanings commonly understood by one of ordinary skill in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having meanings consistent with the context of the present specification, and should not be interpreted in an idealized or overly formal manner.

[0032] In the case of using expressions such as "at least one of A, B, and C", it generally means all of the following: "A but not B and C; B but not A and C; C but not A and B; A and B but not C; A and C but not B; B and C but not A; A, B, and C".

[0033] Embodiments of the present application provide a root cause positioning method, comprising: collecting device configuration data in a configuration management database (CMDB), connection relationship data in a network topology tool, real-time index data in a monitoring system, and historical fault records and unstructured logs in a work order system to form a multi-source heterogeneous data set; performing knowledge extraction on the multi-source heterogeneous data set, extracting device attributes, network topology relationships, fault event entities, and timestamps, and storing them as structured knowledge; defining entity types and relationship types of a knowledge graph, mapping real-time index data in the structured knowledge to dynamic attributes of entities, and constructing a dynamic knowledge graph; learning the time sequence dependency relationship and propagation path between fault events in the dynamic knowledge graph based on a graph neural network combined with time sequence features; and based on the time sequence dependency relationship and the propagation path, outputting the root cause entity, confidence score, and fault propagation path of the fault event through a causal inference algorithm combined with multi-dimensional evidence. Through multi-data fusion knowledge graph, the data island barrier in traditional operation and maintenance is broken, and heterogeneous data scattered in CMDB, monitoring, log, and other systems is integrated into a unified knowledge carrier, and the dynamic knowledge graph is used to map the device state and fault propagation relationship in real time; combined with the topological reasoning ability of the graph neural network (GNN) and the time sequence feature modeling, the representation limitation of static rules on complex causal chains is broken, and the dynamic propagation path of fault events in a large-scale data center or a hybrid cloud environment is accurately captured. Through the global correlation of the knowledge graph and the implicit relationship mining ability of the GNN, the leap from "fragmented alarms" to "root cause path reasoning" is realized, meeting the stringent requirements of real-time, accuracy, and explainability of intelligent operation and maintenance in complex scenarios.

[0034] Figure 1 An application scenario diagram of the root cause positioning method according to embodiments of the present application is schematically shown.

[0035] As Figure 1As shown, the application scenario 100 according to this embodiment can include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 is a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 can include various connection types, such as wired, wireless communication links, or fiber optic cables, and the like.

[0036] A user can use the first terminal device 101, the second terminal device 102, the third terminal device 103 to interact with the server 105 through the network 104 to receive or send messages, and the like. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, and the like (only as examples).

[0037] The first terminal device 101, the second terminal device 102, the third terminal device 103 can be various electronic devices with a display screen and supporting web browsing, including but not limited to smartphones, tablet computers, laptop computers, desktop computers, and the like.

[0038] The server 105 can be a server providing various services, such as a background management server providing support for a website browsed by a user using the first terminal device 101, the second terminal device 102, the third terminal device 103 (only as an example). The background management server can analyze and process received user requests and the like, and feed back the processing results (such as a webpage, information, or data, and the like obtained or generated according to a user request) to the terminal device.

[0039] It should be noted that the root cause positioning method provided by the embodiments of the present application can generally be executed by the server 105. Correspondingly, the root cause positioning apparatus provided by the embodiments of the present application can generally be arranged in the server 105. The root cause positioning method provided by the embodiments of the present application can also be executed by a server or a server cluster different from the server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or the server 105. Correspondingly, the root cause positioning apparatus provided by the embodiments of the present application can also be arranged in a server or a server cluster different from the server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or the server 105.

[0040] It should be understood that Figure 1 The number of terminal devices, networks, and servers in the application scenario 100 is only illustrative. According to the implementation needs, there can be any number of terminal devices, networks, and servers.

[0041] The following will be based on Figure 1 The described scenario, by Figures 2-6 The root cause positioning method according to the embodiment of the application is described in detail.

[0042] Figure 2 The flowchart of a root cause positioning method according to an embodiment of the application is schematically shown.

[0043] As Figure 2 The root cause positioning method of this embodiment includes operations S210-S250.

[0044] In operation S210, device configuration data in the configuration management database, connection relationship data in the network topology tool, real-time index data in the monitoring system, and historical fault records and unstructured logs in the work order system are collected to form a multi-source heterogeneous data set.

[0045] In the embodiment of the application, a complete data view covering devices, networks, monitoring and operation records is constructed through multi-dimensional data collection and fusion technology. Specifically, device configuration data is collected from the configuration management database, including structured information such as hardware model, software version, deployment location and Internet Protocol address (IP address), to ensure the completeness and consistency of device entity attributes; connection relationship data is extracted from the network topology tool, and the physical / logical connection relationship between switches, routers and servers is obtained through Simple Network Management Protocol or Application Programming Interface (i.e. Application Programming Interface, abbreviated as API) to form a topology dependency graph between devices; real-time index data is collected from the monitoring system, covering time series data such as CPU utilization, memory occupation, disk I / O, network delay, and millisecond-level data synchronization is realized through a stream processing framework to ensure that the state at the time of failure can be traced back; historical fault records are extracted from the work order system, including fault type, impact range, repair action and timestamp.

[0046] To solve the heterogeneity of multi-source data, in the embodiment of the application, data standardization and alignment technology is further adopted: the entity association of CMDB devices and monitoring indexes is realized through device identifier (ID), IP address or media access control address, the fault event is mapped to the specific node in the propagation path by using the topology connection relationship, and the real-time index and historical fault records are aligned based on the time window. Finally, a multi-source heterogeneous data set containing device static attributes, dynamic indexes, topology relationships and fault cases is formed, providing a data basis for subsequent knowledge graph construction and root cause reasoning. This data set supports minute-level updates and can adapt to the dynamic change requirements of super large-scale data centers (such as a cluster of ten thousand servers) or hybrid cloud environments.

[0047] In operation S220, knowledge extraction is performed on the multi-source heterogeneous data set to extract device attributes, network topology relationships, fault event entities, and timestamps, and store them as structured knowledge.

[0048] In embodiments of the present application, knowledge extraction of the multi-source heterogeneous data set aims to extract key information from unstructured logs, structured databases, and semi-structured configuration files, and convert them into structured knowledge that can be directly used by a knowledge graph or a machine learning model. Knowledge extraction on the multi-source heterogeneous data set includes: analyzing fault descriptions in unstructured logs through natural language processing technology, identifying fault event entities and timestamps, and extracting device attributes, network topology relationships, and fault event types based on predefined rule templates. By combining natural language processing (NLP) and predefined rule template technology, key information is extracted from unstructured logs, structured databases, and semi-structured configuration files and converted into structured knowledge, achieving efficient integration of multi-source heterogeneous data.

[0049] For example, in the knowledge extraction of the multi-source heterogeneous data set, for the analysis of fault descriptions in unstructured logs, the system first preprocesses the original logs (such as removing noise, unifying format, and tokenizing), and then uses a transformer-based bidirectional encoder representation (BERT) pre-training model combined with a bidirectional long short-term memory network-conditional random field (BiLSTM-CRF) sequence labeling model to achieve fault type identification (such as "disk failure" and "network delay"), device identification extraction (such as "Disksdb" and "192.168.1.100"), and timestamp positioning (based on regular expressions or time series models, with an error of ≤±1 minute), while introducing an attention mechanism to enhance the ability to capture long text context semantics (such as associating "application unresponsive" with "database connection timeout"), and finally ensuring output consistency through rule checking (such as timestamp reasonableness and IP format) and knowledge graph cross-validation; for example, in a certain data center case, the system accurately extracts the fault event "ServiceAtimeout" and the timestamp from the log "ERROR:ServiceAtimeoutat2023-10-0115:00", and locates the specific device in combination with the system log, providing structured input for root cause analysis.

[0050] For example, for device attributes (such as device ID, model, IP address), a rule template based on regular expression and keyword matching is designed (such as Device:(\w+), Model:(\S+), IP:(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})), and the key fields are accurately located from the configuration management database (CMDB) or logs; for network topology relationships, the output format of the simple network management protocol or topology tool API is used to define a template (such as <Switch(\S+), connected_to, Server(\S+)>), the connection relationship between devices is parsed, and a visual topology graph is constructed; for fault event types, a keyword library (such as "timeout", "error", "unreachable") and a mapping rule of regular expression (such as Disk(\w+) failed) are established, and the free text logs are classified into standardized fault types (such as "disk failure" and "network timeout").

[0051] Return Figure 2 In operation S230, the entity type and the relationship type of the knowledge graph are defined, the real-time index data in the structured knowledge is mapped to the dynamic attribute of the entity, and a dynamic knowledge graph is constructed.

[0052] In the embodiments of the present application, the entity type includes physical devices (such as servers, switches), virtual resources (such as virtual machines, containers), and services (such as database services, Web applications); and the relationship type includes hierarchical relationships (such as the rack level to which the device belongs), dependency relationships (such as the database on which the service depends), and logical connections (such as port mapping in network topology). By defining the category of the entity, the object range described by the data is clear, for example, in the information technology (IT) operation and maintenance scenario, if the entity types of "physical device" and "virtual resource" are not defined, the system may confuse servers and virtual machines, resulting in fault location errors. By defining the semantics of the relationship, the interaction logic between entities is clear, for example, if "dependency relationship" and "logical connection" are not distinguished, the system may not be able to determine whether "database service" and "Web application" are calling dependencies or network communication, affecting root cause analysis. By defining the entity type and the relationship type of the knowledge graph, a complete entity-relationship network is formed, and the multi-source heterogeneous data is converted into a structured semantic network, thereby providing a basis for intelligent analysis, decision support, and other scenarios.

[0053] Figure 3 A flowchart of constructing a dynamic knowledge graph by mapping real-time index data in structured knowledge to dynamic attributes of entities is schematically shown.

[0054] As Figure 3As shown, the method for mapping real-time indicator data in structured knowledge to dynamic attributes of entities, constructing a dynamic knowledge graph of the embodiment includes operation S310~operation S330.

[0055] In operation S310, the real-time indicator data is stored by a time series database, the real-time indicator data is converted to attribute values of entities in the knowledge graph according to a preset time window, and a timestamp is marked.

[0056] In the embodiment of the present application, by deeply combining a time series database (TSDB) with a knowledge graph, efficient storage and dynamic conversion of real-time indicator data are realized: first, the TSDB is used to store real-time indicators (such as CPU usage, memory occupation) of physical devices, virtual resources and services, the indicators are aggregated and counted (such as calculating the average value, the maximum value) according to a preset time window (such as 5 minutes), then the aggregation result is taken as a dynamic attribute value (such as updating the "CPU usage of server A" to 73.5%) of an entity in the knowledge graph and a timestamp is marked, finally, the attribute value is synchronized to the knowledge graph through an incremental update mechanism, while the historical attribute value is retained to support time series analysis; this method significantly improves the real-time response capability (data update delay < 10 seconds), time series analysis capability (supporting risk prediction and root cause backtracking) and cost efficiency of the operation and maintenance system.

[0057] In operation S320, in response to the real-time indicator data continuously exceeding the historical threshold, an abnormal event node and an abnormal level are generated and associated to the corresponding entity in the knowledge graph.

[0058] In the embodiments of the present application, by dynamically associating real-time indicator anomaly detection with a knowledge graph, an automatic closed loop from anomaly discovery to operation and maintenance decision is realized. The specific method is as follows: first, a dynamic threshold model is constructed based on historical data (such as the past 30 days), the mean and standard deviation of the indicators (such as CPU usage and response time) are calculated through a sliding window, and an adaptive threshold (such as 80% for normal threshold) is generated; then, the indicator data in the TSDB is monitored in real time, if a certain indicator continuously exceeds the threshold in the last 3 time windows (such as 15 minutes), an abnormal event node is automatically generated, which contains event ID, associated entity identifier (such as server_001), abnormal indicator name (such as cpu_usage), abnormal level (according to the degree of deviation from the threshold, it is divided into mild, moderate and severe, for example, more than 20% deviation is judged as severe) and first detection timestamp; finally, the abnormal event node is injected into the knowledge graph as a new entity, associated with the corresponding entity through the relationship type (such as HAS_ANOMALY), and the history of abnormal events is recorded to support time series analysis. This method can achieve a second-level response (delay < 5 seconds) of abnormal events, for example, when the CPU usage of a certain server exceeds 90% for 15 minutes, the system automatically generates a "severe anomaly" event and associates it to the graph, triggering the expansion strategy, and the performance is restored within 10 minutes; through precise grading of abnormal levels, resource allocation is optimized, for example, when the response time of a certain service API exceeds the threshold by 10%, it is judged as "mild anomaly", only record without alarm, to avoid false alarms; the history of abnormal events retained in the knowledge graph supports root cause analysis and trend prediction, for example, by analyzing the memory usage anomaly of a certain database within a week, the peak period rule is found, and then the resource scheduling is optimized. In a large-scale system (such as managing 100,000 devices), this method shortens the anomaly processing time, reduces the false alarm rate, and promotes the operation and maintenance mode from passive response to active prevention, significantly improving system stability and operation and maintenance efficiency.

[0059] In operation S330, real-time indicator data is pushed to the graph engine in real time using a stream processing framework to dynamically update the attribute values of entities and mark the abnormal level.

[0060] In the embodiments of the present application, the stream processing framework is used to subscribe to the metric data stream in the TSDB in real time, parse the entity identifier (such as server_001), the metric value (such as cpu_usage = 92%), and the timestamp, and perform aggregation calculation (such as generating current_cpu_usage = 88%) on the metric through a sliding time window (such as 5 minutes), and then call the graph engine API (such as Cypher of Neo4j) to dynamically update the entity attribute, while marking the update timestamp; in the anomaly detection link, the stream processing framework compares the metric value with the historical threshold (such as CPU usage > 85% is determined as an anomaly) in real time, and calculates the anomaly level according to the deviation degree (such as exceeding 10% is mild, and exceeding 20% is severe), and takes the anomaly level as a new attribute (such as anomaly_level = "severe") of the entity or associates the anomaly event node to the knowledge graph through the relationship type (such as HAS_ANOMALY); in order to guarantee the data reliability, the system introduces a message queue to buffer the data stream, supports breakpoint continuation and fault handling, and retains the historical version of the attribute value in the graph to support time series analysis. Through dynamic attribute updating and anomaly level marking, the "time sensitive" query (such as quickly locating the current abnormal entity) is supported, and in a large-scale system (such as managing 100,000 devices), the operation and maintenance personnel can immediately obtain the information of 3 CPU abnormal servers and prioritize processing; the anomaly level drives the automatic process (such as expansion, degradation), reduces manual intervention, for example, when the database memory exceeds the threshold value by 20%, the system automatically marks "severe anomaly" and expands the container. This method has been verified in high-concurrency scenarios such as finance and e-commerce, and can shorten the anomaly processing time by 80%, promoting the operation and maintenance mode from passive response to active prevention.

[0061] Return Figure 2 In operation S240, the time sequence dependence relationship and propagation path between fault events in the dynamic knowledge graph are learned based on a graph neural network combined with time sequence characteristics.

[0062] In the embodiments of the present application, by combining dynamic knowledge graph with graph neural network (GNN) time series features, a timestamped fault event quadruple (event1-relation-event2-timestamp) is constructed, and embedding learning is performed on the graph using a time series graph neural network, a time decay factor is introduced, and LSTM / Transformer is used to capture long-term time series dependencies, thereby revealing the time series dependencies and propagation paths between fault events. This method can automatically locate fault sources, predict future fault trends and optimize operation and maintenance strategies through node embedding similarity analysis and edge weight calculation, significantly improving fault location efficiency (reducing abnormal processing time by 80% in large-scale systems), enhancing system early warning capability (discovering potential risks in advance), reducing operation and maintenance costs (reducing resource occupation by 40%), and supporting fault management of complex systems such as cloud computing and Internet of Things, promoting the operation and maintenance mode from passive response to active prevention. For example, in the financial system, the model can identify the time series propagation law of the risk of associated enterprises after the default of an enterprise, and warn of potential risk diffusion within 1-2 quarters, while dynamically adjusting the node connection weight to reflect the time-varying relationship, ensuring the accuracy of fault propagation path analysis.

[0063] Figure 4 A flowchart of learning time series dependencies and propagation paths between fault events in a dynamic knowledge graph based on a graph neural network combined with time series features according to an embodiment of the present application is schematically shown.

[0064] As Figure 4 shown, the method of learning time series dependencies and propagation paths between fault events in a dynamic knowledge graph based on a graph neural network combined with time series features according to the embodiment includes operations S410-S440.

[0065] In operation S410, fault events, repair actions and timestamps are extracted from fault tickets and logs.

[0066] In the embodiments of the present application, first, the fault work order and the log need to be preprocessed, including cleaning redundant information (such as debugging logs, repeated records) and standardizing field formats (such as unifying timestamps to ISO8601 standard). Subsequently, fault keywords (such as "CPU overload" "memory leak") in the log are identified through regular expressions or NLP models, and are mapped to standardized event types (such as CPU_OVERLOAD). At the same time, manual operation records (such as "restart service" "expand resources") are extracted from the work order as repair actions, and the execution time is marked. The extraction of the timestamp is particularly critical, and the time of the occurrence of the fault and the completion of the repair needs to be accurately recorded for subsequent time sequence analysis. For example, a log record "2023-10-0112:00:00 [ERROR] server_001 CPU usage exceeds 95%" can be parsed as {device ID: server_001, event type: CPU_OVERLOAD, timestamp: 2023-10-01T12:00:00Z}. Through this process, the original data is transformed into structured event sequences, providing a basis for subsequent correlation analysis and propagation chain construction. In addition, data quality needs to be ensured to avoid analysis bias due to missing information or format errors. For example, if the timestamp format is not uniform, it may lead to errors in time sequence analysis results; if the fault description is ambiguous, it may affect the accurate classification of event types. Therefore, the data extraction stage needs to combine business rules and technical means to ensure the integrity and accuracy of the information, providing reliable input for subsequent analysis.

[0067] In operation S420, based on the fault event, the repair action and the timestamp, the propagation chain of "fault cause → affected device → final symptom" is established.

[0068] In the embodiments of the present application, firstly, the associated events are screened based on a time window (such as within 5 minutes after the occurrence of a fault), for example, if a CPU overload event of server_001 occurs, and a response delay of db_001 occurs within 2 minutes, then the two events may have a causal relationship. Subsequently, the historical data is analyzed by an association rule mining algorithm (such as Apriori, FP-Growth) to generate propagation rules (such as CPU_OVERLOAD→DB_LATENCY→USER_TIMEOUT). These rules not only reflect direct associations, but also reveal multi-hop propagation (such as CPU overload→database latency→user timeout). When constructing the propagation chain, the device topology information (such as network connection relationship) needs to be combined to ensure the rationality of the propagation path. For example, if server_001 and db_001 have no direct network connection, then the assumption that CPU overload leads to database latency may not be true. The construction result of the propagation chain is usually represented in a graph structure, the nodes are devices or fault events, the edges are propagation relationships, and the time stamp and propagation probability are marked. For example, server_001(CPU_OVERLOAD, 12:00)→db_001(DB_LATENCY, 12:02) indicates that CPU overload is triggered at 12:00, and 2 minutes later, it leads to database latency. Through the propagation chain, the operation and maintenance personnel can quickly locate the fault root cause (such as CPU overload) and the impact range (such as user timeout), so as to formulate targeted repair strategies. In addition, the propagation chain can also be used to simulate the fault propagation process, evaluate the system vulnerability, and provide a basis for disaster recovery design.

[0069] In operation S430, based on a graph neural network, the device topology and historical fault events in the knowledge graph are modeled, and the implicit propagation weight between nodes is learned.

[0070] In the embodiments of this application, firstly, a graph of device topology and fault events is constructed, where nodes include devices (such as servers and databases) and fault types (such as CPU_OVERLOAD), and edges include physical connections (such as network topology) and propagation relationships (such as server_001→db_001). Subsequently, historical fault data (such as propagation chains) is input into the GNN model, and node embedding vectors are learned through message passing mechanisms (such as GCN) or attention mechanisms (such as GAT). These vectors capture the implicit features of devices (such as performance bottlenecks and dependencies) and the propagation patterns of faults (such as CPU overload being more likely to cause database latency). During model training, the learning objective of the propagation weights needs to be defined, such as maximizing the predicted probability of the propagation path. For example, if CPU overload of server_001 in historical data has an 80% probability of causing latency in db_001, then the model should learn a propagation weight of 0.8 between the two. Furthermore, to improve the model's generalization ability, regularization terms (such as L2 regularization) or adversarial training can be introduced to avoid overfitting. Through GNN learning, the system can reveal implicit dependencies that are difficult to capture by traditional rules. For example, even if there is no direct physical connection between devices, the model may still discover indirect dependencies (such as CPU overload → network congestion → database latency) through historical propagation patterns. These implicit weights provide a more refined basis for fault prediction and root cause analysis, significantly improving the accuracy of the analysis.

[0071] When operating the S440, based on the implicit propagation weights between nodes and combined with timing characteristics, the timing dependencies and propagation paths of fault events are captured.

[0072] In the embodiments of this application, firstly, temporal features are extracted, including time intervals between events (such as the 2-minute interval between CPU overload and database latency) and periodic patterns (such as CPU overload during daily peak periods). Subsequently, the temporal information is integrated into the GNN model, for example, by reducing the weight of historical events through a time decay factor (such as exponential weighting), or by combining LSTM / Transformer to capture long-term temporal dependencies. For example, if a certain fault pattern has occurred frequently in the past week, the model should give it higher attention. In dynamic propagation path prediction, the model outputs the devices that may be affected in the future and their probabilities based on the current fault event and historical propagation patterns. For example, if server_001 is currently experiencing CPU overload, the model predicts a 90% probability of db_001 experiencing response latency after 5 minutes, triggering automated repair (such as automatic capacity expansion). Furthermore, temporal features can also be used to identify the evolution trend of faults. For example, if the propagation time of CPU overload extends from 2 minutes to 5 minutes, it may indicate a decrease in system load capacity. Through temporal GNN, the system can achieve an upgrade from static relationship analysis to dynamic path prediction, significantly improving the timeliness and accuracy of fault warnings. For example, in cloud computing scenarios, the model can predict database failures 10 minutes in advance, avoiding service interruptions. This step combines static knowledge graphs with dynamic time-series analysis to provide intelligent solutions for fault management in complex systems.

[0073] return Figure 2 When operating the S250, based on temporal dependencies and propagation paths, the causal inference algorithm combined with multi-dimensional evidence outputs the root cause entity, confidence score, and fault propagation path of the fault event.

[0074] Figure 5 The illustration shows a flowchart illustrating how a causal inference algorithm, combined with multi-dimensional evidence, outputs the root cause entity, confidence score, and fault propagation path of a fault event according to an embodiment of this application.

[0075] like Figure 5 As shown, the method of outputting the root cause entity, confidence score and fault propagation path of a fault event by combining causal inference algorithm with multi-dimensional evidence in this embodiment includes operations S510 to S530.

[0076] When operating the S510, monitor real-time indicator data and identify abnormal indicators.

[0077] In the embodiments of this application, potential faults in the system are quickly discovered through real-time data acquisition and dynamic anomaly detection algorithms. First, core metrics of devices or services (such as CPU utilization, memory usage, and network latency) are continuously collected using monitoring tools, and the data is standardized into a time-series format for subsequent analysis. Then, anomalies are identified by combining static thresholds (such as triggering an alarm when CPU utilization > 90%) and dynamic thresholds (such as the 3σ principle or EWMA algorithm based on historical data). Simultaneously, machine learning models (such as Isolation Forest and LSTM) are introduced to capture abnormal behavior under complex patterns. When a metric exceeds a threshold or the model predicts an anomaly, the system immediately triggers an alarm (such as via SMS or email) and records key information about the anomaly event (such as device ID, metric value, and timestamp). This process ensures early fault detection, prevents problem spread, and reduces false alarm rates through dynamic thresholds and machine learning, improving operational efficiency. For example, in a high-concurrency scenario like the "Double 11" e-commerce shopping festival, the system dynamically identifies a server's CPU utilization suddenly spikes to 98%, far exceeding the dynamic threshold of 85%, thus triggering an alarm in a timely manner and buying time for subsequent processing.

[0078] When operating the S520, the influence range of abnormal indicators is analyzed based on the topological connectivity state of the dynamic knowledge graph.

[0079] In the embodiments of this application, the impact range of abnormal indicators is quickly located through topological analysis of a dynamic knowledge graph. First, a dynamic knowledge graph containing devices, services, indicators, and their relationships is constructed. Nodes represent entities (such as servers, databases, and services), and edges represent dependencies (such as network connections and service calls) or propagation paths (such as CPU overload → database latency → user timeout). The graph is dynamically updated through real-time data streams to ensure consistency with the actual system. When an abnormal indicator is identified, the system starts from the abnormal node and traverses the graph using a graph traversal algorithm (such as BFS or DFS), filtering low-probability paths using propagation weights (such as implicit weights learned by GNNs), ultimately marking the affected nodes and paths. The analysis results are presented as a visual topology graph, intuitively showing the propagation range of the anomaly. For example, when a server's CPU overload is identified as abnormal, graph analysis shows that it affects downstream databases through database connections, leading to delays in the response of payment services that depend on that database, ultimately affecting the user's order placement process. This process helps operations and maintenance personnel quickly pinpoint the scope of the fault, avoiding blind troubleshooting and significantly improving fault location efficiency.

[0080] When operating the S530, based on the similarity of historical cases, the root cause entity, confidence score, and fault propagation path are output through the causal inference algorithm.

[0081] In the embodiments of this application, the root cause and propagation path of a fault are automatically output through historical case matching and causal inference. First, a historical case library is constructed to store past fault events (such as propagation chains and repair actions) and their root cause analysis results, and feature vectors (such as index values, timestamps, and topological locations) are extracted. When a new fault occurs, the system calculates the similarity between the current anomaly and historical cases (such as cosine similarity or Siamese networks), and selects cases with high similarity as references. Subsequently, based on the propagation paths of historical cases, a Bayesian network or counterfactual reasoning model is constructed to calculate the root cause probability of the current fault (such as P(CPU_OVERLOAD|anomaly index)), and outputs the root cause entity (such as a server CPU overload), confidence score (such as 0.92), and propagation path (such as server → database → service → user). Maintenance personnel can prioritize high-probability root causes based on the confidence score and quickly formulate repair strategies based on the propagation path. For example, the anomaly indicators of the current fault have a similarity of 0.85 with the historical case F001. The causal inference model outputs the root cause as a server CPU overload (confidence 0.92), with the propagation path being server → database → payment service → user. Based on this, the operations and maintenance personnel discovered that the server was under attack by malicious requests, and the fault was restored after triggering the rate limiting policy. This process achieves an automated closed loop from anomaly detection to root cause inference, significantly reducing manual investigation time and improving fault handling efficiency.

[0082] By using real-time monitoring, dynamic topology analysis, and causal inference, a complete closed loop from fault discovery to root cause localization was constructed.

[0083] Figure 6 A flowchart illustrating another root cause localization method according to an embodiment of this application is shown schematically.

[0084] like Figure 6 As shown, another root cause localization method in this embodiment is... Figure 2 The method shown also includes operation S260.

[0085] When operating the S260, newly occurring fault cases and repair results are fed back to the graph neural network and causal inference algorithm to continuously optimize the parameters of the graph neural network.

[0086] In the embodiments of this application, by feeding newly occurring fault cases and their repair results back to the Graph Neural Network (GNN) model and causal inference algorithm, the system constructs a continuously optimized closed-loop mechanism: First, it automatically records the entire lifecycle data of the fault (including abnormal indicators, root cause entities, repair actions, and propagation paths) and standardizes it into structured feature vectors; then, it injects new data into a dynamic knowledge graph, expands the topology, and fine-tunes the GNN model parameters to optimize the learning and generalization capabilities of propagation weights, while updating the historical case library and correcting the causal model (such as adjusting the Bayesian network conditional probability table and verifying counterfactual reasoning logic); finally, it evaluates model performance through offline verification and online deployment, and dynamically adjusts the update frequency. For example, in a database latency fault on a cloud platform, by feeding back root cause data on "lock contention," the optimized model's root cause localization accuracy increased to 82%, and the propagation path prediction recall rate reached 78%, significantly shortening the average repair time and reducing operation and maintenance costs. This mechanism enables the system to have self-evolution capabilities, continuously adapting to complex environmental changes and improving business continuity and the level of intelligent operation and maintenance.

[0087] Based on the above-described root cause localization method, this application also provides a root cause localization device. The following will be combined with... Figure 7 The device is described in detail.

[0088] Figure 7 A schematic block diagram of a root cause localization device according to an embodiment of this application is shown.

[0089] like Figure 7 As shown, the root cause localization device 800 in this embodiment includes a data acquisition module 810, a knowledge extraction module 820, a map construction module 830, a path learning module 840, and a fault prediction module 850.

[0090] The data acquisition module 810 is used to collect device configuration data from the configuration management database, connection relationship data from the network topology tool, real-time indicator data from the monitoring system, and historical fault records and unstructured logs from the work order system to form a multi-source heterogeneous dataset. In one embodiment, the data acquisition module 810 can be used to perform the operation S210 described above, which will not be repeated here.

[0091] The knowledge extraction module 820 is used to extract knowledge from multi-source heterogeneous datasets, extract device attributes, network topology relationships, fault event entities and timestamps, and store them as structured knowledge. In one embodiment, the knowledge extraction module 820 can be used to perform the operation S220 described above, which will not be repeated here.

[0092] The graph construction module 830 is used to define the entity types and relation types of the knowledge graph, map real-time indicator data in structured knowledge to dynamic attributes of entities, and construct a dynamic knowledge graph. In one embodiment, the graph construction module 830 can be used to perform the operation S230 described above, which will not be repeated here.

[0093] The path learning module 840 is used to learn the temporal dependencies and propagation paths between fault events in a dynamic knowledge graph based on graph neural networks and temporal features. In one embodiment, the path learning module 840 can be used to perform the operation S240 described above, which will not be repeated here.

[0094] The fault prediction module 850 is used to output the root cause entity, confidence score and fault propagation path of the fault event based on the temporal dependency and propagation path, and by combining multi-dimensional evidence with the causal inference algorithm. In one embodiment, the fault prediction module 850 can be used to perform the operation S250 described above, which will not be repeated here.

[0095] According to embodiments of this application, any multiple modules among the data acquisition module 810, knowledge extraction module 820, graph construction module 830, path learning module 840, and fault prediction module 850 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the data acquisition module 810, knowledge extraction module 820, graph construction module 830, path learning module 840, and fault prediction module 850 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the data acquisition module 810, knowledge extraction module 820, graph construction module 830, path learning module 840, and fault prediction module 850 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0096] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a root cause localization method according to an embodiment of this application.

[0097] like Figure 8As shown, an electronic device 900 according to an embodiment of this application includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0098] RAM 903 stores various programs and data required for the operation of electronic device 900. Processor 901, ROM 902, and RAM 903 are interconnected via bus 904. Processor 901 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 902 and / or RAM 903. It should be noted that programs may also be stored in one or more memories other than ROM 902 and RAM 903. Processor 901 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0099] According to embodiments of this application, the electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the input / output (I / O) interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input / output (I / O) interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0100] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0101] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 902 and / or RAM 903 and / or one or more memories other than ROM 902 and RAM 903 described above.

[0102] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the root cause localization method provided in the embodiments of this application.

[0103] When the computer program is executed by the processor 901, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0104] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 909, and / or installed from a removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0105] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from the removable medium 911. When the computer program is executed by the processor 901, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0106] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

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

[0108] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A root cause localization method, characterized in that, The method includes: Collect device configuration data from the configuration management database, connection relationship data from the network topology tool, real-time indicator data from the monitoring system, and historical fault records and unstructured logs from the work order system to form a multi-source heterogeneous dataset; Knowledge extraction is performed on the multi-source heterogeneous dataset to extract device attributes, network topology relationships, fault event entities and timestamps, and store them as structured knowledge; Define the entity types and relation types of the knowledge graph, map the real-time indicator data in the structured knowledge to the dynamic attributes of the entities, and construct a dynamic knowledge graph; Based on graph neural networks combined with temporal features, the temporal dependencies and propagation paths among fault events in the dynamic knowledge graph are learned; and Based on the temporal dependencies and the propagation path, the root cause entity, confidence score, and failure propagation path of the failure event are output by combining causal inference algorithms with multi-dimensional evidence.

2. The method according to claim 1, characterized in that, The knowledge extraction from the multi-source heterogeneous dataset includes: The fault descriptions in the unstructured logs are parsed using natural language processing techniques to identify fault event entities and timestamps; and Device attributes, network topology relationships, and fault event types are extracted based on predefined rule templates.

3. The method according to claim 1, characterized in that, The entity types include physical devices, virtual resources, and services; and The relationship types include hierarchical relationships, dependency relationships, and logical connections.

4. The method according to claim 1, characterized in that, The step of mapping real-time indicator data in the structured knowledge to dynamic attributes of entities to construct a dynamic knowledge graph includes: The real-time indicator data is stored in a time series database, and the real-time indicator data is converted into attribute values ​​of entities in a knowledge graph by slicing according to a preset time window, and then marked with a timestamp. In response to the real-time indicator data continuously exceeding the historical threshold, an abnormal event node and an abnormal level are generated and associated with the corresponding entity in the knowledge graph; The real-time metric data is pushed to the graph engine in real time using a stream processing framework to dynamically update the attribute values ​​of entities and mark the anomaly level.

5. The method according to claim 1, characterized in that, The method of learning the temporal dependencies and propagation paths among fault events in the dynamic knowledge graph based on graph neural networks and temporal features includes: Extract fault events, repair actions, and timestamps from fault tickets and logs; Based on the aforementioned fault events, repair actions, and timestamps, a propagation chain of "fault cause → affected equipment → final symptoms" is established; Based on graph neural networks, we model the device topology and historical fault events in a knowledge graph and learn the implicit propagation weights between nodes. Based on the implicit propagation weights between the nodes and combined with temporal characteristics, the temporal dependencies and propagation paths of fault events are captured.

6. The method according to claim 1, characterized in that, The method, which combines causal inference algorithms with multi-dimensional evidence, outputs the root cause entity, confidence score, and fault propagation path of the failure event, including: Real-time monitoring of the real-time indicator data to identify abnormal indicators; Based on the topological connectivity state of the dynamic knowledge graph, the influence range of the abnormal indicators is analyzed. By combining historical case similarity, the root cause entity, confidence score, and fault propagation path are output through causal inference algorithm.

7. The method according to claim 1, characterized in that, The method further includes: Newly occurring fault cases and repair results are fed back to the graph neural network and causal inference algorithm to optimize the parameters of the graph neural network.

8. A root cause localization device, characterized in that, The device includes: The data acquisition module is used to collect device configuration data from the configuration management database, connection relationship data from the network topology tool, real-time indicator data from the monitoring system, and historical fault records and unstructured logs from the work order system to form a multi-source heterogeneous dataset. The knowledge extraction module is used to extract knowledge from the multi-source heterogeneous dataset, extracting device attributes, network topology relationships, fault event entities and timestamps, and storing them as structured knowledge. The knowledge graph construction module is used to define the entity types and relationship types of the knowledge graph, map the real-time indicator data in the structured knowledge to the dynamic attributes of the entities, and construct a dynamic knowledge graph. The path learning module is used to learn the temporal dependencies and propagation paths between fault events in the dynamic knowledge graph based on graph neural networks and temporal features; and The fault prediction module is used to output the root cause entity, confidence score and fault propagation path of the fault event based on the temporal dependency and the propagation path, by combining multi-dimensional evidence with a causal inference algorithm.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images