Performance root cause positioning method and device for micro-service system, medium and product

Abstract

The embodiment of the invention discloses a performance root cause positioning method and device for a micro-service system, a medium and a product, and relates to the technical field of micro-services. The method comprises the following steps: in response to an abnormal instruction of a service performance index of a front-end entry service, determining a candidate service set which is in the same service calling link as the front-end entry service, and obtaining a response time sequence of each candidate service in a preset time window; determining a baseline value, converting the original response time into a normalized relative change rate, and determining a service subset having fluctuation similarity with the front-end entry service; performing timing causal analysis on the service subset to determine a timing causal score; and determining a comprehensive root cause score based on the fluctuation similarity, the influence weight and the time sequence causal score, determining a root cause service with the highest confidence coefficient according to the comprehensive root cause score, and outputting a root cause report. According to the scheme of the invention, when the performance of the front-end entry service is abnormal, the root cause service is automatically identified, and the fault positioning efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of microservices technology, and in particular to a method, device, medium, and product for locating the root cause of performance issues in microservice systems. Background Technology

[0002] In cloud-native environments, microservice system architectures are becoming increasingly complex, and the call chains between services are dynamic and ever-changing. Once the front-end entry service experiences performance anomalies (e.g., increased latency, increased error rate), quickly and accurately locating the root cause service becomes a key challenge to ensure system stability.

[0003] Currently, the operations and maintenance team primarily troubleshoots through independent monitoring and alerts for each service. When a system anomaly occurs, different teams typically check the metrics data of their own services and infer possible sources of the problem based on experience or simple rules. This troubleshooting method heavily relies on manual intervention and cross-team communication, lacking the ability to automatically analyze the performance impact relationships between services. This results in a time-consuming root cause localization process, a high false positive rate, and severely impacts fault recovery efficiency. Summary of the Invention

[0004] This invention provides a method, device, medium, and product for performance root cause localization in microservice systems, which solves the problems of low efficiency and insufficient accuracy in root cause localization caused by reliance on manual investigation and lack of automated correlation analysis of performance impact between services in the prior art. When a performance anomaly occurs in the front-end entry service, it can automatically identify candidate root cause services and output a structured root cause report containing the name of the root cause service, thereby improving the efficiency of fault localization.

[0005] According to one aspect of the present invention, a method for performance root cause localization in microservice systems is provided, the method comprising: In response to an abnormal command in the service performance index of the front-end entry service, a set of candidate services in the same business call chain as the front-end entry service is determined based on the service call topology, and the response time sequence of each candidate service in the set of candidate services is obtained within a preset time window. Based on the historical response time series of each candidate service before the anomaly occurred, a baseline value was determined, and the original response time was converted into a normalized relative rate of change to determine a subset of services that have fluctuation similarity with the front-end entry service. Based on the service call topology, the influence weight of each candidate service in the request propagation path is determined, and the service subset is subjected to temporal causal analysis to determine the temporal causal score. A comprehensive root cause score is determined based on the fluctuation similarity, the influence weight, and the temporal causality score. The root cause service with the highest confidence is determined based on the comprehensive root cause score, and a structured root cause report containing the name of the root cause service is output.

[0006] According to another aspect of the present invention, a performance root cause localization apparatus for microservice systems is provided, the apparatus comprising: The first determining module is used to respond to abnormal instructions of the service performance indicators of the front-end entry service, determine a set of candidate services that are in the same business call chain as the front-end entry service based on the service call topology, and obtain the response time sequence of each candidate service in the candidate service set within a preset time window. The second determining module is used to determine the baseline value based on the historical response time series of each candidate service before the anomaly occurs, and convert the original response time into a normalized relative rate of change to determine a subset of services that have fluctuation similarity with the front-end entry service; The third determining module is used to determine the influence weight of each candidate service in the request propagation path based on the service call topology, and to perform temporal causal analysis on the service subset to determine the temporal causal score. The root cause report generation module is used to determine a comprehensive root cause score based on the fluctuation similarity, the influence weight and the time-series causality score, determine the root cause service with the highest confidence based on the comprehensive root cause score, and output a structured root cause report containing the name of the root cause service.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the performance root cause localization method for microservice systems according to any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the performance root cause localization method for microservice systems as described in any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the performance root cause localization method for microservice systems as described in any embodiment of the present invention.

[0010] The technical solution of this invention, in response to an abnormal command in the service performance metrics of a front-end entry service, determines a set of candidate services in the same business call chain as the front-end entry service based on the service call topology, and obtains the response time sequence of each candidate service in the candidate service set within a preset time window; determines a baseline value based on the historical response time sequence of each candidate service before the anomaly occurs, and converts the original response time into a normalized relative rate of change to determine a subset of services with fluctuation similarity to the front-end entry service; and determines the influence weight of each candidate service in the request propagation path based on the service call topology. The method performs temporal causal analysis on the service subset to determine a temporal causal score; determines a comprehensive root cause score based on the fluctuation similarity, the influence weight, and the temporal causal score; identifies the root cause service with the highest confidence based on the comprehensive root cause score; and outputs a structured root cause report containing the name of the root cause service. This solves the problems of low efficiency and insufficient accuracy in root cause location caused by reliance on manual investigation and lack of automated correlation analysis of performance impact between services in the prior art. It can automatically identify candidate root cause services when the front-end entry service experiences performance anomalies and output a structured root cause report containing the name of the root cause service, thereby improving the efficiency of fault location.

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

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

[0013] Figure 1 This is a flowchart of a performance root cause localization method for microservice systems provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of a performance root cause localization method for microservice systems provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of a performance root cause localization device for microservice systems provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the performance root cause localization method for microservice systems according to embodiments of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Example 1 Figure 1 This is a flowchart of a performance root cause localization method for microservice systems according to Embodiment 1 of the present invention. This embodiment is applicable to the localization of abnormal performance root causes in microservice systems. The method can be executed by a performance root cause localization device for microservice systems, which can be implemented in hardware and / or software and can be configured in electronic devices such as computers, servers, or tablet computers. Figure 1 As shown, the method includes: Step 110: In response to the abnormal command of the service performance index of the front-end entry service, determine the set of candidate services that are in the same business call chain as the front-end entry service based on the service call topology, and obtain the response time sequence of each candidate service in the candidate service set within a preset time window.

[0017] Among them, the front-end entry service can be the first service node that a user requests to enter the microservice system, such as the API (Application Programming Interface) gateway or Web (World Wide Web) front-end service in an e-commerce system.

[0018] Optionally, in this embodiment, anomalies in the service performance metrics of the front-end entry service may include at least one of the following: the response time of the front-end entry service exceeds the dynamic baseline threshold; the error rate of the front-end entry service exceeds the preset error rate threshold; or the request rate of the front-end entry service is lower than the preset lower limit threshold.

