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

Abstract

The present application discloses a method, system, electronic device, storage medium and computer program product for inserting an application, and relates to the field of application technology. The method comprises: determining the program code to be inserted from the application; calling 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; 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 inserting the program code; according to the insertion strategy, the program code is inserted to insert the target probe at the insertion position. The present application solves the technical problem of low efficiency in the related art of relying on manual code insertion into the application.

Description

Technical Field

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

[0002] In the field of application technology, performance profiling techniques are primarily relied upon to locate performance issues in code. However, for some application scenarios, such as HTTP servers in Java environments, web servers, microservices, databases, and high-concurrency scenarios, there is a deeper need for execution flow tracing, namely tracking the time taken for each step of request execution and analyzing the percentile distribution of latency in order to improve user experience and system stability. In related technologies, tools based on the aforementioned performance profiling techniques are unable to automatically instrument application code. Programmers are still required to manually insert code, rebuild the project, and rerun the program to instrument the application. As a result, related technologies struggle to support application execution flow tracing, and application instrumentation efficiency is low.

[0003] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0004] The embodiments of the present application provide an application program insertion method, system, electronic device, storage medium, and computer program product to at least solve the technical problem in the related art of relying on manual code insertion into the application program, which is inefficient.

[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 performing an insertion operation on the program code; and performing an insertion operation on the program code according to the insertion strategy 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, including: determining program code to be inserted from the application, wherein the program code is code in 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 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 rules 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 the 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 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; outputting the program code after insertion 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.

[0008] According to another aspect of an embodiment of the present application, a system for inserting an application is also provided, 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 inserted in the application based on the request message; calling the target interface corresponding to the operating system, and determining 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; 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 inserting the program code; according to the insertion strategy, the program code is inserted to insert the target probe at the insertion position.

[0009] According to another aspect of an embodiment of the present application, an electronic device is 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 further provided, including a computer program, which implements any of the above methods when executed by a processor.

[0012] In an embodiment of the present application, the program code to be inserted 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 insertion position in the program code, and the insertion strategy corresponding to the target probe is determined, wherein the insertion strategy is used to represent the rules for performing insertion operations on the program code; according to the insertion strategy, the program code is inserted to insert the target probe at the insertion 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. 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 tracing 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 tracing of the application at the operating system level, thereby solving the technical problem of low efficiency of relying on manual code insertion into the application in the related technology.

[0013] It is easy to notice that the above general description and the following detailed description are merely 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 an application program instrumentation method is shown;

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

[0017] Figure 3 is a flowchart of another application instrumentation method according to an embodiment of the present application;

[0018] Figure 4 is a flowchart of another application instrumentation method according to an embodiment of the present application;

[0019] Figure 5 is a structural diagram of an instrumentation device for an application according to an embodiment of the present application;

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

[0021] Figure 7 is a structural 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] Figure 9 This 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 present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this 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 sequential order. 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 a sequence 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 that plays an important role in the development of enterprise applications, web services, and mobile applications due to its cross-platform capabilities and wide application.

[0028] JVM (Java Virtual Machine) is a virtual machine that runs Java bytecodes and is responsible for executing and managing Java programs.

[0029] JDK (Java Development Kit) is a toolkit used to develop Java programs. It includes JVM, Java class libraries, and other development tools. It is the basic environment for Java development.

[0030] Dynamic instrumentation is a technology that modifies the behavior of an application while it's running. Specifically, dynamic instrumentation involves inserting new code snippets at specific locations to monitor, analyze, or modify runtime behavior. Dynamic instrumentation is particularly useful for performance tuning, logging, and code debugging. Dynamic instrumentation takes effect without requiring an application restart, offering increased flexibility.

[0031] Execution Trace: A detailed record of an application's execution process. By tracking function calls, thread states, and events, it helps developers gain a deeper understanding of application behavior, performance issues, and potential errors. Execution Trace is a crucial tool for performance analysis and debugging.

[0032] Request: In the client-server model, a client sends an action or data request to the server to obtain information or perform a specific task. Requests are the fundamental unit of interaction in network communications. Request response time and processing efficiency directly impact the user experience.

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

[0034] The execution path describes the sequence and dependencies between function calls, thread activities, and event triggers in an application's execution flow. This helps analyze the program's logical execution path and performance issues.

[0035] Percentile Time: In a set of time data, the time value at a specific percentile reflects the ranking of that set of time data in the dataset. 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 that is widely used in servers, embedded systems and personal computers. It has high customizability, stability and community support.

[0038] User Space Probe (Uprobe): 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 a library file format that can be shared by multiple programs in a Linux environment. It usually contains pre-compiled code and data, which helps save memory and improve interoperability between programs.

[0040] Native files are programs or library files written in native programming languages ​​(such as C / C++). They are often used to encapsulate low-level operations or high-performance computing. In particular, Java Native Interface (JNI) methods are often stored in native files.

[0041] A Java class is a unit used to organize and encapsulate data and functionality. A Java method is a piece of code defined within a Java class that performs a specific task. Calling a Java method activates the corresponding Java class's functionality.

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

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

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

[0045] Spikes: These are sudden performance degradations or delays in an application. Spikes are often caused by transient high loads, resource contention, or system bottlenecks, impacting 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 dynamic content generation, static file serving, and other functions. 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 a clear API, which improves the scalability and independent deployment capabilities of the system.

[0049] Java backend: A server-side application developed in Java that handles business logic, data management, and interaction with the frontend. It is a crucial component of web application architecture.

