API calling monitoring method and device, computer equipment and storage medium

Abstract

The invention discloses an API call monitoring method and device, computer equipment and a storage medium, and the method comprises the steps: adding a custom annotation to form a monitoring strategy; annotation information in the monitoring strategy is acquired; triggering an interceptor to capture HTTP request information and HTTP response information; obtaining parameter annotation configuration matched with the current HTTP request information; constructing an information log object; receiving HTTP response data returned by the external service; analyzing a service state code in the HTTP response data to obtain service state information; integrating the HTTP response information, the information log object and the service state information to form a complete log object; and asynchronously sending the complete log object to a log storage service to form stored log data. By implementing the method disclosed by the invention, non-intrusive API call monitoring with flexible configuration, deep monitoring and efficient performance can be realized, and the method has important practical application value and wide application prospect.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of API call monitoring, in particular to an API call monitoring method and device, a computer device and a storage medium. BACKGROUND

[0002] With the wide application of distributed systems and microservice architectures, inter-system communication through APIs has become a core component of modern software architectures. In complex distributed systems, the calling relationship between services is complex, and a business request may involve mutual calling between multiple services. In order to ensure stable operation of the system, timely discovery and positioning of problems, effective monitoring of the API calling process becomes crucial.

[0003] However, the existing API monitoring solutions have many defects, mainly in the following aspects: Strong invasiveness: traditional hard coding requires manually adding monitoring logic in business code, which seriously invades business logic, increases code complexity and maintenance cost. This way tightly couples business code and monitoring code, not only reducing code readability, but also making subsequent maintenance and upgrading more difficult; Non-uniform monitoring granularity: different developers may use different monitoring methods and standards, resulting in non-uniform monitoring data formats, making it difficult to centrally analyze and process. This inconsistency makes data integration and analysis complex, reducing the overall effectiveness of the monitoring system; Inflexible configuration: existing monitoring solutions are often difficult to configure flexibly, and cannot dynamically adjust monitoring strategies according to different interfaces or business scenarios. This makes it difficult for the monitoring system to achieve accurate monitoring when faced with diverse business requirements, and unable to meet the monitoring requirements in different scenarios; Limited monitoring scope: existing solutions usually only focus on HTTP layer success or failure, lacking deep monitoring of business layer status codes. This limited monitoring scope makes it difficult to fully understand the real situation of API calling, and makes it difficult to discover potential business problems; Lack of context information: in distributed systems, it is difficult to effectively pass and associate request context information, resulting in a lack of complete calling chain information in monitoring data. This makes it difficult to quickly locate the root cause of the problem when problems occur, increasing the difficulty of troubleshooting.

[0004] In summary, the existing API monitoring solutions have obvious shortcomings in invasiveness, monitoring granularity, configuration flexibility, monitoring scope, and context information transmission, and are difficult to meet the high requirements of API call monitoring in modern distributed systems and microservice architectures. Therefore, a new monitoring solution is needed to effectively solve the above problems and achieve efficient, flexible and comprehensive monitoring of the API calling process. SUMMARY

[0005] The present application aims to overcome the defects of the prior art, and provide an API call monitoring method, device, computer equipment and storage medium.

[0006] To achieve the above object, the present application adopts the following technical solutions: The API call monitoring method comprises: adding a custom annotation to form a monitoring strategy; When a business method is called, annotation information in the monitoring strategy is obtained; The annotation information is stored in thread local storage; When an HTTP call to an external service is initiated inside the business method, an interceptor captures HTTP request information and HTTP response information; The interceptor obtains parameter annotation configuration matching the current HTTP request information from the thread local storage; According to the matched parameter annotation configuration, an information log object is constructed; The normal HTTP request sending process is continued, and HTTP response data returned by the external service is received; The business status code in the HTTP response data is parsed to obtain business status information; The HTTP response information, the information log object and the business status information are integrated to form a complete log object; The complete log object is sent to a log storage service asynchronously to form stored log data.

[0007] The present application also provides an API call monitoring device, comprising: An adding unit is configured to add a custom annotation to form a monitoring strategy; A call obtaining unit is configured to obtain annotation information in the monitoring strategy when a business method is called; A storage unit is configured to store the annotation information in thread local storage; A call triggering unit is configured to trigger an interceptor to capture HTTP request information and HTTP response information when an HTTP call to an external service is initiated inside the business method; A matching obtaining unit is configured to enable the interceptor to obtain parameter annotation configuration matching the current HTTP request information from the thread local storage; A constructing unit is configured to construct an information log object according to the matched parameter annotation configuration; An executing and receiving unit is configured to continue the normal HTTP request sending process and receive HTTP response data returned by the external service; The parsing unit is used for parsing the service status code in the HTTP response data to obtain service status information. The integration unit is used for integrating the HTTP response information, the information log object and the service status information to form a complete log object. The sending unit is used for asynchronously sending the complete log object to a log storage service to form storage log data.

