Fault positioning method and system for multi-source micro-service, electronic equipment and storage medium

Abstract

The invention provides a fault positioning method and system for a multi-source micro-service, electronic equipment and a storage medium, and the method comprises the steps: extracting calling track data in service abnormality log data of the micro-service in an abnormal time period when an abnormality of a micro-service system is detected, and calculating a calling track score of the micro-service according to the calling track data of the micro-service; calculating an index abnormal score according to the index data of the micro-service; calculating a log exception score according to the service exception log data and the service normal log data of the micro-service; constructing a directed graph according to the calling track data of each micro-service; calculating the weight of each edge according to the service exception log data of each micro-service and the directed graph; performing iterative calculation according to the weight of each edge of the directed graph and the calling track score, the index abnormal score and the log abnormal score of each micro-service through random walk to obtain an abnormal score of each micro-service; and determining the micro-service with the maximum abnormal score as the fault root cause of the abnormity of the micro-service system.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a fault location method, system, electronic device, and storage medium for multi-source microservices. Background Technology

[0002] In recent years, with the continuous expansion of banking-related software applications, more and more banking systems are choosing to migrate from traditional monolithic systems to microservice architectures. Microservice systems typically contain hundreds or thousands of sub-services, each of which can have several to thousands of replica instances running on different containers and servers. As the number of services increases, ensuring the stability and reliability of these services is a pressing issue that needs to be addressed.

[0003] In existing technologies, a modular design approach can be used to break down large applications into hundreds or even thousands of small, independent, and easily managed microservices. These microservices collaborate through lightweight communication mechanisms, building a highly cohesive and loosely coupled system architecture that better adapts to complex and highly dynamic environments. Meanwhile, the widespread adoption of containerization technology has also provided strong support for efficient collaboration between development and operations teams. Developers can package applications and their dependencies into a portable image and easily deploy it in any environment, ensuring consistent application performance across different environments and reducing problems caused by environmental differences. Furthermore, containerization technology simplifies application deployment and upgrade processes, enabling development teams to deploy new features and fixes to production environments more quickly, thereby significantly improving software delivery efficiency.

[0004] However, while microservice architecture and containerization reduce the coupling between services, failures in distributed systems remain difficult to avoid. As services scale, dependencies become increasingly complex, and performance fluctuations can propagate along the call chain. Anomalies in a few root cause nodes can affect related nodes, ultimately leading to business availability issues, or even cascading service failures, causing system paralysis and significant economic losses. Traditional fault location methods rely heavily on the experience of operations personnel, but with the rapid growth in service scale, type, and complexity, the number of monitoring metrics in microservice systems has surged. Using all metrics to diagnose service failures would incur high resource consumption and economic costs, and manual fault location is unreliable. Summary of the Invention

[0005] In view of this, the present invention provides a fault location method, system, electronic device and storage medium for multi-source microservices, with the aim of improving the reliability of fault location, reducing resource consumption and lowering costs.

[0006] The first aspect of this application provides a fault location method for multi-source microservices, the method comprising:

[0007] When an anomaly is detected in the microservice system, service anomaly log data for each microservice is obtained within the anomaly time period, wherein the anomaly time period is the time period during which the microservice system experienced the anomaly.

[0008] Extract the call trajectory data of each microservice from the service exception log data of each microservice, and calculate the call trajectory score of each microservice based on the call trajectory data of each microservice.

[0009] Obtain the metric data of each microservice during the normal time period, and calculate the metric anomaly score of each microservice based on the metric data of each microservice.

[0010] Obtain the normal service log data of each microservice within the normal time period, and calculate the log anomaly score of each microservice based on the service anomaly log data and the normal service log data.

[0011] A corresponding directed graph is constructed based on the call trajectory data of each microservice. The directed graph consists of multiple nodes and multiple edges. The nodes are microservices, and the edges are connections between two microservices that have a call relationship.

[0012] The weight of each edge is calculated based on the service exception log data of each microservice and the directed graph.

[0013] The anomaly score of each microservice is obtained by iteratively calculating the weight of each edge in the directed graph and the call trajectory score, indicator anomaly score, and log anomaly score of each microservice through random walk.

[0014] The microservice with the highest anomaly score among all the microservices is identified as the root cause of the anomaly in the current microservice system.

[0015] Optionally, calculating the call trajectory score for each microservice based on the call trajectory data of each microservice includes:

[0016] For each microservice, the number of abnormal call traces and the number of normal call traces corresponding to the microservice are counted from the call trace data of the microservice;

[0017] The total number of abnormal call traces for each of the other microservices is calculated from the call trace data of each other microservice; wherein, the other microservices are microservices other than the microservice mentioned above.

[0018] The call trajectory score of the microservice is calculated based on the number of abnormal call trajectories, the number of normal call trajectories, and the total number of abnormal call trajectories.

[0019] Optionally, the step of obtaining the metric data of each microservice within a normal time period and calculating the metric anomaly score of each microservice based on the metric data of each microservice includes:

[0020] For each microservice, obtain the indicator data of the microservice within a normal time period, wherein the indicator data includes the indicator data of the microservice at each time point, and the indicator data at each time point includes the indicator value of each microservice indicator at that time point, and the time point is a time point within the normal time period;

[0021] For each time point, the average value of the indicators of the microservice at that time point is calculated based on the indicator values ​​of each microservice indicator at that time point.

[0022] The severity of each microservice metric at the time point is calculated based on the average metric value of the microservice at the time point and the metric value of each microservice metric at the time point.

[0023] For each microservice metric, an anomaly score for the microservice metric is calculated based on the severity of the microservice metric at each of the said time points;

[0024] The abnormal scores of the microservice metrics are filtered out from the abnormal scores of each microservice metric.

[0025] Optionally, calculating the log anomaly score of each microservice based on its service anomaly log data and service normal log data includes:

[0026] For each microservice, the first actual occurrence count of each error type in the microservice during the abnormal time period is calculated from the service exception log data of the microservice, and the second actual occurrence count of each error in the microservice during the normal time period is calculated from the service normal log data of the microservice.

[0027] Calculate the error type distribution difference of the microservice based on the first actual occurrence count and the second actual occurrence count;

[0028] The frequency of a first runtime error occurring in the microservice during the abnormal time period is calculated from the service exception log data of the microservice, and the frequency of a second runtime error occurring in the microservice during the normal time period is calculated from the service normal log data of the microservice.

[0029] Calculate the difference in runtime error frequency of the microservice based on the first runtime error frequency and the second runtime error frequency;

[0030] The log anomaly score of the microservice is calculated based on the differences in error type distribution and error frequency of the microservice.

