Fault root cause locating method and system, and computer storage medium and program product

Abstract

The present application relates to the technical field of computers, and in particular to a fault root cause locating method, a fault root cause positioning system implementing the method, and a computer-readable storage medium and a computer program product. The method comprises: acquiring an architecture topology graph and abnormal alarm information of an application system; on the basis of the architecture topology graph and the abnormal alarm information, constructing a troubleshooting logical tree, wherein in the troubleshooting logical tree, a logical relationship between nodes is used to indicate a potential fault propagation link between configuration components in the architecture topology graph; performing qualitative analysis on the troubleshooting logical tree, so as to identify a potential fault point that causes a fault; performing quantitative analysis on the troubleshooting logical tree, so as to calculate a fault probability and the degree of influence of each potential fault point; and on the basis of results of the qualitative analysis and the quantitative analysis, determining a root cause fault point, and acquiring a fault propagation link of the root cause fault point.

Description

Fault root cause localization methods, systems, computer storage media and program products

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411474283.3, filed on October 21, 2024, entitled “Method, System, Computer Storage Medium and Program Product for Root Cause Analysis of Faults”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of computer technology, and more specifically to a root cause localization method, a root cause localization system implementing the method, a computer-readable storage medium, and a computer program product. Background Technology

[0004] In today's enterprise environment, with the increasing complexity of application system logic and the growing emphasis and investment in high-availability architecture by R&D and operations teams, the scale of computer equipment is constantly expanding. This trend inevitably leads to frequent system anomalies and failures, resulting in a diversification of equipment anomaly alarm types and a sharp increase in the number of alarms. To ensure that the system maintains high availability and reliability at the service level, operations personnel must respond quickly to various anomaly alarms and troubleshoot in a timely manner, thereby minimizing the impact on business operations. In this process, quickly and accurately locating the root cause of system failures is particularly important, as it is a key step for operations personnel to take effective countermeasures and restore normal system operation.

[0005] While a typical high-availability architecture enhances system robustness to some extent, and with increasingly sophisticated monitoring tools, business anomalies or system failures can be handled relatively well, this also places higher demands on enterprise data collection and monitoring systems. It requires operations and maintenance personnel to possess extensive experience and expertise to accurately identify the root cause of failures from massive amounts of monitoring data. This process is not only time-consuming but also prone to errors. Further complicating matters, when system anomaly alarms suffer from false alarms, missed alarms, or alarm delays, locating the root cause of system failures becomes even more difficult.

[0006] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0007] To address or at least mitigate one or more of the above problems, embodiments of this application provide a fault root cause localization method, a fault root cause localization system implementing the method, a computer-readable storage medium, and a computer program product. By constructing a troubleshooting logic tree and combining qualitative and quantitative analysis, it achieves rapid and accurate localization of the root cause of application system faults, while also obtaining the fault propagation chain, effectively improving the efficiency of fault investigation and resolution.

[0008] According to a first aspect of this application, a method for locating the root cause of a fault is provided. The method includes the following steps: acquiring an architecture topology diagram and abnormal alarm information of an application system, wherein the architecture topology diagram indicates the relationships and hierarchical structure between various configuration components of the application system, and the abnormal alarm information includes the identifier of the configuration component related to the fault and its level and abnormal importance; constructing a troubleshooting logic tree based on the architecture topology diagram and the abnormal alarm information, wherein the troubleshooting logic tree uses the logical relationships between nodes to indicate potential fault propagation links between various configuration components in the architecture topology diagram; performing qualitative analysis on the troubleshooting logic tree to identify potential fault points leading to the fault; performing quantitative analysis on the troubleshooting logic tree to calculate the fault probability and impact of each potential fault point; and determining the root cause fault point based on the results of the qualitative and quantitative analysis, and obtaining the fault propagation link of the root cause fault point.

[0009] As an alternative or supplement to the above solutions, a fault root cause localization method according to an embodiment of this application further includes: generating the architecture topology diagram based on the CMDB configuration management information of the application system and a preset tracing path.

[0010] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, generating the architecture topology diagram based on the CMDB configuration management information of the application system and the preset tracing path includes: retrieving and obtaining the CMDB configuration model of the application system from the troubleshooting knowledge base; traversing and parsing the CMDB configuration model using a breadth-first search algorithm to determine the hierarchical structure and nodes of the application system; supplementing the hierarchical structure and nodes of each level according to the tracing path stored in the troubleshooting knowledge base; and generating the architecture topology diagram based on the supplemented hierarchical structure and nodes of each level.

[0011] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, the tracing path indicates how to trace upward from the bottom child node to the next level root node.

[0012] As an alternative or supplement to the above solutions, a fault root cause localization method according to an embodiment of this application further includes: monitoring the operating status of each configuration component in the architecture topology diagram; and determining the abnormal alarm information based on monitoring data and abnormal indicator information for various types of faults.

[0013] As an alternative or supplement to the above solutions, a fault root cause localization method according to an embodiment of this application further includes: adding annotation information to nodes in the architecture topology diagram based on the abnormal alarm information, wherein each node in the architecture topology diagram corresponds to a type of configuration component, and the annotation information includes the number of instances of the type of configuration component and the number of abnormal alarms.

[0014] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, the triggering conditions of the method include: manual triggering, timed polling triggering, and alarm event triggering.

[0015] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, constructing a troubleshooting logic tree based on the architecture topology diagram and the abnormal alarm information includes: comparing the abnormal alarm information of each root node in the architecture topology diagram and determining the root node with the highest abnormality importance as the root event; decomposing the cause of the root event into sub-events level by level, wherein each sub-event indicates whether the operating status of the lower-level node of the root event is abnormal; and connecting the sub-events through logical AND, OR, and OR connections according to the association relationship and hierarchical structure between each configuration component in the architecture topology diagram.