[0008] The application further provides a computer device, which comprises a memory and a processor, the memory stores a computer program, and the processor realizes the method when executing the computer program.

[0009] The application further provides a storage medium, which stores a computer program, and the computer program realizes the method when being executed by a processor.

[0010] Compared with the prior art, the beneficial effects of the present application are: by adding custom annotations to the business method to form a monitoring strategy, the developer does not need to manually insert monitoring logic in the business code, avoiding the intrusion of traditional hard coding on the business logic, this non-intrusive design completely decouples the business code from the monitoring logic, significantly reducing the code complexity and maintenance cost, and improving the readability and maintainability of the code; in addition, the custom annotations allow the developer to flexibly configure the monitoring strategy according to different business needs, including the monitoring range, content and business status code checking rules, etc., this flexible configuration method can meet the needs of various business scenarios, and at the same time, through unified annotation configuration and log structure, the problem of non-uniform monitoring granularity in the prior art is solved, ensuring the consistency of the monitoring data format, facilitating subsequent centralized analysis and processing; in addition, by using the thread local storage mechanism, the annotation information is stored in the current thread, ensuring that the monitoring configuration information can be efficiently transmitted between different levels during the execution of the business method, this mechanism effectively solves the problem of context information transmission and association in distributed systems, even in complex call chains, it can ensure the integrity and association of the monitoring data, providing a solid foundation for call chain tracking; in addition, by intercepting HTTP request and response information and obtaining the matching parameter annotation configuration from the thread local storage, not only the status code of the HTTP layer is monitored, but also the business status code in the HTTP response data is parsed, realizing deep monitoring of the business layer status, this multi-dimensional monitoring method can more comprehensively reflect the real situation of API calling, helping developers and operation and maintenance personnel to more accurately identify potential problems; during monitoring, the complete log object is sent to the log storage service in an asynchronous manner, avoiding the blocking of the main business process caused by synchronous log recording, thereby significantly reducing the impact of monitoring on business performance; at the same time, the thread local storage mechanism reduces the overhead of cross-thread data transmission, further optimizing the system performance and ensuring the efficient operation of the monitoring function; in addition, from the initiation of the HTTP request, the interception of the information, to the construction and asynchronous sending of the log object, the entire process forms a complete call link record, this complete recording method enables the quick positioning of the fault point when problems occur, helping operation and maintenance personnel to quickly troubleshoot problems, and also provides detailed data support for system performance analysis and optimization.

[0011] The present application will be further described below in conjunction with the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0012] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and those skilled in the art can also obtain other drawings based on these drawings without creative labor.

[0013] Figure 1 An application scenario diagram of the API call monitoring method provided by the embodiment of the present application is shown. Figure 2 A flow diagram of the API call monitoring method provided by the embodiment of the present application is shown. Figure 3 A schematic block diagram of the API call monitoring device provided by the embodiment of the present application is shown. Figure 4 A schematic block diagram of the computer device provided by the embodiment of the present application is shown. DETAILED DESCRIPTION

[0014] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.

[0015] It should be understood that, when used in the specification and the appended claims, the terms “comprise” and “include” indicate the presence of the described features, integers, steps, operations, elements, and / or components, but do not exclude one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0016] It should be further understood that, when used in the specification and the appended claims, the term “and / or” refers to any combination of one or more of the associated listed items and all possible combinations thereof.

[0017] Please refer to Figure 1 and Figure 2 , Figure 1 An application scenario diagram of the API call monitoring method provided by the embodiment of the present application is shown. Figure 2 A schematic flow diagram of the API call monitoring method provided by the embodiment of the present application is shown. The API call monitoring method is applied to a server, which performs data interaction with a terminal. Through the innovative annotation and interceptor mechanism, the API call monitoring method realizes non-invasive, flexible configuration, deep monitoring, and high-efficiency performance of API call monitoring. Not only does the API call monitoring method solve many problems existing in the prior art, but also it exhibits significant advantages in development efficiency, operation and maintenance management, system stability, and the like, and has important practical application value and wide application prospect.

[0018] Figure 2 A flow diagram of the API call monitoring method provided by the embodiment of the present application is shown. As shown in Figure 2As shown, the method includes the following steps S110 to S200.

[0019] S110, adding a custom annotation to form a monitoring strategy; Specifically, the developer adds a custom annotation (such as @ApiInvokeLog) on the business method that needs to be monitored, and configures specific monitoring parameters (such as @ApiLogParam) through the properties of the annotation. These annotations define the scope of monitoring, the specific content of monitoring (such as request headers, parameters, etc.), and the checking rules of business status codes, etc.