[0019] In microservice systems, service performance metrics refer to observable data used to characterize the operational status and external service capabilities of a single service. These mainly include response time, error rate, request rate, and resource utilization. These metrics are typically reported by the service itself through embedded points, or automatically collected by service meshes or APM (Application Performance Monitoring) systems, and stored in the monitoring backend in time-series format. In this embodiment, the anomaly refers not to an externally issued command, but rather to the judgment result obtained by the monitoring system after real-time analysis of the above metrics based on preset rules or dynamic models. This judgment process typically includes any one or a combination of the following: threshold alarm: triggered when a metric exceeds a static threshold, for example, the P99 response time of the front-end entry service > 500ms; dynamic baseline deviation: the system constructs a dynamic baseline based on historical data (such as the sliding window mean ± 3σ), and an anomaly is judged when the current metric deviates significantly from this baseline; year-on-year / month-on-month sudden change: a drastic change in the metric compared to the same period yesterday or the previous period (for example, a sudden 10-fold increase in error rate); compound condition trigger: multiple metrics are judged jointly, for example, an increase in response time and a simultaneous increase in error rate. It is understood that in this embodiment, the root cause analysis process is automatically started after the performance indicators of the front-end entry service are detected to meet the preset anomaly judgment conditions.

[0020] A service call topology is a directed graph reflecting the dependencies between services. Nodes can be services, and edges can represent call relationships. For example, in an e-commerce microservice system, by aggregating distributed tracing data, the system constructs a directed graph reflecting the call relationships between services: the API gateway calls the order service, the order service further calls the inventory service and the payment service, and the payment service depends on the user service. Meanwhile, the notification service, because it is only called by background scheduled tasks and never appears in the main business request path, appears as an isolated node in the topology. This overall structure, containing all services and their dependencies, is the service call topology. For example, in an e-commerce system, API gateway → order service → inventory service constitute a call chain, where nodes are services and edges represent call directions.

[0021] The same business call chain refers to candidate services that are logically reachable by requests from the front-end entry service, excluding irrelevant bypass services. For example, when the API gateway experiences a response delay anomaly at 14:30, the system only considers services that might actually be called from the API gateway within the current user request context, including order services, inventory services, payment services, and user services, as candidate services in the same business call chain, excluding notification services or other irrelevant business modules not covered by this entry request path. This ensures that root cause analysis focuses on the set of services that may actually affect front-end performance.

[0022] In one optional implementation of this embodiment, when the service performance index of the front-end entry service is determined to be abnormal, based on the time of the abnormality and the identifier of the front-end entry service, a set of call chains associated with the current abnormal event is retrieved from the distributed tracing system. Each retrieved call chain uses the front-end entry service as its entry node, and its timestamp falls within a preset time floating window centered on the time of the abnormality. Further, each call chain in the call chain set is traversed, and all downstream service identifiers except for the front-end entry service are extracted according to the request execution order. The extracted results are deduplicated to form a candidate service set. Based on this, for each service in the candidate service set, the original response time data within a historical time period with the time of the abnormality as the endpoint and a preset time window as the length is queried from the monitoring index storage system. Further, the original response time data returned by each service is resampled according to a unified preset sampling interval to generate a time-axis aligned response time sequence. Missing time points during the resampling process are filled using a forward padding strategy. Finally, all aligned response time sequences are organized into structured data blocks and passed to the subsequent analysis module.

[0023] Step 120: Determine the baseline value based on the historical response time series of each candidate service before the anomaly occurs, and convert the original response time into a normalized relative rate of change to determine the service subset that has fluctuation similarity with the front-end entry service.

[0024] The historical response time series can be a record of the response time of the candidate service over a period of time before the anomaly occurred. For example, if the anomaly occurs at 14:30, the average response time per second during the period from 14:00 to 14:25 can be taken to form a time series of 750 data points.

[0025] Baseline values ​​can be used to characterize the typical response level of a service under normal conditions and can be calculated using statistical historical data. For example, the sliding window mean or median of the response time series over the past 30 minutes can be used as the baseline for the current moment.

[0026] The normalized relative change rate is a standardized indicator of the degree of change of the original response time relative to its baseline value. The calculation formula can be: relative change rate = (current time - baseline value) / baseline value; for example, if the baseline of a service is 100ms and the current time is 150ms, then the relative change rate is 0.5 (i.e., an increase of 50%).

[0027] Volatility similarity refers to the degree of morphological similarity between the normalized relative rate of change sequences of two services over time. It can be quantified using methods such as Pearson correlation coefficient, dynamic time warping (DTW), or cosine similarity. For example, if the volatility curves of both the front-end entry service and the inventory service show a sharp rise at 14:28, and the magnitude of the rise is similar, then they are considered to have high volatility similarity.

[0028] A service subset can be a set of services selected from all candidate services that are highly consistent with the fluctuation pattern of the front-end entry service, and can be used as input for subsequent causal analysis to avoid including services that are irrelevant to fluctuation in the root cause assessment.

[0029] Optionally, in this embodiment, for each candidate service, a dynamic baseline value can be calculated based on its historical response time series before the anomaly occurred. This baseline can be generated using methods such as the moving window median, exponentially weighted moving average (EWMA), or quantile regression to adapt to periodic or trend changes in service performance. Furthermore, the baseline value at the corresponding moment is subtracted point-by-point from the original response time of each candidate service within a preset time window, and then divided by the baseline value to obtain a normalized relative rate of change sequence. This eliminates the difference in absolute response time magnitude between different services, making the fluctuation amplitude comparable.

[0030] Furthermore, a similarity metric can be calculated between the normalized relative rate of change sequence of each candidate service and the normalized relative rate of change sequence of the front-end entry service. The Pearson correlation coefficient can be used to measure linear correlation, or dynamic time-normalized distance can be used to handle temporal offsets. Candidate services with similarity metrics exceeding a preset threshold are filtered out to form a service subset. This subset includes only services whose fluctuation behavior is highly correlated with the entry anomaly, significantly narrowing the scope of subsequent causal analysis.

[0031] In one optional implementation of this embodiment, for each candidate service, based on its historical response time series before the anomaly occurred, the baseline value corresponding to each time point is calculated using the sliding window midpoint method; for each data point in the original response time series of each candidate service within a preset time window, the baseline value of the corresponding time point is subtracted and then divided by the baseline value to obtain a normalized relative rate of change sequence; similarly, the same baseline calculation and normalization process is performed on the front-end entry service to generate its normalized relative rate of change sequence; the Pearson correlation coefficient between the normalized relative rate of change sequence of each candidate service and the normalized relative rate of change sequence of the front-end entry service is calculated; candidate services with a Pearson correlation coefficient greater than a preset similarity threshold are selected to form a service subset.

[0032] For example, in one instance, the API gateway experienced a sudden increase in latency at 14:30. The system used data from 14:00 to 14:25 as a historical window to calculate the baselines for the order service, inventory service, and payment service. The inventory service baseline was 80ms, rising to 200ms at 14:28, with a relative change rate of 1.5; the API gateway baseline rose from 100ms to 250ms during the same period, also with a relative change rate of 1.5. The trends of both services were highly synchronized, with a Pearson correlation coefficient of 0.92, exceeding the threshold of 0.7. Therefore, the inventory service was included in the service subset. The payment service, although showing slight fluctuations (correlation coefficient 0.3), was not selected.

[0033] Step 130: Determine the influence weight of each candidate service in the request propagation path based on the service call topology, and perform temporal causal analysis on the service subset to determine the temporal causal score.

[0034] The influence weight can be used to quantify the degree of impact of a candidate service on the performance of the front-end entry service, and can be determined by its position in the call path or the frequency of the call. For example, the order service, which is directly called by the API gateway, has a higher influence weight than the inventory service, which is indirectly called; if a service is passed through by 90% of the request path, its weight is also higher.

