Automatic health inspection method and system for background service interface
By using automated health inspection methods and systems, the problems of low efficiency and poor accuracy in monitoring backend service interfaces in microservice architectures have been solved. This has enabled efficient and accurate interface fault detection and report generation, improving system response speed and operational efficiency.
Patent Information
- Application Number
- CN202511014740.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-23
- Publication Date
- 2025-11-14
AI Technical Summary
In a microservice architecture, existing technologies rely on manual periodic checks or simple scripts to detect backend service interfaces, which are inefficient, prone to omissions, and have poor real-time performance. They cannot detect interface faults in a timely manner, resulting in long system fault recovery times, which affect user experience and normal business operations.
This paper provides an automated health inspection method and system for a backend service interface. By configuring inspection tasks, calling the interface at regular intervals, verifying results in multiple dimensions, issuing alarms for anomalies, and generating visual reports, the system achieves fully automated monitoring of the entire process. This includes dual-dimensional verification of status codes and response times, triggering alarms based on the number of consecutive failures, and generating health status reports.
It significantly improves monitoring efficiency and anomaly detection accuracy, shortens fault response time, reduces operation and maintenance costs, helps to quickly locate problems and analyze system health status, adapts to microservice architectures of different sizes, and can be easily integrated into existing monitoring systems.
Smart Images
Figure CN120950329A_ABST
Abstract
Description
Technical Field
[0001] This invention discloses an automated health inspection method and system for a backend service interface, relating to the field of interface data testing technology. Background Technology
[0002] In current microservice architecture application systems, the system is divided into multiple independent microservices, which communicate and collaborate through interfaces. Due to the large number of microservices and their complex dependencies, the stability of the backend service interfaces is crucial to the normal operation of the entire system.
[0003] Currently, monitoring of backend service interfaces mainly relies on periodic manual checks or simple script-based detection. Manual checks suffer from low efficiency, easy omissions, and poor real-time performance, failing to detect interface faults promptly. Simple script-based detection has limited functionality, typically only checking whether the interface can return data normally, unable to fully verify the specific content of the returned results, and struggling to automate alerts and generate detailed health status reports. When interface faults occur, the problem cannot be quickly located, resulting in long system recovery times, impacting user experience and normal business operations. Summary of the Invention
[0004] This invention addresses the problems of existing technologies by providing an automated health inspection method and system for backend service interfaces, applicable to scenarios involving continuous monitoring, anomaly detection, and performance analysis of service interfaces under a microservice architecture.
[0005] The specific solution proposed in this invention is as follows:
[0006] This invention provides an automated health inspection method for a backend service interface, comprising:
[0007] Step 1: Configure Inspection Tasks: Configure the inspection tasks for the interface, set the inspection cycle and alarm trigger conditions.
[0008] Step 2: Based on the inspection cycle, periodically call the configured interface, sending a request to the interface configured for the inspection task at each inspection time point and obtaining the interface's return result.
[0009] Step 3: Verify the returned results: Analyze the obtained interface return results: If the interface returns a status code outside the expected normal status code range, the interface is considered abnormal; if the interface returns a status code within the normal range but the response time exceeds a set threshold, the interface is also considered abnormal; if the interface returns a status code within the normal range and the response time does not exceed the set threshold, the interface is considered normal.
[0010] Step 4: Record the results of each interface test and store them in the database.
[0011] Step 5: Determine whether to trigger an alarm based on the detection results: Periodically count the number of anomalies for each interface, trigger an alarm for interfaces that exceed the alarm triggering criteria, and notify the operations and maintenance personnel.
[0012] Step 6: Generate a health status report: Generate a health status report based on the previous day's interface detection results stored in the database.
[0013] Furthermore, in step 1 of the automated health inspection method for a backend service interface, when configuring the inspection task of the interface, the URL, request method, request parameters, expected status code range, and response time threshold of the interface are added, and an alarm is triggered when the number of consecutive abnormalities exceeds the alarm triggering condition.
[0014] Furthermore, in step 4 of the automated health inspection method for a backend service interface, the results of each interface inspection are recorded: the start time of the inspection of the user service login interface is recorded, as well as the total inspection time, interface name, status code, and response time.
[0015] Furthermore, the health status report generated in step 6 of the automated health inspection method for a backend service interface includes the total number of times the interface was checked in the past day, with the number of normal checks as the number of checks, the number of abnormal checks as the number of checks, and the average response time as the time.
[0016] This invention also provides an automated health inspection system with a backend service interface, including a task configuration module, an interface call module, a result verification module, a recording module, an alarm judgment module, and a report generation module.
[0017] The task configuration module configures inspection tasks: it configures the inspection tasks for the interface, sets the inspection cycle and alarm trigger conditions.
[0018] The API call module periodically calls the configured API according to the inspection cycle. At each inspection time, it sends a request to the API that configures the inspection task and retrieves the API's return result.
[0019] The result verification module verifies the returned results: It analyzes the obtained interface return results: If the interface returns a status code outside the expected normal status code range, the interface is considered abnormal; if the interface returns a status code within the normal range but the response time exceeds a set threshold, the interface is also considered abnormal; if the interface returns a status code within the normal range and the response time does not exceed the set threshold, the interface is considered normal.
[0020] The recording module records the results of each interface test and stores them in the database.
[0021] The alarm judgment module determines whether to trigger an alarm based on the detection results: it periodically counts the number of anomalies for each interface, and triggers an alarm for interfaces that exceed the alarm triggering condition, notifying the operations and maintenance personnel.
[0022] The report generation module generates health status reports: based on the previous day's interface detection results stored in the database, a health status report is generated.
[0023] Furthermore, when configuring the inspection task of the automated health inspection system for the background service interface, the task configuration module adds the interface URL, request method, request parameters, expected status code range, response time threshold, and sets the alarm triggering condition to trigger an alarm if the number of consecutive abnormalities exceeds the limit.
[0024] Furthermore, the recording module of the automated health inspection system for the background service interface records the results of each interface inspection: it records the start time of the inspection of the user service login interface, the total inspection time, the interface name, the status code, and the response time.
[0025] Furthermore, the health status report generated by the report generation module of the automated health inspection system for the background service interface includes the total number of times the interface detected the system in the past day, with the number of normal detections as the number of times, the number of abnormal detections as the number of times, and the average response time as the time.
[0026] The advantages of this invention are:
[0027] This system revolutionizes existing interface monitoring methods that rely on manual intervention or simple scripts. Through end-to-end automation, from scheduled interface calls and multi-dimensional result verification to anomaly alert triggering and visual report generation, it significantly reduces manual intervention, lowers operational costs, and dramatically improves monitoring efficiency. Its dual-dimensional verification mechanism based on status codes and response times accurately identifies interface functional anomalies and performance bottlenecks, resulting in a significantly higher anomaly detection accuracy compared to existing methods that only assess interface availability. The strategy of triggering alerts based on consecutive failure counts enables rapid response to persistent interface failures, greatly shortening response time and effectively minimizing business impact. Furthermore, it automatically generates health reports with rich metrics, presented in intuitive charts and data formats, helping operations personnel quickly locate problems and analyze system health. The dynamic adjustment function of the task configuration module allows it to flexibly adapt to microservice architectures of different scales and business scenarios, easily integrating into existing monitoring systems and reducing system upgrade and transformation costs. Attached Figure Description
[0028] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0029] Figure 1 This is a schematic diagram of the method flow of the present invention. Detailed Implementation
[0030] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand and implement the present invention. However, the embodiments described are not intended to limit the present invention.
[0031] This invention provides an automated health inspection method for a backend service interface, comprising:
[0032] Step 1: Configure Inspection Tasks: Configure the inspection tasks for the interface, set the inspection cycle and alarm trigger conditions.
[0033] Step 2: Based on the inspection cycle, periodically call the configured interface, sending a request to the interface configured for the inspection task at each inspection time point and obtaining the interface's return result.
[0034] Step 3: Verify the returned results: Analyze the obtained interface return results: If the interface returns a status code outside the expected normal status code range, the interface is considered abnormal; if the interface returns a status code within the normal range but the response time exceeds a set threshold, the interface is also considered abnormal; if the interface returns a status code within the normal range and the response time does not exceed the set threshold, the interface is considered normal.
[0035] Step 4: Record the results of each interface test and store them in the database.
[0036] Step 5: Determine whether to trigger an alarm based on the detection results: Periodically count the number of anomalies for each interface, trigger an alarm for interfaces that exceed the alarm triggering criteria, and notify the operations and maintenance personnel.
[0037] Step 6: Generate a health status report: Generate a health status report based on the previous day's interface detection results stored in the database.
[0038] Example 1
[0039] Taking a microservice architecture e-commerce system that includes user services, order services, and payment services as an example, the specific implementation process of this invention is illustrated below:
[0040] Step 1: Configure inspection tasks:
[0041] In the task configuration, add the following interfaces: User Service Login Interface (URL: http: / / user-service / login, POST method, username and password, expected status code range: 200-299, response time threshold: 300 milliseconds); Order Service Create Order Interface (URL: http: / / order-service / createOrder, POST method, product information and user ID, expected status code range: 200-299, response time threshold: 400 milliseconds); Payment Service Payment Interface (URL: http: / / payment-service / pay, POST method, order ID and payment amount, expected status code range: 200-299, response time threshold: 500 milliseconds). These form inspection tasks. Set the inspection cycle to once every 10 minutes, and the alarm trigger condition to trigger an alarm after 3 consecutive failed checks.
[0042] Step 2: Scheduled API Calls: Following the set 10-minute inspection cycle, send requests to the three APIs mentioned above at each inspection time. For example, at 0:10, send a POST request containing the test username and password to the user service login API and retrieve the API's response.
[0043] Step 3: Verify the returned results: Analyze the obtained interface return results. If the user service login interface returns a status code of 401, indicating unauthorized access, which is outside the expected range of 200-299, then the interface is considered abnormal. If the order service create order interface returns a status code of 200, but the response time is 500 milliseconds, exceeding the set threshold of 400 milliseconds, the interface is also considered abnormal. If the payment service payment interface returns a status code of 200 and the response time is 300 milliseconds, both of which meet expectations, then the interface is considered normal.
[0044] Step 4: Record the test results: Record the detailed results of each interface test, such as the test of the user service login interface at 0:10, as follows: Test time: 0:10, Interface name: User service login interface, Status code: 401, Response time: 200 milliseconds, Normal status: No.
[0045] Stored in the database.
[0046] Step 5: Determine if an alarm is triggered: Periodically count the number of anomalies for each interface. If the user service login interface experiences anomalies in the checks at 0:10, 0:20, and 0:30, reaching the alarm trigger condition of three consecutive failed checks, an alarm will be triggered, and the operations and maintenance personnel will be notified via email, SMS, etc.
[0047] Step 6: Generate Health Status Report: The report generation module generates a health status report at 1:00 AM every day, based on the previous day's interface detection results stored in the database. For example, the report might show that the user service login interface was detected 144 times in the past day, with 100 normal tests and 44 abnormal tests, with an average response time of 350 milliseconds; the order service order creation interface was detected 144 times, with 120 normal tests and 24 abnormal tests, with an average response time of 380 milliseconds, and so on.
[0048] Example 2
[0049] This invention also provides an automated health inspection system with a backend service interface, including a task configuration module, an interface call module, a result verification module, a recording module, an alarm judgment module, and a report generation module.
[0050] The task configuration module configures inspection tasks: it configures the inspection tasks for the interface, sets the inspection cycle and alarm trigger conditions.
[0051] The interface invocation module calls the configured interface periodically according to the inspection cycle. At each inspection time, it sends a request to the interface configured for the inspection task and retrieves the interface's return result. The interface invocation module is implemented using Java and the HttpClient library, and triggers the interface invocation operation according to the set inspection cycle through a scheduled task framework (such as Quartz). Each time the interface is called, an HTTP request is constructed based on the configured request method (GET or POST) and request parameters, sent to the target interface, and the return result is retrieved. The core Java code is as follows:
[0052] import java.io.IOException;
[0053] import java.net.URI;
[0054] import java.net.http.HttpClient;
[0055] import java.net.http.HttpRequest;
[0056] import java.net.http.HttpResponse;
[0057] public class ApiCaller{
[0058] public static HttpResponse <string>callApi(String url,String method,String requestBody)throws IOException,InterruptedException{
[0059] HttpClient client=HttpClient.newHttpClient();
[0060] HttpRequest.Builder requestBuilder=HttpRequest.newBuilder()
[0061] .uri(URI.create(url));
[0062] if("POST".equalsIgnoreCase(method)){
[0063] requestBuilder=requestBuilder
[0064] .header("Content-Type","application / json")
[0065] .POST(HttpRequest.BodyPublishers.ofString(requestBody));
[0066] }else if("GET".equalsIgnoreCase(method)){
[0067] requestBuilder=requestBuilder.GET();
[0068] }
[0069] HttpRequest request=requestBuilder.build();
[0070] return client.send(request,HttpResponse.BodyHandlers.ofString());
[0071] }
[0072] }
[0073] The result verification module verifies the returned results: It analyzes the obtained interface return results and uses Java code to write verification logic to extract status codes and response time information from the interface return results. It compares the status codes with expected ranges and the response times with thresholds using conditional statements (such as if-else) to determine whether the interface is functioning correctly. The core Java code is as follows:
[0074] public class ResultValidator{
[0075] public static boolean validateResult(HttpResponse <string>response,intexpectedMinStatus,int expectedMaxStatus,long responseTimeThreshold){
[0076] int statusCode=response.statusCode();
[0077] long responseTime=response.timeline().totalDuration().toMillis();
[0078] return(statusCode>=expectedMinStatus&&statusCode<=expectedMaxStatus)&&responseTime<=responseTimeThreshold;
[0079] }
[0080] }
[0081] The recording module records the results of each interface test and stores them in the database.
[0082] The alarm judgment module determines whether to trigger an alarm based on the detection results: it periodically counts the number of anomalies for each interface, and triggers an alarm for interfaces that exceed the alarm triggering condition, notifying the operations and maintenance personnel. The core JAVA code is as follows:
[0083]
[0084]
[0085] The report generation module generates health status reports: based on the previous day's interface detection results stored in the database, it generates health status reports. Using Java and the Apache POI library, it reads data from the database and generates an Excel report containing interface detection statistics, embedding charts into the report. The core Java code is as follows:
[0086]
[0087]
[0088]
[0089] / / Generate bar chart
[0090] JFreeChart chart = ChartFactory.createBarChart(
[0091] "Daily API Interface Error Rate",
[0092] "Interface Name",
[0093] "Error Rate(%)",
[0094] dataset);
[0095] CategoryPlot plot = chart.getCategoryPlot();
[0096] BarRenderer renderer = (BarRenderer) plot.getRenderer();
[0097] renderer.setSeriesPaint(0, Color.RED);
[0098] File chartFile = new File("error_rate_chart.png");
[0099] ChartUtilities.saveChartAsPNG(chartFile, chart, 800, 600);
[0100] / / Generate Excel report
[0101] Workbook workbook = new XSSFWorkbook();
[0102] Sheet sheet = workbook.createSheet("API Health Report");
[0103] / / Table header
[0104] Row headerRow = sheet.createRow(0);
[0105] String[] headers = {"Interface Name", "Total Checks", "Normal Checks", "Average Response Time", "Error Rate"};
[0106] for(int i = 0; i <headers.length;i++){
[0107] Cell cell=headerRow.createCell(i);
[0108] cell.setCellValue(headers[i]);
[0109]
[0110]
[0111]
[0112]
[0113] The information interaction and execution process between the modules in the above system are based on the same concept as the method embodiment of the present invention, and the specific details can be found in the description in the method embodiment of the present invention, and will not be repeated here.
[0114] Similarly, this invention system changes the existing interface monitoring model that relies on manual or simple script detection. Through a fully automated design, from scheduled interface calls and multi-dimensional result verification to anomaly alarm triggering and visualization report generation, it greatly reduces manual intervention, significantly lowers maintenance manpower costs, and significantly improves monitoring efficiency. Its dual-dimensional verification mechanism based on status codes and response times accurately identifies interface functional anomalies and performance bottlenecks, significantly improving anomaly detection accuracy compared to existing methods that only judge interface availability. The strategy of triggering alarms based on consecutive failure counts can quickly respond to persistent interface failures, greatly shortening fault response time and effectively reducing the impact on business. Furthermore, it automatically generates health reports containing rich indicators, presented in an intuitive chart and data format, helping maintenance personnel quickly locate problems and analyze system health. The dynamic adjustment function of the task configuration module allows it to flexibly adapt to microservice architectures of different scales and business scenarios, easily integrating into existing monitoring systems and reducing system upgrade and transformation costs.
[0115] It should be noted that not all steps and modules in the above processes and system structures are mandatory; some steps or modules can be omitted as needed. The execution order of the steps is not fixed and can be adjusted as required. The system structures described in the above embodiments can be physical or logical structures. That is, some modules may be implemented by the same physical entity, or some modules may be implemented by multiple physical entities, or they may be implemented by certain components in multiple independent devices.
[0116] The above-described embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention. The scope of protection of the present invention is defined by the claims.< / string> < / string>
Claims
1. An automated health inspection method for a backend service interface, characterized by: include: Step 1: Configure Inspection Tasks: Configure the inspection tasks for the interface, set the inspection cycle and alarm trigger conditions. Step 2: Based on the inspection cycle, periodically call the configured interface, sending a request to the interface configured for the inspection task at each inspection time point and obtaining the interface's return result. Step 3: Verify the return results: Analyze the obtained interface return results: If the status code returned by the interface is not within the expected normal status code range, then the interface that is not within the expected normal status code range is determined to be abnormal; If the interface returns a status code within the normal range, but the response time exceeds the set threshold, the interface whose response time exceeds the set threshold is also considered to be abnormal. If the API returns a status code within the normal range and the response time does not exceed the set threshold, the API is considered normal. Step 4: Record the results of each interface test and store them in the database. Step 5: Determine whether to trigger an alarm based on the detection results: Periodically count the number of anomalies for each interface, trigger an alarm for interfaces that exceed the alarm triggering criteria, and notify the operations and maintenance personnel. Step 6: Generate a health status report: Generate a health status report based on the previous day's interface detection results stored in the database.
2. The automated health inspection method for a backend service interface according to claim 1, characterized in that: When configuring the inspection task of the interface in step 1, add the interface URL, request method, request parameters, expected status code range, response time threshold, and set the alarm trigger condition to trigger an alarm if the number of consecutive abnormalities exceeds the limit.
3. The automated health inspection method for a backend service interface according to claim 1, characterized in that step 4 records the results of each interface inspection: records the start time of the inspection of the user service login interface, and records the total inspection time, interface name, status code and response time.
4. The automated health inspection method for a backend service interface according to claim 1, characterized in that: The health status report generated in step 6 includes the total number of times the interface was checked in the past day, with the number of normal checks as the number of checks, the number of abnormal checks as the number of checks, and the average response time as the time.
5. An automated health inspection system with a backend service interface, characterized in that: It includes a task configuration module, an interface call module, a result verification module, a logging module, an alarm judgment module, and a report generation module. The task configuration module configures inspection tasks: it configures the inspection tasks for the interface, sets the inspection cycle, and alarm trigger conditions. The API call module periodically calls the configured API according to the inspection cycle. At each inspection time, it sends a request to the API that configures the inspection task and retrieves the API's return result. The result verification module verifies the returned results: it analyzes the obtained interface return results: if the status code returned by the interface is not within the expected normal status code range, it determines that the interface outside the expected normal status code range is abnormal; If the interface returns a status code within the normal range, but the response time exceeds the set threshold, the interface whose response time exceeds the set threshold is also considered to be abnormal. If the API returns a status code within the normal range and the response time does not exceed the set threshold, the API is considered normal. The recording module records the results of each interface test and stores them in the database. The alarm judgment module determines whether to trigger an alarm based on the detection results: it periodically counts the number of anomalies for each interface, and triggers an alarm for interfaces that exceed the alarm triggering condition, notifying the operations and maintenance personnel. The report generation module generates health status reports: based on the previous day's interface detection results stored in the database, a health status report is generated.
6. An automated health inspection system with a backend service interface according to claim 5, characterized in that: When configuring the inspection task of the interface in the task configuration module, add the interface URL, request method, request parameters, expected status code range, response time threshold, and set the alarm trigger condition to trigger an alarm if the number of consecutive abnormalities exceeds the limit.
7. An automated health inspection system with a backend service interface according to claim 5, characterized in that: The recording module records the results of each interface test: it records the start time of the test for the user service login interface, the total test time, the interface name, the status code, and the response time.
8. An automated health inspection system with a backend service interface according to claim 5, characterized in that: The health status report generated by the report generation module includes the total number of times the interface was checked in the past day, with the number of normal checks as the number of times, the number of abnormal checks as the number of times, and the average response time as the time.