Interface service state analysis system and method based on distributed testing and monitoring

Abstract

The application provides a kind of interface service state analysis system and method based on distributed testing and monitoring, it is related to computer system monitoring technical field.The system integrates test script generation module, improved Jmeter server, index data transfer module, Prometheus server, intelligent analysis module and alarm module, realizes the whole process management of computer system interface service from detection, storage, display, alarm to analysis.Improve Jmeter test tool, make it compatible with Prometheus collection mode, meet different test requirements and multi-concurrent scene;Intelligent analysis module is used to build service dependency, realize intelligent analysis and positioning of fault, solve the problem that service fault is difficult to be actively found and quickly positioned in existing operation and maintenance system, improve the operation and maintenance efficiency of information system.

Description

Technical Field

[0001] This invention relates to the field of computer system monitoring technology, specifically to an interface service status analysis system and method based on distributed testing and monitoring. Background Technology

[0002] In computer system operation and maintenance, as the number of systems increases and service dependencies become more complex, the discovery and localization of service failures become increasingly difficult. Apache JMeter is an open-source Java application used for performance and functional testing. It allows users to create complex test plans, simulate concurrent requests from multiple users, and collect detailed test results. Prometheus is a powerful open-source monitoring and metrics collection system, and its numerous components can help us quickly build a monitoring and alerting system. Therefore, existing technologies often combine Apache JMeter and Prometheus to build a monitoring and alerting system. However, the existing standard JMeter testing tool uses a passive pull mode for stress testing and cannot perfectly adapt to timed single / limited probe scenarios. Furthermore, it requires Prometheus to poll for data collection, leading to data latency. Moreover, existing system service monitoring methods only determine the failure of a service node based on preset alert rules, and the alerting module directly issues an alert for that faulty service node. This can lead to inaccurate localization of the faulty service node, such as failing to locate the root cause of the fault, and further, the risk of an alert storm.

[0003] Therefore, a more comprehensive monitoring and analysis system is needed to address the shortcomings of existing technologies. The aforementioned problems are currently urgent issues that need to be resolved. Summary of the Invention

[0004] The purpose of this invention is to provide an interface service status analysis system and method based on distributed testing and monitoring, aiming to solve at least one technical problem existing in the prior art.

[0005] On one hand, this invention provides an interface service status analysis system based on distributed testing and monitoring. The system includes: a test script generation module, an improved JMeter server, a metric data transfer module, a Prometheus server, an intelligent analysis module, and an alarm module. The test script generation module generates test scripts based on user-written test procedures and sends them to the improved JMeter server. The improved JMeter server receives the test scripts and sends simulation requests to the target interface, collects test result data from the target interface, and actively pushes the data to the metric data transfer module. The Prometheus server retrieves and stores data sent by the JMeter server module from the metric data transfer module and, according to pre-defined parameters, analyzes and monitors the data. The configured alarm rules determine whether an alarm event is triggered; the intelligent analysis module integrates a dependency graph construction unit and a fault location unit; the dependency graph construction unit is used to construct a dynamic dependency graph based on the alarm event received from the Prometheus server, by obtaining service information related to the alarm event from the Prometheus server, where nodes are services and edge weights are calculated using historical call frequency and real-time error rate; the fault location unit is used to calculate the fault propagation probability based on the improved PageRank algorithm, and obtain the root cause service node of the fault based on the calculation result, generating root cause analysis results; the alarm module is used to dynamically suppress downstream service alarms based on the root cause analysis results, including: retaining only alarms of the root cause service.

[0006] Furthermore, the improved JMeter server includes: adding an active probe adapter to the original JMeter server, including modifying the jmeter-prometheus-plugin source code and removing the built-in web server; adding a result encapsulation layer to package single test result data in Prometheus format; and actively pushing the single test result data to the indicator data transfer module via HTTP API.

[0007] Furthermore, the system also includes a service status display module and other cloud server monitoring modules. The service status display module is used to query data in the Prometheus server using PromQL and create a dashboard to display the online status of the service. The other cloud server monitoring modules are used to monitor the operating status of hardware resources by installing Exporter software on the edge cloud server and transmit the monitoring results to the Prometheus server. The Prometheus server compares the operating status of the hardware resources with preset alarm rules and sends hardware alarm events directly to the alarm module based on the comparison results.