[0016] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, performing qualitative analysis on the troubleshooting logic tree to identify potential fault points leading to the fault includes: simplifying the troubleshooting logic tree using a fault tree analysis method to identify multiple minimal cut sets leading to the fault, wherein each minimal cut set includes a minimal set of basic events leading to the fault.

[0017] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, each minimal cut set corresponds to a minimal obstacle removal subtree.

[0018] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, quantitative analysis of the troubleshooting logic tree includes: determining the critical importance of a sub-event based on its importance, the level of the configuration component associated with the sub-event, and the timestamp of the sub-event's occurrence; determining the structural importance of a sub-event based on the ratio of the number of combinations where the state of the sub-event is the same as the state of the root event to the total number of system states, without considering the probability of the sub-event's occurrence; and determining the probabilistic importance of a sub-event based on the degree to which the change in the probability of the sub-event's occurrence causes a change in the probability of the root event's occurrence.

[0019] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, sub-event X i Key Importance I K (i) is calculated as follows: I K (i)=St(a(X i ),l(X i ),t(X i ))

[0020] Where, a(X) i ) represents the sub-event X i Importance, l(X) i ) is related to the sub-event X i The hierarchy of the associated configuration component, t(X) i ) is the sub-event X i The generated timestamp, the function St() represents the timestamp based on a(X) i ), l(X i ), t(X) i Pair of events X i They are ranked and scored according to their importance.

[0021] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, sub-event X i Structural importance I τ (i) The calculation is as follows:

[0022] Among them, X i _1 represents the sub-event X i The state is 1, ∑T(1,X) i _1) represents the sub-event X i The number of combinations where the state of the root event is 1, X i Sub-event X as described in _0 i The state is 0, ∑T(1,X) i _0) represents the sub-event X iThe number of combinations where the state of the root event is 0 and the state of the root event is 1, where N is the total number of sub-events.

[0023] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, sub-event X i Probability Importance I ρ (i) is calculated as follows: I ρ (i)=P(T,X i _1)-P(T,X i _0)

[0024] Wherein, P(T,X) i _1) represents the sub-event X i The probability of the root event occurring when it occurs; P(T,X) i _0) represents the sub-event X i The probability of the root event occurring when it does not occur.

[0025] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, quantitative analysis of the troubleshooting logic tree further includes: calculating a weighted sum of the critical importance, the structural importance, and the probabilistic importance to determine the comprehensive importance of the sub-event.

[0026] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, determining the root cause fault point based on the results of qualitative and quantitative analysis includes: identifying one or more sub-events with the highest overall importance as the root cause fault point.

[0027] As an alternative or supplement to the above solutions, in a fault root cause localization method according to an embodiment of this application, obtaining the fault propagation link of the root cause fault point includes: obtaining the minimum troubleshooting subtree including the root cause fault point; and determining the fault propagation link based on the minimum troubleshooting subtree.

[0028] As an alternative or supplement to the above solutions, a fault root cause localization method according to an embodiment of this application further includes: constructing a troubleshooting knowledge base, wherein the troubleshooting knowledge base includes one or more of the following: CMDB configuration management information of each application system, types of various faults, abnormal indicator information of various faults, abnormal importance of various faults, importance of various sub-events, tracing paths, and fault localization processing logic; and updating the troubleshooting knowledge base according to historical fault root cause localization results.

[0029] According to a second aspect of this application, a fault root cause localization system is provided, comprising: a memory; a processor; and a computer program stored on the memory and executable on the processor, the execution of the computer program causing the following operations: acquiring an architecture topology diagram and abnormal alarm information of an application system, wherein the architecture topology diagram indicates the relationships and hierarchical structure between various configuration components of the application system, and the abnormal alarm information includes the identifier of the configuration component related to the fault and its level and abnormal importance; constructing a troubleshooting logic tree based on the architecture topology diagram and the abnormal alarm information, wherein the troubleshooting logic tree uses the logical relationships between nodes to indicate potential fault propagation links between various configuration components in the architecture topology diagram; performing qualitative analysis on the troubleshooting logic tree to identify potential fault points leading to the fault; performing quantitative analysis on the troubleshooting logic tree to calculate the fault probability and impact degree of each potential fault point; and determining the root cause fault point based on the results of the qualitative and quantitative analysis, and acquiring the fault propagation link of the root cause fault point.

[0030] According to a third aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including instructions that, when executed, perform any one of the fault root cause localization methods according to a first aspect of this application.

[0031] According to a fourth aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements any one of the fault root cause localization methods described in the first aspect of this application.

[0032] The fault root cause localization scheme according to one or more embodiments of this application achieves rapid and accurate localization of the root cause of application system faults by constructing a troubleshooting logic tree and combining qualitative and quantitative analysis. It also obtains the fault propagation chain, effectively improving the efficiency of fault investigation and resolution. Specifically, this scheme obtains the application system's architecture topology diagram and abnormal alarm information to comprehensively and accurately understand the relationships and hierarchical structure between the system's configuration components, as well as the specific manifestations of the faults, laying a solid foundation for subsequent analysis. Then, by constructing a troubleshooting logic tree, it not only intuitively displays the possible propagation paths of the faults but also utilizes the logical relationships between components, greatly improving the accuracy and efficiency of fault analysis. Through qualitative analysis, this scheme can narrow down the root cause localization scope, identify potential fault points, and reduce the time cost of blind troubleshooting. Further quantitative analysis can determine the fault probability and impact of each potential fault point, providing a basis for locating the final root cause fault point. Finally, based on the comprehensive analysis results, this scheme can accurately pinpoint the root cause fault point and clearly display its fault propagation chain, helping maintenance personnel quickly locate problems and formulate repair plans, thereby effectively shortening fault recovery time and improving system stability and availability. Attached Figure Description