[0020] That is, monitoring is achieved through annotations, without the need to modify the business code logic, completely decoupling the monitoring logic from the business logic, and avoiding the intrusion of traditional hardcoding methods on the business code. The developer can flexibly configure the monitoring strategy according to different business needs, support different monitoring parameters for different URL paths and different business scenarios, and meet the diversified monitoring needs.

[0021] In an embodiment, the adding of the custom annotation to form the monitoring strategy includes: adding an @ApiInvokeLog annotation on the API call method that needs to be monitored; configuring one or more @ApiLogParam annotation instances through the field value properties of the @ApiInvokeLog annotation to define the monitoring strategy for different URL paths, including log content, URL matching rules, and business status code checking parameters.

[0022] Specifically, first, two core annotations are defined: @ApiInvokeLog and @ApiLogParam. The @ApiInvokeLog annotation is used to mark the API call method that needs to be monitored, serving as the entry point of monitoring; the @ApiLogParam annotation is used to configure specific monitoring parameters, including log content, URL matching rules, business status code checking parameters, etc. The developer adds the @ApiInvokeLog annotation on the business method that needs to be monitored, and configures one or more @ApiLogParam annotation instances through the field value properties thereof. Each @ApiLogParam instance defines the monitoring strategy for a specific URL path.

[0023] When the business method is called, the @ApiInvokeLog annotation information on the monitoring strategy is obtained through the AOP or interceptor mechanism. The @ApiLogParam configuration in the annotation is parsed, and the URL matching rules, log content, business status code field name, and success status code of each configuration item are extracted.

[0024] That is, the developer only needs to add annotations on the business method without modifying the business code logic, completely decoupling the monitoring logic from the business logic, avoiding the intrusion of traditional hardcoding methods on business code, reducing code complexity and maintenance cost, and improving code readability and maintainability. In addition, by configuring multiple @ApiLogParam instances through the field value attribute of the @ApiInvokeLog annotation, the monitoring strategy for different URL paths is defined, supporting flexible configuration of monitoring parameters for different interfaces or business scenarios, including log content, URL matching rules, business status code field name, and success status code. This flexibility enables the monitoring system to adapt to diverse business needs, avoiding the problem of inconsistent monitoring granularity.

[0025] S120, when the business method is called, the annotation information in the monitoring strategy is obtained; Specifically, when the business method is called, the @ApiInvokeLog annotation information defined in the monitoring strategy is automatically obtained by the AOP (Aspect-Oriented Programming) or interceptor mechanism, including the monitoring parameters configured in the annotation.

[0026] That is, the annotation information is automatically obtained before the execution of the business method, without the need to manually trigger the monitoring logic, simplifying the monitoring startup process, ensuring that the monitoring logic is executed based on the annotation configuration preset by the developer, and avoiding misuse or abuse of the monitoring logic.

[0027] In an embodiment, when the business method is called, the annotation information in the monitoring strategy is obtained, including: When the business method is called, the monitoring strategy is obtained through the method aspect or interceptor in the aspect-oriented programming technology; Parse the specific parameter configuration in the monitoring strategy to obtain the annotation information.

[0028] Specifically, an aspect-oriented programming (AOP) framework such as Spring AOP is introduced into the system. AOP allows developers to separate cross-cutting concerns (such as monitoring logic) from business logic, and achieves method interception by defining pointcuts and advice. Define an aspect class (Aspect), and define a pointcut in the aspect class to match all methods with the @ApiInvokeLog annotation.

[0029] In the aspect class, a notification (Advice) is defined through the @Before or @Around annotation to intercept method calls before the execution of the business method. In the notification method, the @ApiInvokeLog annotation instance on the method is obtained through reflection, thereby obtaining the monitoring strategy.

[0030] The field values in the @ApiInvokeLog annotation are parsed by reflection technology, and the @ApiLogParam annotation instance array is extracted. The @ApiLogParam array is traversed to parse the specific parameter configuration of each instance, including URL matching rules, log content templates, business status code field names, and success status code values. The parsed annotation information is stored in thread local storage (ThreadLocal) or other context management tools for use in subsequent HTTP request interceptors.

[0031] That is, through AOP technology, the monitoring logic is automatically triggered when the business method is called, without manually inserting monitoring logic into the business code. The start of the monitoring logic is completely automated, simplifying the development process and reducing the development workload. In addition, by parsing the specific parameter configuration in the annotation, the monitoring logic is executed based on the configuration preset by the developer. The monitoring logic can be accurately executed according to the annotation configuration, avoiding misuse or abuse of the monitoring logic and ensuring the accuracy and consistency of the monitoring. In addition, using AOP technology to separate the monitoring logic from the business logic, the monitoring logic is implemented through aspects, and the business logic code does not need to be modified, completely decoupling the monitoring logic from the business logic. The business code remains simple and focused, reducing code complexity and maintenance costs, and improving code readability and maintainability.

