A fault locating method of microservice and a terminal

Abstract

The application discloses a micro-service fault positioning method and a terminal, uses a distributed call chain to track interface call conditions of the micro-service, and records return codes of the interfaces; when the return code of the tracked interface indicates that the return is unsuccessful, a node corresponding to the tracked interface is found through performance monitoring, and monitoring data under the node is recorded to a call chain corresponding to the tracked interface, so that fault positioning is performed based on the updated distributed call chain. Therefore, compared with a method of combining distributed link analysis and distributed log system analysis for summation analysis in the prior art, the distributed link analysis and performance monitoring are combined in the application, performance monitoring information of an abnormal interface in the call chain is further added, fault positioning can be quickly performed in this way, and manpower investment is reduced.

Description

Technical Field

[0001] This invention relates to the technical field of fault location, and in particular to a fault location method and terminal for microservices. Background Technology

[0002] Most server-side systems currently employ a microservice architecture. While this architecture significantly improves throughput and performance, the large number of microservice instances also increases system complexity and hinders troubleshooting efficiency. Therefore, to enhance troubleshooting efficiency in distributed scenarios, a distributed tracing system is typically deployed to analyze the entire request call chain.

[0003] However, current distributed link systems can only monitor the business layer. When encountering lower-level, encapsulated functions, they cannot be fully monitored. Therefore, in current distributed link problem analysis scenarios, it is found that a small part of the link cannot be located, such as message middleware links, underlying database links, or links of other low-level functions. The current approach can only combine distributed link analysis with distributed log system analysis for a comprehensive analysis of faults, which requires a significant manpower investment and is relatively inefficient. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a fault location method and terminal for microservices, which can quickly locate faults and reduce manpower input.

[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0006] A method for fault localization in microservices includes the following steps:

[0007] Use a distributed call chain to track the API calls of microservices and record the API return codes;

[0008] Determine whether the return code of the traced interface indicates that the return was unsuccessful. If so, find the node corresponding to the traced interface through performance monitoring, and record the monitoring data under the node into the call chain corresponding to the traced interface, so as to locate the fault based on the updated distributed call chain.

[0009] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows:

[0010] A fault location terminal for microservices includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of the aforementioned fault location method for microservices.

[0011] The beneficial effects of this invention are as follows: It uses a distributed call chain to track the interface calls of microservices and records the return codes of the interfaces. When the return code of the tracked interface indicates an unsuccessful return, performance monitoring is used to find the node corresponding to the tracked interface, and the monitoring data under that node is recorded in the call chain corresponding to the tracked interface. This allows for fault location based on the updated distributed call chain. Therefore, compared to the existing method of combining distributed link analysis and distributed log system analysis for comprehensive analysis, this invention combines distributed link analysis and performance monitoring, further adding performance monitoring information to abnormal interfaces in the call chain. This approach enables rapid fault location and reduces manpower investment. Attached Figure Description

[0012] Figure 1 This is a flowchart of a microservice fault location method according to an embodiment of the present invention;

[0013] Figure 2 This is a schematic diagram of a microservice fault location terminal according to an embodiment of the present invention;

[0014] Label Explanation:

[0015] 1. A fault location terminal for microservices; 2. Memory; 3. Processor. Detailed Implementation

[0016] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0017] Please refer to Figure 1 This invention provides a method for fault location in microservices, comprising the following steps:

[0018] Use a distributed call chain to track the API calls of microservices and record the API return codes;

[0019] Determine whether the return code of the traced interface indicates that the return was unsuccessful. If so, find the node corresponding to the traced interface through performance monitoring, and record the monitoring data under the node into the call chain corresponding to the traced interface, so as to locate the fault based on the updated distributed call chain.

[0020] As described above, the beneficial effects of this invention are as follows: It uses a distributed call chain to track the interface calls of microservices and records the return codes of the interfaces. When the return code of the tracked interface indicates an unsuccessful return, performance monitoring is used to find the node corresponding to the tracked interface, and the monitoring data under that node is recorded in the call chain corresponding to the tracked interface. This allows for fault location based on the updated distributed call chain. Therefore, compared to the existing method of combining distributed link analysis and distributed log system analysis for comprehensive analysis, this invention combines distributed link analysis and performance monitoring, further adding performance monitoring information to abnormal interfaces in the call chain. This approach enables rapid fault location and reduces manpower investment.

