Server fault diagnosis system based on service topology correlation analysis
By constructing a service topology correlation analysis system, multi-source heterogeneous data is collected in real time and a service dependency topology graph is built. By using state weights and spatiotemporal correlation analysis, the problem of difficult fault location in complex distributed networks is solved, and efficient fault tracing and diagnosis are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANDONG VOCATIONAL COLLEGE OF SCI & TECH
- Filing Date
- 2026-01-09
- Publication Date
- 2026-05-01
AI Technical Summary
In complex distributed networks, existing fault diagnosis technologies suffer from alarm storms and root cause flooding, lack quantitative verification capabilities, and are difficult to identify hidden performance faults. Furthermore, existing monitoring tools cannot effectively identify strong dependencies between services, making fault location difficult.
A service topology correlation analysis system is constructed. By collecting multi-source heterogeneous data in real time, a service dependency topology graph is built. Fault storms are analyzed using state weights and spatiotemporal correlation. Quantitative verification is performed by combining edge attribute weights, root cause nodes are identified, and hierarchical alarm handling and in-depth diagnosis are executed.
It achieves comprehensive quantitative perception of server health status, accurately locates the root cause of faults, reduces the false judgment rate, and balances alarm noise reduction with accurate on-site evidence collection, thereby improving the efficiency and accuracy of fault location.
Smart Images