[0032] S130, storing the annotation information into thread local storage; Specifically, the annotation information obtained is stored in the context of the current thread using ThreadLocal. ThreadLocal is a thread-local storage mechanism that ensures that monitoring configuration information can be accessed across levels within the same thread.

[0033] That is, in a complex call chain, it ensures that monitoring configuration information can be efficiently passed between different levels, solving the problem of context information transmission and association in distributed systems. ThreadLocal ensures data isolation within a thread, avoiding data conflicts in a multi-threaded environment.

[0034] S140, when the business method initiates an HTTP call to an external service, an interceptor is triggered to capture HTTP request information and HTTP response information; Specifically, when the business method initiates an HTTP request, the HTTP request and response information is captured by the configured HTTP client interceptor (such as ClientHttpRequestInterceptor in Spring). The interceptor will intercept the sending of the request and the receiving of the response.

[0035] That is, capture the detailed information of HTTP request and response, including request header, request body, response header, response body, etc., to realize comprehensive monitoring of API calls. At the same time, monitor in the real-time process of HTTP request sending and response receiving to ensure the timeliness and accuracy of monitoring data.

[0036] In an embodiment, when the business method internally initiates an HTTP call to an external service, the interceptor triggers to capture HTTP request information and HTTP response information, including: When the business method internally initiates an HTTP call to an external service, the HTTP client interceptor is triggered; The interceptor captures HTTP request information, including request URL, request method, request header, and request parameters; The interceptor captures HTTP response information returned by the external service, including status code, response header, and response body.