[0033] The above and / or other aspects and advantages of this application will become clearer and more readily understood through the following description taken in conjunction with the accompanying drawings, in which the same or similar elements are denoted by the same reference numerals. In the drawings:

[0034] Figure 1 is a schematic flowchart of a fault root cause localization method 10 according to one or more embodiments of this application;

[0035] Figure 2 is a schematic flowchart of a method 20 for generating an architecture topology diagram according to one or more embodiments of this application;

[0036] Figure 3 is a schematic diagram of an architecture topology drawn according to one or more embodiments of this application;

[0037] Figure 4 is a schematic diagram of a troubleshooting logic tree constructed according to one or more embodiments of this application;

[0038] Figure 5 is a schematic diagram of a minimum obstacle-clearing logic tree constructed according to one or more embodiments of this application;

[0039] Figure 6 is a schematic block diagram of a fault root cause localization system 60 according to one or more embodiments of this application. Detailed Implementation

[0040] The following detailed description is merely exemplary in nature and is not intended to limit the disclosed technology or its application and use. Furthermore, it is not intended to be bound by any express or implied theory presented in the foregoing technical fields, background art, or the following detailed description.

[0041] In the following detailed description of the embodiments, numerous specific details are set forth in order to provide a more thorough understanding of the disclosed technology. However, it will be apparent to those skilled in the art that the disclosed technology can be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

[0042] Terms such as "comprising" and "including" indicate that, in addition to the units and steps that are directly and explicitly described in the specification, the technical solution of this application does not exclude the presence of other units and steps that are not directly or explicitly described. Terms such as "first" and "second" do not indicate the order of the units in terms of time, space, size, etc., but are merely used to distinguish the units.

[0043] In the following, exemplary embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings.

[0044] Referring now to the accompanying drawings, FIG1 is a schematic flowchart of a fault root cause localization method 10 according to one or more embodiments of the present application.

[0045] As shown in Figure 1, in step S110, the architecture topology diagram and abnormal alarm information of the application system are obtained.

[0046] The triggering of fault root cause localization method 10 or step S110 can be based on internal factors (e.g., timed polling triggering, alarm event triggering) or external factors (e.g., manual triggering). Timed polling refers to periodically checking the system based on a preset time interval. In one possible implementation, when the set time point is reached, the system automatically triggers fault root cause localization method 10 or step S110 to obtain the architecture topology diagram and abnormal alarm information of the specific application system and initiate fault analysis. Alarm event triggering refers to generating an alarm event as a trigger signal in response to the detection of an anomaly or fault reaching a preset alarm level. In one possible implementation, a trigger signal is generated if three faults are detected within 5 seconds. In another possible implementation, a trigger signal is generated if the anomaly importance of the detected fault exceeds a preset threshold. Manual triggering refers to the system administrator or maintenance personnel manually initiating fault root cause localization method 10 or step S110.

[0047] The architecture topology diagrams in this article illustrate the relationships and hierarchical structure between the various configuration components of an application system (such as a computer application system). Configuration components refer to specific, executable, or manageable units within an application system, typically including servers, network devices, databases, application modules, etc. In an architecture topology diagram, a configuration component can be represented as a node, or a class of configuration components can be uniformly represented as nodes. The hierarchical structure in the architecture topology diagram describes the hierarchical relationship between configuration components. These layers typically represent different levels of abstraction and functional areas. For example, the hierarchy can be divided into business layers, application layers, service layers, logic layers, and hardware layers, each representing different configuration components and their interaction methods. Relationships describe whether configuration components have connection attributes, depending on whether there are physical or logical relationships between component instances. In an architecture topology diagram, these relationships are typically represented by lines or arrows.

[0048] Optionally, the architecture topology diagram is generated based on the application system's CMDB configuration management information and a predefined tracing path. CMDB (Configuration Management Database) is a logical database that contains information about the entire lifecycle of configuration components and the relationships between them (including physical relationships, real-time communication relationships, non-real-time communication relationships, and dependencies). For example, CMDB configuration management information may include the following: configuration components; information about the relationships between configuration components; and configuration component attribute information, such as identifier, type, version, location, and status. A tracing path refers to the process of starting from a certain configuration component and tracing back to other related configuration components through a series of relational links.

[0049] For example, CMDB configuration management information and tracing paths can be pre-stored in a troubleshooting knowledge base. Optionally, in one or more embodiments according to this application, a troubleshooting knowledge base is constructed, wherein the troubleshooting knowledge base may include one or more of the following: CMDB configuration management information of each application system, types of faults, abnormal indicator information of various faults, abnormal importance of various faults, importance of various sub-events, tracing paths, and fault location processing logic. Further, the troubleshooting knowledge base can also be updated based on subsequent historical fault root cause location results. During the fault root cause location process, the troubleshooting knowledge base provides prior knowledge that is relied upon throughout the entire process, and automatically saves troubleshooting experience and iteratively updates knowledge base information after each troubleshooting, thereby feeding back and optimizing the fault analysis and root cause location process.

[0050] Referring now to FIG2, FIG2 is a schematic flowchart of a method 20 for generating an architecture topology diagram according to one or more embodiments of the present application.

