Business service parameter acquisition method and device, storage medium and computer equipment

Abstract

The invention relates to the technical field of computers and the technical field of medical treatment and health, and discloses a business service parameter acquisition method and device, a storage medium and computer equipment, and the method comprises the steps: calling a data acquisition program in a target terminal where a target application program is located, acquiring request parameter data corresponding to a business service request sent by the target application program to the server in real time, and response parameter data of a request response result returned by the server to the target application program based on the business service request; when monitoring that the target terminal is in a high-load state, acquiring request parameter data of a target business service request hitting a preset low-load data acquisition rule, and response parameter data of each request response result belonging to the same business service link as the target business service request; through a parameter acquisition function supporting automatic degradation, normal operation of a host application can be guaranteed while access parameter acquisition is completed, and the troubleshooting efficiency is improved.

Description

Technical Field

[0001] This application relates to the fields of computer technology and medical health technology, and particularly to a method and device for collecting business service parameters, a storage medium, and a computer device. Background Art

[0002] In the field of medical health technology, communication and data interaction between services are equally crucial. Among them, the Dubbo framework, as the core technology for accessing business service requests, plays a pivotal role. However, in the daily operation and maintenance of medical systems and problem troubleshooting, accurately locating the source of problems in Dubbo requests often depends on in-depth analysis of their request parameters (input parameters) and response parameters (output parameters). Currently, the following methods are mainly used in the industry to achieve this goal:

[0003] One traditional approach is to manually write code to print the input and output parameter information of Dubbo requests to a log file. Although this method can meet basic requirements to a certain extent, it brings a significant workload burden, and due to the lack of a unified coding standard among different development teams, it is difficult to keep the format and content of log information consistent, posing additional challenges to subsequent problem analysis. Another more advanced and efficient way is to utilize the Dubbo parameter collection function provided by the Agent side of the open-source project SkyWalking. Through bytecode enhancement technology, this technology can automatically collect the required parameter information during the processing flow of Dubbo requests without manual coding intervention, thus greatly reducing the access cost. However, although this method performs well in terms of convenience, it also has some limitations that cannot be ignored, such as relatively large performance loss and currently does not support the collection function of output parameters. Summary of the Invention

[0004] In view of this, this application provides a method and device for collecting business service parameters, a storage medium, and a computer device. Through a parameter collection function that supports automatic degradation, it can ensure the normal operation of the host application while completing the collection of input and output parameters, and improve the efficiency of problem troubleshooting.

[0005] According to one aspect of this application, a method for collecting business service parameters is provided. The method includes:

[0006] Invoke the data collection program in the target terminal where the target application is located to collect the request parameter data corresponding to the business service request sent by the target application to the server in real time, and the response parameter data of the request response result returned by the server to the target application based on the business service request. When a user performs an interaction operation on the target application, at least one microservice business is triggered. The request response results returned by each microservice business triggered by the same interaction operation, together with the business service request triggered by the interaction operation, form a business service link.

[0007] Monitor in real time whether the target terminal where the target application is located is in a high-load state.

[0008] When it is monitored that the target terminal is in a high-load state, invoke the data collection program of the target terminal to collect the request parameter data corresponding to the target business service request that hits the preset low-load data collection rule, and the response parameter data of each request response result in the same business service link as the target business service request until the target terminal returns to a low-load state.

[0009] Optionally, the real-time monitoring of whether the target terminal where the target application is located is in a high-load state includes:

[0010] Monitor in real time the target performance parameter value corresponding to any one of the multiple preset performance parameters in the target terminal where the target application is located. The preset performance parameters include at least one of the virtual machine garbage collection frequency, CPU usage rate, and memory occupancy rate. The virtual machine garbage collection frequency includes the young generation garbage collection frequency and the full garbage collection frequency.

[0011] When it is monitored that the target performance parameter value is greater than or equal to the preset overload threshold corresponding to the target performance parameter, the target terminal where the target application is located is in a high-load state.

[0012] When it is monitored that the target performance parameter value is less than the preset overload threshold corresponding to the target performance parameter, the target terminal where the target application is located is in a low-load state.

[0013] Optionally, the preset low-load data collection rules include a full-volume collection strategy and a sampling collection strategy. The target business service requests include abnormal business service requests and normal business service requests. The collection of the request parameter data corresponding to the target business service request that hits the preset low-load data collection rule, and the response parameter data of each request response result in the same business service link as the target business service request, includes:

[0014] In the business service requests sent by the target application to the server, identify the abnormal business service requests containing error messages and the normal business service requests not containing error messages;

[0015] Collect the request parameter data and response parameter data in the business service link where the abnormal business service request is located based on the full - volume collection strategy, and collect the request parameter data and response parameter data in the business service link where the normal business service request is located based on the sampling collection strategy.

[0016] Optionally, the step of collecting the request parameter data and response parameter data in the business service link where the abnormal business service request is located based on the full - volume collection strategy, and collecting the request parameter data and response parameter data in the business service link where the normal business service request is located based on the sampling collection strategy includes:

[0017] Determine the abnormal business service link corresponding to the abnormal business service request, and fully collect the request parameter data and response parameter data in the abnormal business service link;

[0018] Determine the normal business service link corresponding to the normal business service request. Taking the collection of one normal business service link as a complete collection operation, collect the request parameter data and response parameter data in each normal business service link based on the preset collection frequency.

[0019] Optionally, the method further includes:

[0020] Through an asynchronous thread different from the thread where the data collection program is called, convert the collected request parameter data and response parameter data into strings of a preset length, then serialize them, and store the serialized request parameter data and response parameter data in a preset data storage repository.

[0021] Optionally, after storing the serialized request parameter data and response parameter data in the preset data storage repository corresponding to the preset parameter monitoring platform, the method further includes:

[0022] In the preset data storage repository, identify the target desensitized data, where the target desensitized data includes at least one of bank card numbers, ID card numbers, and mobile phone numbers;

[0023] Based on a preset regular expression, replace the numbers at the target positions in the target desensitized data with preset characters to obtain the desensitized request parameter data and response parameter data;