[0037] Specifically, an HTTP client interceptor is defined in the system to capture HTTP request and response information. The interceptor can be implemented based on commonly used HTTP client libraries (such as Apache HttpClient, OkHttp, or Spring's RestTemplate). For example, if Spring's RestTemplate is used, the interceptor can be defined by implementing the ClientHttpRequestInterceptor interface.

[0038] Register the defined interceptor in the HTTP client instance to ensure that the interceptor can be triggered every time an HTTP request is initiated. Implement the logic of capturing HTTP request and response information in the interceptor. The interceptor needs to capture request information before the request is sent, and capture response information after the response is received.

[0039] In the interceptor, the annotation configuration information (such as the configuration in @ApiLogParam) stored in the thread local storage (ThreadLocal) is obtained through a utility class, and the captured request and response information is processed according to these configuration information.

[0040] That is, the interceptor captures the detailed information of HTTP requests and responses, provides comprehensive monitoring of the HTTP communication process, ensures the integrity and accuracy of the monitoring data, and provides sufficient data support for subsequent analysis and problem troubleshooting. In addition, the interceptor captures information in the real-time process of HTTP request sending and response receiving, which can ensure the timeliness and accuracy of the monitoring data, and can record the details of each HTTP call in real time, which facilitates quick problem positioning. In addition, the interceptor works in the execution chain of the HTTP client, captures information and continues to execute the normal HTTP request sending and response receiving process, completely decouples the monitoring logic from the business logic, ensures that the monitoring process does not affect the normal business process, and ensures the high-performance operation of the system.

[0041] S150, the interceptor obtains the parameter annotation configuration matched with the current HTTP request information from the thread local storage; Specifically, the interceptor obtains the @ApiLogParam annotation configuration matched with the current HTTP request from ThreadLocal through the utility class. The utility class matches the corresponding annotation configuration according to the request URL, method and other information.

[0042] That is, the monitoring parameters are dynamically matched according to the context of the current request, ensuring the flexibility and accuracy of the monitoring logic, ensuring that the monitoring logic is always executed based on the annotation configuration preset by the developer, and avoiding misuse or abuse of the monitoring logic.

[0043] S160, constructing an information log object according to the matched parameter annotation configuration; Specifically, according to the matched @ApiLogParam annotation configuration, the interceptor constructs a log object containing request URL, method, request header, request parameter and other information. The structure and content of the log object are dynamically generated according to the annotation configuration.

[0044] That is, the structured log object is generated, which is convenient for subsequent storage and analysis. At the same time, the log content is dynamically generated according to the annotation configuration, which supports recording information of different dimensions and meets the diversified monitoring needs.

[0045] S170, continue to execute the normal HTTP request sending process and receive the HTTP response data returned by the external service; Specifically, after the interceptor captures the request and response information, it continues to execute the normal HTTP request sending process and receives the HTTP response data returned by the external service.

[0046] That is, the monitoring logic is decoupled from the business logic, ensuring that the monitoring process does not affect the normal business process, ensuring the integrity of the HTTP request and response data, and providing an accurate data basis for subsequent monitoring analysis.

[0047] S180, parsing the business status code in the HTTP response data to obtain business status information; Specifically, the tool class is used to parse the business status code in the HTTP response data to determine the business level status of API calling. The tool class parses according to the business status code field name and the success status code value in the annotation configuration.

[0048] That is, not only the HTTP level status code is monitored, but also the status code in the business response is parsed to realize the deep monitoring of the business level. Meanwhile, the success or failure of the business calling is accurately determined through the preset business status code field name and the success status code value, avoiding the one-sided judgment depending on the HTTP status code.

[0049] In an embodiment, the parsing of the business status code in the HTTP response data to obtain the business status information comprises: parsing the business status code in the HTTP response data to determine the business status of API calling; extracting information of the business status of API calling to obtain the business status information.

[0050] Specifically, a tool class (such as BusinessStatusParser) is defined in the system to parse the business status code in the HTTP response data. The tool class extracts the business status information from the HTTP response body according to the preset business status code field name and the success status code value.

[0051] In the HTTP client interceptor, the BusinessStatusParser tool class is called to parse the business status code in the HTTP response data. The interceptor obtains the previously stored annotation configuration information (such as the business status code field name and the success status code value in the @ApiLogParam) from the thread local storage (ThreadLocal), and uses the configuration information for parsing and extraction to obtain the business status information.

[0052] That is, by parsing the business status code in the HTTP response data, the business status of API call is determined, not only monitoring the success or failure of the HTTP layer, but also monitoring the status of the business layer in depth, providing a more comprehensive monitoring perspective. This deep monitoring can more accurately identify the real status of business call and avoid one-sided judgment relying only on HTTP status code. In addition, by annotating the business status code field name and success status code value, monitoring strategies can be flexibly configured for different business scenarios. Developers can flexibly adjust the parsing rules of business status code according to different business needs without modifying the business code, greatly improving the flexibility and adaptability of the monitoring system. In addition, by parsing the business status code field in the HTTP response body and determining the business status according to the preset success status code value, the success or failure of the business call can be accurately determined, providing accurate data support for subsequent fault troubleshooting and performance analysis. This accurate business status determination helps quickly locate problems and reduces false positives.

[0053] S190, integrating the HTTP response information, the information log object and the business status information to form a complete log object; Specifically, the captured HTTP response information, the information log object and the parsed business status information are integrated into a complete log object. The log object contains detailed information of request and response, business status, time consumption and other multi-dimensional data.

[0054] That is, by integrating multi-dimensional data to form a complete log object, a comprehensive monitoring perspective is provided to ensure the consistency and integrity of log data, facilitating subsequent analysis and processing.

[0055] In an embodiment, the integration of the HTTP response information, the information log object and the business status information to form a complete log object includes: The HTTP response information, the information log object and the business status information are integrated, and response time information and time consumption information are added to form a complete log object.

[0056] Specifically, a log object class (such as ApiCallLog) is defined to store complete log information. The log object should include fields such as HTTP response information, business status information, request information, response time and time consumption information. The start time of the request is recorded before the business method calls the HTTP client, which can be implemented in AOP aspect or interceptor.

[0057] In the HTTP client interceptor, after capturing the HTTP request and response information, the previously stored annotation configuration information is obtained from the ThreadLocal, and the business status code is parsed. In the interceptor, the time consumption of the request is calculated, and all information is integrated into a log object to form a complete log object.

[0058] That is, by integrating the HTTP response information, business status information, request information, response time, and time consumption information into a complete log object, comprehensive monitoring data is provided, including not only HTTP and business level status, but also detailed request information and performance indicators such as response time and time consumption. This complete log record provides sufficient data support for subsequent analysis and problem troubleshooting. In addition, by adding response time and time consumption information in the log object, the performance of API calls can be monitored in real time, helping operations personnel identify performance bottlenecks and abnormalities. Response time and time consumption information provide an important basis for system performance optimization.

[0059] S200, asynchronously send the complete log object to the log storage service to form stored log data.

[0060] Specifically, the complete log object is asynchronously sent to the log storage service (such as Elasticsearch, Kafka, etc.) through a utility class. The asynchronous processing mechanism ensures that the sending of monitoring logs does not block the main business process.

[0061] That is, the asynchronous processing mechanism avoids the impact of sending monitoring logs on the main business process, ensuring the high-performance operation of the system. At the same time, storing log data into a professional storage service facilitates subsequent log analysis, visualization, and alarm.

[0062] In an embodiment, after the complete log object is asynchronously sent to the log storage service to form stored log data, it further includes: Analyzing the stored log data to generate a monitoring report and displaying the monitoring report through a visualization tool.

[0063] Specifically, a log storage service (such as LogStorageService) is implemented in the system, which is responsible for asynchronously sending the complete log object to the log storage system (such as Elasticsearch, Kafka, database, etc.). Thread pool or message queue is used to realize asynchronous sending, ensuring that log sending operations do not block the main business process. At the same time, in the log storage system, a reasonable index and storage structure are designed to efficiently store and query log data. For example, in Elasticsearch, an index can be created according to the timestamp, API path, etc.

[0064] Use data analysis tools (such as Kibana of Elasticsearch, Grafana or custom data analysis services) to analyze the stored log data, then define analysis rules and query statements, and generate monitoring reports. For example, statistics of API success rate, average response time, error rate and other indicators. Finally, generate monitoring reports according to the analysis results, which can include charts, tables and other forms to show the performance and health status of the API.

[0065] Use visualization tools (such as Kibana, Grafana) to display monitoring reports to operation and maintenance personnel or developers.

[0066] That is, through multi-dimensional analysis of stored log data, detailed monitoring reports are generated, providing a comprehensive view of system performance and health status, supporting analysis of problems from multiple angles such as average response time, success rate, error rate, etc. This multi-dimensional analysis helps operation and maintenance personnel to accurately locate problems. In addition, through the real-time display of monitoring reports by visualization tools, operation and maintenance personnel can monitor the running state of the system in real time and quickly discover potential problems.

[0067] The API call monitoring method described above forms a monitoring strategy by adding a custom annotation on the business method. The developer does not need to manually insert monitoring logic in the business code, avoiding the intrusion of traditional hardcoding into the business logic. This non-intrusive design completely decouples the business code from the monitoring logic, significantly reducing the code complexity and maintenance cost, while improving the readability and maintainability of the code. In addition, the custom annotation allows the developer to flexibly configure the monitoring strategy according to different business needs, including the monitoring scope, content, and business status code checking rules. This flexible configuration method can meet the needs of various business scenarios, while solving the problem of inconsistent monitoring granularity in the prior art, ensuring the consistency of the monitoring data format, and facilitating subsequent centralized analysis and processing. In addition, the annotation information is stored in the current thread using the thread local storage mechanism, ensuring that the monitoring configuration information can be efficiently transmitted between different levels during the execution of the business method. This mechanism effectively solves the problem of context information transmission and association in distributed systems, ensuring the integrity and association of the monitoring data, and providing a solid foundation for call chain tracking. In addition, the interceptor captures HTTP request and response information, and obtains the matching parameter annotation configuration from the thread local storage. Not only the status code of the HTTP layer is monitored, but also the business status code in the HTTP response data is parsed, realizing deep monitoring of the business layer status. This multi-dimensional monitoring method can more comprehensively reflect the real situation of API calls, helping developers and operation and maintenance personnel to accurately identify potential problems. During the monitoring process, the complete log object is sent to the log storage service in an asynchronous manner, avoiding the blocking of the main business process caused by synchronous log recording, thereby significantly reducing the impact of monitoring on business performance. At the same time, the thread local storage mechanism reduces the overhead of cross-thread data transmission, further optimizing the system performance and ensuring the efficient operation of the monitoring function. In addition, from the initiation of the HTTP request to the capture of information by the interceptor, to the construction and asynchronous sending of the log object, the entire process forms a complete call link record. This complete recording method enables quick fault location when problems occur, helping operation and maintenance personnel to quickly troubleshoot problems, and also provides detailed data support for system performance analysis and optimization.

[0068] Figure 3 is a schematic block diagram of an API call monitoring device 300 provided by an embodiment of the present application. As shown in Figure 3 Corresponding to the above API call monitoring method, the present application also provides an API call monitoring device 300. The API call monitoring device 300 includes units for executing the above API call monitoring method, and the device can be configured in a server. Specifically, please refer to Figure 3 The API call monitoring device 300 includes: An adding unit 301 is configured to add a custom annotation to form a monitoring policy; An invocation obtaining unit 302 is configured to obtain annotation information in the monitoring policy when a business method is invoked; A storage unit 303 is configured to store the annotation information in thread local storage; An invocation triggering unit 304 is configured to trigger an interceptor to capture HTTP request information and HTTP response information when an HTTP call to an external service is initiated inside the business method; An obtaining matching unit 305 is configured to obtain, by the interceptor, a parameter annotation configuration matched with the current HTTP request information from the thread local storage; A constructing unit 306 is configured to construct an information log object according to the matched parameter annotation configuration; An execution receiving unit 307 is configured to continue to execute a normal HTTP request sending process and receive HTTP response data returned by the external service; A parsing unit 308 is configured to parse a business status code in the HTTP response data to obtain business status information; An integrating unit 309 is configured to integrate the HTTP response information, the information log object, and the business status information to form a complete log object; A sending unit 310 is configured to asynchronously send the complete log object to a log storage service to form stored log data.

[0069] In an embodiment, the adding unit 301 comprises: An adding module is configured to add an @ApiInvokeLog annotation on an API call method that needs to be monitored; A configuration defining module is configured to configure one or more @ApiLogParam annotation instances through field value properties of the @ApiInvokeLog annotation to define monitoring policies of different URL paths, including log content, URL matching rules, and business status code checking parameters.

[0070] In an embodiment, the invocation obtaining unit 302 comprises: An invocation obtaining module is configured to obtain the monitoring policy through a method aspect or an interceptor in an aspect-oriented programming technology when the business method is invoked; A parsing module is configured to parse specific parameter configurations in the monitoring policy to obtain the annotation information.

[0071] In an embodiment, the invocation triggering unit 304 comprises: An invocation triggering module is configured to trigger an HTTP client interceptor when an HTTP call to an external service is initiated inside the business method. The first capturing module is configured to capture HTTP request information by the interceptor, including request URL, request method, request header, and request parameter. The second capturing module is configured to capture HTTP response information returned by the external service by the interceptor, including status code, response header, and response body.

[0072] In an embodiment, the parsing unit 308 comprises: The parsing judgment module is configured to parse the service status code in the HTTP response data, and judge the service status of the API call. The extraction module is configured to extract information from the service status of the API call to obtain service status information.

[0073] In an embodiment, the integration unit 309 comprises: The integration adding module is configured to integrate the HTTP response information, the information log object, and the service status information, and add response time information and time consumption information to form a complete log object.

[0074] In an embodiment, the apparatus further comprises: The analysis and display unit is configured to analyze the stored log data, generate a monitoring report, and display the monitoring report through a visualization tool.

[0075] It should be noted that the specific implementation process of the API call monitoring apparatus 300 and each unit can be clearly understood by those skilled in the art, which can be referred to the corresponding description in the foregoing method embodiments. For the convenience and brevity of description, it will not be repeated here.

[0076] The API call monitoring apparatus 300 can be implemented in the form of a computer program, which can run on a computer device as shown in the computer device. Figure 4

[0077] Please refer to Figure 4 , Figure 4 is a schematic block diagram of a computer device provided by an embodiment of the present application. The computer device 500 can be a server, wherein the server can be a stand-alone server or a server cluster composed of multiple servers.

[0078] Please refer to Figure 4 , the computer device 500 comprises a processor 502, a memory, and a network interface 505 connected through a system bus 501, wherein the memory can comprise a non-volatile storage medium 503 and an internal memory 504.

[0079] ​The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions which, when executed, can cause the processor 502 to perform an API call monitoring method.

[0080] The processor 502 is configured to provide computing and control capabilities to support the operation of the entire computer device 500.

[0081] The memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503, which, when executed by the processor 502, can cause the processor 502 to perform an API call monitoring method.

[0082] The network interface 505 is configured to perform network communication with other devices. Those skilled in the art can understand that the network interface 505 can be configured to perform network communication with other devices through wired or wireless communication. Figure 4 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device 500 to which the scheme of the present application is applied. The specific computer device 500 can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0083] The processor 502 is configured to run the computer program 5032 stored in the memory to perform the following steps: add custom annotations to form a monitoring policy; obtain annotation information in the monitoring policy when a business method is called; store the annotation information in thread local storage; trigger an interceptor to capture HTTP request information and HTTP response information when an HTTP call to an external service is initiated inside the business method; the interceptor obtains parameter annotation configuration matching the current HTTP request information from the thread local storage; constructs an information log object according to the matched parameter annotation configuration; continues to execute the normal HTTP request sending process and receives the HTTP response data returned by the external service; parses the business status code in the HTTP response data to obtain business status information; integrates the HTTP response information, the information log object and the business status information to form a complete log object; asynchronously sends the complete log object to a log storage service to form stored log data.