[0008] Furthermore, the data pulled by the Prometheus server includes one or a combination of service online status, response latency, stress test results, CPU load of hardware resources, and hard disk capacity data.

[0009] Furthermore, the edge weights of the dynamically dependent graph are calculated as follows:

[0010] ;

[0011] In the formula, Let be the edge weight, representing the dependency strength of service j calling service i. This is a weighting coefficient based on the historical call frequency. This is the weighting coefficient for the real-time error rate. The historical call frequency of service j to service i. The real-time error rate of service j.

[0012] Furthermore, the historical call frequency calculation method includes: querying the time-series database in the Prometheus server to find the total number of times service j calls service i within a preset historical time period; calculating the total number of calls to service j; and applying the formula... The historical call frequency value is calculated.

[0013] Furthermore, the real-time error rate calculation method includes: counting the total number of service j calls within a sliding time window from the time-series database in the Prometheus server using the stream processing engine; counting the number of error responses and timeouts of service j within the same time window; and calculating the error rate using the formula... The real-time error rate is calculated.

[0014] Furthermore, the improved PageRank algorithm includes:

[0015] ;

[0016] In the formula, Let represent the failure propagation probability of service i, d represent the damping coefficient, and N represent the number of nodes. Let the edge weights be represented as the edge weights between service j and service i. Represented as real-time anomaly factors, This is represented as the node's out-degree. Let be the probability of fault propagation for service j;

[0017] The real-time anomaly factor The calculation formula is:

[0018] ;

[0019] In the formula, This represents the number of errors in service j. This represents the number of timeouts for service j. This is represented as the normalized threshold for the number of errors. This represents the normalized threshold for the number of timeouts.

[0020] Furthermore, the alarm module is used to send service alarms to designated recipients according to pre-configured routing rules. The service alarms include the service that has failed and the analysis results.

[0021] Secondly, embodiments of the present invention provide a method for analyzing the status of interface services based on distributed testing and monitoring. This method is applied to the aforementioned interface service status analysis system based on distributed testing and monitoring. The method includes: Step S1, generating a test script based on a user-written test process and sending it to an improved JMeter server; Step S2, the improved JMeter server receiving the test script and sending a simulation request to the target interface, collecting test result data from the target interface, and actively pushing the data to the indicator data transfer module; Step S3, the Prometheus server pulling the data sent by the JMeter server module from the indicator data transfer module for storage, and according to pre-configured... Step S4: The dependency graph construction unit, based on the received alarm event sent by the Prometheus server, obtains service information related to the alarm event from the Prometheus server to construct a dynamic dependency graph, where nodes are services and edge weights are calculated using historical call frequency and real-time error rate; Step S5: The fault location unit uses an improved PageRank algorithm to calculate the fault propagation probability and obtains the root cause service node of the fault based on the calculation result, generating root cause analysis results; Step S6: The alarm module dynamically suppresses downstream service alarms based on the root cause analysis results, including: retaining only alarms of the root cause service.

[0022] In another aspect, the present invention also provides a computer-readable storage medium storing one or more instructions, the computer instructions being used to cause the computer to execute the above-described interface service status analysis method based on distributed testing and monitoring.

[0023] In another aspect, the present invention provides an electronic device, comprising: a memory and a processor; the memory stores at least one program instruction; the processor loads and executes the at least one program instruction to implement the above-mentioned interface service status analysis method based on distributed testing and monitoring.

[0024] Compared with the prior art, the present invention has the following technical advantages:

[0025] (1) The Jmeter testing tool has been improved to meet different needs such as single test and stress test, and is compatible with Prometheus collection mode. It has better scalability and can meet multiple concurrent scenarios.

[0026] (2) By intelligently analyzing monitoring data through interface call relationships and building service dependency relationships in combination with large models, the root cause of faults can be quickly located, assisting operation and maintenance personnel to proactively discover and promptly handle faults, thereby improving the operation and maintenance efficiency of information systems. Attached Figure Description

[0027] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0028] Figure 1 This is a schematic diagram of the structure of an interface service status analysis system based on distributed testing and monitoring provided in Embodiment 1 of the present invention.

[0029] Figure 2 This is a schematic diagram of a constructed dynamic dependency graph provided in Embodiment 1 of the present invention.

[0030] Figure 3 This is a schematic diagram of a process for calculating the probability of fault propagation based on an improved PageRank algorithm, provided in Embodiment 1 of the present invention.