[0031] Optionally, calculating the weight of each edge based on the service exception log data of each microservice and the directed graph includes:

[0032] For each edge in the directed graph, a first microservice and a second microservice on the edge are determined; wherein, the first microservice is the microservice that is requested to be called among the two microservices on the edge, and the second microservice is the microservice that is called among the two microservices on the edge.

[0033] The total number of first anomalies occurring in the first microservice is counted from the service anomaly log data of the first microservice, and the total number of second anomalies occurring simultaneously in the first microservice and the second microservice is counted from the service anomaly log data of the first microservice and the second microservice.

[0034] The weight of the edge is calculated based on the first total number of anomalies and the second total number of anomalies.

[0035] Optionally, the step of obtaining the anomaly score of each microservice by iteratively calculating the weights of each edge in the directed graph and the call trajectory score, metric anomaly score, and log anomaly score of each microservice through random walk includes:

[0036] Calculate the node anomaly score for each microservice based on its call trajectory score, metric anomaly score, and log anomaly score.

[0037] For each microservice, based on the call trajectory data of the microservice, the upstream service set and downstream service set of the microservice are statistically analyzed;

[0038] The dwell probability of the microservice is calculated based on the weight of each edge, the node anomaly score of the microservice, the upstream service set, and the downstream service set.

[0039] For each edge, a state transition value is calculated based on the edge's weight and the weights of all other edges, and a state transition matrix is ​​constructed based on the state transition values ​​of all edges. The other edges are edges formed by the first microservice of the edge and other second microservices with which it has a calling relationship. The other second microservices are either the first microservice of the edge, or the second microservice of the edge, or microservices other than the first and second microservices that have a calling relationship with the first microservice. If the other microservice is the first microservice, the weight of the other edge is the dwell probability of the first microservice.

[0040] Based on the node anomaly score of each microservice, calculate the bias vector for each microservice;

[0041] An anomaly score is calculated for each microservice based on the bias vector and the state transition matrix.

[0042] A second aspect of this application provides a fault location system for multi-source microservices, the system comprising:

[0043] The first module unit is used to obtain service exception log data of each microservice during the exception time period when an exception is detected in the microservice system. The exception time period is the time period during which the microservice system experienced an exception.

[0044] The first calculation unit is used to extract the call trajectory data of each microservice from the service exception log data of each microservice, and calculate the call trajectory score of each microservice based on the call trajectory data of each microservice.

[0045] The second calculation unit is used to obtain the indicator data of each microservice during the normal time period, and calculate the indicator anomaly score of each microservice based on the indicator data of each microservice.

[0046] The third calculation unit is used to obtain the normal service log data of each microservice within the normal time period, and to calculate the log anomaly score of each microservice based on the service anomaly log data and the normal service log data.

[0047] A directed graph generation unit is used to construct a corresponding directed graph based on the call trajectory data of each microservice. The directed graph consists of multiple nodes and multiple edges, where each node is a microservice and each edge is a connection between two microservices that have a call relationship.

[0048] The fourth calculation unit is used to calculate the weight of each edge based on the service exception log data of each microservice and the directed graph.

[0049] The fifth calculation unit is used to perform iterative calculations by random walk based on the weights of each edge in the directed graph and the call trajectory score, indicator anomaly score, and log anomaly score of each microservice to obtain the anomaly score of each microservice.

[0050] The determining unit is used to determine the microservice with the highest anomaly score among the various microservices as the root cause of the anomaly that occurred in the microservice system this time.

[0051] Optionally, the first computing unit is specifically used for:

[0052] For each microservice, the number of abnormal call traces and the number of normal call traces corresponding to the microservice are counted from the call trace data of the microservice;

[0053] The total number of abnormal call traces for each of the other microservices is calculated from the call trace data of each other microservice; wherein, the other microservices are microservices other than the microservice mentioned above.

[0054] The call trajectory score of the microservice is calculated based on the number of abnormal call trajectories, the number of normal call trajectories, and the total number of abnormal call trajectories.

[0055] A third aspect of this application provides an electronic device, including: a processor and a memory, the processor and the memory being connected via a bus; wherein, the processor is used to call and execute a program stored in the memory; the memory is used to store the program, the program being used to implement the fault location method for multi-source microservices as provided in the first aspect of this application.

[0056] A fourth aspect of this application provides a computer-readable storage medium storing computer-executable instructions for performing a fault location method for multi-source microservices as provided in the first aspect of this application.

[0057] This application provides a fault location method, system, electronic device, and storage medium for multi-source microservices. When an anomaly is detected in the microservice system, the method involves: acquiring service anomaly log data for each microservice during the anomaly period (the time period in which the anomaly occurred); extracting call trajectory data for each microservice from the service anomaly log data and calculating a call trajectory score for each microservice based on the call trajectory data; acquiring indicator data for each microservice during the normal period and calculating an anomaly score for each microservice based on the indicator data; and acquiring service normal log data for each microservice during the normal period and calculating an anomaly score for each microservice based on the normal log data. The service anomaly log data and service normal log data are used to calculate the log anomaly score of each microservice. A directed graph is constructed based on the call trajectory data of each microservice. The directed graph consists of multiple nodes and edges, where nodes are microservices and edges connect two microservices with a call relationship. The weight of each edge is calculated based on the service anomaly log data and the directed graph. Anomaly scores for each microservice are obtained by iteratively calculating the weights of each edge in the directed graph with the call trajectory score, indicator anomaly score, and log anomaly score of each microservice using a random walk. The microservice with the highest anomaly score is identified as the root cause of the anomaly in the microservice system. The technical solution provided in this application calculates the call trajectory score, indicator anomaly score, and log anomaly score for each microservice. It also constructs a service dependency graph (directed graph) of the microservice system based on the call trajectory data of each microservice and calculates the weight of each edge in the directed graph. This allows for the calculation of the anomaly score for each microservice based on the weight of each edge, the call trajectory score, indicator anomaly score, and log anomaly score. Finally, based on the anomaly scores of each microservice, the root cause of the microservice system failure can be determined. This eliminates the need for manual fault location, resulting in high reliability of fault location and reduced resource consumption and economic costs. Attached Figure Description

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

[0059] Figure 1 A flowchart illustrating a fault location method for multi-source microservices provided in this application embodiment;

[0060] Figure 2 This is a schematic diagram of the structure of a fault location system for multi-source microservices provided in an embodiment of the present invention;

