Application program instrumentation method and system, electronic equipment, storage medium and computer program product

Abstract

The invention discloses an instrumentation method and system for an application program, electronic equipment, a storage medium and a computer program product, and relates to the technical field of application programs. The method comprises the following steps: determining a program code to be instrumented from an application program; a target interface corresponding to the operation system is called, a target probe configured for the program code is determined, and the target probe is used for tracking data generated by the application program in the operation process of the operation system; determining an instrumentation position in the program code by using the target interface, and determining an instrumentation strategy corresponding to the target probe, the instrumentation strategy being used for representing a rule for performing instrumentation operation on the program code; and according to the instrumentation strategy, performing instrumentation operation on the program code to insert a target probe at the instrumentation position. According to the method and the device, the technical problem of relatively low efficiency of manually performing code instrumentation on the application program in related technologies is solved.

Description

Technical Field

[0001] The present application relates to the field of application technology, and in particular to an application program instrumentation method, system, electronic device, storage medium, and computer program product. Background Art

[0002] In the field of application technology, performance profiling technology is mainly used to locate performance problems in the code. However, for some application scenarios, such as the Hypertext Transfer Protocol server (HTTP server) scenario in the Java environment, the web server (Web Server) scenario, microservices, databases, and high-concurrency scenarios, there is a deeper demand for execution flow tracking, that is, tracking each step of the request execution time and analyzing the percentile distribution of delays in order to improve user experience and system stability. In the related technology, the tools based on the above-mentioned performance profiling technology cannot automatically instrument the application code. The programmer still needs to manually insert the code, rebuild the project, and re-run the program to implement application instrumentation. Therefore, the related technology is difficult to support the execution flow tracking of the application, and the instrumentation efficiency of the application is low.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present application provide an application program plugging method, system, electronic device, storage medium and computer program product to at least solve the technical problem of low efficiency in the related art of manually plugging code into the application program.

[0005] According to one aspect of an embodiment of the present application, a method for inserting an application is provided, comprising: determining program code to be inserted from the application; calling a target interface corresponding to the operating system to determine a target probe configured for the program code, wherein the target probe is used to track data generated by the application during the operation of the operating system; using the target interface to determine an insertion position in the program code, and determining an insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent rules for inserting the program code; and according to the insertion strategy, inserting the program code to insert the target probe at the insertion position.

[0006] According to another aspect of an embodiment of the present application, a method for inserting an application is provided, which is applied to a tracing tool, and includes: determining a program code to be inserted from the application, wherein the program code is a code in an object-oriented programming language; calling an application programming interface corresponding to the operating system, and determining a target probe configured for the program code, wherein the target probe is used to perform execution flow tracing on data generated by the application at the code level and at the system level during the operation of the operating system; using the application programming interface to determine an insertion position in the program code, and determining an insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent a rule for inserting the program code; according to the insertion strategy, inserting the program code to insert the target probe at the insertion position; using the target probe inserted at the insertion position to perform execution flow tracing on data generated by the application at the code level and at the system level to obtain a tracing result.

[0007] According to another aspect of an embodiment of the present application, a method for inserting an application is provided, comprising: obtaining program code to be inserted in the application by calling a first interface, wherein the first interface includes a first parameter, and the parameter value of the first parameter includes the program code; calling a target interface corresponding to the operating system, and determining a target probe configured for the program code, wherein the target probe is used to track data generated by the application during the operation of the operating system; using the target interface to determine an insert position in the program code, and determining an insert strategy corresponding to the target probe, wherein the insert strategy is used to represent a rule for inserting the program code; according to the insert strategy, inserting the program code to insert the target probe at the insert position; outputting the insert program code by calling a second interface, wherein the second interface includes a second parameter, and the parameter value of the second parameter includes the insert program code.

[0008] According to another aspect of an embodiment of the present application, there is also provided an application instrumentation system, including: a client, sending a request message, wherein the request message is used to request information about the application and / or request the application to perform a task; a server, used to determine the program code to be instrumented in the application based on the request message; calling a target interface corresponding to the operating system to determine a target probe configured for the program code, wherein the target probe is used to track data generated by the application during the operation of the operating system; using the target interface to determine an instrumentation position in the program code, and determining an instrumentation strategy corresponding to the target probe, wherein the instrumentation strategy is used to represent rules for instrumenting the program code; and according to the instrumentation strategy, instrumenting the program code to insert the target probe at the instrumentation position.

[0009] According to another aspect of an embodiment of the present application, an electronic device is further provided, including: a memory storing an executable program; and a processor for running the program, wherein any one of the above methods is executed when the program is running.

[0010] According to another aspect of an embodiment of the present application, a computer-readable storage medium is further provided, the computer-readable storage medium including a stored executable program, wherein when the executable program is running, the device where the storage medium is located is controlled to execute any of the above methods.

[0011] According to another aspect of an embodiment of the present application, a computer program product is also provided, including a computer program, and when the computer program is executed by a processor, it implements any of the above methods.

[0012] In an embodiment of the present application, the program code to be plugged in is determined from the application; the target interface corresponding to the operating system is called to determine the target probe configured for the program code, wherein the target probe is used to track the data generated by the application during the operation of the operating system; the target interface is used to determine the plugging position in the program code, and the plugging strategy corresponding to the target probe is determined, wherein the plugging strategy is used to represent the rules for plugging the program code; according to the plugging strategy, the program code is plugged to insert the target probe at the plugging position. Therefore, the embodiment of the present application adopts the method of calling the target interface to insert the target probe into the program code running by the operating system, and in particular, it can determine the plugging position and plugging strategy in the program code, so as to achieve the purpose of automatically plugging into the application to support the execution flow tracking at the operating system level, thereby achieving the technical effect of improving the code plugging efficiency in the application and facilitating the execution flow tracking of the application at the operating system level, thereby solving the technical problem of low efficiency in the related technology of relying on manual code plugging into the application.

[0013] It is easy to notice that the above general description and the following detailed description are only for the purpose of exemplifying and explaining the present application, and do not constitute a limitation of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a plugging method for an application program is shown;

[0016] Figure 2 is a flowchart of an application program instrumentation method according to an embodiment of the present application;

[0017] Figure 3 is a flow chart of another method for inserting an application program according to an embodiment of the present application;

[0018] Figure 4 is a flow chart of another method for inserting an application program according to an embodiment of the present application;

[0019] Figure 5 is a structural schematic diagram of an application program plugging device according to an embodiment of the present application;

[0020] Figure 6 is a structural schematic diagram of an instrumentation device for another application according to an embodiment of the present application;

[0021] Figure 7 is a structural schematic diagram of an instrumentation device for another application according to an embodiment of the present application;

[0022] Figure 8 is a structural block diagram of an instrumentation system for an application according to an embodiment of the present application;

[0023] Fig. 9 It is a structural block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0026] First, some nouns or terms that appear in the process of describing the embodiments of the present application are subject to the following explanations.

[0027] Java (Java Programming Language): is a high-level, general-purpose, object-oriented programming language. With its cross-platform capabilities and wide application, it occupies an important position in the development of enterprise-level applications, Web services and mobile applications.

[0028] JVM (full name: Java Virtual Machine): refers to the virtual machine used to run Java bytecode, which is responsible for executing and managing Java programs.

[0029] JDK (full name: Java Development Kit): refers to the toolkit used to develop Java programs, including JVM, Java class library and other development tools. It is the basic environment for Java development.

[0030] Dynamic Instrumentation: refers to a technology that can modify the behavior of an application while it is running. Specifically, dynamic instrumentation refers to monitoring, analyzing, or modifying the behavior of a program while it is running by inserting new code snippets at specific locations. Dynamic instrumentation is particularly suitable for scenarios such as performance tuning, logging, and code debugging. Dynamic instrumentation can take effect without restarting the application and is highly flexible.

[0031] Execution Trace: It is a detailed record of the application execution process. By tracking function calls, thread states, and events for applications, it can help developers gain in-depth understanding of the application's running behavior, performance issues, and potential errors. Execution Trace is an important means of performance analysis and debugging.

[0032] Request: In the client-server model, an operation or data request initiated by the client to the server to obtain information or perform a specific task. Request is the basic interaction unit in network communication. The response time and processing efficiency of the request directly affect the user experience.

[0033] Response Time (RT): measures the time it takes from a client request to a server response. Response time is a key indicator for evaluating system performance and user experience.

[0034] The execution path is used to describe the sequence relationship and dependency between function calls, thread activities, and event triggers in the application execution process. The execution path helps analyze the logical path and performance issues of program execution.

[0035] Percentile Time: In a set of time data, the time value at a specific percentile reflects the ranking of this set of time data in the data set. In other words, percentile time is used to evaluate the distribution characteristics of response time or execution time, helping to identify performance bottlenecks and optimization directions.

[0036] Application Programming Interface (API): defines the rules and methods for interaction between applications or libraries, enabling different software components to communicate and collaborate with each other, simplifying development work and enhancing the scalability of system functions.

[0037] Linux (Linux Operating System Kernel, Linux): is an open source operating system kernel, widely used in servers, embedded systems and personal computers, with high customizability, stability and community support.

[0038] User Space Probe (Uprobe for short): It is a function provided by the Linux kernel that allows dynamic insertion of trace points in user space applications. It can monitor and modify the execution of specific functions at runtime, but does not directly support Java method-level instrumentation.

[0039] Dynamic link library file (Shared Object, referred to as SO): refers to the library file format that can be shared by multiple programs in the Linux environment. It usually contains pre-compiled code and data, which helps save memory and improve interoperability between programs.

[0040] Native File: refers to a program or library file written in a native programming language (such as C / C++), which is often used to encapsulate low-level operations or high-performance computing. In particular, Java Native Interface (JNI) methods are often stored in local files in application scenarios.

[0041] Java Class: refers to the unit used to organize and encapsulate data and functions. Java Method is a code segment defined in a Java class to perform a specific task. By calling a Java method, the function of the corresponding Java class can be started.

[0042] Input / Output (I / O) refers to the data transmission process between a computer system and external devices or environments, including the reading and writing of data. It is the basis for the interaction between the operating system and application programs and the outside world.

[0043] Virtual Thread: refers to a lightweight thread model that allows multiple tasks to be executed concurrently in the same operating system thread. It is particularly suitable for I / O intensive applications and can improve the concurrency and response speed of the program.

[0044] Platform Thread: refers to the traditional thread implementation, which is directly mapped to the operating system thread and is used to handle compute-intensive tasks. It is different from the virtual thread.

[0045] Spikes: refers to sudden performance degradation or delay in an application. Spikes are usually caused by instantaneous high load, resource competition or system bottlenecks, which will affect system stability and user experience.

[0046] Hypertext Transfer Protocol Server (HTTP Server): refers to a server that specializes in processing HTTP protocol requests. It is responsible for receiving requests from the network and returning corresponding resources or processing results.

