Method, system, program product, medium and apparatus for dynamic detection of request parameters

Abstract

The application provides a method, system, program product, medium and device for dynamically detecting request parameters. The method comprises: reading and analyzing a configuration file according to a JVM starting parameter to obtain memory objects including a list of classes to be monitored, an alarm threshold and a list of alarm receiving objects; verifying the configuration file and the memory objects to obtain a verified configuration object and inject a configuration context; when a client class is loaded by the JVM, performing bytecode enhancement on the client class matching the classes in the list of classes to be monitored; when an application service initiates an HTTP request through the enhanced client class, detecting request parameters in real time according to the alarm threshold in the configuration context; and when the parameters exceed the threshold range, executing an alarm according to the list of alarm receiving objects. The method of the application can realize non-intrusive, real-time and dynamic detection and early warning of request parameters.

Description

Technical Field

[0001] This invention relates to the field of computer application technology, and more specifically, to a method, system, program product, medium, and device for dynamically detecting request parameters. Background Technology

[0002] In distributed systems and microservice architectures, HTTP requests are the mainstream method for inter-service communication. The Java technology ecosystem offers various HTTP client implementations, including the JDK's native HttpURLConnection, Apache HttpClient, and OkHttp. These clients all provide configuration capabilities for connection timeout and read timeout. Developers configure timeout parameters by explicitly calling relevant setting methods such as setConnectTimeout() and setReadTimeout() when instantiating HTTP client objects in their code; that is, they manually call methods like setConnectTimeout() and setReadTimeout() to set thresholds. Without explicit configuration, some HTTP clients may adopt infinite waiting or the operating system's default timeout strategy, easily leading to network call blocking. If the timeout parameters are set improperly, the client's underlying network library will execute corresponding waiting or interruption logic, directly affecting service stability. Therefore, it is necessary to effectively check the compliance of HTTP timeout configurations.

[0003] Currently, checking HTTP timeout configurations primarily relies on manual code review or static code analysis tools (such as SonarQube rule scanning). The core logic is to scan the code to determine if statements setting HTTP timeout parameters exist. However, this method has significant drawbacks in real-world production scenarios: First, the detection efficiency is low and the implementation cost is high. Large business systems contain tens of thousands of HTTP request call points, and manual line-by-line review is extremely time-consuming; existing static scanning tools can often only check the "existence of calls" at the syntax level, and it is difficult to dynamically determine whether the set values ​​are reasonable in the current business scenario. For example, setting internal service calls to 30 minutes is obviously unreasonable, but static tools may consider it "set" and pass.

[0004] Second, the detection coverage is incomplete and prone to omissions. Manual review is susceptible to fatigue and may lead to oversights; static analysis is difficult to cover scenarios that use reflection, dynamic proxies, or dynamically loaded parameters from configuration files; with frequent code iterations, if new code is deployed without rigorous review, timeout settings are easily overlooked, leading to thread pool exhaustion or service avalanche.

[0005] Third, there is a lack of real-time runtime detection and dynamic awareness capabilities. Traditional detection methods are only effective during the development or testing phase and cannot monitor the actual behavior in the production environment. If timeout parameters become abnormal due to changes in the configuration center, environment variable overriding, or third-party library upgrades, existing solutions cannot detect and intercept them in real time. The reason for this is that static analysis and runtime state are disconnected, lacking an effective mechanism for real-time interception, parameter acquisition, and compliance verification of HTTP requests at the bytecode execution level.

[0006] Therefore, there is an urgent need for a technical solution that can address the problems of existing technologies, such as HTTP timeout settings relying on manual review, low efficiency, easy omissions, the need for recompilation or restart for configuration changes, and the lack of real-time runtime monitoring. Summary of the Invention

[0007] To address the problems, or at least some of the problems, existing technologies, the present invention provides a method, system, storage medium, device, and computer program product for dynamically detecting request parameters. Through bytecode enhancement technology and an external configuration file loading mechanism, it achieves non-intrusive, real-time, and dynamic detection and early warning of request parameters.

[0008] According to a first aspect of the present invention, an embodiment of the present invention provides a method for dynamically detecting request parameters. The method includes: reading and parsing a configuration file used for detecting request parameters based on JVM (Java Virtual Machine) startup parameters to obtain a memory object including a list of classes to be monitored, an alarm threshold, and a list of alarm receiving objects; verifying the configuration file and the memory object to obtain a verified configuration object; injecting the verified configuration object into a configuration context; reading the list of classes to be monitored from the configuration context; when a client class loaded by the JVM matches a class in the list of classes to be monitored read from the configuration context, performing bytecode enhancement on the matching client class; when an application service initiates an HTTP request through the bytecode-enhanced client class, detecting the HTTP request parameters according to the alarm threshold in the configuration context; and when the HTTP request parameters do not meet the range of the alarm threshold, performing an alarm operation according to the list of alarm receiving objects.

[0009] According to the above embodiments of the present invention, on the one hand, by loading and parsing the configuration file based on JVM startup parameters, the monitoring scope, alarm threshold, and alarm objects can be dynamically specified. After loading, the configuration information is verified to ensure the legality and validity of the configuration, avoiding detection failure due to configuration errors. On the other hand, the client class to be monitored is dynamically enhanced through bytecode enhancement, without modifying the source code of the business application. The injection of request parameter detection logic can be completed at JVM startup, without affecting business operations or causing intrusion. Simultaneously, by combining with external configuration files, monitoring rules can be flexibly configured, enabling real-time interception and verification of HTTP request parameter values ​​at the bytecode execution level, achieving non-intrusive, real-time detection and alarming of HTTP request parameters.