[0035] The request propagation path can be the call chain from the front-end entry service to a candidate service. For example, the path from the API gateway to the inventory service is "API gateway → order service → inventory service", with a path length of 2 hops.

[0036] Temporal causal analysis can determine whether there is a causal relationship by analyzing the time sequence of performance fluctuations between services. For example, if the inventory service experiences a delay at 14:28:10, while the API gateway only slows down at 14:28:15, there may be a causal relationship where the inventory service causes the gateway to slow down.

[0037] The temporal causality score can be used to quantify the strength of causality between a service and the front-end entry service. The higher the score, the more likely the service is to experience an anomaly before the entry service, indicating that it possesses root cause characteristics.

[0038] Optionally, in this embodiment, after determining the service subset with fluctuation similarity to the front-end entry service, it is possible to further calculate the shortest call distance from each candidate service in the service subset to the front-end entry service based on the service call topology. The shortest call distance is the number of edges in the call path. Simultaneously, the proportion of the candidate service appearing in the call chain starting from the front-end entry service within a preset historical period is counted as its call frequency weight. The inverse of the shortest call distance is then weighted and averaged with the call frequency weight to obtain the influence weight of the candidate service. Further, the normalized relative change rate sequences of each candidate service in the service subset are compared with the normalized relative change rate sequence of the front-end entry service. The time series is resampled at a preset sampling interval to a uniform time granularity, forming an aligned time series. For each aligned time series, the time point when the response time first exceeds a preset multiple (e.g., 1.5 times) of its baseline value is traced back from the time of the anomaly and taken as the fluctuation start time of the service. The time difference between the fluctuation start time of each candidate service and the fluctuation start time of the front-end entry service is calculated. If the time difference is greater than zero and less than the preset maximum propagation delay threshold, the time difference is substituted into a preset monotonically increasing mapping function (e.g., a linear function or a sigmoid function) to calculate the time-series causality score. If the time difference is less than or equal to zero or greater than or equal to the maximum propagation delay threshold, the time-series causality score is set to zero.

[0039] For example, in a single order delay failure, the service subset includes the order service and the inventory service. The topology shows: API Gateway → Order Service, Order Service → Inventory Service. Historical data shows that the order service appears in 95% of requests, while the inventory service appears in 80%, thus the order service has a higher impact weight. Time-series analysis reveals that the inventory service's fluctuations begin at 14:28:08, the order service at 14:28:10, and the API gateway at 14:28:12. The inventory service is 4 seconds ahead of the gateway, earning a causal score of 0.85; the order service is 2 seconds ahead, earning 0.65. Ultimately, the inventory service scores higher on the causal dimension.

[0040] Step 140: Determine the comprehensive root cause score based on fluctuation similarity, influence weight, and time-series causality score. Based on the comprehensive root cause score, determine the root cause service with the highest confidence and output a structured root cause report containing the name of the root cause service.

[0041] Optionally, in this embodiment, after determining the time-series causal score, the three normalized indicators can be further weighted and summed based on preset first weight coefficients, second weight coefficients, and third weight coefficients to obtain an initial root cause score. Further, a confidence calibration model trained based on historical root cause annotation data can be used to perform a non-linear mapping on the initial root cause score to obtain a calibrated root cause score. Further, it is determined whether the response time of each candidate service during the abnormal period exceeds its baseline value. If it does not exceed the baseline value, the calibrated root cause score of the candidate service is multiplied by a preset penalty factor to obtain a comprehensive root cause score.

[0042] Based on this, candidate services are sorted in descending order according to the comprehensive root cause score, and the candidate service ranked first is identified as the root cause service. Then, based on the service call topology, the shortest call path from the root cause service to the front-end entry service is determined. At the same time, the fluctuation start time of the root cause service and the fluctuation start time of the front-end entry service are obtained, and the difference between the two is calculated as the fluctuation advance time. Finally, the root cause service name, shortest call path, fluctuation advance time, and comprehensive root cause score are organized into a structured root cause report according to a preset data format and output to the external system.

[0043] The technical solution of this embodiment, in response to an abnormal command of the service performance index of the front-end entry service, determines a set of candidate services in the same business call chain as the front-end entry service based on the service call topology, and obtains the response time sequence of each candidate service in the candidate service set within a preset time window; determines the baseline value based on the historical response time sequence of each candidate service before the anomaly occurs, and converts the original response time into a normalized relative rate of change to determine a service subset with fluctuation similarity to the front-end entry service; determines the influence weight of each candidate service in the request propagation path based on the service call topology, performs time-series causal analysis on the service subset to determine the time-series causal score; determines the comprehensive root cause score based on fluctuation similarity, influence weight, and time-series causal score, determines the root cause service with the highest confidence based on the comprehensive root cause score, and outputs a structured root cause report containing the name of the root cause service. This solves the problems of low efficiency and insufficient accuracy in root cause location caused by reliance on manual investigation and lack of automated correlation analysis of performance impact between services in the prior art. It can automatically identify candidate root cause services when the front-end entry service experiences performance anomalies and output a structured root cause report containing the name of the root cause service, thereby improving the efficiency of fault location.

[0044] Example 2 Figure 2This is a flowchart of a performance root cause localization method for microservice systems according to Embodiment 2 of the present invention. This embodiment is a further refinement of the above technical solution, and the technical solution in this embodiment can be combined with various optional solutions in one or more of the above embodiments. Figure 2 As shown, the method includes: Step 210: Determine the set of candidate services that are in the same business call chain as the front-end entry service based on the service call topology, and obtain the response time sequence of each candidate service in the candidate service set within a preset time window.

[0045] Optionally, in this embodiment, determining a set of candidate services that are in the same business call chain as the front-end entry service based on the service call topology, and obtaining the response time sequence of each candidate service in the candidate service set within a preset time window, may include: obtaining the service call topology, and determining all downstream services originating from the front-end entry service as a set of candidate services based on the service call topology; obtaining the response time data of each candidate service within a preset time window ending at the time of the anomaly occurrence from the monitoring indicator storage system, and constructing a response time sequence.

[0046] Among them, the service call chain data is the call chain triggered by business requests related to the current abnormal event, starting from the front-end entry service.

[0047] In one optional implementation of this embodiment, after the service performance index of the front-end entry service is determined to be abnormal, the call chain set associated with the current abnormal event can be retrieved from the distributed tracing system based on the time of the abnormality and the identifier of the front-end entry service. Each retrieved call chain uses the front-end entry service as its entry node, and its timestamp falls within a preset time floating window centered on the time of the abnormality. Further, each call chain in the call chain set is traversed, and all downstream service identifiers except for the front-end entry service are extracted according to the request execution order. The extracted results are deduplicated to form a candidate service set. Based on this, for each service in the candidate service set, the original response time data within a historical time period with the time of the abnormality as the endpoint and a preset time window as the length is queried from the monitoring index storage system. Then, the original response time data returned by each service is resampled according to a unified preset sampling interval to generate a time-axis aligned response time sequence. Missing time points during the resampling process are filled using a forward padding strategy. Finally, all aligned response time sequences are organized into structured data blocks and passed to the subsequent processing module.