[0051] As shown in Figure 2, in step S210, the CMDB configuration model of the specified application system is retrieved and obtained from the troubleshooting knowledge base. In step S220, the CMDB configuration model is traversed and parsed using a breadth-first search algorithm to determine the hierarchical structure of the application system and the nodes at each level. For example, the application system can be used as the center, and the breadth-first search algorithm can be used from top to bottom to obtain the nodes at each level. This means starting from the top-level node and searching downwards layer by layer until all reachable nodes are found. Optionally, method 20 may also include: pruning the obtained nodes and relationships at each level based on the CMDB configuration model, and cleaning redundant data. This step aims to remove unnecessary and redundant nodes and relationships, and clean the data to ensure the accuracy and consistency of information, preparing for subsequent topology mapping. In step S230, it is determined whether there are other sub-level root nodes. If sub-level root nodes exist, step S240 is executed: the hierarchical structure and nodes at each level are supplemented according to the tracing paths stored in the troubleshooting knowledge base. For example, a tracing path provided by an operations and maintenance expert can be obtained from a troubleshooting knowledge base. This tracing path includes instructions on how to trace upwards from the bottom-level child nodes to the next-level root node. Then, for each next-level root node, the corresponding bottom-level child node searches and supplements the tracing path to ensure that all relevant nodes and relationships are fully included. If no next-level root node exists, proceed directly to step S250. In step S250, based on the hierarchical structure, the obtained application system configuration components are used to draw a corresponding architecture topology diagram according to the relationships between each node.

[0052] Figure 3 is a schematic diagram of the architecture topology drawn according to one or more embodiments of this application. As shown in Figure 3, each node icon corresponds to a type of configuration component. Below the icon, the number of configuration component instances, the total number of alarms during a fault, and the number of critical alarms can be marked. Drill-down of node information is also supported to display detailed data information. Furthermore, as shown in the figure, the application system has a secondary root node "cluster," as circled in the ellipse in Figure 3. According to the embodiments of this application (e.g., method 20 in Figure 2), the architecture topology drawn by this top-down, tracing-the-roots drawing scheme has significant advantages in visualization, interaction, and readability. It should be noted that each type of configuration component in Figure 3 can contain multiple configuration component instances, and each configuration component instance has a unique configuration component identifier. Whether various configuration components have a "connection" attribute depends on whether there is a physical or logical association between two configuration component instances.

[0053] Returning to Figure 1, the abnormal alarm information in step S110 is key information used to indicate potential or actual faults. This information is crucial for quickly locating faults, analyzing the root causes of faults, and taking corresponding measures.

[0054] Optionally, based on the architecture topology diagram drawn in the above steps, the operational status of the configuration components within the architecture topology diagram can be monitored, and abnormal alarm information can be determined based on the monitoring data and abnormal indicator information for various faults. For example, reasonable abnormal indicator information can be set according to the normal operating range and historical data of the configuration components, and abnormal alarm information can be generated when the monitoring data exceeds the range indicated by the abnormal indicator information. Since the data formats in various fields have multimodal characteristics, abnormal alarm information can be uniformly standardized to facilitate subsequent use and analysis. In a specific example, the standardized anomaly alarm information may include one or more of the following: Anomaly Identifier – a unique identifier for this anomaly alarm information; Timestamp – the specific time the anomaly occurred; Content Details – details of alarms, events, and anomaly logs related to the fault; Anomaly Indicator Information – monitoring indicators or log templates for business, basic systems, network, security, application, and other fields; Associated Configuration Instance – the configuration component identifier and type of the application system associated with this fault; Layer – the layer in which the configuration component is located, such as business layer-0, application layer-1, service layer-2, logic layer-3, hardware layer-4, etc.; Anomaly Importance – the severity or priority of this fault, such as general-0, important-1, critical-2, etc.

[0055] Optionally, annotation information can be added to nodes in the architecture topology diagram based on anomaly alarm information to form a preliminary troubleshooting diagram. The annotation information may include the number of instances of that type of configuration component and the number of anomaly alarms. Furthermore, in the preliminary troubleshooting diagram, anomalies of different importance can be visually distinguished using different colors.

[0056] In step S120, a troubleshooting logic tree is constructed based on the architecture topology diagram and anomaly alarm information. The troubleshooting logic tree in this paper abstractly models the system architecture as a tree-like logic diagram, using the logical relationships between nodes to indicate potential fault propagation links between various configuration components in the architecture topology diagram.

[0057] Optionally, in step S120, the abnormal alarm information of each root node in the architecture topology diagram is first compared, and the root node with the highest abnormality importance is determined as the root event; then, the cause of the root event is decomposed into sub-events (including decomposable intermediate events and non-decomposable basic events), where each sub-event indicates whether the running status of the lower-level node of the root event is abnormal. For example, the sub-events and the root event can be defined as follows:

[0058] Sub-events (e.g., intermediate events, basic events): Indicate whether the running status of child nodes under the root node is abnormal.

[0059] Root event: Indicates whether the root node's running state is abnormal. A root event is composed of all its child events arranged according to certain logic. Therefore, a root event must be a child event X. i The function is defined as follows: T = T(X1, X2, ..., X...). N )

[0060] Simultaneously define:

[0061] Furthermore, based on the relationships and hierarchical structure between the configuration components in the architecture topology diagram, sub-events can be connected using logical AND, OR, and OR operations to transform application system failure problems into mathematical statistical probability problems. For example, the logical relationship mapping is as follows:

[0062] Logical AND: The root event occurs only when all child events have occurred. The structure function for a logical AND fault tree is:

[0063] Logical OR (OR): The root event occurs when at least one of the child events occurs. The structure function for a logical OR fault tree is:

[0064] Based on the above logical relationship mapping, the obstacle-clearing logic tree is constructed by decomposing from top to bottom and layer by layer from the root node. Figure 4 is a schematic diagram of the obstacle-clearing logic tree constructed according to one or more embodiments of this application. The structure functions of the sub-events and root events in the obstacle-clearing logic tree shown in Figure 4 can be expressed as: T = A1 + A2 + A3 = (C1 + C2) + C n +…+C N =(D1D2+D3D4)+D m +…+D M =E1+E1+E k +…+E K =F1F2+F1F2+F p +…+F P

[0065] In step S130, a qualitative analysis is performed on the troubleshooting logic tree to identify potential fault points that could lead to the fault.