[0061] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0062] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0063] In this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0064] To better understand the technical terms used in this application, the following explanations are provided: Spectrum-Based Fault Localization (SBFL) Algorithm: The SBFL algorithm is a fault localization technique based on test case coverage information. Its core idea is to analyze the correlation between code elements and faults by statistically analyzing the execution paths and results of test cases, thereby locating potential fault locations. Specifically, the SBFL algorithm records the execution result (pass or fail) of each test case and statistically analyzes the coverage of each code element in passed and failed test cases, including the number of times the element appears in failed test cases, the number of times it appears in successful test cases, and cases where it is not covered. Using this statistical information, the algorithm calculates an anomaly score for each code element; a higher score indicates a greater likelihood that the element will cause a fault. Finally, the SBFL algorithm sorts the scores to help developers quickly locate possible root causes of faults. This method effectively narrows down the scope of fault investigation and improves debugging efficiency.

[0065] PageRank is an algorithm for evaluating the importance of web pages, proposed by the founders of Google. Its core idea is to determine a page's ranking by analyzing the link relationships between pages. Specifically, if a page is linked to by many other pages, especially high-quality pages, then that page will rank higher. PageRank constructs a directed graph based on page links, uses probability transition matrices and iterative calculations to obtain a ranking score for each page. The higher the ranking score, the higher the page appears in search results. This method makes search results more accurate and relevant.

[0066] As the background information above indicates, manual fault location is unreliable. Specifically, experienced operations and maintenance personnel or domain experts manually define normal ranges and alarm thresholds for various indicators based on historical experience, business characteristics, and system operating status. For example, CPU utilization exceeding 80% may trigger an alarm, and memory usage exceeding 90% may be considered abnormal. Manual judgment is then made based on these set indicators to locate the corresponding fault location; however, this fault location method has low reliability.

[0067] In existing technologies, fault location can also be achieved based on static dependencies or historical call data. Specifically, by analyzing historical data and using statistical or machine learning models, the normal range and alarm thresholds of various indicators can be automatically calculated. The core of this method lies in using patterns and regularities in historical data to identify the normal fluctuation range of indicators and setting alarm thresholds accordingly. For example, through time series analysis, seasonal fluctuations, periodic changes, and outliers of indicators can be identified, thereby dynamically adjusting the thresholds. The advantage of this method is its high degree of automation, its ability to quickly adapt to system changes, and its reduced burden of manual intervention, thereby improving the accuracy of alarms.

[0068] However, this approach fails to fully consider the differences in access frequency and service response time among different services, ignores the dynamic nature of fault propagation, and struggles to accurately capture real-time fault propagation paths. Therefore, when cascading failures occur in the system, with multiple services exhibiting anomalies simultaneously, traditional methods based on metrics or call relationships often struggle to quickly and accurately pinpoint the root cause of the service failure.

[0069] Therefore, this application provides a method, system, electronic device, and storage medium for fault localization of multi-source microservices. It calculates the call trajectory score, indicator anomaly score, and log anomaly score for each microservice, and constructs a service dependency graph (directed graph) of the microservice system based on the call trajectory data of each microservice. It also calculates the weight of each edge in the directed graph to calculate the anomaly score of each microservice based on the edge weights, the call trajectory score, indicator anomaly score, and log anomaly score. Finally, based on the anomaly scores of each microservice, the root cause of the microservice system failure is determined. Thus, when multiple microservices in a microservice system experience simultaneous anomalies, the root cause of the service failure can be quickly and accurately located.

[0070] See Figure 1 The diagram illustrates a flowchart of a fault location method for multi-source microservices provided in an embodiment of this application. The method specifically includes the following steps:

[0071] S101: When an anomaly is detected in the microservice system, obtain the service anomaly log data for each microservice during the anomaly period, where the anomaly period is the time during which the microservice system experienced the anomaly.

[0072] During the specific execution of step S101, the running status of the microservice system can be monitored in real time, and it can be determined whether the microservice system has encountered an anomaly based on the running status. When it is determined that the microservice system has encountered an anomaly, the time period during which the anomaly occurred can be determined (for ease of distinction, the time period during which the microservice system encountered an anomaly is called the anomaly time period). The microservice system is deployed with a corresponding cluster, which includes multiple microservices. For each microservice, the log data of that service during the anomaly time period can be obtained (for ease of distinction, the log data of the microservice during the anomaly time period is called the service anomaly log data).

[0073] In some embodiments, the operating status of the microservice system can be detected by the monitoring component of the microservice system, and it can be determined whether the operating status of the microservice system meets the service level target standard. If it does, it is determined that the microservice system has not experienced any abnormalities. If it does not, it is determined that the microservice system has experienced an abnormality. At this time, the corresponding fault location operation is triggered to determine the abnormal time period in which the microservice system experienced the abnormality, so as to collect the corresponding data based on the abnormal time period.

[0074] It should be noted that by collecting the running status of microservices in real time, we can keep track of their running status and promptly detect whether any abnormalities have occurred in the microservice system. When an abnormality is confirmed, we can promptly trigger fault location operations to accurately determine the root cause of the fault, thereby effectively curbing the spread of the fault.

[0075] In this embodiment of the application, the service exception log data of the microservice includes at least the call trajectory data of the microservice during the exception time period; wherein, the call trajectory data of the microservice is an unstructured string collection, which may include multiple fields, such as timestamp, operation type, status code, error message, etc.

[0076] S102: Extract the call trajectory data of each microservice from the service exception log data of each microservice, and calculate the call trajectory score of each microservice based on the call trajectory data of each microservice.

[0077] During the specific execution of step S102, the total number of abnormal call trajectories and the total number of normal call trajectories that did not occur during the abnormal time period can be counted from the call trajectory data of the service exception log data of the microservice. In order to calculate the call trajectory score of each microservice based on the total number of abnormal trajectories and the total number of normal trajectories of each microservice.

[0078] Optionally, the process of calculating the call trajectory score for each microservice based on the call trajectory data of each microservice can be as follows: For each microservice, the number of abnormal call trajectories and the number of normal call trajectories corresponding to the microservice are counted from the call trajectory data of the microservice; the total number of abnormal call trajectories of each other microservice is counted from the call trajectory data of each other microservice; wherein, other microservices are microservices other than the microservice itself; the call trajectory score of the microservice is calculated based on the number of abnormal call trajectories, the number of normal call trajectories, and the total number of abnormal call trajectories.

[0079] In practical applications, the call trajectory data includes multiple call trajectories. For each call trajectory, it can be determined whether the call trajectory contains keywords such as "error", "exception", and "fail". If they are present, it can be determined that the call trajectory is an exception call trajectory; if they are not present, it can be determined that the call trajectory is a normal call trajectory.