[0031] Figure 4 This is a full-process timing diagram of an interface service status analysis system based on distributed testing and monitoring provided in Embodiment 1 of the present invention.

[0032] Figure 5 This is a flowchart of an interface service status analysis method based on distributed testing and monitoring provided in Embodiment 2 of the present invention.

[0033] Figure 6 This is a partial block diagram of the electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

[0034] Before discussing the exemplary embodiments in more detail, it should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the operations as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the figures. The process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0035] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0036] The present invention will now be described in detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0037] Example 1

[0038] To facilitate subsequent understanding, the overall inventive concept of this invention is described here. This invention provides an interface service status analysis system based on distributed testing and monitoring, comprising: a test script generation module, an improved JMeter server, an indicator data transfer module, a Prometheus server, an intelligent analysis module and an alarm module, a service status display module, and other cloud server monitoring modules.

[0039] Test script generation module: Operations personnel write test processes through the local JMeter client. The JMeter client is developed based on Java and supports cross-platform operation. Operations personnel can visually compile test tasks for various types of services, analyze the status codes, return content, and latency of the test results, and send the generated test scripts to the JMeter server module.

[0040] The improved JMeter server module receives test scripts and runs them automatically. It allows for scheduled tasks via cron to monitor different services at varying frequencies, such as minutes, hours, and days. To meet the need for single or limited-time service health status checks, the PushGateway middleware is introduced. The jmeter-prometheus-plugin source code is modified to enable JMeter to proactively push data to PushGateway.

[0041] Prometheus server: It pulls data such as the online status, response latency, and stress test results of the Jmeter server module from the PushGateway middleware, and pulls and stores status data such as CPU load and hard disk capacity of hardware resources from the Exporter software installed on other cloud servers.

[0042] Service status display module: Grafana is used, which supports multiple data sources such as Prometheus. Data in Prometheus is queried through PromQL and made into a dashboard that can be used as a monitoring screen. It supports real-time refresh and multi-dimensional data display, realizing a visual display of the online status of services.

[0043] The alerting module includes AlertManager. When Prometheus collects monitoring data, it identifies abnormal service states according to set rules and pushes alerts to AlertManager. AlertManager sends different levels of alerts to corresponding recipients via email, SMS, etc., according to the configuration. SMS notifications are implemented by writing a webhook program to call other programs.

[0044] Other cloud server monitoring modules: By installing Exporter software on edge cloud servers, the Prometheus server periodically pulls their status data to monitor and alert on the operating status of hardware resources, reminding maintenance personnel to deal with issues such as high CPU load and insufficient hard disk capacity in a timely manner. At the same time, it can optimize resources for servers with long-term low load.

[0045] The intelligent analysis module utilizes added interface service information, combined with the large model and interface input and output parameters, to learn interface interaction data, analyze service dependencies, and construct a dynamically updated dependency graph. When a service status changes, it performs reverse or forward tracing analysis based on real-time monitoring data and the dependency graph to pinpoint the root cause of the fault and generates remediation suggestions based on the fault type and service importance. After remediation, JMeter is used to re-probe the relevant services to verify the effectiveness of the remediation results.

[0046] The specific implementation method is as follows:

[0047] like Figure 1 The diagram shown is a schematic of the interface service status analysis system based on distributed testing and monitoring provided by the present invention.

[0048] As an example, the system includes: a test script generation module 1, an improved JMeter server 2, a metrics data transfer module 3, a Prometheus server 4, an intelligent analysis module 5, and an alarm module 6. The test script generation module 1 generates test scripts based on user-written test procedures and sends them to the improved JMeter server. The improved JMeter server 2 receives the test scripts and sends simulation requests to the target interface, collects test result data from the target interface, and actively pushes the data to the metrics data transfer module. The Prometheus server 4 retrieves data sent by the JMeter server module from the metrics data transfer module 3 for storage and determines whether to trigger an alarm based on pre-configured alarm rules. The intelligent analysis module 5 integrates a dependency graph construction unit 50 and a fault location unit 51. The dependency graph construction unit 50 is used to construct a dynamic dependency graph based on the alarm events sent by the Prometheus server 4, and to obtain service information related to the alarm events from the Prometheus server 4. In this graph, nodes represent services, and edge weights are calculated using historical call frequency and real-time error rate. The fault location unit 51 is used to calculate the fault propagation probability based on the improved PageRank algorithm, and to obtain the root cause service node of the fault based on the calculation results, generating root cause analysis results. The alarm module 6 is used to dynamically suppress downstream service alarms based on the root cause analysis results, including: retaining only alarms of the root cause service.