[0066] Typically, the troubleshooting logic trees of large application systems are relatively complex, and the constructed structure functions consist of multiple logical operations. Fault tree analysis methods can be used to mathematically process the structure functions to simplify the calculations. This can reduce the complexity of fault analysis and provide a theoretical basis for maintenance personnel to conduct qualitative fault analysis.

[0067] For example, the Fussell algorithm can be used to simplify the troubleshooting logic tree. Starting from the root event of the troubleshooting logic tree, events at each level are replaced with events at the next level according to logical relationships, until all logic gates are replaced with basic events. This yields all minimal cut sets of the troubleshooting logic data (i.e., the minimum set of basic events that cause system failure; a minimal cut set represents one possibility of system failure). It should be noted that each obtained minimal cut set actually corresponds to a minimal troubleshooting subtree, and the root node and / or child nodes in each minimal troubleshooting subtree can be considered potential failure points leading to the failure.

[0068] For example, after simplifying the structure function of the obstacle-clearing logic tree in Figure 4, the following structure function of the minimum obstacle-clearing subtree can be obtained: A1=C1+C2=D1D2+D3D4=E1=F1F2

[0069] Figure 5 shows a schematic diagram of this minimum troubleshooting subtree. As shown in Figure 5, the root node and multiple child nodes in this minimum troubleshooting subtree can be considered as potential fault points that could lead to a failure.

[0070] In step S140, the troubleshooting logic tree is quantitatively analyzed to calculate the failure probability and impact of each potential fault point.

[0071] This step aims to analyze the probability of fault occurrence and the importance of various sub-events based on the troubleshooting logic tree, in order to quantify the impact of sub-events on the system root event and further confirm the fault propagation path and root cause. In one or more embodiments according to this application, the quantitative analysis mainly involves critical importance, structural importance, and probabilistic importance.

[0072] As mentioned above, after performing qualitative analysis of the fault, multiple minimum troubleshooting subtrees are obtained. The priority of the anomaly severity in each minimum troubleshooting subtree can be further determined using standardized anomaly alarm information. For example, the critical importance of a sub-event is determined based on its importance within the minimum troubleshooting subtree, the hierarchy of the configuration component associated with the sub-event, and the timestamp of the sub-event's occurrence. In one example, sub-event X... i Key Importance I K (i) is calculated as follows: I K (i)=St(a(X i ),l(X i ),t(X i ))

[0073] Where, a(X) i ) represents sub-event X i Importance, l(X) i ) is related to sub-event X iThe hierarchy of the associated configuration component, t(X) i ) is the sub-event X i The generated timestamp, the function St() represents the timestamp based on a(X) i ), l(X i ), t(X) i Pair of events X i They are ranked and scored according to their importance.

[0074] For example, the structural importance of a sub-event can be determined by the ratio of the number of combinations in which the state of the sub-event is the same as the state of the root event to the total number of system states, without considering the probability of its occurrence. Specifically, the structural importance of a sub-event is determined by observing the results of the fault tree without considering its probability of occurrence. Since the state of a sub-event can be 1 (fault) or 0 (non-fault), when sub-event X... i When a certain state is in one of the following conditions, the number of possible combinations of states for the remaining N-1 sub-events is 2. N-1 Furthermore, sub-event X i Structural importance I τ (i) can be calculated as follows:

[0075] Among them, X i _1 represents sub-event X i The state is 1, ∑T(1,X) i _1) represents sub-event X i The number of combinations where the state of the root event is 1, X i _0 Sub-event X i The state is 0, ∑T(1,X) i _0) represents sub-event X i The number of combinations where the state of the root event is 0 and the state of the root event is 1, where N is the total number of sub-events.

[0076] For example, the probabilistic importance of a sub-event can be determined based on the degree to which a change in the probability of a root event causes a change in the probability of a sub-event. In one example, sub-event X... i Probability Importance I ρ (i) The calculation is as follows:

[0077] Where P(T) is the probability of the root event occurring; P(X) i ) is the sub-event X i The probability of occurrence. In general, assuming that the sub-events are independent and mutually exclusive, the following equation holds: P(T) = P(X) i )P(T,X i _1)+(1-P(X i ))P(T,Xi _0)

[0078] Wherein, P(T,X) i _1) represents sub-event X i The probability of the root event occurring when it occurs; P(T,X) i _0) represents sub-event X i The probability of the root event occurring when it does not occur. Therefore, the probability of sub-event X. i Probability Importance I ρ (i) can be calculated as: I ρ (i)=P(T,X i _1)-P(T,X i _0)

[0079] Furthermore, the overall importance of a sub-event can be determined by calculating a weighted sum of its criticality, structural importance, and probabilistic importance. In one example, sub-event X... i Overall Importance I ε (i) is calculated as follows: I ε (i)=kI κ (i)+tI τ (i)+pI ρ (i)

[0080] The weighting coefficients k, t, and p are obtained from historical fault cases and will be iteratively optimized during actual troubleshooting.

[0081] In step S150, the root cause failure point is determined based on the results of qualitative and quantitative analysis, and the failure propagation link of the root cause failure point is obtained.

[0082] For example, one or more sub-events with the highest overall importance can be identified as root cause failure points. After identifying the root cause failure points, a minimal troubleshooting subtree is obtained, which includes one or more sub-events corresponding to the root cause failure point. This minimal troubleshooting subtree illustrates the propagation path from the sub-events to the root event, that is, the finally determined failure propagation path.