[0047] Web Server: In addition to processing HTTP requests, the Web server also supports functions such as dynamic content generation and static file service. It is the infrastructure that supports the operation of websites and Web applications.

[0048] Microservices Architecture: refers to a software design pattern that decomposes a single application into a set of small, independent services. Each service is responsible for a specific function and communicates through clear APIs, which improves the scalability and independent deployment capabilities of the system.

[0049] Java Backend: refers to the server-side application developed in Java language, which is responsible for processing business logic, data management and interaction with the front end. Java backend is an important part of Web application architecture.

[0050] Stack Trace: refers to the record of the current call sequence of a thread during program execution. Stack trace includes a series of method calls and execution points, which can be used for debugging and performance analysis to help identify the source of errors and execution paths.

[0051] Java Agent: A special type of Java program that can be attached to the JVM when the application is started or running. It is used to monitor, modify or enhance the running Java application. Java Agent is an effective means of Java performance monitoring and debugging.

[0052] Just-In-Time Compiler (JIT compiler): compiles high-level language code (such as Java bytecode) into machine code in real time while the program is running, improving execution efficiency. However, due to the characteristics of dynamic compilation, the address layout of the program may change each time it runs, increasing the difficulty of obtaining accurate stack traces.

[0053] Probe: A tool used to monitor the runtime behavior of an application. It inserts monitoring points at key locations in the code to collect and report data during program runtime, which helps with performance analysis and fault detection.

[0054] Java Archive file (JAR file for short): refers to the file format used to package and distribute Java class libraries and applications, which can contain compiled class files, resource files, and metadata.

[0055] Synchronous Logging: The logging will wait for the log writing to be completed in the main program flow. Asynchronous Logging: The logging operation is separated to the background thread for execution, which reduces the blocking time of the main program.

[0056] According to an embodiment of the present application, an embodiment of a plugging method for an application is also provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0057] The method embodiment provided in the first embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal (or mobile device) for implementing a plugging method of an application program is shown. Figure 1As shown, the computer terminal 10 (or mobile device 10) may include one or more (shown as 102a, 102b, ..., 102n in the figure) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor (Microcontroller Unit, MCU) or a programmable logic device (Field Programmable Gate Array, FPGA)), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, the computer terminal 10 may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a computer bus), a network interface, a cursor control device (such as a mouse, a touchpad, etc.), a keyboard, a power supply and / or a camera.

[0058] It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations shown.

[0059] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10 (or mobile device). As involved in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0060] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the plugging method of the application program in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, the plugging method of the above-mentioned application program is realized. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0061] The transmission device 106 is used to connect to a network via a network interface to receive or send data. The specific examples of the above-mentioned network may include a wired and / or wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0062] like Figure 1 The display shown may be, for example, a touch screen liquid crystal display (LCD), which may enable a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0063] It should be noted that, in some optional embodiments, the above Figure 1 The computer device (or mobile device) shown may include hardware elements (including circuits), software elements (including computer code stored on a computer-readable medium), or a combination of hardware elements and software elements. It should be noted that Figure 1 This is merely one example of a particular embodiment and is intended to illustrate the types of components that may be present in the above-described computer device (or mobile device).

[0064] Under the above operating environment, this application provides Figure 2 The instrumentation method of the application is shown. Figure 2 1 is a flow chart of a method for inserting a stub of an application according to an embodiment of the present application. Figure 2 As shown, the method may include the following steps S201 to S204.

[0065] Step S201, determining the program code to be inserted from the application program.

[0066] The above-mentioned application can be, but is not limited to: Java program, enterprise-level application, mobile application, Java server-side application. When the application is running in the operating system, the program code to be plugged can be determined from the application, and the program code can be a Java method in the Java program. In other words, the above-mentioned program code can be plugged in during the running of the application. The plugging process is dynamic plugging, which realizes the execution flow tracking of the application at the operating system level.

[0067] Specifically, in response to the application running in the operating system, the program code to be plugged in the application is determined. Based on this, the dynamic nature of the application plugging solution is achieved, which means that the specific Java method that needs to be plugged can be identified without restarting the application.

[0068] In application scenarios, static code analysis and dynamic runtime monitoring can be combined to intelligently select the insertion points in the application to determine the program code to be inserted.

[0069] For example, during the static code analysis process, you can use tools or plug-ins to perform code reviews, analyze the source code or bytecode of the application, and identify key business logic branches, loop structures, method calls, data access, and other code areas that may become performance bottlenecks; you can use known performance analysis knowledge bases or models to predict which code paths may have resource contention, deadlocks, long-tail delays, and other problems under high concurrency or specific loads; you can also analyze historical performance data to identify methods and classes that are frequently executed or consume more resources, thereby determining candidate objects to be plugged in.

[0070] For example, during dynamic runtime monitoring, runtime performance monitoring tools (such as JavaVisualVM, JProfiler, Visual GC, etc.) can be used to collect application running data under real or simulated loads, including CPU usage, memory consumption, thread status, response time, etc., and further analyze the running data to identify the code segments that consume the most resources, have the longest response time, or exhibit abnormal behavior during actual execution. In addition, the hotspot analysis function can be used to automatically identify the code paths with the highest access frequency and the longest time consumption during application operation as the focus of dynamic instrumentation.

[0071] For another example, in the process of determining the program code to be instrumented from the application, a comprehensive strategy integrating static code analysis and dynamic runtime monitoring is adopted to intelligently locate performance bottlenecks. First, through static code analysis, a detailed list of candidate instrumentation points is established before the application is deployed, focusing on code segments that may become hot spots or cause performance problems. Subsequently, in the actual operating environment of the application, the dynamic performance data collection module continuously monitors key indicators such as thread behavior, resource consumption, and response time, and feeds these real-time conditions back to the analysis engine. Based on this, the analysis engine combines the information obtained from static analysis to intelligently identify the exact code segments, which can be regarded as the root causes of performance problems revealed in dynamic monitoring. Therefore, the instrumentation strategy can be dynamically adjusted to make the instrumentation strategy closer to the actual needs of the application and improve the accuracy of performance optimization.

[0072] In addition, considering the complexity of business logic and the needs of specific scenarios, developers and operation and maintenance personnel can also use intuitive interfaces or graphical user interfaces to manually select and adjust the classes and methods to be plugged in based on their insights into business processes or considerations of specific performance issues.

[0073] It should be noted that, in order to further improve the comprehensiveness and depth of the instrumentation, the embodiments of the present application can also incorporate system-level tracing technology to dynamically track the interaction between the application and the operating system (such as system calls, context switches, and input and output operations, etc.). In addition, in order to further enhance the instrumentation capability of virtual threads, the creation and scheduling modes of virtual threads can be carefully analyzed to accurately locate the code paths responsible for key tasks in high-concurrency scenarios, and instrumentation can be set for the code paths to achieve refined monitoring of virtual thread activities and resource allocation.

[0074] It should be noted that the embodiment of the present application can also introduce an event-driven instrumentation mechanism. By presetting events or performance thresholds, when an application encounters an abnormal situation during operation, such as long-term blocking or resource usage exceeding expectations, the instrumentation strategy is dynamically adjusted to quickly locate the problem code, greatly shortening the fault location time and improving the stability and response speed of the system.

[0075] As can be seen from the above, determining the program code to be inserted mainly relies on the in-depth understanding and analysis of the application program, combining static code review and dynamic runtime monitoring to identify those code locations that are critical to performance optimization. Such an intelligent plugging strategy can effectively reduce unnecessary monitoring overhead and focus resources on performance hotspots that need attention, thereby improving overall application performance and user experience. It is easy to notice that, based on the above step S201, the embodiment of the present application can adapt to any Java method, including those methods that are dynamically created or changed at runtime, providing a wide range of applications for subsequent plugging operations.

[0076] Step S202 , calling a target interface corresponding to the operating system, and determining a target probe configured for the program code, wherein the target probe is used to track data generated by the application program during the operation of the operating system.

[0077] Furthermore, the target interface corresponding to the operating system is called to determine the target probe configured for the program code, wherein the target probe is used to track the data generated by the application during the operation of the operating system. The above target interface may be an API for defining the target probe in the operating system. The target interface may be a predefined plug-in interface. In the application scenario, the target probe configured for the program code may include a preset number of types (e.g., 256 types) of Java probes. The target probe may perform execution flow tracking on the execution data generated by the application during the operation of the application.

[0078] In particular, the target interface can be a system-level interface such as Linux uprobe. The target interface can dynamically insert tracking points in user space programs. The target probes are configured as observation points associated with specific Java methods. Through these probes, detailed information of the program during runtime can be collected, including but not limited to CPU usage information, context switching information, I / O operation information, etc.

[0079] Step S203 , using the target interface to determine the insertion position in the program code, and determining the insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent the rules for performing the insertion operation on the program code.

[0080] According to the definition of the target probe, the instrumentation strategy corresponding to the target probe can be determined. Specifically, in the application scenario, there is a correspondence between different instrumentation strategies and different pre-defined probes. According to the correspondence and the target probe determined by calling the target interface, the instrumentation strategy can be determined. For example, the instrumentation strategy may include: log-based (Bwlog) instrumentation, JNI instrumentation.

[0081] Bwlog instrumentation is a log-based instrumentation technology that outputs logs in a specific format at a specified code location. These logs can then be parsed by trace tools to restore the Java execution flow. The advantage of Bwlog instrumentation is that it is flexible to implement. For example, a buffer-based synchronous log (with minimal execution overhead) can be used. In addition, Bwlog instrumentation can provide richer information (such as supporting the identification of virtual threads), but because it involves file I / O operations, the performance overhead of Bwlog instrumentation is usually higher than that of JNI instrumentation.

[0082] JNI instrumentation is an instrumentation technology based on JNI call implementation, which inserts calls to specific JNI methods (i.e. probes) at the target code location. JNI instrumentation is mainly used to adapt to tools that only support SO probes (such as Linuxuprobe). However, the limitation of JNI instrumentation is that it can only identify the platform thread of the caller and cannot accurately track virtual threads, but the advantage of JNI instrumentation is that it has higher execution efficiency and less I / O overhead.

[0083] In the application scenario, the location of the probe can be selected according to the user's configuration. For example, the location of the probe may include: method entry (call) location and / or return (ret) location. The probe strategy can be used to determine how to insert the probe, for example, using the log form or the JNI call form to insert the probe. The selection of the probe strategy directly affects the type of data to be traced and the system overhead of the tracing process.

[0084] Step S204 , performing an instrumentation operation on the program code according to the instrumentation strategy, so as to insert a target probe at the instrumentation position.

[0085] Furthermore, in the application scenario, the program code is instrumented according to the instrumentation strategy through the instrumentation API provided by the JVM. Specifically, the target probe code is added at the instrumentation location through a bytecode modification tool (such as Javassist or Byte Buddy) to ensure that the target probe can be activated at the correct location to collect the required data.