[0010] In some embodiments of the present invention, the method further includes: starting a daemon thread to detect modification events for the configuration file; when the daemon thread detects a modification event, reading the new configuration file and updating the configuration context according to the new configuration file.

[0011] In some embodiments of the present invention, the method further includes: checking the modification time of the configuration file at a preset period; reading the new configuration file when the modification time changes, and updating the configuration context according to the new configuration file.

[0012] According to the above embodiments of the present invention, by automatically reading the new configuration content and updating the configuration context in real time when the configuration file is updated, dynamic refreshing and activation of monitoring rules such as monitoring scope, alarm thresholds, and alarm receiving objects can be achieved without restarting the JVM or application services. Therefore, hot updates of configuration rules can be supported without interrupting business operations, redeploying, or intruding on business code, significantly improving the flexibility and real-time performance of detection strategy adjustments. This meets the actual needs of distributed systems to dynamically change monitoring strategies during operation, while also improving system maintainability and scenario adaptability.

[0013] In some embodiments of the present invention, reading and parsing the configuration file used for detecting request parameters includes: reading the configuration file storage path specified in the JVM startup parameters and verifying the validity of the configuration file storage path; when the configuration file storage path passes the validity verification, performing structured parsing on the configuration file to obtain the memory object.

[0014] In some embodiments of the present invention, verifying the validity of the configuration file storage path includes checking whether the configuration file exists under the configuration file storage path and whether the current JVM process has read permissions.

[0015] In some embodiments of the present invention, the alarm rule threshold includes a low timeout threshold and a high timeout threshold, and the verification of the memory object includes: determining whether the low timeout threshold is greater than 0 and less than the high timeout threshold; if the determination is yes, the verification passes; if the determination is no, the verification fails, and the low timeout threshold and the high timeout threshold are replaced according to preset default values.

[0016] According to the above embodiments of the present invention, by judging whether the alarm rule threshold settings obtained by parsing the configuration file are reasonable, and automatically replacing the abnormal threshold with a preset default value when the alarm rule threshold settings are unreasonable, problems such as detection failure and service abnormality caused by unreasonable threshold settings can be avoided. At the same time, parameter correction can be completed without manual intervention, reducing operation and maintenance costs.

[0017] According to a second aspect of the present invention, an embodiment of the present invention provides a system for dynamically detecting request parameters. The system includes: a configuration parsing and hot-loading module, configured to perform the following operations: reading and parsing a configuration file for detecting request parameters based on JVM startup parameters to obtain a memory object including a list of classes to be monitored, an alarm threshold, and a list of alarm receiving objects; verifying the configuration file and the memory object to obtain a verified configuration object; and injecting the verified configuration object into a configuration context; a bytecode enhancement module, configured to read the list of classes to be monitored from the configuration context, and when a client class loaded by the JVM matches a class in the list of classes to be monitored read from the configuration context, perform bytecode enhancement on the matching client class; a real-time detection module, configured to detect HTTP request parameters based on the alarm threshold in the configuration context when an application service initiates an HTTP request through the bytecode-enhanced client class; and an intelligent alarm module, configured to perform an alarm operation based on the list of alarm receiving objects when the HTTP request parameters do not meet the range of the alarm threshold.

[0018] According to the above embodiments of the present invention, on the one hand, by loading and parsing the configuration file based on JVM startup parameters, the monitoring scope, alarm threshold, and alarm objects can be dynamically specified. After loading, the configuration information is verified to ensure the legality and validity of the configuration, avoiding detection failure due to configuration errors. On the other hand, the client class to be monitored is dynamically enhanced through bytecode enhancement, without modifying the source code of the business application. The injection of request parameter detection logic can be completed at JVM startup, without affecting business operations or causing intrusion. Simultaneously, by combining with external configuration files, monitoring rules can be flexibly configured, enabling real-time interception and verification of HTTP request parameter values ​​at the bytecode execution level, achieving non-intrusive, real-time detection and alarming of HTTP request parameters.

[0019] In some embodiments of the present invention, the configuration parsing and hot reloading module is further configured to perform the following operations: start a daemon thread to detect modification events for the configuration file; when the daemon thread detects a modification event, read the new configuration file and update the configuration context according to the new configuration file.

[0020] In some embodiments of the present invention, the configuration parsing and hot-loading module is further configured to perform the following operations: check the modification time of the configuration file according to a preset period; when the modification time changes, read the new configuration file and update the configuration context according to the new configuration file.

[0021] According to the above embodiments of the present invention, by automatically reading the new configuration content and updating the configuration context in real time when the configuration file is updated, dynamic refreshing and activation of monitoring rules such as monitoring scope, alarm thresholds, and alarm receiving objects can be achieved without restarting the JVM or application services. Therefore, hot updates of configuration rules can be supported without interrupting business operations, redeploying, or intruding on business code, significantly improving the flexibility and real-time performance of detection strategy adjustments. This meets the actual needs of distributed systems to dynamically change monitoring strategies during operation, while also improving system maintainability and scenario adaptability.

[0022] In some embodiments of the present invention, reading and parsing the configuration file used for detecting request parameters includes: reading the configuration file storage path specified in the JVM startup parameters and verifying the validity of the configuration file storage path; when the configuration file storage path passes the validity verification, performing structured parsing on the configuration file to obtain the memory object.