[0083] The fault root cause localization method 10 according to one or more embodiments of this application achieves rapid and accurate localization of the root cause of application system faults by constructing a troubleshooting logic tree and combining qualitative and quantitative analysis, and at the same time obtains the fault propagation link, effectively improving the efficiency of fault investigation and resolution. Specifically, Method 10 obtains the application system's architecture topology diagram and abnormal alarm information to comprehensively and accurately understand the relationships and hierarchical structure between system components, as well as the specific manifestations of faults, laying a solid foundation for subsequent analysis. Next, by constructing a troubleshooting logic tree, it not only intuitively displays the possible propagation paths of faults but also utilizes the logical relationships between components, greatly improving the accuracy and efficiency of fault analysis. Through qualitative analysis, Method 10 can quickly narrow down the fault location scope, identify potential fault points, and reduce the time cost of blind troubleshooting. Further quantitative analysis determines the fault probability and impact of each potential fault point, providing a scientific basis for determining the final root cause fault point. Finally, based on the comprehensive analysis results, Method 10 can accurately pinpoint the root cause fault point and clearly display its fault propagation chain, helping maintenance personnel quickly locate problems and formulate repair plans, thereby effectively shortening fault recovery time and improving system stability and availability.

[0084] Furthermore, in the fault root cause localization method 10 according to one or more embodiments of this application, a directed troubleshooting topology diagram of the application system hierarchy is constructed based on CMDB configuration components and their relationships: Based on the hierarchical management of the CMDB architecture, its configuration components are "nodes," and the relationships are a directed tree "network." Key indicators, anomalies, alarms, and logs are collected for all "nodes" across the entire stack. Further, abnormal events of "nodes" are used as "problems," and relationships are used as root cause reasoning paths. A minimal troubleshooting logic tree is constructed using a troubleshooting knowledge base and fault tree analysis algorithms to qualitatively and quantitatively analyze the causes of system faults. Simultaneously, method 10 accumulates troubleshooting experience, reviews fault cases, refines troubleshooting rules, and builds a troubleshooting expert knowledge base to optimize the troubleshooting process, thereby helping maintenance personnel quickly and accurately complete system-wide problem investigation and improving the efficiency of fault root cause localization.

[0085] Figure 6 is a schematic block diagram of a root cause localization system 60 according to one or more embodiments of this application. The root cause localization system 60 includes a memory 610, a processor 620, and a computer program 630 stored in the memory 610 and executable on the processor 620. The execution of the computer program 630 causes the aforementioned root cause localization method 10 or the method 20 for generating an architecture topology map to be performed.

[0086] Alternatively, this application can also be implemented as a computer-readable storage medium storing a program for causing a computer to perform the steps of the method shown in FIG1 or FIG2. Here, various types of computer-readable storage media can be used, such as disks (e.g., magnetic disks, optical disks, etc.), cards (e.g., memory cards, optical cards, etc.), semiconductor memory (e.g., ROM, non-volatile memory, etc.), and tapes (e.g., magnetic tape, cassette tape, etc.).

[0087] This disclosure can also be implemented as a computer program product comprising a computer program that, when executed by a processor, implements the steps of the method shown in FIG1 or FIG2.

[0088] Where applicable, the various embodiments provided in this application may be implemented using hardware, software, or a combination of hardware and software. Furthermore, where applicable, without departing from the scope of this application, the various hardware and / or software components described herein may be combined into composite components comprising software, hardware, and / or both. Where applicable, without departing from the scope of this application, the various hardware and / or software components described herein may be divided into sub-components comprising software, hardware, or both. Additionally, where applicable, it is contemplated that software components may be implemented as hardware components, and vice versa.

[0089] The software (such as program code and / or data) according to this application may be stored on one or more computer-readable storage media. It is also contemplated that the software identified herein may be implemented using one or more networked and / or otherwise general-purpose or special-purpose computers and / or computer systems. Where applicable, the order of the various steps described herein may be changed, combined into compound steps, and / or divided into sub-steps to provide the features described herein.

[0090] The embodiments and examples presented herein are provided to best illustrate embodiments of this application and its particular applications, thereby enabling those skilled in the art to implement and use this application. However, those skilled in the art will understand that the above description and examples are provided for ease of illustration and example only. The descriptions presented are not intended to cover all aspects of this application or to limit this application to the precise forms disclosed.

Claims

1. A method for locating the root cause of a fault, the method comprising the following steps: Obtain the architecture topology diagram and anomaly alarm information of the application system, wherein the architecture topology diagram indicates the relationship and hierarchical structure between the various configuration components of the application system, and the anomaly alarm information includes the identifier of the configuration component related to the fault and its level and anomaly importance; Based on the architecture topology diagram and the abnormal alarm information, a troubleshooting logic tree is constructed. The troubleshooting logic tree uses the logical relationship between each node to indicate the potential fault propagation links between each configuration component in the architecture topology diagram. Qualitative analysis is performed on the troubleshooting logic tree to identify potential fault points that could lead to the fault. Quantitative analysis is performed on the troubleshooting logic tree to calculate the failure probability and impact of each potential failure point; as well as The root cause failure point is determined based on the results of qualitative and quantitative analysis, and the failure propagation path of the root cause failure point is obtained.

2. The fault root cause localization method according to claim 1, wherein, The method further includes: Based on the CMDB configuration management information of the application system and the preset traceability path, the architecture topology diagram is generated.

3. The fault root cause localization method according to claim 2, wherein, Based on the CMDB configuration management information of the application system and the preset tracing path, the architecture topology diagram is generated as follows: Retrieve and obtain the CMDB configuration model of the application system from the troubleshooting knowledge base; The CMDB configuration model is traversed and parsed using a breadth-first search algorithm to determine the hierarchical structure of the application system and the nodes at each level. Based on the tracing paths stored in the troubleshooting knowledge base, the hierarchical structure and nodes at each level are supplemented; and Based on the supplemented hierarchical structure and nodes at each level, the architecture topology diagram is generated.

4. The fault root cause localization method according to claim 2 or 3, wherein, The tracing path indicates how to trace upwards from the bottom child node to the next level root node.

5. The fault root cause localization method according to claim 1, wherein, The method further includes: Monitor the operational status of each configuration component in the architecture topology diagram; and Based on monitoring data and abnormal indicator information for various faults, the abnormal alarm information is determined.