[0084] It should be understood that, in the embodiments of the present application, the processor 502 can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0085] It can be understood by those skilled in the art that all or part of the processes in the above-mentioned embodiments can be completed by a computer program instructing related hardware. The computer program includes program instructions, and the computer program can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the above-mentioned embodiments.

[0086] Therefore, the present application also provides a storage medium. The storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program is executed by a processor to make the processor execute the following steps: add a custom annotation to form a monitoring policy; obtain annotation information in the monitoring policy when a business method is called; store the annotation information in thread local storage; trigger an interceptor to capture HTTP request information and HTTP response information when an HTTP call to an external service is initiated inside the business method; the interceptor obtains parameter annotation configuration matched with the current HTTP request information from the thread local storage; constructs an information log object according to the matched parameter annotation configuration; continues to execute a normal HTTP request sending process, and receives HTTP response data returned by the external service; parses a business status code in the HTTP response data to obtain business status information; integrates the HTTP response information, the information log object and the business status information to form a complete log object; asynchronously sends the complete log object to a log storage service to form stored log data.

[0087] The storage medium can be a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk, and various computer-readable storage media that can store program codes.

[0088] Those skilled in the art can understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been described in general terms in the above description. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0089] In several embodiments provided by the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. For example, the apparatus embodiments described above are merely schematic. For example, the division of each unit is only a logical function division, and actual implementation can have another division manner. For example, a plurality of units or components can be combined or integrated into another system, or some features can be omitted or not executed.