[0049] In some feasible implementations, the test script generation module 1 is deployed with a local JMeter client. After installing a Java runtime environment locally, the operations and maintenance personnel run the JMeter client and use its visual interface to write test scripts (jmx files) for services such as text, images, and videos. During the writing process, configurations can be made for test task status code judgment, return content analysis, latency monitoring, etc. After completion, the test script is sent to the JMeter server module. This approach has the following three main advantages:

[0050] (1) Good cross-platform compatibility: Thanks to Jmeter being developed based on Java, it can support cross-platform operation very well. Any client that has installed the Java runtime environment can open and run the Jmeter client to compile test scripts (jmx files) and can also support the server.

[0051] (2) Visual test script debugging: As a very mature open-source testing tool, Jmeter has a mature ecosystem and community support. Operation and maintenance personnel can visually complete almost all types of service tests, including text, images, videos, etc.

[0052] (3) Accurate judgment of test results: Unlike some script tools, such as Python's requests library, which send HTTP requests and simply judge the status code returned by the interface, Jmeter can visualize and compile a series of test tasks, and analyze the status code, return content and delay of the final result. It can perform very complex test tasks and judge the results.

[0053] Specifically, in actual use, operations and maintenance personnel use the Jmeter client (GUI mode) to create test plans (.jmx files); the test plan can include multiple HTTP requests, assertions, timers, etc., to simulate user requests and verify responses; after the test is completed, the test script is uploaded to the Jmeter server deployed on the edge cloud system server.

[0054] In some feasible implementations, the improved JMeter server 2 includes: adding an active probe adapter on the basis of the original JMeter server, including modifying the jmeter-prometheus-plugin source code and deleting the built-in web server; adding a result encapsulation layer for packaging single test result data in Prometheus format; and actively pushing the single test result data to the indicator data transfer module 3 via HTTP API.

[0055] Preferably, the improved JMeter server 2 receives test scripts and runs them automatically. Scheduled tasks are set using a cron tool to monitor different services at different frequencies, such as minutes, hours, and days. To meet the need for single or limited-time service health status checks, a data transfer module 3 (PushGateway middleware) is introduced. The jmeter-prometheus-plugin source code is modified to enable JMeter to actively push data to PushGateway.

[0056] Specifically, the improved JMeter server 2 runs test scripts based on preset scheduled tasks (e.g., set to execute once per minute via cron), simulates user requests, sends them to the monitored interface service, and receives test results, including response time, status code, and response content.

[0057] The data is processed immediately after each sampling, including converting the sampling results into Prometheus-formatted metrics (e.g., service_up{service="order-service"}1 or 0, service_response_time{service="order-service"}350). The metric data is then pushed to the PushGateway middleware via an asynchronous thread pool.

[0058] In some feasible implementations, the system further includes a service status display module 7 and other cloud server monitoring modules 8; the service status display module 7 is used to query data in the Prometheus server through PromQL and create a dashboard to display the online status of the service; the other cloud server monitoring modules 8 are used to monitor the operating status of hardware resources by installing Exporter software on the edge cloud server and transmit the monitoring results to the Prometheus server 4; the Prometheus server 4 compares the operating status of the hardware resources with preset alarm rules and sends hardware alarm events directly to the alarm module based on the comparison results.

[0059] Preferably, Prometheus server 4 periodically (e.g., every 15 seconds) pulls data from the PushGateway middleware and stores it in its time-series database. Prometheus server 4 then determines whether to trigger an alarm event based on configured alarm rules (e.g., service_up==0 for one minute). Simultaneously, every 3 minutes, it pulls hardware data such as CPU utilization, memory usage, and hard disk capacity from the Exporter software of other edge cloud servers and stores this data in its local time-series database.

[0060] Preferably, the service status display module 7 includes: configuring the Prometheus data source in Grafana, writing query statements using PromQL, such as querying the average service response time and service online rate over the past 24 hours, and creating a monitoring dashboard in the form of line charts, bar charts, dashboards, etc., setting it to automatically refresh every 30 seconds, and allowing maintenance personnel to view the service status (online / offline), response time, etc. in real time through the dashboard.

