A method and system for monitoring abnormal operation of microservice architecture

Abstract

The present invention belongs to the field of server monitoring, and provides a method and system for monitoring abnormal operation of a microservice architecture, including: obtaining the log of a gateway involved in the microservice by means of a sliding window; parsing the log of the gateway to extract a service call chain; constructing a dependency relationship between services according to the service call chain; constructing a directed graph according to the dependency relationship; dividing the directed graph into multiple subgraphs according to the attributes of the edge; for each subgraph, detecting whether there are similar subgraphs in the latest preset number of sliding windows, if not, there are call anomalies between the microservices in the corresponding subgraph. The present invention can improve the efficiency of monitoring abnormal operation of a microservice architecture.

Description

Technical Field

[0001] The present invention belongs to the field of server monitoring, and in particular relates to a method and system for monitoring abnormal operation of a microservice architecture. Background Art

[0002] With the development of Internet technology and the continuous growth of business needs, the complexity and scale of modern software systems are increasing. Traditional monolithic architectures are gradually unable to meet the requirements of rapid iteration, elastic expansion and high availability, so microservice architectures have emerged. Microservice architectures split a single large application into multiple independent small services, each of which focuses on completing specific business functions and interacts through lightweight communication mechanisms (such as HTTP / REST, gRPC, etc.). This architecture has shown significant advantages in improving system flexibility, development efficiency and scalability.

[0003] However, the introduction of microservice architecture also brings new challenges. Due to the increase in the number of services and their independent deployment characteristics, the dependencies between services become complex and dynamic. The call chain between services may involve multiple nodes, and the overall status of the system is difficult to fully grasp through traditional monitoring methods. At the same time, performance indicators such as service call frequency, response time, and error rate are affected by many factors. In actual operation, fluctuations in these indicators may indicate potential anomalies or system failures. If these anomalies are not discovered and handled in a timely manner, they may cause system performance to degrade or even cause more serious service interruptions.

[0004] Traditional monitoring methods mainly rely on static monitoring of a single service or node, such as resource usage, number of requests, and response time. These methods can only capture single-point problems and are difficult to effectively monitor the dynamic dependencies between services in complex systems. In addition, traditional methods lack analysis of the overall behavior of the system and cannot capture potential anomalies caused by changes in service call relationships in the microservice architecture. Therefore, how to monitor service dependencies in the microservice architecture in real time and accurately, and to detect and respond to anomalies in a timely manner, has become a technical problem that urgently needs to be solved in the current system operation and management field. Summary of the invention

[0005] In order to solve the problem of smart contract audit in the prior art, a monitoring method and system for abnormal operation of microservice architecture are proposed.

[0006] In one embodiment, the present invention provides a method for monitoring abnormal operation of a microservice architecture, comprising the following steps:

[0007] Obtain the logs of the gateway involved in the microservice by means of a sliding window;

[0008] Parsing the log extraction service call chain of the gateway;

[0009] Building dependencies between services based on the service call chain;

[0010] A directed graph is constructed according to the dependency relationship, wherein the nodes in the directed graph represent microservices, the edges represent the calling relationship between services, the direction of the edge points from the source service to the target service, and the attributes of the edge are the number of service calls, response time, and error rate;

[0011] Splitting the directed graph into a plurality of subgraphs according to the attributes of the edges;

[0012] For each subgraph, check whether there are similar subgraphs in the most recent preset number of sliding windows. If not, there are call anomalies between the microservices in the corresponding subgraph.

[0013] Furthermore, parsing the log extraction service call chain of the gateway specifically includes:

[0014] Get the recorded log data from the API gateway;

[0015] Filter the collected logs and retain information related to service calls;

[0016] According to the request ID, the log records of the same request in different service nodes are associated together;

[0017] Determine the order in which requests are called between various service nodes by analyzing the associated log records;

[0018] Output the extracted service call chain in a structured form.

[0019] Furthermore, the constructing of inter-service dependencies according to the service call chain includes:

[0020] Identify all involved service nodes from the service call chain, each node represents an independent microservice;

[0021] For each service call chain, analyze the call sequence and determine which services have direct call relationships.

[0022] Accumulating and aggregating dependency relationships according to the calling relationships;

[0023] Weights are assigned based on the call frequency, response time, and error rate as dependencies.

[0024] Further, constructing a directed graph according to the dependency relationship includes:

[0025] Extract all microservices from service dependencies and create corresponding nodes;

[0026] Create directed edges between nodes based on the order of calls in the service dependency relationship;

[0027] Assign attributes to each edge, including the number of service calls, response time, and error rate.

[0028] Furthermore, the constraint condition for dividing the directed graph into multiple subgraphs according to the attributes of the edges is:

[0029] There are strong dependencies between services within a subgraph;

[0030] There are fewer service dependencies between subgraphs, reducing cross-subgraph service calls.

[0031] Furthermore, the step of dividing the directed graph into a plurality of subgraphs according to the attributes of the edges is:

[0032] For each edge Calculate its weight :

[0033] ;

[0034] Among them, α, β, and γ are adjustable weight coefficients used to balance the importance of different attributes, i and j are node numbers, and the number of calls ij Indicates the number of times node i calls node j and the response time ij Indicates the response time and error rate when node i calls node j ij represents the error rate when node i calls node j;

[0035] According to the calculated weight value , sort all edges from high to low;

[0036] Treat each node as a separate subgraph , at the beginning, there are n subgraphs in the system, where n is the total number of nodes, and i and j are the node numbers;

[0037] Starting from the edge with the highest weight, check each edge in turn , if the edge If the connected nodes i and j belong to different subgraphs, the two subgraphs are merged. The new subgraph after the merger contains all the paths from i to j and retains all the nodes on the path. The merging operation is continued until the number of subgraphs reaches the expected value or the edge weight across subgraphs is lower than a certain threshold.

[0038] The algorithm stops when all edges have been processed or the edge weights across subgraphs are lower than the preset threshold; at this point, the graph is divided into several subgraphs, the node dependencies within each subgraph are strong, and the dependencies between subgraphs are weak.

[0039] Furthermore, the method for calculating the edge weight similarity between two subgraphs includes:

[0040] For the current subgraph and the subgraph of the previous sliding window , calculate their similarity:

[0041] ;

[0042] in and They represent the weights of the corresponding edge e in the current subgraph and the past subgraph respectively, and E is the common edge set in the two subgraphs.

[0043] Furthermore, the size of the sliding window is 10 minutes and the step size is 5 minutes.

[0044] Furthermore, after determining the subgraph in which the service call has an exception, the nodes in the subgraph and the call relationships are displayed to the user.

[0045] On the other hand, the present invention also provides a monitoring system for abnormal operation of a microservice architecture, comprising the following modules:

[0046] An acquisition module, used to acquire the logs of the gateway involved in the microservice by means of a sliding window;

[0047] A parsing module, used to parse the log extraction service call chain of the gateway;

[0048] A construction module, used to construct dependencies between services according to the service call chain;

[0049] A graph construction module is used to construct a directed graph according to the dependency relationship, wherein the nodes in the directed graph represent microservices, the edges represent the calling relationship between services, the direction of the edges points from the source service to the target service, and the attributes of the edges are the number of service calls, response time, and error rate;

[0050] A segmentation module, used for segmenting the directed graph into a plurality of subgraphs according to the attributes of the edges;

[0051] The detection module is used to detect whether there are similar subgraphs in the latest preset number of sliding windows for each subgraph. If not, there are call anomalies between the microservices in the corresponding subgraph.

[0052] The present invention can produce the following beneficial effects through the above technical solution:

[0053] (1) Through sliding window and directed graph technology, the call relationship and dependency changes between services in the microservice architecture are accurately captured. Combined with the similarity calculation of edge weights (such as number of calls, response time, and error rate), abnormal call behavior can be accurately detected, rather than just simple changes in dependencies, thereby reducing false positives and improving the accuracy of anomaly detection.