[0048] For example, an e-commerce platform detected a sudden increase in P99 latency of 8 seconds to its API gateway at 14:30. The system retrieved 1200 call chain records from the distributed tracing platform between 14:28 and 14:32, all of which used the API gateway as the entry point. Analysis revealed that the order service and inventory service frequently appeared in these call chains, while the notification service, although present in the overall system dependencies, was not invoked in any of the call chains related to this anomaly. Therefore, the candidate service set only included the order service and inventory service. Subsequently, the system queried the response time per second data of these two services from the monitoring metric storage system between 14:25 and 14:30, and resampled it into 300 time-aligned data points for subsequent root cause analysis.

[0049] Step 220: Determine the baseline value based on the historical response time series of each candidate service before the anomaly occurs, and convert the original response time into a normalized relative rate of change to determine the service subset that has fluctuation similarity with the front-end entry service.

[0050] Optionally, in this embodiment, determining the baseline value based on the historical response time series of each candidate service before the anomaly occurs, and converting the original response time into a normalized relative rate of change, and determining the service subset with fluctuation similarity to the front-end entry service may include: determining the baseline value of each candidate service based on the response time series of each candidate service within a preset historical period ending at the time of the anomaly; determining the normalized relative rate of change sequence based on the baseline value and the original response time of each candidate service within a preset time window; determining the fluctuation similarity between the normalized relative rate of change sequence of each candidate service and the normalized relative rate of change sequence of the front-end entry service; and determining the candidate services whose fluctuation similarity meets the preset conditions as the service subset.

[0051] The preset historical time period can be the time range used to calculate the baseline, which is located before the anomaly occurred. For example, if the anomaly occurs at 14:30, then 14:00–14:25 can be used as the historical time period to reflect the performance level under normal service conditions.

[0052] The service subset is a set of services selected from all candidate services that highly correlate with the fluctuation pattern of the front-end entry service. For example, among the three candidates—order service, inventory service, and payment service—only the inventory service has a correlation coefficient with the API gateway exceeding the 0.7 threshold, and therefore it was selected into the service subset.

[0053] In an optional implementation of this embodiment, after determining the candidate service set, for each candidate service in the candidate service set, based on its response time series within a preset historical period ending at the time of the anomaly, a sliding window midpoint method is used to calculate its baseline value at each time point within the preset time window. The length of the sliding window can be dynamically set according to the historical periodicity characteristics of the service. Further, for each data point in the original response time series of the candidate service within the preset time window, the baseline value corresponding to the same time point is subtracted, and the difference is divided by the baseline value, thereby generating a dimensionless normalized relative rate of change sequence. Based on this, the same processing flow is performed on the front-end entry service, namely, calculating the baseline value based on its response time series within the same preset historical period, and normalizing its original response time within the preset time window to obtain the normalized relative rate of change series of the front-end entry service; then, aligning the normalized relative rate of change series of each candidate service with the normalized relative rate of change series of the front-end entry service by time point, and calculating the Pearson correlation coefficient between the two as a quantitative indicator to measure the similarity of fluctuations; finally, the candidate services with a Pearson correlation coefficient greater than or equal to a preset similarity threshold are selected to form a service subset for subsequent analysis.

[0054] In one example of this embodiment, the API gateway experienced a sudden increase in latency at 14:30. The system used data from 14:00–14:25 to calculate baselines: 120ms for the order service, 80ms for the inventory service, and 100ms for the API gateway. During the period from 14:25–14:30, the response time of the inventory service increased from 80ms to 200ms (relative rate of change 1.5), and the API gateway increased from 100ms to 250ms (relative rate of change 1.5). The fluctuations of both were highly synchronized, with a Pearson correlation coefficient of 0.92. While the order service also fluctuated, its correlation coefficient was only 0.45. Setting a similarity threshold of 0.7, only the inventory service was ultimately included in the service subset.

[0055] The solution in this embodiment dynamically determines the baseline value of each candidate service based on the historical response time series before the anomaly occurs. This effectively adapts to normal fluctuations in service performance and avoids misjudging periodic peaks as anomalies. By converting the original response time into a normalized relative rate of change sequence, the difference in the absolute magnitude of response time between different services is eliminated, making the fluctuation patterns across services comparable. On this basis, by calculating the fluctuation similarity with the front-end entry service and setting a reasonable threshold to filter service subsets, only candidate services with highly consistent performance change trends are retained. This significantly reduces noise interference and computational complexity in subsequent causal analysis, providing a highly relevant input basis for comprehensive root cause scoring.

[0056] Step 230: Determine the influence weight of each candidate service in the request propagation path based on the service call topology, and perform temporal causal analysis on the service subset to determine the temporal causal score.

[0057] Optionally, in this embodiment, determining the influence weight of each candidate service in the request propagation path based on the service call topology and performing time-series causal analysis on the service subset to determine the time-series causal score may include: determining the influence weight of each candidate service based on the call distance or call frequency from each candidate service to the front-end entry service in the service call topology; resampling the normalized relative change rate sequence of each candidate service in the service subset and the normalized relative change rate sequence of the front-end entry service to a unified time granularity to obtain an aligned time series; determining the time offset between the fluctuation start time of each candidate service and the fluctuation start time of the front-end entry service based on the aligned time series, and determining the time-series causal score based on the time offset.

[0058] The call distance refers to the number of edges (i.e., hops) along the shortest path from the front-end entry service to a candidate service in the call topology. For example, in the call chain "API Gateway → Order Service → Inventory Service", the call distance for the order service is 1, and for the inventory service it is 2. The closer the distance, the more direct the impact on the entry performance.

[0059] Call frequency refers to the proportion of a candidate service that is indirectly or directly called by the front-end entry service in historical requests. For example, if in the past hour, out of 1000 call chains originating from the API gateway, 850 involved inventory services, then its call frequency is 85%. High-frequency services are more likely to be related to the current anomaly.

[0060] The influence weight is a value calculated by combining the call distance and call frequency, used to quantify the potential influence of candidate services on the front-end entry service. Generally, the closer the distance and the higher the frequency, the greater the weight. For example, the order service (distance 1, frequency 90%) has a higher influence weight than the inventory service (distance 2, frequency 80%).

[0061] Resampling to a uniform time granularity refers to aligning time series from different services that differ in reporting frequency to the same time axis. For example, if service A reports every second and service B reports every 2 seconds, interpolation or padding can be used to unify them to one point per second, facilitating subsequent comparisons.

[0062] The fluctuation start point refers to the time when the service response time first deviates significantly from the baseline. For example, it can be defined as the moment when the response time first exceeds 1.5 times the baseline value. For instance, the inventory service first breaks the baseline at 14:28:08, which is its fluctuation start point.

[0063] The time offset and temporal causality score are correlated as follows: if the candidate service fluctuates earlier than the front-end entry service, the time difference is positive, which is mapped to a higher causality score; if it is synchronous or lagging, the score is zero or very low. For example, if the inventory service fluctuates 4 seconds earlier than the API gateway, the time offset is +4 seconds, and the mapped score is 0.85.

