Method, computing device, medium, and program product for determining network fault root cause

Abstract

The present application relates to a method, a computing device, a medium and a program product for determining a network fault root cause. The method comprises: acquiring real-time data of a network for constructing input features, the real-time data at least including alarm events, time series index data, and network topology information; based on the input features, generating a candidate root cause set via a multi-dimensional analysis model; based on the candidate root cause set, respectively outputting a plurality of reasoning results about the fault root cause via a plurality of reasoning engines; and at least for the plurality of reasoning results about the fault root cause, performing aggregation, conflict processing and confidence calculation in order to output a diagnosis result about the network fault root cause. The present application can significantly improve the fault root cause determination accuracy, explainability, traceability and automation degree under complex network and complex fault scenarios.

Description

Technical Field

[0001] The embodiments of the present invention generally relate to the field of computers, and more specifically to a method, computing device, computer-readable storage medium, and computer program product for determining the root cause of a network failure. Background Technology

[0002] Traditional methods for diagnosing network fault root causes mainly include: traditional rule-based reasoning, machine learning-based diagnosis, and simple fusion methods. For example, traditional rule-based reasoning methods typically rely on expert experience to predefine fault-to-root-cause mapping rules. Therefore, this approach suffers from limited fault coverage, difficulty adapting to new, compound, and complex faults, and high manual maintenance costs. Machine learning-based diagnosis methods typically rely on massive amounts of data for models to autonomously learn fault patterns. However, this approach suffers from insufficient interpretability of diagnostic results, high dependence on labeled data, and inaccuracy for rare faults. Fusion methods typically use fixed-weight calculations or voting mechanisms for fault diagnosis. However, because they do not fully utilize multi-source data, they struggle to meet the high-precision, interpretable, and highly automated fault diagnosis requirements of complex networks.

[0003] In summary, the shortcomings of traditional network fault root cause diagnosis methods are at least that they cannot meet the needs of high-precision, interpretable automatic fault diagnosis in complex networks or complex fault scenarios. Summary of the Invention

[0004] This invention provides a method, computing device, computer-readable storage medium, and computer program product for determining the root cause of network faults, which can significantly improve the accuracy, interpretability, and automation of fault diagnosis in complex networks or complex fault scenarios.

[0005] According to a first aspect of the present invention, a method for determining the root cause of a network failure is also provided. The method includes: acquiring real-time data of the network to construct input features, the real-time data including at least alarm events, time-series indicator data, and network topology information; generating a candidate root cause set based on the input features via a multi-dimensional analysis model; outputting multiple inference results regarding the root cause of the failure via multiple inference engines based on the candidate root cause set; and performing aggregation, conflict resolution, and confidence calculation on at least the multiple inference results regarding the root cause of the failure to output a diagnostic result regarding the root cause of the network failure.

[0006] In some embodiments, the alarm events include device alarm events and fault alarm events, and the time-series indicator data includes at least time-series indicator data on CPU utilization, traffic, latency, and packet loss rate. Obtaining real-time network data includes: receiving alarm events reported by devices via an event collector; identifying and structuring key symptoms from the received alarm events via a symptom extractor; maintaining indicator data for multiple time windows via a time-series analyzer; and constructing a device, interface, and link graph model based on link layer discovery protocols and device discovery protocols to obtain network topology information.

[0007] In some embodiments, the method further includes: generating a candidate root cause set based on the input features via a multi-dimensional analysis model, including: querying a predefined fault type and root cause mapping table via a diagnostic mapping module to map the fault type to a first candidate root cause; grouping similar key symptoms using a clustering algorithm via a symptom analysis module to infer a second candidate root cause; obtaining a third candidate root cause from similar historical cases via a historical fault data retrieval module based on vectorized retrieval and the KNN algorithm; calculating the fault propagation path based on a network topology graph via a topology analysis module to determine the root cause device of the fault propagation path from the affected area to obtain a fourth candidate root cause; and deduplicating and sorting the first, second, third, and fourth candidate root causes via a candidate fusion and deduplication module to generate a candidate root cause set.

[0008] In some embodiments, obtaining a third candidate root cause of similar historical cases via a historical failure case retrieval module, based on vectorized retrieval and the KNN algorithm, includes: using a natural language vectorization module to convert the description of the failure event into a high-dimensional vector; based on the high-dimensional vector, retrieving multiple historical failure cases that are most similar to the historical failure cases via the KNN algorithm; and extracting the root causes of the failures from the multiple historical failure cases to obtain a third candidate root cause.

[0009] In some embodiments, based on a set of candidate root causes, multiple inference results about the root causes of the failure are output via multiple inference engines, including: via an abductive reasoning engine, calculating the likelihood and confidence of each candidate root cause in the set of candidate root causes under given symptom conditions to generate abductive reasoning results; via a forward inference engine, verifying the rationality of the symptom propagation chain starting from each candidate root cause in the set of candidate root causes to generate forward inference results; and via a backward inference engine, confirming the feasibility of each candidate root cause in the set of candidate root causes through hypothesis testing and constraint checks to generate backward inference results.

[0010] In some embodiments, at least the aggregation, conflict resolution, and confidence calculation of the plurality of inference results regarding the root causes of the fault, in order to output a diagnostic result regarding the root causes of the network fault, includes: aggregating the abductive reasoning results, forward reasoning results, and backward reasoning results via a multi-policy integrator to generate an aggregated inference result; resolving conflicts in the aggregated inference results via a conflict resolver to output a conflict-free inference result; and calculating the confidence of the conflict-free inference result based on a voting mechanism and evidence strength via a confidence calculator to output a root cause diagnostic result regarding the network fault.

[0011] In some embodiments, receiving alarm events reported by devices via an event collector includes: receiving alarm events reported by network devices; extracting alarm event timestamps, network device identifiers, alarm event types, and alarm event severity based on the received alarm events; and associating the received alarm events with super events.

[0012] In some embodiments, identifying and structuring key symptoms from received alarm events via a symptom extractor includes: extracting structured symptoms from the received alarm events; identifying key-level symptoms and error-level symptoms from the extracted structured symptoms to generate a symptom set; and extracting implicit symptoms from the symptom set.

[0013] In some embodiments, maintaining multi-time-window metric data via a time-series analyzer includes: collecting time-series metric data on CPU utilization, traffic, latency, and packet loss rate; dividing the time windows into multiple groups of time windows with different window sizes; and, based on the multiple groups of time windows, detecting abnormal patterns in terms of spikes, persistence, and trends for the collected time-series metric data.

[0014] In some embodiments, acquiring real-time network data for constructing input features includes acquiring super events, symptom sets, and time-series indicator data to construct input features. The super events are associated with network device identifiers, interface identifiers, and diagnosis types. The symptom sets include critical-level symptoms and error-level symptoms. The time-series indicator data includes time-series indicator data for CPU utilization, traffic, latency, and packet loss rate over a predetermined time period.

[0015] In some embodiments, generating a candidate root cause set includes: fusing a first candidate root cause, a second candidate root cause, a third candidate root cause, and a fourth candidate root cause to form a candidate root cause list, so as to calculate the evidence strength score of each candidate root cause; performing deduplication on the fused candidate root cause list so as to retain the candidate root cause with the highest evidence strength score among the same plurality of candidate root causes; and sorting the candidate root cause list after deduplication in descending order of evidence strength score, retaining a predetermined number of candidate root causes at the top of the sort, to generate a candidate root cause set.

[0016] In some embodiments, calculating the evidence strength score for each candidate root cause includes: for each candidate root cause in the candidate root cause list, calculating the degree of matching between each candidate root cause and the diagnosis type to obtain a diagnosis matching score; for each candidate root cause, calculating the coverage of expected symptoms and actual symptoms of the candidate root cause to obtain a symptom coverage score; for each candidate root cause, confirming whether the root cause device is located upstream of the fault propagation to obtain a topology consistency score; and calculating the evidence strength score for each candidate root cause based on the diagnosis matching score, the symptom coverage score, and the topology consistency score.

[0017] In some embodiments, the process of calculating the likelihood and confidence of each candidate root cause in a set of candidate root causes under given symptom conditions via an abductive reasoning engine to generate an abductive reasoning result includes: obtaining a set of candidate root causes, a set of observed symptoms, and super-event context information; querying a predetermined knowledge base for each candidate root cause in the set of candidate root causes to obtain the theoretical expected symptoms corresponding to each candidate root cause, wherein the predetermined knowledge base stores the mapping relationship between root causes and symptoms; calculating the likelihood of generating observed symptoms under given root cause conditions; calculating the degree of overlap between expected symptoms and observed symptoms to obtain coverage; extracting typical temporal patterns of multiple performance index data from expected symptoms to calculate the temporal similarity between the current observed temporal sequence and the expected temporal sequence using a dynamic time warping algorithm; calculating a motivation score based on temporal consistency, topological consistency, and temporal similarity; performing a weighted fusion calculation based on the likelihood, coverage, prior probability, and motivation score of each candidate root cause to obtain a comprehensive score; and traversing the comprehensive scores of each candidate root cause to obtain the candidate root cause with the highest comprehensive score as the abductive reasoning result.

[0018] In some embodiments, verifying the plausibility of the symptom propagation chain from each candidate root cause in the candidate root cause set via a forward inference engine to generate a forward inference result includes: constructing a symptom propagation chain according to causal relationships from the expected symptoms of each candidate root cause in the candidate root cause set; verifying whether the symptoms in the expected symptoms are in the observed symptoms in order to calculate the link coverage; and calculating a forward score based on the link coverage and link length penalty in order to generate a forward inference result.

[0019] In some embodiments, at least the plurality of inference results regarding the root causes of the fault are aggregated, conflict-resolved, and confidence-calculated to output diagnostic results regarding the root causes of network faults. This includes: obtaining causal inference results, forward inference results, and backward inference results to extract a root cause list. The causal inference results include root causes, confidence levels, and inference paths. The forward inference results include root causes, forward scores, and symptom chain coverage. The backward inference results include root causes, backward scores, and consistency scores. In response to determining that there is a root cause with a confidence level higher than a predetermined threshold, the... The root cause is determined to be a root cause diagnosis result of network failure; in response to determining that there is no root cause with a confidence level higher than a predetermined threshold, the frequency of each root cause recommended in the abductive reasoning result, forward reasoning result, and backward reasoning result is counted; the strength of evidence for each root cause is counted and compared to determine whether there is a dominant root cause; in response to determining that there is a dominant root cause, the dominant root cause is determined to be a root cause diagnosis result of network failure; and in response to determining that there is no dominant root cause, a weighted average confidence level is calculated for the root cause to determine the root cause diagnosis result of network failure based on the weighted average confidence level.

[0020] According to a second aspect of the present invention, a computing device is also provided. The computing device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the computing device to perform the method of the first aspect of the present invention.

[0021] According to a third aspect of the present invention, a computer-readable storage medium is also provided. The computer-readable storage medium stores a computer program that, when executed by a machine, performs the method of the first aspect of the present invention.

[0022] According to a fourth aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a machine, performs the method of the first aspect of the present invention.