[0061] Preferably, other cloud server monitoring module 8: Install node_exporter software on each edge cloud server. Prometheus pulls hardware data through this software. When the CPU utilization exceeds 80% or the hard disk capacity is less than 20%, an alarm is triggered and the operation and maintenance personnel are notified. For servers with a CPU utilization of less than 20% for 7 consecutive days, the system prompts the operation and maintenance personnel to consider reducing the configuration or taking them offline to save resources.

[0062] In some feasible implementations, Alert Module 6 sets alert rules in Prometheus, such as triggering a warning-level alert when the service response time exceeds 1 second for 3 consecutive times, and triggering an emergency-level alert when the service is detected as offline 3 times consecutively. Alert Module 6 (AlertManager) is configured to notify operations personnel via email upon receiving a warning-level alert, and simultaneously notify operations personnel via SMS and email upon receiving an emergency-level alert. The SMS notification is implemented by a Webhook program calling a third-party SMS interface.

[0063] In some feasible implementations, the intelligent analysis module 5 pre-collects information such as the name, function, input parameters, output parameters, and calling protocol of each interface. The large model learns from this information and interface call logs to construct a service dependency graph. When a service experiences a response timeout, the system automatically retrieves the service's historical response time data, the real-time status of its upstream calling services and downstream dependent services, analyzes it in conjunction with the dependency graph, calculates the failure propagation probability based on the improved PageRank algorithm, and obtains the root cause service node based on the calculation results, generating root cause analysis results. If the response time of its downstream database service is also found to be abnormal, the root cause of the failure is determined to be the database service, and a handling suggestion of "restarting the database service and then performing a connection test via Jmeter" is generated. After the operation and maintenance personnel execute the suggestion, Jmeter immediately tests the service and related dependent services, and feeds back the test results to the failure analysis module to confirm whether the failure has been resolved.

[0064] Preferably, the edge weights of the dynamic dependency graph are calculated as follows:

[0065] ;

[0066] In the formula, Let be the edge weight, representing the dependency strength of service j calling service i. The historical call frequency weighting coefficient is preferably 0.7. The real-time error rate weighting coefficient is preferably 0.3. The historical call frequency of service j to service i. The real-time error rate of service j.

[0067] The historical call frequency calculation method includes: querying the time-series database in the Prometheus server to find the total number of times service j calls service i within a preset historical time period; calculating the total number of calls to service j; and applying the formula... The historical call frequency value is calculated.

[0068] The real-time error rate calculation method includes: counting the total number of service j calls within a sliding time window from the time-series database in the Prometheus server using the stream processing engine; counting the number of error responses and timeouts of service j within the same time window; and calculating the error rate according to the formula. The real-time error rate is calculated.

[0069] Specifically, if the faulty service node in the alarm event issued by Prometheus server 4 is the bank gateway (B), then the service information related to the current alarm, including historical call relationships and monitoring data, is retrieved from the database of Prometheus server 4. Specifically, the historical call relationships show that the upstream service node of the faulty service node, the bank gateway (B), is the payment service (P), and the upstream of the payment service (P) is the order service (O). That is, the order service (O) calls the payment service (P), and the payment service (P) calls the bank gateway (B). Based on this, the dependency graph is as follows: Figure 2 As shown. The result is calculated based on the above formula. The edge weight is , The edge weight is .

[0070] In some feasible implementations, the improved PageRank algorithm includes:

[0071] ;

[0072] In the formula, Let represent the failure propagation probability of service i, d represent the damping coefficient (preferably 0.85), and N represent the number of nodes. Let the edge weights be represented as the edge weights between service j and service i. Represented as real-time anomaly factors, The out-degree of a node is represented by the number of downstream service nodes. Let be the probability of fault propagation for service j;

[0073] The real-time anomaly factor The calculation formula is:

[0074] ;

[0075] In the formula, This represents the number of errors in service j. This represents the number of timeouts for service j. This is expressed as the error count normalization threshold, preferably 10. This represents the normalized threshold for the number of timeouts, preferably 5.

[0076] Specifically, in combination Figure 3 As shown, using the example above, the number of errors for service B is 15, and the number of timeouts is 10. The root cause calculation process includes:

[0077] Initialize the faulty node by using faulty node B as the initial faulty node. ;