[0024] Display the desensitized request parameter data and response parameter data on the preset parameter monitoring platform.

[0025] Optionally, the business service requests and request response results in the same business service link respectively correspond to the same associated header item.

[0026] According to another aspect of the present application, a business service parameter collection device is provided. The device includes:

[0027] An input / output parameter collection module, configured to call a data collection program in a target terminal where a target application is located, and collect in real time request parameter data corresponding to a business service request sent by the target application to a server, and response parameter data of a request response result returned by the server to the target application based on the business service request. When a user performs an interaction operation on the target application, at least one microservice business is triggered. The request response results respectively returned by the microservice businesses triggered by the same interaction operation and the business service request triggered by the interaction operation constitute a business service link.

[0028] A load status monitoring module, configured to monitor in real time whether the target terminal where the target application is located is in a high-load state.

[0029] A low-load mode collection module, configured to, when it is monitored that the target terminal is in a high-load state, call the data collection program of the target terminal, and collect request parameter data corresponding to a target business service request that hits a preset low-load data collection rule, and response parameter data of each request response result in the same business service link as the target business service request until the target terminal returns to a low-load state.

[0030] Optionally, the load status monitoring module is further configured to:

[0031] Monitor in real time a target performance parameter value corresponding to any one of a plurality of preset performance parameters in the target terminal where the target application is located. The preset performance parameters include at least one of a virtual machine garbage collection frequency, a CPU usage rate, and a memory occupancy rate. The virtual machine garbage collection frequency includes a young generation garbage collection frequency and a full garbage collection frequency.

[0032] When it is monitored that the target performance parameter value is greater than or equal to a preset overload threshold corresponding to the target performance parameter, the target terminal where the target application is located is in a high-load state.

[0033] When it is monitored that the target performance parameter value is less than a preset overload threshold corresponding to the target performance parameter, the target terminal where the target application is located is in a low-load state.

[0034] Optionally, the preset low-load data acquisition rule includes a full-volume acquisition strategy and a sampling acquisition strategy. The target business service requests include abnormal business service requests and normal business service requests. The low-load mode acquisition module is further configured to:

[0035] In the business service requests sent by the target application to the server, identify abnormal business service requests containing error messages and normal business service requests not containing error messages;

[0036] Based on the full-volume acquisition strategy, acquire the request parameter data and response parameter data in the business service link where the abnormal business service request is located, and based on the sampling acquisition strategy, acquire the request parameter data and response parameter data in the business service link where the normal business service request is located.

[0037] Optionally, the low-load mode acquisition module is further configured to:

[0038] Determine the abnormal business service link corresponding to the abnormal business service request, and fully acquire the request parameter data and response parameter data in the abnormal business service link;

[0039] Determine the normal business service link corresponding to the normal business service request. Taking the acquisition of one normal business service link as a complete acquisition operation, acquire the request parameter data and response parameter data in each normal business service link based on the preset acquisition frequency.

[0040] Optionally, the device further includes: a data storage module, configured to:

[0041] Through an asynchronous thread different from the thread where the data acquisition program is called, convert the acquired request parameter data and response parameter data into strings of a preset length, then serialize them, and store the serialized request parameter data and response parameter data in a preset data storage repository.

[0042] Optionally, the device further includes: a data desensitization and display module, configured to:

[0043] In the preset data storage repository, identify target desensitization data, where the target desensitization data includes at least one of bank card numbers, ID card numbers, and mobile phone numbers;

[0044] Based on a preset regular expression, replace the numbers at the target positions in the target desensitization data with preset characters to obtain the desensitized request parameter data and response parameter data;

[0045] Display the desensitized request parameter data and response parameter data on a preset parameter monitoring platform.

[0046] Optionally, the service requests and request response results in the same service link each correspond to the same associated header item.

[0047] According to another aspect of the present application, there is provided a storage medium having a computer program stored thereon, and when the program is executed by a processor, the above-mentioned service parameter collection method is implemented.

[0048] According to still another aspect of the present application, there is provided a computer device including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor. When the processor executes the program, the above-mentioned service parameter collection method is implemented.

[0049] By means of the above technical solution, a service parameter collection method and device, a storage medium, and a computer device provided by the present application call a data collection program in a target terminal where a target application program is located, and collect in real time request parameter data corresponding to a service request sent by the target application program to a server, and response parameter data of a request response result returned by the server to the target application program based on the service request; when it is monitored that the target terminal is in a high-load state, collect request parameter data of a target service request that hits a preset low-load data collection rule, and response parameter data of each request response result in the same service link as the target service request; through a parameter collection function that supports automatic degradation, it is possible to ensure the normal operation of the host application while completing the collection of input and output parameters, and improve the problem troubleshooting efficiency.

[0050] The above description is only an overview of the technical solution of the present application. In order to be able to understand the technical means of the present application more clearly, it can be implemented according to the content of the description. And in order to make the above and other purposes, features and advantages of the present application more obvious and understandable, the following specifically illustrates the specific embodiments of the present application. Description of the Drawings

[0051] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The schematic embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation of the present application. In the drawings:

[0052] Figure 1 A flowchart showing a service parameter collection method provided by an embodiment of the present application is shown;

[0053] Figure 2 A flowchart showing a method for monitoring the load state of a target terminal provided by an embodiment of the present application is shown;

[0054] Figure 3 A flowchart showing another service parameter collection method provided by an embodiment of the present application is shown;

[0055] Figure 4 The figure shows a schematic structural diagram of a service parameter collection device provided by an embodiment of the present application;

[0056] Figure 5 The figure shows a schematic structural diagram of another service parameter collection device provided by an embodiment of the present application. Detailed implementation manners

[0057] The present application will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments may be combined with each other.

[0058] In this embodiment, a method for collecting service parameter is provided, which is applied to a microservice architecture. The microservice architecture includes multiple microservice services, and each microservice service provides various service to an application program through its own server. The application program is installed on a terminal, and a data collection program is included in the operating system of the terminal, such as Figure 1 As shown, the method includes:

[0059] Step 101, call the data collection program in the target terminal where the target application program is located, and collect in real time the request parameter data corresponding to the service request sent by the target application program to the server, and the response parameter data of the request response result returned by the server to the target application program based on the service request. Among them, when a user performs an interaction operation on the target application program, at least one microservice service is triggered, and the request response results returned by each microservice service triggered by the same interaction operation, together with the service request triggered by the interaction operation, constitute a service link.

[0060] The function of collecting Dubbo parameters by the Agent provided by the official of the open source project SkyWalking specifically refers to the ability to collect and monitor the parameters of Dubbo services through the Agent of SkyWalking in a microservice architecture. Dubbo parameters (service parameters) refer to various parameters used to configure and optimize services when developing microservices using the Dubbo framework. These parameters cover multiple aspects such as service discovery, service governance, and performance tuning, and are crucial for ensuring the normal operation and optimization of services.

[0061] Specifically, Dubbo parameters include but are not limited to the following categories:

[0062] 1. Service discovery parameters:

[0063] group: Service grouping, used to identify the grouping of different services within the same application or different versions of the same service.

[0064] version: Service version, used to identify the version number of the service, facilitating the differentiation and management of different versions of the same service.

[0065] interface: Service interface, indicating the fully qualified name of the service interface, which is the unique identifier of the service.

[0066] 2. Service governance parameters:

[0067] loadbalance: Load balancing strategy, used to achieve load balancing of multiple providers on the consumer side. Common strategies include random and roundrobin.

[0068] filter: Filter configuration, used to add additional logical processing during service calls, such as logging and permission verification.

[0069] retries: Number of retries, which is the number of times allowed to retry when a service call fails.

[0070] 3. Performance tuning parameters:

[0071] timeout: Call timeout, setting a reasonable timeout can improve the response speed of the service and the system throughput.

[0072] actives: Maximum number of concurrent requests, restricting the number of requests that the service processes at the same time to avoid system overload.

[0073] threads: Thread pool size, reasonably configuring the thread pool size according to the number of cores and load of the system can improve the concurrent processing ability of the system.

[0074] In addition, Dubbo also provides many other advanced configuration items, such as monitoring, tracing, circuit breaking, etc. These configuration items can help developers and operators better monitor and manage services, improving the maintainability and reliability of the system. In actual applications, these parameters need to be adjusted according to specific business scenarios and system environments to achieve the best performance. At the same time, attention also needs to be paid to the parameter configuration in service governance and performance tuning to ensure the normal operation and optimization of the service.

[0075] In the above embodiments of this application, SkyWalking Agent can be combined to achieve low-loss collection of the input and output parameters (i.e., business service parameters) of Dubbo interfaces. After simply configuring and connecting to SkyWalking Agent, the ability to collect Dubbo input and output parameters after "customization" can be obtained. Due to support for dynamic configuration, it can meet the differentiated requirements of different applications.

[0076] Specifically, for example, a user performs interaction operations on a target application on a terminal (such as a smart phone, a wearable device, etc.), such as filling out a health questionnaire, recording physiological indicators (such as blood pressure, heart rate), setting health reminders, etc. The user's interaction operations will trigger one or more microservice operations. For example, filling out a health questionnaire can trigger a data analysis microservice, and recording physiological indicators can trigger data storage and anomaly detection microservices. Then, the target application constructs corresponding business service requests according to the user's interaction operations. These business service requests usually contain necessary request parameter data, such as user ID, operation type, relevant data (such as physiological indicator values), etc. Then, the data collection program in the target terminal where the target application is located can be called to collect the request parameter data corresponding to the business service requests sent by the target application to the server in real time, that is, the request parameter data of these business service requests can be collected in real time through ways such as API interfaces, message queues, etc. During the collection process, in order to ensure the security of the data is crucial, encryption technologies (such as SSL / TLS) can also be used to protect the data from attacks.

[0077] After the server corresponding to the microservice operation receives the business service request, it performs microservice operation processing according to the request parameter data in the business service request. The processing process can involve data verification, business logic execution, database operations, etc. After the server finishes processing, it constructs response parameter data containing the request response result. These data can include processing results, status codes, error messages (if any), etc.

[0078] Then, the server transmits the response parameter data of the request response result back to the target application in real time through protocols such as HTTP, WebSocket, etc. During the transmission process, appropriate transmission protocols and compression algorithms can be selected according to the data volume and real-time requirements. To ensure the real-time nature of the data, two-way communication protocols such as WebSocket can also be used to achieve real-time communication between the client (target terminal) and the server. In addition, the data transmission speed can be further improved by means such as optimizing the network path and using CDN acceleration. At this time, the data collection program in the target terminal where the target application is located is called to collect the response parameter data of the request response result returned by the server to the target application based on the business service request in real time.

[0079] In particular, the request response results returned by each microservice operation triggered by the same interaction operation, together with the business service requests triggered by the interaction operation, jointly constitute a business service link. By "linking" the "parameter data" corresponding to various micro-business services triggered by the same interaction operation together, it helps to track and analyze the complete behavior path of the user in the health field, and then form a complete user health record or report. These data can be used for subsequent health management, disease prediction, and personalized service recommendation, etc.

[0080] By invoking the data collection program in the target terminal where the target application is located, the request parameter data corresponding to the business service request sent by the target application to the server and the response parameter data corresponding to the request response result returned by the server are collected in real time, so that the service status of the microservice business can be promptly checked, the problem troubleshooting efficiency can be improved, and thus the user experience can be enhanced.

[0081] Step 102, monitor in real time whether the target terminal where the target application is located is in a high-load state.

[0082] Step 103, when it is monitored that the target terminal is in a high-load state, invoke the data collection program of the target terminal to collect the request parameter data corresponding to the target business service request that hits the preset low-load data collection rule, and the response parameter data of each request response result in the same business service link as the target business service request until the target terminal returns to a low-load state.