[0064] In an optional implementation of this embodiment, after obtaining the service subset, the shortest call distance from each candidate service in the service subset to the front-end entry service can be calculated based on the service call topology, and the proportion of each candidate service appearing in the call chain starting from the front-end entry service in the past preset historical period can be counted as the call frequency; the reciprocal of the shortest call distance is then weighted and averaged with the call frequency according to a preset ratio to obtain the influence weight of each candidate service. Furthermore, the normalized relative change rate sequences of each candidate service in the service subset and the normalized relative change rate sequences of the front-end entry service are resampled to a unified time granularity according to a preset sampling interval to form an aligned time series. Based on this, tracing back from the time of the anomaly, the time points when the response times of each candidate service and the front-end entry service first exceed a preset multiple of their corresponding baseline values ​​are detected as their respective fluctuation start times. Then, the time difference between the fluctuation start time of each candidate service and the fluctuation start time of the front-end entry service is calculated. If the time difference is greater than zero and less than a preset maximum propagation delay threshold, the time difference is substituted into a preset monotonically increasing mapping function to obtain the corresponding temporal causality score. If the time difference is less than or equal to zero or greater than or equal to the maximum propagation delay threshold, the temporal causality score is set to zero.

[0065] The solution in this embodiment combines structural information and historical call behavior in the service call topology to quantify the influence weight of each candidate service on the front-end entry service, which can reflect the actual difference in the influence of different services in the request propagation path. On this basis, by performing time alignment on the normalized relative change rate sequence and accurately identifying the start time of fluctuations, the sequence of performance degradation between services can be effectively captured.

[0066] Step 240: Determine the comprehensive root cause score based on fluctuation similarity, influence weight, and time-series causal score.

[0067] Optionally, in this embodiment, determining the comprehensive root cause score based on fluctuation similarity, influence weight, and time-series causality score may include: weighting and fusing fluctuation similarity, influence weight, and time-series causality score to obtain an initial root cause score; performing a nonlinear mapping on the initial root cause score based on a confidence calibration model trained using historical root cause annotation data to obtain a calibrated root cause score; and applying a penalty factor to the root cause scores of candidate services whose response time does not exceed their own baseline value during abnormal periods to obtain a comprehensive root cause score.

[0068] The confidence calibration model can be a lightweight regression model (e.g., logistic regression, gradient boosting tree) trained based on historical failure cases, used to map the initial score to a more reliable confidence level. For example, if a service with an initial score of 0.8 has a 90% probability of being the true root cause in the past, the calibrated output would be 0.9.

[0069] The penalty factor is a mechanism that can be used to suppress spuriously related services. For example, if a service's response time is similar to the entry point fluctuation but does not exceed the baseline (i.e., there is no real degradation), its score is discounted. For instance, a penalty factor of 0.5 can be applied to avoid misjudging passively affected services as the root cause.

[0070] In one optional implementation of this embodiment, after determining the fluctuation similarity, influence weight, and temporal causality score of each candidate service, the three indicators can be normalized to the [0,1] interval. Further, based on preset first, second, and third weight coefficients, the normalized three indicators are weighted and summed to obtain an initial root cause score. On this basis, the initial root cause score is input into a confidence calibration model trained based on historical root cause annotation data. This model performs a non-linear mapping on the initial root cause score, outputting a calibrated root cause score. Further, it is determined whether the original response time of each candidate service during the abnormal period exceeds its corresponding baseline value. If it does not exceed the baseline value, the calibrated root cause score of the candidate service is multiplied by a preset penalty factor to obtain a comprehensive root cause score. If it exceeds the baseline value, the calibrated root cause score is directly used as the comprehensive root cause score.

[0071] In one example of this embodiment, during an order delay failure, the inventory service's fluctuation similarity was 0.92, its impact weight was 0.65, its temporal causality score was 0.85, and its initial score after weighted fusion (0.4 / 0.3 / 0.3) was 0.829. After calibration and model mapping, the score was 0.86. Since its response time increased from 80ms to 200ms, significantly exceeding the baseline, no penalty was required. Another candidate service, the recommendation service, although similar to the API gateway's fluctuation (similarity 0.78), had a response time consistently near the baseline (50ms ± 5ms), showing no real degradation. Therefore, its calibrated score of 0.72 was multiplied by a penalty factor of 0.5, resulting in a final comprehensive score of only 0.36, and it was excluded from the root cause candidate list.

[0072] The solution in this embodiment integrates fluctuation similarity, influence weight, and temporal causality score into a multi-dimensional weighted fusion, comprehensively considering the correlation of performance changes between services, the influence of topology, and temporal primacy, thus avoiding the one-sidedness of a single-dimensional judgment. It introduces a confidence calibration model trained based on historical root cause annotation data, effectively correcting the distribution bias of the initial score and improving the consistency between the score and the probability of the true root cause. Furthermore, by applying a penalty factor to candidate services that did not experience actual performance degradation during abnormal periods, it effectively suppresses the possibility of "pseudo-correlated" services that only exhibit fluctuations due to downstream propagation effects being misjudged as root causes, thereby significantly improving the accuracy, robustness, and interpretability of the comprehensive root cause score.

[0073] Step 250: Determine the root cause service with the highest confidence based on the comprehensive root cause score, and output a structured root cause report containing the name of the root cause service.

[0074] Optionally, in this embodiment, determining the root cause service with the highest confidence based on the comprehensive root cause score and outputting a structured root cause report containing the name of the root cause service may include: ranking candidate services according to the comprehensive root cause score and determining the candidate service ranked first as the root cause service; determining the call path from the root cause service to the front-end entry service based on the service call topology; extracting the fluctuation start time of the root cause service and its fluctuation advance time relative to the front-end entry service; and combining the root cause service name, call path, fluctuation advance time, and comprehensive root cause score to form a structured root cause report.

[0075] The root cause service is the one with the highest overall score among all candidate services and is deemed most likely to cause front-end anomalies. For example, in an e-commerce order delay failure, if the inventory service has the highest score, it is identified as the root cause service.

[0076] A call path is the complete service link from the front-end entry service to the root cause service, and it consists of directed edges in the service call topology. For example, "API Gateway → Order Service → Inventory Service" is a call path from the entry point to the root cause.

[0077] The fluctuation start point refers to the time when the service response time first deviates significantly from its baseline value, which can be defined as the moment when the response time first exceeds 1.5 times the baseline. For example, the inventory service first breaks the baseline at 14:28:08, which is its fluctuation start point.

[0078] The fluctuation lead time is the time difference between the start time of the root cause service's fluctuation and the start time of the front-end entry service's fluctuation. For example, if the inventory service fluctuates at 14:28:08 and the API gateway fluctuates at 14:28:12, the lead time is 4 seconds, which is key evidence supporting the causal relationship.

[0079] Structured root cause reports are machine-readable diagnostic outputs, typically organized in JSON or Protocol Buffer format. They include fields such as root cause service name, call path, lead time, and score, facilitating automatic parsing by alarm systems or display by operations and maintenance platforms.

[0080] In an optional implementation of this embodiment, after obtaining the comprehensive root cause score of each candidate service, the candidate services can be sorted in descending order according to the comprehensive root cause score, and the candidate service ranked first in the sorting result is determined as the root cause service. Further, based on the service call topology, the system traverses backward from the root cause service to the front-end entry service to determine the shortest call path between the two, and represents this path as a service sequence arranged in the call order. On this basis, the fluctuation start time of the root cause service and the fluctuation start time of the front-end entry service are obtained, and the difference between the two is calculated as the fluctuation advance time. Then, the root cause service name, call path, fluctuation advance time, and comprehensive root cause score are organized according to a preset data format to generate a structured root cause report. Finally, the structured root cause report is output to an external system for alarm notification or fault review.