[0054] (2) Using sliding window technology, the solution can update and monitor the dependencies between services in the system in real time. As time goes by, the sliding window can capture the dynamic changes of the system and ensure the timeliness and accuracy of the monitoring results. This dynamic monitoring method adapts to the elasticity and variability of the microservice architecture and can detect potential abnormal situations in a timely manner.

[0055] (3) By splitting a complex directed graph into multiple subgraphs and performing independent similarity checks on each subgraph, the scheme effectively simplifies the analysis of complex dependencies. Modular subgraph analysis not only helps to quickly locate abnormal services, but also limits the scope of the fault to a local area, reducing the impact on the overall system.

[0056] (4) The combination of sliding window technology and similar subgraph detection can not only be used for short-term anomaly detection, but also for trend analysis through long-term data accumulation. The operation and maintenance team can use this trend data to optimize the system, identify long-standing performance problems or potential bottlenecks, and further improve the overall performance and stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0058] Figure 1 is a flow chart of the method of the present invention. DETAILED DESCRIPTION

[0059] Below, the invention is preferably described in conjunction with the accompanying drawings and specific implementation methods.

[0060] This embodiment solves the above problem through the following steps:

[0061] In one embodiment, reference Figure 1 , the present invention provides a method for monitoring abnormal operation of a microservice architecture.

[0062] Microservice architecture is a software architecture style that decomposes an application into a set of small, independently deployed services. Each service is usually built around a specific business function and communicates through lightweight protocols such as HTTP / REST, gRPC, etc. The advantage of microservice architecture is that it can improve the flexibility, scalability and maintainability of the system, but it also brings the complexity and management difficulties of distributed systems.

[0063] In a microservice architecture, operational anomalies usually refer to any deviation from normal behavior during the operation of a service. These anomalies may include, but are not limited to, long service response times, increased request failure rates, service crashes or unavailability, and excessive resource consumption. These anomalies often affect the overall performance, reliability, and user experience of the system, so it is critical to detect and handle these anomalies in a timely manner.

[0064] Specifically, the steps include:

[0065] Step S1, obtaining the log of the gateway involved in the microservice by means of a sliding window.

[0066] Sliding window is a technology commonly used in time series data processing. By defining a fixed-size window (for example, one minute or five minutes), the window will gradually slide on the time axis, and each slide will cover a new section of log data. In the present invention, the sliding window is applied to the log data stream of the API gateway to regularly capture the log information interacting with the microservice.

[0067] In the microservice architecture, the API gateway is the entry point for all service requests and is responsible for receiving, routing, and processing requests from clients. Whenever a request enters the system through the gateway, the gateway will record detailed request information. These log data include the source IP of the request, the target microservice, the request time, the request path, the response status code, and the response time.

[0068] In order to monitor the running status of microservices, the method of the present invention first needs to extract log information related to a specific microservice from the log of the gateway. This information reflects the request processing of the microservice in a specific time period and is the basis for analyzing the performance of the microservice and identifying abnormal behavior.

[0069] In the method of the present invention, the sliding window is used to periodically obtain the gateway logs related to the microservice. Specifically, the size of the sliding window can be configured according to the needs of the system, for example, set to one minute. In each minute period, the sliding window extracts the log information related to the target microservice from the log data stream of the gateway, and aggregates these log records into a data set.

[0070] As time goes by, the sliding window will continue to slide forward, each movement covers a new time period, and extracts the corresponding log data again. This method ensures that the system can continuously obtain the latest log information, providing continuous and real-time data support for subsequent anomaly detection.

[0071] Step S2, parsing the log extraction service call chain of the gateway.

[0072] The service call chain refers to all the service nodes and their call order that a request goes through in the microservice system. For each request, the call chain can be composed of the initial service when the request enters the gateway, processed by multiple intermediate services, and finally returned to the client. The service call chain not only reflects the execution path of the request, but also shows the dependencies between services. It is an important tool for understanding and optimizing the system architecture.