[0083] Then, the monitoring tool built into the operating system of the target terminal where the target application is located (such as the free command and top command in Linux, or Performance Monitor (Perfmon) in Windows) can be used to obtain the terminal operation data, so as to monitor whether the target terminal is in a high-load state. When it is monitored that the target terminal is in a high-load state, the data collection program of the target terminal is invoked to collect the request parameter data corresponding to the target business service request that hits the preset low-load data collection rule, and the response parameter data in the same business service link as the foregoing request parameter data until the target terminal returns to a low-load state. In this way, the load state of the target terminal where the target application is located in the medical and health field can be monitored in real time, and specific data can be collected based on the preset low-load data collection rule when it is in a high-load state, providing a basis for subsequent performance optimization and fault troubleshooting while reducing the application pressure on the terminal, thereby ensuring the normal operation of the host application.

[0084] Optionally, in step 102, when monitoring in real time whether the target terminal where the target application is located is in a high-load state, with reference to Figure 2 as shown, it specifically includes:

[0085] Step 1021, monitor in real time the target performance parameter value corresponding to any one of the multiple preset performance parameters in the target terminal where the target application is located, where the preset performance parameters include at least one of the virtual machine garbage collection frequency, CPU usage rate, and memory occupancy rate, and the virtual machine garbage collection frequency includes the young generation garbage collection frequency and the full garbage collection frequency.

[0086] Step 1022: When it is monitored that the target performance parameter value is greater than or equal to the preset overload threshold corresponding to the target performance parameter, the target terminal where the target application is located is in a high-load state.

[0087] Step 1023: When it is monitored that the target performance parameter value is less than the preset overload threshold corresponding to the target performance parameter, the target terminal where the target application is located is in a low-load state.

[0088] In the above embodiments of the present application, taking a certain key application in the intelligent hospital system as an example, such as the electronic medical record system. This system runs on the hospital server, and the terminal is the computer or mobile device of medical staff. It is also possible to monitor whether the target terminal is in a high-load state by monitoring the target performance parameter value corresponding to any one of multiple preset performance parameters of the terminal where the electronic medical record system is located. The preset performance parameters include at least one of the virtual machine garbage collection frequency, CPU usage rate, and memory occupancy rate. The virtual machine garbage collection frequency includes the young generation garbage collection frequency and the full garbage collection frequency.

[0089] For the virtual machine garbage collection frequency, for example, the virtual machine garbage collection frequency can be calculated in real time through monitoring code and compared with the preset overload threshold. If the frequency is greater than or equal to the threshold, it is considered that the target terminal where the target application is located is in a high-load state; otherwise, it is in a low-load state. When monitoring the frequency of JVM GC (Java Virtual Machine Garbage Collection) in real time, the virtual machine garbage collection frequency also includes the young generation garbage collection frequency and the full garbage collection frequency. Correspondingly, the preset overload threshold can be set accordingly: for example, if it is monitored that the YGC (Young Generation Garbage Collection) exceeds 5 times per minute or the Full GC (Full Garbage Collection) exceeds 2 times, it is considered to be in a high-load state, and then the collection frequency is reduced. This rule can be customized according to specific situations for different applications. For example, if the GC is not frequent for a period of time, the full-volume collection is automatically restored.

[0090] For indicators such as CPU usage rate and memory occupancy rate, the performance monitoring tool deployed on the hospital server can be used to collect the indicator information such as CPU usage rate and memory occupancy rate on the terminal. According to the hardware configuration of the hospital server and the performance requirements of the electronic medical record system, thresholds such as the CPU usage rate not exceeding 70% and the memory occupancy rate not exceeding 70% can be set. By monitoring the running state of the terminal, it can provide a basis for changing the subsequent collection strategy.

[0091] By applying the technical solution of this embodiment, with the parameter acquisition function that supports automatic degradation, it is possible to ensure the normal operation of the host application while completing the acquisition of input and output parameters, and improve the efficiency of problem troubleshooting.

[0092] Further, as a refinement and extension of the specific implementation manner of the above embodiment, to fully illustrate the specific implementation process of this embodiment, another method for collecting business service parameters is provided, which is applied to a microservice architecture. The microservice architecture includes multiple microservice businesses, and each microservice business provides various business services to the application program through its own server. The application program is installed on the terminal, and a data collection program is included in the operating system of the terminal, such as Figure 3 As shown, the method includes:

[0093] Step 201: Invoke the data collection program in the target terminal where the target application program is located to collect in real time the request parameter data corresponding to the business service request sent by the target application program to the server, and the response parameter data of the request response result returned by the server to the target application program based on the business service request. Among them, when the user performs an interaction operation on the target application program, at least one microservice business is triggered. The request response results returned by each microservice business triggered by the same interaction operation, together with the business service request triggered by the interaction operation, form a business service link. For the business service request and the request response result in the same business service link, there is a same associated header item respectively.

[0094] Step 202: Monitor in real time whether the target terminal where the target application program is located is in a high-load state.

[0095] In the above embodiments of the present application, parameter collection is an auxiliary function and cannot affect the normal operation of the host application. Therefore, when the application is under high pressure, automatic degradation can be performed. Specifically, for example, there is a remote medical consultation application program (referred to as "Medical APP" for short), which allows patients to conduct online video consultations with doctors, send medical reports, and receive diagnostic suggestions. The Medical APP is deployed on a mobile device and communicates with the backend server to process various business service requests. Call the data collection program in the target terminal where the target application is located to capture the business service requests sent by the Medical APP to the server. Then, extract the key parameter data in the requests, such as request types (video consultation, sending reports, etc.), user IDs, request timestamps, etc. Record the collected request parameter data in the local log or send it to a remote log server for subsequent analysis and monitoring. When the processing server corresponding to the Medical APP returns a response, the response parameter data can be captured through a callback function or an event listener. These parameters may include the response status code, the returned data content (such as diagnostic suggestions, medical report processing results, etc.), the response time, etc. Similarly, record the collected response parameter data in the log for correlation analysis with the request parameter data. Then, continuously monitor whether the target terminal where the target application is located is in a high-load state, so that when the application is under high pressure, the data collection function can be automatically degraded.