[0081] The solution in this embodiment ranks candidate services and identifies the root cause service based on a comprehensive root cause score, ensuring that the root cause determination results have clear quantitative basis. Furthermore, by combining service call topology with call path backtracking, it provides a complete request propagation chain from the root cause to the entry point, enhancing the interpretability of the diagnostic conclusions. Simultaneously, it extracts the fluctuation advance duration as key evidence of temporal causality and incorporates it, along with the root cause service name, call path, and score, into a structured report. This not only outputs the final conclusion but also provides verifiable multi-dimensional supporting information. The generated structured root cause report adopts a standardized format, facilitating automatic parsing, alarm linkage, or manual review by downstream systems, significantly improving the usability, reliability, and automated integration capabilities of the fault location results.

[0082] To better understand the performance root cause localization method for microservice systems involved in this embodiment, a specific example is used to describe it below: Fault scenario: Your e-commerce APP suddenly slows down at 14:30, and users complain that "it takes 10 seconds to place an order"; Traditional screening process: 14:30 - Customer service received a user complaint. 14:35 - The operations and maintenance team received an alarm: "Gateway response time > 500ms". 14:40 - Team Meeting: Each member reviews their own monitoring data. 14:50 - Gateway Group: "We are operating normally; it might be an order service issue." 15:00 - Orders Group: "We're operating normally; it might be inventory service." 15:10 - Inventory Group: "We're fine, it might be the database." 15:20 - DBA: "Database is normal..." 3:30 PM - Still arguing... 16:00 - Finally discovered: There was lock contention in the inventory service database. 16:30 - Bug fixes Total: 2 hours of losses, significant user churn. The crux of the problem is that each service is monitored, but there is no correlation analysis, so it's unclear who is affecting whom.

[0083] The following are the implementation steps of an embodiment of the present invention: Step 1: Raw Data Collection Time points: 14:29 ~ 14:34, recorded once per minute. Table 1. Original Data Table It can be seen that gateway, orders, and inventory all surged simultaneously at 14:32, while payment services remained largely unchanged; the trends of the three are very similar.

[0084] Step 2: Data Preprocessing Objective: To enable fair comparison of data of different magnitudes. Problem: The gateway baseline was 50ms, which increased to 230ms (+360%); the inventory baseline was 20ms, which increased to 195ms (+875%). The absolute values ​​are different, but the percentage changes are significant.

[0085] Processing method: Calculate the rate of change relative to the baseline. # 1. Calculate the baseline for each service (take the average of the first 3 minutes). Baseline = { "Gateway": (52+51+53) / 3 = 52.0, "Orders": (32+31+34) / 3 = 32.3, "Inventory": (22+21+23) / 3 = 22.0, "Payment": (41+42+43) / 3 = 42.0 } # 2. Calculate the rate of change at each time point. Rate of change = (current value - baseline) / baseline; the processed data is shown in Table 2 below: Table 2 Step 3: Calculate similarity Using the Pearson correlation coefficient formula: Formula: r = Σ[(x i - x̄)(y i - ȳ)] / √[Σ(x i - x̄) 2 * Σ(y i - ȳ) 2 ] Calculating Gateway vs. Order Similarity: Data Preparation (Rate of Change at 6 Time Points): Gateway change rate (X): [0.00, -0.02, 0.02, 3.04, 3.42, 0.63]; Order change rate (Y): [-0.01, -0.04, 0.05, 3.95, 4.42, 0.70]; Step 1: Calculate the average value x̄ = (0.00 + -0.02 + 0.02 + 3.04 + 3.42 + 0.63) / 6 = 7.09 / 6 = 1.1817; ȳ = (-0.01 + -0.04 + 0.05 + 3.95 + 4.42 + 0.70) / 6 = 9.07 / 6 =1.5117; Step 2: Calculate the deviation at each point Time point | X deviation (x) i -x̄) | Y deviation (y i -ȳ); 14:29 | 0.00-1.1817 = -1.1817 | -0.01-1.5117 = -1.5217; 14:30 | -0.02-1.1817 = -1.2017 | -0.04-1.5117 = -1.5517; 14:31 | 0.02 - 1.1817 = -1.1617 | 0.05 - 1.5117 = -1.4617; 14:32 | 3.04 - 1.1817 = 1.8583 | 3.95 - 1.5117 = 2.4383; 14:33 | 3.42 - 1.1817 = 2.2383 | 4.42 - 1.5117 = 2.9083; 14:34 | 0.63-1.1817 = -0.5517 | 0.70-1.5117 = -0.8117; Step 3: Calculate the deviation product; Time point | X deviation × Y deviation; 14:29 | (-1.1817)×(-1.5217) = 1.798; 14:30 | (-1.2017)×(-1.5517) = 1.864; 14:31 | (-1.1617)×(-1.4617) = 1.698; 14:32 | 1.8583 × 2.4383 = 4.531; 14:33 | 2.2383 × 2.9083 = 6.509; 14:34 | (-0.5517)×(-0.8117) = 0.448; The sum of the products = 1.798 + 1.864 + 1.698 + 4.531 + 6.509 + 0.448 = 16.848; Step 4: Calculate the sum of squares Sum of squared deviations X = (-1.1817) 2 +(-1.2017) 2 +(-1.1617) 2 +(1.8583) 2 +(2.2383) 2 +(-0.5517) 2 =1.396+1.444+1.349+3.453+5.010+0.304 = 12.956; Sum of squared deviations of Y = (-1.5217) 2 +(-1.5517) 2 +(-1.4617) 2 +(2.4383) 2 +(2.9083) 2 +(-0.8117) 2 = 2.316 + 2.408 + 2.136 + 5.945 + 8.458 + 0.659 = 21.922; Step 5: Calculate the correlation coefficient r = 16.848 / √(12.956 × 21.922) = 16.848 / √(284.0) = 16.848 / 16.852 = 0.9998 (approximately equal to 1).

[0086] Interpretation of results: r = 0.9998 ≈ 1.0 → Perfect positive correlation; This means that when the gateway slows down, orders will almost certainly slow down as well, and the change will be proportional. Calculate other combinations using the same method: Gateway vs. Inventory: r = 0.995; Gateway vs. Payment: r = 0.12 # Very low, almost irrelevant; Orders vs. Inventory: r = 0.998; Orders vs. Payments: r = 0.10; Similarity matrix: Gateway order inventory payment Gateway 1.00 0.9998 0.995 0.12 Orders: 0.9998, 1.00, 0.998, 0.10 Inventory: 0.995, 0.998, 1.00, 0.15 Payment: 0.12 0.10 0.15 1.00 Step 4: Combine with topology analysis Known call relationships (obtained from code or traffic analysis): Gateway service → Order service (100% of gateway requests will access the order service). Order Service → Inventory Service (100% of order requests will access the inventory). Gateway service → Payment service (20% of gateway requests will invoke payment). Calculate the propagation impact coefficient: # How would a 1ms slowdown in inventory management affect upstream processes? Inventory → Orders: 100% impact (because all order requests access the inventory); Orders → Gateway: 100% affected (because all gateway requests call the order function); # Propagation path: Inventory → Orders → Gateway; Therefore: a 1ms delay in inventory → a 1ms increase in order processing → a 1ms increase in gateway processing time; A comprehensive score combining similarity and topology: def calculates root cause scores (service): # Formula: Similarity × 0.6 + Topological centrality × 0.4; Similarity = Correlation coefficient with the gateway (service); Topological centrality = Computing topological influence (services); Score = Similarity × 0.6 + Topological centrality × 0.4; Return score.