[0080] In this application embodiment, research has shown that the SBFL algorithm is a widely used fault location technique in software engineering. Specifically, by analyzing the execution results of corresponding test cases, the code segment or module most relevant to the fault is identified. Thus, while the SBFL algorithm was initially designed for code-level defect location, its core ideas and methods have also been applied to microservice fault root cause location. For each microservice, each call path involves multiple microservices. Therefore, based on the SBFL algorithm, code defect location can be extended to microservice fault root cause location. By statistically comparing the execution paths and results of test cases with the execution paths and results of statistical call relationships, that is, by statistically analyzing the call path data of each microservice to determine the number of abnormal and normal call paths for each microservice, a call path score for each microservice can be calculated based on the number of abnormal and normal call paths.

[0081] Specifically, for each microservice, the number of abnormal call traces of all other microservices can be accumulated to obtain the total number of abnormal call traces corresponding to the microservice. Finally, the call trace score of the microservice is calculated by the number of abnormal call traces, the number of normal call traces and the total number of abnormal call traces, as shown in formula (1).

[0082] (1)

[0083] in, The call trajectory score for the i-th microservice Let i be the number of abnormal call traces for the i-th microservice. The number of normal UIJ calls for the i-th microservice. Let be the total number of abnormal call traces for the i-th microservice.

[0084] S103: Obtain the metric data of each microservice during the normal time period, and calculate the metric anomaly score of each microservice based on the metric data of each microservice.

[0085] In the specific execution step S103, multiple microservice metrics can be pre-set. For example, these metrics may include service response time, CPU utilization, and memory utilization. For each microservice, a time period during which no anomalies occurred in the microservice system can be determined (for ease of differentiation, this time period is referred to as the normal time period). Metric data for the microservice within the normal time period is obtained. Multiple time points are selected from the normal time period, and metric data for each time point is extracted from the metric data. The metric data for each time point includes the metric value of each microservice metric at that time point. Based on the metric values ​​of each microservice metric at each time point, an anomaly score for each microservice metric is calculated. Finally, based on the anomaly scores of each microservice metric, the anomaly score for the microservice metric is determined.

[0086] Optionally, the process of obtaining the metric data of each microservice within a normal time period and calculating the abnormal metric score of each microservice based on the metric data of each microservice can be as follows: For each microservice, obtain the metric data of the microservice within a normal time period, wherein the metric data includes the metric data of the microservice at each time point, and the metric data at each time point includes the metric value of each microservice metric at that time point, and the time point is a time point within a normal time period; For each time point, calculate the average metric value of the microservice at that time point based on the metric values ​​of each microservice metric at that time point; Calculate the severity of each microservice metric at that time point based on the average metric value of the microservice at that time point and the metric value of each microservice metric at that time point; For each microservice metric, calculate the abnormal metric score of the microservice metric based on the severity of the microservice metric at each time point; Filter out the abnormal metric scores of the microservices from the abnormal metric scores of each microservice metric.

[0087] It should be noted that any time point within the normal time period, the same time point of the previous day, and the same time point of the previous week can be selected as multiple time points selected from the normal time period in this application.

[0088] In practical applications, for each time point, the mean value of each microservice indicator at that time point is calculated to obtain the average value of the microservice indicator at that time point; the absolute value of the difference between the value of each microservice indicator and the average value of that indicator is calculated to obtain the average absolute deviation of each microservice indicator; based on the average value of the indicator, the value of each microservice indicator and the average absolute deviation, the severity of each microservice indicator at that time point is calculated, as shown in formula (2):

[0089] (2)

[0090] Where t is a time point, This represents the severity of the k-th microservice metric at that point in time. This represents the value of the k-th microservice metric at that point in time. This represents the average value of the k-th microservice metric at that point in time. This represents the average absolute deviation of the k-th microservice metric at that point in time.

[0091] In some embodiments, after obtaining the severity of each microservice metric at each time point, the anomaly score of the microservice metric can be calculated based on the severity of the microservice metric at each time point, and the largest anomaly score among the anomaly scores of each microservice metric can be taken as the anomaly score of the microservice metric. The method for determining the anomaly score of the microservice metric is as shown in formula (3):

[0092] (3)

[0093] in, Let k be the anomaly score of the i-th microservice, k be the microservice metric, m be the total number of all microservice metrics, and c be the total number of all time points.

[0094] S104: Obtain the normal service log data for each microservice within the normal time period, and calculate the log anomaly score for each microservice based on the service anomaly log data and the normal service log data.

[0095] In the specific execution of step S104, for each microservice, after obtaining the service exception log data and service normal log data of the microservice, the error type distribution difference and error frequency difference of the microservice can be calculated based on the service exception log data and service normal log data, so as to calculate the log exception score of the microservice based on the error type distribution difference and error frequency difference of the microservice.

[0096] Optionally, the process of calculating the log anomaly score of a microservice based on its service anomaly log data and service normal log data can be as follows: For each microservice, calculate the first actual occurrence count of each error type during the abnormal time period from the service anomaly log data, and calculate the second actual occurrence count of each error during the normal time period from the service normal log data; calculate the error type distribution difference of the microservice based on the first and second actual occurrence counts; calculate the first runtime error frequency during the abnormal time period from the service anomaly log data, and calculate the second runtime error frequency during the normal time period from the service normal log data; calculate the runtime error frequency difference of the microservice based on the first and second runtime error frequencies; and calculate the log anomaly score of the microservice based on the error type distribution difference and error frequency difference.

[0097] In practical applications, after obtaining service exception log data and service normal log data, key information, including timestamps, service names, error codes, error messages, and other core elements, can be extracted from the call traces in the service exception log data and service normal log data, based on these unstructured call traces. These scattered fields can be transformed into standardized structured datasets to facilitate subsequent analysis and processing.

[0098] Specifically, the call trace can be parsed to convert it into a structured call trace, where the structured call trace can be... ; Parse the structured call path into a structured vector ,in Indicates the time when the log was generated. The service that indicates log ownership. Indicates the log operation type. Indicates the result of the operation. This indicates an error message related to the operation. This indicates the upstream service being invoked.

[0099] In this embodiment of the application, after structuring the call traces in the service exception log data and the service normal log data, the first runtime error frequency (average error and its fluctuation range per unit time) and the first actual occurrence number of each error type (error type can be network error, service call failure, etc.) of the microservice system during the abnormal time period can be extracted from the call traces in the structured service exception log data.

[0100] The difference in the frequency of microservice runtime errors is calculated based on the first runtime error frequency and the second runtime error frequency, as shown in formula (4); the difference in the distribution of error types of microservices is calculated based on the first actual occurrence count and the second actual occurrence count, as shown in formula (5).

[0101] (4)

[0102] in, The second runtime error frequency, The first runtime error frequency, Differences in the frequency of runtime errors for microservices.

[0103] (5)