[0096] In particular, a header sampling strategy can also be adopted, that is, by means of the Correlation Header item in the sw8 cross-process protocol of SkyWalking, the full-link transparent parameter collection Tag is implemented, and this Tag can be continuously transmitted during cross-process and cross-thread execution, ensuring that all Dubbo request parameters in a link can be collected, so as to enable full-link collection, facilitate subsequent problem troubleshooting, and improve the troubleshooting accuracy.

[0097] In step 203, when it is monitored that the target terminal is in a high-load state, call the data collection program of the target terminal, and in the business service requests sent by the target application to the server, identify the abnormal business service requests containing error messages and the normal business service requests not containing error messages. Among them, the preset low-load data collection rules include a full-volume collection strategy and a sampling collection strategy, and the target business service requests include abnormal business service requests and normal business service requests.

[0098] In step 204, determine the abnormal business service link corresponding to the abnormal business service request, and fully collect the request parameter data and response parameter data in the abnormal business service link.

[0099] Step 205: Determine the normal business service link corresponding to the normal business service request. Consider collecting the request parameter data and response parameter data in one normal business service link as one complete collection operation. Based on a preset collection frequency, collect the request parameter data and response parameter data in each normal business service link until the target terminal returns to a low-load state.

[0100] Next, when it is monitored that the target terminal is in a high-load state, identify the abnormal business service requests containing error messages and the normal business service requests without error messages among the business service requests sent by the target application to the server. The error message can appear in the form of a specific error code, exception description, stack trace, etc.

[0101] For the identified requests containing error messages (abnormal business service requests), use technical means such as interceptors or proxy servers to fully capture the request parameter data of each business service request containing error messages. The request parameter data can include key information such as patient information, diagnosis and treatment records, operation instructions, etc. For the requests containing error messages, trace their propagation paths in the business service link and the processing results of each node. The response parameter data can include processing results, error codes, return information, etc. Therefore, if a certain link is hit by the preset low-load data collection rule (for example, it is identified as containing an error message), that is, it needs to be sampled. We hope that all dubbo parameters (business service parameters) in this link are collected because if only some nodes in a link collect parameters, the troubleshooting effect is not good, so try to collect data for the entire link as much as possible to improve the accuracy and efficiency of subsequent problem troubleshooting.

[0102] For the business service requests without error messages (normal business service requests), this part can be collected by reducing the collection frequency. According to the business requirements and performance requirements of the system, set a reasonable collection frequency. The collection frequency should ensure that enough data can be captured for analysis and monitoring without causing too much impact on the system performance. For example, after collecting the number of items per minute specified by the preset collection frequency, stop collecting. Similarly, the data in one business service link needs to be collected simultaneously. In particular, a link blacklist can also be set, and the data in the link blacklist can be not collected to improve data security.

[0103] Therefore, by monitoring the pressure state of the host application and adjusting the collection strategy in a timely manner, the safe operation of the host application can be guaranteed, and the user experience when using the application can be improved.

[0104] Step 206: Through an asynchronous thread different from the thread where the data collection program is called, convert the collected request parameter data and response parameter data into strings of a preset length and then serialize them, and store the serialized request parameter data and response parameter data in a preset data storage repository.

[0105] Step 207: In the preset data repository, identify the target desensitized data. Based on the preset regular expression, replace the numbers at the target positions in the target desensitized data with preset characters to obtain the desensitized request parameter data and response parameter data.

[0106] Step 208: Display the desensitized request parameter data and response parameter data on the preset parameter monitoring platform.

[0107] Next, the native data collection function of SkyWalking performs parameter serialization in a synchronous manner, which will block the execution process of the Dubbo request thread. Therefore, a thread pool and a local queue can be used to implement asynchronous parameter serialization and reporting, which will not affect the execution of the Dubbo request thread at all. That is, through an asynchronous thread different from the thread where the data collection program is called, the collected request parameter data and response parameter data are converted into strings of a preset length and then serialized, and the serialized request parameter data and response parameter data are stored in the preset data repository corresponding to the preset parameter monitoring platform. The data in the preset data repository can be cleaned regularly, for example, every three months, and the preset cleaning time can be changed at any time.

[0108] Specifically, when performing conversion and serialization, for numerical data, Python's string formatting methods (such as str.format() or f-string) can be used to convert it into a string of a specified length. For example, in MySQL, the LPAD function can be used to achieve a similar padding effect.

[0109] For data that is already a string, if its length does not meet the preset requirements, it can be adjusted by truncation or padding. For example, in Python, the slice operation can be used to truncate a string, or the ljust and rjust methods can be used to pad a string.

[0110] Serialization is the process of converting a data structure or object state into a format that can be stored or transmitted. In Python, common serialization methods include: JSON serialization, that is, using the json module to convert Python objects (such as dictionaries, lists, etc.) into JSON-formatted strings. JSON serialization is suitable for data exchange between the front end and the back end in web development. URL encoding, that is, using the urllib.parse.urlencode() method to convert request parameters into URL-encoded strings. URL encoding is suitable for adding parameters to the URL for GET requests. Custom serialization, that is, implementing a custom serialization method according to specific requirements. For example, designing an algorithm to encode a list of strings into a single string and being able to decode it back to the original list of strings when needed.

[0111] Note that in actual applications, it may not be necessary to perform strict character length conversion on all fields, which depends on specific requirements and protocol specifications. In addition, the serialization method should also be selected according to the transport protocol and data exchange format.

[0112] For this reason, the native collection function of SkyWalking reports data by converting it to a string through the toString() method of the object. However, this method consumes a large amount of performance. For objects larger than 1M, it may take dozens of milliseconds to 1 second. Generally, only part of the data of large objects needs to be collected to locate problems. To solve this problem, a custom Json serialization tool is used to support truncation by specifying the maximum length of the parameter, that is, only serialize data of the specified length. This method has short serialization time, low memory and CPU consumption, and the serialization time of parameters of any size does not exceed 1ms. Compared with the traditional method of manually coding and open-source SkyWalking Agent to record request parameters in the log, parameter serialization can achieve low-performance-loss parameter collection by using a custom serialization tool class and by asynchronous execution and limiting the maximum length.