[0073] Although the API gateway records the details of all requests, this information is usually stored in log files in an unstructured or semi-structured form. In order to extract useful service call chain information from them, these logs need to be parsed and processed. This process includes identifying key fields related to service calls from the logs, such as request ID, service name, request path, timestamp, etc., and organizing them into a meaningful call chain.

[0074] In the method of the present invention, the process of parsing the gateway log to extract the service call chain includes the following steps:

[0075] Step S21, log collection step: First, obtain the recorded log data from the API gateway. The log data usually contains multiple records, each record represents a service call.

[0076] Step S22, log filtering step: filter the collected logs to retain information related to service calls. At this time, it is necessary to identify key information fields in the logs, such as Request ID, which is a unique identifier for each request and is used to associate multiple related log entries.

[0077] Step S23, request association step: according to the request ID, the log records of the same request in different service nodes are associated together. This step is crucial because it can integrate the scattered log entries into a complete call chain.

[0078] Step S24, constructing a call chain: by analyzing the associated log records, determine the call sequence of the request between the various service nodes. The call chain shows the entire path of the request from entering the system to the end of the response.

[0079] Step S25, call chain output step: Finally, the extracted service call chain can be output in a structured form, such as JSON or table form, to facilitate subsequent analysis.

[0080] Step S3: constructing inter-service dependencies based on the service call chain.

[0081] Inter-service dependency means that a microservice needs to rely on the output of other microservices to complete its own tasks. In a microservice architecture, dependencies between services are usually implemented through network calls. For example, a user service may need to call an authentication service to verify the user's identity, and then call an order service to process the user's order. These call relationships constitute inter-service dependencies.

[0082] According to the extracted service call chain, the method of the present invention constructs the dependency relationship between services through the following steps:

[0083] Step S31, service node identification:

[0084] First, identify all involved service nodes from the service call chain. Each node represents an independent microservice that provides specific functionality in the system. Node identification is usually achieved by extracting the service name, service ID, or other unique identifier in the service call chain.

[0085] Step S32, call relation extraction:

[0086] For each service call chain, analyze the call sequence and determine which services have direct call relationships. Specifically, if service A calls service B, then service A is dependent on the output of service B. At this point, in the dependency graph, a directed edge will be established between service A and service B, with the direction of the edge pointing from A to B, indicating A's dependency on B.

[0087] Step S33, accumulation and aggregation of dependencies:

[0088] Throughout the system operation, multiple requests will call multiple services through different paths. As more and more call chains are resolved and added to the dependency graph, the dependencies between services will gradually accumulate. By aggregating these dependencies, you can identify which dependencies are the most critical or most frequent call paths in the system.

[0089] Step S34, edge weight assignment:

[0090] To more accurately reflect the strength of dependencies between services, weights can be assigned to the edges in the dependency graph. The weight of an edge is usually determined by factors such as call frequency, response time, and error rate. For example, the more calls there are, the stronger the dependency, and the greater the weight of the edge. Weight assignment can help further analyze the criticality of services and the performance bottlenecks of the system.

[0091] Step S4, constructing a directed graph based on the dependency relationship, wherein the nodes in the directed graph represent microservices, the edges represent the calling relationships between services, the direction of the edges points from the source service to the target service, and the attributes of the edges are the number of service calls, response time, and error rate.

[0092] In the present invention, the basic structure of a directed graph includes nodes and edges.

[0093] Node: In a directed graph, each node represents an independent microservice. The existence of a node indicates that the service assumes a specific function in the system, such as user authentication, order processing, payment services, etc.

[0094] Edge: An edge represents a call relationship between services and is an element that connects two nodes in a directed graph. The direction of the edge indicates the order of the call, from the caller (source service) to the callee (target service). For example, if service A calls service B, then in the directed graph, there is a directed edge from node A to node B.

[0095] In order to fully reflect the complexity and importance of the calling relationship between services, each edge in the directed graph not only represents the calling relationship, but also carries multiple key attributes, including the number of service calls, response time, and error rate.