6. The fault root cause localization method according to claim 1, wherein, The method further includes: Based on the abnormal alarm information, add annotation information to the nodes in the architecture topology diagram, wherein each node in the architecture topology diagram corresponds to a type of configuration component, and the annotation information includes the number of instances of that type of configuration component and the number of abnormal alarms.

7. The fault root cause localization method according to claim 1, wherein, The triggering conditions for the method include: manual triggering, timed polling triggering, and alarm event triggering.

8. The fault root cause localization method according to claim 1, wherein, Constructing a troubleshooting logic tree based on the architecture topology diagram and the abnormal alarm information includes: Compare the abnormal alarm information of each root node in the architecture topology diagram, and determine the root node with the highest abnormal importance as the root event; The cause of the root event is decomposed into sub-events, where each sub-event indicates whether the running status of the lower-level node of the root event is abnormal; and Based on the relationships and hierarchical structure between the configuration components in the architecture topology diagram, the sub-events are connected by logical AND, OR, and OR.

9. The fault root cause localization method according to claim 1, wherein, Qualitative analysis of the troubleshooting logic tree is performed to identify potential fault points leading to the fault, including: The troubleshooting logic tree is simplified using a fault tree analysis method to identify multiple minimal cut sets that lead to the fault, wherein each minimal cut set includes the minimal set of basic events that lead to the fault.

10. The fault root cause localization method according to claim 9, wherein, Each minimal cut set corresponds to a minimal barrier subtree.

11. The fault root cause localization method according to claim 1, wherein, Quantitative analysis of the troubleshooting logic tree includes: The critical importance of a sub-event is determined based on its importance, the hierarchy of the configuration component associated with the sub-event, and the timestamp of the sub-event. Without considering the probability of the sub-event occurring, the structural importance of the sub-event is determined by the ratio of the number of combinations in which the state of the sub-event is the same as the state of the root event to the total number of states in the system; and The probability importance of the sub-event is determined based on the degree to which the change in the probability of the root event causes a change in the probability of the sub-event.

12. The fault root cause localization method according to claim 11, wherein, Sub-event X i Key Importance I K (i) is calculated as follows: I K (i)=St(a(X i ),l(X i ),t(X i )) Where, a(X) i ) represents the sub-event X i Importance, l(X) i ) is related to the sub-event X i The hierarchy of the associated configuration component, t(X) i ) is the sub-event X i The generated timestamp, the function St() represents the timestamp based on a(X) i ), l(X i ), t(X) i Pair of events X i They are ranked and scored according to their importance.

13. The fault root cause localization method according to claim 11, wherein, Sub-event X i Structural importance I τ (i) The calculation is as follows: Among them, X i _1 represents the sub-event X i The state is 1, ∑T(1,X) i _1) represents the sub-event X i The number of combinations where the state of the root event is 1, X i Sub-event X as described in _0 i The state is 0, ∑T(1,X) i _0) represents the sub-event X i The number of combinations where the state of the root event is 0 and the state of the root event is 1, where N is the total number of sub-events.

14. The fault root cause localization method according to claim 11, wherein, Sub-event X i Probability importance I ρ (i) is calculated as follows: I ρ (i)=P(T,X i _1)-P(T,X i _0) Wherein, P(T,X) i _1) represents the sub-event X i The probability of the root event occurring when it occurs; P(T,X) i _0) represents the sub-event X i The probability of the root event occurring when it does not occur.

15. The fault root cause localization method according to any one of claims 11-14, wherein, Quantitative analysis of the aforementioned troubleshooting logic tree also includes: The weighted sum of the critical importance, the structural importance, and the probabilistic importance is calculated to determine the overall importance of the sub-event.

16. The fault root cause localization method according to claim 15, wherein, Based on the results of qualitative and quantitative analysis, the root causes of failures include: The one or more sub-events with the highest overall importance are identified as the root cause failure points.

17. The fault root cause localization method according to claim 1, wherein, Obtaining the fault propagation path of the root cause fault point includes: Obtain the minimum troubleshooting subtree including the root cause fault point; and The fault propagation link is determined based on the minimum obstacle removal subtree.

18. The fault root cause localization method according to claim 1, wherein, The method further includes: Construct a troubleshooting knowledge base, which includes one or more of the following: CMDB configuration management information for each application system, types of faults, abnormal indicator information for various faults, abnormal importance of various faults, importance of various sub-events, tracing paths, and fault location processing logic; and The troubleshooting knowledge base is updated based on the historical root cause analysis results.

19. A root cause localization system, the system comprising: Memory; processor; as well as A computer program stored in the memory and executable on the processor, the execution of which causes the following operations: Obtain the architecture topology diagram and anomaly alarm information of the application system, wherein the architecture topology diagram indicates the relationship and hierarchical structure between the various configuration components of the application system, and the anomaly alarm information includes the identifier of the configuration component related to the fault and its level and anomaly importance; Based on the architecture topology diagram and the abnormal alarm information, a troubleshooting logic tree is constructed. The troubleshooting logic tree uses the logical relationship between each node to indicate the potential fault propagation links between each configuration component in the architecture topology diagram. Qualitative analysis is performed on the troubleshooting logic tree to identify potential fault points that could lead to the fault. Quantitative analysis is performed on the troubleshooting logic tree to calculate the failure probability and impact of each potential failure point; as well as The root cause failure point is determined based on the results of qualitative and quantitative analysis, and the failure propagation path of the root cause failure point is obtained.

20. The fault root cause localization system according to claim 19, wherein, The execution of the computer program also results in the following operations: Based on the CMDB configuration management information of the application system and the preset traceability path, the architecture topology diagram is generated.