[0104] in, Here is the error type distribution for microservices, where b represents the error type. The number of times the first error type b occurs in microservice i within the abnormal time period. This represents the second actual occurrence number of error types in microservice i during the normal time period b.

[0105] It should be noted that the overall deviation is calculated by combining the frequency deviation and the fault type distribution deviation. The larger the overall deviation, the higher the log anomaly score of the microservice. The calculation method of the log anomaly score of the microservice is shown in formula (6):

[0106] (6)

[0107] in, Assign an anomaly score to the logs of microservice i. The correlation coefficient is a predefined value.

[0108] S105: Construct a corresponding directed graph based on the call trajectory data of each microservice. The directed graph consists of multiple nodes and multiple edges. Nodes are microservices, and edges are connections between two microservices that have a call relationship.

[0109] During the specific execution of step S105, the call trajectory data of each microservice can be extracted from the service exception log data of each microservice. The call trajectory data includes multiple call trajectories. The call relationship between each microservice is determined based on the call trajectory of each microservice, so that each microservice is used as a node and the call relationship between each microservice is used as an edge to construct a directed graph.

[0110] S106: Calculate the weight of each edge based on the service exception log data of each microservice and the directed graph.

[0111] In the specific execution of step S106, after constructing the directed graph, for each edge in the directed graph, the weight of the edge is determined based on the service exception log data of the two microservices that constitute the edge.

[0112] Optionally, the process of calculating the weight of each edge based on the service exception log data of each microservice and the directed graph can be as follows: For each edge in the directed graph, determine the first microservice and the second microservice on the edge; wherein, the first microservice is the microservice that requests and calls between the two microservices on the edge, and the second microservice is the microservice that is called between the two microservices on the edge; count the total number of first exceptions that occur in the first microservice from the service exception log data of the first microservice, and count the total number of second exceptions that occur simultaneously in the first microservice and the second microservice from the service exception log data of the first microservice and the second microservice; calculate the weight of the edge based on the total number of first exceptions and the total number of second exceptions.

[0113] In practical applications, since the anomaly score of a microservice does not directly equate to its likelihood of being the root cause of a failure, a comprehensive consideration from the perspective of anomaly propagation is necessary. The stronger the correlation between the metrics of two microservices, the higher the likelihood that they are affected by the same anomaly source. Therefore, the probability of anomaly propagation can be measured by the number of times a microservice experiences a failure within an abnormal time period, thus determining the weight between two microservices with a calling relationship.

[0114] Specifically, based on the total number of first anomalies where the first microservice fails within the abnormal time period and the total number of second anomalies where the first and second microservices fail simultaneously within the abnormal time period, the weight of the edge formed by the first and second microservices is calculated, whereby the weight of the edge is calculated as shown in formula (7):

[0115] (7)

[0116] in, For the first microservice, For the second microservice, This represents the total number of first exceptions that occurred within the abnormal time period for the first microservice. This represents the total number of times the first and second microservices simultaneously failed within the abnormal time period, representing the second exception. The probability that the failure of the first microservice leads to the failure of the second microservice is the causal probability, which is the weight of the corresponding edge.

[0117] S107: The anomaly score of each microservice is obtained by iteratively calculating the weights of each edge in the directed graph and the call trajectory score, indicator anomaly score, and log anomaly score of each microservice through random walk.

[0118] In the specific execution step S107, a random walk is used to calculate the node anomaly score of each microservice based on the call trajectory score, indicator anomaly score, and log anomaly score of each microservice. Based on the node anomaly scores of each microservice, the bias vector of each microservice is calculated. Based on the weight of each edge, the node anomaly score of each microservice, and the bias vector, the anomaly score of each microservice is calculated.

[0119] Optionally, the process of obtaining the anomaly score of each microservice by iteratively calculating the weights of each edge in the directed graph and the call trajectory score, metric anomaly score, and log anomaly score of each microservice through random walk can be as follows: Calculate the node anomaly score of each microservice based on its call trajectory score, metric anomaly score, and log anomaly score; for each microservice, statistically analyze the upstream and downstream service sets based on its call trajectory data; calculate the dwell probability of the microservice based on the weights of each edge, the node anomaly score of the microservice, the upstream service set, and the downstream service set; for each edge, calculate the node anomaly score based on its weights and the call trajectory score of each microservice. The weights of other edges are calculated, the state transition values ​​of the edges are calculated, and a state transition matrix is ​​constructed based on the state transition values ​​of each edge. Here, each other edge is an edge consisting of the first microservice of the edge and other second microservices with which it has a calling relationship. Each other second microservice is either the first microservice of the edge, or the second microservice of the edge, or a microservice other than the first or second microservices that has a calling relationship with the first microservice. If the other microservice is the first microservice, the weight of the other edge is the dwell probability of the first microservice. Based on the node anomaly scores of each microservice, the bias vector of each microservice is calculated. Based on the bias vectors and the state transition matrix, the anomaly score of each microservice is calculated.

[0120] In practical applications, research has shown that an innovative random walk method based on the improved PageRank algorithm enhances the accuracy of fault location by adaptively adjusting the propagation probabilities of forward, backward, and self-dwelling propagation. Specifically, it generates a weighted directed graph model based on the call relationships between microservices and prioritizes each microservice by iteratively calculating the dwell probability of each node (microservice). Compared to the traditional PageRank algorithm, the accuracy of the calculation results is significantly improved.

[0121] Traditional PageRank algorithms may be limited by "local extrema," meaning that the correlation between microservices and downstream services is low, resulting in limited exploration capabilities. To address this issue, this invention introduces a backpropagation mechanism and defines a backpropagation coefficient, enabling downstream services to be influenced by upstream services. Specifically, this application sets corresponding backpropagation conditions, where the calling relationship between the first and second microservices constituting an edge is that the first microservice calls the second microservice, and the second microservice does not call the first microservice. When an edge satisfies the backpropagation conditions, the weight of that edge is backpropagated, and the backpropagation weight of the edge is calculated. The probability of backpropagation (backpropagation weight) is calculated as follows:

[0122] (8)

[0123] in, For the pre-set correlation coefficient, The reverse weights are the edges formed by the first microservice i and the second microservice j. Let be the weight of the edge formed by the first microservice i and the second microservice j; This indicates that the first microservice i calls the second microservice j. This indicates that the second microservice j does not call the first microservice i.

[0124] It should be noted that if the probability of a microservice affecting its upstream and downstream services is low, but the degree of abnormality of the microservice is high, it can be considered that the probability of it being an abnormal service is relatively high. In this case, the dwell time of the walkthrough at that node (microservice) should be extended. Since the original value range exceeds the [0,1] interval, it needs to be normalized. Therefore, the node abnormality score of the microservice is... The calculation method is shown in formula (9):