[0023] This invention utilizes input features constructed from multi-source real-time network data, including alarm events, time-series indicator data, and network topology information, and generates a candidate root cause set through a multi-dimensional analysis model. The candidate root cause set of this invention can fully integrate multi-source information. Furthermore, based on the input features, this invention outputs multiple inference results regarding fault root causes via multiple inference engines; and aggregates, resolves conflicts, and calculates confidence scores for at least these multiple inference results to output diagnostic results regarding network fault root causes. This invention can fully integrate multi-source information and multiple inference results regarding fault root causes output by various inference engines, improving the coverage of candidate fault root causes, the accuracy of fault diagnosis, and the degree of automation, while enhancing the robustness and interpretability of fault diagnosis in complex networks and complex fault scenarios. Therefore, this invention can significantly improve the accuracy, interpretability, and automation of fault diagnosis in complex networks or complex fault scenarios.

[0024] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0025] The above and other features, advantages, and aspects of the various embodiments of the present invention will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements.

[0026] Figure 1 A schematic diagram of a system for determining the root cause of a network failure is shown according to an embodiment of the present invention.

[0027] Figure 2 A flowchart of a method for determining the root cause of a network failure according to an embodiment of the present invention is shown.

[0028] Figure 3 A flowchart of a method for generating a set of candidate root causes according to an embodiment of the present invention is shown.

[0029] Figure 4 A flowchart of a method for deduplication and sorting according to an embodiment of the present invention is shown.

[0030] Figure 5 A flowchart illustrating a method for generating inference results according to an embodiment of the present invention is shown schematically.

[0031] Figure 6 A flowchart illustrating a method for generating abductive reasoning results according to an embodiment of the present invention is shown schematically.

[0032] Figure 7A flowchart illustrating a method for outputting inference results of the root cause of a fault according to an embodiment of the present invention is shown.

[0033] Figure 8 The flowchart illustrates a method for aggregating, conflict-handling, and confidence-calculating inference results for root causes of failures according to an embodiment of the present invention.

[0034] Figure 9 The schematic diagram illustrates the structural hierarchy of a network fault root cause diagnosis system according to an embodiment of the present invention.

[0035] In the various figures, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0036] Preferred embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0037] The term "comprising" and its variations, as used herein, indicate an open-ended inclusion, meaning "including but not limited to". Unless otherwise stated, the term "or" means "and / or". The term "based on" means "at least partially based on". The terms "one example embodiment" and "one embodiment" mean "at least one example embodiment". The term "another embodiment" means "at least one additional embodiment". The terms "first", "second", etc., may refer to different or the same objects.

[0038] As mentioned earlier, the shortcomings of traditional network fault root cause diagnosis methods are that they are difficult to meet the needs of high-precision, traceable, interpretable and highly automated fault diagnosis in complex network environments.

[0039] To at least partially address one or more of the aforementioned problems and other potential issues, exemplary embodiments of the present invention utilize input features constructed from multi-source real-time network data, including alarm events, time-series indicator data, and network topology information, and generate a candidate root cause set via a multi-dimensional analysis model. The candidate root cause set of the present invention can fully integrate multi-source information. Furthermore, the present invention, based on multi-dimensional input features, outputs multiple inference results regarding fault root causes via multiple inference engines; and aggregates, resolves conflicts, and calculates confidence scores for at least the multiple inference results regarding fault root causes to output diagnostic results regarding network fault root causes. The present invention can fully integrate multi-source information and multiple inference results regarding fault root causes output by various inference engines, improving the coverage of candidate fault root causes, the accuracy of fault diagnosis, and the degree of automation, while enhancing the robustness and interpretability of fault diagnosis in complex networks and complex fault scenarios. Therefore, the present invention can significantly improve the accuracy, interpretability, and automation of fault diagnosis in complex networks or complex fault scenarios.

[0040] The following combination Figure 1 This describes a computing device 100 that implements a method for determining the root cause of network failures. For example... Figure 1 As shown, the computing device 100 may have one or more processing units, including dedicated processing units such as graphics processing units (GPUs), field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or general-purpose computing on graphics processing units (GPGPUs), as well as general-purpose processing units such as CPUs. The computing device 100 also includes at least: an input feature construction unit 102, a candidate root cause set generation unit 104, a fault root cause inference result generation unit 106, and a network fault root cause diagnosis result determination unit 108.

[0041] Regarding the input feature construction unit 102, it is used to acquire real-time network data for constructing input features. The real-time data includes at least alarm events, time-series indicator data, and network topology information.

[0042] Regarding the candidate root cause set generation unit 104, it is used to generate a candidate root cause set based on the input features via a multi-dimensional analysis model.

[0043] Regarding the fault root cause reasoning result generation unit 106, it is used to output multiple reasoning results about fault root causes based on the candidate root cause set and through multiple reasoning engines.

[0044] The fault root cause diagnosis result determination unit 108 is used to aggregate, resolve conflicts, and calculate confidence for at least the plurality of inference results about the fault root causes, so as to output a diagnosis result about the network fault root causes.

[0045] The following combination Figure 2 and Figure 9 This describes a method for determining the root cause of network failures. Figure 2 A flowchart of a method 200 for determining the root cause of a network failure according to an embodiment of the present invention is shown. Figure 9 A schematic diagram illustrating the structural hierarchy of a network fault root cause diagnosis system 900 according to an embodiment of the present invention is provided. It should be understood that method 200, for example, can be implemented in... Figure 9 The described network fault root cause diagnosis system is executed at point 900. It can also be used in... Figure 1 The described computing device 100 performs the operation. It should be understood that method 200 may also include additional actions not shown and / or the actions shown may be omitted, and the scope of the invention is not limited in this respect.

[0046] like Figure 9 As shown, the network fault root cause diagnosis system 900 includes a data access layer 910, a candidate root cause generation layer 920, a decision fusion layer 930, and a multi-strategy inference layer 940. The data access layer 910 includes a time series analyzer 911, an event collector 912, a symptom extractor 913, and a topology service module 914. The candidate root cause generation layer 920 includes a diagnostic mapping module 921, a symptom analysis module 922, a historical fault data retrieval module 923, a topology analysis module 924, and a candidate fusion and deduplication module 925. The decision fusion layer 930 includes a causal inference engine 931, a forward inference engine 932, and a backward inference engine 933. The multi-strategy inference layer 940 includes a multi-strategy integrator 941, a conflict resolver 942, a confidence calculator 943, and a result generator 944. The method 200 for determining the root cause of network faults provided in this embodiment of the invention can be run in the network fault root cause diagnosis system 900.

[0047] In step 202, the computing device 100 acquires real-time network data to construct input features. The real-time data includes at least alarm events, time-series indicator data, and network topology information.

[0048] Regarding alarm events, such as equipment alarm events and fault alarm events.

[0049] Regarding timing metrics data, this should include at least the following: timing metrics data related to CPU utilization, traffic, latency, and packet loss rate.

[0050] In some embodiments, a method for acquiring real-time network data includes, for example, the following: a computing device 100 receives alarm events reported by devices via an event collector 912; identifies and structures key symptoms from the received alarm events via a symptom extractor 913; maintains multi-time-window indicator data via a time-series analyzer 911; and constructs a device, interface, and link graph model based on a link layer discovery protocol and a device discovery protocol to acquire network topology information.

[0051] Regarding alarm events reported by network devices, such as Simple Network Management Protocol Trap (SNMP Trap) and System Logging Protocol (Syslog).

[0052] Regarding critical symptoms, for example, symptoms at the critical (CRITICAL) level and error (ERROR) level are identified as critical symptoms.

[0053] For example, the network topology service module 914 can maintain the network topology through the Link Layer Discovery Protocol (LLDP) and the Cisco Discovery Protocol (CD), and provide an API for querying upstream / downstream nodes.

[0054] In some embodiments, the computing device 100 receives alarm events reported by devices via the event collector 912, including, for example, receiving alarm events reported by network devices; extracting the alarm event timestamp, network device identifier, alarm event type, and alarm event severity based on the received alarm events; and associating the received alarm events with super events. A super event, for example, refers to a composite event formed by aggregating multiple alarms that are close in time, from the same device or interface, topologically related, and causally connected, which is different from alarms directly reported by devices; for example, if the same port experiences "low optical power, interface down, BGP disconnection" within 30 seconds, it is aggregated into a super event of "port link failure".

[0055] Therefore, the above solution solves the problems of scattered granularity and insufficient correlation of individual alarms by associating multiple alarm events as super events, and improves the unified organization capability and fault context expression capability of multiple alarm events.

[0056] In some embodiments, the computing device 100 identifies and structures key symptoms from received alarm events via a symptom extractor 913, including: extracting structured symptoms from the received alarm events; identifying key-level symptoms and error-level symptoms from the extracted structured symptoms to generate a symptom set; and extracting implicit symptoms from the symptom set.

[0057] Implicit symptoms refer to those that cannot be directly obtained from a single alarm and need to be deduced through timing or correlation analysis. Examples of implicit symptoms include: CPU usage exceeding 80% for 5 consecutive minutes, interface jitter occurring 5 times within 5 minutes, continuously increasing packet loss rate, simultaneous disconnection of multiple downstream nodes, and increased PFC frames with decreased throughput.

[0058] Therefore, the above solution can solve problems such as redundant original alarm information, lack of prominence of key fault characteristics, and difficulty in discovering hidden fault information, thereby improving the accuracy and completeness of fault symptom representation.

[0059] In some embodiments, the computing device 100 maintains multi-time-window metric data via a timing analyzer 911, including: collecting timing metric data regarding CPU utilization, traffic, latency, and packet loss rate; dividing the time windows into multiple groups of time windows with different window sizes; and based on the multiple groups of time windows, detecting abnormal patterns in terms of spikes, persistence, and trends for the collected timing metric data. For example, the multiple groups of time windows with different sizes could be three groups of time windows of different sizes, such as "60 seconds, 5 minutes, and 30 minutes".

[0060] Therefore, the above scheme, by using multiple time windows to analyze indicators such as CPU utilization, traffic, latency, and packet loss rate, can solve the problem that a single time scale is difficult to simultaneously identify sudden anomalies, continuous anomalies, and trend anomalies, and improve the time scale adaptability of network performance anomaly detection.

[0061] In some embodiments, the computing device 100 acquires real-time network data for constructing input features, including acquiring super events, symptom sets, and time-series indicator data to construct input features. The super events are associated with network device identifiers, interface identifiers, and diagnosis types. The symptom sets include critical-level symptoms and error-level symptoms. The time-series indicator data includes time-series indicator data for CPU utilization, traffic, latency, and packet loss rate over a predetermined time period.

[0062] Therefore, the above solution constructs a multi-dimensional input feature that simultaneously includes equipment association, diagnosis type, fault symptoms and performance change information by unifying and integrating super events, structured symptoms and multiple time-series indicators. This solves the problem of lack of a unified diagnostic context among multi-source network data and improves the feature completeness and relevance of subsequent root cause analysis.

[0063] In step 204, the computing device 100 generates a set of candidate root causes based on the input features and via a multi-dimensional analysis model.

[0064] The multi-dimensional analysis model includes, for example, the following dimensions: diagnostic mapping dimension, symptom analysis dimension, historical case dimension, and topology analysis dimension.