21. The fault root cause localization system according to claim 20, wherein, Based on the CMDB configuration management information of the application system and the preset tracing path, the architecture topology diagram is generated as follows: Retrieve and obtain the CMDB configuration model of the application system from the troubleshooting knowledge base; The CMDB configuration model is traversed and parsed using a breadth-first search algorithm to determine the hierarchical structure of the application system and the nodes at each level. Based on the tracing paths stored in the troubleshooting knowledge base, the hierarchical structure and nodes at each level are supplemented; and Based on the supplemented hierarchical structure and nodes at each level, the architecture topology diagram is generated.

22. The fault root cause localization system according to claim 20 or 21, wherein, The tracing path indicates how to trace upwards from the bottom child node to the next level root node.

23. The fault root cause localization system according to claim 19, wherein, The execution of the computer program also results in the following operations: Monitor the operational status of each configuration component in the architecture topology diagram; and Based on monitoring data and abnormal indicator information for various faults, the abnormal alarm information is determined.

24. The fault root cause localization system according to claim 19, wherein, The execution of the computer program also results in the following operations: Based on the abnormal alarm information, add annotation information to the nodes in the architecture topology diagram, wherein each node in the architecture topology diagram corresponds to a type of configuration component, and the annotation information includes the number of instances of that type of configuration component and the number of abnormal alarms.

25. The fault root cause localization system according to claim 19, wherein, The fault root cause localization system is enabled to obtain the architecture topology diagram and abnormal alarm information of the application system based on one of the following triggering conditions: manual triggering, timed polling triggering, and alarm event triggering.

26. The fault root cause localization system according to claim 19, wherein, Constructing a troubleshooting logic tree based on the architecture topology diagram and the abnormal alarm information includes: Compare the abnormal alarm information of each root node in the architecture topology diagram, and determine the root node with the highest abnormal importance as the root event; The cause of the root event is decomposed into sub-events, where each sub-event indicates whether the running status of the lower-level node of the root event is abnormal; and Based on the relationships and hierarchical structure between the configuration components in the architecture topology diagram, the sub-events are connected by logical AND, OR, and OR.

27. The fault root cause localization system according to claim 19, wherein, Qualitative analysis of the troubleshooting logic tree is performed to identify potential fault points leading to the fault, including: The troubleshooting logic tree is simplified using a fault tree analysis method to identify multiple minimal cut sets that lead to the fault, wherein each minimal cut set includes the minimal set of basic events that lead to the fault.

28. The fault root cause localization system according to claim 19, wherein, Each minimal cut set corresponds to a minimal barrier subtree.

29. The fault root cause localization system according to claim 19, wherein, Quantitative analysis of the troubleshooting logic tree includes: The critical importance of a sub-event is determined based on its importance, the hierarchy of the configuration component associated with the sub-event, and the timestamp of the sub-event. Without considering the probability of the sub-event occurring, the structural importance of the sub-event is determined by the ratio of the number of combinations in which the state of the sub-event is the same as the state of the root event to the total number of states in the system; and The probability importance of the sub-event is determined based on the degree to which the change in the probability of the root event causes a change in the probability of the sub-event.

30. The fault root cause localization system according to claim 29, wherein, Sub-event X i Key Importance I K (i) is calculated as follows: I K (i)=St(a(X i ),l(X i ),t(X i )) Where, a(X) i ) represents the sub-event X i Importance, l(X) i ) is related to the sub-event X i The hierarchy of the associated configuration component, t(X) i ) is the sub-event X i The generated timestamp, the function St() represents the timestamp based on a(X) i ), l(X i ), t(X) i Pair of events X i They are ranked and scored according to their importance.

31. The fault root cause localization system according to claim 29, wherein, Sub-event X i Structural importance I τ (i) The calculation is as follows: Among them, X i _1 represents the sub-event X i The state is 1, ∑T(1,X) i _1) represents the sub-event X i The number of combinations where the state of the root event is 1, X i Sub-event X as described in _0 i The state is 0, ∑T(1,X) i _0) represents the sub-event X i The number of combinations where the state of the root event is 0 and the state of the root event is 1, where N is the total number of sub-events.

32. The fault root cause localization system according to claim 29, wherein, Sub-event X i Probability importance I ρ (i) is calculated as follows: I ρ (i)=P(T,X i _1)-P(T,X i _0) Wherein, P(T,X) i _1) represents the sub-event X i The probability of the root event occurring when it occurs; P(T,X) i _0) represents the sub-event X i The probability of the root event occurring when it does not occur.

33. The fault root cause localization system according to any one of claims 29-32, wherein, Quantitative analysis of the aforementioned troubleshooting logic tree also includes: The weighted sum of the critical importance, the structural importance, and the probabilistic importance is calculated to determine the overall importance of the sub-event.

34. The fault root cause localization system according to claim 33, wherein, Based on the results of qualitative and quantitative analysis, the root causes of failures include: The one or more sub-events with the highest overall importance are identified as the root cause failure points.

35. The fault root cause localization system according to claim 19, wherein, Obtaining the fault propagation path of the root cause fault point includes: Obtain the minimum troubleshooting subtree including the root cause fault point; and The fault propagation link is determined based on the minimum obstacle removal subtree.

36. The fault root cause localization system according to claim 19, wherein, The execution of the computer program also results in the following operations: Construct a troubleshooting knowledge base, which includes one or more of the following: CMDB configuration management information of each application system, types of faults, abnormal indicator information of various faults, abnormal importance of various faults, importance of various sub-events, tracing path, and fault location processing logic. as well as The troubleshooting knowledge base is updated based on the historical root cause analysis results.

37. A computer-readable storage medium comprising instructions that, when executed, perform the fault root cause localization method according to any one of claims 1-18.

38. A computer program product comprising a computer program that, when executed by a processor, implements the fault root cause localization method according to any one of claims 1-18.

Images