[0125] (9)

[0126] In some embodiments, the upstream service set I and downstream service set O of each microservice can be statistically analyzed based on the call relationships between microservices in the directed graph. For each microservice, the weights of the edges formed by the microservice and each upstream service in the upstream service set, the weights of the edges formed by the microservice and each downstream service in the downstream service set, and the node anomaly score of the microservice can be calculated. Percentage of time spent in the current microservice The specific calculation formula is shown in formula (10):

[0127] (10)

[0128] in This represents the self-retention coefficient of a microservice. The node anomaly score for microservice i. Let be the inverse weight of the edge formed by microservice i and upstream service z. Let be the weight of the edge formed by microservice i and its downstream microservice r.

[0129] In some embodiments, the state transition value of an edge is calculated based on the edge's weight and the weights of all other edges, and a state transition matrix is ​​constructed based on the state transition values ​​of each edge. The state transition value of an edge is calculated as shown in formula (11) below:

[0130] (11)

[0131] in, Let y be the state transition value of the edge formed by the first microservice i and the second microservice j, and let y be the other second microservices. The weight of the edge consisting of the first service and the other second service.

[0132] It should be noted that the probability of node anomaly score for each microservice can be calculated based on the node anomaly score of each microservice, and a bias direction can be constructed based on the node anomaly score probability of each microservice. The probability calculation method for node anomaly scores in microservices is shown in formula (12):

[0133] (12)

[0134] Where n is the total number of microservices. This represents the probability of node anomaly scores for microservice 1.

[0135] In this embodiment, iterative calculations can be performed based on the root cause graph of the microservice until the results converge, yielding the anomaly score of the microservice. The iterative equation for the microservice is calculated as follows:

[0136] (13)

[0137] Where d represents the probability of implicit transmission. For the iteration result, This includes anomaly scores for each microservice. In the initial iteration, The anomaly score for each microservice is set to 1 / n. In non-initial iterations, The result is from the previous iteration. If the Euclidean distance between two consecutive iteration results is less than a threshold... If the iteration ends, the result of the last iteration is taken as the root cause ranking result. The higher the anomaly score in the root cause ranking result, the greater the likelihood that the corresponding microservice is the root cause of the failure.

[0138] In summary, the technical solution provided in this application calculates the call trajectory score, indicator anomaly score, and log anomaly score for each microservice. It also constructs a service dependency graph (directed graph) of the microservice system based on the call trajectory data of each microservice and calculates the anomaly propagation (weight) of each edge in the directed graph. This allows for the use of a dynamic random walk method to locate the root cause of abnormal services (calculating the anomaly score of each microservice based on the weight of each edge, the call trajectory score, indicator anomaly score, and log anomaly score). Specifically, by setting forward, backward, and self-stopping walk modes, the walk process becomes more flexible, improving the accuracy of the location. Finally, based on the anomaly scores of each microservice, the root cause of the microservice system failure is determined.

[0139] S108: The microservice with the highest anomaly score among all microservices is identified as the root cause of the anomaly in the microservice system.

[0140] During the specific execution of step S108, after obtaining the root cause ranking result, the microservice corresponding to the anomaly score with the highest score in the root cause ranking result can be determined, and the root cause of the anomaly in this microservice system can be identified.

[0141] This application provides a fault location method for multi-source microservices. When an anomaly is detected in the microservice system, the method acquires service anomaly log data for each microservice during the anomaly period, where the anomaly period is the time when the microservice system experiences the anomaly. It then extracts call trajectory data for each microservice from the service anomaly log data and calculates a call trajectory score for each microservice based on this data. Finally, it acquires metric data for each microservice during the normal period and calculates an anomaly score for each microservice based on this data. The method also acquires service normal log data for each microservice during the normal period and calculates an anomaly score for each microservice based on this data. The service anomaly logs and normal service logs of each microservice are used to calculate the log anomaly score. A directed graph is constructed based on the call trajectory data of each microservice. This graph consists of multiple nodes and edges, where nodes represent microservices and edges connect two microservices with a call relationship. The weight of each edge is calculated based on the service anomaly logs and the directed graph. The anomaly score of each microservice is calculated by combining the weights of each edge with the call trajectory score, metric anomaly score, and log anomaly score. The microservice with the highest anomaly score is identified as the root cause of the current anomaly in the microservice system. The technical solution provided in this application calculates the call trajectory score, indicator anomaly score, and log anomaly score for each microservice. It also constructs a service dependency graph (directed graph) of the microservice system based on the call trajectory data of each microservice and calculates the weight of each edge in the directed graph. This allows for the calculation of the anomaly score for each microservice based on the weight of each edge, the call trajectory score, indicator anomaly score, and log anomaly score. Finally, based on the anomaly scores of each microservice, the root cause of the microservice system failure can be determined. This eliminates the need for manual fault location, resulting in high reliability of fault location and reduced resource consumption and economic costs.

[0142] Based on the fault location of multi-source microservices provided in the above embodiments of this application, correspondingly, this application provides a fault location system for multi-source microservices, such as... Figure 2 As shown, the system includes:

[0143] The first module unit 21 is used to obtain service exception log data of each microservice during the exception time period when an exception is detected in the microservice system. The exception time period is the time period during which the microservice system is abnormal.

[0144] The first calculation unit 22 is used to extract the call trajectory data of each microservice from the service exception log data of each microservice, and calculate the call trajectory score of each microservice based on the call trajectory data of each microservice.

[0145] The second calculation unit 23 is used to obtain the indicator data of each microservice during the normal time period, and calculate the indicator abnormality score of each microservice based on the indicator data of each microservice.

[0146] The third calculation unit 24 is used to obtain the normal service log data of each microservice within a normal time period, and to calculate the log anomaly score of each microservice based on the service anomaly log data and the normal service log data.

[0147] The directed graph generation unit 25 is used to construct a corresponding directed graph based on the call trajectory data of each microservice. The directed graph consists of multiple nodes and multiple edges, where nodes are microservices and edges are connections between two microservices that have a call relationship.

[0148] The fourth calculation unit 26 is used to calculate the weight of each edge based on the service exception log data of each microservice and the directed graph;

[0149] The fifth calculation unit 27 is used to perform iterative calculations by random walk based on the weights of each edge in the directed graph and the call trajectory score, indicator anomaly score, and log anomaly score of each microservice to obtain the anomaly score of each microservice.

[0150] The determination unit 28 is used to determine the root cause of the failure of the microservice system in this case based on the microservice with the highest anomaly score among all microservices.