[0023] In some embodiments of the present invention, verifying the validity of the configuration file storage path includes checking whether the configuration file exists under the configuration file storage path and whether the current JVM process has read permissions.

[0024] In some embodiments of the present invention, the alarm rule threshold includes a low timeout threshold and a high timeout threshold, and the verification of the memory object includes: determining whether the low timeout threshold is greater than 0 and less than the high timeout threshold; if the determination is yes, the verification passes; if the determination is no, the verification fails, and the low timeout threshold and the high timeout threshold are replaced according to preset default values.

[0025] According to the above embodiments of the present invention, by judging whether the alarm rule threshold settings obtained by parsing the configuration file are reasonable, and automatically replacing the abnormal threshold with a preset default value when the alarm rule threshold settings are unreasonable, problems such as detection failure and service abnormality caused by unreasonable threshold settings can be avoided. At the same time, parameter correction can be completed without manual intervention, reducing operation and maintenance costs.

[0026] According to a third aspect of the present invention, an embodiment of the present invention provides a computer-readable storage medium having stored thereon computer-readable instructions, which, when executed by a processor, cause a computer to perform the following operations: the operations include the steps included in the method for dynamically detecting request parameters as described in any of the above embodiments.

[0027] According to a fourth aspect of the present invention, an embodiment of the present invention provides a computer device including a memory and a processor, the memory being used to store one or more computer-readable instructions, wherein the one or more computer-readable instructions, when executed by the processor, can implement the method for dynamically detecting request parameters as described in any of the above embodiments.

[0028] According to a fifth aspect of the present invention, an embodiment of the present invention provides a computer program product including a computer program, which, when executed by a processor, implements the method for dynamically detecting request parameters as described in any of the above embodiments.

[0029] As described above, the method, system, storage medium, device, and computer program product for dynamically detecting request parameters provided by the embodiments of the present invention, on the one hand, load and parse configuration files according to JVM startup parameters, dynamically specifying the monitoring scope, alarm threshold, and alarm objects, and verifying the configuration information after loading to ensure the legality and validity of the configuration and avoid detection failure due to configuration errors. On the other hand, it dynamically enhances the client class to be monitored through bytecode enhancement, without modifying the source code of the business application. The injection of request parameter detection logic can be completed at JVM startup, without being aware of or intrusive to the business operation. At the same time, monitoring rules can be flexibly configured by combining with external configuration files, enabling real-time interception and verification of HTTP request parameter values ​​at the bytecode execution level, achieving non-intrusive, real-time detection and alarming of HTTP request parameters. Attached Figure Description

[0030] Figure 1 This is a flowchart illustrating the method for dynamically detecting request parameters according to Embodiment 1 of the present invention; Figure 2 This is a flowchart illustrating the method for dynamically detecting request parameters according to Embodiment 2 of the present invention; Figure 3 This is a flowchart illustrating a configuration loading and bytecode enhancement method according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the system architecture for dynamically detecting request parameters according to Embodiment 3 of the present invention. Detailed Implementation

[0031] The various aspects of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. Well-known modules, units, and their connections, links, communications, or operations are not shown or described in detail. Furthermore, the described features, architectures, or functions can be combined in any way in one or more embodiments. Those skilled in the art should understand that the various embodiments described below are for illustrative purposes only and are not intended to limit the scope of protection of the present invention. It will also be readily understood that the modules, units, or processing methods in the embodiments described herein and shown in the accompanying drawings can be combined and designed in various different configurations.

[0032]

Example 1

[0033] like Figure 1 As shown, in Embodiment 1 of the present invention, the method may include at least the following steps S11, S12, S13, S14, S15, S16 and S17, which are described in detail below.

[0034] In step S11, the configuration file used for detecting request parameters is read and parsed according to the JVM virtual machine startup parameters to obtain a memory object including a list of classes to be monitored, alarm thresholds, and a list of alarm receiving objects.

[0035] The configuration file, for example, is a YML file, which includes: a target monitoring configuration item, used to configure a list of HTTP client classes to be detected / monitored (e.g., OkHttp, HttpClient, HttpURLConnection, etc.); a rule threshold configuration item, used to configure compliance thresholds for HTTP request timeout parameters, including low timeout thresholds and high timeout thresholds; and an alarm receiver configuration item, used to configure the recipients of alarm information, such as email addresses, mobile phone numbers, alarm groups, and maintenance personnel. By configuring the list of monitoring target classes, alarm receivers, and threshold policies in an external YML file, it is possible to dynamically adjust the monitoring scope and notification policies without restarting the application, in conjunction with a configuration center or file-based monitoring as described later.

[0036] In some implementations, reading and parsing the configuration file used for detecting request parameters includes: reading the configuration file storage path specified in the JVM startup parameters and validating the validity of the configuration file storage path; when the configuration file storage path passes the validity check, performing structured parsing on the configuration file to obtain the memory object. Validating the validity of the configuration file storage path includes: checking whether the configuration file exists under the configuration file storage path and whether the current JVM process has read permissions.

[0037] In step S12, the configuration file and memory object are verified to obtain the verified configuration object.

[0038] In some implementations, the alarm rule thresholds in the memory object include a low timeout threshold and a high timeout threshold; the verification of the memory object includes: determining whether the low timeout threshold is greater than 0 and less than the high timeout threshold; if the determination is yes, the verification passes; if the determination is no, the verification fails, and the low timeout threshold and the high timeout threshold are replaced according to preset default values.