[0090] The steps in the method embodiments of the present application can be adjusted, combined and deleted in sequence according to actual needs. The units in the apparatus embodiments of the present application can be combined, divided and deleted according to actual needs. In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit.

[0091] The integrated unit, if realized in the form of a software functional unit and sold or used as an independent product, can be stored in a storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art, or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of instructions for causing a computer device (which can be a personal computer, a terminal or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present application.

[0092] The above description is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical range disclosed by the present application, and these modifications or replacements should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. An API call monitoring method, characterized in that, include: Add custom annotations to define monitoring strategies; When a business method is invoked, the annotation information in the monitoring strategy is retrieved; Storing annotation information in thread-local storage; When a business method initiates an HTTP call to an external service, the interceptor is triggered to capture the HTTP request and response information. The interceptor retrieves parameter annotation configurations that match the current HTTP request information from thread-local storage; Construct an information log object based on the matched parameter annotation configuration; Continue executing the normal HTTP request sending process and receive HTTP response data returned by the external service; Parse the business status code in the HTTP response data to obtain business status information; The HTTP response information, information log object, and business status information are integrated to form a complete log object; The complete log object is sent asynchronously to the log storage service to form the stored log data.

2. The API call monitoring method according to claim 1, characterized in that, The addition of custom annotations to form a monitoring strategy includes: Add the @ApiInvokeLog annotation to the API call methods that need to be monitored; Configure one or more @ApiLogParam annotation instances through the field value attributes of the @ApiInvokeLog annotation to define monitoring strategies for different URL paths, including log content, URL matching rules, and business status code check parameters.

3. The API call monitoring method according to claim 1, characterized in that, When a business method is invoked, the annotation information in the monitoring strategy is retrieved, including: When a business method is invoked, the monitoring strategy is obtained through method aspects or interceptors in aspect-oriented programming. Parse the specific parameter configurations in the monitoring strategy to obtain annotation information.

4. The API call monitoring method according to claim 1, characterized in that, When a business method initiates an HTTP call to an external service, the interceptor is triggered to capture HTTP request and response information, including: When a business method initiates an HTTP call to an external service, the HTTP client interceptor is triggered. The interceptor captures HTTP request information, including the request URL, request method, request headers, and request parameters; The interceptor captures HTTP response information returned by external services, including status codes, response headers, and response bodies.

5. The API call monitoring method according to claim 1, characterized in that, The process of parsing the business status code in the HTTP response data to obtain business status information includes: Parse the business status code in the HTTP response data to determine the business status of the API call; Extract business status information from API calls to obtain business status information.

6. The API call monitoring method according to claim 1, characterized in that, The process of integrating HTTP response information, information log objects, and business status information to form a complete log object includes: The HTTP response information, information log object, and business status information are integrated, and response time information and time consumption information are added to form a complete log object.

7. The API call monitoring method according to claim 1, characterized in that, After asynchronously sending the complete log object to the log storage service to form stored log data, the process also includes: Analyze the stored log data, generate monitoring reports, and display the monitoring reports using visualization tools.

8. An API call monitoring device, characterized in that, include: Add a unit to add custom annotations to form a monitoring strategy; The call acquisition unit is used to retrieve annotation information from the monitoring strategy when a business method is invoked; Storage unit, used to store annotation information in thread-local storage; The call trigger unit is used to trigger the interceptor to capture HTTP request and HTTP response information when an HTTP call to an external service is initiated within a business method; Get matching unit, which is used by the interceptor to retrieve parameter annotation configurations that match the current HTTP request information from thread-local storage; The building unit is used to construct information log objects based on the matched parameter annotation configuration; The execution receiving unit is used to continue the normal HTTP request sending process and receive HTTP response data returned by external services; The parsing unit is used to parse the business status code in the HTTP response data to obtain business status information; The integration unit is used to integrate HTTP response information, information log objects, and business status information to form a complete log object; The sending unit is used to asynchronously send the complete log object to the log storage service to form stored log data.

9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images