Figure CN121957962A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer data processing and automated fault location technology, specifically to a server fault diagnosis system based on service topology correlation analysis. Background Technology
[0002] With the rapid development of cloud computing, containerization technology, and microservices architecture, modern enterprise software systems have evolved from monolithic architectures to complex distributed networks composed of massive server nodes. In this architecture, business systems are broken down into multiple independently running but interdependent service units (i.e., server nodes), which frequently interact through RESTful APIs, RPC (Remote Procedure Call), or message queues, forming a complex service dependency topology.
[0003] In actual operation, a single request from a front-end user often triggers a complete call chain across dozens of server nodes and involving different infrastructure environments (such as physical machines, virtual machines, and containers) on the back-end. While this highly dynamic and tightly coupled service topology improves the system's agility and scalability, it also makes the propagation mechanism of server failures extremely covert and destructive.
[0004] Although various monitoring tools are currently available in the industry capable of collecting server infrastructure metrics (such as CPU utilization and memory level) or application-layer performance metrics (such as response time and throughput), existing fault diagnosis technologies still have the following limitations when facing the complex distributed topology scenarios described above: First, there's the issue of alarm storms and root cause overload. Due to strong dependencies between server nodes, when a core node upstream in the topology fails, the effects of the failure spread rapidly downstream along the call chain, causing numerous downstream server nodes to trigger abnormal alarms due to timeouts or retry mechanisms. Existing monitoring systems often lack cascading analysis capabilities based on the topology graph, easily leading to "alarm storms." This results in operations and maintenance personnel being overwhelmed by massive amounts of derivative alarm information, making it difficult to quickly locate the true root cause node from the complex red alerts.
[0005] Second, there is a lack of quantitative verification and latent fault identification capabilities. Traditional root cause analysis methods are mostly based on simple threshold judgments or statistical correlations, lacking a quantitative verification mechanism for "edge attributes" between nodes (such as call frequency and latency contribution), which easily leads to false alarms (for example, misjudging high-load nodes unrelated to the fault as root causes). In addition, existing technologies can usually only identify "explicit faults" such as service outages, while for "latent performance faults" where service is not interrupted but performance is severely degraded, there is often a lack of effective identification methods and automated on-site snapshot capture mechanisms, making it difficult to reproduce and troubleshoot complex and difficult problems. Summary of the Invention
[0006] To address the shortcomings of existing technologies, this invention provides a server fault diagnosis system based on service topology correlation analysis to solve the problems mentioned in the background section.
[0007] To achieve the above objectives, the present invention provides the following technical solution: a server fault diagnosis system based on service topology correlation analysis, comprising: The service topology construction module is configured to collect multi-source heterogeneous data from server nodes in real time, and construct infrastructure feature vectors, runtime environment feature vectors, and business performance feature vectors respectively; and, based on the application layer service call relationship data, construct and dynamically maintain a service dependency topology graph that presents the dependency relationships between server nodes. The fault storm diagnosis module is configured to calculate the state weight of server nodes based on infrastructure feature vectors, runtime environment feature vectors, and business performance feature vectors. When the state weights of multiple server nodes on the service dependency topology graph trigger alarms simultaneously within a preset time window, and the spatiotemporal correlation of the alarm nodes exceeds a preset correlation threshold, a fault storm event is determined to have occurred. Furthermore, an upstream backtracking analysis is performed from the downstream server node that triggered the alarm along the dependency relationship to locate the root cause node with the highest fault propagation index. The integrated alarm generation module is configured to perform quantitative verification and hierarchical alarm handling for root cause nodes, including: In response to the root cause node, retrieve the edge attribute weights of the topological directed edges pointing from the root cause node to its direct downstream server nodes, and calculate the response time contribution. Compare the response time contribution with a preset correlation threshold to verify the causal validity of the root cause node, and lock it as the final diagnostic target when the verification is successful. Obtain the state weight of the final diagnosed target. Based on the combined characteristics of the state weight and response time contribution, determine whether the fault type is an explicit fault storm or a latent performance fault. If it is determined to be an explicit fault storm, identify the downstream derivative nodes of the final diagnosed target based on the service dependency topology graph and perform alarm convergence operation to intercept derivative alarms. If it is determined to be a latent performance fault, issue a deep diagnostic command to the final diagnosed target through the out-of-band management channel, collect a fine-grained snapshot of the runtime, and generate a diagnostic report by combining the response time contribution.
[0008] Preferably, the service topology construction module includes a heterogeneous data normalization subunit, a call chain reorganization subunit, a graph entity mapping subunit, and a multi-dimensional attribute fusion subunit; The call chain reorganization subunit is configured to aggregate discrete link span objects into a complete single request call chain based on the tracing identifier, and determine the upstream and downstream hierarchical relationship between server nodes according to the parent span identifier; The graph entity mapping subunit is configured to perform aggregation analysis on multiple single request call chains within a preset time window, extract server nodes, extract the call behavior between server nodes as topological directed edges, and generate an initial service dependency topology graph. The graph entity mapping subunit performs the following steps when generating the initial service dependency topology graph: extracting the source service identifier and target service identifier from the single request call chain; searching the topology graph data structure to see if a target server node exists corresponding to the source service identifier and target service identifier; if not, creating a new server node and adding it to the node set; establishing a topological directed edge from the source server node to the target server node, and calculating the call frequency and average response latency of the topological directed edge within a preset time window, writing the call frequency and average response latency as edge attribute weights into the topological directed edge.
[0009] Preferably, the graph entity mapping subunit is also configured to perform a topology aging and update strategy, including: Initialize the activity heat value of each directed edge in the topology; at the end of each update cycle, count the number of link spans that match the directed edge of the specific topology in each update cycle, and use it as the current traffic incentive value. Read the activity level value of the previous period and multiply it by the preset time decay factor to obtain the historical retention level. The historical retention heat value is added to the current traffic incentive value, and the result is truncated to the upper limit to obtain the current period's active heat value. The current period's activity level is compared with a preset aging threshold. If it is less than the aging threshold, the current directed edge in the topology is determined to be inactive, and logical removal or marking operations are performed.
[0010] Preferably, when generating a service dependency topology graph containing state weights, the multi-dimensional attribute fusion subunit is specifically configured as follows: obtain multi-source heterogeneous data of server nodes, and construct infrastructure feature vectors, runtime environment feature vectors and business performance feature vectors respectively; use the Min-Max interval scaling method to dedimensionalize each sub-index element in each feature vector and map its value to the preset standard [0,1] interval. The maximum value extraction operation is performed on the normalized infrastructure feature vector, runtime environment feature vector, and business performance feature vector respectively. The element with the largest value in each vector is selected as the infrastructure risk characterization value, runtime environment risk characterization value, and business performance risk characterization value of the server node respectively. The state weight of the server node is obtained by linearly weighting and aggregating the infrastructure risk characterization value, runtime environment risk characterization value, and business performance risk characterization value. The state weight is compared with the preset first threshold and second threshold to determine the rendering attribute of the server node in the service dependency topology graph. The rendering attribute includes at least the node fill color, node size level, or alarm flashing frequency. Specifically, a first threshold and a second threshold are preset, with the second threshold being greater than the first threshold; When the state weight is less than the first threshold, it means that the server node is in the normal operating range, and the node is filled with green color. When the state weight is between the first and second thresholds, it indicates that the server node is in the sub-health warning range, and the node is filled with yellow color. When the state weight is greater than the second threshold, it is determined to be a high-risk fault zone, and the node is filled with red color.
[0011] Preferably, the runtime environment feature vector includes at least one or more of the following combinations: The TCP connection anomaly distribution coefficient is configured to characterize the occupancy and release of network socket resources; the garbage collection pause overhead ratio is configured to characterize the impact of business thread pauses caused by the virtual machine memory reclamation process; and the database connection pool saturation is configured to characterize the saturation level of connection resources between server nodes and persistent storage media.
[0012] Preferably, the fault storm diagnosis module includes a spatiotemporal correlation clustering subunit; The spatiotemporal correlation clustering subunit is configured to monitor the state weights of each server node in the service dependency topology graph in real time. When it is detected that within a preset sliding time window, the state weights of more than a preset storm threshold of server nodes are in the high-risk fault range, the first subgraph extraction instruction is triggered. The first subgraph extraction instruction includes: based on the connection relationship of the service dependency topology graph, determining whether the server nodes in the high-risk fault zone constitute a connected subgraph; if a connected subgraph is formed, calculating the spatial density and time synchronization coefficient between nodes in the current connected subgraph, and associating the spatial density and time synchronization coefficient to obtain the spatiotemporal correlation; if the spatiotemporal correlation exceeds the preset correlation threshold, marking the current connected subgraph as the fault storm impact domain, and generating a storm event identifier.
[0013] Preferably, the fault storm diagnosis module also includes a reverse causal chain extraction subunit and a root cause confidence inference subunit; The reverse causal chain extraction sub-unit is configured as a response storm event identifier and performs a topology traversal operation within the fault storm's influence domain. Specifically, it starts from the edge node with the highest state weight in the fault storm's influence domain and performs a breadth-first search along the reverse direction of the directed edges in the topology. During the breadth-first search in the reverse direction, it obtains the state weight of the currently traversed upstream server node. If the state weight is greater than or equal to the first threshold, the upstream server node is determined to be in an abnormal state, and it is retained as a potential fault propagation node. The recursive search continues to its upstream nodes, thereby constructing a set of potential fault propagation paths composed of abnormal nodes. The set of potential fault propagation paths represents the cascading relationship of fault traffic spreading from the upstream root cause node to the downstream victim node. If the state weight is less than the first threshold, the current upstream server node is determined to be in a normal operating state, and it is removed as a bypass node. The search for the current branch path is terminated. The root cause confidence inference subunit is configured to calculate the fault propagation index for each candidate server node in the set of potential fault propagation paths; The root cause confidence inference subunit determines the candidate server node with the highest calculated fault propagation index as the root cause node and outputs the identifier of the current root cause node and a snapshot of its associated infrastructure layer performance indicators.
[0014] Preferably, the fusion alarm generation module includes an impact contribution quantification subunit and an alarm strategy subunit; The influence contribution quantification subunit is configured to respond to the root cause node and, based on the service dependency topology graph, retrieves the pre-stored edge attribute weights in the topological directed edges from the root cause node to its direct downstream server node. Calculate the contribution of root cause nodes to the overall response time degradation of downstream services by using edge attribute weights. A preset correlation threshold is set. If the contribution of response time is lower than the correlation threshold, it is determined that there is a deviation in the calculation of the current fault propagation index, and the candidate node with the second highest fault propagation index is re-verified. If the contribution of response time is higher than the correlation threshold, the current root cause node is locked as the final diagnosis target, and the contribution of response time is written into the alarm details as quantitative evidence. The alarm strategy subunit is configured to receive the final confirmed target and read the current root cause node's state weight; When the state weight is in the high-risk fault range, it is determined to be an explicit fault storm, and a storm blocking signal is generated. When the state weight is in the sub-health warning range or the normal range, and the contribution of the response time is higher than the correlation threshold, it is judged as a hidden performance failure and a depth probe signal is generated.
[0015] Preferably, the fusion alarm generation module also includes a cascaded noise suppression subunit and a deep scene capture subunit; The cascaded noise suppression subunit is configured to respond to storm blocking signals generated for explicit fault storms. In the service dependency topology graph, it performs downstream dependency traversal with the final diagnosed target as the root cause node; identifies all derived alarm nodes on the fault propagation path of the root cause node, and generates alarm convergence rules; using the alarm convergence rules, it intercepts independent alarm notifications for derived alarm nodes in the alarm push channel, and aggregates the fault summaries of derived alarm nodes into the root cause alarm card of the final diagnosed target, thereby achieving structured convergence of alarm storms.
[0016] Preferably, the deep field capture subunit is configured to respond to the deep probe signal generated for the latent performance fault, and issue a diagnostic instruction set to the host computing resource corresponding to the final diagnosed target through the out-of-band management channel; the diagnostic instruction set includes: triggering the thread stack dump of the Java Virtual Machine, collecting the memory heap histogram, and capturing the network packet digest of the most recent N seconds; receiving the runtime fine-grained snapshot returned by the execution of the diagnostic instruction set, merging it with the response time contribution data, and generating a latent fault diagnosis report.
[0017] This invention provides a server fault diagnosis system based on service topology correlation analysis. It has the following beneficial effects: (1) By integrating multi-source heterogeneous data from infrastructure, operating environment and business performance to construct multi-dimensional feature vectors and dynamic service topologies, a comprehensive quantitative perception of server health status was achieved, ensuring that physical resource bottlenecks and logical dependency anomalies could be accurately captured, laying the data foundation for full-link diagnosis.
[0018] (2) By using spatiotemporal correlation analysis to effectively filter discrete noise to identify real fault storms, and combining the dependency topology to perform upstream backtracking and fault propagation index calculation, the root cause node with the highest propagation influence can be accurately located in a large number of alarms, solving the problem of fault tracing in complex distributed systems.
[0019] (3) The response time contribution is calculated based on the edge attribute weight, and quantitative causal verification is performed on the root cause node to effectively eliminate irrelevant nodes that are related but do not substantially cause performance degradation, thereby reducing the misjudgment rate of automated diagnosis.
[0020] (4) Based on the state weight and contribution characteristics, the faults are classified. For the explicit storm, alarm convergence is performed to suppress cascading noise. For the implicit fault, the deep instruction set is triggered to capture runtime snapshots, thus realizing differentiated closed-loop processing that takes into account both alarm noise reduction and accurate on-site evidence collection. Attached Figure Description
[0021] Figure 1 This is a schematic diagram of the overall process of the present invention; Figure 2 This is a schematic diagram of the service topology construction module process of the present invention; Figure 3 This is a schematic diagram of the fault storm diagnosis module of the present invention; Figure 4 This is a schematic diagram of the alarm generation module process of the present invention. Detailed Implementation
[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0023] Example 1 Please see Figures 1 to 4 This invention provides a server fault diagnosis system based on service topology correlation analysis, comprising: The service topology construction module is configured to collect multi-source heterogeneous data from server nodes in real time, and construct infrastructure feature vectors, runtime environment feature vectors, and business performance feature vectors respectively; and, based on the application layer service call relationship data, construct and dynamically maintain a service dependency topology graph that presents the dependency relationships between server nodes. The fault storm diagnosis module is configured to calculate the state weight of server nodes based on infrastructure feature vectors, runtime environment feature vectors, and business performance feature vectors. When the state weights of multiple server nodes on the service dependency topology graph trigger alarms simultaneously within a preset time window, and the spatiotemporal correlation of the alarm nodes exceeds a preset correlation threshold, a fault storm event is determined to have occurred. Furthermore, an upstream backtracking analysis is performed from the downstream server node that triggered the alarm along the dependency relationship to locate the root cause node with the highest fault propagation index. The integrated alarm generation module is configured to perform quantitative verification and hierarchical alarm handling for root cause nodes, including: In response to the root cause node, retrieve the edge attribute weights of the topological directed edges pointing from the root cause node to its direct downstream server nodes, and calculate the response time contribution. Compare the response time contribution with a preset correlation threshold to verify the causal validity of the root cause node, and lock it as the final diagnostic target when the verification is successful. Obtain the state weight of the final diagnosed target. Based on the combined characteristics of the state weight and response time contribution, determine whether the fault type is an explicit fault storm or a latent performance fault. If it is determined to be an explicit fault storm, identify the downstream derivative nodes of the final diagnosed target based on the service dependency topology graph and perform alarm convergence operation to intercept derivative alarms. If it is determined to be a latent performance fault, issue a deep diagnostic command to the final diagnosed target through the out-of-band management channel, collect a fine-grained snapshot of the runtime, and generate a diagnostic report by combining the response time contribution.
[0024] In this embodiment, addressing the issue of cascading failures and "alarm storms" caused by strong dependencies between nodes in a microservice architecture, this invention constructs and dynamically maintains a service dependency topology graph. When multiple nodes simultaneously trigger alarms, it is not limited to single-point analysis but utilizes the topology structure to perform backtracking analysis from downstream server nodes to upstream. By calculating the fault propagation index and combining it with spatiotemporal correlation, the system can penetrate massive amounts of downstream derived alarms and accurately pinpoint the root cause node located upstream in the topology. This mechanism effectively achieves alarm convergence, reduces the interference of redundant information on operations and maintenance personnel, and improves the efficiency of locating fault sources in complex distributed networks.
[0025] To address the problem that traditional methods relying solely on simple thresholds or statistical correlations can easily misidentify high-load, non-faulty nodes as root causes, this invention introduces a quantitative verification step after identifying the root cause node. By retrieving the edge attribute weights of the directed edges in the topology and calculating the "response time contribution," the system can quantify the specific impact of the root cause node on downstream anomalies from a causal logic perspective. Only when the response time contribution meets the correlation threshold is the node confirmed as the final diagnostic target. This secondary verification mechanism ensures the rigor of fault diagnosis and effectively reduces the false alarm rate during the automatic diagnosis process.
[0026] To address the limitations of existing technologies in identifying "hidden performance faults" where service remains uninterrupted but performance deteriorates, and the lack of on-site data support, this invention distinguishes between explicit fault storms and hidden performance faults based on a combination of state weights and response time contribution characteristics. For hidden performance faults, the system automatically issues in-depth diagnostic commands and collects detailed runtime snapshots through out-of-band management channels. This design overcomes the data gaps in traditional monitoring tools when facing complex non-downtime faults, providing crucial on-site data support for subsequent fault reproduction and in-depth code-level investigation. This invention does not rely solely on single resource metrics but instead collects and integrates multi-source heterogeneous data, including infrastructure, runtime environment (such as garbage collection and database connection pools), and business performance, in real time to construct feature vectors. This multi-dimensional state awareness system makes the calculation of server node state weights more objective and comprehensive, enabling the capture of complex fault precursors that are difficult to reflect with a single metric, thereby improving the accuracy of server node health status assessment.
[0027] Example 2 This embodiment is an explanation based on Embodiment 1. Please refer to it. Figures 1 to 2 The service topology construction module includes a heterogeneous data normalization subunit, a call chain reorganization subunit, a graph entity mapping subunit, and a multi-dimensional attribute fusion subunit. The call chain reorganization subunit is configured to aggregate discrete link span objects into a complete single request call chain based on the tracing identifier, and determine the upstream and downstream hierarchical relationship between server nodes according to the parent span identifier; The graph entity mapping subunit is configured to perform aggregation analysis on multiple single request call chains within a preset time window, extract server nodes, extract the call behavior between server nodes as topological directed edges, and generate an initial service dependency topology graph. The graph entity mapping subunit performs the following steps when generating the initial service dependency topology graph: extracting the source service identifier and target service identifier from the single request call chain; searching the topology graph data structure to see if a target server node exists corresponding to the source service identifier and target service identifier; if not, creating a new server node and adding it to the node set; establishing a topological directed edge from the source server node to the target server node, and calculating the call frequency and average response latency of the topological directed edge within a preset time window, writing the call frequency and average response latency as edge attribute weights into the topological directed edge.
[0028] The graph entity mapping subunit is also configured to execute topology aging and update strategies, including: Initialize the activity heat value of each directed edge in the topology; at the end of each update cycle, count the number of link spans that match the directed edge of the specific topology in each update cycle, and use it as the current traffic incentive value. Read the activity level value of the previous period and multiply it by the preset time decay factor to obtain the historical retention level. The historical retention heat value is added to the current traffic incentive value, and the result is truncated to the upper limit to obtain the current period's active heat value. The current period's activity level is compared with a preset aging threshold. If it is less than the aging threshold, the current directed edge in the topology is determined to be inactive, and logical removal or marking operations are performed.
[0029] Specific implementation examples of topology aging and update strategies: After each update cycle ends, with the update cycle set to 15-60 seconds, the system performs an activity heat value calculation on all existing directed edges. Iterative calculation: ; in, This means reading the activity level value from the previous period and multiplying it by a preset time decay factor α to obtain the historical retention level; representing the "past state". Even if there is no traffic at present, the level will not instantly drop to zero, but will decay proportionally by α, reflecting the anti-jitter characteristics of topological stability; This is the current traffic incentive value, representing "current traffic". If a new call occurs, the popularity value will quickly rebound. `min` is configured with a saturation limit: ensuring the popularity value does not grow indefinitely, facilitating subsequent normalization. E i,j : Represents a topological directed edge from source server node i to target server node j.
[0030] H i,j (t): represents a directed edge E i,j The activity level at the end of time window t.
[0031] α: Time decay factor, with a value range of 0 < α < 1. The smaller the value of α, the faster the aging rate.
[0032] N i,j (t): The total number of link spans that the system actually captures matching the directed edge within the current time window t.
[0033] β: Traffic incentive weight, representing the contribution of a single call to popularity, with a value of 1.0.
[0034] H max : The upper limit of the activity level value to prevent the value from overflowing.
[0035] T th Aging threshold: Values below the aging threshold are considered inactive.
[0036] After the calculation is completed, the system performs a Boolean logic decision: ; Wherein, the set of nodes in the topology graph at the current moment is V. current Let S be the set of all link spans captured within the current time window. window .
[0037] For S window Each span object s in k Extract its source entity src(s) k ) and target entity dst(s k Construct the set of observation nodes V for the current period. observed : ; Expansion decision logic, calculate the new node set ΔV: ; This indicates that node v appears in the currently observed link data. This indicates that node v does not exist in the current topology graph data structure. v represents any newly discovered server node object that has not yet been recorded. like If the set is empty, then instantiation is performed on each element in the newly added node set ΔV, and the settings are updated. Similarly, for the set of directed edges E current Perform the same difference operation to discover any new calling relationships.
[0038] In this embodiment, the present invention achieves automated construction and dynamic full lifecycle management of complex dependencies in a distributed system through a service topology construction module and its subordinate graph entity mapping subunit. At the technical principle level, the system first utilizes a call chain reorganization subunit to aggregate discretely distributed link span objects into a complete single-request call chain based on tracking identifiers, thereby resolving the precise upstream and downstream hierarchical relationships between server nodes. Based on this, the graph entity mapping subunit automatically identifies and instantiates newly added server nodes through set difference operations, while simultaneously establishing topological directed edges and calculating the call frequency and average response latency within a preset time window as edge attribute weights, completing the transformation from static connections to a dynamic graph with performance attributes. A topology aging and update strategy based on an "activity heat model" is employed. Periodic heat iteration calculations are performed on each topological directed edge. This algorithm retains the historical activity heat value of the previous period by introducing a time decay factor α, and performs a weighted summation based on the traffic incentive value of the current period. Finally, the edge's activity status is determined by comparing it with an aging threshold, and logical cleanup is performed.
[0039] The beneficial effects of this embodiment are as follows: First, it achieves stability and anti-jitter capability of the topology relationship. By introducing a time decay factor, the system endows the topology connection with a certain "historical inertia," avoiding the erroneous instantaneous removal of topology edges due to network fluctuations or brief interruptions in business traffic (such as short periods without calls), thus ensuring the continuity and stability of the topology view in dynamically changing environments. Second, it possesses adaptive resource management and data cleaning capabilities. Through a dual judgment mechanism of traffic incentives and aging thresholds, the system can automatically identify and eliminate outdated and redundant connections that have not had business interactions for a long time, preventing the service dependency topology graph from becoming bloated due to the infinite accumulation of historical data, ensuring that the diagnostic system always focuses on the currently real and effective business paths, and reducing the system's computational load and storage overhead. Third, it improves the data dimension of fault diagnosis. By synchronously calculating and writing the call frequency and latency equilateral attribute weights when constructing the topology, this invention transforms a simple logical connection graph into a weighted graph with performance quantification indicators, providing an accurate data foundation for subsequently distinguishing between explicit faults and implicit performance degradation.
[0040] Example 3 This embodiment is an explanation based on Embodiment 2. Please refer to it. Figures 2 to 3 When generating a service dependency topology graph containing state weights, the multi-dimensional attribute fusion sub-unit is specifically configured as follows: obtain multi-source heterogeneous data of server nodes, construct infrastructure feature vectors, runtime environment feature vectors and business performance feature vectors respectively; use the Min-Max interval scaling method to dedimensionalize each sub-index element in each feature vector and map its value to the preset standard [0,1] interval. The runtime environment feature vector includes at least one or more of the following combinations: The TCP connection anomaly distribution coefficient is configured to characterize the occupancy and release of network socket resources; the garbage collection pause overhead ratio is configured to characterize the impact of business thread pauses caused by the virtual machine memory reclamation process; and the database connection pool saturation is configured to characterize the saturation level of connection resources between server nodes and persistent storage media.
[0041] The maximum value extraction operation is performed on the normalized infrastructure feature vector, runtime environment feature vector, and business performance feature vector respectively. The element with the largest value in each vector is selected as the infrastructure risk characterization value, runtime environment risk characterization value, and business performance risk characterization value of the server node respectively. The state weight of the server node is obtained by linearly weighting and aggregating the infrastructure risk characterization value, runtime environment risk characterization value, and business performance risk characterization value. The state weight is compared with the preset first threshold and second threshold to determine the rendering attribute of the server node in the service dependency topology graph. The rendering attribute includes at least the node fill color, node size level, or alarm flashing frequency. Specifically, a first threshold and a second threshold are preset, with the second threshold being greater than the first threshold; When the state weight is less than the first threshold, it means that the server node is in the normal operating range, and the node is filled with green color. When the state weight is between the first and second thresholds, it indicates that the server node is in the sub-health warning range, and the node is filled with yellow color. When the state weight is greater than the second threshold, it is determined to be a high-risk fault zone, and the node is filled with red color.
[0042] The server node status weight is defined as a quantitative value that represents the current health status or failure risk of the server node, and the value range is [0,1]. For each server node V i Constructing infrastructure feature vectors Business performance feature vector and runtime environment feature vectors ; ; ; ; in, Central processing unit load saturation, Indicates memory resident usage. This indicates the disk input and output throughput pressure. Indicates the packet loss rate in network transmission; Indicates the average response delay. Indicates the service call error rate. This represents the total number of request traffic received by the server node per unit of time. in, This represents the TCP connection anomaly distribution coefficient. This indicates the ratio of waste recycling downtime costs. Indicates the saturation level of the database connection pool; Among them, the TCP connection anomaly distribution coefficient The calculation formula is as follows:
[0043] in, This indicates the total number of incomplete connections that are currently being passively closed. Such connections indicate that the application layer code has not properly closed the Socket handle. This indicates the total number of connections currently in the active closing waiting state; This indicates the total number of connections currently in normal communication status. Waste recycling downtime costs The calculation formula is as follows:
[0044] in, M represents the length of the sampling time window, and M represents the total number of garbage collections that occur within the sampling time window. This represents the duration of the "Stop-The-World" (STW) pause caused by the k-th garbage collection. Database connection pool saturation The calculation formula is as follows:
[0045] in, This indicates the number of active connections currently executing SQL statements in the connection pool. This indicates the number of business threads currently blocked in the queue waiting to acquire a connection because the connection pool is full. This indicates the maximum number of allowed connections set in the connection pool configuration file; database connection pool saturation. Calculate the ratio of active requests to maximum capacity to quantify the degree of contention and blockage of server nodes for downstream persistent storage resources; Infrastructure feature vectors Business performance feature vector and runtime environment feature vectors The Min-Max scaling method is used to map all metrics to the [0,1] interval; and the server node V is calculated using the following formula. i State weights :
[0046] in, This represents the maximum element value after normalization of the feature dimensions within the infrastructure feature vector; This represents the maximum element value after normalization of the feature dimensions within the business performance feature vector; This represents the maximum element value after normalization of the feature dimensions within the runtime environment feature vector; in, For infrastructure layer weights, For runtime layer weights, Weighting for business performance; , , ; This embodiment sets up a scenario during a major e-commerce promotion, where the monitoring system collects raw monitoring data from the "order server node" at time T. At this time, the node experiences a sudden surge in traffic, causing the database connection pool to become full, but CPU and memory resources have not yet been exhausted.
[0047] At monitoring time TT, the system uses distributed probes to collect various heterogeneous data from multiple sources on the Vtrade server node in real time. The specific values collected are as follows: Infrastructure feature vector Data collection results: The system detected the following physical layer resource usage: Central Processing Unit (CPU) Load Saturation The collected value is 45%, or 0.45. This indicates that the CPU is currently under medium load and has not reached its bottleneck.
[0048] Memory resident usage The collected value is 60%, which is 0.60. Memory usage is high, but within a safe range.
[0049] Disk I / O throughput pressure The collected value is 10%, or 0.10. Disk read / write activity is low.
[0050] Network packet loss rate The collected value is 5%, or 0.05. There is slight packet loss in the network link, but it does not affect connectivity.
[0051] Runtime environment feature vector Data Acquisition and Calculation: The system delves into the middleware and reads the following key counter values: TCP connection state data: 800 connections are currently in normal communication; 10 connections are currently in the process of being passively closed but not yet completed; and 190 connections are currently in the process of actively closing and waiting. Based on the above data, the anomaly distribution coefficient will be calculated to be approximately 0.20.
[0052] Garbage collection (GC) data: Within a sampling time window of 60,000 milliseconds (1 minute), the total "Stop-The-World" pauses caused by garbage collection amounted to 1,200 milliseconds. Based on this data, the pause cost ratio will be calculated to be 0.02.
[0053] Database connection pool data: The connection pool configuration file sets the maximum allowed number of connections to 100; the number of active connections currently executing SQL is 95; the number of waiting threads currently blocked in the queue due to a full connection pool is 15. Based on the above data, the current total request demand is 110, exceeding the maximum capacity of 100, indicating a saturation overflow state. The calculation process is shown in Table 1 below: Table 1: Raw Data Acquisition Table for Runtime Environment
[0054] Business performance feature vector Data Collection Results: The system analyzes application layer business call logs and obtains the following metrics: Average response delay The measured value is 150 milliseconds. Compared to the system's unacceptable upper limit of 500 milliseconds, the current response speed is acceptable.
[0055] Service call error rate The collected value is 0.00%. No HTTP 500 error occurred in the current business request.
[0056] Request traffic per unit time The sampling rate is 1000 times / second. Compared to the single-machine design capacity of 2000 times / second, the current traffic is at a moderate level.
[0057] Step 2, Feature Vector Normalization and Maximum Value Extraction Table: Based on the set weight coefficients q1=0.2 (infrastructure), q2=0.3 (runtime), and q3=0.5 (business performance), calculate the final state weight W. state (V i W state (V i =0.2×0.60+0.3×1.00+0.5×0.50=0.67; Judgment: The first threshold is set to 0.40, and the second threshold is set to 0.75; Judgment result: The server node is within the range of [0.40, 0.75], and is judged to be in a "sub-health warning state". The system will perform the following operation: In the service dependency topology graph, the fill color of this node will be rendered as yellow.
[0058] Since this node is in a sub-optimal state, if subsequent analysis using "Response Time Contribution (PTC)" reveals that it is impacting downstream processes, it will further trigger the subsequent "Hidden Performance Failure" diagnostic process. Examples of multi-sample server node determination are shown in Table 2 below. Table 2: Example of sample determination for multi-sample server nodes Node number Maximum risk value of infrastructure Maximum risk value during runtime Maximum risk value for business performance State weights Rendering result (color) <![CDATA[V1]]> 0.10 (Low Load) 0.05 (Connection pool idle) 0.10 (Fast response) 0.085 green <![CDATA[V2]]> 0.40 (CPU fluctuation) 0.20 (GC normal) 0.20 0.240 green <![CDATA[V3]]> 0.90 (CPU spike) 0.30 (Connection successful) 0.20 (Undamaged) 0.370 green <![CDATA[V4]]> 0.20 (Resources are normal) 0.90 (DB pool saturated) 0.30 (slight vibration) 0.460 yellow <![CDATA[V5]]> 0.30 (Resources are normal) 1.00 (TCP Exhaustion) 0.40 (latency decreased) 0.560 yellow <![CDATA[V6]]> 0.10 (Resources are normal) 0.10 (normal environment) 0.80 (High error rate) 0.450 yellow <![CDATA[V7]]> 0.50 (High memory usage) 0.80 (Frequent GC) 0.60 (Delay anomaly) 0.640 yellow <![CDATA[V8]]> 0.60 (IO High) 0.90 (DB congestion) 0.85 (Request backlog) 0.815 red <![CDATA[V9]]> 0.85 (close to crash) 1.00 (No response) 0.95 (numerous timeouts) 0.945 red <![CDATA[V 10 ]]> 0.25 (normal) 0.25 (normal) 0.79 (critical value) 0.520 yellow
[0059] Data comparison (V3 vs. V4): V3 (high CPU): 0.9, final state weight 0.37 (green). V4 (full DB pool): 0.9, final state weight 0.46 (yellow).
[0060] This data demonstrates that "runtime environment" is more predictive of failures than "pure CPU load," and therefore it is given a higher weight (0.3 > 0.2), enabling potential problems to be detected earlier.
[0061] In this embodiment, a quantitative assessment system for the health status of server nodes based on multi-source heterogeneous data is constructed through a multi-dimensional attribute fusion subunit. At the technical principle level, the system first collects real-time infrastructure data (such as CPU load and memory usage), runtime environment data (such as TCP connection status, GC pauses, and database connection pool saturation), and business performance data (such as response latency and error rate) of the server nodes, constructing feature vectors for each. Subsequently, the system uses a Min-Max interval scaling method to dedimensionalize each indicator and extracts the maximum value from each vector as the risk characterization value. Finally, the system calculates the state weight using a linear weighted aggregation formula and determines the rendering attributes (such as color) of nodes in the topology graph based on dual threshold intervals (normal, sub-healthy, and high-risk).
[0062] The solution specifically introduces "runtime environment feature vector" as a key evaluation dimension, which covers in-depth indicators such as TCP connection anomaly distribution coefficient, garbage collection pause overhead ratio, and database connection pool saturation.
[0063] Traditional monitoring often relies too heavily on infrastructure metrics such as CPU or memory, easily overlooking performance bottlenecks caused by the exhaustion of middleware resources (such as database connection pools). This invention, by assigning a runtime environment weight (q2=0.3) higher than the infrastructure weight (q1=0.2), can preemptively classify a node's status as "sub-healthy (yellow)" even when the CPU load is not yet saturated but the database connections are full (such as the V4 node in the example). This allows for earlier detection of potential service blocking risks compared to simply relying on resource monitoring. By aggregating complex underlying multidimensional data into a single [0,1] state weight and directly mapping the weight range to the color (green, yellow, red) of the topology graph nodes, operations personnel can intuitively perceive the overall health distribution of the system through changes in the topology graph colors without having to review complex monitoring dashboards, quickly locating nodes in sub-healthy or high-risk states. The use of a "maximum value extraction" strategy instead of simple average calculation ensures that extreme anomalies in a single dimension (such as only extremely high network packet loss rate) are not diluted by other normal metrics, guaranteeing the sensitivity of risk characterization and avoiding missed detections.
[0064] Example 4 This embodiment is an explanation based on Embodiment 1. Please refer to it. Figures 2 to 3 The fault storm diagnosis module includes a spatiotemporal correlation clustering subunit; The spatiotemporal correlation clustering subunit is configured to monitor the state weights of each server node in the service dependency topology graph in real time. When it is detected that within a preset sliding time window, the state weights of more than a preset storm threshold of server nodes are in the high-risk fault range, the first subgraph extraction instruction is triggered. The first subgraph extraction instruction includes: based on the connection relationship of the service dependency topology graph, determining whether the server nodes in the high-risk fault zone constitute a connected subgraph; if a connected subgraph is formed, calculating the spatial density and time synchronization coefficient between nodes in the current connected subgraph, and associating the spatial density and time synchronization coefficient to obtain the spatiotemporal correlation; if the spatiotemporal correlation exceeds the preset correlation threshold, marking the current connected subgraph as the fault storm impact domain, and generating a storm event identifier.
[0065] Space density Calculated using the following formula:
[0066] in, This represents the total number of server nodes in the high-risk fault region of the connected subgraph. This represents the total number of directed edges in the connected subgraph that directly connect server nodes to two high-risk fault regions. And calculate the time synchronization coefficient. :
[0067] in, The standard deviation of the timestamps of the start of all server nodes entering the high-risk fault zone in the connected subgraph; This represents the preset time normalization window constant, which uses the exponential decay function to determine the standard deviation. When the standard deviation approaches 0, Ctime approaches 1 (fully synchronized); when the standard deviation approaches its maximum value, Ctime approaches 0.
[0068] Among them, spatial density and time synchronization coefficient The spatiotemporal correlation degree was calculated using the geometric mean method;
[0069] Spatial compactness is a normalized value based on graph theory density, ranging from [0,1], while temporal synchronicity is a normalized probability coefficient based on time window ratio, ranging from (0,1]. Since both are dimensionless scalars, the final spatiotemporal correlation degree S of the spatiotemporal correlation clustering subunits is calculated using the geometric mean method. corr The advantage of using the geometric mean method lies in its introduction of a multiplicative penalty mechanism. This means that when either spatial density or temporal synchronicity is low, the final spatiotemporal correlation will significantly decrease. This ensures that events identified as a "fault storm" must simultaneously possess significant spatial clustering and temporal synchronization characteristics, thereby effectively reducing the false alarm rate caused by random discrete faults.
[0070] Specific data example: Scenario 1 is set as a real "failure storm" event. Background: Node V1 (core database) goes down at 10:00:00, causing V2, V3, V4 and V5, which depend on it, to all turn red within 2 seconds (entering the high-risk failure zone).
[0071] Input data is set as: connected subgraph nodes (V sub ): 5 nodes {V1, V2, V3, V4, V5}. That is, |V sub |=5.
[0072] Connecting edges: V1 points to V2, V3, V4, and V5, and there are also calls between V2 and V3. There are a total of 6 directed edges, i.e., |E sub |=6.
[0073] Trigger timestamps: V1: 10:00:00; V2: 10:00:01; V3: 10:00:01; V4: 10:00:02; V5: 10:00:02; Calculation process: Step 1 is to calculate the space density (C) space ); Substitute into the formula: C space =2×6 / 5×(5-1)=12 / 20=0.6; The output 0.6 indicates that the nodes are closely connected and have a strong dependency relationship.
[0074] Step 2: Calculate time synchronization (C time ), calculate the standard deviation (σ) of the timestamp onset Time series (relative seconds): {0, 1, 1, 2, 2}; mean μ = 1.2; variance s 2 ≈0.56; Standard deviation σ onset ≈0.75; Calculate the synchronization coefficient: Substitute into the formula: C time=exp(-0.7560)≈0.987; Interpretation: 0.987 is close to 1, indicating that the fault occurred more synchronously.
[0075] Step 3: Calculate the spatiotemporal correlation degree (S corr Substituting into the formula: S corr =≈0.77; Judgment result: 0.77>0.6 (association threshold) → judged as "fault storm". System action: trigger root cause analysis, locate V1 as the root cause.
[0076] Scenario 2 is set as a randomly occurring "pseudo-storm" with the same 5 nodes and the same topology. However, the network fluctuates that day: V1 reports an error at 10:00, V2 reports an error due to a code bug at 10:15, and V3 reports an error due to a full disk at 10:40. Although these errors are connected, they are not causally related.
[0077] Input data: Connected subgraph nodes (V sub ): 5 nodes (same as above); |V sub |=5.
[0078] Connected edge (E) sub ): 6 edges (same as above). |E sub |=6; Trigger timestamp: V1:10:00:00(0s); V2:10:15:00(900s); V3:10:40:00(2400s); V4:10:05:00(300s); V5:10:20:00(1200s); Calculation process: Step 1 is to calculate the space density (C) space Since the topology remains unchanged, the result is still 0.6.
[0079] Analysis: Looking at the topology alone, they are indeed related, which can easily mislead traditional monitoring systems.
[0080] Step 2: Calculate time synchronization (C time ), calculate the standard deviation (σ) of the timestamp onset ): Time series: {0, 900, 2400, 300, 1200}, standard deviation σ onset ≈826 seconds (high degree of dispersion).
[0081] Calculate the synchronization coefficient: Substitute: C time ==exp(-13.76)≈0.000001; Interpretation: The result is close to 0, indicating that the time is completely out of sync.
[0082] Calculate the spatiotemporal correlation degree (S corr)Substituting: Scorr = 0.6 × 0.000001 ≈ 0.00077; Result: 0.00077 < 0.6 (association threshold) → judged as "non-storm event".
[0083] System action: Only send ordinary individual alarms, do not activate the storm emergency plan, and do not perform complex root cause backtracking calculations.
[0084] The fault storm diagnosis module also includes a reverse causal chain extraction subunit and a root cause confidence inference subunit; The reverse causal chain extraction sub-unit is configured as a response storm event identifier and performs a topology traversal operation within the fault storm's influence domain. Specifically, it starts from the edge node with the highest state weight in the fault storm's influence domain and performs a breadth-first search (BFS) along the reverse direction of the directed edges in the topology. During the breadth-first search in the reverse direction, it obtains the state weight of the currently traversed upstream server node. If the state weight is greater than or equal to the first threshold, the upstream server node is determined to be in an abnormal state (covering the sub-health warning range and the high-risk fault range), and is retained as a potential fault propagation node. The recursive search continues to its upstream nodes, thereby constructing a set of potential fault propagation paths composed of abnormal nodes. The set of potential fault propagation paths represents the cascading relationship of fault traffic spreading from the upstream root cause node to the downstream victim node. If the state weight is less than the first threshold, the current upstream server node is determined to be in a normal operating state, and is removed as a bypass node, and the search of the current branch path is terminated. The root cause confidence inference subunit is configured to calculate the failure propagation index for each candidate server node in the set of potential failure propagation paths, denoted as . ;
[0085] in, This represents the state weight of source server node i. Represents the set of potential fault propagation paths. This represents the state weight of the source server node i pointing to the target server node j. This represents the topological hop distance between source server node i and target server node j. The propagation impact coefficient is set between 0.1 and 1.0, with 0.5 being preferred. The propagation impact coefficient is a preset positive weighting factor used to adjust the gain ratio of the state weight of downstream affected nodes in the calculation of the fault propagation index. The propagation impact coefficient is negatively correlated with the average out-degree of nodes in the service topology graph; the denser the node connections, the higher the propagation impact coefficient. The smaller the value, the better, to prevent numerical explosion. This reflects the algorithm's adaptability and is a plus. The root cause confidence inference subunit determines the candidate server node with the highest calculated fault propagation index as the root cause node and outputs the identifier of the current root cause node and a snapshot of its associated infrastructure layer performance indicators.
[0086] In this embodiment, at the technical principle level, the system first uses spatiotemporal correlation clustering subunits to perform "spatiotemporal dual-dimensional" verification on nodes in high-risk zones. The spatiotemporal correlation degree is derived by calculating the spatial density and temporal synchronization coefficient of the connected subgraph and using the geometric mean method. This algorithm utilizes a multiplicative penalty mechanism to ensure that only spatially closely connected and temporally highly synchronized abnormal events are identified as "fault storms," thereby filtering out false storm alarms caused by network fluctuations or discrete error reports.
[0087] Once a storm event is confirmed, the system initiates the reverse causal chain extraction subunit, starting from the edge affected nodes and performing a breadth-first search (BFS) along the reverse direction of the directed edges in the topology. During this process, the system dynamically filters abnormal nodes based on state weights, eliminates normal bypasses, and constructs a precise set of potential fault propagation paths. Subsequently, the root cause confidence deduction subunit calculates the fault propagation index for each candidate node. The fault propagation index considers not only the node's own state weights but also the weighted cumulative influence of downstream affected nodes, where the propagation influence coefficient... It is negatively correlated with the average out-degree of the topology, thus enabling adaptive adjustment of the algorithm.
[0088] By introducing the geometric mean calculation of spatiotemporal correlation, this invention can mathematically distinguish between true cascading failures and random discrete anomalies, avoiding frequent false triggering of emergency plans by the operation and maintenance system due to "pseudo-storms" and improving the signal-to-noise ratio of alarms. Through inverse BFS search and fault propagation index calculation, the system can penetrate the massive number of derivative alarms on the surface and quantitatively assess the contribution of each node to the downstream fault propagation. Even when the root cause node's own state weight is not the highest (e.g., it is only in a sub-healthy state but causes a large-scale paralysis of downstream areas), it can accurately pinpoint the root cause based on its cumulative impact on downstream areas, solving the problem of traditional methods struggling to locate "hidden root causes." Propagation impact system Based on the mechanism of dynamic adjustment of topology density, the numerical explosion problem caused by too many downstream server nodes in dense graph structures is prevented, ensuring that the diagnostic algorithm can maintain stable computational performance in service topologies of different sizes and densities.
[0089] Example 5 This embodiment is an explanation based on Embodiment 1. Please refer to it. Figure 4 The integrated alarm generation module includes an impact contribution quantification subunit and an alarm strategy subunit; The impact contribution quantification subunit is configured as a response root node and, based on the service dependency topology graph, retrieves the pre-stored edge attribute weights (i.e., the call frequency and average response latency mentioned by the graph entity mapping subunit) in the topological directed edges from the root node to its direct downstream server nodes. Calculate the contribution of root cause nodes to the overall response time degradation of downstream services by using edge attribute weights. The contribution to response time, denoted as PTC, is calculated using the following formula:
[0090] in, This represents the real-time call frequency, directly read from the directed edge attributes of the topology. Within the fault storm's impact domain and fault window, it represents the number of times a downstream server node calls an upstream server node. Indicates the real-time average response latency. This represents the baseline average response latency, which is the average time the link takes during historically normal periods. This represents the total request throughput, which is the total number of inbound requests received by a downstream server node within the fault window and within the affected domain of the fault storm. Indicates the total average response time. Indicates the baseline total average response delay; This represents a smoothing factor to prevent the denominator from being 0; A preset correlation threshold is set. If the contribution of response time is lower than the correlation threshold, the preferred value is set to 5%. If the current fault propagation index calculation is found to be biased, the candidate node with the second highest fault propagation index will be re-verified. If the contribution of response time is higher than the correlation threshold, the current root cause node will be locked as the final diagnosis target, and the contribution of response time will be written into the alarm details as quantitative evidence. The alarm strategy subunit is configured to receive the final confirmed target and read the current root cause node's state weight; When the state weight is in the high-risk fault range, it is determined to be an explicit fault storm, and a storm blocking signal is generated. When the state weight is in the sub-health warning range or the normal range, and the contribution of the response time is higher than the correlation threshold, it is judged as a hidden performance failure and a depth probe signal is generated.
[0091] The fusion alarm generation module also includes a cascaded noise suppression subunit and a deep scene capture subunit; The cascaded noise suppression subunit is configured to respond to storm blocking signals generated for explicit fault storms. In the service dependency topology graph, it performs downstream dependency traversal with the final diagnosed target as the root cause node; identifies all derived alarm nodes on the fault propagation path of the root cause node, and generates alarm convergence rules; using the alarm convergence rules, it intercepts independent alarm notifications for derived alarm nodes in the alarm push channel, and aggregates the fault summaries of derived alarm nodes into the root cause alarm card of the final diagnosed target, thereby achieving structured convergence of alarm storms.
[0092] The deep field capture subunit is configured to respond to deep probe signals generated for latent performance faults and issue a set of diagnostic instructions to the host computing resources corresponding to the final diagnosed target through an out-of-band management channel. The set of diagnostic instructions includes: triggering thread stack dumps of the Java Virtual Machine, collecting memory heap histograms, and extracting network packet summaries from the last N seconds. It receives the runtime fine-grained snapshot returned by the execution of the diagnostic instructions, merges it with the response time contribution data, and generates a latent fault diagnosis report.
[0093] In this embodiment, at the technical principle level, the system first utilizes the influence contribution quantification subunit to perform quantitative verification of causal relationships. This unit does not rely entirely on the topology structure but instead calls pre-stored edge attribute weights to calculate the response time contribution. By comparing the deviation between real-time latency and baseline latency, and combining the call frequency and total throughput for weighted normalization, the specific contribution ratio of the root cause node to the overall downstream response time degradation is accurately calculated. The system sets a correlation threshold as a verification threshold. If the calculation result is lower than the threshold, a re-verification of the second-highest risk node is automatically triggered, realizing the self-correction of the diagnostic logic. Based on this, the alarm strategy subunit classifies faults into "explicit fault storms" and "latent performance faults" according to the dual dimensions of "state weight" and "response time contribution". For explicit faults, the cascaded noise suppression subunit uses the diagnosed node as the root and traverses downstream along the topological dependency relationship to identify and intercept independent alarms of all derived nodes, aggregating them into the root cause alarm card. For latent faults, the deep scene capture subunit issues commands through out-of-band management channels to collect JVM thread stacks, memory histograms, and network packet summaries. By introducing PTC metrics, this invention transforms qualitative topology analysis into quantitative contribution calculation, effectively eliminating irrelevant nodes that, while on the fault propagation path, do not substantially cause performance degradation, ensuring the accuracy of the final diagnosis and reducing the false positive rate of automated diagnosis. By identifying derivative nodes and executing interception aggregation strategies, the system can compress hundreds or thousands of cascading alarms caused by the same root cause into a single root cause notification, significantly reducing the information processing burden on operations personnel and allowing them to directly focus on the core fault source. For "grayscale faults" where service is not interrupted but performance is compromised, this invention can automatically trigger deep scene capture to obtain a detailed runtime snapshot (such as evidence of thread deadlock or memory leak) at the moment the fault occurs. This compensates for the shortcomings of traditional monitoring, which relies solely on metric data and lacks scene stack information, providing crucial diagnostic basis for subsequent code-level investigation.
[0094] The threshold is set to facilitate comparison. The size of the threshold depends on the amount of sample data and the number of bases set by those skilled in the art for each set of sample data; as long as it does not affect the ratio between the parameter and the quantized value, it is acceptable.
[0095] The above formulas are all derived from software simulation using a large amount of data and are selected to be close to the actual values. The coefficients in the formulas are set by those skilled in the art according to the actual situation. The above description is only a preferred embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any equivalent substitutions or changes made by those skilled in the art within the technical scope disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the protection scope of the present invention.
Claims
1. A server fault diagnosis system based on service topology correlation analysis, characterized in that, include: The service topology construction module is configured to collect multi-source heterogeneous data from server nodes in real time, and construct infrastructure feature vectors, runtime environment feature vectors, and business performance feature vectors respectively; and, based on the application layer service call relationship data, construct and dynamically maintain a service dependency topology graph that presents the dependency relationships between server nodes. The fault storm diagnosis module is configured to calculate the state weight of server nodes based on infrastructure feature vectors, runtime environment feature vectors, and business performance feature vectors. When the state weights of multiple server nodes on the service dependency topology graph trigger alarms simultaneously within a preset time window, and the spatiotemporal correlation of the alarm nodes exceeds a preset correlation threshold, a fault storm event is determined to have occurred. Furthermore, an upstream backtracking analysis is performed from the downstream server node that triggered the alarm along the dependency relationship to locate the root cause node with the highest fault propagation index. The integrated alarm generation module is configured to perform quantitative verification and hierarchical alarm handling for root cause nodes, including: In response to the root cause node, retrieve the edge attribute weights of the topological directed edges pointing from the root cause node to its direct downstream server nodes, and calculate the response time contribution. Compare the response time contribution with a preset correlation threshold to verify the causal validity of the root cause node, and lock it as the final diagnostic target when the verification is successful. Obtain the state weight of the final diagnosed target. Based on the combined characteristics of the state weight and response time contribution, determine whether the fault type is an explicit fault storm or a latent performance fault. If it is determined to be an explicit fault storm, identify the downstream derivative nodes of the final diagnosed target based on the service dependency topology graph and perform alarm convergence operation to intercept derivative alarms. If it is determined to be a latent performance fault, issue a deep diagnostic command to the final diagnosed target through the out-of-band management channel, collect a fine-grained snapshot of the runtime, and generate a diagnostic report by combining the response time contribution.
2. The server fault diagnosis system based on service topology correlation analysis according to claim 1, characterized in that, The service topology construction module includes a heterogeneous data normalization subunit, a call chain reorganization subunit, a graph entity mapping subunit, and a multi-dimensional attribute fusion subunit. The call chain reorganization subunit is configured to aggregate discrete link span objects into a complete single request call chain based on the tracking identifier, and determine the upstream and downstream hierarchical relationship between server nodes according to the parent span identifier. The graph entity mapping subunit is configured to perform aggregation analysis on multiple single request call chains within a preset time window, extract server nodes, extract the call behavior between server nodes as topological directed edges, and generate an initial service dependency topology graph. The graph entity mapping subunit performs the following steps when generating the initial service dependency topology graph: extracting the source service identifier and target service identifier from the single request call chain; searching the topology graph data structure to see if there is a target server node corresponding to the source service identifier and target service identifier; if not, creating a new server node and adding it to the node set; establishing a topological directed edge from the source server node to the target server node, and calculating the call frequency and average response latency of the topological directed edge within a preset time window, and writing the call frequency and average response latency as edge attribute weights into the topological directed edge.
3. The server fault diagnosis system based on service topology correlation analysis according to claim 2, characterized in that, The graph entity mapping subunit is also configured to execute a topology aging and update strategy, including: Initialize the activity heat value of each directed edge in the topology; at the end of each update cycle, count the number of link spans that match the directed edge of the specific topology in each update cycle, and use it as the current traffic incentive value. Read the activity level value of the previous period and multiply it by the preset time decay factor to obtain the historical retention level. The historical retention heat value is added to the current traffic incentive value, and the result is truncated to the upper limit to obtain the current period's active heat value. The current period's activity level is compared with a preset aging threshold. If it is less than the aging threshold, the current directed edge in the topology is determined to be inactive, and logical removal or marking operations are performed.
4. A server fault diagnosis system based on service topology correlation analysis according to claim 2, characterized in that, When generating a service dependency topology graph containing state weights, the multi-dimensional attribute fusion subunit is specifically configured to: acquire multi-source heterogeneous data of server nodes, construct infrastructure feature vectors, runtime environment feature vectors, and business performance feature vectors respectively; and use the Min-Max interval scaling method to dedimensionalize each sub-index element in each feature vector and map its value to a preset standard [0,1] interval. The normalized infrastructure feature vector, runtime environment feature vector, and business performance feature vector are subjected to maximum value extraction operation respectively. The element with the largest value in each vector is selected as the infrastructure risk characterization value, runtime environment risk characterization value, and business performance risk characterization value of the current server node. The state weight of the server node is obtained by linearly weighting and aggregating the infrastructure risk characterization value, the runtime environment risk characterization value, and the business performance risk characterization value. The state weight is compared with a preset first threshold and a second threshold to determine the rendering attributes of the server node in the service dependency topology graph. The rendering attributes include at least the node fill color. A first threshold and a second threshold are preset, with the second threshold being greater than the first threshold; When the state weight is less than the first threshold, it means that the server node is in the normal operating range, and the node is filled with green color. When the state weight is between the first and second thresholds, it indicates that the server node is in the sub-health warning range, and the node is filled with yellow color. When the state weight is greater than the second threshold, it is determined to be a high-risk fault zone, and the node is filled with red color.
5. A server fault diagnosis system based on service topology correlation analysis according to claim 4, characterized in that, The runtime environment feature vector includes at least one or more of the following combinations: The TCP connection anomaly distribution coefficient is configured to characterize the occupancy and release of network socket resources; The garbage collection pause overhead ratio is configured to characterize the impact of business thread pauses caused by the virtual machine memory reclamation process; Database connection pool saturation is configured to characterize the degree of saturation of connection resources between server nodes and persistent storage media.
6. A server fault diagnosis system based on service topology correlation analysis according to claim 1, characterized in that, The fault storm diagnosis module includes a spatiotemporal correlation clustering subunit; The spatiotemporal correlation clustering subunit is configured to monitor the state weights of each server node in the service dependency topology graph in real time. When it is detected that within a preset sliding time window, the number of server nodes with a state weight exceeding a preset storm threshold is in the high-risk fault range, the first subgraph extraction instruction is triggered. The first subgraph extraction instruction includes: determining whether the server nodes in the high-risk fault zone constitute a connected subgraph based on the connection relationship of the service dependency topology graph; If a connected subgraph is formed, the spatial density and time synchronization coefficient between nodes in the current connected subgraph are calculated, and the spatial density and time synchronization coefficient are correlated to obtain the spatiotemporal correlation. If the spatiotemporal correlation exceeds a preset correlation threshold, the current connected subgraph is marked as the fault storm influence domain, and a storm event identifier is generated.
7. A server fault diagnosis system based on service topology correlation analysis according to claim 1, characterized in that, The fault storm diagnosis module also includes a reverse causal chain extraction subunit and a root cause confidence inference subunit. The reverse causal chain extraction subunit is configured to respond to storm event identifiers and perform topology traversal operations within the fault storm's influence domain. Specifically, starting from the edge node with the highest state weight in the fault storm's influence domain, a breadth-first search is performed along the reverse direction of the directed edges of the topology; during the breadth-first search in the reverse direction, the state weight of the currently traversed upstream server node is obtained. If the state weight is greater than or equal to the first threshold, the upstream server node is determined to be in an abnormal state, and it is retained as a potential fault propagation node. The recursive search continues to its upstream nodes, thereby constructing a set of potential fault propagation paths composed of abnormal nodes. The set of potential fault propagation paths represents the cascading relationship of fault traffic spreading from the upstream root cause node to the downstream victim node; if the state weight is less than the first threshold, it is determined that the current upstream server node is in normal operation, it is removed as a bypass node, and the search of the current branch path is terminated. The root cause confidence inference subunit is configured to calculate the fault propagation index for each candidate server node in the set of potential fault propagation paths. The root cause confidence inference subunit determines the candidate server node with the highest calculated fault propagation index as the root cause node and outputs the identifier of the current root cause node and a snapshot of its associated infrastructure layer performance indicators.
8. A server fault diagnosis system based on service topology correlation analysis according to claim 1, characterized in that, The fusion alarm generation module includes an impact contribution quantification subunit and an alarm strategy subunit; The influence contribution quantification subunit is configured to respond to the root cause node and, based on the service dependency topology graph, retrieve the pre-stored edge attribute weights in the topological directed edges from the root cause node to its direct downstream server node. Calculate the contribution of root cause nodes to the overall response time degradation of downstream services by using edge attribute weights. A preset correlation threshold is set. If the contribution of response time is lower than the correlation threshold, it is determined that there is a deviation in the calculation of the current fault propagation index, and the candidate node with the second highest fault propagation index is re-verified. If the contribution of response time is higher than the correlation threshold, the current root cause node is locked as the final diagnostic target, that is, the candidate server node with the highest fault propagation index, and the contribution of response time is written into the alarm details as quantitative evidence. The alarm strategy subunit is configured to receive the final confirmed target and read the current root cause node's state weight. When the state weight is in the high-risk fault range, it is determined to be an explicit fault storm, and a storm blocking signal is generated. When the state weight is in the sub-health warning range or the normal range, and the contribution of the response time is higher than the correlation threshold, it is determined to be a latent performance failure, and a depth probe signal is generated.
9. A server fault diagnosis system based on service topology correlation analysis according to claim 1, characterized in that, The fusion alarm generation module also includes a cascaded noise suppression subunit and a deep scene capture subunit; The cascaded noise suppression subunit is configured to respond to a storm blocking signal generated in response to a manifest fault storm, and to perform downstream dependency traversal in the service dependency topology graph with the final diagnosed target as the root cause node. Identify all derived alarm nodes on the root cause node fault propagation path and generate alarm convergence rules; use alarm convergence rules to intercept independent alarm notifications for derived alarm nodes in the alarm push channel, and aggregate the fault summaries of derived alarm nodes into the root cause alarm card of the final diagnosed target to achieve structured convergence of alarm storms.
10. A server fault diagnosis system based on service topology correlation analysis according to claim 9, characterized in that, The deep field capture subunit is configured to respond to the deep probe signal generated for the latent performance fault and send a set of diagnostic instructions to the host computing resources corresponding to the final diagnosis target through the out-of-band management channel; The diagnostic instruction set includes: triggering a thread stack dump of the Java Virtual Machine, collecting a memory heap histogram, and extracting network packet summaries from the most recent N seconds; receiving a runtime fine-grained snapshot returned by the execution of the diagnostic instruction set, merging it with response time contribution data, and generating a hidden fault diagnosis report.
Citation Information
Cited By
Cloud edge collaboration-based service fault root cause analysis method and system
CN122293486A