[0151] This application provides a fault location system for multi-source microservices. When an anomaly is detected in the microservice system, it acquires service anomaly log data for each microservice during the anomaly period, where the anomaly period is the time when the microservice system experiences the anomaly. It extracts call trajectory data for each microservice from the service anomaly log data and calculates a call trajectory score for each microservice based on this data. It also acquires metric data for each microservice during the normal period and calculates an anomaly score for each microservice based on this data. Finally, it acquires service normal log data for each microservice during the normal period and calculates an anomaly score for each microservice based on the service anomaly log data and the number of service normal logs. The system calculates the log anomaly score for each microservice; constructs a directed graph based on the call trajectory data of each microservice, where each graph consists of multiple nodes and edges, with nodes representing microservices and edges connecting two microservices with a call relationship; calculates the weight of each edge based on the service anomaly log data of each microservice and the directed graph; calculates the anomaly score for each microservice based on the weights of each edge in the directed graph, the call trajectory score, the metric anomaly score, and the log anomaly score of each microservice; and identifies the microservice with the highest anomaly score as the root cause of the anomaly in the microservice system. This eliminates the need for manual fault location, resulting in high reliability and reduced resource consumption and economic costs.

[0152] Optionally, the first computing unit is specifically used for:

[0153] For each microservice, the number of abnormal call traces and the number of normal call traces corresponding to the microservice are counted from the microservice call trace data;

[0154] The total number of abnormal call traces for each of the other microservices is calculated from the call trace data of each other microservices; where other microservices refer to microservices other than the microservice itself.

[0155] The call trajectory score of a microservice is calculated based on the number of abnormal call trajectories, the number of normal call trajectories, and the total number of abnormal call trajectories.

[0156] Optional, the second computing unit is specifically used for:

[0157] For each microservice, obtain the microservice's metric data within a normal time period. The metric data includes the microservice's metric data at each time point, and the time point metric data includes the metric value of each microservice metric at that time point. The time point is a time point within the normal time period.

[0158] For each point in time, calculate the average value of the microservice metrics at that point in time, based on the metric values ​​of each microservice at that point in time.

[0159] The severity of each microservice metric at a given time point is calculated based on the average metric value of the microservice at that time point and the metric value of each microservice metric at that time point.

[0160] For each microservice metric, calculate the anomaly score of the microservice metric based on the severity of the microservice metric at each time point;

[0161] Abnormal scores for microservice metrics are filtered out from the abnormal scores of various microservice metrics.

[0162] Optional, the third computing unit is specifically used for:

[0163] For each microservice, the first actual occurrence count of each error type during the abnormal time period is calculated from the service exception log data of the microservice, and the second actual occurrence count of each error during the normal time period is calculated from the service normal log data of the microservice.

[0164] Calculate the difference in error type distribution for microservices based on the first and second actual occurrence counts;

[0165] The frequency of the first runtime error occurring in the microservice during the abnormal time period is statistically analyzed from the service exception log data of the microservice, and the frequency of the second runtime error occurring in the microservice during the normal time period is statistically analyzed from the service normal log data of the microservice.

[0166] Calculate the difference in runtime error frequency of microservices based on the first runtime error frequency and the second runtime error frequency;

[0167] Calculate the log anomaly score for each microservice based on the differences in error type distribution and error frequency.

[0168] Optional, the fourth computing unit is specifically used for:

[0169] For each edge in the directed graph, determine the first microservice and the second microservice on the edge; where the first microservice is the microservice that is requested to be called among the two microservices on the edge, and the second microservice is the microservice that is called among the two microservices on the edge.

[0170] The total number of first anomalies occurring in the first microservice is counted from the service anomaly log data of the first microservice, and the total number of second anomalies occurring simultaneously in the first and second microservices is counted from the service anomaly log data of the first and second microservices.

[0171] The weights of the edges are calculated based on the total number of the first and second anomalies.

[0172] Optional, the fifth computing unit is specifically used for:

[0173] For each edge, if the first microservice and the second microservice corresponding to the edge satisfy the backpropagation condition, calculate the back weight of the edge based on the edge weight.

[0174] Calculate the node anomaly score for each microservice based on its call trajectory score, metric anomaly score, and log anomaly score.

[0175] For each microservice, based on the microservice's call history data, the upstream service set and downstream service set of the microservice are statistically analyzed;

[0176] The dwell probability of a microservice is calculated based on the weights of each edge, the inverse weights of each edge, the node anomaly scores of the microservice, the upstream service set, and the downstream service set.

[0177] For each edge, calculate the edge's state transition value based on the edge's weight and the weights of all other edges, and construct a state transition matrix based on the state transition values ​​of all edges. Here, "other edges" refers to edges formed by the first microservice of the edge and other second microservices with which it has a calling relationship; other second microservices are either the first microservice of the edge, or the second microservice of the edge, or microservices other than the first and second microservices that have a calling relationship with the first microservice; if an other microservice is the first microservice, the weight of the other edge is the dwell probability of the first microservice.

[0178] Calculate the bias vector for each microservice based on the node anomaly score of each microservice.

[0179] Calculate the anomaly score for each microservice based on the bias vector and the state transition matrix.

[0180] This application also provides a storage medium storing program instructions that, when loaded and executed by a processor, implement any of the above-described multiplexed method embodiments.

[0181] This application also provides an electronic device, such as Figure 3 As shown, the device includes a processor 301 and a memory 302, which are connected via a bus; the memory stores program instructions; the processor calls the program instructions in the memory to execute any of the above-described abnormal transaction detection method embodiments.

[0182] The processor mentioned in this article can be the terminal's CPU, an integrated MCU within the terminal, or a combination of a CPU and an MCU. Furthermore, the processor contains a kernel that retrieves the corresponding program from memory; one or more kernels can be configured.

[0183] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. Units described as separate components may or may not be physically separate. Components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0184] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0185] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0186] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A fault location method for multi-source microservices, characterized in that, The method includes: When an anomaly is detected in the microservice system, service anomaly log data for each microservice is obtained within the anomaly time period, wherein the anomaly time period is the time period during which the microservice system experienced the anomaly. Extract the call trajectory data of each microservice from the service exception log data of each microservice, and calculate the call trajectory score of each microservice based on the call trajectory data of each microservice; Obtain the metric data of each microservice during the normal time period, and calculate the metric anomaly score of each microservice based on the metric data of each microservice. Obtain the normal service log data of each microservice within the normal time period, and calculate the log anomaly score of each microservice based on the service anomaly log data and the normal service log data. A corresponding directed graph is constructed based on the call trajectory data of each microservice. The directed graph consists of multiple nodes and multiple edges. The nodes are microservices, and the edges are connections between two microservices that have a call relationship. The weight of each edge is calculated based on the service exception log data of each microservice and the directed graph. The abnormal score of each microservice is obtained by iteratively calculating the weight of each edge in the directed graph and the call trajectory score, indicator abnormal score and log abnormal score of each microservice through random walk. The microservice with the highest anomaly score among all the microservices is identified as the root cause of the anomaly in the current microservice system.