[0065] In some embodiments, a method for generating a candidate root cause set based on input features via a multi-dimensional analysis model includes, for example,: querying a predefined fault type and root cause mapping table via a diagnostic mapping module 921 to map fault types to first candidate root causes; grouping similar key symptoms using a clustering algorithm via a symptom analysis module 922 to infer second candidate root causes based on identified and structured key symptoms; obtaining third candidate root causes of similar historical cases via a historical fault data retrieval module 923 based on vectorized retrieval and the KNN algorithm; calculating fault propagation paths based on a network topology graph via a topology analysis module 924 to determine the root cause device of the fault propagation path from the affected area to obtain a fourth candidate root cause; and deduplicating and sorting the first, second, third, and fourth candidate root causes via a candidate fusion and deduplication module 925 to generate a candidate root cause set. The following will combine... Figure 3 The method 300 for generating a candidate root cause set according to embodiments of the present invention will be described in detail here, and will not be repeated. Thus, by generating candidate root causes in parallel from multiple analytical dimensions, the probability of missing true root causes is reduced, and a candidate range with high coverage is provided for subsequent inference.

[0066] At step 206, the computing device 100 outputs multiple inference results about the root causes of the failure based on the candidate root cause set via multiple inference engines.

[0067] Regarding the multiple inference engines, they include, for example: abductive reasoning engine 931, forward reasoning engine 932, and backward reasoning engine 933.

[0068] In some embodiments, based on a set of candidate root causes, multiple inference results regarding the root causes of the failure are output via multiple inference engines. For example, this includes: calculating the likelihood and confidence of each candidate root cause in the set of candidate root causes under given symptom conditions via abductive reasoning engine 931 to generate abductive reasoning results; verifying the rationality of the symptom propagation chain starting from each candidate root cause in the set via forward inference engine 932 to generate forward inference results; and confirming the feasibility of each candidate root cause in the set via backward inference engine 933 through hypothesis testing and constraint checks to generate backward inference results. The following will combine... Figure 5The method 500 for generating inference results according to embodiments of the present invention will not be described in detail here. Thus, by having multiple inference engines output multiple inference results regarding the root causes of faults, different inference strategies can verify candidate root causes from different perspectives, fully leveraging the complementary advantages of various inference methods and improving diagnostic accuracy and fault tolerance in complex fault scenarios.

[0069] At step 208, the computing device 100 aggregates, resolves conflicts, and calculates confidence for at least a plurality of inference results about the root causes of the fault, so as to output diagnostic results about the root causes of the network fault.

[0070] In some embodiments, a method for outputting root cause diagnosis results for network faults includes, for example,: aggregating abductive reasoning results, forward reasoning results, and backward reasoning results via a multi-policy integrator 941 to generate aggregated reasoning results; processing conflicts in the aggregated reasoning results via a conflict resolver 942 to output conflict-free reasoning results; and calculating the confidence level of the conflict-free reasoning results based on a voting mechanism and evidence strength via a confidence calculator 943, so as to output the root cause diagnosis results for network faults via a result generator 944. The following will combine... Figure 7 A method 700 for outputting diagnostic results of the root cause of a fault, according to an embodiment of the present invention, will not be described in detail here. Thus, the present invention, by fusing multiple inference results and resolving conflicts between different inferences, generates a final diagnostic result with quantified confidence, thereby improving the stability, reliability, and interpretability of the final diagnostic result.

[0071] In the above scheme, the present invention acquires real-time data including alarm events, time-series index data, and network topology information to construct input features from multiple dimensions such as fault events, performance changes, and network connection relationships, thereby improving the completeness of fault information and solving the problem of missing fault features and inaccurate reflection of fault status caused by a single data source, providing a more comprehensive data foundation for subsequent root cause analysis. The present invention also generates a candidate root cause set based on the constructed input features through a multi-dimensional analysis model, and generates candidate root causes in parallel through multiple analysis dimensions, reducing the probability of missing true root causes and providing a candidate range with high coverage for subsequent inference. This invention also utilizes the generated candidate root cause set and multiple inference engines to output multiple inference results regarding the root causes of faults. This allows different inference strategies to verify candidate root causes from different perspectives, fully leveraging the complementary advantages of various inference methods and improving diagnostic accuracy and fault tolerance in complex fault scenarios. Furthermore, this invention aggregates, resolves conflicts, and calculates confidence scores for at least multiple inference results regarding the root causes of faults to output diagnostic results for network fault root causes. By fusing multiple inference results and resolving conflicts between different inferences, a final diagnostic result with quantified confidence is generated, improving the stability, reliability, and interpretability of the final diagnostic result. Therefore, this invention can significantly improve the accuracy, interpretability, and automation of fault root cause determination in complex networks and complex fault scenarios.

[0072] The following combination Figure 3 This describes the method 300 used to generate the candidate root cause set. Figure 3 A flowchart of a method 300 for generating a candidate root cause set according to an embodiment of the present invention is shown. It should be understood that method 300 can, for example, be implemented in... Figure 9 The described network fault root cause diagnosis system is executed at point 900. It can also be used in... Figure 1 The described computing device 100 performs the operation. It should be understood that method 300 may also include additional actions not shown and / or the actions shown may be omitted, and the scope of the invention is not limited in this respect.

[0073] At step 302, the computing device 100 queries a predefined fault type and root cause mapping table via the diagnostic mapping module in order to map the fault type to the first candidate root cause.

[0074] For example, if the diagnosed fault type is "LINK_FAILURE", the predefined fault type and root cause mapping table is queried to directly map the fault type "LINK_FAILURE" to the possible root cause "optical module fault". Thus, this invention can quickly obtain the root cause related to the current fault type using existing fault knowledge, improving the efficiency of initial candidate generation.

[0075] At step 304, the computing device 100, via the symptom analysis module, uses a clustering algorithm to group similar key symptoms based on the identified and structured key symptoms in order to infer a second candidate root cause.

[0076] For example, computing device 100 identifies observed critical symptoms at both the CRITICAL and ERROR levels (e.g., "device offline" (typically CRITICAL level), "BGP disconnection" (potentially ERROR level, or escalated to CRITICAL level due to widespread outage)); it then groups similar critical symptoms using a clustering algorithm to infer possible root causes (i.e., second candidate root causes). Thus, by clustering critical symptoms and inferring second candidate root causes, potential failure modes can be discovered from the similarities and relationships between symptoms, improving the ability to analyze unknown and complex combinations of symptoms.

[0077] At step 306, the computing device 100 obtains the third candidate root cause of similar historical cases through the historical fault data retrieval module, based on vectorized retrieval and the KNN algorithm.

[0078] In some embodiments, a third candidate root cause of similar historical cases is obtained through a historical fault data retrieval module based on vectorized retrieval and the KNN algorithm. This includes, for example, using a natural language vectorization module to convert the description of the fault event into a high-dimensional vector; retrieving multiple historical fault data that are most similar to the historical fault data based on the high-dimensional vector and the KNN algorithm; and extracting the root causes of the faults from the multiple historical fault data to obtain the third candidate root cause.

[0079] For example, by converting the description of a fault event into a high-dimensional vector using Sentence-BERT, and then retrieving the top-10 most similar historical cases from the Elasticsearch KNN algorithm, the root causes of these cases are extracted as third-candidate root causes. Thus, this approach, by converting fault event descriptions into high-dimensional semantic vectors and combining them with the KNN algorithm to retrieve similar historical fault data, can improve the accuracy of historical case matching and the efficiency of fault root cause reuse; furthermore, by utilizing historical fault experience to assist in current fault diagnosis, it can reduce the computational and inference costs of analyzing recurring faults.

[0080] At step 308, the computing device 100 calculates the fault propagation path based on the network topology diagram via the topology analysis module, and determines the root cause device of the fault propagation path from the affected area in order to obtain a fourth candidate root cause.

[0081] Regarding the determination of the root cause device from the affected area's fault propagation path, for example, the upstream node of the fault propagation path can be reversed to identify the most likely root cause device. Therefore, this invention can narrow down the range of root cause devices based on the fault's impact range and network connectivity, thereby improving the ability to locate topology-related faults.

[0082] In step 310, the computing device 100 performs deduplication and sorting of the first candidate root cause, the second candidate root cause, the third candidate root cause, and the fourth candidate root cause via a candidate fusion and deduplication module in order to generate a set of candidate root causes.

[0083] In the above scheme, the present invention combines multiple root cause generation methods such as fault mapping, symptom clustering, historical case retrieval and topology propagation analysis, which can solve the problem that the coverage of a single root cause analysis method is limited and it is difficult to adapt to complex network faults. It can also improve the completeness and diversity of candidate root causes, and reduce the search scale of subsequent inference through fusion and deduplication.

[0084] The following combination Figure 4 Explain the methods used for deduplication and sorting 400. Figure 4 A flowchart of a method 400 for deduplication and sorting according to an embodiment of the present invention is shown. It should be understood that method 400 can, for example, be used in... Figure 9 The described network fault root cause diagnosis system is executed at point 900. It can also be used in... Figure 1 The described computing device 100 performs the operation. It should be understood that method 400 may also include additional actions not shown and / or the actions shown may be omitted, and the scope of the invention is not limited in this respect.

[0085] In step 402, the computing device 100 fuses the first candidate root cause, the second candidate root cause, the third candidate root cause, and the fourth candidate root cause to form a list of candidate root causes, so as to calculate the evidence strength score for each candidate root cause.

[0086] One method for calculating the strength of evidence score for each candidate root cause is to synthesize evidence scores from multiple dimensions. These dimensions may include, for example, diagnostic matching, symptom coverage, and topological consistency. Therefore, by fusing candidate root causes from multiple sources and calculating their strength of evidence scores, the impact of different analytical approaches on the same root cause can be comprehensively considered, thus forming a unified basis for evaluating candidate root causes.

[0087] Regarding the diagnostic match score, it is used, for example, to reflect the degree of match between the root cause and the diagnostic type. In some embodiments, the computing device 100 calculates the degree of match between each candidate root cause and the diagnostic type for each candidate root cause in the candidate root cause list to obtain a diagnostic match score. Table 1 below illustrates the code used to generate the diagnostic match score (diagnosis_match).

[0088] Table 1

[0089] Where 1.0 represents an exact match, 0.5 represents a partial match, and 0.0 represents no match; the code comments above state: 1.0 is obtained when the "diagnosis type to root cause mapping table" is exactly matched; 0.5 is obtained only when the root cause category is the same as the diagnosis category; otherwise, 0 is obtained.

[0090] Therefore, the present invention can assess the correlation between candidate root causes and the current fault category by calculating the degree of matching between candidate root causes and diagnostic types.

[0091] Regarding the symptom coverage score, it is used, for example, to reflect the degree of overlap between the expected symptoms and the actual observed symptoms of the root cause. In some embodiments, the computing device 100 calculates the degree of coverage between the expected symptoms and the actual symptoms of each candidate root cause to obtain a symptom coverage score. For example, the symptom coverage score is calculated as shown in the following formula (1).

[0092] symptom_coverage = |observed_symptoms ∩ expected_symptoms| / |observed_symptoms| (1).

[0093] Here, `symptom_coverage` represents the symptom coverage score. `observed_symptoms` (equivalent to `E_r`) represents the set of observed symptoms, with a score of 0 when `|observed_symptoms|=0`. The symptom coverage score ranges from [0,1], with a higher value indicating higher coverage. Therefore, this invention evaluates the explanatory power of candidate root causes for observed fault phenomena by calculating the coverage between expected and actual symptoms, thereby improving the symptom correlation of candidate root causes.