[0039] In step S13, the verified configuration object is injected into the configuration context.

[0040] In a further embodiment, the method further includes: starting a daemon thread to detect modification events of the configuration file; when the daemon thread detects a modification event, reading the new configuration file, and updating the configuration context according to the new configuration file. The daemon thread is a background daemon thread (non-user thread) and will not block JVM exit; furthermore, the daemon thread is independent of the business thread pool and is set to low priority (Thread.setPriority(Thread.MIN_PRIORITY)), thereby reducing the performance impact on the host application.

[0041] For example, the above timed polling mode checks the last modified time (lastModified()) of the configuration file (such as a YML format configuration file) every 5 seconds by default.

[0042] In a further embodiment, the method further includes: checking the modification time of the configuration file at a preset period; reading the new configuration file when the modification time changes, and updating the configuration context according to the new configuration file.

[0043] For example, the above file change monitoring pattern uses the WatchService service of the Java NIO framework to listen for MODIFY events (modification events) in the directory where the configuration file is located, achieving real-time detection of configuration file changes. The file change monitoring pattern is used first to detect configuration file changes, with a timed polling pattern used as a fallback strategy.

[0044] By employing a dual-mode approach of "timed polling + file change monitoring" to monitor configuration file changes, the system automatically reads the new configuration content and updates the configuration context in real time when the configuration file is updated. This achieves dynamic refreshing and activation of monitoring rules, such as monitoring scope, alarm thresholds, and alarm recipients, without restarting the JVM or application services. Consequently, it supports hot updates of configuration rules without interrupting business operations, redeploying, or intruding on business code. This significantly improves the flexibility and real-time performance of monitoring strategy adjustments, meeting the practical needs of distributed systems for dynamically changing monitoring strategies during operation, while also enhancing system maintainability and scenario adaptability.

[0045] In step S14, the list of classes to be monitored is read from the configuration context.

[0046] In step S15, when the client class loaded by the JVM matches a class in the list of classes to be monitored read from the configuration context, bytecode enhancement is performed on the matching client class. By performing bytecode enhancement on the matching client class, request parameter detection logic can be automatically injected during the HTTP request execution phase without modifying the business source code. This allows for seamless deployment during JVM startup, achieving a zero-intrusion request parameter detection mechanism.

[0047] In step S16, when the application service initiates an HTTP request through the client class enhanced with bytecode, the HTTP request parameters are detected according to the alarm threshold in the configuration context.

[0048] In step S17, when the HTTP request parameters do not meet the range of the alarm threshold, an alarm operation is performed according to the alarm receiving object list.

[0049] The method for dynamically detecting request parameters described in Embodiment 1 of this invention, through bytecode enhancement technology and external configuration hot-loading mechanism, achieves non-intrusive, real-time, and dynamic detection and early warning of HTTP request timeout parameters. It can automatically intercept the request execution methods of all mainstream HTTP client libraries, with comprehensive detection coverage and no blind spots, achieving full-link detection coverage.

[0050]

Example 2

[0051] Sub-step S212: YML file reading and parsing. Create a YAML instance using the SnakeYAML library and read the configuration file content in a file stream manner to avoid memory overflow caused by loading a large file at once; parse the configuration content in the configuration file in a structured way and map it to a memory object: (1) Parse monitor.targets (monitoring objects / monitoring targets) into a List <string>(a list of strings) stores the fully qualified names of the HTTP client classes to be monitored; (2) parse rules.thresholds (rule thresholds / alarm rule thresholds) into a Map<String, Integer> (Integer mapping), extract min_timeout (minimum timeout time / low timeout threshold) and max_timeout (maximum timeout time / high timeout threshold); (3) parse alert.receivers (alarm receivers) into a List <alertreceiver>(List of alarm receiving objects), where the alarm receiving objects are custom entity classes containing fields such as name, type, id, address, and url.

[0052] Sub-step S213: Configuration validation and default value filling (threshold / recipient / monitoring target validation). The validity validation includes: verifying whether monitor.targets is not empty; if empty, a WARN log is printed, and the Agent only starts without executing bytecode enhancement; verifying whether min_timeout > 0 and max_timeout > min_timeout are satisfied; if not, an IllegalConfigException is thrown, and default values ​​are used (e.g., min=10s, max=120s); verifying whether the type of each recipient in alert.receivers is a valid value (wechat / email / webhook), marking recipients with missing fields as "invalid" and skipping them.

[0053] The default value population includes automatically populating built-in default values ​​for fields that are not configured (e.g., min_timeout is not defined).

[0054] Sub-step S214: Configure global context injection. Inject the parsed and validated configuration object into a thread-safe singleton configuration context (ConfigContext): The ConfigContext singleton uses volatile to modify the core configuration fields to ensure visibility in a multi-threaded environment; it provides getXXX() methods (such as getMonitorTargets() / getThresholds()) for subsequent modules to call, and all read operations are lock-free, only write operations are locked.

[0055] Sub-step S215: Start configuration hot update listener. Start a background daemon thread (non-user thread, to avoid blocking JVM exit) and implement configuration listening using a dual mode of timed polling and file change listening: (1) Timed polling: by default, check the last modification time (lastModified()) of the YML file every 5 seconds; (2) File change listening: listen to the MODIFY event of the directory where the configuration file is located based on Java NIO's WatchService. In addition, the file change listening mode is used first, and the timed polling mode is used as a fallback strategy. Among them, the background daemon thread is independent of the business thread pool and is set to low priority (Thread.setPriority(Thread.MIN_PRIORITY)) to reduce the performance impact on the host application.