[0096] Number of service calls:

[0097] The number of service calls refers to the total number of times a service calls another service within a specific time period. The number of calls is an important indicator for measuring the strength of the dependency relationship between services. The more calls there are, the closer the dependency relationship between the two services is.

[0098] By analyzing the number of service calls, we can identify the high-frequency call paths in the system. These paths are often the critical paths of the system and have a significant impact on the overall performance of the system.

[0099] Response time:

[0100] Response time refers to the time it takes for a service to receive a request and return a response. Response time directly affects the user experience of the system and is an important indicator for measuring service performance.

[0101] By recording the response time of each service call in a directed graph, performance bottlenecks in the system can be identified. When the response time of a certain edge is significantly higher than that of other edges, it may indicate that there is a performance problem in the call path and it needs to be optimized or adjusted.

[0102] Error rate:

[0103] The error rate is the frequency of errors that occur during service calls, usually expressed as the percentage of calls with errors to the total number of calls. A high error rate may indicate a problem with the service or the resources it depends on.

[0104] By monitoring the error rate of service calls, we can promptly discover and resolve potential faults between services. Call paths with high error rates may appear as "dangerous edges" in a directed graph and require special attention.

[0105] Based on the dependencies between services, the process of generating a directed graph includes the following steps:

[0106] Step S41, node construction:

[0107] Extract all microservices from the service dependencies and create corresponding nodes. Each node represents a specific microservice, which is represented by a unique identifier or service name in the graph.

[0108] Step S42, edge establishment and direction determination:

[0109] Directed edges are created between nodes based on the calling order in the service dependency. The direction of the edge is from the calling service (source service) to the called service (target service), indicating the dependency relationship between services. Edges with clear directions can clearly show the flow of service calls and help understand the interaction pattern between services.

[0110] Step S43, attribute assignment:

[0111] Each edge is assigned attributes, including the number of service calls, response time, and error rate. The number of calls can be determined by counting the call frequency of the corresponding service pairs in the service call chain; the response time can be determined by calculating the average processing time of the service calls in the call chain; the error rate can be determined by counting the ratio of the number of errors that occurred during the call process to the total number of calls.

[0112] Step S5, dividing the directed graph into a plurality of subgraphs according to the attributes of the edges;

[0113] In a microservice architecture, as the system scales and increases in complexity, the dependencies between services can become extremely complex. In order to better understand and manage these relationships, it is necessary to split the entire dependency graph into multiple subgraphs, each of which represents a group of closely related services. This segmentation not only helps to simplify analysis, but also helps identify modular structures and potential abnormal behaviors in the system. By leveraging the properties of the edges (such as the number of service calls, response time, error rate, etc.), a graph segmentation algorithm can be used to split the directed graph into several subgraphs, thereby revealing the internal dependencies of different service clusters in the system.

[0114] The goal of graph partitioning is to divide a directed graph into several subgraphs while preserving important dependencies in the graph, so that:

[0115] There are strong dependencies between services within a subgraph (i.e., high call frequency, low response time, and low error rate).

[0116] There are fewer service dependencies between subgraphs, and cross-subgraph service calls are minimized.

[0117] In this way, closely related services in the system can be grouped together to form a clear modular structure for easy management and optimization.

[0118] The method of dividing into multiple sub-graphs of the present invention specifically comprises the following steps:

[0119] Step S51, edge weight calculation:

[0120] For each edge (from node i to node j), calculate its weight :

[0121] ;

[0122] Among them, α, β, and γ are adjustable weight coefficients used to balance the importance of different attributes, i and j are node numbers, and the number of calls ij Indicates the number of times node i calls node j and the response time ij Indicates the response time and error rate when node i calls node j ij Represents the error rate when node i calls node j.

[0123] Step S52: according to the calculated weight value , sort all edges from high to low.

[0124] Step S53, treat each node as a separate subgraph , initially there are n subgraphs in the system, where n is the total number of nodes, and i and j are the node numbers.