[0094] Regarding the topology consistency score, it is used, for example, to reflect whether the root cause device is located upstream of the fault propagation. In some embodiments, the computing device 100 determines whether the root cause device is located upstream of the fault propagation for each candidate root cause in order to obtain a topology consistency score.

[0095] For example, Table 2 below shows the code used to generate the topology_consistency score.

[0096] Table 2

[0097] Here, "1.0, if device_in_upstream_path" means "1.0 if the candidate root cause device is located upstream of the propagation", "0.5, if device_in_affected_zone" means "0.5 if the candidate device is not upstream but is in the affected zone", and "0.0, if device_in_downstream_path" means "0 if the candidate device is located downstream or has no topological association".

[0098] For example, the computing device 100 calls the API interface provided by the network topology service, inputs relevant parameters of the candidate root cause (such as device identifier, range of affected devices and / or interfaces, and fault propagation path), and queries topology information (such as the hierarchical topology connection relationship of all network devices, interfaces, and links; the propagation path of this fault, and the upstream and downstream affiliation of the affected area). Based on the query results, it determines the upstream, affected area, or downstream location of the candidate root cause device, and calculates the topology consistency score of the candidate root cause. Thus, this invention verifies the rationality of the root cause location through network topology relationships, thereby eliminating erroneous candidate root causes with inconsistent topology locations.

[0099] In some embodiments, the computing device 100 calculates the strength of evidence score for each candidate root cause based on the diagnostic matching score, symptom coverage score, and topological consistency score. For example, the strength of evidence score for each candidate root cause is calculated as shown in the following formula (2):

[0100] For example, in this model, evidence_strength represents the strength of evidence score; diagnosis_match score has a weight of 0.5; symptom_coverage score has a weight of 0.3; and topology_consistency score has a weight of 0.2. Therefore, this invention can comprehensively consider the diagnosis_match score, symptom_coverage score, and topology_consistency score to calculate the strength of evidence score for candidate root causes from multiple dimensions, thereby improving the credibility of the evidence strength.

[0101] In step 404, the computing device 100 performs deduplication on the fused candidate root cause list so as to retain the candidate root cause with the highest evidence strength score among the same multiple candidate root causes.

[0102] Regarding deduplication, such as deduplication based on deduplication rules, Table 3 below shows the code used to implement deduplication rules.

[0103] Table 3

[0104] Where `key` represents the composite key, which is (root_cause_id, device_id, interface_id); the code above indicates that for candidates with the same composite key, only the one with the highest strength of evidence is retained: r k = argmax E(r), r∈Rk. Where “candidate” means “candidate root cause” and “candidates” means “the set of all candidate root causes in the candidate root cause list”.

[0105] Therefore, the present invention can deduplicate the candidate root causes after fusion, so as to retain the candidate root cause with the highest evidence strength among the duplicate candidates, thereby reducing the redundancy of candidate root causes.

[0106] In step 406, the computing device 100 sorts the candidate root cause list after deduplication in descending order of evidence strength score, and retains a predetermined number of candidate root causes at the top of the sort to generate a candidate root cause set.

[0107] Using the code shown in Table 3 above, for example, the final output is a "Top-20 Candidate Root Cause List," where each candidate root cause includes: root cause identifier (root_cause_id), type (category), device identifier (device_id), interface identifier (interface_id), and evidence strength (evidence_strength). Alternatively, a candidate root cause may also include: candidate root cause source, expected symptoms, prior probability, and scoring details; where interface_id can be empty. Therefore, this invention can sort candidate root causes in descending order of evidence strength and retain a predetermined number of them, prioritizing high-confidence candidates with sufficient evidence strength, thereby controlling the computational scale of subsequent inference and improving inference efficiency.

[0108] In the above-described scheme, this invention addresses the problem of interference with subsequent reasoning caused by factors such as duplicate candidate root causes, excessive number of candidates, and insufficient evidence strength or low-confidence candidates by scoring, deduplicating, and ranking candidate root causes from multiple sources. This reduces the reasoning search space while preserving multi-source diagnostic information. Furthermore, it quantifies the evidence of candidate root causes by comprehensively considering diagnostic type matching, expected symptom coverage, and topological location consistency, solving the problem that a single scoring criterion is insufficient to accurately evaluate the evidence strength of candidate root causes, and improving the accuracy and interpretability of the candidate root cause evidence strength ranking.

[0109] The following combination Figure 5 This describes the method used to generate the inference results (500). Figure 5 A flowchart of a method 500 for generating inference results according to an embodiment of the present invention is shown. It should be understood that method 500 can, for example, be implemented in... Figure 9 The described network fault root cause diagnosis system is executed at point 900. It can also be used in... Figure 1 The described computing device 100 performs the operation. It should be understood that method 500 may also include additional actions not shown and / or the actions shown may be omitted, and the scope of the invention is not limited in this respect.

[0110] At step 502, the computing device 100 calculates the likelihood and confidence of each candidate root cause in the candidate root cause set under given symptom conditions via the abductive reasoning engine in order to generate the abductive reasoning result.

[0111] Abductive reasoning, for example, is a form of inverse reasoning, defined as "finding the explanation that best explains the observed fact among all possible explanations"; unlike deductive reasoning (general to specific) and inductive reasoning (specific to general), abductive reasoning infers the most reasonable explanation from the specific to the specific.

[0112] In some embodiments, the method for generating abductive reasoning results includes, for example,: a computing device 100 acquiring a set of candidate root causes, a set of observed symptoms, and super-event context information; for each candidate root cause in the candidate root cause set, querying a predetermined knowledge base to obtain the theoretical expected symptoms corresponding to each candidate root cause, the predetermined knowledge base storing the mapping relationship between root causes and symptoms; calculating the likelihood of generating observed symptoms under given root cause conditions; calculating the degree of overlap between expected symptoms and observed symptoms to obtain coverage; extracting typical temporal patterns of multiple performance index data from expected symptoms to calculate the temporal similarity between the current observed temporal sequence and the expected temporal sequence using a dynamic time warping algorithm; calculating a motivation score based on temporal consistency, topological consistency, and temporal similarity; performing a weighted fusion calculation based on the likelihood, coverage, prior probability, and motivation score of each candidate root cause to obtain a comprehensive score; and traversing the comprehensive scores of each candidate root cause to obtain the candidate root cause with the highest comprehensive score as the abductive reasoning result. The following will combine... Figure 6 The method 600 for generating abductive reasoning results according to embodiments of the present invention will not be described in detail here. Thus, the present invention uses an abductive reasoning strategy to calculate the likelihood and confidence of candidate root causes under given symptom conditions, enabling the reverse screening of the most likely root causes of failures from observed fault phenomena.

[0113] At step 504, the computing device 100 verifies the plausibility of the symptom propagation chain from each candidate root cause in the candidate root cause set via a forward inference engine in order to generate a forward inference result.

[0114] In some embodiments, the method for generating forward reasoning results includes, for example, the computing device 100 constructing a symptom propagation chain based on causal relationships, starting from the expected symptoms of each candidate root cause in the candidate root cause set. An example of constructing a symptom propagation chain based on causal relationships is: optical module failure → low optical power → interface down → BGP disconnection.

[0115] In some embodiments, the method for generating forward inference results further includes, for example, the computing device 100 verifying whether the symptoms in the expected symptoms are also in the observed symptoms in order to calculate link coverage. For example, verifying whether the symptoms in the expected symptoms (Er) are also in the observed symptoms. The following example of a method for calculating link coverage is illustrated by formula (3).

[0116] C_chain(r)=|S(chain_r)∩O| / |S(chain_r)|. (3).

[0117] Where chain_r is the ordered symptom propagation chain corresponding to root cause r, S(chain_r) is the set of symptom nodes that do not contain root cause nodes, and O represents observed symptoms. Therefore, this invention can evaluate the degree of consistency between the causal propagation process corresponding to a candidate root cause and the actual fault phenomenon through link coverage.

[0118] In some embodiments, the method for generating forward inference results may further include, for example, the computing device 100 calculating a forward score based on link coverage and link length penalties to generate forward inference results. For example, the method for calculating the forward score is illustrated below using formula (4).

[0119] Score_F=max(0, C_chain-λF·P_len)(4).

[0120] Here, P_len is the normalized link length penalty, and λF is, for example, 0.5. Therefore, by introducing a long link penalty, excessively long or complex propagation paths can be suppressed while maintaining the scope of symptom explanation, thus improving the rationality of the forward inference results. Through the forward inference strategy, the symptom propagation chain corresponding to the candidate root cause is verified. The symptom propagation chain is constructed and verified starting from the candidate root cause, solving the problem that static matching between the root cause and a single symptom is insufficient to verify the causal process of the fault. This improves the verification capability of the fault propagation logic and reduces the impact of overly complex inference paths through the link length penalty.

[0121] At step 506, the computing device 100 confirms the feasibility of each candidate root cause in the candidate root cause set through hypothesis testing and constraint checks via the reverse reasoning engine, so as to generate the reverse reasoning result.

[0122] In some embodiments, generating reverse reasoning results includes, for example, verifying whether each candidate root cause in the candidate root cause set is a known root cause in a predetermined knowledge base, and whether the expected symptoms are stable, in order to obtain a knowledge base matching score. Here, the expected symptoms corresponding to a candidate root cause r are at least one, and E_r represents the set of expected symptoms corresponding to candidate root cause r.

[0123] For example, starting with a candidate root cause r, the system queries a predetermined knowledge base to confirm whether "r" is a known root cause and whether the expected symptoms are stable, thereby verifying whether "r → Er (expected symptoms)" is stable. Thus, this invention can improve the reliability of diagnostic results by verifying whether a candidate root cause belongs to a known root cause in the knowledge base and checking the stability of its expected symptoms, thereby evaluating the degree of matching between the candidate root cause and existing fault knowledge.

[0124] In some embodiments, the method for generating reverse reasoning results further includes, for example: checking whether the candidate root cause conflicts with known constraints in order to determine a consistency score; and calculating a reverse score based on the consistency score and the knowledge base matching score in order to generate reverse reasoning results.

[0125] For example, if a candidate root cause r requires "equipment model X", but the actual equipment model is Y, then the candidate root cause r is confirmed to conflict with the known constraints. Regarding the consistency score, for example, consistency={1.0, no conflict; 0.0, conflict exists}, the value is 1.0 when there is no conflict and 0.0 when there is a conflict.

[0126] For example, the following example demonstrates how to calculate the reverse score using formula (5).

[0127] backward_score =0.7·consistency + 0.3·knowledge_base_match (5).

[0128] Wherein, `backward_score` represents the backward score, `consistency` is the constraint consistency score, and `knowledge_base_match` is the knowledge base matching score, with 0.3 and 0.7 representing weights. Therefore, this invention can improve the logical consistency of candidate root causes by checking whether they conflict with known constraints, eliminating infeasible root causes, and calculating the backward score based on the consistency score and knowledge base matching score to comprehensively evaluate the knowledge support and constraint satisfaction of candidate root causes; thereby reducing erroneous diagnoses that conflict with existing knowledge or network constraints.