[0078] In the dependency graph, the initial fault node is taken as the first node to be traversed, and all nodes are traversed in the direction from downstream to upstream. In this embodiment, all nodes are the bank gateway (B), payment service (P) and order service (O), and the traversal order is bank gateway (B), payment service (P) and order service (O).

[0079] The edge weight between the two service nodes is calculated based on historical call frequency and real-time error rate, including... , ;

[0080] The PR value of each service node is calculated by superimposing real-time anomaly factors;

[0081] include ;

[0082] ;

[0083] ;

[0084] The fault propagation probability PR ranking results for output service i are as follows: [B(1.0), P(0.815), O(0.161)];

[0085] Based on the sorting results, the root cause service nodes that have failed are output, and root cause analysis results are generated, including: the bank gateway (B) is identified as the root cause, and the analysis result is interface timeout.

[0086] The improved PageRank algorithm in the aforementioned intelligent analysis module, compared to the original PageRank algorithm, distinguishes the dependence strength between core services and edge services by introducing dynamic edge weights; and by injecting fault factors, it captures the impact of instantaneous service anomalies on propagation compared to the static topology structure of the original PageRank algorithm. The original PageRank algorithm is mostly used in the field of web page ranking, and this embodiment reconstructs it into a fault propagation model, which effectively adapts to the causal reasoning of operation and maintenance monitoring scenarios.

[0087] The alarm module dynamically suppresses downstream service alarms based on the root cause analysis results, including: only sending bank gateway (B) alarms to suppress payment service alarms.

[0088] In some feasible implementations, combined with Figure 4 The following is a timing diagram of the system. The process includes:

[0089] Operations personnel upload test scripts; JMeter sends a request to the Target based on the test scripts; the Target (target interface) returns a response to JMeter; JMeter pushes metrics to PushGW for intermediate storage; the Prometheus server pulls data from PushGW; the Prometheus server evaluates alarm rules based on the pulled data; the Prometheus server sends alarm events to the AlertManager; the intelligent engine large model built into the intelligent analysis module is invoked to trigger root cause analysis and execute the localization algorithm; a root cause report is returned; the AlertManager sends concise alarms to operations personnel; operations personnel handle the fault based on the alarm information; after the fault is handled, verification tests are triggered; the service status is displayed in the service status display module (Grafana).

[0090] The above implementation method, through an innovative three-pronged approach of "proactive detection and modification + dynamic dependency graph construction + root cause localization algorithm," solves three long-standing pain points in the operation and maintenance field: inaccurate localization, slow response, and rampant alarms. The beneficial effects of this system can be detailed in terms of technical implementation, tool adaptation, and fault handling efficiency.

[0091] 1. Clear and concise implementation process: The system specifically explains the technical solutions and software selections used for each functional module. For example, it clearly states that JMeter is used for interface testing, Prometheus is responsible for data collection and storage, Grafana is used for visualization, and AlertManager handles alerts. This clear technical path and tool division of labor makes the system's construction logic, data flow process, and the collaborative relationships between modules readily apparent, facilitating understanding, deployment, and maintenance by technical personnel and lowering the barrier to system implementation.

[0092] 2. Enhanced Adaptability and Extensibility of JMeter: Meeting Diverse Testing Needs: By improving the JMeter plugin source code, it can proactively push data to PushGateway, adapting to Prometheus's data collection mode. This allows JMeter to not only perform traditional stress testing but also meet the needs of single or limited service health status assessments, covering monitoring and testing tasks in different scenarios. Support for High-Concurrency Scenarios: JMeter itself has the ability to simulate multiple user concurrent requests. Combined with system optimizations to its plugins, it can still run stably and accurately push data in high-concurrency scenarios, improving the system's adaptability to complex business environments.

[0093] 3. Significantly Improved Operation and Maintenance Efficiency: Proactive Fault Discovery: The system uses Jmeter to monitor service status periodically, Prometheus to collect data in real time, and AlertManager to push timely alerts. This changes the traditional operation and maintenance model of passively waiting for fault reports, enabling proactive discovery of service anomalies (such as response timeouts, offline status, etc.) and hardware resource issues (such as high CPU load, insufficient hard drive capacity, etc.). Rapidly Locating the Root Cause of Faults: The intelligent analysis module uses large-scale model learning of interface interaction data to build a dynamically updated service dependency graph. When a service anomaly occurs, it combines real-time monitoring data with an improved PageRank algorithm to calculate the probability of fault propagation, quickly locating the initial root cause node (such as downstream database anomalies causing upstream service timeouts), avoiding the inefficient process of blind troubleshooting in traditional operation and maintenance.