[0125] Step S54, starting from the edge with the highest weight, check each edge in turn , if the edge If the connected nodes i and j belong to different subgraphs, the two subgraphs are merged. The merged new subgraph contains all paths from i to j and retains all nodes on the path. The merging operation continues until a certain stopping condition is met, such as the number of subgraphs reaches the expected value or the edge weight across subgraphs is lower than a certain threshold.

[0126] Step S55: When all edges have been processed or the edge weights across subgraphs are all below a preset threshold, the algorithm stops. At this point, the graph is divided into several subgraphs, and the node dependencies within each subgraph are strong, while the dependencies between subgraphs are weak.

[0127] The segmented subgraphs usually represent independent modules or subsystems in the system. By dividing the service cluster into subgraphs, modular management of the system can be achieved, simplifying development and maintenance.

[0128] By splitting a directed graph into multiple subgraphs based on edge attributes, the dependency structure of the microservice system can be effectively simplified, revealing the strong and weak dependencies between service clusters. The edge weight-based splitting algorithm provides a flexible and efficient way to decompose complex systems into manageable modules for easy optimization and maintenance. The split subgraphs not only play an important role in modular management, performance optimization, fault isolation, and anomaly detection, but also provide a clear structural foundation for further system analysis.

[0129] Step S6: for each subgraph, check whether there is a similar subgraph in the latest preset number of sliding windows. If not, there is a call anomaly between the microservices in the corresponding subgraph.

[0130] In a microservice architecture, the dependencies and calling patterns between services may change over time. These changes may sometimes be caused by normal fluctuations in business demand, but they may also be early signals of potential anomalies. In order to effectively monitor the changes in calling relationships between services, prevent the spread of anomalies and affect the overall stability of the system, the present invention proposes an anomaly monitoring method based on sliding windows and similar subgraph detection. Specifically, by performing similarity detection on each subgraph within the most recent several sliding windows, it is determined whether the structure of the subgraph is stable or has undergone abnormal changes.

[0131] By performing similarity checks on each subgraph in the most recent sliding windows, we determine whether the structure of the subgraph has changed significantly. If no similar subgraph is found in the most recent sliding window, we assume that there is a call anomaly between the microservices in the subgraph.

[0132] According to the previous steps, set the sliding window size W and sliding step size S. The window size W determines the analysis range in each time period, and the step size S determines the window movement frequency. For example, the window size is 10 minutes and the step size is 5 minutes, which means that a new sliding window will be generated every 5 minutes and the data in the past 10 minutes will be analyzed.

[0133] According to the previous steps, for each sliding window, extract and build the subgraph within the current time period. The extracted subgraph includes the nodes (microservices) and edges (service call relationships) in the subgraph, as well as the attributes of the edges (number of calls, response time, error rate).

[0134] Calculate the edge weight similarity between two subgraphs. For the current subgraph and the subgraph of the previous sliding window , calculate their similarity:

[0135] ;

[0136] in and They represent the weights of the corresponding edge e in the current subgraph and the past subgraph respectively, and E is the common edge set in the two subgraphs.

[0137] Set the similarity threshold θ, if the current subgraph If the similarity with the previous n sliding window subgraphs is lower than θ, the change between the subgraphs is considered significant and marked as abnormal.

[0138] Furthermore, after determining the subgraph in which the service call is abnormal, the nodes and call relationships in the subgraph are displayed to the user.

[0139] On the visualization interface, users can see a directed graph containing several nodes and edges. The connection direction between nodes is clearly visible, and users can see at a glance the specific services called abnormally and their dependencies.

[0140] Abnormal nodes and edges will be highlighted. For example, the color of the edge may gradually change from green (normal) to yellow or red (abnormal) to prompt users to pay attention to abnormal changes in call relationships.

[0141] Furthermore, while displaying the abnormal subgraph, the system can provide additional troubleshooting support, such as recommended inspection steps, related log links, service health check reports, etc.

[0142] The system can also provide automated operation entry points, such as restarting abnormal services, adjusting configurations, or triggering load balancing policies to help quickly restore the system to normal status.