[0021] Furthermore, the step of finding the node corresponding to the tracked interface through performance monitoring includes, prior to:

[0022] Associate the interface call address with the distributed call chain, perform performance monitoring on the interface call address, and record the name and time consumption of each node in the distributed call chain call process.

[0023] As described above, by associating the interface call address with the distributed call chain, it becomes easier to map the performance monitoring results of the call address to the call chain later.

[0024] Furthermore, the node name includes the packet path;

[0025] The process of finding the node corresponding to the tracked interface through performance monitoring includes:

[0026] In each node of the recorded call process, find the node name corresponding to the packet path of the tracked interface to obtain the node corresponding to the tracked interface.

[0027] As described above, since the node name contains the packet path, the query can be performed directly by the node name when searching for the node corresponding to the tracked interface, thus improving the search efficiency.

[0028] Furthermore, determining whether the return code of the tracked interface indicates a failure includes:

[0029] The system continuously monitors the tracked interface within a preset time period. If the number of failed return codes recorded within the preset time period exceeds a preset proportion, it indicates that the return was unsuccessful.

[0030] As described above, the analysis of daily distributed link results will automatically activate additional monitoring software once the error rate reaches a certain level. This will reduce the number of cases marked as unsuccessful due to misjudgment and reduce unnecessary additional monitoring.

[0031] Furthermore, the monitoring data under the node is recorded into the call chain corresponding to the tracked interface, including:

[0032] Obtain the first call chain address corresponding to the tracked interface in the distributed call chain, and add the monitoring data under the node to the first call chain address.

[0033] As described above, when relevant personnel query the call chain information to analyze problems, they can directly link the call chain and the data after combining the node monitoring data, thereby quickly locating and analyzing the problem.

[0034] Please refer to Figure 2 Another embodiment of the present invention provides a fault location terminal for microservices, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps:

[0035] Use a distributed call chain to track the API calls of microservices and record the API return codes;

[0036] Determine whether the return code of the traced interface indicates that the return was unsuccessful. If so, find the node corresponding to the traced interface through performance monitoring, and record the monitoring data under the node into the call chain corresponding to the traced interface, so as to locate the fault based on the updated distributed call chain.

[0037] As described above, the beneficial effects of this invention are as follows: It uses a distributed call chain to track the interface calls of microservices and records the return codes of the interfaces. When the return code of the tracked interface indicates an unsuccessful return, performance monitoring is used to find the node corresponding to the tracked interface, and the monitoring data under that node is recorded in the call chain corresponding to the tracked interface. This allows for fault location based on the updated distributed call chain. Therefore, compared to the existing method of combining distributed link analysis and distributed log system analysis for comprehensive analysis, this invention combines distributed link analysis and performance monitoring, further adding performance monitoring information to abnormal interfaces in the call chain. This approach enables rapid fault location and reduces manpower investment.

[0038] Furthermore, the step of finding the node corresponding to the tracked interface through performance monitoring includes, prior to:

[0039] Associate the interface call address with the distributed call chain, perform performance monitoring on the interface call address, and record the name and time consumption of each node in the distributed call chain call process.

[0040] As described above, by associating the interface call address with the distributed call chain, it becomes easier to map the performance monitoring results of the call address to the call chain later.

[0041] Furthermore, the node name includes the packet path;

[0042] The process of finding the node corresponding to the tracked interface through performance monitoring includes:

[0043] In each node of the recorded call process, find the node name corresponding to the packet path of the tracked interface to obtain the node corresponding to the tracked interface.

[0044] As described above, since the node name contains the packet path, the query can be performed directly by the node name when searching for the node corresponding to the tracked interface, thus improving the search efficiency.

[0045] Furthermore, determining whether the return code of the tracked interface indicates a failure includes:

[0046] The system continuously monitors the tracked interface within a preset time period. If the number of failed return codes recorded within the preset time period exceeds a preset proportion, it indicates that the return was unsuccessful.

[0047] As described above, the analysis of daily distributed link results will automatically activate additional monitoring software once the error rate reaches a certain level. This will reduce the number of cases marked as unsuccessful due to misjudgment and reduce unnecessary additional monitoring.