[0087] # Calculation results: Inventory services: Similarity = 0.995; Topological centrality = 1.0 (because it is on the critical path and affects all requests); Score = 0.995 × 0.6 + 1.0 × 0.4 = 0.997; Order service: Similarity = 0.9998; Topological centrality = 1.0; Score = 0.9998 × 0.6 + 1.0 × 0.4 = 0.9999; Payment services: Similarity = 0.12; Topological centrality = 0.2 (affects only 20% of requests); Score = 0.12 × 0.6 + 0.2 × 0.4 = 0.152.

[0088] The question is: with both order and inventory scores high, what is the real root cause? Step 5: Chronological Analysis (Causal Inference) Check which service slows down first: Raw response time (ms): Time Gateway Order Inventory 14:31 53 34 23 ← All normal 14:32 210 160 180 ← All slowed down # Calculate the latency increment (how much it increases compared to the previous minute): Gateway increment: 210 - 53 = 157ms; Order increment: 160 - 34 = 126ms; Inventory increment: 180 - 23 = 157ms; # Note: Inventory and gateway data increased by 157ms, while orders only increased by 126ms; # This could mean that: inventory slows down first, affecting orders, and then orders affect the gateway; # However, order processing itself is also time-consuming, so gateway = orders + additional processing; More precise analysis: Examine the "delayed following" phenomenon; Assume the call chain and the delay relationship: Gateway latency = Order latency + Gateway processing time; Order delay = Inventory delay + Order processing time; At 14:32: If inventory delay increases: 157ms; Therefore, the order delay should increase by: 157ms + the change in the order itself; Actual order increase: 126ms (less than 157ms!); This means that the order processing itself may have been faster (-31ms), which offset some of the inventory delay; therefore, the slower inventory processing is the main reason, and there is no problem with the order itself.

[0089] Step 6: Root Cause Localization Analysis conclusion: Root Cause Analysis Report Root cause: Inventory service (95% confidence level); Chain of evidence: 1. High similarity in time series: - Gateway vs. Inventory: 0.995 (strong correlation); - Of all services, the curve shape of inventory best matches that of gateway; 2. Key Topological Location: - Located at the end of the call chain: Gateway → Order → Inventory; - Slower inventory turnover will 100% impact all upstream services; 3. Highest degree of self-abnormality: - Inventory change rate: from +5% to +718% (a 143-fold increase); - Order change rate: from +5% to +395% (a 79-fold increase); - Gateway change rate: from +2% to +304% (a 152-fold increase); - Inventory saw the largest relative change; 4. Chronological order: - In theory: If inventory slows down first, then orders, and finally the gateway slows down. - The actual data conforms to this pattern 5. Exclude other services: - Payment service: Similarity is only 0.12, and it is not on the main call chain. - Order services: Although the similarity is high, the anomaly rate is relatively low. Delving into the inner workings of the inventory service (via eBPF data): Breakdown of time spent on a single inventory service request (at 14:32): Total time: 180ms ├── Business logic execution: 15ms (normal) ├── Waiting for CPU scheduling: 5ms (normal) ├── Network I / O: 0ms (No network call) Database query: 160ms └── Where: Lock wait time: 155ms └── Actual execution time: 5ms Conclusion: Database lock contention slows down inventory management. Inventory service confidence calculation: 1. Raw scores for each dimension: Similarity: 0.995; Topology: 1.0; Anomaly score: 1.0; Timing: 0.916; 2. Weighting (based on business importance): Similarity: 30%; Topology: 25%; Anomaly level: 25%; Timing: 20%; 3. Weighted calculation: Weighted score = 0.995 × 0.3 + 1.0 × 0.25 + 1.0 × 0.25 + 0.916 × 0.2 = 0.2985 + 0.25 + 0.25 + 0.1832 = 0.9817; 4. Model calibration: Historical accuracy of the model: 0.96; The score after calibration = 0.9817 × 0.96 = 0.9424; 5. Final confidence level: Confidence level = 0.9424 × 100% = 94.24%; Report shows: 95% (rounded).

[0090] This invention, through the introduction of a multi-dimensional cross-validation mechanism, effectively overcomes the high false alarm problem caused by traditional APM systems relying on a single indicator (such as CPU utilization). Specifically, it comprehensively considers four dimensions—fluctuation similarity, topological influence weight, anomaly degree, and temporal causality—for collaborative judgment. A high-confidence root cause is only output when multiple evidence chains consistently point to the same service, significantly improving the reliability of the judgment results. Simultaneously, the scores and weight contributions of each dimension can be traced and displayed item by item, ensuring complete interpretability of the root cause conclusions and avoiding black-box decision-making. Furthermore, the system supports dynamically adjusting the weights of each dimension according to different fault modes (such as sudden faults or gradual performance degradation). For example, in sudden scenarios, the anomaly weight is increased to capture instantaneous degradation, while in gradual scenarios, the similarity weight is enhanced to identify slow drift, thereby achieving adaptive and accurate localization for diverse anomaly scenarios.

[0091] Example 3 Figure 3 This is a schematic diagram of a performance root cause localization device for microservice systems provided according to Embodiment 3 of the present invention. Figure 3 As shown, the device includes: a first determining module 310, a second determining module 320, a third determining module 330, and a root cause report generation module 340.

[0092] The first determining module 310 is used to respond to an abnormal instruction of the service performance index of the front-end entry service, determine a set of candidate services that are in the same business call chain as the front-end entry service based on the service call topology, and obtain the response time sequence of each candidate service in the candidate service set within a preset time window. The second determining module 320 is used to determine the baseline value based on the historical response time series of each candidate service before the anomaly occurs, and convert the original response time into a normalized relative rate of change to determine a subset of services that have fluctuation similarity with the front-end entry service; The third determining module 330 is used to determine the influence weight of each candidate service in the request propagation path based on the service call topology, and to perform temporal causal analysis on the service subset to determine the temporal causal score. The root cause report generation module 340 is used to determine a comprehensive root cause score based on the fluctuation similarity, the influence weight and the time-series causality score, determine the root cause service with the highest confidence based on the comprehensive root cause score, and output a structured root cause report containing the name of the root cause service.

[0093] In one optional implementation of this embodiment, an anomaly in the service performance metrics of the front-end entry service includes at least one of the following: The response time of the front-end entry service exceeds the dynamic baseline threshold. The error rate of the front-end entry service exceeds a preset error rate threshold. The request rate of the front-end entry service is lower than a preset lower threshold.

[0094] In an optional implementation of this embodiment, the first determining module 310 is specifically used to obtain the service call topology and, based on the service call topology, determine all downstream services originating from the front-end entry service as a candidate service set; wherein, the service call chain data is a call chain triggered by business requests related to the current abnormal event, starting from the front-end entry service; The response time data of each candidate service within a preset time window ending at the time of the anomaly are obtained from the monitoring index storage system and constructed into a response time sequence.