[0113] Next, when storing and displaying data, data such as bank card numbers, ID card numbers, and mobile phone numbers can be desensitized by regular expression matching to ensure data security. Specifically, in the request parameter data and response parameter data of the preset data storage repository, identify the target desensitized data, which includes at least one of bank card numbers, ID card numbers, and mobile phone numbers. Based on the preset regular expression, replace the numbers at the target positions in the target desensitized data with preset characters, and display the desensitized request parameter data and response parameter data on the preset parameter monitoring platform. For this reason, by modifying the Dubbo plugin in SkyWalking Agent, intercept the Dubbo request execution link and perform bytecode technology instrumentation to capture the incoming and outgoing parameters, and serialize and report them asynchronously. Finally, SkyWalking-Web is used for display. That is, after modification, the Dubbo request incoming and outgoing parameters in the link can be viewed on the SkyWalking-Web console.

[0114] More specifically, when desensitizing data by regular expression:

[0115] For bank card number desensitization, bank card numbers usually consist of 16 to 19 digits. The desensitization rule can be set to only display the first six digits and the last four digits, and the middle part is replaced by a specific character (such as an asterisk *). The regular expression is, for example: (\d{6})\d+(\d{4});

[0116] The replacement pattern is, for example:

[0117] `1□□□□□□□□1********1□□□□□□□□2` (where `1`, `1`, `1`, and `2` represent the first and second capture groups in the regular expression respectively).

[0118] For ID card number desensitization, an ID card number generally consists of 18 digits or letters (the last digit can be X). The desensitization rule can be set to only display the first six digits and the last four digits, and replace the middle part with specific characters. The regular expression is, for example: (\d{6})\d+(\d{4}), (if considering the case where the last digit is X, it can be slightly adjusted, but the basic idea is the same);

[0119] The replacement pattern is, for example:

[0120] `1□□□□□□1******1□□□□□□2`.

[0121] For mobile phone number desensitization, a mobile phone number usually consists of 11 digits. The desensitization rule can be set to only display the first three digits and the last four digits, and replace the middle four digits with specific characters.

[0122] The regular expression is, for example: (\d{3})\d{4}(\d{4});

[0123] The replacement pattern is, for example: `1□□□□1****1□□□□2`;

[0124] Therefore, desensitization rules can be formulated according to actual needs, which not only protect data security but also maintain data availability. At the same time, the desensitized data can be verified to ensure that the desensitization effect meets expectations.

[0125] Through the above method, sensitive data such as bank card numbers, ID card numbers, and mobile phone numbers can be effectively desensitized, thus protecting data security.

[0126] By applying the technical solution of this embodiment, the native collection function of SkyWalking only supports collecting Dubbo input parameters. After transformation, it now adds the collection of output parameters. At the same time, the native collection function of SkyWalking does not support dynamic configuration and cannot adapt to the customized parameter collection requirements of different applications. Therefore, through transformation, it is possible to support the SkyWalking Server side to dynamically control the collection switch of the Agent side, control the collection frequency of parameters at the second and minute levels, the link blacklist (interfaces and methods in the blacklist do not collect input and output parameters), the maximum length of JSon serialization, etc.

[0127] Further, as Figure 1 a specific implementation of the method, an embodiment of the present application provides a business service parameter collection device, as Figure 4 shown. The device includes:

[0128] The input and output parameter collection module 301 is used to call the data collection program in the target terminal where the target application is located, and collect in real time the request parameter data corresponding to the business service request sent by the target application to the server, and the response parameter data of the request response result returned by the server to the target application based on the business service request. When a user performs an interaction operation on the target application, at least one microservice business is triggered. The request response results returned by each microservice business triggered by the same interaction operation, together with the business service request triggered by the interaction operation, constitute a business service link;

[0129] The load status monitoring module 302 is used to monitor in real time whether the target terminal where the target application is located is in a high-load state;

[0130] The low-load mode collection module 303 is used to, when it is monitored that the target terminal is in a high-load state, call the data collection program of the target terminal, and collect the request parameter data corresponding to the target business service request that hits the preset low-load data collection rule, and the response parameter data of each request response result in the same business service link as the target business service request, until the target terminal returns to a low-load state.

[0131] Optionally, the load status monitoring module 302 is further used for:

[0132] Monitor in real time the target performance parameter value corresponding to any one of a variety of preset performance parameters in the target terminal where the target application is located. The preset performance parameters include at least one of virtual machine garbage collection frequency, CPU usage rate, and memory occupancy rate. The virtual machine garbage collection frequency includes young generation garbage collection frequency and full garbage collection frequency;

[0133] When it is monitored that the target performance parameter value is greater than or equal to the preset overload threshold corresponding to the target performance parameter, the target terminal where the target application is located is in a high-load state;

[0134] When it is monitored that the target performance parameter value is less than the preset overload threshold corresponding to the target performance parameter, the target terminal where the target application is located is in a low-load state.

[0135] Optionally, the preset low-load data collection rule includes a full-volume collection strategy and a sampling collection strategy. The target business service request includes an abnormal business service request and a normal business service request. The low-load mode collection module 303 is further used for:

[0136] In the business service requests sent by the target application to the server, identify the abnormal business service requests containing error messages and the normal business service requests not containing error messages;

[0137] Collect the request parameter data and response parameter data in the service link of the abnormal service request based on the full-volume collection strategy, and collect the request parameter data and response parameter data in the service link of the normal service request based on the sampling collection strategy.

[0138] Optionally, the low-load mode collection module 303 is further configured to:

[0139] Determine the abnormal service link corresponding to the abnormal service request, and fully collect the request parameter data and response parameter data in the abnormal service link;