[0129] In the above scheme, the present invention sets up three reasoning strategies, namely abductive, forward and backward, to verify candidate root causes from different perspectives such as probabilistic association, causal propagation and hypothesis constraints. This solves the problem that a single reasoning mechanism cannot simultaneously take into account probabilistic rationality, causal integrity and constraint consistency, thereby improving the accuracy and fault tolerance of fault diagnosis in complex networks.

[0130] The following combination Figure 6 This describes the method 600 used to generate abductive reasoning results. Figure 6 A flowchart of a method 600 for generating abductive reasoning results according to an embodiment of the present invention is shown. It should be understood that method 600 can, for example, be used in... Figure 9 The described network fault root cause diagnosis system is executed at point 900. It can also be used in... Figure 1 The described computing device 100 performs the operation. It should be understood that method 600 may also include additional actions not shown and / or the actions shown may be omitted, and the scope of the invention is not limited in this respect.

[0131] At step 602, the computing device 100 acquires the candidate root cause set, the observed symptom set, and the super event context information.

[0132] For example, the causal reasoning engine receives three types of data. These include, for instance, a set of candidate root causes, a set of observed symptoms, and super-event context information. The candidate root cause set contains a list of the top-20 candidate root causes; the set of observed symptoms includes, for example, structured symptoms extracted from the event; and the super-event context information includes, for example, device ID, interface ID, and diagnosis type. This data provides causal reasoning with complete information on root cause candidates, fault phenomena, and fault environment.

[0133] At step 604, the computing device 100 queries a predetermined knowledge base for each candidate root cause in the candidate root cause set in order to obtain the theoretical expected symptoms corresponding to each candidate root cause. The predetermined knowledge base stores the mapping relationship between root causes and symptoms.

[0134] For example, the reasoning algorithm is used to perform reasoning on each candidate root cause in sequence. First, the knowledge base is queried to obtain the expected symptom set corresponding to the candidate root cause. Then, the candidate root cause and observed symptoms are obtained. For each candidate root cause r, the expected symptom set E_r, prior probability and time sequence template are queried. Then, the likelihood, coverage, motivation score and comprehensive score are calculated. Finally, the root cause with the highest score is selected.

[0135] At step 606, the computing device 100 calculates the likelihood of producing the observed symptoms under given root cause conditions.

[0136] Likelihood, for example, is used to reflect the ability of a root cause to explain the observed fault symptoms. The higher the likelihood value, the higher the probability that the observed fault symptoms are caused by that root cause.

[0137] For example, the likelihood L=P(O∣r) of the observed symptom set O given a candidate root cause r can be calculated, for example, by using the example of formula (6) to calculate the likelihood.

[0138] P(O|r) = Π o ∈OP(o|r) (6)。

[0139] Wherein, the probability of a single symptom P(o|r) = {0.9 if o∈Er, 0.9 if o Er is 0.1}, where Er represents the expected set of symptoms of the root cause r, and Er ⊆ S (the complete set of symptoms).

[0140] For example, the root cause r = optical module failure, and the observed symptoms O = frequent port jitter, packet loss, and low optical power alarms; that is, first assume: the root cause of the fault is optical module failure (given the root cause condition), then judge: if the optical module is faulty, will the above set of symptoms be likely to occur? If there is a high degree of agreement, then the likelihood P(O|r) is high, indicating that the root cause can reasonably explain the existing fault phenomenon. Another example is root cause r = CPU overload, and observed symptoms O = low optical power and port down. Even assuming CPU overload is the root cause, optical link-related alarms are almost never generated, and the likelihood is low, indicating that the root cause cannot explain the current symptoms.

[0141] Therefore, the present invention can evaluate the probabilistic explanatory power of each candidate root cause for the current failure phenomenon by calculating the likelihood of the observed symptoms generated by the candidate root causes.

[0142] At step 608, the computing device 100 calculates the degree of overlap between the expected symptoms and the observed symptoms in order to obtain coverage.

[0143] For example, the overlap between expected and observed symptoms is calculated as C = |O∩Er| / |O|, where C represents the overlap, O represents the observed symptoms, and Er represents the set of expected symptoms corresponding to the candidate root cause r. Coverage is used to measure the degree of match between the expected symptoms corresponding to the candidate root cause and the observed symptoms actually observed on-site; the higher the coverage value, the more consistent the root cause is with the current failure facts.

[0144] Therefore, this invention obtains coverage by calculating the degree of overlap between expected symptoms and observed symptoms, thereby evaluating the completeness and authenticity of the candidate root cause's explanation of the actual failure phenomenon.

[0145] At step 610, the computing device 100 extracts typical time-series patterns of multiple performance index data from the expected symptoms in order to use a dynamic time warping algorithm to calculate the time-series similarity between the current observed time series and the expected time series.

[0146] Typical timing patterns refer to sequences of changes in indicators before and after a root cause event, extracted from historical confirmed cases or expert knowledge. Examples include slow CPU usage increases, sudden traffic spikes, continuous decreases in optical power, and periodic spikes in PFC frames.

[0147] Several performance metrics are mentioned, such as CPU utilization, traffic, latency, and packet loss rate.

[0148] Regarding typical timing patterns, such as standardized change curves / timing change patterns of performance indicators like CPU, traffic, latency, and packet loss rate when a certain type of fault root cause occurs, which are pre-stored in the knowledge base, this is also known as a fault baseline timing template. Each fault root cause corresponds to a unique set of indicator fluctuation patterns, unaffected by the speed of fault occurrence or duration, retaining only the unique change pattern characteristics of the fault, which serves as the standard reference template for DTW matching.

[0149] Dynamic Time Warping (DTW) is an algorithm used to calculate the similarity between two time series. It finds the optimal alignment by dynamically bending the time axis, making it robust to time shifts and noise. DTW similarity is widely used in speech recognition, data mining, and time series analysis. DTW similarity is used to capture the similarity of temporal patterns, helping to identify performance-related root causes.

[0150] The calculation of the temporal similarity between the current observed time series and the expected time series using the dynamic time warping algorithm includes, for example, the following steps.

[0151] Input two time series segments: Time series A: [a1, a2, …, a n Time series B: [b1, b2, …, b m ], where time series A is the field observation time series, n is the sampling point of series A, time series B is the root cause typical time series template, and m is the number of template sampling points of series B.

[0152] First, calculate the cost matrix D, D[i][j] = distance(a i , b j ), where a i For the i-th sampling point of time series A, b j For the j-th sampling point corresponding to time series B, the distance is usually expressed using Euclidean distance, for example, distance(a, b) = √[(a - b)]. 2 ],D[i][j] = distance(a i , b j ) represents the local difference between ai and bj.

[0153] Next, calculate the cumulative cost matrix C.

[0154] An exemplary calculation method for the cumulative cost matrix C is shown in formula (7).