2. The method according to claim 1, characterized in that, The step of calculating the call trajectory score for each microservice based on the call trajectory data of each microservice includes: For each microservice, the number of abnormal call traces and the number of normal call traces corresponding to the microservice are counted from the call trace data of the microservice; The total number of abnormal call traces for each of the other microservices is calculated from the call trace data of each other microservice; wherein, the other microservices are microservices other than the microservice mentioned above. The call trajectory score of the microservice is calculated based on the number of abnormal call trajectories, the number of normal call trajectories, and the total number of abnormal call trajectories.

3. The method according to claim 1, characterized in that, The step of obtaining the metric data of each microservice during a normal time period and calculating the metric anomaly score of each microservice based on the metric data of each microservice includes: For each microservice, obtain the indicator data of the microservice within a normal time period, wherein the indicator data includes the indicator data of the microservice at each time point, and the indicator data at each time point includes the indicator value of each microservice indicator at that time point, and the time point is a time point within the normal time period; For each time point, the average value of the indicators of the microservice at that time point is calculated based on the indicator values ​​of each microservice indicator at that time point. The severity of each microservice metric at the time point is calculated based on the average metric value of the microservice at the time point and the metric value of each microservice metric at the time point. For each microservice metric, an anomaly score for the microservice metric is calculated based on the severity of the microservice metric at each of the said time points; The abnormal scores of the microservice metrics are filtered out from the abnormal scores of each microservice metric.

4. The method according to claim 1, characterized in that, The step of calculating the log anomaly score of each microservice based on its service anomaly log data and service normal log data includes: For each microservice, the first actual occurrence count of each error type in the microservice during the abnormal time period is calculated from the service exception log data of the microservice, and the second actual occurrence count of each error in the microservice during the normal time period is calculated from the service normal log data of the microservice. Calculate the error type distribution difference of the microservice based on the first actual occurrence count and the second actual occurrence count; The frequency of a first runtime error occurring in the microservice during the abnormal time period is calculated from the service exception log data of the microservice, and the frequency of a second runtime error occurring in the microservice during the normal time period is calculated from the service normal log data of the microservice. Calculate the difference in runtime error frequency of the microservice based on the first runtime error frequency and the second runtime error frequency; The log anomaly score of the microservice is calculated based on the differences in error type distribution and error frequency of the microservice.

5. The method according to claim 1, characterized in that, The step of calculating the weight of each edge based on the service exception log data of each microservice and the directed graph includes: For each edge in the directed graph, a first microservice and a second microservice on the edge are determined; wherein, the first microservice is the microservice that is requested to be called among the two microservices on the edge, and the second microservice is the microservice that is called among the two microservices on the edge. The total number of first anomalies occurring in the first microservice is counted from the service anomaly log data of the first microservice, and the total number of second anomalies occurring simultaneously in the first microservice and the second microservice is counted from the service anomaly log data of the first microservice and the second microservice. The weight of the edge is calculated based on the first total number of anomalies and the second total number of anomalies.

6. The method according to claim 5, characterized in that, The abnormal score of each microservice is obtained by iteratively calculating the weights of each edge in the directed graph and the call trajectory score, metric anomaly score, and log anomaly score of each microservice through random walk, including: Calculate the node anomaly score for each microservice based on its call trajectory score, metric anomaly score, and log anomaly score. For each microservice, based on the call trajectory data of the microservice, the upstream service set and downstream service set of the microservice are statistically analyzed; The dwell probability of the microservice is calculated based on the weight of each edge, the node anomaly score of the microservice, the upstream service set, and the downstream service set. For each edge, a state transition value is calculated based on the edge's weight and the weights of all other edges, and a state transition matrix is ​​constructed based on the state transition values ​​of all edges. The other edges are formed by the first microservice of the edge and other second microservices with which it has a calling relationship. The other second microservices are either the first microservice of the edge, the second microservice of the edge, or any microservice other than the first and second microservices that has a calling relationship with the first microservice. If the other microservice is the first microservice, the weight of the other edge is the dwell probability of the first microservice. Based on the node anomaly score of each microservice, calculate the bias vector for each microservice; An anomaly score is calculated for each microservice based on the bias vector and the state transition matrix.

7. A fault location system for multi-source microservices, characterized in that, The system includes: The first module unit is used to obtain service exception log data of each microservice during the exception time period when an exception is detected in the microservice system, wherein the exception time period is the time period during which the microservice system experienced an exception. The first calculation unit is used to extract the call trajectory data of each microservice from the service exception log data of each microservice, and calculate the call trajectory score of each microservice based on the call trajectory data of each microservice. The second calculation unit is used to obtain the indicator data of each microservice during the normal time period, and calculate the indicator anomaly score of each microservice based on the indicator data of each microservice. The third calculation unit is used to obtain the normal service log data of each microservice within the normal time period, and to calculate the log anomaly score of each microservice based on the service anomaly log data and the normal service log data. A directed graph generation unit is used to construct a corresponding directed graph based on the call trajectory data of each microservice. The directed graph consists of multiple nodes and multiple edges, where each node is a microservice and each edge is a connection between two microservices that have a call relationship. The fourth calculation unit is used to calculate the weight of each edge based on the service exception log data of each microservice and the directed graph. The fifth calculation unit is used to perform iterative calculations by random walk based on the weights of each edge in the directed graph and the call trajectory score, indicator anomaly score, and log anomaly score of each microservice to obtain the anomaly score of each microservice. The determining unit is used to determine the microservice with the highest anomaly score among the various microservices as the root cause of the anomaly that occurred in the microservice system this time.

8. The system according to claim 7, characterized in that, The first computing unit is specifically used for: For each microservice, the number of abnormal call traces and the number of normal call traces corresponding to the microservice are counted from the call trace data of the microservice; The total number of abnormal call traces for each of the other microservices is calculated from the call trace data of each other microservice; wherein, the other microservices are microservices other than the microservice mentioned above. The call trajectory score of the microservice is calculated based on the number of abnormal call trajectories, the number of normal call trajectories, and the total number of abnormal call trajectories.

9. An electronic device, characterized in that, include: A processor and a memory are connected via a bus; wherein the processor is used to call and execute a program stored in the memory; The memory is used to store a program for implementing the fault location method for multi-source microservices as described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for performing the fault location method for multi-source microservices as described in any one of claims 1-6.

Images