[0086] It is easy to notice that, through the above steps S201 to S204, the embodiment of the present application can realize dynamic plugging of the program code to be plugged (such as any Java method) during the operation of the application (such as a Java program) without restarting the application, and provides tracking of the program code call link by docking with the system-level trace tool. At the same time, key performance indicators at the operating system level can be collected, such as multi-threaded competition and I / O delay. In addition, the above scheme provided by the embodiment of the present application also supports plugging recovery and re-enabling, which is convenient for quickly locating and analyzing the performance problems of the application in the online environment. By flexibly configuring the probe type and the plugging strategy, the low intrusiveness of the plugging is guaranteed, and a comprehensive insight into the execution overhead is achieved, which greatly enhances the performance analysis capability and problem debugging efficiency of the application.

[0087] As can be seen from the above, in an embodiment of the present application, the program code to be plugged in is determined from the application; the target interface corresponding to the operating system is called to determine the target probe configured for the program code, wherein the target probe is used to track the data generated by the application during the operation of the operating system; the target interface is used to determine the plugging position in the program code, and the plugging strategy corresponding to the target probe is determined, wherein the plugging strategy is used to represent the rules for plugging the program code; according to the plugging strategy, the program code is plugged to insert the target probe at the plugging position. Therefore, the embodiment of the present application adopts the method of calling the target interface to insert the target probe into the program code running by the operating system, and in particular, it can determine the plugging position and plugging strategy in the program code, so as to achieve the purpose of automatically plugging into the application to support the execution flow tracking at the operating system level, thereby achieving the technical effect of improving the code plugging efficiency in the application and facilitating the execution flow tracking of the application at the operating system level, thereby solving the technical problem of low efficiency in the related technology of relying on manual code plugging into the application.

[0088] The following further describes the optional embodiments included in the above method provided in the embodiments of the present application.

[0089] In an optional embodiment, in step S203, determining the insertion position in the program code using the target interface includes the following method steps:

[0090] Step S231, using the target interface, determining an insertion position set, wherein different program codes correspond to different insertion positions in the insertion position set;

[0091] Step S232: using the target interface, determine the insertion position corresponding to the program code in the insertion position set.

[0092] In the above optional embodiment, the above target interface can support different program codes, and different insertion positions can be determined according to different program codes during multiple calls to the target interface. For example, the target interface supports any Java class and Java method, and the insertion position is specified multiple times. Each time the insertion is performed, the specific operation or specific behavior (action) to be performed can be freely selected at the corresponding insertion position. Based on this, data tracking can be performed at the beginning or end of any Java method.

[0093] In the application scenario, the target interface refers to the specific functions defined in the API (Application Programming Interface). The target interface allows users to interact with the dynamic instrumentation system to specify and control the details of the instrumentation. The instrumentation location set refers to a series of code locations that can be selected for instrumentation. These locations can be the entry (call) location of any method of any class in a Java program, the return (ret) location of any method, or the full life cycle (full) of the entire method. Different program codes correspond to different instrumentation locations in the instrumentation location set, which means that users can accurately specify the code segments they want to monitor or analyze according to specific needs, such as a specific class or method.

[0094] In the application scenario, the target interface is used to parse the configuration parameters provided by the user through the API to determine the set of instrumentation locations. These configuration parameters include but are not limited to the class name and method name that need to be instrumented, the instrumentation method (Bwlog instrumentation or JNI instrumentation), event name (event), timing action (action), distinguishing mark (tag), etc. Through these configuration parameters, the code segments to be monitored are identified, and the specific locations of these code segments in the Java program are determined, and then the instrumentation location set is determined.

[0095] Furthermore, the target interface is used to determine the insertion position corresponding to the program code in the insertion position set, and the position to be inserted is accurately determined to each specific method or code segment that needs to be monitored according to the insertion position set. In the process of determining the insertion position corresponding to the program code, the Java bytecode is read and modified. Through the Instrumentation API, the system can inject specific code or calls at the specified insertion position to monitor the program behavior.

[0096] Through the above steps S231 to S232, the embodiment of the present application can realize an accurate and flexible dynamic application program instrumentation mechanism. The user can select any program code (such as Java method) for instrumentation according to specific needs, and control the depth of instrumentation (such as call, ret or full) and the method of instrumentation (such as Bwlog instrumentation or JNI instrumentation).

[0097] In an optional embodiment, the application program instrumentation method further includes:

[0098] Step S233, obtaining configuration information of the target interface, wherein the configuration information is used to describe functions configured for the target interface, and the functions are associated with the instrumentation operation;

[0099] In step S203, the instrumentation strategy corresponding to the target probe is determined, including the following method steps:

[0100] Step S234, determining the instrumentation strategy from the configuration information.

[0101] In the above optional embodiment, the configuration information of the target interface may include function option information or configuration option information predetermined for the target interface. Based on this, the instrumentation strategy may be determined from the configuration information.

[0102] In the application scenario, the target interface can be an interface provided by the operating system for dynamically inserting tracking points, such as Linux's uprobe. The configuration information may include an instruction set related to the instrumentation operation, for example, in which specific Java method the user wants to perform instrumentation, whether the user wants to implement instrumentation through log output (log) or through JNI calls (type), and whether the user wants to mark specific events (event), marks (action can be start, end or mark), etc. Based on this, the user can flexibly determine the configuration information according to needs, thereby controlling the instrumentation strategy. In other words, through the above optional embodiments, the pertinence of instrumentation can be enhanced, unnecessary performance loss can be reduced, and the accuracy and practicality of Java program execution flow tracking can be improved.

[0103] Furthermore, the instrumentation strategy is determined from the configuration information. The instrumentation strategy is formulated based on the configuration information, and the instrumentation strategy specifically instructs the bytecode modification tool on how to add additional code to the Java method to achieve the instrumentation method and instrumentation purpose specified by the user. Based on this, the embodiment of the present application can support users to dynamically adjust the instrumentation behavior, and even during the program running, the instrumentation strategy can be changed instantly according to the new configuration information, without restarting the application (such as the Java program), thereby improving the efficiency of online debugging and performance analysis.

[0104] Through the above steps S233 to S234, the embodiment of the present application realizes the ability to dynamically configure and implement instrumentation, so that users can adjust the instrumentation strategy in real time according to actual needs when the application is running, and accurately track the execution overhead of specific methods. Based on this, the embodiment of the present application can enhance the understanding and location capabilities of Java developers and operation and maintenance personnel of application performance bottlenecks, especially when dealing with complex multi-threaded and microservice architectures, and can more effectively analyze and optimize request processing delays and improve service quality. At the same time, the embodiment of the present application can realize the adjustment of dynamic instrumentation strategies, avoid unnecessary waste of resources, and maintain the stability and efficiency of program performance.

[0105] In an optional embodiment, in step S234, determining the instrumentation strategy from the configuration information includes the following method steps:

[0106] Step S235, in response to the strategy selection operation, select a first instrumentation strategy or a second instrumentation strategy from the configuration information, wherein the first instrumentation strategy is used to represent the rules for instrumenting the program code based on the log information of the application, and the second instrumentation strategy is used to represent the rules for instrumenting the program code based on the target type program code, and the target type is a type other than the type of the program code.

[0107] The above-mentioned strategy selection operation can be a user's decision to use an instrumentation strategy based on log information or an instrumentation strategy based on the target type program code according to needs. The above-mentioned first instrumentation strategy, namely the Bwlog instrumentation strategy, is an instrumentation method that outputs a specific format log at a specified code location, which can provide rich method call information, including virtual thread identifiers, which helps to accurately track the execution process of each request in a multi-threaded environment. The output format and content of the Bwlog instrumentation strategy can be customized through configuration to meet different analysis needs. In the Java application scenario, when the user chooses the Bwlog instrumentation strategy, it means that the Java logging framework will be used to add additional log recording code to the program code, thereby recording relevant information before and after the Java method call, so as to facilitate the subsequent analysis of the log to understand the details of the execution flow.

[0108] The second instrumentation strategy is used to represent the rules for instrumenting program code based on the target type program code, where the target type is other types except the type of program code. The second instrumentation strategy, namely the JNI instrumentation strategy, is a technology for implementing instrumentation by calling JNI methods. This instrumentation method is mainly used to meet the needs of system-level trace tools (such as Linux uprobe) that only support SO file probes. In Java application scenarios, by inserting calls to JNI methods in Java code, the execution behavior of Java methods can be mapped to the trace tool at the operating system level, thereby obtaining lower-level performance data (such as the overhead of kernel events). When users select the second instrumentation strategy, it means adding calls to specific JNI functions in the program code, which are defined in local files (such as librtinstr.so). These JNI functions are triggered by operating system-level trace tools as target probes to record system-level information related to the execution of Java methods.

[0109] Through the above step S235, the embodiment of the present application implements a dynamic policy selection mechanism, allowing users to flexibly switch between log-based instrumentation and JNI-based instrumentation according to specific application scenarios and needs, thereby improving the adaptability and practicality of the application instrumentation solution. The log-based instrumentation strategy provides a high-information perspective that facilitates understanding the execution path and time distribution of the application, while the JNI-based instrumentation strategy provides strong support for scenarios that require access to operating system-level performance indicators. The log-based instrumentation strategy combined with the JNI-based instrumentation strategy ensures that comprehensive performance data can be obtained at both the Java application level and the system level, thereby more accurately locating and analyzing performance bottlenecks or abnormal delay problems, providing a technical basis for optimizing the performance and service quality of Java applications.

[0110] In an optional embodiment, the target probe may be in the form of log information or a probe function in a target format. In step S204, according to the plugging strategy, the program code is plugged in to insert the target probe at the plugging position, including the following method steps:

[0111] Step S241, in response to the instrumentation strategy being the first instrumentation strategy, performing an instrumentation operation on the program code based on the log information of the application program, so as to insert the log information in the target format at the instrumentation position;

[0112] Step S242 , in response to the instrumentation strategy being the second instrumentation strategy, performing an instrumentation operation on the program code based on the target type program code to insert a probe function at the instrumentation position.

[0113] In the above optional embodiment, when the instrumentation strategy is the first instrumentation strategy, the target probe is expressed as log information in the target format, that is, the target probe corresponding to the Bwlog instrumentation strategy is a log output in a specific format. When the instrumentation strategy is the second instrumentation strategy, the target probe is expressed as a probe function, that is, the target probe corresponding to the JNI instrumentation strategy is a JNI function.

[0114] It should be noted that under the Bwlog instrumentation strategy, in order to track the program execution process and performance indicators, log information can be output according to the predefined structure to obtain the log information in the above-mentioned specific format. This log format is convenient for subsequent analysis tools to identify and parse, so as to accurately capture and analyze the behavior, call sequence and resource consumption of the program at runtime. When the instrumentation strategy is set to the first instrumentation strategy, the system will perform instrumentation operations by inserting log information in a specific format at the specified instrumentation location. These log information will record the start and end time of the method call and possible intermediate marking points, including the identification of the virtual thread, etc.