[0140] Determine the normal service link corresponding to the normal service request. Taking the collection of one normal service link as a complete collection operation, collect the request parameter data and response parameter data in each normal service link based on the preset collection frequency.

[0141] Optionally, the service requests and request response results in the same service link respectively correspond to the same associated header item.

[0142] Further, as Figure 1 a specific implementation of the method, an embodiment of the present application provides a service parameter collection device, as Figure 5 shown. The device includes:

[0143] An input / output parameter collection module 401, configured to call the data collection program in the target terminal where the target application is located, and collect in real time the request parameter data corresponding to the service request sent by the target application to the server, and the response parameter data of the request response result returned by the server based on the service request. When a user performs an interaction operation on the target application, at least one microservice business is triggered. The request response results respectively returned by the microservice businesses triggered by the same interaction operation and the service request triggered by the interaction operation constitute a service link;

[0144] A load status monitoring module 402, configured to monitor in real time whether the target terminal where the target application is located is in a high-load state;

[0145] A low-load mode collection module 403, configured to, when it is monitored that the target terminal is in a high-load state, call the data collection program of the target terminal, and collect the request parameter data corresponding to the target service request that hits the preset low-load data collection rule, and the response parameter data of each request response result in the same service link as the target service request until the target terminal returns to a low-load state;

[0146] The data storage module 404 is used to convert the collected request parameter data and response parameter data into strings of a preset length through an asynchronous thread different from the thread where the data acquisition program is called, serialize them, and store the serialized request parameter data and response parameter data in a preset data storage repository.

[0147] The data desensitization and display module 405 is used to identify target desensitized data in a preset data storage repository, where the target desensitized data includes at least one of bank card numbers, ID card numbers, and mobile phone numbers. Based on a preset regular expression, replace the numbers at the target positions in the target desensitized data with preset characters to obtain the desensitized request parameter data and response parameter data, and display the desensitized request parameter data and response parameter data on a preset parameter monitoring platform.

[0148] Optionally, the load status monitoring module 402 is further used to:

[0149] Real-time monitor the target performance parameter value corresponding to any one of multiple preset performance parameters in the target terminal where the target application program is located. The preset performance parameters include at least one of virtual machine garbage collection frequency, CPU usage rate, and memory occupancy rate. The virtual machine garbage collection frequency includes young generation garbage collection frequency and full garbage collection frequency;

[0150] When it is monitored that the target performance parameter value is greater than or equal to the preset overload threshold corresponding to the target performance parameter, the target terminal where the target application program is located is in a high-load state;

[0151] When it is monitored that the target performance parameter value is less than the preset overload threshold corresponding to the target performance parameter, the target terminal where the target application program is located is in a low-load state.

[0152] Optionally, the preset low-load data acquisition rule includes a full-volume acquisition strategy and a sampling acquisition strategy. The target business service request includes an abnormal business service request and a normal business service request. The low-load mode acquisition module 403 is further used to:

[0153] In the business service requests sent by the target application program to the server, identify abnormal business service requests containing error messages and normal business service requests not containing error messages;

[0154] Collect the request parameter data and response parameter data in the business service link where the abnormal business service request is located based on the full-volume acquisition strategy, and collect the request parameter data and response parameter data in the business service link where the normal business service request is located based on the sampling acquisition strategy.

[0155] Optionally, the low-load mode acquisition module 403 is further used to:

[0156] Determine the abnormal service link corresponding to the abnormal service request, and collect all the request parameter data and response parameter data in the abnormal service link;

[0157] Determine the normal service link corresponding to the normal service request. Taking the collection of one normal service link as one complete collection operation, collect the request parameter data and response parameter data in each normal service link based on a preset collection frequency.

[0158] Optionally, the service request and the request response result in the same service link respectively correspond to the same associated header item.

[0159] It should be noted that for other corresponding descriptions of each functional unit involved in a service parameter collection device provided in an embodiment of the present application, reference can be made to Figures 1 to 3 the corresponding description in the method, which will not be elaborated here.

[0160] Based on the above-mentioned Figures 1 to 3 method, correspondingly, an embodiment of the present application also provides a storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the service parameter collection method as described above Figures 1 to 3 is implemented.

[0161] Based on such an understanding, the technical solution of the present application can be embodied in the form of a software product, and the software product can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), including several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in various implementation scenarios of the present application.

[0162] Based on the above-mentioned Figures 1 to 3 method, and Figure 4 and Figure 5 the virtual device embodiment as described above, for the purpose of achieving the above object, an embodiment of the present application also provides a computer device, which can specifically be a personal computer, a server, a network device, etc. The computer device includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to implement the service parameter collection method as described above Figures 1 to 3 is implemented.

[0163] Optionally, the computer device may further include a user interface, a network interface, a camera, a Radio Frequency (RF) circuit, sensors, an audio circuit, a WI-FI module, and so on. The user interface may include a display screen (Display), an input unit such as a keyboard (Keyboard), etc. Optionally, the user interface may further include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface, a wireless interface (such as a Bluetooth interface, a WI-FI interface), etc.

[0164] Those skilled in the art can understand that the structure of a computer device provided in this embodiment does not constitute a limitation on the computer device, and it may include more or fewer components, or combine certain components, or have different component arrangements.

[0165] The storage medium may further include an operating system and a network communication module. The operating system is a program for managing and storing the hardware and software resources of the computer device, and supports the operation of information processing programs and other software and / or programs. The network communication module is used to implement communication between the components inside the storage medium, as well as communication between the storage medium and other hardware and software in the entity device.

[0166] Through the description of the above embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus a necessary general hardware platform, or can also be implemented by hardware to call the data acquisition program in the target terminal to collect the request parameter data corresponding to the service request sent by the target application to the server in real time, and the response parameter data of the request response result returned by the server to the target application based on the service request; when it is monitored that the target terminal is in a high-load state, collect the request parameter data of the target service request that hits the preset low-load data acquisition rule, and the response parameter data that belongs to the same service link as the request parameter data; display the collected data on the preset parameter monitoring platform after desensitization processing; through the parameter acquisition function that supports automatic downgrading, it is possible to ensure the normal operation of the host application while completing the acquisition of input and output parameters, and improve the problem troubleshooting efficiency.