[0143] The system can display the current abnormal subgraph and the previous normal subgraph to help users understand the evolution of the abnormality. For example, you can display the historical change trend of edge weights to illustrate how the number of calls, response time, or error rate has changed.

[0144] By intuitively displaying the nodes and call relationships in the exception subgraph, users can quickly understand the dependency structure and potential problems in the microservice system. Combined with interactive visualization tools, users can deeply analyze the exception situation and take timely measures to restore system stability. This display method not only improves the efficiency of anomaly detection, but also provides strong support for system optimization and maintenance.

[0145] The above steps, through sliding window and directed graph technology, accurately capture the call relationship and dependency changes between services in the microservice architecture. Combined with the similarity calculation of edge weights (such as number of calls, response time, error rate), it can accurately detect abnormal call behavior, not just simple changes in dependencies, thereby reducing false positives and improving the accuracy of anomaly detection.

[0146] Using sliding window technology, the solution can update and monitor the dependencies between services in the system in real time. Over time, the sliding window can capture the dynamic changes of the system and ensure the timeliness and accuracy of the monitoring results. This dynamic monitoring method adapts to the elasticity and variability of the microservice architecture and can detect potential abnormalities in a timely manner.

[0147] By splitting a complex directed graph into multiple subgraphs and performing independent similarity checks on each subgraph, the solution effectively simplifies the analysis of complex dependencies. Modular subgraph analysis not only helps to quickly locate abnormal services, but also limits the scope of the fault to a local area, reducing the impact on the overall system.

[0148] The combination of sliding window technology and similar subgraph detection can not only be used for short-term anomaly detection, but also for trend analysis through long-term data accumulation. The operation and maintenance team can use these trend data to optimize the system, identify long-standing performance problems or potential bottlenecks, and further improve the overall performance and stability of the system.

[0149] On the other hand, the present invention also provides a monitoring system for abnormal operation of a microservice architecture, comprising the following modules:

[0150] An acquisition module, used to acquire the logs of the gateway involved in the microservice by means of a sliding window;

[0151] A parsing module, used to parse the log extraction service call chain of the gateway;

[0152] A construction module, used to construct dependencies between services according to the service call chain;

[0153] A graph construction module is used to construct a directed graph according to the dependency relationship, wherein the nodes in the directed graph represent microservices, the edges represent the calling relationship between services, the direction of the edges points from the source service to the target service, and the attributes of the edges are the number of service calls, response time, and error rate;

[0154] A segmentation module, used for segmenting the directed graph into a plurality of subgraphs according to the attributes of the edges;

[0155] The detection module is used to detect whether there are similar subgraphs in the latest preset number of sliding windows for each subgraph. If not, there are call anomalies between the microservices in the corresponding subgraph.

[0156] Furthermore, the specific implementation methods of the above-mentioned system for monitoring abnormal operation of a microservice architecture are the same as a method for monitoring abnormal operation of a microservice architecture, and all further technical solutions in a method for monitoring abnormal operation of a microservice architecture are fully introduced into a system for monitoring abnormal operation of a microservice architecture.

[0157] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the relevant field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents.

Claims