[0056] Sub-step S216: Output configuration loading result log. Output the configuration loading result to the host application's logging system or the Agent's independent log. For example, the specific log content is as follows: The [HTTP-Timeout-Detector] configuration was loaded successfully. Number of monitored target classes: java.net.HttpURLConnection (JDK native HTTP client class), org.apache.http.client.HttpClient (Apache HttpClient client class), okhttp3.OkHttpClient (OkHttp client class), com.example.custom.HttpClient (user-defined HTTP client class); Timeout thresholds: min=10s, max=120s; Valid alarm recipients: Zhang San (WeChat), Li Si (email), Operations Team (webhook); Hot update monitoring is enabled, monitoring file: / etc / http-detector / config.yml.

[0057] Step S22, bytecode enhancement (matching monitor.targets instrumentation). Read the monitor.targets list from ConfigContext, and only instrument classes in the list; skip classes that are not configured.

[0058] Step S23, runtime HTTP timeout detection. The latest threshold rules are read in real-time from the ConfigContext (the values ​​after hot updates take effect immediately), and timeout parameter verification is performed. In this embodiment, step S23 includes the following sub-steps S231 to S237: Sub-step S231 triggers the detection logic through instrumentation code to intercept the execution of HTTP requests.

[0059] Sub-step S232: Read the real-time configuration threshold and obtain the min_timeout and max_timeout parameters from the ConfigContext in real time.

[0060] Sub-step S233: Collect request timeout parameters and obtain values ​​such as connectTimeout and readTimeout.

[0061] Sub-step S234: Determine if the timeout parameter is valid. The verification condition is min_timeout ≤ timeout value ≤ max_timeout. If valid, proceed to sub-step S235; otherwise, proceed to sub-step S236.

[0062] Sub-step S235: Record normal logs, complete the instrumentation operation, do not trigger alarms, and request normal execution completion.

[0063] Sub-step S236: Collect exception details, including but not limited to: request URL, timeout value, call stack, timestamp, etc.

[0064] Sub-step S237: Encapsulate alarm data and generate a standardized exception information structure.

[0065] Step S24, alarm trigger. Read the latest alert.receivers list from ConfigContext, send alarms according to the configured type, and the configuration changes will take effect without restarting.

[0066] The method for dynamically detecting HTTP request timeout configuration based on Java Agent and external YML configuration described in Embodiment 2 of the present invention has the following beneficial effects:

[0067] I. Achieve truly non-intrusive deployment and configuration decoupling: Without requiring any modification to the business code, configuration information such as monitoring rules and alarm receiving objects (alarm notification personnel) is decoupled from business logic and centrally managed through external YML files. Operations personnel only need to modify the YML configuration file and specify its path to flexibly adjust parameters such as the HTTP client library to be monitored and the alarm receiving objects, without recompiling the Agent or modifying the business code, significantly reducing system maintenance costs.

[0068] 2. Real-time dynamic detection and hot configuration update at runtime: Overcoming the limitations of static analysis, it can capture the HTTP request timeout parameter value of the target class at runtime and compare it with the threshold parameter in memory. Combined with the YML configuration hot reloading mechanism, when the business scenario changes and the timeout threshold needs to be adjusted or the alarm duty personnel are changed, only the YML configuration file needs to be updated and the configuration will take effect immediately without restarting the application service, ensuring continuous business operation.

[0069] III. Achieving comprehensive monitoring coverage and high detection accuracy: Based on the underlying bytecode interception mechanism, it naturally supports any HTTP client class specified in the YML configuration file (including custom-implemented client classes), covering various HTTP request methods such as GET, POST, PUT, and DELETE; it can not only detect cases where timeout parameters are not set, but also accurately identify problems with unreasonable timeout parameter settings, ensuring the accuracy of detection results.

[0070] IV. Flexible alarm mechanism: Supports multi-dimensional alarm policies, centrally configures and manages alarm receiving objects, facilitating collaborative operation and maintenance by the team; can dynamically switch alarm receiving objects and alarm channels according to application configuration, helping the operation and maintenance team to quickly locate and fix potential network stability risks and improve system reliability.

[0071] Meanwhile, this invention provides a specific example of dynamically detecting HTTP request timeout parameters using the method of Embodiment 2 described above, which specifically includes the following steps: Step A. Prepare the configuration file Create a configuration file named config.yml in the specified directory on the server (e.g., / etc / http-detector / ), with the following content: # HTTP timeout detection configuration file monitor: # List of fully qualified HTTP client classes to be monitored; can be dynamically added to or removed from. targets: - "java.net.HttpURLConnection" - "org.apache.http.client.HttpClient" - "okhttp3.OkHttpClient" - "com.example.custom.HttpClient" # Supports custom clients rules: thresholds: min_timeout: 10 # Minimum allowed timeout (seconds) max_timeout: 120 # Maximum allowed timeout (seconds) alert: # Alarm receiver configuration, supporting multiple users receivers: - name: "Zhang San" type: "wechat" id: "zhangsan_wx_id" - name: "Li Si" type: "email" Address: "lisi@company.com" - name: "Operations and Maintenance Team" type: "webhook" url: "http: / / internal-monitor / alert" Step B. Configure JVM startup parameters Add the following JVM parameter to the startup script of the Java application that needs to be tested: -javaagent: / data / agents / http-timeout-detector-agent.jar \ -Ddetector.config.path= / etc / http-detector / config.yml Therefore, all rule configurations can be completed simply by specifying the configuration file path, without having to pass specific class names and person names through lengthy parameters.