[0115] Specifically, when adopting the first instrumentation strategy (i.e., the Bwlog instrumentation strategy), special-formatted log statements are precisely inserted at selected positions in the code based on the existing log framework and information of the target application. This involves specifying parameters such as the class name, method name, instrumentation position (such as method entry or exit points), event type, and expected log format (such as containing elements like timestamp, thread identifier, event name, etc.) through a command-line tool. After receiving these parameters, the command-line tool uses the Instrumentation API and bytecode manipulation techniques to dynamically modify the bytecode of the running application, achieving the insertion of formatted log output code at the specified code positions. Thus, whenever the target method is called or returns, the application automatically outputs log information conforming to the preset format, recording the details of the execution flow and key performance indicators, thereby providing a detailed data basis for subsequent performance analysis and problem location.

[0116] According to the above step S241, the log information of the application is used as the data source for the tracing tool. Although this instrumentation method involves file input and output, it can provide richer execution flow information, including but not limited to method call stacks, identification of virtual threads, etc. Although the performance overhead of this instrumentation method may be relatively slightly higher, due to the use of a synchronized log output method with a buffer, while ensuring information integrity, the impact on program operation is minimized. The solution where the above instrumentation strategy is set as the first instrumentation strategy is particularly applicable to scenarios where detailed understanding of the execution path and time decomposition is required.

[0117] When the instrumentation strategy is set as the second instrumentation strategy, based on the target type of program code, instrumentation operations are performed on the program code to insert probe functions at the instrumentation positions.

[0118] Specifically, when selecting the second instrumentation strategy (i.e., the JNI instrumentation strategy), the system inserts JNI function calls as probes at the entry or exit positions of the specified Java methods. The above operations are based on the target Java code and are achieved by dynamically modifying the bytecode without the need for recompilation or restarting the application. The probe functions are located in the supporting native library and can work in coordination with system-level tracing tools to capture fine-grained information about method calls (such as start and end times) in real time, effectively supporting the requirements of high-performance and low-intrusion execution flow tracing.

[0119] The above-mentioned probe functions are pre-defined in the shared objects or dynamic link library files supported by the system-level trace tool. For example, the probe functions may include: jni_start_00, jni_start_01, ..., jni_mark_ff, etc. in the librtinstr.so file. In the Java application scenario, by inserting calls to these probe functions at specific locations of the Java program, the embodiments of the present application can seamlessly connect with the system-level trace tool (such as Linux uprobe) to achieve the timing of the start, end and mark of the Java method call, as well as the corresponding event tracking. The advantage of the above-mentioned plug-in strategy being set to the second plug-in strategy is low intrusiveness and low performance overhead.

[0120] Through the above steps S241 to S242, the embodiment of the present application provides comprehensive support for the execution flow tracking of the application program through the instrumentation strategy based on log information and the instrumentation strategy based on probe functions. Users can choose the appropriate instrumentation strategy according to actual needs and performance considerations to achieve a detailed analysis of the execution overhead of program code (such as Java methods), including but not limited to method time consumption, call stack, virtual thread identification, etc. At the same time, by docking with system-level trace tools, the solution provided by the embodiment of the present application can capture and analyze deeper performance data, thereby realizing cross-language and cross-system performance analysis, and significantly enhancing the performance monitoring and optimization capabilities of Java applications.

[0121] In an optional embodiment, the application program instrumentation method further includes the following method steps:

[0122] Step S251, in response to the instrumentation strategy being the first instrumentation strategy, identifying a virtual thread corresponding to the program code, and obtaining identification information of the virtual thread;

[0123] Step S252: Use the identification information and the target probe to trace the virtual thread to obtain a trace result of the virtual thread.

[0124] In the above optional embodiment, when the instrumentation strategy is the first instrumentation strategy, the virtual thread corresponding to the program code is identified, and the identification information of the corresponding virtual thread is output in the log.

[0125] In Java application scenarios, the above virtual thread is a new thread model introduced by Java, which can execute multiple tasks concurrently in the same operating system thread to improve concurrency and reduce the switching overhead between threads. In Java applications, the identification information of virtual threads usually includes thread identifiers and other metadata, which can be used to track the execution flow of virtual threads.

[0126] Specifically, the above identification information may also specifically refer to data that can uniquely identify a virtual thread, including but not limited to the thread identification, thread group information, priority, etc. of the virtual thread. These identification information are used in the dynamic instrumentation technology to ensure that the instrumentation code can be accurately associated with the correct virtual thread, so as to collect the execution flow data related to the virtual thread. The above instrumentation code refers to the code snippet dynamically inserted in the Java method for collecting execution flow data.

[0127] The above tracing results refer to the detailed data reflecting the execution flow of the virtual thread collected after instrumenting and tracing the virtual thread. The data in the tracing results may include the CPU usage time, I / O waiting time, context switching time, call stack information, etc. of the virtual thread. The tracing results provide key information for evaluating and optimizing the performance of the virtual thread.

[0128] In the Java application scenario, based on the above step S251, by dynamically inserting specific code (i.e., target probe) in the specified Java method, identification information is captured when the virtual thread enters or exits the Java method. The system needs to be able to understand the thread model inside the Java virtual machine in order to accurately identify and mark the virtual thread when performing dynamic stubbing.

[0129] Furthermore, the virtual thread is tracked using the identification information and the target probe to obtain the tracing result of the virtual thread. After obtaining the identification information of the virtual thread, the system can use the identification information and the previously set target probe to track and record the activities of the virtual thread in detail. Specifically, the tracing process involves executing specific code at the instrumentation location to capture the state and behavior of the virtual thread at a certain moment, and then generating tracing results based on the collected data. For example, if a virtual thread triggers a probe when calling a method, the system will record the timestamp, input parameters, output parameters, execution time, and call stack information of the call as the tracing result. The tracing results can be used to analyze and optimize the performance of the virtual thread.

[0130] Through the above steps S251 to S252, the embodiment of the present application can achieve dynamic plugging and tracking of virtual threads when the application is running, without restarting the application process, and obtain high-precision virtual thread execution flow data. Based on this, the embodiment of the present application can directly promote the in-depth understanding and rapid location of virtual thread performance issues, especially in large-scale distributed systems and microservice architectures, and can help developers and operation and maintenance personnel more effectively analyze and optimize the concurrent performance of applications and improve user experience. In addition, based on the above scheme, it can also provide developers with a new tool that enables developers to understand the operating mechanism and performance bottlenecks of virtual threads in more detail, so as to better utilize virtual threads to improve the concurrent processing capabilities of applications.

[0131] In an optional embodiment, the configuration information further includes at least one of the following:

[0132] Startup configuration information, used to indicate the function of starting the instrumentation operation;

[0133] Class configuration information, used to indicate the class where the instrumentation operation is performed;

[0134] Position configuration information, used to indicate the insertion position corresponding to the insertion operation;

[0135] Strategy configuration information, used to indicate the instrumentation strategy corresponding to the instrumentation operation;

[0136] Identification configuration information, associated with the instrumentation location, and used to identify events that occur during the process of tracing application data;

[0137] Behavior configuration information is used to indicate the operation behavior corresponding to the target probe.

[0138] The above startup configuration information is used to indicate the function of starting the instrumentation operation, including when and how to start the instrumentation. The startup configuration information can be started through specific command line parameters or through specific API calls when the program is running.

[0139] For example, the user can use the command <jdk> / bin / java -jar rtinstr.jar <pid><MyClass.myMethod>Start the instrumentation, here <jdk> 、 <pid>And <MyClass.myMethod> are both part of the startup configuration information. Thus, the embodiments of this application support dynamic loading of instrumentation without restarting the application, improving the efficiency and convenience of online debugging.

[0140] The above class configuration information is used to represent the class where the instrumentation operation is performed, that is, the Java class name that the user hopes to instrument. By specifying the class configuration information, the embodiments of this application can accurately instrument the classes that the user is interested in without affecting other parts of the program, which provides a high degree of focus and control for the developers of the application.

[0141] The above location configuration information is used to represent the instrumentation location corresponding to the instrumentation operation, that is, at which stage of the Java method call to insert the probe, which can be the Java method entry (call) location, the Java method exit (ret) location, or the entire Java method full process (full). The location configuration information ensures the accuracy and depth of the instrumentation. The user can select the most suitable monitoring point according to the need to obtain the required data type and coverage.

[0142] The above strategy configuration information is used to represent the instrumentation strategy corresponding to the instrumentation operation, that is, the specific implementation method of the instrumentation, such as the Bwlog instrumentation strategy based on log information or the JNI instrumentation strategy based on JNI calls. Each instrumentation strategy has unique advantages and applicable scenarios. The strategy configuration information enables the user to make a balanced choice between low overhead and high information content, improving the usability of the traced data.

[0143] The above identification configuration information is associated with the instrumentation location and is used to identify the events that occur during the process of tracing the data of the application. The identification configuration information is implemented through a user-defined tag parameter (tag). This tag parameter can be a hexadecimal number, which is used to distinguish different types of events. Especially when tracing nested or overlapping execution flows, the tag parameter helps to ensure the clear identification and classification of events.

[0144] The above behavior configuration information is used to represent the operation behavior corresponding to the target probe, such as start timing, end timing, or marking. The behavior configuration information guides the probe to perform specific actions at different stages of the program execution to ensure the accuracy and integrity of the traced data.

[0145] In an exemplary application scenario, according to the above instrumentation method of the application, an API function definition corresponding to an instrumentation tool can be provided. By calling this API, a flexible Java method-level instrumentation function can be implemented, supporting fine-grained runtime tracing through configuration instructions. The call format of this API is expressed as: "

[0146] <jdk> / bin / java -jar rtinstr.jar <pid>\

[0147] <target class.method>[:insertion location][:type][:event name][:operation][:label] \

[0148] [Other classes.Methods...] \

[0149] [Log Path] \

[0150] [local library path] \

[0151] [Uninstall Options]".

[0152] The main configuration items of the above API are described as follows.

[0153] First, the basic call is to start the instrumentation tool by specifying the JDK path, the target Java process PID and rtinstr.jar. This JAR package encapsulates all instrumentation function implementations.

[0154] Second, the target method is configured as follows: it supports specifying multiple class methods at the same time (such as MyClass.myMethod), and the insertion location can be at the method entry (call), before each return point (ret), and the entire process (full, including both call and ret).

[0155] Third, the instrumentation strategy type is: Bwlog instrumentation strategy or JNI instrumentation strategy.

[0156] Fourth, event tracking is: naming the insertion point through the event parameter to facilitate subsequent data aggregation analysis; supporting the acquisition of percentile statistics.

[0157] Fifth, the operation type is: start event timing (start), end event timing (end), auxiliary mark (mark). When the operation type is not specified, the full mode automatically inserts start / end at the entry / return point.