[0048] Furthermore, the monitoring data under the node is recorded into the call chain corresponding to the tracked interface, including:

[0049] Obtain the first call chain address corresponding to the tracked interface in the distributed call chain, and add the monitoring data under the node to the first call chain address.

[0050] As described above, when relevant personnel query the call chain information to analyze problems, they can directly link the call chain and the data after combining the node monitoring data, thereby quickly locating and analyzing the problem.

[0051] The fault location method and terminal for microservices described above are applicable to rapid fault location in microservices, reducing manpower input. The following is a detailed description of specific implementation methods:

[0052] Example 1

[0053] Please refer to Figure 1 A method for fault localization in microservices, comprising the following steps:

[0054] S1. Use a distributed call chain to track the API calls of the microservice and record the API return codes.

[0055] Specifically, once the application starts, the distributed call chain will automatically track and monitor the call status of the interfaces, and it will also record the return code of each interface.

[0056] In this embodiment, assuming that the requested interface address is / test-api / jprofiler / test, the distributed call chain system will record the call chain of this interface to various microservices, as well as some code call chains at higher levels. The main information recorded includes: client → gateway → microservice A → internal method of microservice A → microservice B → internal method of microservice B, etc.

[0057] Within microservice A, methods only reach the upper level of the method. For example, in the following code, only the "something" level is monitored, and the distributed call chain of statements inside "stmt.executeQuery" cannot be obtained.

[0058] public String test()throws SQLException{

[0059] / / Other business code

[0060] something;

[0061] / / SQL operations

[0062] stmt=conn.createStatement();

[0063] ResultSet rs=stmt.executeQuery("SELECT*FROM table name");

[0064] return "result";

[0065] }

[0066] S2. Determine whether the return code of the traced interface indicates that the return was unsuccessful. If so, find the node corresponding to the traced interface through performance monitoring, and record the monitoring data under the node into the call chain corresponding to the traced interface, so as to locate the fault based on the updated distributed call chain.

[0067] S21. Continuously monitor the tracked interface within a preset time period. If the number of failed return codes recorded within the preset time period exceeds a preset proportion, it indicates that the return was unsuccessful, and step S22 is executed.

[0068] Specifically, there is a monitoring system that monitors the interface return codes over a period of time. When the proportion of failed return codes reaches a certain level, say 5%, step S22 is executed.

[0069] S22. Associate the interface call address with the distributed call chain, perform performance monitoring on the interface call address, and record the name and time consumption of each node in the call process of the distributed call chain, wherein the node name contains the package path.

[0070] Specifically, an additional flame graph or JProfiler monitoring software needs to be deployed for performance monitoring. In this embodiment, JProfiler monitoring software is deployed. In this step, the JProfiler monitoring software is automatically turned on to begin additional performance data monitoring.

[0071] The JProfiler monitoring software can obtain the HTTP call to the interface ( / test-api / jprofiler / test), the time it takes, and the names and times of subsequent nodes. Therefore, performance monitoring can reveal the call chain and time of each code method within a specific interface.

[0072] At this point, based on the HTTP call, the URL in the HTTP call can be associated with the address in the call chain, and the names of each node in JProfiler and the CPU time slice consumed by each node can be recorded. The node name includes the package path.

[0073] In this embodiment, each microservice in JProfiler is monitored separately, and the nodes that call methods in each microservice are recorded. When searching for node names with the same package path later, the corresponding microservice can be found first, and then the node name can be searched to improve search efficiency.

[0074] S23. In each node of the recorded call process, find the node name corresponding to the packet path of the tracked interface to obtain the node corresponding to the tracked interface; obtain the first call chain address corresponding to the tracked interface in the distributed call chain, and add the monitoring data under the node to the first call chain address.

[0075] Specifically, among the nodes in the recorded call process, there is a node name that corresponds to the package path of the stmt.executeQuery statement. Then, the node name and time slice data under that node in JProfiler can be recorded under that data in the call chain.

[0076] For example, suppose the request in the entire call chain is A, which includes sub-call chains a, b, c, and d. Sub-call chain b can only obtain information at the level of toolJProfilerController.test. Therefore, it is necessary to record all nodes below this level of information in JProfiler under sub-call chain b. In this way, the missing underlying data information in the distributed call chain can be automatically supplemented.