[0072] Step C. Complete process of configuration loading and enhancement After the application restarts, the end-to-end execution process of configuration loading and bytecode enhancement is as follows: Figure 3 As shown, the specific steps include S301 to S314: In step S301, the JVM starts and loads the Agent JAR package via the javaagent parameter, and specifies the path to the external YML configuration file via the Ddetector.config.path parameter. The Agent's premain method triggers the entire configuration loading process.

[0073] Step S302: Call the System.getProperty("detector.config.path") method to read the Detector.config.path parameter.

[0074] Step S303: Verify whether the YML configuration file exists and whether the current Agent process has read permissions. If the YML configuration file does not exist or the permissions are insufficient, proceed to step S304; if the YML configuration file exists and read permissions are available, proceed to step S305.

[0075] In step S304, if the YML configuration file does not exist, terminate Agent initialization or downgrade to use the default configuration; if permissions are insufficient, print an ERROR log and exit.

[0076] Step S305: Create a Yaml instance using the SnakeYAML library and read the configuration file content as a file stream.

[0077] Step S306: Validate the configuration content in the configuration file (not empty / numerical / format). If the validation fails, proceed to step S307; if the validation passes, proceed to step S308. Verify if monitor.targets is not empty. If empty, print a WARN log, and the Agent will only start without performing bytecode enhancement. Verify if min_timeout > 0 and max_timeout > min_timeout. If not, throw an IllegalConfigException and use default values ​​(e.g., min=10s, max=120s). Verify if the type of each receiver in alert.receivers is a valid value (wechat / email / webhook). Receivers with missing fields are marked as "invalid" and skipped.

[0078] Step S307: Check if monitor.targets is not empty. If it is empty, print WARN (alarm) log. Check if min_timeout > 0 and max_timeout > min_timeout. If not, throw IllegalConfigException (configuration exception) and use the default values ​​(e.g., min=10s, max=120s).

[0079] Step S308: Configure the injection of the global context ConfigContext singleton.

[0080] Step S309: Start the configuration hot update listening thread.

[0081] Step S310: Output a log indicating successful configuration loading.

[0082] Step S311: Register ClassFileTransformer (class file converter).

[0083] Step S312: During class loading, the monitor.targets list is read from ConfigContext. It is determined whether the client class loaded by the JVM matches the class in the monitor.targets list read from ConfigContext. If they match, step S313 is executed; otherwise, step S314 is executed.

[0084] Step S313: Perform bytecode enhancement on the matched client class to insert a detection probe.

[0085] Step S314: Skip the client classes that are not matched and do not modify them.

[0086] Step D. Runtime Detection and Dynamic Adjustment Configure hot update: First, perform the following operations: Edit / etc / http-detector / config.yml, add a new monitoring class com.newlib.Client, and change the alarm recipient to "Wang Wu (WeChat ID: wangwu_wx_id)"; then, configure awareness: The Agent's hot update thread (WatchService) detects a file modification event and triggers the following configuration reload process: lock the configuration context, read the configuration content in the new configuration file; verify the new configuration, i.e., the new class name format and alarm recipient information; after verification, update monitor.targets and alert.receivers in ConfigContext; after the update is complete, release the lock and output / print the configuration hot update success log: [HTTP-Timeout-Detector] Configuration hot update successful: 1 new monitoring class added, alarm recipient updated to 1 (Wang Wu (wechat)).

[0087] The effects of configuring hot updates are as follows: For unloaded com.newlib.Client classes, bytecode enhancement will be automatically triggered the next time they are loaded; for classes that have already been loaded: the Agent calls the Instrumentation.retransformClasses() method to redefine the class and insert detection probes; HTTP requests initiated by newly added monitoring classes (initiated by com.newlib.Client) will immediately use the latest configuration (new threshold) to perform detection, and alarm messages will be synchronously pushed to the updated alarm receiving objects, without requiring the application service to be restarted throughout the process.

[0088]

Example 3

[0089] like Figure 4 As shown, the system includes: a configuration parsing and hot-loading module 410, a bytecode enhancement module 420, a real-time detection module 430, and an intelligent alarm module 440.

[0090] The configuration parsing and hot reloading module 410 is used to parse the YML file path in the JVM startup parameters, load and parse the YML content, cache the monitoring rules and notification information in memory, and support timed refresh or listening for file changes to update the configuration.

[0091] The configuration parsing and hot-loading module serves as the "configuration hub" of the entire system, responsible for managing the entire lifecycle of configuration files, from reading, parsing, and validating to dynamic updates. In some implementations, the configuration parsing and hot-loading module specifically includes the following four sub-units: (1) Path parsing unit The path resolution unit is used to read the Ddetector.config.path system property and parse the absolute path of the configuration file. Furthermore, it supports automatic conversion between relative and absolute paths and environment variable replacement (such as ${DETECTOR_CONFIG_PATH}) to ensure compatibility with different system deployment environments.

[0092] (2) Configure the parsing unit The configuration parsing unit uses the SnakeYAML library to parse the configuration and packages the relevant dependencies into the Agent JAR package to avoid dependency conflicts with the host application.

[0093] The parsing logic of the configuration parsing unit is as follows: a custom Constructor and TypeDescription are used to directly map YML configuration file nodes to the corresponding Java entity classes (instead of a loose Map), which can improve configuration reading efficiency and structured management capabilities.