[0167] Those skilled in the art can understand that the drawings are only schematic diagrams of a preferred implementation scenario, and the modules or processes in the drawings are not necessarily essential for implementing this application. Those skilled in the art can understand that the modules in the device in the implementation scenario can be distributed in the device in the implementation scenario according to the description of the implementation scenario, or can be correspondingly changed to be located in one or more devices different from this implementation scenario. The modules in the above implementation scenario can be combined into one module, or further split into multiple sub-modules.

[0168] The above serial numbers of the present application are only for description and do not represent the advantages or disadvantages of the implementation scenarios. The above disclosure is only several specific implementation scenarios of the present application. However, the present application is not limited thereto, and any changes that can be made by those skilled in the art should fall within the protection scope of the present application.

Claims

1. A method for collecting business service parameters, characterized in that: Applied to a microservice architecture, the microservice architecture includes multiple microservice businesses, each microservice business provides various business services to an application program through its own server, the application program is installed on a terminal, and the operating system of the terminal includes a data collection program, the method includes: Calling a data collection program in a target terminal where a target application is located, collecting in real time request parameter data corresponding to a business service request sent by the target application to a server, and response parameter data of a request response result returned by the server to the target application based on the business service request, wherein at least one microservice business is triggered when a user performs an interactive operation on the target application, and the request response results returned by each microservice business triggered by the same interactive operation, together with the business service request triggered by the interactive operation, constitute a business service link; Real-time monitoring of whether the target terminal where the target application is located is in a high-load state; When it is monitored that the target terminal is in a high-load state, the data collection program of the target terminal is called to collect request parameter data corresponding to the target business service request that hits the preset low-load data collection rule, as well as response parameter data of each request response result in the same business service link as the target business service request, until the target terminal returns to a low-load state.

2. The method according to claim 1, characterized in that The real-time monitoring of whether the target terminal where the target application is located is in a high-load state includes: Real-time monitoring of a target performance parameter value corresponding to any one of a plurality of preset performance parameters in a target terminal where a target application is located, wherein the preset performance parameter includes at least one of a virtual machine garbage collection frequency, a CPU usage rate, and a memory occupancy rate, and the virtual machine garbage collection frequency includes a young generation garbage collection frequency and a full garbage collection frequency; When it is monitored that the target performance parameter value is greater than or equal to a preset overload threshold corresponding to the target performance parameter, the target terminal where the target application is located is in a high load state; When it is monitored that the target performance parameter value is less than a preset overload threshold corresponding to the target performance parameter, the target terminal where the target application is located is in a low-load state.

3. The method according to claim 1, characterized in that The preset low-load data collection rule includes a full collection strategy and a sampling collection strategy, the target business service request includes an abnormal business service request and a normal business service request, the collection of request parameter data corresponding to the target business service request that hits the preset low-load data collection rule, and the response parameter data of each request response result in the same business service link as the target business service request, including: Among the business service requests sent by the target application to the server, identifying abnormal business service requests containing error information and normal business service requests not containing error information; The request parameter data and response parameter data in the business service link where the abnormal business service request is located are collected based on the full collection strategy, and the request parameter data and response parameter data in the business service link where the normal business service request is located are collected based on the sampling collection strategy.

4. The method according to claim 3, characterized in that: The collecting of request parameter data and response parameter data in the business service link where the abnormal business service request is located based on the full collection strategy, and the collecting of request parameter data and response parameter data in the business service link where the normal business service request is located based on the sampling collection strategy, include: Determine the abnormal business service link corresponding to the abnormal business service request, and collect all request parameter data and response parameter data in the abnormal business service link; Determine the normal business service link corresponding to the normal business service request, take the collection of one normal business service link as a complete collection operation, and collect the request parameter data and response parameter data in each normal business service link based on the preset collection frequency.

5. The method according to claim 1, characterized in that: The method further comprises: The collected request parameter data and response parameter data are converted into strings of preset length and serialized through an asynchronous thread different from the thread in which the data collection program is called, and the serialized request parameter data and response parameter data are stored in a preset data repository.

6. The method according to claim 5, characterized in that After storing the serialized request parameter data and response parameter data in a preset data repository corresponding to the preset parameter monitoring platform, the method further includes: In a preset data repository, target desensitized data is identified, wherein the target desensitized data includes at least one of a bank card number, an ID card number, and a mobile phone number; Based on a preset regular expression, the number at the target position in the target desensitized data is replaced by a preset character to obtain desensitized request parameter data and response parameter data; The desensitized request parameter data and response parameter data are displayed on the preset parameter monitoring platform.

7. The method according to any one of claims 1 to 6, characterized in that The business service request and request response result in the same business service link respectively correspond to the same associated header item.

8. A business service parameter collection device, characterized in that: The device comprises: An input and output parameter collection module is used to call a data collection program in a target terminal where a target application is located, and collect in real time request parameter data corresponding to a business service request sent by the target application to a server, and response parameter data of a request response result returned by the server to the target application based on the business service request, wherein at least one microservice business is triggered when a user performs an interactive operation on the target application, and the request response results returned by each microservice business triggered by the same interactive operation, together with the business service request triggered by the interactive operation, constitute a business service link; A load status monitoring module is used to monitor in real time whether the target terminal where the target application is located is in a high load state; The low-load mode acquisition module is used to call the data acquisition program of the target terminal when it is monitored that the target terminal is in a high-load state, and collect the request parameter data corresponding to the target business service request that hits the preset low-load data acquisition rule, as well as the response parameter data of each request response result in the same business service link as the target business service request, until the target terminal returns to a low-load state.

9. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for collecting business service parameters described in any one of claims 1 to 7 is implemented.

10. A computer device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, characterized in that: When the processor executes the computer program, the method for collecting business service parameters described in any one of claims 1 to 7 is implemented.

Images