[0158] Sixth, the extended configuration includes: hexadecimal tags (tag) to distinguish different execution flows; custom log storage path (logpath); specify the local dependency library path (nativepath); remove all stubs to restore the original state (uninstall).

[0159] Based on the above API, the Linux uprobe is connected to the system-level tracing tool to achieve a complete monitoring link from Java methods to system calls. Different types of instrumentation methods (Bwlog / JNI) have their own characteristics.

[0160] Through the definition and use of the above configuration information, the embodiment of the present application realizes dynamic instrumentation of highly customized applications. Users can flexibly specify the start conditions, target classes, instrumentation locations, instrumentation strategies, and identification and behavior definitions of tracing events. The above mechanism can broaden the application scenarios of execution flow tracing, so that tracing is not limited to a single method, but can cover the entire program execution link. At the same time, the ability to dynamically adjust the instrumentation strategy ensures that the tracing process can adapt to performance requirements in different environments, reduces the impact of tracing on the application itself, and improves the quality and reliability of tracing data. Based on the above customized instrumentation method, powerful tools can be provided for developers and operation and maintenance personnel to understand and optimize the performance of applications in a more refined manner. In particular, the above tools can show significant advantages in dealing with complex multi-threaded and microservice architectures.

[0161] In an optional embodiment, after inserting the target probe at the insertion position, the application program insertion method further includes the following method steps:

[0162] Step S206 , using the target probe to execute the operation behavior corresponding to the behavior configuration information, so as to track and obtain the data generated by the application at the code level and the data generated at the system level.

[0163] The target probe is a code snippet or function call inserted at the specified instrumentation location to capture key information during program execution. The target probe can be a log message in a specific format or a probe function. The specific form is determined by the instrumentation strategy. In the Java application scenario, the target probe is designed to work with system-level trace tools (such as Linux uprobe) to complete the tracking of the Java program execution flow.

[0164] The above behavior configuration information may refer to the instrumentation strategy. The above behavior configuration information includes the instrumentation location (call, ret or full), instrumentation method (log or JNI), event name (event), timing action (action), distinguishing mark (tag), etc. In the Java application scenario, these behavior configuration information constitutes the instruction set of how to execute the target probe, determines when the probe is triggered (start, end or mark) during the execution of the Java method, and how to identify and classify the collected data.

[0165] The above operation behavior refers to the specific operation performed by the target probe when the program is running based on the behavior configuration information. For example, when the Bwlog instrumentation strategy is adopted, the target probe will record logs at the start and end points of the method call, providing detailed time information and method call stack information of the Java method call. When the JNI call instrumentation strategy is adopted, the target probe will call the JNI functions pre-defined in the local file (such as librtinstr.so). These JNI functions act as probes and cooperate with the system-level trace tool to capture lower-level performance data.

[0166] By using the target probe to execute the operation behavior corresponding to the behavior configuration information, the obtained tracking data can include two levels of data: code-level execution flow data, including method call time, call order, and call relationship; system-level performance data, involving operating system-level events, such as context switching and I / O operation overhead. The above tracking data is obtained by executing the operation behavior configured by the target probe, providing key information for subsequent performance analysis and optimization.

[0167] Through the above-mentioned step S206, the embodiment of the present application realizes dynamic and fine-grained tracking of application execution, while taking into account data collection at the code level and the system level. This tracking solution can capture and record the call time, call link and dependent system resource consumption of program code (such as Java methods) during program execution, so that developers can not only understand the performance of the program code itself, but also gain insight into performance bottlenecks at the operating system level (such as multi-threaded competition and I / O delays). The above-mentioned comprehensive tracking data provides strong support for the performance optimization of applications, especially in complex server-side applications (such as HTTP servers, Web servers, and microservices, etc.), which can help locate and solve delay problems and improve user experience. In addition, the dynamic nature of the above-mentioned solution means that plugging and tracking can be performed without restarting the application, which enhances the practicality of the solution.

[0168] In an optional embodiment, in step S204, according to the plugging strategy, the program code is plugged in to insert the target probe at the plugging position, including the following method steps:

[0169] Step S243 , according to the plugging strategy, the program code in the running process is plugged in to insert the target probe at the plugging position.

[0170] Based on the above optional embodiments, during the running of the application, the program code is instrumented according to the instrumentation strategy to insert the target probe at the instrumentation position, which reflects the dynamic and non-invasive nature of the solution and is an important improvement over the static instrumentation technology in related technologies.

[0171] In the Java application scenario, the instrumentation operation is performed according to the instrumentation strategy. The system will insert probes in real time at the specified program code location according to the functions and rules configured by the user through the target interface. For example, if the user selects the first instrumentation strategy (i.e., the Bwlog instrumentation strategy), the system will insert log information in a specific format at the instrumentation location of the program code based on the application's log information. These log information will record the start, end, and mark points of the method call, providing a detailed execution flow track. On the other hand, if the user selects the second instrumentation strategy (JNI instrumentation strategy), the system will insert probe functions pre-defined in local files (such as librtinstr.so) at the instrumentation location based on the target type program code, thereby tracking the time and events of method calls.

[0172] It should be noted that the key point of dynamic plugging technology is to perform plugging operations on program code in the running process. Traditional plugging methods usually require the application to be recompiled and deployed after being modified, while the embodiment of the present application can dynamically modify the bytecode while the application is running without restarting the process. Based on this, the application developer or operation and maintenance personnel can adjust and enable the plugging strategy in real time without affecting the application service, and monitor and analyze the performance problems in the online environment in real time.

[0173] Through the above step S243, the embodiment of the present application can realize dynamic and non-invasive execution flow tracking of the application. By inserting the target probe on demand when the application is running, whether it is a log-based instrumentation strategy or a JNI-based instrumentation strategy, the time point and related data of the program code call can be captured in real time, which provides strong support for tracking request delays, analyzing multi-threaded competition and I / O delays. In other words, the above step S243 directly provides the application with a means of real-time performance monitoring and analysis without going through a tedious restart and deployment process, thereby improving the efficiency of online problem location and performance optimization.

[0174] In an optional embodiment, in step S204, according to the plugging strategy, the program code in the running process is plugged to insert the target probe at the plugging position, including the following method steps:

[0175] Step S244, determining the target program code of the target probe;

[0176] Step S245 , according to the plugging strategy, calling the bytecode modification tool to plug the program code in the running process, so as to insert the target program code at the plugging position.

[0177] In Java application scenarios, the target probes mentioned above refer to the code or functions inserted into Java programs to track specific events or collect runtime data. Target probes can be in various forms. Depending on the instrumentation strategy, target probes can be log information in a specific format or probe functions.

[0178] When the instrumentation strategy selects the Bwlog instrumentation strategy based on log information, the target program code is the code snippet that generates the target format log information at the specified location. When the instrumentation strategy selects the JNI instrumentation strategy based on JNI calls, the target program code is the code snippet that calls the JNI function predefined in the local file (such as librtinstr.so). The selection and insertion of the target program code is performed dynamically according to the user-specified instrumentation strategy, ensuring the flexibility and low intrusiveness of the instrumentation operation.

[0179] The above-mentioned bytecode modification tool refers to a tool that can read and modify Java bytecode. Using the bytecode modification tool, even if the Java program has been compiled into bytecode, additional code can be dynamically inserted at runtime. Common bytecode modification tools include Javassist and Byte Buddy. Through these bytecode modification tools, the embodiments of the present application can modify the program code and insert the target probe without restarting the Java process.

[0180] The program code in the running process refers to the code being executed by the Java virtual machine, not the code in the editing or compiling stage. Based on this, the embodiment of the present application can dynamically perform plugging operations on these codes without interrupting the execution of the program, which means that Java developers or operation and maintenance personnel can adjust the plugging strategy in real time without affecting the application service, and conduct refined tracking of the execution flow of the application.

[0181] According to step S244, the process of determining the target program code of the target probe is to parse out the specific locations of the Java classes and Java methods that need to be plugged based on the configuration information provided by the user through the target interface. The system will decide what type of target program code to insert according to different plugging strategies.

[0182] According to step S245, according to the plugging strategy, the bytecode modification tool is called to plug the program code in the running process, so as to insert the target program code at the plugging position. This process involves reading the bytecode of the Java class at runtime, dynamically modifying the bytecode according to the plugging strategy, inserting the target probe code, and then reloading the modified bytecode into the Java virtual machine for execution.

[0183] Through the above steps S244 to S245, the embodiment of the present application can dynamically insert the program code without restarting the application process. The user can flexibly select the insertion strategy, configure the insertion location and probe type, and insert specific tracking code into the program code of the application, which not only reduces the cost of online problem location, but also allows for a detailed analysis of the execution flow, especially when dealing with complex multi-threaded and microservice scenarios, so that the execution overhead and performance bottlenecks of the request can be more accurately understood, and the stability of the application and user experience can be improved. In addition, the implementation of dynamic insertion also avoids the redundant code and compatibility issues that may be caused by traditional static insertion, so that the insertion strategy can be adjusted at any time according to demand, which improves the practicality and flexibility of the solution.

[0184] In an optional embodiment, in step S201, determining the program code to be plugged from the application program includes the following method steps:

[0185] Step S211, in response to the application running in the operating system, determining the program code to be inserted in the application based on the request message, wherein the request message is used to request to obtain information of the application and / or request the application to perform a task.

[0186] In the above optional embodiment, the request message can be a request sent by the user to the Java virtual machine through a specific tool or command line, aiming to obtain the running information of the application or request the application to perform a specific task. This request message usually contains the information of the specific Java method or Java class that the user wants to track or analyze. For example, in the Java application scenario, when executing the command <jdk> / bin / java -jar rtinstr.jar <pid><MyClass.myMethod>hour,<MyClass.myMethod> It is a part of the request message, which is used to specify the program code to be instrumented. The format and content of the request message vary according to the specific application scenario and tool design. The request message serves as the trigger condition and configuration basis for the dynamic instrumentation operation.

[0187] The program code to be inserted in the above application is determined based on the information contained in the request message. Specifically, the program code refers to the Java class and Java method in which the user wants to insert the probe or tracing code. The flexibility of dynamic instrumentation technology lies in that the user can specify the insertion location in any Java method, which means that no matter how frequent or complex the Java method is called, the user can specify the insertion location of the Java method through the request message, so that the Java method can be monitored and analyzed in real time.

[0188] The above-mentioned dynamic instrumentation is a technology that can modify the bytecode to insert tracking or monitoring code while the program is running without restarting the process. According to the above-mentioned step S211, the triggering of dynamic instrumentation is based on the prerequisite that the application is running in the operating system. After receiving the request message, the system performs the instrumentation operation in real time according to the program code location specified in the message. In the Java application scenario, the process of performing the instrumentation operation utilizes the Instrumentation API of the Java virtual machine, so that the instrumentation operation can be performed without interrupting the application service, which improves the efficiency of performance monitoring and problem location in the online environment.