[0094] For example, the parsed objects include: configuration of the target to be monitored, configuration of timeout threshold rules, configuration of alarm receiving objects, and global configuration; the entity classes include: / / Monitoring configuration entity public class MonitorConfig { private List <string>targets; / / Corresponds to monitor.targets } / / Threshold rule entity public class ThresholdRule { private int min_timeout; private int max_timeout; } / / Alarm Recipient Entity public class AlertReceiver { private String name; private String type; / / wechat / email / webhook private String id; / / Qiwei ID private String address; / / Email address private String url; / / Webhook address } / / Global configuration entity public class GlobalConfig { private MonitorConfig monitor; private ThresholdRule rules; private List <alertreceiver>alert; } (3) Configure the verification unit The configuration verification unit is used to verify the validity of the parsed configuration to prevent invalid configurations from causing Agent abnormalities. Its verification rules are as follows: Non-empty check: monitor.targets cannot be empty (otherwise the Agent has no monitoring targets); Numerical verification: min_timeout > 0 and max_timeout > min_timeout; Format validation: The type in alert.receivers must be a valid value; email type must match the email regular expression; webhook type must be a valid URL.

[0095] (4) Hot update unit The implementation methods of hot update units include: Basic solution: Use a timed polling method to check the last modified time of the file every 5 seconds. If it is inconsistent with the time recorded in memory, reload the file. Advanced solution: Use WatchService based on Java NIO to listen for the MODIFY event in the directory where the configuration file is located, and trigger a reload immediately after the file is modified; Thread safety: When reloading the configuration (configuration update), write operations on ConfigContext are locked with ReentrantLock to ensure data consistency in a multi-threaded environment, thereby avoiding "dirty data" when reading the configuration; Loading logic: When reloading, the original configuration (historically valid configuration) is retained as a fallback strategy. If the new configuration fails to be parsed, it is rolled back to the old configuration and an ERROR log is printed.

[0096] The bytecode enhancement module 420 is used to dynamically identify and modify the bytecode of the target HTTP client class based on the "monitoring class list" configured in YML, according to the ASM or ByteBuddy framework, and inject detection probes.

[0097] In this embodiment, the core adaptation logic of the bytecode enhancement module is as follows: obtain the monitor.targets list from the configuration context ConfigContext, perform bytecode enhancement only on classes in the list, and allow unconfigured classes directly, effectively reducing system performance loss; the hot update adaptation logic is as follows: when a new monitoring class is added, if the class has not yet been loaded by the JVM, bytecode instrumentation will be automatically triggered on the next load; if the class has been loaded, class redefinition will be triggered through Instrumentation.retransformClasses() to achieve runtime dynamic enhancement. The Agent needs to enable class retransformation support configuration (Can-Retransform-Classes: true).

[0098] The real-time detection module 430, also known as the rule validation engine / real-time detection engine, has a built-in timeout parameter validation strategy (such as non-zero check and threshold range check) to read the dynamic threshold configuration in YML for comparison.

[0099] In this embodiment, the core adaptation logic of the real-time detection module is as follows: each time the HTTP request timeout parameter detection is performed, the latest threshold rule is read from the configuration context ConfigContext instead of using the static configuration at initialization, to ensure that the detection rule can take effect in real time after the configuration is hot-updated; the performance optimization logic is as follows: the threshold rule adopts a lock-free read + copy-on-write mechanism to avoid the impact of frequent locking operations on the detection performance.

[0100] The intelligent alarm module 440 is used to construct alarm messages and, based on the recipient list configured in YML, connect to notification channels such as WeChat and email to push risk information to designated responsible persons.

[0101] In this embodiment, the core adaptation logic of the intelligent alarm module is as follows: when an alarm is triggered, the alarm receiving object list is read from the configuration context ConfigContext in real time. After adding, deleting or modifying the alarm receiving object, the alarm target can be updated synchronously without restarting the application service.