1. A method for monitoring abnormal operation of a microservice architecture, characterized in that: The method comprises the following steps: Obtain the logs of the gateway involved in the microservice by means of a sliding window; Parsing the log extraction service call chain of the gateway; Building dependencies between services based on the service call chain; A directed graph is constructed according to the dependency relationship, wherein the nodes in the directed graph represent microservices, the edges represent the calling relationship between services, the direction of the edge points from the source service to the target service, and the attributes of the edge are the number of service calls, response time, and error rate; Splitting the directed graph into a plurality of subgraphs according to the attributes of the edges; For each subgraph, check whether there are similar subgraphs in the latest preset number of sliding windows. If not, there is a call exception between the microservices in the corresponding subgraph; The constraint condition for dividing the directed graph into multiple subgraphs according to the attributes of the edges is: There are strong dependencies between services within a subgraph; There are fewer service dependencies between subgraphs, which reduces cross-subgraph service calls; The step of dividing the directed graph into multiple subgraphs according to the attributes of the edges is as follows: for each edge e ij Calculate its weight w ij : Among them, α, β, and γ are adjustable weight coefficients used to balance the importance of different attributes, where i and j are node numbers and the number of calls ij Indicates the number of times node i calls node j and the response time ij Indicates the response time and error rate when node i calls node j ij represents the error rate when node i calls node j; According to the calculated weight value w ij , sort all edges from high to low; treat each node as a separate subgraph S i = {i}, there are n subgraphs in the system at the beginning, where n is the total number of nodes, i and j are node numbers; Starting from the edge with the highest weight, check each edge e in turn ij , if edge e ij If the connected nodes i and j belong to different subgraphs, the two subgraphs are merged. The new subgraph after merging contains all paths from i to j and retains all nodes on the path. The merging operation continues until the number of subgraphs reaches the expected value or the edge weight across subgraphs is lower than a certain threshold. When all edges have been processed or the edge weight across subgraphs is lower than the preset threshold, the algorithm stops. At this time, the graph is divided into several subgraphs, and the node dependency within each subgraph is strong, while the dependency between subgraphs is weak. Methods for calculating edge weight similarity between two subgraphs include: For the current subgraph G t and the subgraph G of the previous sliding window t-k , calculate their similarity: where w t (e) and w t-k (e) represents the weight of the corresponding edge e in the current subgraph and the past subgraph respectively, and E is the common edge set in the two subgraphs.

2. According to claim 1, a method for monitoring abnormal operation of a microservice architecture is characterized in that: The log extraction service call chain for parsing the gateway specifically includes: Get the recorded log data from the API gateway; Filter the collected logs and retain information related to service calls; According to the request ID, the log records of the same request in different service nodes are associated together; by analyzing the associated log records, the calling order of the request between various service nodes is determined; Output the extracted service call chain in a structured form.

3. According to claim 1, a method for monitoring abnormal operation of a microservice architecture is characterized in that: The constructing of inter-service dependencies according to the service call chain includes: identifying all involved service nodes from the service call chain, each node representing an independent microservice; For each service call chain, analyze the call sequence and determine which services have direct call relationships. Accumulating and aggregating dependency relationships according to the calling relationships; Weights are assigned based on the call frequency, response time, and error rate as dependencies.

4. According to claim 1, a method for monitoring abnormal operation of a microservice architecture is characterized in that: The step of constructing a directed graph according to the dependency relationship comprises: Extract all microservices from service dependencies and create corresponding nodes; Create directed edges between nodes based on the order of calls in the service dependency relationship; Assign attributes to each edge, including the number of service calls, response time, and error rate.

5. The method for monitoring abnormal operation of a microservice architecture according to claim 1, characterized in that: The sliding window size is 10 minutes and the step size is 5 minutes.

6. A method for monitoring abnormal operation of a microservice architecture according to claim 1, characterized in that: After determining the subgraph where the service call exception occurs, the nodes in the subgraph and the call relationships are displayed to the user.

7. A monitoring system for abnormal operation of a microservice architecture, characterized in that: The system is used to execute the method according to any one of claims 1 to 6, and the system includes the following modules: An acquisition module, used to acquire the logs of the gateway involved in the microservice by means of a sliding window; A parsing module, used to parse the log extraction service call chain of the gateway; A construction module, used to construct dependencies between services according to the service call chain; A graph construction module is used to construct a directed graph according to the dependency relationship, wherein the nodes in the directed graph represent microservices, the edges represent the calling relationship between services, the direction of the edges points from the source service to the target service, and the attributes of the edges are the number of service calls, response time, and error rate; A segmentation module, used for segmenting the directed graph into a plurality of subgraphs according to the attributes of the edges; The detection module is used to detect whether there are similar subgraphs in the latest preset number of sliding windows for each subgraph. If not, there are call anomalies between the microservices in the corresponding subgraph.

Images