[0050] A stack trace is a record of the current call sequence of a thread during program execution. A stack trace includes a series of method calls and execution points, and can be used for debugging and performance analysis to help identify error sources and execution paths.

[0051] A Java agent is a special type of Java program that can be attached to the JVM at application startup or runtime to monitor, modify, or enhance a running Java application. Java agents are 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 nature of dynamic compilation, the address layout of the program may change each time it is run, 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 runtime data, 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: Logging waits for log writing to complete in the main program flow. Asynchronous Logging: Logging operations are separated into background threads for execution, reducing the blocking time of the main program.

[0056] According to an embodiment of the present application, an embodiment of a method for inserting 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 an application program instrumentation method is shown. Figure 1As shown, the computer terminal 10 (or mobile device 10) may include one or more processors 102 (illustrated as 102a, 102b, ..., 102n in the figure) (the processor 102 may include, but is not limited to, a processing device such as a 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, 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 than 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 circuitry." This data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be fully or partially integrated into any of the other components of the computer terminal 10 (or mobile device). As discussed in the embodiments of this application, this data processing circuitry functions as a processor control (e.g., selecting 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 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, implementing the plugging method of the above-mentioned application. 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 located 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] Transmission device 106 is configured to connect to a network via a network interface to receive or transmit data. Specific examples of the aforementioned network may include a wired and / or wireless network provided by the communications provider of computer terminal 10. In one embodiment, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 106 may be a radio frequency (RF) module configured 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 enables 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. 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 aforementioned 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 Flowchart of the 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 aforementioned applications may include, but are not limited to, Java programs, enterprise applications, mobile applications, and Java server-side applications. When the application is running in the operating system, the program code to be instrumented can be determined from the application. This program code can be a Java method within the Java program. In other words, the program code can be instrumented while the application is running. This instrumentation process is dynamic instrumentation, enabling 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 inserted in the application is determined. Based on this, the dynamic nature of the application insertion solution is achieved, which means that the specific Java method that needs to be inserted 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 static code analysis, tools or plug-ins can be used to conduct 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. Known performance analysis knowledge bases or models can be used to predict which code paths may experience resource contention, deadlocks, long-tail delays, and other problems under high concurrency or specific loads. Historical performance data can also be analyzed to identify methods and classes that are frequently executed or consume more resources, thereby determining candidate objects for instrumentation.

[0070] For example, during dynamic runtime monitoring, runtime performance monitoring tools (such as JavaVisualVM, JProfiler, and Visual GC) can be used to collect application runtime data under real or simulated loads, including CPU usage, memory consumption, thread status, and response time. Further analysis of this data can identify code segments that consume the most resources, have the longest response times, or exhibit abnormal behavior during actual execution. Furthermore, hotspot analysis can be used to automatically identify the most frequently accessed and time-consuming code paths during application execution, which serve as key targets for dynamic instrumentation.

[0071] For another example, in the process of determining the program code to be instrumented from the application, a comprehensive strategy that combines 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 hotspots or cause performance issues. 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 feedback to the analysis engine. Based on this, the analysis engine combines the information obtained from static analysis to intelligently identify the exact code segments. These code segments can be regarded as the root causes of performance problems revealed in dynamic monitoring. As a result, the instrumentation strategy can be dynamically adjusted to make the instrumentation strategy more closely aligned with 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 instrumented based on their own insights into business processes or considerations of specific performance issues.

[0073] It should be noted that, to further enhance the comprehensiveness and depth of instrumentation, embodiments of this application can also incorporate system-level tracing technology to dynamically track interactions between applications and the operating system (such as system calls, context switches, and input / output operations). Furthermore, to further enhance the instrumentation capabilities of virtual threads, detailed analysis of virtual thread creation and scheduling patterns can be performed to precisely locate code paths responsible for critical tasks in high-concurrency scenarios. Instrumentation can then be set for these code paths to achieve refined monitoring of virtual thread activity and resource allocation.

[0074] It should be noted that embodiments 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 a long blockage or unexpected resource usage, the instrumentation strategy can be dynamically adjusted to quickly locate the problematic code, greatly shortening the fault location time and improving the stability and responsiveness of the system.

[0075] As can be seen from the above, determining the program code to be instrumented mainly relies on an in-depth understanding and analysis of the application, combined with static code review and dynamic runtime monitoring, to identify those code locations that are critical for performance optimization. Such an intelligent instrumentation strategy can effectively reduce unnecessary monitoring overhead and concentrate 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 modified at runtime, providing a wide range of applications for subsequent instrumentation operations.

[0076] Step S202 : 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.

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

[0078] Specifically, the target interface can be a system-level interface such as a Linux uprobe. This interface enables the dynamic insertion of tracepoints into user-space programs. Target probes are configured as observation points associated with specific Java methods. These probes can collect detailed runtime information about the program, including but not limited to CPU usage, context switches, and I / O operations.

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

[0080] Based on the definition of the target probe, the instrumentation strategy corresponding to the target probe can be determined. Specifically, in the application scenario, different instrumentation strategies correspond to different pre-defined probes. Based on this correspondence and the target probe determined by calling the target interface, the instrumentation strategy can be determined. For example, the instrumentation strategies mentioned above may include log-based (Bwlog) instrumentation and JNI instrumentation.

[0081] Bwlog instrumentation is a log-based instrumentation technology that outputs logs in a specific format at specified code locations. These logs can then be parsed by trace tools to restore the Java execution flow. The advantage of Bwlog instrumentation lies in its flexible implementation. For example, it can use buffer-based synchronous logging (which minimizes execution overhead). Furthermore, Bwlog instrumentation provides richer information (such as supporting virtual thread identification). However, due to the involvement of file I / O operations, Bwlog instrumentation generally has a higher performance overhead than JNI instrumentation.

[0082] JNI instrumentation is a JNI-based instrumentation technology that inserts calls to specific JNI methods (also known as probes) into the target code. JNI instrumentation is primarily designed to accommodate tools that only support SO probes (such as Linuxuprobe). However, JNI instrumentation is limited in that it only identifies the caller's platform thread and cannot accurately track virtual threads. However, JNI instrumentation offers advantages in terms of higher execution efficiency and reduced I / O overhead.

[0083] In application scenarios, instrumentation locations can be selected based on user configuration. For example, these locations can include method entry (call) and / or return (ret) locations. The instrumentation strategy determines how to insert probes, such as using logs or JNI calls. The choice of instrumentation strategy directly impacts the type of data 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 to insert a target probe at the instrumentation position.

[0085] Furthermore, in application scenarios, the program code is instrumented according to the instrumentation strategy using the JVM's instrumentation API. Specifically, bytecode modification tools (such as Javassist or Byte Buddy) are used to add target probe code at the instrumentation location to ensure that the target probe is 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 insertion of the program code to be inserted (such as any Java method) in the application (such as a Java program) without restarting the application during its operation, and by docking with the system-level trace tool, it provides tracking of the program code call link, and can also collect key performance indicators at the operating system level, such as multi-threaded competition and I / O delay. In addition, the above solution provided by the embodiment of the present application also supports insertion recovery and re-enabling, which is convenient for quickly locating and analyzing the performance problems of the application in an online environment. By flexibly configuring the probe type and the insertion strategy, it not only ensures the low intrusiveness of the insertion, but also achieves a comprehensive insight into the execution overhead, greatly enhancing 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 inserted 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 insertion position in the program code, and the insertion strategy corresponding to the target probe is determined, wherein the insertion strategy is used to represent the rules for performing insertion operations on the program code; according to the insertion strategy, the program code is inserted to insert the target probe at the insertion 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. 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 tracing 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 tracing 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 insertion 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 location 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 aforementioned optional embodiment, the target interface can support different program codes. During multiple calls to the target interface, different insertion locations can be determined based on the different program codes. For example, the target interface supports any Java class and Java method, and insertion locations can be specified multiple times. Each time an insertion is performed, the specific operation or action to be performed at the corresponding insertion location can be freely selected. 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 functionality 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 instrumentation. The instrumentation location set refers to a series of code locations that can be selected for instrumentation. These locations can be the entry point (call) of any method in any class in a Java program, the return point (ret) of any method, or the entire 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 segment they want to monitor or analyze according to their 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 and determine the instrumentation location set. These configuration parameters include, but are not limited to, the class and method names to be instrumented, the instrumentation method (Bwlog instrumentation or JNI instrumentation), the event name (event), the timed action (action), and the distinguishing mark (tag). Using these configuration parameters, the code segments to be monitored are identified and their specific locations within the Java program are determined, thereby determining the instrumentation location set.

[0095] Furthermore, the target interface is used to determine the corresponding instrumentation locations in the program code within the instrumentation location set. Based on the instrumentation location set, the instrumentation locations are precisely targeted to each specific method or code segment that requires monitoring. To determine the corresponding instrumentation locations for the program code, the Java bytecode is read and modified. Using the Instrumentation API, the system can inject specific code or calls into the designated instrumentation locations to monitor program behavior.

[0096] Through steps S231 to S232, the present embodiment of the present invention implements a precise and flexible dynamic application instrumentation mechanism. Users can select any program code (e.g., Java method) for instrumentation based on their specific needs, while also controlling the instrumentation depth (e.g., call, ret, or full) and the instrumentation method (e.g., Bwlog instrumentation or JNI instrumentation).

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

[0098] Step S233: acquiring 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: Determine 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 an application scenario, the target interface can be an interface provided by the operating system for dynamically inserting trace points, such as Linux's uprobe. Configuration information can include an instruction set for the instrumentation operation, such as which specific Java method the user wishes to instrument, whether the user wishes to implement instrumentation through logging (log) or JNI calls (type), and whether the user wishes to mark specific events (events), and the marking (action can be start, end, or mark). Based on this, users can flexibly determine configuration information based on their needs, thereby controlling the instrumentation strategy. In other words, the optional embodiments described above can enhance the targeted nature of instrumentation, reduce unnecessary performance losses, and improve the accuracy and practicality of Java program execution flow tracing.

[0103] Furthermore, an instrumentation strategy is determined from the configuration information. The instrumentation strategy is formulated based on the configuration information and specifically directs the bytecode modification tool on how to add additional code to Java methods to achieve the user-specified instrumentation method and purpose. Based on this, embodiments of the present application can support users in dynamically adjusting instrumentation behavior. Even while a program is running, the instrumentation strategy can be instantly changed based on new configuration information, without having to restart the application (e.g., a 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, allowing users to 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 positioning 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 policy selection operation, select the first instrumentation policy or the second instrumentation policy from the configuration information, wherein the first instrumentation policy 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 policy is used to represent the rules for performing instrumentation operations on the program code based on the target type program code, where 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 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 log in a specific format at a specified code location. It 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 additional log recording code will be added to the program code using the Java logging framework, thereby recording relevant information before and after the Java method call, making it easier to understand the details of the execution flow by analyzing the log later.

[0108] The second instrumentation strategy described above represents the rules for instrumenting program code based on the target type of the program code, where the target type is a type other than the program code type. The second instrumentation strategy, known as the JNI instrumentation strategy, implements instrumentation by calling JNI methods. This instrumentation approach is primarily 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 operating system-level trace tools, thereby obtaining lower-level performance data (such as kernel event overhead). Selecting the second instrumentation strategy means adding calls to specific JNI functions defined in local files (such as librtinstr.so) to the program code. These JNI functions act as target probes, triggered by operating system-level trace tools, and record system-level information related to Java method execution.

[0109] Through the above-mentioned step S235, the embodiment of the present application realizes a dynamic policy selection mechanism, which allows 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, which facilitates understanding the execution path and time distribution of the application, while the JNI-based instrumentation strategy provides strong support for scenarios that need to obtain operating system-level performance indicators. The combination of the log-based instrumentation strategy and 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, and 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, an instrumentation operation is performed on the program code according to the instrumentation strategy to insert the target probe at the instrumentation 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 log information in a 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 represented as log information in the target format. That is, the target probe corresponding to the Bwlog instrumentation strategy is log output in a specific format. When the instrumentation strategy is the second instrumentation strategy, the target probe is represented 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 program's behavior, call sequence and resource consumption 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 employing the first instrumentation strategy (i.e., the Bwlog instrumentation strategy), specially formatted log statements are precisely inserted at selected locations within the code, based on the target application's existing logging framework and information. This involves specifying parameters such as the class name to be instrumented, the method name, the instrumentation location (e.g., method entry or exit point), the event type, and the desired log format (e.g., including elements such as timestamp, thread ID, and event name) through a command-line tool. After receiving these parameters, the command-line tool leverages the instrumentation API and bytecode manipulation techniques to dynamically modify the bytecode of the running application, inserting formatted log output code at the specified code location. Consequently, whenever the target method is called or returns, the application automatically outputs log information in the pre-set format, recording execution flow details and key performance indicators, providing a comprehensive data foundation for subsequent performance analysis and problem location.

[0116] According to step S241, the application's log information 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 and virtual thread identification. Although this instrumentation method may have a relatively high performance overhead, due to the use of a synchronous log output method with a buffer, the impact on program execution is minimized while ensuring information integrity. The solution in which the instrumentation strategy is set to the first instrumentation strategy is particularly suitable for scenarios that require a detailed understanding of the execution path and time decomposition.

[0117] When the instrumentation strategy is set to the second instrumentation strategy, an instrumentation operation is performed on the program code based on the target type program code to insert a probe function at the instrumentation position.

[0118] Specifically, when the second instrumentation strategy (i.e., JNI instrumentation strategy) is selected, the system inserts JNI function calls as probes at the entry or exit of the specified Java method. This operation is based on the target Java code and is implemented by dynamically modifying the bytecode, without the need to recompile or restart the application. The probe function is located in the supporting native library and can work 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 needs of high-performance, 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 in the Java program, the embodiment 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 Java method calls, as well as the corresponding event tracking. The advantage of the above-mentioned instrumentation method in which the instrumentation strategy is set to the second instrumentation strategy is low intrusion 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 tracing 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 connecting 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, 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 steps:

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

[0123] Step S252 : Using the identification information and the target probe, the virtual thread is traced 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 identification information of the corresponding virtual thread is output in the log.

[0125] In Java applications, virtual threads are a new threading model introduced by Java. They enable multiple tasks to be executed concurrently within the same operating system thread, improving concurrency and reducing thread switching overhead. In Java applications, virtual threads are identified by a thread ID and other metadata, which can be used to track the execution flow of the virtual thread.

[0126] Specifically, the aforementioned identification information can also specifically refer to data that uniquely identifies a virtual thread, including but not limited to the virtual thread's thread ID, thread group information, and priority. This identification information is used in dynamic instrumentation to ensure that the instrumented code is accurately associated with the correct virtual thread, thereby collecting execution flow data related to that virtual thread. The instrumented code mentioned above refers to the code snippet dynamically inserted into a Java method to collect execution flow data.

[0127] The trace results described above are detailed data collected through instrumentation and tracing of virtual threads, reflecting the execution flow of the virtual threads. These data may include CPU usage time, I / O wait time, context switch time, call stack information, and more. These trace results provide critical information for evaluating and optimizing virtual thread performance.

[0128] In Java applications, based on step S251 above, specific code (i.e., a target probe) is dynamically inserted into a specified Java method to capture identification information when a virtual thread enters or exits a Java method. The system must understand the Java virtual machine's internal thread model to accurately identify and tag virtual threads during dynamic instrumentation.

[0129] Furthermore, the virtual thread is tracked using identification information and target probes to obtain the tracing results of the virtual thread. After obtaining the identification information of the virtual thread, the system can use this identification information and the previously set target probes 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 this 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 insertion and tracking of virtual threads while 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 solution, 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 tracking of 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 during program runtime.

[0139] For example, the user can use the command <jdk> / bin / java -jar rtinstr.jar <pid><MyClass.myMethod>Start the instrumentation, here <jdk> 、 <pid>as well as<MyClass.myMethod> Therefore, the embodiment of the present application supports dynamic loading of instrumentation without restarting the application, thereby improving the efficiency and convenience of online debugging.

[0140] The class configuration information is used to indicate the class where the instrumentation operation is performed, that is, the name of the Java class that the user wishes to instrument. By specifying the class configuration information, embodiments of the present application can precisely instrument the class of interest without affecting other parts of the program, providing application developers with a high degree of focus and control.

[0141] The above location configuration information indicates the corresponding instrumentation location for the instrumentation operation, that is, the stage of the Java method call at which the probe is inserted. This can be the Java method entry (call), Java method exit (ret), or the entire Java method flow (full). The location configuration information ensures the accuracy and depth of instrumentation, allowing users to select the most appropriate monitoring point based on their needs to obtain the desired data type and coverage.

[0142] The above policy configuration information is used to represent the instrumentation strategy corresponding to the instrumentation operation, that is, the specific implementation method of instrumentation, such as log information-based (Bwlog instrumentation strategy) or JNI call-based (JNI instrumentation strategy). Each instrumentation strategy has unique advantages and applicable scenarios. The policy configuration information allows users to balance low overhead and high information quality, improving the usability of tracing data.

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

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

[0145] In an exemplary application scenario, an API function definition corresponding to an instrumentation tool can be provided based on the instrumentation method of the above application. This API can be called to implement flexible Java method-level instrumentation and support fine-grained runtime tracing through configuration instructions. The calling 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 the 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 optional insertion locations are 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: Use the event parameter to name the insertion point to facilitate subsequent data aggregation analysis; support the acquisition of percentile statistics.

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

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

[0159] Based on the above API, we connect to system-level tracing tools through Linux uprobe, achieving a complete monitoring chain 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-mentioned configuration information, the embodiment of the present application realizes dynamic instrumentation of highly customized applications. Users can flexibly specify the start-up conditions, target classes, instrumentation locations, instrumentation strategies, and identification and behavior definitions of tracing events. The above-mentioned 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 the 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-mentioned 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 detailed manner. In particular, the above-mentioned 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, executing the operation behavior corresponding to the behavior configuration information to track and obtain the data generated by the application at the code level and the data generated at the system level.

[0163] These target probes are code snippets or function calls inserted at designated instrumentation locations to capture critical information during program execution. Target probes can be log messages in a specific format or probe functions, depending on the instrumentation strategy. In Java applications, target probes are designed to work in conjunction with system-level tracing tools (such as Linux uprobe) to trace the execution flow of Java programs.

[0164] This behavior configuration information can refer to an instrumentation strategy. It includes the instrumentation location (call, ret, or full), instrumentation method (log or JNI), event name (event), timing action (action), and distinguishing flags (tag). In Java application scenarios, this behavior configuration information constitutes the instruction set for executing the target probe, determining when the probe is triggered (start, end, or mark) during Java method execution, and how the collected data is identified and categorized.

[0165] These operational behaviors refer to specific actions performed by the target probe during program execution based on the behavioral configuration information. For example, when using the Bwlog instrumentation strategy, the target probe logs the start and end points of method calls, providing detailed timing information and call stack information for Java method calls. When using the JNI call instrumentation strategy, the target probe calls JNI functions predefined in local files (such as librtinstr.so). These JNI functions act as probes, collaborating with system-level trace tools to capture lower-level performance data.

[0166] Using target probes to execute the operations corresponding to the behavior configuration information, the resulting trace data can include two levels of data: code-level execution flow data, including method call times, call order, and call relationships; and system-level performance data, covering operating system-level events such as context switches and I / O operation overhead. This trace data, obtained by executing the operations configured by the target probes, provides 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 tracing of application execution, while taking into account data collection at the code level and the system level. This tracing 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 tracing 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 instrumentation and tracing 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 instrumentation strategy, the program code is instrumented to insert a target probe at the instrumentation position, including the following method steps:

[0169] Step S243 : performing an instrumentation operation on the program code in the running process according to the instrumentation strategy, so as to insert a target probe at the instrumentation 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 Java application scenarios, when instrumentation is performed according to the instrumentation strategy, the system will insert probes in real time at designated program code locations based on 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. This log information will record the start, end, and mark points of method calls, providing a detailed execution flow trace. 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 timing and events of method calls.

[0172] It should be noted that the key point of dynamic instrumentation technology is to perform instrumentation operations on program code during operation. Traditional instrumentation methods usually require the application to be recompiled and redeployed after being modified, while the embodiments of the present application can dynamically modify the bytecode while the application is running without restarting the process. Based on this, application developers or operation and maintenance personnel can adjust and enable instrumentation strategies in real time without affecting application services, and monitor and analyze performance issues 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, providing strong support for tracking request delays, analyzing multi-threaded competition and I / O delays, etc. In other words, the above step S243 directly provides a means of real-time performance monitoring and analysis for the application without going through the 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 instrumentation strategy, the program code in the running process is instrumented to insert the target probe at the instrumentation position, including the following method steps:

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

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

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

[0178] When the Bwlog instrumentation strategy, which instruments based on log information, is selected, the target program code is the code snippet that generates log information in the target format at the specified location. When the JNI instrumentation strategy, which instruments based on JNI calls, is selected, the target program code is the code snippet that calls JNI functions predefined in local files (such as librtinstr.so). The target program code is selected and inserted dynamically based on the user-specified instrumentation strategy, ensuring flexibility and low-intrusiveness of the instrumentation operation.

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

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

[0181] According to step S244, the process of determining the target program code of the target probe is to parse the specific locations of the Java classes and Java methods that need to be instrumented based on the configuration information provided by the user through the target interface. The system will determine the type of target program code to be inserted based on different instrumentation strategies.

[0182] In step S245, according to the instrumentation strategy, the bytecode modification tool is invoked to instrument the running program code, inserting the target program code at the instrumentation location. This process involves reading the Java class bytecode at runtime, dynamically modifying the bytecode according to the instrumentation 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 tracing code into the program code of the application. This not only reduces the cost of online problem locating, but also allows for a detailed analysis of the execution flow, especially when dealing with complex multi-threaded and microservice scenarios. It can more accurately understand the execution overhead and performance bottlenecks of the request, and improve the stability of the application and user experience. 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, thereby improving the practicality and flexibility of the solution.

[0184] In an optional embodiment, in step S201, determining the program code to be instrumented 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 a request message, wherein the request message is used to request obtaining application information and / or requesting 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> This is the portion of the request message that specifies the program code to be instrumented. The format and content of the request message vary depending on the specific application scenario and tool design. The request message serves as the trigger condition and configuration basis for dynamic instrumentation operations.

[0187] The program code to be instrumented in the application is determined based on the information contained in the request message. Specifically, this program code refers to the Java class and Java method in which the user wishes to insert the probe or tracing code. The flexibility of dynamic instrumentation technology lies in the fact that users can specify the instrumentation location within any Java method. This means that regardless of the call frequency or complexity of a Java method, the user can specify the instrumentation location for that Java method through a request message, enabling real-time monitoring and analysis of that Java method.

[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, thereby improving the efficiency of performance monitoring and problem location in the online environment.

[0189] Through the above-mentioned step S211, the embodiment of the present application dynamically determines and inserts the program code to be monitored (such as Java classes and 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-mentioned 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 location, 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 running in the operating system, determining the program code to be instrumented in the application based on the request message includes the following method steps:

[0191] Step S212, in response to the application 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 : determining different program codes to be inserted in the application program in response to different types of request messages, 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 application scenarios, a request message is a message sent by a client to a server, requesting an operation or data. These request messages can be of different types, such as HTTP requests, web service calls, and database queries. The processing logic and execution flow for each type of request message can be distinct.

[0195] Furthermore, the system needs to dynamically identify and distinguish different types of request messages during application runtime, that is, within the operating system environment. The type of request message can be identified based on the format and content of the request message, or the context in which the request is sent. For example, for HTTP requests, the method type (GET, POST, etc.) or URL in the request header can be parsed to identify the type of HTTP request. For microservice requests, the protocol or message format used for inter-service calls can be used to identify the type of microservice request.

[0196] Different types of request messages are independent of each other. That is, different types of request messages are processed and traced independently. That is, the instrumentation code and strategy for processing one type of request message will not affect other types of request messages. This ensures the accuracy and targeting 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 require instrumentation based on the different types of request messages, specifically the different program code. These different program code types are Java methods or Java classes responsible for handling the corresponding request message types. For example, the code that handles HTTP requests might reside in the web server's request handler, while the code that handles database calls might reside in the database access interface layer.

[0198] Furthermore, based on the request message type and processing logic, the different program codes to be instrumented are determined. For each type of request message, the system identifies the program code most relevant to the request message and then applies dynamic instrumentation technology to this program code 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 insertion of different program codes to be inserted. This not only means that developers and operation and maintenance personnel can perform fine-grained tracking of request execution flows 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 application scenarios that deal with complex multi-threading and microservice architectures, and can more accurately locate performance bottlenecks and optimization points, thereby improving the response speed of the application and user experience. 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 from the application after instrumentation to obtain the application before instrumentation;

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

[0203] Step S209: Record the call stack information of the application program's thread during its execution.

[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 insertion recovery through the target interface, the system will call the bytecode modification tool again, read the bytecode of the current program, remove the target probe code previously inserted, 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 instrumentation position. In a Java application scenario, the user can specify instrumentation multiple times and perform instrumentation operations on the same Java method or different Java methods. In particular, when tracing complex execution flows, the same target probe may be inserted at multiple locations. The above deduplication operations on multiple target probes ensure that even if the user repeatedly specifies the same instrumentation 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 instrumentation operation, but also ensures the accuracy of the instrumentation, 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 instrumentation is further optimized.

[0206] Based on step S209, the call stack information of the application's threads during execution is recorded. In Java application scenarios, when implementing the Java stack trace tool's tracing functionality, regardless of whether the instrumentation strategy is the first (Bwlog) or second (JNI) instrumentation strategy, the system will record the call stack information of Java method calls, i.e., the method call path. For the Bwlog instrumentation strategy, the system will include the call stack information in the output of the target probe. For the JNI instrumentation strategy, although the probe itself does not directly output the call stack, embodiments of the present application provide a mechanism for generating and maintaining a Java memory-to-symbol mapping, enabling system-level trace tools (such as Linux uprobe) to parse and record Java stack traces based on this mapping mechanism. Consequently, embodiments of the present application provide system-level trace tools with the necessary Java stack trace information, allowing developers to not only track the time overhead of Java method calls but also visualize the specific call paths, which helps understand complex multi-threaded interactions and execution flow links. By recording call stack information, embodiments of the present application improve the depth and accuracy of execution flow tracing, enabling more detailed and comprehensive performance analysis.

[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 locating. 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, this application also provides the following Figure 3 An application instrumentation method is shown. Figure 3 is a flowchart of another application instrumentation method according to an embodiment of the present application, wherein the application instrumentation method is applied to a tracing tool, such as Figure 3 As shown, the application's instrumentation methods include:

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

[0210] Step S302: Calling the application programming 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 execution flow of data generated by the application at the code level and the data generated at the system level during the operation of the operating system;

[0211] Step S303, using the application programming 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 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 instrumentation position, performs 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 aforementioned tracing tool can be an application execution flow tracing tool (i.e., a trace tool). Specifically, the execution flow tracing tool can instrument program code according to the aforementioned application instrumentation method and instrumentation strategy, inserting target probes at the instrumentation locations. Furthermore, the execution flow tracing tool uses the target probes inserted at the instrumentation locations to perform execution flow tracing on data generated by the application at the code level and at the system level, generating tracing results.

[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 manual code plugging into the application in the related art, which is inefficient. 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 performed, 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 related descriptions and will not be repeated here.

[0217] In the aforementioned operating environment, this application also provides the following Figure 4 Another application instrumentation method is shown. Figure 4 is a flow chart of another application instrumentation method according to an embodiment of the present application, such as Figure 4 As shown, the application's instrumentation methods include:

[0218] Step S401: acquiring program code to be instrumented 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 performing the plug-in operation on 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 instrumented program code by calling a second interface, wherein the second interface includes a second parameter, and a parameter value of the second parameter includes the instrumented program code.

[0223] The application instrumentation method of the embodiment of the present application can be run on a cloud server to provide an application instrumentation cloud service for the client. The client calls the first interface to send an application instrumentation request, and the cloud server obtains the program code to be instrumented in the application corresponding to the application instrumentation request through the first interface, generates the instrumented program code according to the application instrumentation method, and further returns the instrumented program code to the client through the second interface.

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

[0225] In an embodiment of the present application, in response to an application running in an operating system, the program code to be inserted in the application 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; 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 insertion position in the program code, and to 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; 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 tracing 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 tracing 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 related technologies.

[0226] It should be noted that the preferred implementation of the above steps S401 to S405 can be found in the above 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 this application is not limited by the order of the actions described, because according to this 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 this 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 the necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the technical solution of the present application, or the part that contributes to the existing technology, can be embodied in the form of a software product. The computer software product 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 enabling 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 structural diagram of an instrumentation device for an application 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 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; 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 determining module 503 is further configured 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 determining module 503 is further configured 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 above-mentioned 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 further used to: in response to the instrumentation strategy being the 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 the 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, associated with the instrumentation location, and 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 instrumentation module 504 is further configured to: perform an instrumentation operation on the program code in the running process according to the instrumentation strategy, so as to insert a target probe at the instrumentation position.

[0239] Optionally, the above-mentioned instrumentation module 504 is further used to: determine the target program code of the target probe; call the bytecode modification tool according to the instrumentation strategy to instrument the program code in the running process, so as to insert the target program code at the instrumentation 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 about the application and / or request the application to perform a task.

[0241] Optionally, the above-mentioned 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 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 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 insertion module 504 correspond to steps S201 to S204 in the embodiment. The four modules and the corresponding steps implement the same instances and application scenarios, but are not limited to the contents disclosed in the aforementioned embodiment.

[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 structural diagram of an instrumentation device for another application 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 in 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 tracing 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 use the application programming 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; 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 use the target probe inserted at the insertion position 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 to 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, insertion module 604 and tracking module 605 correspond to steps S301 to S305 in the embodiment. The five modules and the corresponding steps implement the same instances and application scenarios, but are not limited to the contents disclosed in the aforementioned embodiment.

[0246] 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 7 is a structural diagram of an instrumentation device for another application 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 obtain the 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; 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 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; an insertion module 704, which is used to insert the target probe at the insertion position according to the insertion strategy; an output module 705, which is used to output the program code after 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 insertion.

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

[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 part of a device.

[0249] It should be noted that the preferred implementation of this embodiment can be found in the relevant descriptions in the aforementioned embodiments and 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] Embodiments of the present application may provide an instrumentation system for an application. Figure 8 This is a structural block diagram of an application instrumentation system according to an embodiment of the present application. Figure 8 As shown, the application 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 information of an 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 program executes any one of the aforementioned application program insertion methods when the program is running.

[0255] Figure 9 This is a structural block diagram of an electronic device according to an embodiment of the present application. Figure 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), 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 this application.

[0257] Specifically, the electronic device can pre-install 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 genesis), model version control (supporting the control of different model versions), model evaluation (based on model evaluation tools to evaluate 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 (API) calling capabilities, and can call the model into the created application through the API interface. At the same time, it provides application management tools to achieve management and monitoring of the application.

[0258] Furthermore, the electronic device can 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. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, implementing the plugging method of the application in the above embodiment. 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 located 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 a combination thereof.

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

[0261] Those skilled in the art will understand that Figure 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 (MID). Figure 9 The structure of the electronic device is not limited. For example, the electronic device 90 may also include Figure 9 More or fewer components (such as network interfaces, display devices, etc.) shown in, or with Figure 9 Different configurations shown.

[0262] Those skilled in the art will understand that all or part of the steps in the plugging method for various applications in the above-mentioned embodiments can be completed by instructing the hardware related to the terminal device through a program. 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 magnetic 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 containing the computer-readable storage medium 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 instrumentation method of any one of the above-mentioned application programs in the above-mentioned 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, which, when executed by a processor, implements the application program instrumentation method provided in the embodiment.

[0267] 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 that can be used to store a computer program that, when executed by a processor, implements the application program instrumentation method provided in the above embodiments.

[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, it implements the application program instrumentation method provided in the above embodiment.

[0269] In the above embodiments of the present application, the description of each embodiment has its own focus. 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. In actual implementation, there may be other division methods, such as 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 separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0272] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or 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, or the part that contributes to the existing technology, 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 and includes a number of instructions for enabling 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 in each embodiment of the present application. The aforementioned storage medium includes: U disk, ROM, RAM, mobile hard disk, disk or optical disk, etc., various media that can store program code.

[0274] The above is only a preferred embodiment 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: Determining program code to be instrumented from an application program, wherein the application program runs in an operating system; 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; Determining an instrumentation location in the program code using the target interface, and determining an instrumentation strategy corresponding to the target probe, wherein the instrumentation strategy is used to represent a rule for performing an instrumentation operation on the program code, and the instrumentation strategy is determined from configuration information of the target interface; 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; Determining the insertion position in the program code using the target interface includes: determining an insertion position set using the target interface, wherein different program codes correspond to different insertion positions in the insertion position set; and determining the insertion position corresponding to the program code in the insertion position set using the target interface.

2. 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, the function being associated with the instrumentation operation; Determining the instrumentation strategy corresponding to the target probe includes: The instrumentation strategy is determined from the configuration information.

3. The method according to claim 2, characterized in that Determining the instrumentation strategy from the configuration information includes: In response to a policy selection operation, a first instrumentation strategy or a second instrumentation strategy is selected 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 a target type program code, where the target type is a type other than the type of the program code.

4. The method according to claim 3, characterized in that The target probe may be in the form of log information or a probe function in a target format. The program code may be instrumented according to the instrumentation strategy to insert the target probe at the instrumentation 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 location; 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, so as to insert the probe function at the instrumentation position.

5. The method according to claim 3, 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 using the identification information and the target probe to obtain a tracing result of the virtual thread.

6. The method according to claim 2, 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 tracking of data of the application; The behavior configuration information is used to indicate the operation behavior corresponding to the target probe.

7. The method according to claim 6, 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 data generated by the application at the code level and data generated at the system level.

8. The method according to claim 1, 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 insertion strategy, a bytecode modification tool is called to insert the program code in the running process, so as to insert the target program code at the insertion position.

9. The method according to claim 1, characterized in that Identify the program code to be instrumented from the application, including: In response to the application running 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 obtaining information of the application and / or requesting the application to perform a task.

10. The method according to claim 9, characterized in that In response to the application being run in the operating system, determining the program code to be instrumented in the application based on the request message includes: In response to the application running 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 instrumented in the application are determined, wherein the different program codes correspond to the different types of request messages.

11. The method according to any one of claims 1 to 10, 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 call stack information of the application's thread during operation.

12. A method for tracking an application, characterized in that: Used in tracking tools, including: Determining program code to be inserted from an application program, wherein the program code is a code in an object-oriented programming language, and the application program runs in an operating system; 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 tracing on data generated by the application at the code level and data generated at the system level during the execution of the operating system; Determining an instrumentation location in the program code using the application programming interface, and determining an instrumentation strategy corresponding to the target probe, wherein the instrumentation strategy is used to represent a rule for performing an instrumentation operation on the program code, and the instrumentation strategy is determined from configuration information of the application programming; 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; Using the target probe inserted at the insertion position, performing execution flow tracing on data generated by the application at the code level and data generated at the system level to obtain a tracing result; Determining the insertion position in the program code using the application programming interface includes: determining an insertion position set using the application programming interface, wherein different program codes correspond to different insertion positions in the insertion position set; and determining the insertion position corresponding to the program code in the insertion position set using the application programming interface.

13. A method for instrumenting an application, characterized in that: include: Acquire program code to be instrumented in the application by calling a first interface, wherein the first interface includes a first parameter, a parameter value of the first parameter includes the program code, and the application runs in an operating system; 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; Determining an instrumentation location in the program code using the target interface, and determining an instrumentation strategy corresponding to the target probe, wherein the instrumentation strategy is used to represent a rule for performing an instrumentation operation on the program code, and the instrumentation strategy is determined from configuration information of the target interface; 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; Outputting the instrumented program code by calling a second interface, wherein the second interface includes a second parameter, and a parameter value of the second parameter includes the instrumented program code; Determining the insertion position in the program code using the target interface includes: determining an insertion position set using the target interface, wherein different program codes correspond to different insertion positions in the insertion position set; and determining the insertion position corresponding to the program code in the insertion position set using the target interface.

14. An application instrumentation system, characterized in that: include: The client sends a request message, wherein the request message is used to request information of the application and / or request the application to perform a task; The server is configured to determine, based on the request message, program code to be inserted in the application program, wherein the application program runs in an operating system; call 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 program during operation of the operating system; determine an insertion position in the program code using the target interface, and determine an insertion policy corresponding to the target probe, wherein the insertion policy is used to represent a rule for inserting the program code, and the insertion policy is determined from configuration information of the target interface; perform an insertion operation on the running program code according to the insertion policy to insert the target probe at the insertion position; determine the insertion position in the program code using the target interface, comprising: determining an insertion position set using the target interface, wherein different program codes correspond to different insertion positions in the insertion position set; and determining the insertion position corresponding to the program code in the insertion position set using the target interface.

15. 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 13 when running.

16. 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 13.

17. A computer program product, characterized in that The invention comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 13.

Images