[0189] Through the above step S211, the embodiment of the present application dynamically determines and inserts the program code to be monitored (such as Java classes, Java methods) by responding to the running status of the application and the received request message, thereby realizing real-time monitoring and tracking of the program code during the execution of the application. The above steps support application developers and operation and maintenance personnel to instantly adjust and enable performance monitoring by sending request messages without restarting the application. This solution not only reduces the cost of online problem locating, but also allows the capture of real application behavior under actual load, providing strong support for performance optimization and troubleshooting. In particular, for scenarios that require continuous operation and response to requests, dynamic insertion can perform refined performance analysis without interfering with normal services, greatly improving efficiency and flexibility.

[0190] In an optional embodiment, in step S211, in response to the application program running in the operating system, determining the program code to be plugged in the application program based on the request message includes the following method steps:

[0191] Step S212, in response to the application program running in the operating system, identifying different types of request messages, wherein the different types of request messages are independent of each other;

[0192] Step S213, in response to different types of request messages, determining different program codes to be inserted in the application, wherein different program codes correspond to different types of request messages.

[0193] In the above optional embodiment, different types of request messages may be request messages of a custom probe type, request messages of an embedded additional information type, etc. Different types of request messages will not interfere with each other.

[0194] In the application scenario, a request message refers to information sent by the client to the server that contains an operation or data request. These request messages can be of different types, such as HTTP requests, Web service calls, database queries, etc. The processing logic and execution flow of each type of request message may be completely different.

[0195] Furthermore, the system needs to dynamically identify and distinguish different types of request messages when the application is running, that is, in the operating system environment. The type of the request message is identified based on the format, content, or context of the request. For example, for HTTP requests, the type of the HTTP request can be identified by parsing the method type (GET, POST, etc.) or URL in the request header; for microservice requests, the type of the microservice request may be identified by the protocol or message format of the service call.

[0196] Different types of request messages are independent of each other, that is, different types of request messages are independent in processing and tracing, that is, the stub code and strategy for processing one type of request message will not affect other types of request messages. This ensures the accuracy and pertinence of tracing and avoids confusion and interference between the execution flows of different types of request messages.

[0197] Furthermore, the system determines the specific parts of the application that need to be instrumented, that is, different program codes, based on different types of request messages. These different program codes refer to Java methods or Java classes responsible for processing corresponding types of request messages. For example, the code for processing HTTP requests may be located in the request processor of the Web server, while the code for processing database calls may be located in the database access interface layer.

[0198] Furthermore, based on the type and processing logic of the request message, different program codes to be plugged are determined. For each type of request message, the system identifies the program code most relevant to the request message, and then applies dynamic plugging technology to these program codes to track the execution flow of the program code.

[0199] Through the above steps S212 to S213, the embodiment of the present application can intelligently identify and distinguish different types of request messages when the application is running, and accordingly determine and perform dynamic plugging of different program codes to be plugged in. This not only means that developers and operation and maintenance personnel can track the request execution flow in a fine-grained manner without modifying the code or restarting the application, but also ensures the independence and accuracy of the request message processing logic for each type. This dynamism and pertinence significantly improves the efficiency and effectiveness of execution flow tracking, especially in the application scenarios of dealing with complex multi-threading and microservice architectures, and can more accurately locate performance bottlenecks and optimization points, improving the response speed and user experience of the application. In addition, the above-mentioned ability to intelligently identify request message types also enables the above-mentioned solution to adapt to a wide range of application scenarios and request patterns, enhancing the practicality and flexibility of the solution.

[0200] In an optional embodiment, after inserting the target probe at the insertion position, the application program insertion method further includes at least one of the following method steps:

[0201] Step S207, deleting the target probe in the application after the instrumentation, and obtaining the application before the instrumentation;

[0202] Step S208, performing a deduplication operation on multiple target probes inserted at the insertion position;

[0203] Step S209, recording the call stack information of the application program's thread during its operation.

[0204] In the Java application scenario, based on the above step S207, the dynamic bytecode modification capability of the Java virtual machine is utilized to delete the target probe in the application after the insertion, and obtain the application before the insertion. Specifically, when the user issues a command for the insertion recovery through the target interface, the system will call the bytecode modification tool again, read the bytecode of the current program, remove the previously inserted target probe code, and then reload the restored bytecode into the Java virtual machine for execution. Based on this, the embodiment of the present application allows the user to dynamically restore the state before the insertion without restarting the application, thereby avoiding the performance overhead introduced by the insertion operation from continuously affecting the normal operation of the application, and improving the practicality and flexibility of the embodiment of the present application.

[0205] Based on the above step S208, deduplication operations are performed on multiple target probes inserted at the insertion position. In the Java application scenario, the user can specify the insertion multiple times and perform the insertion operation on the same Java method or different Java methods. Especially when tracing complex execution flows, the same target probe may be inserted at multiple locations. The above deduplication operation on multiple target probes ensures that even if the user repeatedly specifies the same insertion position and probe type, the system will only insert one probe, avoiding code redundancy and potential performance impact. Based on this, the embodiment of the present application not only improves the efficiency of the insertion operation, but also ensures the accuracy of the insertion, and ensures the consistency and validity of the tracking data. Through probe deduplication, runtime errors and resource waste caused by repeated probe insertion are avoided, and the performance of dynamic insertion is further optimized.

[0206] Based on the above step S209, the call stack information of the application's thread during operation is recorded. In the Java application scenario, in the process of implementing the tracing function of the Java stack trace tool, regardless of whether the instrumentation strategy selects the first instrumentation strategy (Bwlog instrumentation strategy) or the second instrumentation strategy (JNI instrumentation strategy), the system will record the call stack information when the Java method is called, that is, the method call path. For the Bwlog instrumentation strategy, the system will add the call stack information to the output of the target probe; and for the JNI instrumentation strategy, although the probe itself does not directly output the call stack, the embodiment of the present application can provide a mapping mechanism for generating and maintaining Java memory to symbols, so that the system-level trace tool (such as Linux uprobe) can parse and record the Java stack trace according to the above mapping mechanism. Based on this, the embodiment of the present application provides the necessary Java stack trace information for the system-level trace tool, so that developers can not only track the time overhead of Java method calls, but also see the specific call path, which helps to understand complex multi-threaded interactions and execution flow links. By recording the call stack information, the embodiment of the present application improves the depth and accuracy of execution flow tracing, making performance analysis more detailed and comprehensive.

[0207] Through the above steps S207 to S209, the embodiment of the present application can further optimize the recovery, deduplication and call stack tracing functions of the instrumentation on the basis of dynamic instrumentation, and provide a powerful execution flow tracing tool for application developers and operation and maintenance personnel. The state before instrumentation can be restored without restarting the application, avoiding the continuous performance impact caused by instrumentation, and improving the efficiency and convenience of online problem location. Instrumentation deduplication ensures the accuracy and efficiency of instrumentation, and avoids resource waste and runtime errors caused by repeated insertion of probes. The recording of call stack information deepens the understanding of the execution flow, so that performance analysis can cover the details of method calls, and improves the ability of the solution to track complex execution flows. Based on this, the embodiment of the present application can further enhance the flexibility, efficiency and comprehensiveness of dynamic instrumentation technology, and provide strong support for performance optimization and problem solving of applications.

[0208] In the aforementioned operating environment, the present application also provides Figure 3 An instrumentation method for an application is shown. Figure 3 is a flowchart of another application program instrumentation method according to an embodiment of the present application, wherein the application program instrumentation method is applied to a tracking tool, such as Figure 3 As shown, the instrumentation methods of this application include:

[0209] Step S301, determining a program code to be plugged from an application program, wherein the program code is a code in an object-oriented programming language;

[0210] Step S302, calling an application programming interface corresponding to the operating system to determine a target probe configured for the program code, wherein the target probe is used to perform execution flow tracking on data generated at the code level and at the system level during the operation of the application program in the operating system;

[0211] Step S303, using the application programming interface to determine the location of the plug-in in the program code, and determine the plug-in strategy corresponding to the target probe, wherein the plug-in strategy is used to represent the rules for performing the plug-in operation on the program code;

[0212] Step S304, performing an instrumentation operation on the program code according to the instrumentation strategy to insert a target probe at the instrumentation position;

[0213] Step S305 , using the target probe inserted at the insertion position, perform execution flow tracing on the data generated by the application at the code level and the data generated at the system level to obtain a tracing result.

[0214] The above-mentioned tracing tool may be an execution flow tracing tool (i.e., a trace tool) of an application. That is, the above-mentioned execution flow tracing tool may perform an instrumentation operation on the program code according to the instrumentation method of the above-mentioned application and the instrumentation strategy, so as to insert a target probe at the instrumentation position. Furthermore, the above-mentioned execution flow tracing tool uses the target probe inserted at the instrumentation position to perform execution flow tracing on the data generated by the application at the code level and the data generated at the system level to obtain a tracing result.

[0215] In an embodiment of the present application, a program code to be inserted is determined from an application program, wherein the program code is a code in an object-oriented programming language; an application programming interface corresponding to the operating system is called to determine a target probe configured for the program code, wherein the target probe is used to perform execution flow tracing on data generated by the application program at the code level and at the system level during the operation of the operating system; the application programming interface is used to determine an insertion position in the program code, and an insertion strategy corresponding to the target probe is determined, wherein the insertion strategy is used to represent a rule for performing an insertion operation on the program code; according to the insertion strategy, the program code is inserted to insert the target probe at the insertion position; and the target probe inserted at the insertion position is used to perform execution flow tracing on the data generated by the application program at the code level and at the system level to obtain a tracing result. Therefore, the embodiment of the present application adopts the method of calling the target interface to insert the target probe into the program code running in the operating system. In particular, it can determine the location and strategy of the plug-in in the program code, and achieve the purpose of automatically plugging into the application to support the execution flow tracking at the operating system level, thereby achieving the technical effect of improving the efficiency of code plugging in the application and facilitating the execution flow tracking of the application at the operating system level, thereby solving the technical problem of low efficiency of manual code plugging in the application in the related technology. Furthermore, based on the efficient code plugging method, the execution flow tracking of the data generated by the application at the code level and the data generated at the system level is improved, which improves the timeliness and accuracy of the tracking results.

[0216] It should be noted that the preferred implementation of the above steps S301 to S305 can be found in the above-mentioned related descriptions and will not be repeated here.

[0217] In the aforementioned operating environment, the present application also provides Figure 4 Another application instrumentation method is shown. Figure 4 is a flowchart of another application program instrumentation method according to an embodiment of the present application. Figure 4 As shown, the instrumentation methods of this application include:

[0218] Step S401, obtaining a program code to be plugged in an application program by calling a first interface, wherein the first interface includes a first parameter, and a parameter value of the first parameter includes the program code;

[0219] Step S402, calling a target interface corresponding to the operating system to determine a target probe configured for the program code, wherein the target probe is used to track data generated by the application during the operation of the operating system;