[0095] In an optional implementation of this embodiment, the second determining module 320 is specifically used to determine the baseline value of each candidate service based on the response time sequence of each candidate service within a preset historical period ending at the time of the anomaly. Based on the baseline value and the original response time of each candidate service within a preset time window, a normalized relative rate of change sequence is determined. Based on the normalized relative rate of change sequence of each candidate service and the normalized relative rate of change sequence of the front-end entry service, the fluctuation similarity between the two is determined; Candidate services whose fluctuation similarity meets the preset conditions are determined as the service subset.

[0096] In an optional implementation of this embodiment, the third determining module 330 is specifically used to determine the influence weight of each candidate service based on the call distance or call frequency from each candidate service to the front-end entry service in the service call topology. The normalized relative rate of change sequences of each candidate service in the service subset and the normalized relative rate of change sequence of the front-end entry service are resampled to a unified time granularity to obtain an aligned time series. Based on the aligned time series, the time offset between the fluctuation start time of each candidate service and the fluctuation start time of the front-end entry service is determined, and the time-series causal score is determined according to the time offset.

[0097] In an optional implementation of this embodiment, the root cause report generation module 340 is specifically used to perform weighted fusion of the fluctuation similarity, the influence weight and the temporal causality score to obtain an initial root cause score; The confidence calibration model trained based on historical root cause annotation data is used to perform a nonlinear mapping on the initial root cause score to obtain the calibrated root cause score. A penalty factor is applied to the root cause score of candidate services whose response time does not exceed their own baseline value during abnormal periods to obtain a comprehensive root cause score.

[0098] In an optional implementation of this embodiment, the root cause report generation module 340 is further configured to sort the candidate services according to the comprehensive root cause score, and determine the candidate service ranked first as the root cause service; Based on the service call topology, determine the call path from the root cause service to the front-end entry service; Extract the start time of fluctuations in the root cause service and its lead time relative to the fluctuations of the front-end entry service; The root cause service name, the call path, the fluctuation advance time, and the comprehensive root cause score are combined to form a structured root cause report.

[0099] The performance root cause localization device for microservice systems provided in this embodiment of the invention can execute the performance root cause localization method for microservice systems provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0100] In the technical solutions of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of performance index data of the microservice system involved all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0101] Example 4 Figure 4 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0102] like Figure 4As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from the storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0103] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0104] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods described above, such as performance root cause localization methods for microservice systems.

[0105] In some embodiments, the performance root cause analysis method for microservice systems can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the performance root cause analysis method for microservice systems described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute the performance root cause analysis method for microservice systems by any other suitable means (e.g., by means of firmware).

[0106] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0107] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0108] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM), optical fibers, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0109] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0110] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0111] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system. It addresses the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) in terms of management difficulty and weak business scalability.

[0112] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0113] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

[0114] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements a database detection method as provided in any embodiment of this application.

[0115] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LANs or WANs—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0116] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the solution has been or necessarily used.

[0117] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for locating the root cause of performance issues in microservice systems, characterized in that, The method includes: In response to an abnormal command in the service performance index of the front-end entry service, a set of candidate services in the same business call chain as the front-end entry service is determined based on the service call topology, and the response time sequence of each candidate service in the set of candidate services is obtained within a preset time window. Based on the historical response time series of each candidate service before the anomaly occurred, a baseline value was determined, and the original response time was converted into a normalized relative rate of change to determine a subset of services that have fluctuation similarity with the front-end entry service. Based on the service call topology, the influence weight of each candidate service in the request propagation path is determined, and the service subset is subjected to temporal causal analysis to determine the temporal causal score. A comprehensive root cause score is determined based on the fluctuation similarity, the influence weight, and the temporal causality score. The root cause service with the highest confidence is determined based on the comprehensive root cause score, and a structured root cause report containing the name of the root cause service is output.

2. The performance root cause localization method for microservice systems according to claim 1, characterized in that, Anomalies in the service performance metrics of the front-end entry service include at least one of the following: The response time of the front-end entry service exceeds the dynamic baseline threshold. The error rate of the front-end entry service exceeds a preset error rate threshold. The request rate of the front-end entry service is lower than a preset lower threshold.

3. The performance root cause localization method for microservice systems according to claim 2, characterized in that, The step of determining a set of candidate services that are in the same business call chain as the front-end entry service based on the service call topology, and obtaining the response time sequence of each candidate service in the set within a preset time window, includes: Obtain the service call topology, and based on the service call topology, determine all downstream services originating from the front-end entry service as a candidate service set; wherein, the service call chain data is the call chain triggered by business requests related to the current abnormal event, starting from the front-end entry service; The response time data of each candidate service within a preset time window ending at the time of the anomaly are obtained from the monitoring index storage system and constructed into a response time sequence.

4. The performance root cause localization method for microservice systems according to claim 1, characterized in that, The process involves determining a baseline value based on the historical response time series of each candidate service before the anomaly occurs, converting the original response time into a normalized relative rate of change, and identifying a subset of services with fluctuation similarity to the front-end entry service, including: Based on the response time series of each candidate service within a preset historical period ending at the time of the anomaly, the baseline value of each candidate service is determined. Based on the baseline value and the original response time of each candidate service within a preset time window, a normalized relative rate of change sequence is determined. Based on the normalized relative rate of change sequence of each candidate service and the normalized relative rate of change sequence of the front-end entry service, the fluctuation similarity between the two is determined; Candidate services whose fluctuation similarity meets the preset conditions are determined as the service subset.

5. The performance root cause localization method for microservice systems according to claim 1, characterized in that, The process of determining the influence weight of each candidate service in the request propagation path based on the service call topology, and performing temporal causal analysis on the service subset to determine the temporal causal score, includes: The influence weight of each candidate service is determined based on the call distance or call frequency from each candidate service to the front-end entry service in the service call topology. The normalized relative rate of change sequences of each candidate service in the service subset and the normalized relative rate of change sequence of the front-end entry service are resampled to a unified time granularity to obtain an aligned time series. Based on the aligned time series, the time offset between the fluctuation start time of each candidate service and the fluctuation start time of the front-end entry service is determined, and the time-series causal score is determined according to the time offset.

6. The performance root cause localization method for microservice systems according to claim 1, characterized in that, The determination of the comprehensive root cause score based on the fluctuation similarity, the influence weight, and the temporal causality score includes: The initial root cause score is obtained by weighted fusion of the fluctuation similarity, the influence weight, and the temporal causality score. The confidence calibration model trained based on historical root cause annotation data is used to perform a nonlinear mapping on the initial root cause score to obtain the calibrated root cause score. A penalty factor is applied to the root cause score of candidate services whose response time does not exceed their own baseline value during abnormal periods to obtain a comprehensive root cause score.

7. The performance root cause localization method for microservice systems according to claim 1, characterized in that, The step of determining the root cause service with the highest confidence level based on the comprehensive root cause score and outputting a structured root cause report containing the name of the root cause service includes: The candidate services are ranked according to the comprehensive root cause score, and the candidate service ranked first is determined as the root cause service. Based on the service call topology, determine the call path from the root cause service to the front-end entry service; Extract the start time of fluctuations in the root cause service and its lead time relative to the fluctuations of the front-end entry service; The root cause service name, the call path, the fluctuation advance time, and the comprehensive root cause score are combined to form a structured root cause report.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the performance root cause localization method for microservice systems as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the performance root cause localization method for a microservices system as described in any one of claims 1-7.

10. A computer program product comprising a computer program that, when executed by a processor, implements the performance root cause localization method for a microservices system according to any one of claims 1-7.

Images