[0155] C[i][j] = D[i][j] + min( C[i-1][j-1], # diagonal C[i-1][j], # top C[i][j-1] # left) (7).

[0156] Where C[i][j] is a dynamic programming matrix, representing the minimum cumulative difference after optimal alignment of two prefix segments.

[0157] Furthermore, the DTW distance is extracted, DTW_dist = C[n][m], which represents the cumulative difference after optimal alignment of the complete sequence.

[0158] In addition, normalization is performed. For example, the normalization method is shown in formula (8).

[0159] normalized_dtw = DTW_dist / (n + m) (8).

[0160] Here, normalized_dtw represents the standardized distance, and DTW_dist / (n + m) represents the distance based on the total length of the two time series segments, n + m. Thus, normalization eliminates numerical bias caused by varying time series lengths, enabling fair comparison of templates of different lengths.

[0161] Then, the temporal similarity is converted, and the conversion method is as shown in formula (9).

[0162] DTW_sim = 1 - normalized_dtw / max_distance(9).

[0163] Where max_distance is a predefined maximum distance constant; normalized_dtw represents the standardized distance; DTW_sim represents the time series similarity, and its value range is, for example, [0,1]. The closer to 1, the more similar the on-site time series and the fault template are (i.e., the root cause has a high degree of matching), and the closer to 0, the more inconsistent the two time series fluctuation patterns are (i.e., the root cause has a low degree of confidence).

[0164] In addition, DTW_sim_total can be obtained by weighted fusion of the similarity of single indicators such as CPU, traffic, latency, and packet loss rate, where DTW_sim_total = Σ(qk·DTW_sim,k) / Σqk. For example, DTW_sim in formula (9) can also be replaced by DTW_sim_total. When there is only one valid indicator, DTW_sim and DTW_sim_total are the same.

[0165] Therefore, this invention extracts typical timing patterns of performance indicators such as CPU, traffic, and latency from expected symptoms, and uses the Dynamic Time Warping (DTW) algorithm to calculate the similarity (DTW_sim) between the current observed timing and the expected timing. By comparing the current timing with the expected timing while allowing non-linear changes in the time axis, the accuracy of timing pattern matching is improved.

[0166] At step 612, the computing device 100 calculates the motivation score based on temporal consistency, topological consistency, and temporal similarity.

[0167] For example, the computing device 100 calculates the motivation score using formula (10).

[0168] M(r) = 0.4·T + 0.3·P_topo + 0.3·DTW_sim(10).

[0169] Where M(r) represents the motivation score, T(r) represents temporal consistency, P_topo(r) represents topological consistency, and DTW_sim(r) represents temporal similarity.

[0170] Regarding temporal consistency, it is used, for example, to detect whether the root cause occurs earlier than all symptoms, thereby ensuring a causal relationship between the root cause and the symptoms. Regarding topological consistency, it is used, for example, to check whether the root cause is located upstream of the fault propagation. Thus, this invention can calculate a motivation score based on temporal consistency, topological consistency, and temporal similarity, enabling a comprehensive evaluation of the plausibility of candidate root causes in terms of temporal variation and network location.

[0171] At step 614, the computing device 100 performs a weighted fusion calculation based on the likelihood, coverage, prior probability, and motivation score of each candidate root cause to obtain a comprehensive score.

[0172] For example, the computing device 100 can calculate the comprehensive score using formula (11).

[0173] Score = 0.3·L + 0.3·C + 0.2·P + 0.2·M (11).

[0174] Where L represents likelihood, C represents coverage, P represents prior probability, and M represents motivation score; likelihood and coverage each have a weight of 0.3, indicating that these two dimensions are the core indicators for judging root causes; prior probability and motivation score each have a weight of 0.2, used to adjust candidate probabilities and verify the time sequence and topological rationality.

[0175] Therefore, this invention reduces the impact of abnormal single indicators on diagnostic results by weighted fusion of likelihood, coverage, prior probability and motivation score to form a multi-evidence comprehensive score.

[0176] At step 616, the computing device 100 iterates through the comprehensive score of each candidate root cause and obtains the candidate root cause with the highest comprehensive score as the abductive reasoning result.

[0177] For example, the computing device 100 iterates through all candidate root causes based on a predetermined algorithm, repeating the above calculation steps for each candidate root cause to record a comprehensive score for each candidate root cause. After the iteration is complete, the candidate root cause r with the highest score is selected. As the result of abductive reasoning, the root cause r is output. Regarding the root cause r Information such as confidence level and multi-dimensional scoring details.

[0178] In the above scheme, the present invention conducts causal analysis by integrating multiple types of evidence such as root cause likelihood, symptom coverage, prior probability, topological consistency and temporal similarity, which solves the problem that it is difficult to accurately distinguish similar root causes based on a single symptom or a single probability indicator, and improves the probability inference ability and diagnostic accuracy of complex network faults.

[0179] The following combination Figure 7 This invention describes a method 700 for outputting inference results of fault root causes, according to an embodiment of the present invention. It should be understood that method 700 can, for example, be used in... Figure 9 The described network fault root cause diagnosis system is executed at point 900. It can also be used in... Figure 1 The described computing device 100 performs the operation. It should be understood that method 700 may also include additional actions not shown and / or the actions shown may be omitted, and the scope of the invention is not limited in this respect.

[0180] In step 702, the computing device 100 aggregates the abductive reasoning results, forward reasoning results, and backward reasoning results via a multi-strategy integrator to generate an aggregated reasoning result.

[0181] For example, computing device 100 acquires abductive reasoning results, forward reasoning results, and backward reasoning results to extract a root cause list. The abductive reasoning results include root causes, confidence levels, and reasoning paths; the forward reasoning results include root causes, forward scores, and symptom chain coverage; and the backward reasoning results include root causes, backward scores, and consistency scores. The following will combine... Figure 8 The method 800 for aggregating, conflict-handling, and confidence-calculating inference results for root causes of failures according to embodiments of the present invention will not be described in detail here.

[0182] Therefore, this invention integrates the results of abductive reasoning, forward reasoning, and backward reasoning to synthesize diagnostic evidence generated by different reasoning mechanisms, thereby reducing the impact of a single reasoning result on the final diagnosis.

[0183] In step 704, the computing device 100 processes the conflicts in the aggregated reasoning results via a conflict resolver in order to output a reasoning result without conflicts.

[0184] Therefore, the present invention can handle conflicts in the aggregation results in order to eliminate contradictory diagnostic conclusions, thereby avoiding inconsistent results from directly affecting the final root cause determination.

[0185] In step 706, the computing device 100 calculates the confidence level of the inference result that does not conflict, based on the voting mechanism and the strength of evidence, via a confidence calculator, in order to output the root cause diagnosis result of the network failure.

[0186] Therefore, this invention uses a voting mechanism and the strength of evidence to calculate confidence levels, and then quantitatively evaluates the fused diagnostic results, thereby improving the comparability and credibility of the final root cause diagnosis. Thus, the above solution addresses the problem that different reasoning strategies may produce contradictory or inconsistent diagnostic conclusions, thereby improving the stability, reliability, and interpretability of the final root cause diagnosis.

[0187] The following combination Figure 8 This describes a method 800 for aggregating, resolving conflicts, and calculating confidence scores for inference results of root causes of failures, according to embodiments of the present invention. It should be understood that method 800 can, for example, be used in... Figure 9 The described network fault root cause diagnosis system is executed at point 900. It can also be used in... Figure 1 The described computing device 100 performs the operation. It should be understood that method 800 may also include additional actions not shown and / or the actions shown may be omitted, and the scope of the invention is not limited in this respect.

[0188] At step 802, the computing device 100 acquires the abductive reasoning results, the forward reasoning results, and the backward reasoning results in order to extract a root cause list.

[0189] The results of abductive reasoning include, for example, root cause, confidence level, and reasoning path; the results of forward reasoning include, for example, root cause, forward score, and symptom chain coverage; and the results of backward reasoning include, for example, root cause, backward score, and consistency score. Therefore, by extracting information such as root cause, score, confidence level, reasoning path, and symptom chain from these three types of reasoning results, the above scheme can aggregate diagnostic evidence generated by different reasoning strategies, providing a complete basis for subsequent comprehensive decision-making.

[0190] In step 804, if the computing device 100 determines that there is a root cause with a confidence level higher than a predetermined threshold, it identifies the root cause as a root cause diagnosis result of the network failure.

[0191] For example, with a predetermined threshold of 0.8, the system checks if there is a root cause with a confidence level greater than 0.8 in the strategy output. If so, that root cause is directly used as the final output, and the decision criterion is marked as "high confidence level priority". Thus, when a root cause with a confidence level higher than the predetermined threshold exists, it is directly determined as the diagnostic result, enabling rapid root cause localization when a clear and highly reliable diagnostic conclusion is found, thereby improving diagnostic efficiency.

[0192] In step 806, if the computing device 100 determines that there is no root cause with a confidence level higher than a predetermined threshold, it counts the number of times each root cause recommended in the abductive reasoning results, forward reasoning results, and backward reasoning results is counted.

[0193] For example, if no strategy outputs a high-confidence result (e.g., the root cause confidence of no strategy output is >0.8), the voting and statistics phase begins, and the number of votes for each candidate root cause is counted: for example, the number of votes = the number of times the root cause is recommended among all strategies.

[0194] For example, the voting mechanism can be defined using formula (12).

[0195] Votes(r) =Σ_strategy∈{A,F,B} I(root_cause_strategy == r) (12).

[0196] Where Votes(r) represents the total number of votes received by root cause r, I represents the indicator function, which returns 1 if the condition is true and 0 otherwise, and A, F, and B represent the three strategies of abductive reasoning, forward reasoning, and backward reasoning, respectively. root_cause_strategy == r means that the preferred root cause output by a certain strategy is equal to r. Under the three strategies, Votes(r) takes values ​​from 0 to 3.

[0197] For example, if the abductive reasoning strategy recommends "optical module failure", the forward reasoning strategy recommends "optical module failure", and the backward reasoning strategy recommends "configuration error", then "optical module failure" will receive 2 votes and "configuration error" will receive 1 vote.

[0198] In step 808, the computing device 100 statistically analyzes and compares the strength of evidence for each root cause in order to determine whether a dominant root cause exists.

[0199] Regarding the strength of evidence for each root cause, for example, based on expert rules in a knowledge base, count how many rules support that root cause.

[0200] For example, rule support strength can be defined using formula (13).

[0201] evidence_strength(r)=Σ_strategy∈V(r) rule_count_strategy(r)(13).

[0202] Here, V(r) represents the set of strategies supporting root cause r, and rule_count_strategy(r) represents the number of valid rules supporting r within the corresponding strategy. It should be understood that the more rules recommended, the stronger the evidence.

[0203] For example, the computing device 100 compares the strength of evidence for each root cause to determine whether there is a "dominant root cause," for example, the strength of evidence for a dominant root cause is at least 30% higher than that for a suboptimal root cause. For example, if the strength of evidence for the root cause "optical module failure" is 12 and the strength of evidence for the root cause "configuration error" is 5, then "optical module failure" is the dominant root cause.

[0204] In step 810, if the computing device 100 determines that a dominant root cause exists, it identifies the dominant root cause as the root cause diagnosis result of the network fault.

[0205] For example, if the comparison results reveal a dominant root cause, "optical module failure," then "optical module failure" is directly determined as the final output of the network failure root cause diagnosis. For instance, the diagnostic output may include the root cause, confidence level, and decision-making basis, such as "evidence strength comparison" (to reflect trust in the majority of evidence).

[0206] In step 812, if the computing device 100 determines that there is no dominant root cause, it calculates a weighted average confidence level for the root cause in order to determine the root cause diagnosis result for the network failure based on the weighted average confidence level.

[0207] For example, the computing device 100 calculates a weighted average confidence level based on the strategy confidence level, such as weighted average confidence level = (abductive reasoning confidence level × 0.5 + forward reasoning confidence level × 0.3 + backward reasoning confidence level × 0.3).

[0208] In some embodiments, the root cause diagnosis results for network failures may include, for example, a final confidence level and a "weighted average" of the decision criteria, while marking conflict (conflict=true) to alert operations personnel that there are discrepancies between policies in the results and that manual review may be required.

[0209] For example, the weighted average confidence level can be calculated using formula (14).

[0210] Conf_final(r )=[Σ_strategy∈V(r ) w_strategy·Conf_strategy(r ) ] / Σw_strategy (14).

[0211] Where, r V(r) represents the root cause that received the most votes. ) indicates support for the root cause r The set of strategies, where w_strategy represents the strategy weights (e.g., abductive reasoning = 0.5, forward reasoning = 0.3, backward reasoning = 0.2), Conf_strategy(r ) represents the strategy relative to the root cause r The confidence level.

[0212] Therefore, the root cause diagnosis results (i.e., the final output) of network failures include three possible branch states: high confidence direct adoption, dominant root cause selection, and weighted average calculation (with conflict markers). The output structures of these three are different, but they all contain three core fields: root cause, confidence level, and decision basis.

[0213] In some embodiments, the computing device 100 collects feedback data for a predetermined number of days to calculate the rule accuracy of each rule; dynamically updates the accuracy based on each rule; applies a minimum constraint to the dynamically updated rule accuracy; detects trends in the accuracy of each rule; triggers rule review in response to determining that the accuracy of a target rule has decreased three times consecutively, with a cumulative decrease exceeding 20%; detects the rule accuracy of the target rule for the most recent five times in response to no rule review being triggered; triggers rule strengthening in response to determining that the rule accuracy of the target rule for the most recent five times is greater than or equal to 90%; and maintains the current confidence level of the target rule in response to determining that the rule accuracy of the target rule for the most recent five times does not meet the requirement of being greater than or equal to 90%. Regarding the rules, for example, the expert diagnostic rules in the knowledge base are the same as those used for strength of evidence comparison, for example, by using dynamic confidence to weight the number of rules so that feedback updates truly affect conflict resolution.

[0214] For example, the computing device 100 periodically initiates a confidence update process to collect all feedback data within the most recent N days (e.g., 30 days); for example, the feedback data includes the diagnostic correctness label of each rule, user adoption status, system automatic verification results, etc.; the feedback data provides the basis for the calculation of rule accuracy.

[0215] Regarding rule accuracy, it is a core metric used to measure rule quality; the higher the accuracy, the more reliable the rule. For example, for each rule, the total number of times the rule was used and the number of times it was correct within a statistical time window are counted. The accuracy calculation formula is: Accuracy = Total number of correct uses / Total number of uses.

[0216] Regarding dynamic updates, such as calculating new confidence values ​​based on the EWMA formula, for example, the EWMA formula is expressed as follows:

[0217] The new confidence level = 0.7 × historical confidence level + 0.3 × rule accuracy.

[0218] In this design, 0.7 is the inertia factor, retaining 70% of the historical confidence level weight to smooth short-term fluctuations; 0.3 is the learning factor, retaining 30% of the weight of the newly calculated rule accuracy. This invention enables the system to respond quickly to changes in rule quality. This allows confidence to gradually increase as accuracy continues to rise, without drastically decreasing confidence due to a single anomaly.

[0219] Regarding minimum constraints, for example, a lower threshold is used to ensure that the rule accuracy has a chance to recover. For example, the following expression illustrates how the final rule accuracy is calculated: final_confidence = max(new_confidence, threshold_min).

[0220] Here, `final_confidence` represents the final rule confidence, `new_confidence` represents the rule confidence after EWMA update, and `threshold_min` represents the lower bound of confidence. `threshold_min` = 0.3, meaning that even if a rule performs extremely poorly (i.e., its accuracy is very low), the confidence level generally will not drop below 0.3, preserving the rule's eligibility in the knowledge base and the possibility of subsequent recovery.