[0220] Step S403, using the target interface to determine the location of the plug-in in the program code, and determining the plug-in strategy corresponding to the target probe, wherein the plug-in strategy is used to represent the rules for plugging the program code;

[0221] Step S404, performing an instrumentation operation on the program code according to the instrumentation strategy to insert a target probe at the instrumentation position;

[0222] Step S405: outputting the program code after the instrumentation by calling the second interface, wherein the second interface includes a second parameter, and a parameter value of the second parameter includes the program code after the instrumentation.

[0223] The plugging method of the above-mentioned application in the embodiment of the present application can be run in the cloud server to provide the client with the plugging cloud service of the application. The client calls the first interface to send the plugging request of the application, and after the cloud server obtains the program code to be plugged in the application corresponding to the plugging request of the application through the first interface, it generates the plugged program code according to the plugging method of the application, and further returns the plugged program code to the client through the second interface.

[0224] The above-mentioned first interface and the second interface may be the same interface or different interfaces. In an optional embodiment, the interface parameters in the above-mentioned first interface and the second interface may include but are not limited to: interface global identifier, interface signature key, interface timestamp, interface request identifier, system call credential identifier, etc. The above-mentioned first interface may use a get request (GET) or a submit request (POST) as an interface request method to obtain a file processing request. The above-mentioned second interface may use a lightweight data exchange format (such as JavaScript Object Notation format, referred to as JSON format) to feedback a file processing response.

[0225] In an embodiment of the present application, in response to an application program running in an operating system, a program code to be inserted in the application program is obtained by calling a first interface, wherein the first interface includes a first parameter, and the parameter value of the first parameter includes the program code; a target interface corresponding to the operating system is called to determine a target probe configured for the program code, wherein the target probe is used to track data generated by the application program during the operation of the operating system; the target interface is used to determine an insertion position in the program code, and to determine an insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent a rule for inserting the program code; according to the insertion strategy, the program code is inserted to insert the target probe at the insertion position; and the program code after insertion is output by calling a second interface, wherein the second interface includes a second parameter, and the parameter value of the second parameter includes the program code after insertion. Therefore, the embodiment of the present application adopts the method of calling the target interface to insert the target probe into the program code running by the operating system. In particular, it can determine the insertion position and insertion strategy in the program code, thereby achieving the purpose of automatically inserting the code into the application to support the execution flow tracking at the operating system level, thereby achieving the technical effect of improving the efficiency of code insertion in the application and facilitating the execution flow tracking of the application at the operating system level, and thus solving the technical problem of low efficiency of relying on manual code insertion into the application in the related technology.

[0226] It should be noted that the preferred implementation of the above steps S401 to S405 can be found in the above-mentioned related descriptions and will not be repeated here.

[0227] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0228] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0229] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0230] According to an embodiment of the present application, a device embodiment for implementing the above-mentioned application program instrumentation method is also provided. Figure 5 is a schematic diagram of the structure of an application program plugging device according to an embodiment of the present application, such as Figure 5 As shown, the device includes: a first determination module 501, which is used to determine the program code to be inserted from the application; a second determination module 502, which is used to call the target interface corresponding to the operating system, and determine the target probe configured for the program code, wherein the target probe is used to track the data generated by the application during the operation of the operating system; a third determination module 503, which is used to determine the insertion position in the program code using the target interface, and determine the insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent the rules for performing the insertion operation on the program code; and an insertion module 504, which is used to perform the insertion operation on the program code according to the insertion strategy, so as to insert the target probe at the insertion position.

[0231] Optionally, the third determination module 503 is further used to: determine an insertion position set using a target interface, wherein different program codes correspond to different insertion positions in the insertion position set; and determine the insertion position corresponding to the program code in the insertion position set using the target interface.

[0232] Optionally, the third determination module 503 is further used to: obtain configuration information of the target interface, wherein the configuration information is used to describe functions configured for the target interface, and the functions are associated with the instrumentation operation; and determine the instrumentation strategy from the configuration information.

[0233] Optionally, the third determination module 503 is also used to: in response to a policy selection operation, select a first instrumentation strategy or a second instrumentation strategy from the configuration information, wherein the first instrumentation strategy is used to represent the rules for performing instrumentation operations on the program code based on the log information of the application, and the second instrumentation strategy is used to represent the rules for performing instrumentation operations on the program code based on the target type program code, and the target type is a type other than the type of the program code.

[0234] Optionally, the target probe may be expressed in the form of: log information or probe function in a target format. The above-mentioned instrumentation module 504 is also used to: in response to the instrumentation strategy being a first instrumentation strategy, perform an instrumentation operation on the program code based on the log information of the application program to insert the log information in the target format at the instrumentation position; in response to the instrumentation strategy being a second instrumentation strategy, perform an instrumentation operation on the program code based on the target type program code to insert the probe function at the instrumentation position.

[0235] Optionally, in addition to all the above modules, the instrumentation device of the above application also includes: a tracing module (not shown in the figure), which is used to identify the virtual thread corresponding to the program code in response to the instrumentation strategy being the first instrumentation strategy, and obtain the identification information of the virtual thread; use the identification information and the target probe to track the virtual thread to obtain the tracing result of the virtual thread.

[0236] Optionally, in the instrumentation device of the above-mentioned application, the configuration information also includes at least one of the following: startup configuration information, used to indicate the function of starting the instrumentation operation; class configuration information, used to indicate the class on which the instrumentation operation is performed; location configuration information, used to indicate the instrumentation location corresponding to the instrumentation operation; strategy configuration information, used to indicate the instrumentation strategy corresponding to the instrumentation operation; identification configuration information, which is associated with the instrumentation location and is used to identify events that occur in the process of tracking the application data; behavior configuration information, used to indicate the operation behavior corresponding to the target probe.

[0237] Optionally, in addition to all the above modules, the plugging device of the above application also includes: an execution module (not shown in the figure), which is used to insert the target probe at the plugging position, and then use the target probe to execute the operation behavior corresponding to the behavior configuration information to track the data generated by the application at the code level and the data generated at the system level.

[0238] Optionally, the above-mentioned plugging module 504 is further used to: perform plugging operation on the program code in the running process according to the plugging strategy, so as to insert the target probe at the plugging position.

[0239] Optionally, the above-mentioned plugging module 504 is also used to: determine the target program code of the target probe; and according to the plugging strategy, call the bytecode modification tool to plug the program code in the running process to insert the target program code at the plugging position.

[0240] Optionally, the first determination module 501 is further used to: in response to the application running in the operating system, determine the program code to be inserted in the application based on a request message, wherein the request message is used to request information of the application and / or request the application to perform a task.

[0241] Optionally, the first determination module 501 is also used to: in response to the application running in the operating system, identify different types of request messages, wherein the different types of request messages are independent of each other; in response to different types of request messages, determine different program codes to be inserted in the application, wherein different program codes correspond to different types of request messages.

[0242] Optionally, in addition to all the above modules, the instrumentation device of the above application also includes: a processing module (not shown in the figure), which is used to delete the target probe in the application after instrumentation to obtain the application before instrumentation; perform deduplication operations on multiple target probes inserted at the instrumentation position; and record the call stack information of the application's thread during operation.

[0243] It should be noted here that the above-mentioned first determination module 501, second determination module 502, third determination module 503 and plug-in module 504 correspond to steps S201 to S204 in the embodiment, and the four modules have the same instances and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the aforementioned embodiments.

[0244] According to an embodiment of the present application, another device embodiment for implementing the above-mentioned instrumentation method for the application is also provided. Figure 6 is a schematic diagram of the structure of another application program plugging device according to an embodiment of the present application, such as Figure 6 As shown, the device includes: a first determination module 601, which is used to determine the program code to be inserted from the application program, wherein the program code is a code of an object-oriented programming language; a second determination module 602, which is used to call the application programming interface corresponding to the operating system, and determine the target probe configured for the program code, wherein the target probe is used to perform execution flow tracking on the data generated by the application program at the code level and the data generated at the system level during the operation of the operating system; a third determination module 603, which is used to determine the insertion position in the program code by using the application programming interface, and determine the insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent the rules for performing the insertion operation on the program code; an insertion module 604, which is used to perform the insertion operation on the program code according to the insertion strategy, so as to insert the target probe at the insertion position; a tracing module 605, which is used to perform execution flow tracing on the data generated by the application program at the code level and the data generated at the system level by using the target probe inserted at the insertion position, and obtain a tracing result.

[0245] It should be noted here that the above-mentioned first determination module 601, second determination module 602, third determination module 603, plugging module 604 and tracking module 605 correspond to steps S301 to S305 in the embodiment, and the five modules are the same as the instances and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the aforementioned embodiments.

[0246] According to an embodiment of the present application, another device embodiment for implementing the above-mentioned instrumentation method of the application is also provided. Figure 7 is a structural diagram of another application program plugging device according to an embodiment of the present application, such as Figure 7 As shown, the device includes: an acquisition module 701, which is used to acquire the program code to be inserted in the application by calling the first interface, wherein the first interface includes a first parameter, and the parameter value of the first parameter includes the program code; a first determination module 702, which is used to call the target interface corresponding to the operating system, and determine the target probe configured for the program code, wherein the target probe is used to track the data generated by the application during the operation of the operating system; a second determination module 703, which is used to determine the insertion position in the program code using the target interface, and determine the insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent the rules for performing the insertion operation on the program code; an insertion module 704, which is used to perform the insertion operation on the program code according to the insertion strategy, so as to insert the target probe at the insertion position; an output module 705, which is used to output the program code after the insertion by calling the second interface, wherein the second interface includes a second parameter, and the parameter value of the second parameter includes the program code after the insertion.

[0247] It should be noted here that the above-mentioned acquisition module 701, first determination module 702, second determination module 703, plug-in module 704 and output module 705 correspond to steps S401 to S405 in the embodiment, and the five modules are the same as the instances and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the aforementioned embodiments.

[0248] It should be noted that the above modules or units may be hardware components or software components stored in a memory and processed by one or more processors, and the above modules may also be run in a computer terminal as a part of the device.

[0249] It should be noted that the preferred implementation of this embodiment can refer to the relevant descriptions in the aforementioned embodiments, which will not be repeated here.

[0250] It should be noted that the preferred implementation scheme involved in the above embodiments of the present application is the same as the scheme provided in the above embodiments, as well as the application scenario and implementation process, but is not limited to the scheme provided in the above embodiments.

[0251] The embodiments of the present application may provide an instrumentation system for an application program. Figure 8 1 is a structural block diagram of an application program instrumentation system according to an embodiment of the present application. Figure 8 As shown, the application program instrumentation system includes: a client 801 and a server 802 .

[0252] The client 801 sends a request message, wherein the request message is used to request to obtain information of the application and / or request the application to perform a task;