[0094] 4. Assisted efficient handling: The system generates targeted handling suggestions based on the fault type and service importance, and verifies the results again through Jmeter after handling, forming a closed loop of "discovery-location-handling-verification", which greatly shortens the fault resolution time and improves the overall stability of the information system.

[0095] It is worth mentioning that all modules involved in this embodiment are logical units. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this invention, this embodiment does not introduce units that are not closely related to solving the technical problem proposed by this invention; however, this does not mean that other units are absent from this embodiment.

[0096] Example 2

[0097] Please see Figure 5 This embodiment provides a flowchart of an interface service status analysis method based on distributed testing and monitoring.

[0098] As an example, the method is applied to the interface service status analysis system based on distributed testing and monitoring described in Embodiment 1, and the method includes:

[0099] Step S1: Generate test scripts based on the user-written test process and send them to the improved JMeter server.

[0100] Step S2: The improved JMeter server receives the test script and sends a simulation request to the target interface, collects the test result data of the target interface, and actively pushes the data to the indicator data transfer module.

[0101] Step S3: The Prometheus server pulls the data sent by the Jmeter server module from the indicator data transfer module and stores it, and determines whether to trigger an alarm event according to the pre-configured alarm rules.

[0102] Step S4: The dependency graph construction unit constructs a dynamic dependency graph based on the alarm event received from the Prometheus server, by obtaining service information related to the alarm event from the Prometheus server. Here, nodes represent services, and the weights of edges are calculated using historical call frequency and real-time error rate.

[0103] Step S5: The fault location unit uses the improved PageRank algorithm to calculate the fault propagation probability, and based on the calculation results, obtains the root cause service node where the fault occurred, and generates the root cause analysis results.

[0104] Step S6: The alarm module dynamically suppresses downstream service alarms based on the root cause analysis results, including: retaining only the alarms of the root cause service.

[0105] It is not difficult to see that this embodiment is a method embodiment corresponding to the first embodiment, and this embodiment can be implemented in conjunction with the first embodiment. The relevant technical details mentioned in the first embodiment are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the first embodiment.

[0106] Example 3

[0107] This invention also proposes a storage medium storing an interface service status analysis method based on distributed testing and monitoring. When the interface service status analysis program based on distributed testing and monitoring is executed by a processor, it implements the steps of the interface service status analysis method based on distributed testing and monitoring as described above. Since this storage medium adopts all the technical solutions of all the above embodiments, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be repeated here.

[0108] Example 4

[0109] Please see Figure 6 The present invention also provides an electronic device, including: a memory and a processor; the memory stores at least one program instruction; the processor loads and executes the at least one program instruction to implement the interface service status analysis method based on distributed testing and monitoring provided in Embodiment 2.

[0110] The memory 702 and processor 701 are connected via a bus, which may include any number of interconnecting buses and bridges, connecting various circuits of one or more processors 701 and memory 702 together. The bus may also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver may be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 701 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 701.

[0111] Processor 701 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 702 can be used to store data used by processor 701 during operation.

[0112] The above descriptions are merely embodiments of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, based on the guidance provided in this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. An interface service status analysis system based on distributed testing and monitoring, characterized in that, The system includes: a test script generation module, an improved Jmeter server, a metric data transfer module, a Prometheus server, an intelligent analysis module, and an alarm module; The test script generation module is used to generate test scripts based on user-written test processes and send them to the improved JMeter server. The improved JMeter server is used to receive test scripts and send simulation requests to the target interface, collect test result data from the target interface, and actively push the data to the indicator data transfer module. The improved JMeter server includes: adding an active probe adapter to the original JMeter server, including modifying the jmeter-prometheus-plugin source code and removing the built-in web server; adding a result encapsulation layer to package single test result data in Prometheus format; and actively pushing the single test result data to the indicator data transfer module via HTTP API. The Prometheus server is used to pull data sent by the Jmeter server module from the indicator data transfer module for storage, and to determine whether to trigger an alarm event based on the pre-configured alarm rules. The intelligent analysis module integrates a dependency graph construction unit and a fault location unit. The dependency graph construction unit is used to construct a dynamic dependency graph based on the alarm events sent by the Prometheus server and the service information related to the alarm events in the Prometheus server. Here, nodes are services, and edge weights are calculated by historical call frequency and real-time error rate. The fault location unit is used to calculate the fault propagation probability based on the improved PageRank algorithm, and to obtain the root cause service node of the fault based on the calculation result, and generate the root cause analysis result. The alarm module is used to dynamically suppress downstream service alarms based on the root cause analysis results, including: retaining only alarms from the root cause service.