[0221] Regarding accuracy trend detection, it can be used, for example, to continuously monitor the time trend of rule accuracy. For instance, by comparing the accuracy of the most recent 3 and 5 times using a sliding window, trend detection can help distinguish between temporary fluctuations and long-term declines in rule accuracy.

[0222] Regarding triggering rule review, first check if the accuracy rate has consistently decreased by more than 20% over the last three times (e.g., from 80% to below 64%). If rule review is triggered, it indicates that the rule may no longer be applicable or requires maintenance. Mark the rule as "requires maintenance" and notify experts for intervention. Analyze the reasons for the rule's failure, adjust the rule conditions, or disable the rule altogether. This can prevent low-quality rules from continuously impacting diagnostic results.

[0223] In some embodiments, if the review conditions are not triggered, the system further checks whether the rule accuracy has consistently remained above 90% for the last five times. If the accuracy exceeds 90% for five consecutive times, it indicates that the rule is performing well, and the system determines that the rule can be further strengthened. Strengthening mechanisms may include increasing the rule's recommendation priority and improving the ranking of high-confidence rules among candidates. For example, when a rule's strengthening count reaches five times, a strengthening flag is triggered, and the recommendation strategy is adjusted.

[0224] Regarding maintaining the current confidence level of the target rule, when the accuracy of the target rule does not meet the decline trigger condition (e.g., its accuracy has not continuously decreased by more than 20% in the last 3 times) or the reinforcement trigger condition (e.g., its accuracy has not continuously exceeded 90% in the last 5 times), the target rule is determined to be in a stable range (e.g., accuracy is between 70-90%), the current confidence level of the target rule is maintained, and no adjustment operation is made to it.

[0225] In some embodiments, regardless of whether rule review, rule strengthening, or rule maintenance (maintaining the confidence level of the rule) is triggered, the new confidence level of the rule needs to be persisted to the knowledge base, including information such as the update timestamp, feedback source, and decision basis. The rule data is written back to the confidence field and confidence_history table in the rule table for subsequent analysis and auditing. The entire process forms a closed loop: from feedback collection, accuracy calculation, EWMA update, trend detection, decision triggering to persistent storage.

[0226] To facilitate a further understanding of this plan, the following is combined with... Figure 9 Describe the complete interactive process from submitting a fault diagnosis request to the collaboration of various layers within the system to complete the diagnosis and return the results.

[0227] First, the fault diagnosis request stage: submit a fault diagnosis request through the front-end interface, and upload relevant data such as alarm events, symptom information and problem descriptions. The front-end interface transmits the data to the data access layer 910.

[0228] Second, the data access and processing stage: The data access layer 910 processes the received alarm event data. Key operations include: extracting structured symptoms (such as symptom types CRITICAL / ERROR / WARNING), analyzing time-series patterns (such as slow CPU increases vs. sudden spikes), and extracting fault feature vectors. The processed structured data is then transmitted to the candidate root cause generation layer 920.

[0229] Third, the candidate root cause generation and knowledge retrieval stage: The candidate root cause generation layer 920 receives structured symptoms and temporal features, and performs four-dimensional candidate root cause generation (four dimensions, such as abductive reasoning, forward reasoning, backward reasoning, and knowledge similarity reasoning). Simultaneously, it initiates various queries to the knowledge base, including: root cause mapping queries based on fault type, KNN historical fault data retrieval based on vector similarity, and network topology queries (used to obtain propagation paths); the knowledge base returns the first, second, third, and fourth candidate root causes.

[0230] Fourth, the candidate root cause fusion stage: The candidate root cause generation layer 920 fuses candidate root causes from multiple knowledge sources (e.g., first candidate root cause, second candidate root cause, third candidate root cause, and fourth candidate root cause). For example, considering factors such as evidence strength, confidence priority, diversity guarantee, and stability screening, a comprehensive score is calculated for each candidate root cause. Duplicate or highly similar candidates are eliminated through intelligent deduplication, and a list of Top-K candidate root causes is output to generate a candidate root cause set. The generated candidate root cause set is then output to the multi-strategy inference layer 940.

[0231] Fifth, the multi-strategy reasoning stage: the multi-strategy reasoning layer 940 executes three reasoning strategies (abductive reasoning, forward reasoning, and backward reasoning) for each candidate root cause.

[0232] Among them, abductive reasoning uses a Bayesian probability model to calculate the conditional probability of each candidate under given symptom conditions; forward reasoning is based on rule chain derivation, starting from the symptom node and determining the possible root cause node to propagate along the rule chain; backward reasoning generates hypothetical root causes and verifies whether the root cause can explain all observed symptoms.

[0233] Sixth, Decision Fusion Stage: The decision fusion layer 930 receives the results of the above three reasoning strategies and the evidence strength of each candidate root cause, and performs multi-dimensional fusion, such as including one or more of the following: simple voting, weighted average, high confidence priority, and conflict resolution.

[0234] Simple voting, such as combining the preferred results of various strategies, is a simple yet reliable method. Weighted averaging, for example, assigns different weights based on the historical accuracy of each strategy—for instance, Bayesian weight 0.4, forward inference weight 0.4, and backward inference weight 0.2—to calculate the overall score.

[0235] Regarding prioritizing high confidence, for example, when multiple candidate root cause scores are similar, the candidate corresponding to the rule with high confidence in the knowledge base is selected first.

[0236] Regarding conflict resolution, for example, the strength and confidence of evidence can be used as the basis for conflict adjudication, and the candidate root cause with the strongest supporting evidence can be selected as the final root cause diagnosis result.

[0237] Seventh, Result Return Stage: The decision fusion layer 930 returns the final diagnostic result to the multi-strategy inference layer 940, which then returns the diagnostic result to the front-end interface. The front-end interface displays the diagnostic result.

[0238] Regarding the diagnostic results, they include, for example: root cause name, classification, and detailed description; confidence level: 0.0-1.0 range, with higher confidence indicating greater certainty; reasoning path: displaying the reasoning process and chain of evidence for each strategy; and providing a visual reasoning tree from symptoms to root cause.

[0239] Eighth, User Feedback and Confidence Update Phase: Users (e.g., operations and maintenance personnel) can view the detailed reasoning path and basis. If they adopt the root cause recommended by the system, the feedback is "Correct"; if they reject it or diagnose it themselves, the feedback is "Incorrect". The front-end interface submits user feedback to the knowledge base.

[0240] Ninth, EWMA Dynamic Update Phase: The knowledge base receives user feedback, triggering a dynamic update process for rule confidence. The Exponentially Weighted Moving Average (EWMA) algorithm is used to smoothly update rule confidence. For example, it calculates the rule's accuracy within a time window; it detects accuracy trends and triggers rule review or reinforcement; and it updates the confidence field in the knowledge base, saving the new value and update time. This creates a self-optimizing closed loop, continuously improving rule quality.

[0241] The above solution combines abductive reasoning (suitable for scenarios with multiple symptom combinations and incomplete symptoms), forward reasoning (suitable for scenarios with clear symptom chains), and backward reasoning (suitable for scenarios with few root cause candidates). The fusion of these three reasoning strategies creates a complementary advantage for each scenario, and errors in a single strategy can be corrected by others. For example, abductive reasoning might misdiagnose the root cause as "fiber optic cable breakage," while forward reasoning might find a more suitable symptom of "optical module failure." The final root cause diagnosis would then be "optical module TX anomaly," thus avoiding extreme misdiagnosis. Furthermore, each diagnosis is provided with a clear confidence level (e.g., 0.87), and manual verification is prompted at low confidence levels, while automation is supported at high confidence levels, thereby increasing maintenance personnel's trust in the diagnostic system.

[0242] Then, in the above scheme, the evidence involved in each step of the root cause diagnosis process is recorded, which helps to further improve interpretability and traceability. For example, the abductive reasoning process records: candidate root causes, likelihood, coverage, detailed values ​​of motivation scores, DTW time-series similarity calculation results, etc. For example, the forward reasoning process records: the derived symptom chain, link coverage. For example, the backward reasoning process records: hypothesis testing process, consistency check results. For example, the decision fusion process records: voting statistics (the number of support votes received by each root cause), weighted average calculation (confidence of each strategy and its weight), decision basis (high confidence priority / evidence strength / weighted average / conflict marker).

[0243] For example, if the root cause of the fault is diagnosed as "abnormal TX power of the optical module" with a confidence level of 87%, the recorded information about the inference path should include at least the following:

[0244] 1. Candidate generation (Top-5 candidates with overall evidence strength > 0.75)

[0245] - Optical module TX anomaly (strength of evidence 0.85)

[0246] - Optical module RX anomaly (strength of evidence 0.72)

[0247] - Fiber optic link breakage (strength of evidence 0.68)

[0248] - Interface configuration error (Evidence strength 0.65)

[0249] - CPU overload (strength of evidence 0.62).

[0250] 2. Abductive reasoning (confidence level 87%)

[0251] - Likelihood: 0.82 (85% of observed symptoms were as expected)

[0252] - Symptom coverage: 88% (explains 4 out of 5 symptoms)

[0253] - Motivation score: 0.90

[0254] Temporal consistency: 0.92 (root cause time earlier than all symptoms)

[0255] Topology consistency: 0.88 (root cause located at the very top of the fault propagation)

[0256] DTW timing similarity: 0.91 (CPU elevation mode matches history).

[0257] 3. Forward reasoning (75% confidence level)

[0258] - Symptom chain: Optical module TX low → Interface LED error → BGP oscillation

[0259] - Link coverage: 80%.

[0260] 4. Reverse reasoning (70% confidence level)

[0261] - Hypothesis testing: Root cause validity confirmed via knowledge base.

[0262] - Consistency check: Passed (matches diagnosis type).

[0263] 5. Integrated Decision Making

[0264] - Voting: [Optical module TX anomaly] 2 votes (cause and effect analysis), [Optical module RX anomaly] 1 vote, [Fiber optic link break] 1 vote

[0265] - Weighted average confidence level: (0.87×0.5 + 0.75×0.0 + 0.70×0.2) / 0.7 = 0.83

[0266] - Decision basis: weighted average (votes are not singular).

[0267] 6. Final Conclusion

[0268] - Based on comprehensive analysis, the most likely root cause is the abnormal TX power of the optical module.

[0269] - Recommended repair solutions: Replace the optical module, check the fiber optic link, and verify the optical power parameters.

[0270] The above-mentioned scheme, by adopting DTW time series pattern recognition, can capture the temporal similarity of faults, such as identifying the morphological patterns of time series (upward trend, downward trend, periodicity); and has good time offset and noise immunity. For example, based on DTW, it allows pattern misalignment by dynamically bending the time axis and is not sensitive to time alignment.

[0271] For example, Scenario A: CPU usage slowly increases from 50% to 95% within 30 minutes (performance degradation); Scenario B: CPU usage suddenly jumps from 30% to 95% (sudden shock); using traditional statistical comparison methods, both exceed the 90% threshold and cannot be distinguished; however, according to the fault attribution diagnosis method of this invention, Scenario A has a high similarity to historical performance fault sequences, and Scenario B is similar to configuration error sequences.

[0272] The dynamic update mechanism for rule confidence in the above scheme can balance stability and learning, and avoid the premature disabling of good rules due to a single error. It is combined with an adaptive rule review and rule reinforcement triggering mechanism. The rule review can be triggered when the accuracy continues to decline, preventing misleading rules from existing in the long term. The rule reinforcement can increase confidence when the accuracy remains high, promoting the priority use of high-quality rules. As a result, the life cycle of confidence rules is extended.