[0253] Server 801 is used to determine the program code to be inserted in the application based on the request message; call the target interface corresponding to the operating system to determine the target probe configured for the program code, wherein the target probe is used to track the data generated by the application during the operation of the operating system; use the target interface to determine the insertion position in the program code, and determine the insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent the rules for inserting the program code; according to the insertion strategy, the program code is inserted to insert the target probe at the insertion position.

[0254] An embodiment of the present application may provide an electronic device, comprising: a memory storing an executable program; and a processor for running the program, wherein the plugging method of any one of the aforementioned application programs is executed when the program is running.

[0255] Fig. 9 is a structural block diagram of an electronic device according to an embodiment of the present application. Fig. 9 As shown, the electronic device 90 may include: one or more (only one is shown in the figure) processors 92, a memory 94, a storage controller, and a peripheral interface.

[0256] The above-mentioned electronic device can be understood as an integrated intelligent terminal, including but not limited to a server, a desktop computer, a personal computer (PC for short), a model all-in-one machine, etc., and the electronic device can be pre-installed with the above-mentioned model in the above-mentioned embodiment of the present application.

[0257] Specifically, the electronic device can pre-set multiple types of models, including but not limited to models in the fields of natural language processing, visual processing, speech processing, code processing, multimodal task processing, etc., so as to provide a variety of model choices. In different product forms, the electronic device can support one or more model usage methods, including but not limited to model training, model calling, model fine-tuning, model deployment, model reasoning and application, etc. In some product forms, the electronic device also supports model management, including but not limited to multi-type model management (supporting the management of multiple types of models such as discriminants and generative models), model version control (supporting the control of different model versions), model evaluation (based on model evaluation tools, evaluating the performance and effect of the model), etc. In other product forms, the electronic device can also create applications based on the model, provide application programming interface (Application Programming Interface, referred to as API) calling capabilities, and can call the model to the created application through the API interface, while providing application management tools to achieve management and monitoring of the application.

[0258] Furthermore, the electronic device may also include data management (supporting the creation and management of model tuning data sets), a training center (providing rich training resources to help users learn and master artificial intelligence (AI) technology), and basic management and control capabilities (providing enterprise-level basic management and control capabilities to ensure the security and efficient operation of the system). Through the above functions, a comprehensive, integrated AI development, training, deployment and application device is provided.

[0259] Among them, the memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the plugging method and device of the application in the embodiment of the present application, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, the plugging method of the application in the above embodiment is realized. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the terminal A via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0260] The processor may call the executable program stored in the memory through the transmission device to execute the plugging method of the application program in any one of the above embodiments.

[0261] Those skilled in the art will understand that Fig. 9 The structure shown is for illustration only, and the electronic device may also be a terminal device such as a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, and a mobile Internet device (Mobile Internet Devices, MID for short). Fig. 9 The structure of the electronic device is not limited. For example, the electronic device 90 may also include Fig. 9 More or fewer components (such as network interfaces, display devices, etc.) shown in, or with Fig. 9 Different configurations are shown.

[0262] A person skilled in the art can understand that all or part of the steps in the plugging method of various application programs in the above-mentioned embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0263] The embodiment of the present application further provides a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium includes a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute any of the aforementioned application program instrumentation methods.

[0264] Optionally, in this embodiment, the above storage medium may be located in an electronic device.

[0265] Optionally, in this embodiment, the computer-readable storage medium is configured to store an executable program, and when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the plugging method of the application program in any one of the above embodiments.

[0266] The embodiment of the present application further provides a computer program product. Optionally, in this embodiment, the computer program product may include a computer program, and when the computer program is executed by a processor, the application program instrumentation method provided in the embodiment is implemented.

[0267] The embodiments of the present application also provide a computer program product. Optionally, the computer program product may include a non-volatile computer-readable storage medium, which may be used to store a computer program, and when the computer program is executed by a processor, the plugging method of the application provided in the embodiments is implemented.

[0268] The embodiment of the present application further provides a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, the method for inserting an application program provided in the embodiment above is implemented.

[0269] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0270] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the above-mentioned units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0271] The units described above as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0272] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0273] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the plugging method of the above-mentioned application program in each embodiment of the present application. The aforementioned storage medium includes: U disk, ROM, RAM, mobile hard disk, disk or CD-ROM and other media that can store program code.

[0274] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.< / pid> < / jdk> < / pid> < / jdk> < / pid> < / jdk> < / pid> < / jdk>

Claims

1. A method for instrumenting an application, characterized in that: include: Determine the program code to be instrumented from the application program; Calling a target interface corresponding to the operating system to determine a target probe configured for the program code, wherein the target probe is used to track data generated by the application during the operation of the operating system; Determine the insertion position in the program code by using the target interface, and determine the insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent the rules for performing the insertion operation on the program code; According to the plugging strategy, the program code is plugged in to insert the target probe at the plugging position.

2. The method according to claim 1, characterized in that Determining the insertion position in the program code by using the target interface includes: Determine a plug position set by using the target interface, wherein different program codes correspond to different plug positions in the plug position set; The target interface is used to determine the insertion position corresponding to the program code in the insertion position set.

3. The method according to claim 1, characterized in that The method further comprises: Acquire configuration information of the target interface, wherein the configuration information is used to describe a function configured for the target interface, and the function is associated with the instrumentation operation; Determining the instrumentation strategy corresponding to the target probe includes: The instrumentation strategy is determined from the configuration information.

4. The method according to claim 3, characterized in that Determining the instrumentation strategy from the configuration information includes: In response to a policy selection operation, a first instrumentation policy or a second instrumentation policy is selected from the configuration information, wherein the first instrumentation policy is used to represent rules for performing instrumentation operations on the program code based on log information of the application, and the second instrumentation policy is used to represent rules for performing instrumentation operations on the program code based on a target type program code, wherein the target type is a type other than the type of the program code.

5. The method according to claim 4, characterized in that The target probe may be in the form of log information or a probe function in a target format. According to the plugging strategy, the program code may be plugged in to insert the target probe at the plugging position, including: In response to the instrumentation strategy being the first instrumentation strategy, performing an instrumentation operation on the program code based on the log information of the application program, so as to insert the log information in the target format at the instrumentation position; In response to the instrumentation strategy being the second instrumentation strategy, an instrumentation operation is performed on the program code based on the target type program code to insert the probe function at the instrumentation position.

6. The method according to claim 4, characterized in that The method further comprises: In response to the instrumentation strategy being the first instrumentation strategy, identifying a virtual thread corresponding to the program code, and obtaining identification information of the virtual thread; The virtual thread is traced by using the identification information and the target probe to obtain a trace result of the virtual thread.

7. The method according to claim 3, characterized in that The configuration information also includes at least one of the following: Startup configuration information, used to indicate the function of starting the instrumentation operation; Class configuration information, used to indicate the class on which the instrumentation operation is performed; Position configuration information, used to indicate the insertion position corresponding to the insertion operation; Strategy configuration information, used to indicate the instrumentation strategy corresponding to the instrumentation operation; Identification configuration information, associated with the instrumentation location and used to identify events that occur during the process of tracking data of the application; The behavior configuration information is used to indicate the operation behavior corresponding to the target probe.

8. The method according to claim 7, characterized in that After inserting the target probe at the insertion position, the method further includes: The target probe is used to execute the operation behavior corresponding to the behavior configuration information, so as to track and obtain the data generated by the application at the code level and the data generated at the system level.

9. The method according to claim 1, characterized in that: According to the plugging strategy, the program code is plugged in to insert the target probe at the plugging position, including: According to the plugging strategy, the program code in the running process is plugged, so as to insert the target probe at the plugging position.

10. The method according to claim 9, characterized in that According to the plugging strategy, the program code in the running process is plugged to insert the target probe at the plugging position, including: Determining a target program code of the target probe; According to the plugging strategy, a bytecode modification tool is called to plug the program code in the running process, so as to insert the target program code at the plugging position.

11. The method according to claim 1, characterized in that: Determine the program code to be instrumented from the application, including: In response to the application being run in the operating system, the program code to be inserted in the application is determined based on a request message, wherein the request message is used to request to obtain information of the application and / or request the application to perform a task.

12. The method according to claim 11, characterized in that In response to the application being run in the operating system, determining the program code to be inserted in the application based on the request message includes: In response to the application being run in the operating system, identifying different types of request messages, wherein the different types of request messages are independent of each other; In response to the different types of request messages, different program codes to be inserted in the application are determined, wherein the different program codes correspond to the different types of request messages.

13. The method according to any one of claims 1 to 12, characterized in that After inserting the target probe at the insertion position, the method further includes at least one of the following: In the application after the instrumentation, deleting the target probe to obtain the application before the instrumentation; performing a deduplication operation on the plurality of target probes inserted at the insertion position; Record the call stack information of the application program's thread during operation.

14. A method for tracking an application, characterized in that: Used in tracking tools, including: Determine a program code to be inserted from the application program, wherein the program code is a code of an object-oriented programming language; Calling an application programming interface corresponding to the operating system to determine a target probe configured for the program code, wherein the target probe is used to perform execution flow tracking on data generated by the application at the code level and data generated at the system level during the running of the operating system; Determine the insertion position in the program code by using the application programming interface, and determine the insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent the rules for performing the insertion operation on the program code; According to the plugging strategy, the program code is plugged to insert the target probe at the plugging position; The target probe inserted at the insertion position is used to perform execution flow tracing on the data generated by the application at the code level and the data generated at the system level to obtain a tracing result.

15. A method for inserting an application, characterized in that: include: Acquire the program code to be inserted in the application program by calling a first interface, wherein the first interface includes a first parameter, and a parameter value of the first parameter includes the program code; Calling a target interface corresponding to the operating system to determine a target probe configured for the program code, wherein the target probe is used to track data generated by the application during the operation of the operating system; Determine the insertion position in the program code by using the target interface, and determine the insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent the rules for performing the insertion operation on the program code; According to the plugging strategy, the program code is plugged to insert the target probe at the plugging position; The program code after the instrumentation is output by calling a second interface, wherein the second interface includes a second parameter, and a parameter value of the second parameter includes the program code after the instrumentation.

16. An application instrumentation system, characterized in that: include: The client sends a request message, wherein the request message is used to request to obtain information of the application and / or request the application to perform a task; The server is used to determine the program code to be inserted in the application based on the request message; call the target interface corresponding to the operating system to determine the target probe configured for the program code, wherein the target probe is used to track the data generated by the application during the operation of the operating system; use the target interface to determine the insertion position in the program code, and determine the insertion strategy corresponding to the target probe, wherein the insertion strategy is used to represent the rules for performing the insertion operation on the program code; according to the insertion strategy, the program code is inserted to insert the target probe at the insertion position.

17. An electronic device, characterized in that: include: A memory storing an executable program; A processor, configured to run the program, wherein the program executes the method according to any one of claims 1 to 15 when running.

18. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored executable program, wherein when the executable program is run, the device where the storage medium is located is controlled to execute the method according to any one of claims 1 to 15.

19. A computer program product, characterized in that It comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 15.

Images