[0077] Subsequently, when relevant personnel query the call chain information to analyze the problem, they can directly link the call chain and the data combined with JProfiler to quickly locate and analyze the problem.

[0078] Because in existing distributed link systems, such as message middleware links, underlying databases, or other underlying functional links, it is impossible to obtain the data. Current methods can only combine distributed link analysis with distributed log system analysis for comprehensive problem analysis, which requires significant manpower and is relatively inefficient. However, the fault location method in this embodiment can quickly correlate the call chain with monitoring data obtained from a combination of call profiles when a certain range of fault scenarios occur, enabling rapid problem analysis and fault location, and improving the overall efficiency of problem repair.

[0079] Example 2

[0080] Please refer to Figure 2 A microservice fault location terminal 1 includes a memory 2, a processor 3, and a computer program stored on the memory 2 and executable on the processor 3. When the processor 3 executes the computer program, it implements the various steps of a microservice fault location method according to Embodiment 1.

[0081] In summary, the present invention provides a microservice fault location method and terminal that uses a distributed call chain to track the interface calls of microservices and records the return codes of the interfaces. When the return code of the tracked interface indicates an unsuccessful return, performance monitoring is used to find the node corresponding to the tracked interface, and the monitoring data under that node is recorded in the call chain corresponding to the tracked interface, so as to locate the fault based on the updated distributed call chain. Therefore, compared with the existing technology that combines distributed link analysis and distributed log system analysis for summative analysis, the present invention combines distributed link analysis and performance monitoring, and further adds performance monitoring information to the abnormal interfaces in the call chain. This method can quickly locate faults and reduce manpower input.

[0082] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for fault location in microservices, characterized in that, Including the following steps: Use a distributed call chain to track the API calls of microservices and record the API return codes; Determine whether the return code of the tracked interface indicates that the return was unsuccessful. If so, find the node corresponding to the tracked interface through performance monitoring, and record the monitoring data under the node into the call chain corresponding to the tracked interface, so as to locate the fault based on the updated distributed call chain. The step of finding the node corresponding to the tracked interface through performance monitoring includes: Associate the interface call address with the distributed call chain, perform performance monitoring on the interface call address, and record the name and time consumption of each node in the call process of the distributed call chain; The node name contains the packet path; The process of finding the node corresponding to the tracked interface through performance monitoring includes: In each node of the recorded call process, find the node name corresponding to the packet path of the tracked interface to obtain the node corresponding to the tracked interface; The determination of whether the return code of the tracked interface indicates a failure includes: The system continuously monitors the tracked interface within a preset time period. If the number of failed return codes recorded within the preset time period exceeds a preset proportion, it indicates that the return was unsuccessful.

2. The microservice fault location method according to claim 1, characterized in that, Record the monitoring data under the node into the call chain corresponding to the tracked interface, including: Obtain the first call chain address corresponding to the tracked interface in the distributed call chain, and add the monitoring data under the node to the first call chain address.

3. A fault location terminal for microservices, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it performs the following steps: Use a distributed call chain to track the API calls of microservices and record the API return codes; Determine whether the return code of the tracked interface indicates that the return was unsuccessful. If so, find the node corresponding to the tracked interface through performance monitoring, and record the monitoring data under the node into the call chain corresponding to the tracked interface, so as to locate the fault based on the updated distributed call chain. The step of finding the node corresponding to the tracked interface through performance monitoring includes: Associate the interface call address with the distributed call chain, perform performance monitoring on the interface call address, and record the name and time consumption of each node in the call process of the distributed call chain; The node name contains the packet path; The process of finding the node corresponding to the tracked interface through performance monitoring includes: In each node of the recorded call process, find the node name corresponding to the packet path of the tracked interface to obtain the node corresponding to the tracked interface; The determination of whether the return code of the tracked interface indicates a failure includes: The system continuously monitors the tracked interface within a preset time period. If the number of failed return codes recorded within the preset time period exceeds a preset proportion, it indicates that the return was unsuccessful.

4. A microservice fault location terminal according to claim 3, characterized in that, Record the monitoring data under the node into the call chain corresponding to the tracked interface, including: Obtain the first call chain address corresponding to the tracked interface in the distributed call chain, and add the monitoring data under the node to the first call chain address.

Images