[0102] In a further embodiment, the system also includes a context management module ( Figure 4 (Not shown in the image) is used to maintain the current application's configuration state, alarm receiver mapping, and detection state in memory, enabling hot updates of configuration parameters in memory.

[0103] This embodiment's system for dynamically detecting request parameters is based on a Java JDK 1.8+ environment, utilizing the java.lang.instrument.Instrumentation interface and bytecode manipulation libraries (such as ByteBuddy or ASM), and incorporating SnakeYAML as the configuration parsing engine. The system's workflow includes the following stages:

[0104] (1) Startup phase: JVM starts -> reads -javaagent parameters -> parses the YML file path specified by -Ddetector.config.path -> loads YML configuration (monitoring class list, notifiers, thresholds) -> registers ClassFileTransformer (class file converter).

[0105] (2) Class loading phase: JVM loads class -> Transformer intercepts -> compares with the list of monitored classes in YML -> if a match is found, modifies the bytecode (inserts detection logic at the entry point of the key method) -> defines the enhanced class.

[0106] (3) Operation phase: Business code initiates HTTP request -> executes enhanced method -> triggers detection probe -> reads the latest YML configuration strategy in memory -> verifies timeout parameter -> (if abnormal) sends alarm according to the notifier in YML configuration / (if normal) allows request.

[0107] (4) Configuration update phase: The scheduled task or file listener detects a change in the YML file -> re-parses the YML -> updates the configuration cache in memory -> the new strategy takes effect immediately for subsequent requests.

[0108] The system employing the dynamic request parameter detection described in Embodiment 3 of this invention utilizes Java Instrumentation API (JVMTI) technology to dynamically enhance the bytecode of the HTTP client core class during the JVM class loading phase or runtime. Simultaneously, an external YML configuration-driven mechanism is introduced. Upon agent startup, it reads the specified YML configuration file, parsing out configuration items such as the "list of fully qualified HTTP class names to be monitored," the "list of alarm recipients," and the "timeout threshold policy." Then, before the HTTP request actually initiates network I / O, custom detection logic is inserted to obtain the current timeout configuration parameters in real time and verify them according to the security policy defined in the YML configuration file. Once a preset risk threshold is triggered, the system immediately executes the corresponding alarm operation, achieving dynamic monitoring and early warning of HTTP request timeout parameters.

[0109] Through the above description of the embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software combined with a hardware platform. Based on this understanding, all or part of the technical solution of the present invention that contributes to the background art can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of the present invention.

[0110] Correspondingly, embodiments of the present invention also provide a computer-readable storage medium storing computer-readable instructions or programs thereon. When executed by a processor, the computer-readable instructions or programs cause a computer to perform the following operations, which include the steps included in the method described in any of the above embodiments, and will not be repeated here. The storage medium may include, for example, an optical disc, a hard disk, a floppy disk, flash memory, magnetic tape, etc.

[0111] Furthermore, embodiments of the present invention also provide a computer device including a memory and a processor. The memory is used to store one or more computer-readable instructions or programs, wherein the one or more computer-readable instructions or programs, when executed by the processor, can implement the steps of the method described in any of the above embodiments. The computer device may be, for example, a server, a desktop computer, a laptop computer, a tablet computer, etc.

[0112] This invention also provides a computer program product including a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the steps of the methods provided in the embodiments of this disclosure.

[0113] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on a user's computing device, partially on a user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0114] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. Therefore, the scope of protection of the present invention should be determined by the claims.< / alertreceiver> < / string> < / alertreceiver> < / string>

Claims

1. A method for dynamically detecting request parameters, characterized in that, The method includes: The configuration file used for detecting request parameters is read and parsed based on the JVM startup parameters to obtain an in-memory object including a list of classes to be monitored, alarm thresholds, and a list of alarm receiving objects; The configuration file and memory object are validated to obtain the validated configuration object. Inject the verified configuration object into the configuration context; Read the list of classes to be monitored from the configuration context; When the client class loaded by the JVM matches a class in the list of classes to be monitored read from the configuration context, bytecode enhancement is performed on the matching client class; When the application service initiates an HTTP request through the bytecode-enhanced client class, the HTTP request parameters are detected according to the alarm threshold in the configuration context; When the HTTP request parameters do not meet the range of the alarm threshold, an alarm operation is performed according to the list of alarm receiving objects.

2. The method as described in claim 1, characterized in that, The method further includes: Start a daemon thread to detect modification events related to the configuration file; When the daemon thread detects a modification event, it reads the new configuration file and updates the configuration context according to the new configuration file.

3. The method as described in claim 1, characterized in that, The method further includes: The modification time of the configuration file is checked according to a preset cycle; When the modification time changes, the new configuration file is read, and the configuration context is updated according to the new configuration file.

4. The method as described in claim 1, characterized in that, The process of reading and parsing the configuration file used to detect request parameters includes: Read the configuration file storage path specified in the JVM startup parameters and verify the validity of the configuration file storage path; When the configuration file storage path passes the validity check, the configuration file is parsed in a structured manner to obtain the memory object.

5. The method as described in claim 4, characterized in that, Verifying the validity of the configuration file storage path includes: Check if the configuration file exists in the specified configuration file storage path, and whether the current JVM process has read permissions.

6. The method as described in claim 1, characterized in that, The alarm rule thresholds include a low timeout threshold and a high timeout threshold, and the verification of the memory object includes: Determine whether the low timeout threshold is greater than 0 and less than the high timeout threshold; If the determination is yes, then the verification passes; If the determination is negative, the verification fails, and the low timeout threshold and high timeout threshold are replaced according to the preset default values.

7. A system for dynamically detecting request parameters, characterized in that, The system includes: Configure the parsing and hot-loading module to perform the following operations: The configuration file used for detecting request parameters is read and parsed based on the JVM startup parameters to obtain an in-memory object including a list of classes to be monitored, alarm thresholds, and a list of alarm receiving objects; The configuration file and memory object are validated to obtain the validated configuration object. Inject the verified configuration object into the configuration context; The bytecode enhancement module is used to read the list of classes to be monitored from the configuration context, and when the client class loaded by the JVM matches the class in the list of classes to be monitored read from the configuration context, perform bytecode enhancement on the matching client class. The real-time detection module is used to detect HTTP request parameters based on the alarm threshold in the configuration context when the application service initiates an HTTP request through the client class enhanced by bytecode. The intelligent alarm module is used to perform an alarm operation based on the list of alarm recipients when the HTTP request parameters do not meet the range of the alarm threshold.

8. A computer-readable storage medium storing computer-readable instructions, characterized in that, The computer-readable instructions are executed by a processor to implement the steps of the method as described in any one of claims 1-6.

9. A computer device comprising a memory and a processor, The memory stores computer-readable instructions, characterized in that, The processor executes the computer-readable instructions to implement the steps of the method as claimed in any one of claims 1-6.

10. A computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1-6.

Images