2. The interface service status analysis system based on distributed testing and monitoring according to claim 1, characterized in that, The system also includes a service status display module and other cloud server monitoring modules; The service status display module is used to query data in the Prometheus server through PromQL and create a dashboard to display the online status of the service. The other cloud server monitoring module is used to monitor the operating status of hardware resources by installing Exporter software on the edge cloud server and transmit the monitoring results to the Prometheus server. The Prometheus server compares the hardware resource operating status with preset alarm rules, and sends hardware alarm events directly to the alarm module based on the comparison results.

3. The interface service status analysis system based on distributed testing and monitoring according to claim 2, characterized in that, The data pulled by the Prometheus server includes one or a combination of service online status, response latency, stress test results, CPU load of hardware resources, and hard disk capacity data.

4. The interface service status analysis system based on distributed testing and monitoring according to claim 1, characterized in that, The edge weights of the dynamic dependency graph are calculated as follows: ； In the formula, Let be the edge weight, representing the strength of the dependency between service j and service i. The historical call frequency weighting coefficient, This is the weighting coefficient for the real-time error rate. The historical call frequency of service j to service i. The real-time error rate for service j.

5. The interface service status analysis system based on distributed testing and monitoring according to claim 4, characterized in that, The method for calculating the historical call frequency includes: Query the total number of times service j calls service i within a preset historical time period from the time-series database on the Prometheus server; Calculate the total number of calls to service j; According to the formula The historical call frequency value is calculated.

6. The interface service status analysis system based on distributed testing and monitoring according to claim 4, characterized in that, The real-time error rate calculation method includes: The stream processing engine calculates the total number of service j calls within a sliding time window from the time-series database on the Prometheus server. Count the number of error responses and timeouts for service j within the same time window; According to the formula The real-time error rate is calculated.

7. The interface service status analysis system based on distributed testing and monitoring according to claim 4, characterized in that, The improved PageRank algorithm includes: ； In the formula, Let represent the failure propagation probability of service i, d represent the damping coefficient, and N represent the number of nodes. Let the edge weights be represented as the edge weights between service j and service i. Represented as real-time anomaly factors, This is represented as the node's out-degree. Let be the probability of fault propagation for service j; The real-time anomaly factor The calculation formula is: ； In the formula, This represents the number of errors in service j. This represents the number of timeouts for service j. This is represented as the normalized threshold for the number of errors. This represents the normalized threshold for the number of timeouts.

8. The interface service status analysis system based on distributed testing and monitoring according to claim 1, characterized in that, The alarm module is used to send service alarms to designated recipients according to pre-configured routing rules. The service alarms include the service that has failed and the analysis results.

9. A method for analyzing the status of interface services based on distributed testing and monitoring, the method being applied to the interface service status analysis system based on distributed testing and monitoring as described in any one of claims 1-8, characterized in that, The method includes: Step S1: Generate test scripts based on the user-written test process and send them to the improved JMeter server; Step S2: The improved JMeter server receives the test script and sends a simulation request to the target interface, collects the test result data of the target interface, and actively pushes the data to the indicator data transfer module. Step S3: The Prometheus server pulls the data sent by the Jmeter server module from the indicator data transfer module and stores it, and determines whether to trigger an alarm event according to the pre-configured alarm rules. Step S4: The dependency graph construction unit constructs a dynamic dependency graph based on the alarm event sent by the Prometheus server. The graph obtains service information related to the alarm event from the Prometheus server. The nodes are services, and the weights of the edges are calculated by historical call frequency and real-time error rate. Step S5: The fault location unit uses the improved PageRank algorithm to calculate the fault propagation probability, and based on the calculation results, obtains the root cause service node where the fault occurred and generates the root cause analysis results. Step S6: The alarm module dynamically suppresses downstream service alarms based on the root cause analysis results, including: retaining only the alarms of the root cause service.

Images