[0273] Furthermore, the multi-dimensional fusion approach employed in the aforementioned solution not only does not increase computational costs but also achieves near 100% root cause coverage. Its four dimensions are generated from different data sources, significantly reducing the probability of missing root causes. Moreover, it can support complex scenarios (e.g., cross-device failures, simultaneous failures of multiple devices, novel failures, etc.). Its structured knowledge base storage and automatic rule updates also facilitate easy system maintenance.

[0274] The various processes and procedures described above, such as methods 200 to 800, can be executed at a computing device. This computing device may include, for example, at least one processor (at least one graphics processor and at least one central processing unit); and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor. In some embodiments, methods 200 to 800 may be implemented as a computer software program or program product tangibly contained in a machine-readable medium. In some embodiments, part or all of the computer program may be loaded and / or installed on the computing device via read-only memory (ROM) and / or a communication unit. When the computer program is loaded into random-access memory (RAM) and executed by the GPU and CPU, one or more actions of methods 200 to 800 described above can be performed.

[0275] This invention can be a method, apparatus, system, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention. The computer-readable storage medium may be a tangible device capable of holding and storing instructions used by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof.

[0276] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to various computing / processing devices, or downloaded via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network, to an external computer or external storage device. Various aspects of the invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0277] These computer-readable program instructions can be provided to the central processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the central processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0278] 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 the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or part of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. It should be understood that steps can be reordered, added, or deleted using the various forms of processes shown above. For example, the steps described in this application may be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in this application are achieved, and this is not limited herein.

[0279] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors.

Claims

1. A method for determining the root cause of a network failure, characterized in that, include: Acquire real-time network data to construct input features, wherein the real-time data includes at least alarm events, time-series indicator data, and network topology information; Based on the input features, a candidate root cause set is generated through a multi-dimensional analysis model; Based on the candidate root cause set, multiple inference results about the root cause of the failure are output through multiple inference engines; as well as At least the inference results regarding the root causes of the faults are aggregated, conflict-resolved, and confidence-calculated to output diagnostic results regarding the root causes of network faults.

2. The method according to claim 1, characterized in that, The alarm events include device alarm events and fault alarm events. The time-series metric data includes at least time-series metric data regarding CPU utilization, traffic, latency, and packet loss rate. Real-time network data includes: The event collector receives alarm events reported by the device. Key symptoms are identified and structured from received alarm events via a symptom extractor. The time series analyzer is used to maintain indicator data across multiple time windows; and Based on link layer discovery protocols and device discovery protocols, a device, interface, and link graph model is constructed to obtain network topology information.

3. The method according to claim 1, characterized in that, Based on the input features, a candidate root cause set is generated through a multi-dimensional analysis model, including: The diagnostic mapping module queries a predefined fault type and root cause mapping table to map the fault type to the first candidate root cause. Through the symptom analysis module, the identified and structured key symptoms are grouped together using a clustering algorithm to infer the second candidate root cause. Through the historical fault data retrieval module, based on vectorized retrieval and the KNN algorithm, the third candidate root cause of similar historical cases is obtained; The fault propagation path is calculated based on the network topology diagram using the topology analysis module. The root cause device of the fault propagation path is determined from the affected area in order to obtain the fourth candidate root cause. The candidate fusion and deduplication module deduplicates and sorts the first, second, third, and fourth candidate root causes to generate a set of candidate root causes.

4. The method according to claim 3, characterized in that, Through the historical fault data retrieval module, based on vectorized retrieval and the KNN algorithm, the third candidate root causes of similar historical cases are obtained, including: The description of the fault event is converted into a high-dimensional vector using the natural language vectorization module; Based on the high-dimensional vector, the KNN algorithm is used to retrieve the most similar historical fault data; and Extract the root causes of the multiple historical fault data to obtain a third candidate root cause.

5. The method according to claim 1, characterized in that, Based on the candidate root cause set, multiple inference engines output multiple inference results regarding the root causes of the failure, including: The likelihood and confidence of each candidate root cause in the candidate root cause set under given symptom conditions are calculated through the abductive reasoning engine in order to generate abductive reasoning results. The forward inference engine verifies the plausibility of the symptom propagation chain by starting from each candidate root cause in the candidate root cause set, in order to generate forward inference results; and The feasibility of each candidate root cause in the candidate root cause set is confirmed through hypothesis testing and constraint checks via the reverse reasoning engine in order to generate reverse reasoning results.

6. The method according to claim 5, characterized in that, At least the multiple inference results regarding the root causes of the faults are aggregated, conflict-resolved, and confidence-calculated to output diagnostic results regarding the root causes of network faults, including: The abductive reasoning results, forward reasoning results, and backward reasoning results are aggregated through a multi-strategy integrator to generate aggregated reasoning results; The conflict resolver processes the conflicts in the aggregated reasoning results to output conflict-free reasoning results. Using a confidence calculator, based on voting mechanisms and the strength of evidence, the confidence level of inferences that do not conflict is calculated in order to output root cause diagnoses of network failures.

7. The method according to claim 2, characterized in that, The alarm events reported by the receiving device via the event collector include: Receive alarm events reported by network devices; Based on the received alarm events, extract the alarm event timestamp, network device identifier, alarm event type, and alarm event severity; and Associate the received alarm events with super events.

8. The method according to claim 2, characterized in that, The symptom extractor identifies and structures key symptoms from received alarm events, including: Extract structured symptoms from received alert events; Identify key-level and error-level symptoms from the extracted structured symptoms to generate a symptom set; and Extract latent symptoms from the symptom set.

9. The method according to claim 2, characterized in that, The time series analyzer maintains multi-time-window metric data including: Collect time-series metrics data on CPU utilization, traffic, latency, and packet loss rate; Divide the time window into multiple groups of time windows with different window sizes; Based on multiple time windows, abnormal patterns in terms of peaks, persistence, and trends are detected for the collected time-series indicator data.

10. The method according to claim 2, characterized in that, Acquiring real-time data from the network to construct input features includes: Acquire super events, symptom sets, and time-series indicator data to construct input features. The super events are associated with network device identifiers, interface identifiers, and diagnosis types. The symptom sets include critical-level symptoms and error-level symptoms. The time-series indicator data includes time-series indicator data on CPU utilization, traffic, latency, and packet loss rate within a predetermined time period.

11. The method according to claim 3, characterized in that, The generated candidate root cause set includes: The first, second, third, and fourth candidate root causes are fused to form a list of candidate root causes, so as to calculate the evidence strength score for each candidate root cause. The merged candidate root cause list is deduplicated to retain the candidate root cause with the highest evidence strength score among multiple identical candidate root causes; and The candidate root cause list, after deduplication, is sorted in descending order of evidence strength score, and a predetermined number of candidate root causes at the top of the list are retained to generate a candidate root cause set.

12. The method according to claim 11, characterized in that, The strength of evidence score for each candidate root cause is calculated as follows: For each candidate root cause in the candidate root cause list, calculate the degree of match between each candidate root cause and the diagnosis type in order to obtain a diagnosis match score; For each candidate root cause, the coverage of expected symptoms and actual symptoms of the candidate root cause is calculated in order to obtain a symptom coverage score. For each candidate root cause, it is determined whether the root cause device is located upstream of the fault propagation in order to obtain a topology consistency score; and The evidence strength score for each candidate root cause is calculated based on diagnostic matching score, symptom coverage score, and topological consistency score.

13. The method according to claim 5, characterized in that, The abductive reasoning engine calculates the likelihood and confidence of each candidate root cause in the candidate root cause set under given symptom conditions, in order to generate abductive reasoning results, including: Obtain the set of candidate root causes, the set of observed symptoms, and the context information of the super event; For each candidate root cause in the candidate root cause set, a predetermined knowledge base is queried to obtain the theoretical expected symptoms corresponding to each candidate root cause. The predetermined knowledge base stores the mapping relationship between root causes and symptoms. Calculate the likelihood of producing observed symptoms under given root cause conditions; Calculate the degree of overlap between expected symptoms and observed symptoms in order to obtain coverage; Extract typical time-series patterns from expected symptoms for multiple performance metrics data so that the time-series similarity between the current observed time series and the expected time series can be calculated using a dynamic time warping algorithm; Motivation scores are calculated based on temporal consistency, topological consistency, and temporal similarity. A weighted fusion calculation is performed based on the likelihood, coverage, prior probability, and motivation score of each candidate root cause to obtain a comprehensive score; and Iterate through the comprehensive score of each candidate root cause and obtain the candidate root cause with the highest comprehensive score as the result of abductive reasoning.

14. The method according to claim 5, characterized in that, The forward inference engine verifies the plausibility of the symptom propagation chain by starting from each candidate root cause in the candidate root cause set, in order to generate forward inference results including: Starting from the expected symptoms of each candidate root cause in the candidate root cause set, construct the symptom transmission chain according to the causal relationship; Verify whether the symptoms in the expected symptoms are also in the observed symptoms in order to calculate link coverage; and Based on link coverage and link length penalties, a forward score is calculated to generate forward inference results.

15. The method according to claim 5, characterized in that, Through the reverse reasoning engine, the feasibility of each candidate root cause in the candidate root cause set is confirmed by hypothesis testing and constraint checks, so as to generate reverse reasoning results including: Starting from each candidate root cause in the candidate root cause set, verify whether the candidate root cause is a known root cause in the predetermined knowledge base, and whether the expected symptoms are stable, in order to obtain a knowledge base matching score. Check whether candidate root causes conflict with known constraints in order to determine a consistency score; and A reverse score is calculated based on the consistency score and the knowledge base matching score in order to generate reverse reasoning results.

16. The method according to claim 5, characterized in that, At least the multiple inference results regarding the root causes of the faults are aggregated, conflict-resolved, and confidence-calculated to output diagnostic results regarding the root causes of network faults, including: Obtain abductive reasoning results, forward reasoning results, and backward reasoning results to extract a root cause list. The abductive reasoning results include root causes, confidence levels, and reasoning paths. The forward reasoning results include root causes, forward scores, and symptom chain coverage. The backward reasoning results include root causes, backward scores, and consistency scores. In response to determining that there is a root cause with a confidence level higher than a predetermined threshold, the root cause is identified as a root cause diagnosis result of network failure; In response to the determination that there are no root causes with confidence levels higher than a predetermined threshold, the number of times each root cause is recommended in the abductive reasoning results, forward reasoning results, and backward reasoning results is counted. The strength of evidence for each root cause is statistically analyzed and compared in order to determine whether a dominant root cause exists. In response to determining the existence of a dominant root cause, the dominant root cause is identified as a root cause diagnosis result of the network failure; and In response to the determination that no dominant root cause exists, a weighted average confidence level is calculated for the root cause in order to determine the root cause diagnosis results for the network failure based on the weighted average confidence level.

17. A computing device, characterized in that, include: At least one processor; as well as A memory that is communicatively connected to the at least one processor; in The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-16.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a machine, performs the method according to any one of claims 1-16.

19. A computer program product, characterized in that, Includes a computer program, which, when executed by a machine, performs the method according to any one of claims 1-16.

Images