CN120029887B

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

Info

Publication number: CN120029887B
Application number: CN202510505449.1A
Authority: CN
Inventors: 林育德; 苏峰; 张权; 常怀鑫; 李三红
Original assignee: Alibaba Cloud Computing Ltd
Current assignee: Alibaba Cloud Computing Ltd
Priority date: 2025-04-21
Filing date: 2025-04-21
Publication date: 2025-09-05
Anticipated expiration: 2045-04-21
Also published as: CN120029887A

Abstract

The application discloses a pile inserting method, system, electronic equipment, storage medium and computer program product of an application program, and relates to the technical field of application programs. The method comprises the steps of determining program codes to be instrumented from an application program, calling a target interface corresponding to an operating system, determining a target probe configured for the program codes, wherein the target probe is used for tracking data generated by the application program in the running process of the operating system, determining the instrumentation position in the program codes by using the target interface, determining an instrumentation strategy corresponding to the target probe, wherein the instrumentation strategy is used for representing rules for instrumentation operation of the program codes, and performing instrumentation operation on the program codes according to the instrumentation strategy so as to insert the target probe in the instrumentation position. The application solves the technical problem that the efficiency is lower because the code instrumentation is manually carried out on the application program in the related technology.

Description

Method, system, electronic device, storage medium and computer program product for instrumentation of application program

Technical Field

The present application relates to the field of application technologies, and in particular, to a method, a system, an electronic device, a storage medium, and a computer program product for instrumentation of an application.

Background

In the application program technical field, the positioning of the performance problems of codes is mainly performed by means of a performance analysis technology. However, for some application scenarios, such as hypertext transfer protocol Server (HTTP SERVER) scenario, web Server (Web Server) scenario, micro-services, databases and high concurrency scenario in Java environment, there is a deeper demand for execution flow tracking, i.e. tracking each step of time of request execution, analyzing the percentile distribution of delay in order to improve user experience and system stability. In the related art, the tool based on the performance analysis technology cannot realize automatic instrumentation of the code of the application program, and the programmer is still required to manually insert the code, reconstruct the project and rerun the program to realize instrumentation of the application program, so that the related technology is difficult to support execution flow tracking of the application program, and the instrumentation efficiency of the application program is low.

In view of the above problems, no effective solution has been proposed at present.

Disclosure of Invention

The embodiment of the application provides a method, a system, electronic equipment, a storage medium and a computer program product for instrumentation of an application program, which at least solve the technical problem that the efficiency is low because code instrumentation is manually carried out on the application program in the related technology.

According to one aspect of the embodiment of the application, a instrumentation method of an application program is provided, and the instrumentation method comprises the steps of determining program codes to be instrumented from the application program, calling a target interface corresponding to an operating system, determining a target probe configured for the program codes, wherein the target probe is used for tracking data generated by the application program in the running process of the operating system, determining instrumentation positions in the program codes by using the target interface, determining instrumentation strategies corresponding to the target probe, wherein the instrumentation strategies are used for representing rules for instrumentation operation of the program codes, and performing instrumentation operation on the program codes according to the instrumentation strategies so as to insert the target probe in the instrumentation positions.

According to another aspect of the embodiment of the application, the instrumentation method of the application program is applied to a tracking tool and comprises the steps of determining program codes to be instrumented from the application program, calling an application programming interface corresponding to an operating system to determine a target probe configured for the program codes, wherein the target probe is used for performing flow tracking on data generated by the application program at a code level and data generated by the application program at a system level in the running process of the operating system, determining instrumentation positions in the program codes by using the application programming interface, and determining instrumentation strategies corresponding to the target probe, wherein the instrumentation strategies are used for representing rules for performing instrumentation operation on the program codes, performing instrumentation operation on the program codes according to the instrumentation strategies to insert the target probe at the instrumentation positions, and performing flow tracking on the data generated by the application program at the code level and the data generated by the system level by using the target probe inserted at the instrumentation positions to obtain tracking results.

According to another aspect of the embodiment of the application, a instrumentation method of an application program is provided, and the instrumentation method comprises the steps of obtaining program codes to be instrumented in the application program by calling a first interface, wherein the first interface comprises a first parameter, a parameter value of the first parameter comprises the program codes, calling a target interface corresponding to an operating system and determining a target probe configured for the program codes, wherein the target probe is used for tracking data generated by the application program in the running process of the operating system, determining an instrumentation position in the program codes by using the target interface, determining an instrumentation strategy corresponding to the target probe, wherein the instrumentation strategy is used for representing rules for instrumentation operation of the program codes, conducting instrumentation operation on the program codes according to the instrumentation strategy to insert the target probe in the instrumentation position, and outputting the instrumented program codes by calling a second interface, wherein the parameter value of the second interface comprises a second parameter.

According to another aspect of the embodiment of the application, a instrumentation system of an application program is provided, which comprises a client, a server, a target interface and an instrumentation policy, wherein the client is used for sending a request message, the request message is used for requesting to acquire information of the application program and/or requesting the application program to execute tasks, the server is used for determining program codes to be instrumented in the application program based on the request message, the target interface corresponding to an operating system is called and is determined to be a target probe configured by the program codes, the target probe is used for tracking data generated by the application program in the running process of the operating system, the instrumentation policy corresponding to the target probe is determined by utilizing the target interface, the instrumentation policy is used for representing rules for instrumentation operation on the program codes, and the instrumentation operation is performed on the program codes according to the instrumentation policy so as to insert the target probe in the instrumentation location.

According to another aspect of the embodiment of the application, there is also provided an electronic device, including a memory storing an executable program, and a processor for running the program, where the program executes the method of any one of the above.

According to another aspect of the embodiments of the present application, there is also provided a computer readable storage medium, including a stored executable program, wherein the executable program when run controls a device in which the storage medium is located to perform the method of any one of the above.

According to another aspect of embodiments of the present application, there is also provided a computer program product comprising a computer program which, when executed by a processor, implements a method according to any of the above.

In the embodiment of the application, a program code to be instrumented is determined from an application program, a target interface corresponding to an operating system is called, a target probe configured for the program code is determined, wherein the target probe is used for tracking data generated by the application program in the running process of the operating system, the instrumentation position in the program code is determined by utilizing the target interface, an instrumentation strategy corresponding to the target probe is determined, the instrumentation strategy is used for representing a rule for instrumentation operation of the program code, and the instrumentation operation is performed on the program code according to the instrumentation strategy so as to insert the target probe in the instrumentation position. Therefore, the embodiment of the application inserts the target probe into the program code running in the operating system in a mode of calling the target interface, in particular to the method and the device, which can determine the instrumentation position and the instrumentation strategy in the program code, achieves the aim of automatically instrumentation into the application program so as to support the execution flow tracking of the operating system level, achieves the technical effects of improving the code instrumentation efficiency in the application program and facilitating the execution flow tracking of the application program in the operating system level, and further solves the technical problem that the efficiency is lower because the code instrumentation is manually conducted to the application program in the related technology.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application, as claimed.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:

FIG. 1 shows a block diagram of the hardware architecture of a computer terminal (or mobile device) for implementing the instrumentation method of an application program;

FIG. 2 is a flow chart of a instrumentation method of an application according to an embodiment of the present application;

FIG. 3 is a flow chart of another method of instrumentation of an application according to an embodiment of the present application;

FIG. 4 is a flow chart of a method of instrumentation of yet another application according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a pile driver for an application according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a pile driver for another application according to an embodiment of the present application;

FIG. 7 is a schematic diagram of a pile driver for another application according to an embodiment of the present application;

FIG. 8 is a block diagram of a instrumentation system of an application according to an embodiment of the present application;

fig. 9 is a block diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In order that those skilled in the art will better understand the present application, a technical solution in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, shall fall within the scope of the present application.

It should be noted that the terms "first," "second," and the like in the description and the claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the application described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

First, partial terms or terminology appearing in the course of describing the embodiments of the application are applicable to the following explanation.

Java (Java Programming Language) is a high-level, generic, object-oriented programming language that plays an important role in enterprise-level application, web service, and mobile application development, in terms of its cross-platform capabilities and wide-ranging applications.

JVM (collectively Java Virtual Machine) refers to a virtual machine for running Java bytecodes, responsible for executing and managing Java programs.

JDK (collectively Java Development Kit) is a tool kit for developing Java programs, and includes JVM, java class library and other development tools, which is the basic environment for Java development.

Dynamic instrumentation (Dynamic Instrumentation) refers to a technique that can modify the behavior of an application during its operation. In particular, dynamic instrumentation refers to the monitoring, analysis, or modification of program runtime behavior by inserting new code fragments at specific locations. The dynamic instrumentation is particularly suitable for performance tuning, log recording, code debugging and other scenes. The dynamic instrumentation can take effect without restarting the application program, and has stronger flexibility.

Execution flow Trace (Execution Trace) is a detailed record of the Execution of an application. By tracking function calls, thread states, and events for an application, a developer can be aided in understanding behavior, performance issues, and potential errors of application execution. Performing flow tracing is an important means of performance analysis and debugging.

Request (Request) in the client-server model, an operation or data Request initiated by a client to a server for obtaining information or performing a specific task. The request is a basic interactive element in the network communication. The response time and processing efficiency of the request directly affect the user experience.

Response Time (RT) measures the Time required from the client to the receipt of a server Response. Response time is a key indicator for evaluating system performance and user experience.

An Execution link (Execution Path) is used to describe the sequence relationships and dependencies between function calls, thread activities, and event triggers in the application Execution flow. The execution links help analyze the logical paths and performance problems of program execution.

Percentile time (PERCENTILE TIME) the time value at a particular percentile among a set of time data reflects the ranking of that set of time data in the dataset. That is, the percentile time is used to evaluate the distribution characteristics of response times or execution times, helping to identify performance bottlenecks and optimization directions.

Application programming interfaces (Application Programming Interface, APIs for short) define rules and methods of interaction between applications or libraries, enabling different software components to communicate and cooperate with each other, simplifying development work and enhancing the scalability of system functionality.

Linux (Linux Operating SYSTEM KERNEL) is an open source Operating system kernel, is widely applied to servers, embedded systems and personal computers, and has higher customization, stability and community support.

User Space Probe Uprobe is a function provided by Linux kernel, allowing the dynamic insertion of tracking points in User Space application program, and can monitor and modify the execution of specific function at runtime, but not directly support Java method-level instrumentation.

A dynamic link library file (SO) refers to a library file format that can be Shared by a plurality of programs in a Linux environment, and generally contains pre-compiled code and data, which helps to save memory and improve interoperability between programs.

Local files (NATIVE FILE), referred to as programs or library files written in a local programming language (e.g., C/C++), are often used to encapsulate underlying operations or high-performance computations. In particular, a Java native interface (Java NATIVE INTERFACE, abbreviated as JNI) method is often stored in a local file in an application scenario.

Java Class refers to a unit for organizing and encapsulating data and functions. A Java Method (Method) is a code segment defined in a Java class for performing a specific task. The function of the corresponding Java class may be started by invoking the Java method.

Input/Output (I/O) refers to the data transmission process between a computer system and an external device or environment, including reading and writing of data, and is the basis for interaction between an operating system and application programs and the outside world.

Virtual Thread (Virtual Thread) is a lightweight Thread model, allows multiple tasks to be executed concurrently in the same operating system Thread, is particularly suitable for I/O intensive applications, and can improve concurrency and response speed of programs.

Platform threads (Platform threads), which refer to traditional Thread implementations, map directly to operating system threads for processing computationally intensive tasks, unlike virtual threads.

The glitch (Spikes) refers to a sudden performance degradation or delay in the application. Burrs are often caused by transient high loads, resource competition, or system bottlenecks, which can affect the stability and user experience of the system.

The hypertext transfer protocol server (HTTP SERVER) is a server specially processing HTTP protocol requests, and is responsible for receiving requests from the network and returning corresponding resources or processing results.

The Web Server (Web Server) not only processes HTTP request, but also supports dynamic content generation and static file service, and is an infrastructure supporting website and Web application operation.

The micro service (Microservices Architecture) refers to a software design mode, a single application program is decomposed into a group of small and independent services, each service is responsible for a specific function, communication is carried out through a definite API, and the expandability and independent deployment capability of the system are improved.

Java Backend (Java back) is a server-side application developed using the Java language, responsible for handling business logic, data management, and interactions with the front-end. Java backend is an important component in Web application architecture.

Stack tracking STACK TRACE refers to the recording of the current call sequence of a thread during program execution. Stack trace includes a series of method call and execution points that can be used for debugging and performance analysis to help identify error sources and execution paths.

Java Agent refers to a special type of Java program that can be attached to the JVM at application start-up or run-time to monitor, modify or enhance the running Java application. Java agents are an effective means of Java performance monitoring and debugging.

A Just-In-Time Compiler (JIT Compiler for short) compiles high-level language code (such as Java byte code) into machine code In real Time when the program runs, so that the execution efficiency is improved, but the address layout of the program can be changed during each running due to the characteristic of dynamic compiling, so that the difficulty of acquiring accurate stack tracking is increased.

Probes (probes) are tools for monitoring the behavior of an application program during operation, and are used for facilitating performance analysis and fault detection by inserting monitoring points at key positions of codes to collect and report data during operation of the program.

Java archive files (Java ARCHIVE FILE, JAR files for short) refer to file formats used to package and distribute Java class libraries and applications, and may contain compiled class files, resource files, and metadata.

The log (Synchronous Logging) is synchronized in that the record waits in the main program stream for the log write to complete. Asynchronous journaling Asynchronous Logging separates the logging operations into background thread execution, reducing the blocking time of the main program.

There is also provided, in accordance with an embodiment of the present application, an embodiment of a instrumentation method for an application program, wherein steps illustrated in the flowcharts of the figures may be executed in a computer system, such as a set of computer executable instructions, and wherein although a logical order is illustrated in the flowcharts, in some cases the steps illustrated or described may be executed in an order different from that herein.

The method according to the first embodiment of the present application may be implemented in a mobile terminal, a computer terminal or a similar computing device. Fig. 1 shows a hardware block diagram of a computer terminal (or mobile device) for implementing the instrumentation method of an application program. As shown in fig. 1, the computer terminal 10 (or mobile device 10) may include one or more (shown as 102a,102 b), a processor 102 (the processor 102 may include, but is not limited to, a processing device such as a microprocessor (Microcontroller Unit, MCU) or a programmable logic device (Field Programmable GATE ARRAY, FPGA)), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, the computer terminal 10 can include a display, an input/output interface (I/O interface), a universal serial bus (Universal Serial Bus, USB) port (which can be included as one of the ports of a computer bus), a network interface, a cursor control device (e.g., a mouse, a touchpad, etc.), a keyboard, a power source, and/or a camera.

It will be appreciated by those of ordinary skill in the art that the configuration shown in fig. 1 is merely illustrative and is not intended to limit the configuration of the electronic device described above. For example, the computer terminal 10 may also include more or fewer components than shown in FIG. 1, or have a different configuration than shown in FIG. 1.

It should be noted that the one or more processors 102 and/or other data processing circuits described above may be referred to generally herein as "data processing circuits. The data processing circuit may be embodied in whole or in part in software, hardware, firmware, or any other combination. Furthermore, the data processing circuitry may be a single stand-alone processing module, or incorporated, in whole or in part, into any of the other elements in the computer terminal 10 (or mobile device). As referred to in embodiments of the application, the data processing circuit acts as a processor control (e.g., selection of the path of the variable resistor termination connected to the interface).

The memory 104 may be used to store software programs and modules of application software, such as program instructions/data storage devices corresponding to the instrumentation method of application programs in the embodiments of the present application, and the processor 102 executes the software programs and modules stored in the memory 104, thereby executing various functional applications and data processing, i.e. implementing the instrumentation method of application programs described above. Memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include memory located remotely from the processor 102, which may be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission means 106 is arranged to connect to a network via a network interface for receiving or transmitting data. Specific examples of the network described above may include wired and/or wireless networks provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC) that can connect to other network devices through a base station to communicate with the internet. In one example, the transmission device 106 may be a Radio Frequency (RF) module for communicating with the internet wirelessly.

The display shown in fig. 1 may be, for example, a touch screen type Liquid crystal display (Liquid CRYSTAL DISPLAY, LCD) that may enable a user to interact with a user interface of the computer terminal 10 (or mobile device).

It should be noted here that, in some alternative embodiments, the computer device (or mobile device) shown in fig. 1 described above may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that fig. 1 is only one example of a specific example, and is intended to illustrate the types of components that may be present in the computer device (or mobile device) described above.

In the above-described operating environment, the present application provides a instrumentation method for an application program as shown in fig. 2. Fig. 2 is a flow chart of a instrumentation method of an application according to an embodiment of the present application. As shown in fig. 2, the method may include the following steps S201 to S204.

In step S201, the program code to be instrumented is determined from the application.

The application programs may be, but are not limited to, java programs, enterprise-level applications, mobile applications, java server-side applications. When an application runs in an operating system, program code to be instrumented may be determined from the application, which may be a Java method in a Java program. That is, the instrumentation operation of the program codes can be implemented in the running process of the application program, the instrumentation process is dynamic instrumentation, and the execution flow tracking of the application program is implemented on the operating system level.

Specifically, in response to an application running in an operating system, program code to be instrumented in the application is determined. Based on this, the dynamics of the application instrumentation scheme is achieved, which means that the specific Java method that needs to be instrumented can be identified without restarting the application.

In an application scenario, instrumentation points in an application program can be intelligently selected in combination with static code analysis and dynamic runtime monitoring, thereby determining program code to be instrumented.

For example, in the process of static code analysis, tools or plug-ins can be used for code examination, source codes or byte codes of application programs are analyzed, key business logic branches, loop structures, method calls, data access and other code areas which possibly become performance bottlenecks are identified, known performance analysis knowledge bases or models can be utilized for predicting which code paths possibly have problems of resource competition, deadlock, long tail delay and the like under high concurrency or specific load, and methods and classes which are frequently executed or consume more resources can be found out according to historical performance data analysis, so that candidate objects to be inserted are determined.

For example, in the process of dynamic runtime monitoring, runtime performance monitoring tools (such as Java VisualVM, JProfiler, visual GC, etc.) can collect the running data of an application program under real or simulated load, including CPU utilization, memory consumption, thread state, response time, etc., and further analyze the running data to identify the code segment with the most consumed resources, the longest response time, or abnormal behavior in actual execution. In addition, the hot spot analysis function can be utilized to automatically identify the code path with highest access frequency and longest time consumption in the running process of the application program, and the code path is used as a key attention object of dynamic instrumentation.

For another example, in determining the code of the program to be instrumented from the application, a comprehensive strategy that fuses static code analysis with dynamic runtime monitoring is employed to intelligently locate performance bottlenecks. First, through static code analysis, an exhaustive list of instrumentation point candidates is built before application deployment, focusing on code segments that may be hot spots or cause performance problems. Then, in the actual running environment of the application program, the dynamic performance data collection module continuously monitors key indexes such as thread behavior, resource consumption, response time and the like, and feeds the key indexes back to the analysis engine. Based on the method, the analysis engine intelligently identifies exact code segments in combination with information obtained by static analysis, and the code segments can be regarded as the root of performance problems appearing in dynamic monitoring, so that the instrumentation strategy can be dynamically adjusted, the instrumentation strategy is more close to the real requirements of application, and the accuracy of performance optimization is improved.

In addition, considering the complexity of business logic and the requirement of a specific scene, the method and the class to be inserted can also be supported by an intuitive interface or a graphical user interface, and developers and operation and maintenance personnel can manually select and adjust the class and the method to be inserted according to the consideration of the hole or the specific performance problem of the business process.

It should be noted that, in order to further improve the comprehensiveness and depth of instrumentation, the embodiments of the present application may also incorporate a system level tracking technique to dynamically track interactions (such as system calls, context switches, and input/output operations) between an application program and an operating system. In addition, in order to further strengthen the instrumentation capability of the virtual thread, the code paths responsible for critical tasks in a high concurrency scene can be precisely positioned by carefully analyzing the creation and scheduling modes of the virtual thread, and instrumentation is set for the code paths so as to realize the fine monitoring of the activity and resource allocation of the virtual thread.

It should be noted that, the embodiment of the present application may also introduce an event-driven pile inserting mechanism. Through presetting event or performance threshold, when the application program encounters abnormal conditions in the running process, such as long-time blocking or resource occupation exceeding expectations, the pile inserting strategy is dynamically adjusted, the problem codes are rapidly positioned, the fault positioning time is greatly shortened, and the stability and response speed of the system are improved.

From the above, it can be seen that determining the program code to be instrumented relies mainly on deep understanding and analysis of the application program, in combination with static code inspection and dynamic runtime monitoring, to identify those code locations that are critical to performance optimization. The intelligent pile inserting strategy can effectively reduce unnecessary monitoring expenditure, concentrate resources on performance hot spots needing to be concerned, and accordingly overall application performance and user experience are improved. It is easy to note that, based on the above step S201, the embodiment of the present application can adapt to any Java method, including those that are dynamically created or changed at runtime, and provides a wide range of applications for subsequent instrumentation.

Step S202, a target interface corresponding to an operating system is called, and a target probe configured by a program code is determined, wherein the target probe is used for tracking data generated by an application program in the running process of the operating system.

Further, a target interface corresponding to the operating system is called, and a target probe configured for the program code is determined, wherein the target probe is used for tracking data generated by the application program in the running process of the operating system. The target interface may be an API in the operating system for defining the target probe. The target interface may be a predefined instrumented interface. In an application scenario, the target probes configured for the program code may include a preset number of types (e.g., 256 types) of Java probes. The target probe may perform execution flow tracking on execution data generated by an application during execution of the application.

In particular, the target interface may be a system level interface such as Linux uprobe. The target interface is capable of dynamically inserting tracking points in the user space program. The target probes are configured as observation points associated with a particular Java method, through which detailed information at program runtime can be gathered, including but not limited to CPU usage information, context switch information, I/O operation information, and the like.

In step S203, the target interface is used to determine the instrumentation position in the program code, and determine the instrumentation policy corresponding to the target probe, where the instrumentation policy is used to represent the rule of the instrumentation operation for the program code.

According to the definition of the target probe, the stake-inserting strategy corresponding to the target probe can be determined. Specifically, in the application scenario, there is a correspondence between different instrumentation strategies and different probes defined in advance, and the instrumentation strategies can be determined according to the correspondence and the target probes determined by calling the target interfaces. For example, the instrumentation policy described above may include log-based (Bwlog) instrumentation, JNI instrumentation.

Bwlog instrumentation is a log-based instrumentation technique that outputs logs in a specific format at specified code locations that can then be parsed by trace tools to restore Java execution streams. Bwlog instrumentation has the advantage of flexibility in implementation, e.g., buffer-based synchronization logs (minimal execution overhead) can be employed. Furthermore, bwlog instrumentation can provide more rich information (such as support for virtual thread authentication), but the performance overhead of Bwlog instrumentation is typically higher than JNI instrumentation due to the involvement of file I/O operations.

JNI instrumentation is an instrumentation technique implemented based on JNI calls by inserting calls to specific JNI methods (i.e., probes) at the target code locations. JNI instrumentation is primarily intended to fit tools (e.g., linux uprobe) that only support SO probes. However, the JNI instrumentation has a limitation that only the platform thread of the caller can be identified, and the virtual thread cannot be precisely tracked, but the JNI instrumentation has the advantages of higher execution efficiency and less I/O overhead.

In an application scenario, the instrumentation location may be selected according to a user's configuration. For example, the instrumentation locations may include a method entry (call) location and/or a return (ret) location. And the instrumentation policy may be used to determine how to insert probes, for example, using log (log) form or JNI call form. The choice of instrumentation policy directly affects the type of data tracked and the overhead of the tracking process.

In step S204, the program code is instrumented according to the instrumentation policy to insert the target probe at the instrumentation location.

Further, in the application scenario, instrumentation operations are performed on the program code according to an instrumentation policy through an instrumentation interface (Instrumentation API) provided by the JVM. Specifically, the code of the target probe is added at the stake-in location by a bytecode modification tool (such as Javassist or Byte Buddy) to ensure that the target probe can be activated at the correct location to collect the required data.

It is easy to note that, through steps S201 to S204, the embodiment of the present application can implement dynamic instrumentation of the program code to be instrumented (such as any Java method) in an application program (such as a Java program) during running, without restarting the application program, and by interfacing with a system-level trace tool, tracking of a program code call link is provided, and at the same time, key performance indicators of an operating system level, such as a multithreading competition condition and I/O delay, can be acquired. In addition, the scheme provided by the embodiment of the application also supports pile inserting recovery and re-starting, so that the performance problems of the application program can be quickly positioned and analyzed in an on-line environment. Through the flexible configuration of the probe types and the instrumentation strategy, the low invasiveness of instrumentation is guaranteed, the comprehensive insight of the execution cost is realized, and the performance analysis capability and the problem debugging efficiency of the application program are greatly enhanced.

It can be seen that in the embodiment of the application, a program code to be instrumented is determined from an application program, a target interface corresponding to an operating system is called, a target probe configured for the program code is determined, wherein the target probe is used for tracking data generated by the application program in the running process of the operating system, the instrumentation position in the program code is determined by using the target interface, an instrumentation strategy corresponding to the target probe is determined, wherein the instrumentation strategy is used for representing a rule for instrumentation operation of the program code, and the instrumentation operation is performed on the program code according to the instrumentation strategy so as to insert the target probe in the instrumentation position. Therefore, the embodiment of the application inserts the target probe into the program code running in the operating system in a mode of calling the target interface, in particular to the method and the device, which can determine the instrumentation position and the instrumentation strategy in the program code, achieves the aim of automatically instrumentation into the application program so as to support the execution flow tracking of the operating system level, achieves the technical effects of improving the code instrumentation efficiency in the application program and facilitating the execution flow tracking of the application program in the operating system level, and further solves the technical problem that the efficiency is lower because the code instrumentation is manually conducted to the application program in the related technology.

Alternative embodiments included in the above-described method provided by embodiments of the present application are further described below.

In an alternative embodiment, in step S203, the instrumentation location in the program code is determined using the target interface, comprising the following method steps:

Step S231, determining a pile-inserting position set by utilizing a target interface, wherein different program codes correspond to different pile-inserting positions in the pile-inserting position set;

And S232, determining the instrumentation position corresponding to the program code in the instrumentation position set by utilizing the target interface.

In the alternative embodiment, the target interface may support different program codes, and different instrumentation locations may be determined according to the different program codes during multiple calls to the target interface. For example, the target interface supports any Java class and Java method, specifies the instrumentation location multiple times, and can freely select a specific operation or a specific action (action) to be executed at the corresponding instrumentation location each time, based on which data tracking can be performed at the beginning or end of any Java method.

In an application scenario, a target interface refers to a specific function defined in an API (application programming interface). The target interface allows a user to interact with the dynamic instrumentation system to specify and control details of instrumentation. The instrumentation location set refers to a series of code locations that can be selected to be instrumented, which may be any method entry (call) location, any method pre-return (ret) location, or a full life cycle (full) of the entire method for any class in a Java program. The different program code corresponds to different instrumentation locations in the set of instrumentation locations, which means that a user may precisely specify the code segment that is desired to be monitored or analyzed, e.g., a particular class or method, according to particular needs.

In the application scene, the configuration parameters provided by a user through an API are analyzed by utilizing the target interface, and the pile inserting position set is determined. These configuration parameters include, but are not limited to, class name and method name of the required instrumentation, instrumentation mode (Bwlog instrumentation or JNI instrumentation), event name (event), timing action (action), distinguishing flag (tag), etc. And identifying code segments to be monitored through the configuration parameters, determining specific positions of the code segments in the Java program, and further determining a pile inserting position set.

Further, the target interface is utilized to determine the stake inserting position corresponding to the program code in the stake inserting position set, and the stake inserting position to be monitored is accurate to each specific method or code segment to be monitored according to the stake inserting position set. In the process of determining the instrumentation position corresponding to the program code, the Java byte code is read and modified, and through Instrumentation API, the system can inject specific codes or calls into the appointed instrumentation position so as to monitor the program behavior.

Through the steps S231 to S232, the embodiment of the present application can implement an accurate and flexible dynamic instrumentation mechanism for application programs. The user can select any program code (such as Java method) to perform instrumentation according to specific requirements, and meanwhile, the depth (such as call, ret or full) of the instrumentation and the manner (such as Bwlog instrumentation or JNI instrumentation) of the instrumentation are controlled.

In an alternative embodiment, the instrumentation method of the application program further includes:

step S233, obtaining configuration information of a target interface, wherein the configuration information is used for describing functions configured for the target interface, and the functions are associated with pile inserting operation;

in step S203, determining a stake-inserting strategy corresponding to the target probe, including the following method steps:

Step S234, determining the pile inserting strategy from the configuration information.

In the above-described alternative 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 policy may be determined from the configuration information.

In an application scenario, the target interface may be an interface provided by the operating system for dynamically inserting tracking points, such as uprobe of Linux. Configuration information may include instruction sets regarding instrumentation operations, such as in which particular Java method the user wishes to instrumentation, whether the user wishes to implement instrumentation through log output (log) or JNI calls (type), and whether the user wishes to mark a particular event (event), the mark (action may take start, end, or mark), etc. Based on the configuration information, a user can flexibly determine the configuration information according to the requirements, so that the pile inserting strategy is controlled. That is, by the above-mentioned alternative embodiment, the pertinence of the instrumentation can be enhanced, the unnecessary performance loss is reduced, and the accuracy and practicality of the execution flow tracking of the Java program are improved.

Further, from the configuration information, a instrumentation policy is determined. The instrumentation policy is formulated based on the configuration information, and specifically instructs a bytecode modification tool how to add additional codes in the Java method, so as to achieve the instrumentation mode and the instrumentation purpose specified by the user. Based on the method, the embodiment of the application can support the dynamic adjustment of the instrumentation behavior of the user, even in the running process of the program, the instrumentation strategy can be changed in real time according to the new configuration information, the application program (such as Java program) is not required to be restarted, and the efficiency of online debugging and performance analysis is improved.

Through the steps S233 to S234, the embodiment of the present application realizes the capability of dynamically configuring and implementing instrumentation, so that a user can adjust the instrumentation policy in real time according to the actual requirements when an application program runs, and accurately track the execution overhead of a specific method. Based on the method, the device and the system, the understanding and positioning capability of Java developers and operation and maintenance personnel to application performance bottlenecks can be enhanced, particularly when complex multithreading and micro-service architecture is processed, request processing delay can be effectively analyzed and optimized, and service quality is improved. Meanwhile, the embodiment of the application can realize the adjustment of the dynamic pile inserting strategy, avoid unnecessary resource waste and keep the stability and the high efficiency of the program performance.

In an alternative embodiment, in step S234, the instrumentation policy is determined from the configuration information, including the following method steps:

In step S235, in response to the policy selection operation, a first instrumentation policy or a second instrumentation policy is selected from the configuration information, where the first instrumentation policy is used to represent a rule for instrumentation operation on the program code based on log information of the application program, and the second instrumentation policy is used to represent a rule for instrumentation operation on the program code based on a target type program code, and the target type is other types than the type of the program code.

The policy selection operation may be that the user decides whether to use the instrumentation policy based on log information or the instrumentation policy based on the target type program code according to the need. The first instrumentation policy, i.e. Bwlog instrumentation policy, is an instrumentation method that outputs log of a specific format at a specified code location, and can provide rich method call information, including virtual thread identification, which helps to accurately track the execution flow of each request in a multi-threaded environment. The output format and content of Bwlog instrumentation strategies can be customized through configuration to meet different analysis requirements. In the Java application scenario, the user selects Bwlog the instrumentation policy, which means that an additional log record code is added to the program code by using the Java log framework, so that relevant information is recorded before and after the Java method call, and the details of the execution flow can be understood by analyzing the log later.

The second instrumentation policy is used to represent rules for instrumentation of the program code based on the target type of the program code, where the target type is other than the type of the program code. The second instrumentation policy, i.e., the JNI instrumentation policy, is a technique for implementing instrumentation by invoking the JNI method. The instrumentation approach is mainly used to meet the requirements of system level trace tools (such as Linux uprobe) which only support SO file probes. In a Java application scenario, by inserting a call to the JNI method in Java code, the execution behavior of the Java method can be mapped into the trace tool at the operating system level, so as to obtain performance data (such as the overhead of kernel events) at a lower level. The user selects a second instrumentation policy, meaning that calls to specific JNI functions are added to the program code, which are defined in a local file (such as library. So). These JNI functions act as target probes, triggered by trace tools at the operating system level, to record system level information related to Java method execution.

Through the step S235, the embodiment of the application realizes a dynamic policy selection mechanism, allows a user to flexibly switch between log-based instrumentation and JNI-based instrumentation according to specific application scenarios and requirements, and improves the adaptability and practicality of an application instrumentation scheme. The log-based instrumentation strategy provides a high information content view angle, so that the execution path and time distribution of the application program can be understood conveniently, and the JNI-based instrumentation strategy provides powerful support for scenes in which the performance index of the operating system layer needs to be acquired. The log-based instrumentation strategy is combined with the JNI-based instrumentation strategy, so that comprehensive performance data can be obtained at both the Java application level and the system level, and therefore, performance bottlenecks or abnormal delay problems can be more accurately positioned and analyzed, and a technical foundation is provided for optimizing the performance and service quality of Java applications.

In an alternative embodiment, the expression form of the target probe includes log information or probe functions in a target format, and in step S204, the program code is subject to a instrumentation operation according to an instrumentation policy to insert the target probe in an instrumentation position, including the following method steps:

step S241, in response to the instrumentation policy being the first instrumentation policy, instrumentation operation is performed on the program code based on the log information of the application program to insert log information in a target format at the instrumentation position;

In step S242, in response to the instrumentation policy being the second instrumentation policy, instrumentation is performed on the program code based on the target type program code to insert the probe function at the instrumentation location.

In the above alternative embodiment, when the instrumentation policy is the first instrumentation policy, the expression form of the target probe is log information in the target format, that is, the target probe corresponding to the Bwlog instrumentation policy is log output in the specific format. When the instrumentation policy is the second instrumentation policy, the expression form of the target probe is a probe function, that is, the target probe corresponding to the JNI instrumentation policy is a JNI function.

It should be noted that, under the Bwlog instrumentation policy, in order to track the program execution flow and performance index, log information may be output according to a predefined structure, so as to obtain the log information in the specific format. The log format facilitates the identification and analysis of subsequent analysis tools, so that the behavior, the calling sequence and the resource consumption condition of the program in the running process can be accurately captured and analyzed. When the instrumentation policy is set to the first instrumentation policy, the system will perform the instrumentation operation by inserting log information in a specific format at the specified instrumentation location, which records the start and end times of the method call, and possibly intermediate mark points, including the identity of the virtual thread, etc.

Specifically, when the first instrumentation policy (i.e., bwlog instrumentation policy) is employed, log statements of a particular format are inserted precisely at selected locations in the code, based on the existing log framework and information of the target application. This involves specifying parameters, via the command line tool, such as class name to be instrumented, method name, instrumentation location (e.g., method entry or exit point), event type, and desired log format (e.g., including elements such as time stamp, thread identification, event name, etc.). After the command line tool receives these parameters, the bytecode of the running application is dynamically modified using the instrumented interface (Instrumentation API) and bytecode manipulation techniques to implement insertion of formatted log output code at specified code locations. Therefore, each time the target method is called or returned, the application program automatically outputs log information conforming to a preset format, and records details and key performance indexes of the execution flow, so that a detailed data basis is provided for subsequent performance analysis and problem positioning.

According to the above step S241, the log information of the application program is used as the data source of the tracking tool, and the instrumentation method is related to the input and output of the file, but can provide more abundant execution flow information, including but not limited to the method call stack, the identification of the virtual thread, etc. Although the performance overhead of the pile inserting mode may be relatively slightly higher, the synchronous log output mode with the buffer zone is adopted, so that the influence on the program operation is minimized while the information integrity is ensured. The above-described scheme in which the instrumentation policy is set as the first instrumentation policy is particularly suitable for a scenario in which detailed knowledge of an execution path and time resolution is required.

When the instrumentation policy is set to the second instrumentation policy, instrumentation is performed on the program code based on the target type program code to insert the probe function at the instrumentation location.

Specifically, when the second instrumentation policy (i.e., the JNI instrumentation policy) is selected, the system inserts JNI function calls as probes at its ingress or egress locations for the specified Java method. The above operations are based on the target Java code by dynamically modifying the bytecode without recompiling or restarting the application. The probe function is located in a matched local library, can work together with a system-level tracking tool, captures fine-grained information (such as starting and ending time) of method call in real time, and effectively supports high-performance and low-intrusion execution flow tracking requirements.

The probe functions are predefined in a shared object or dynamic link library file supported by the system level trace tool. For example, the probe function may include jni_start_00, jni_start_01, jni_mark_ff, etc. in the library. In a Java application scenario, by inserting calls to these probe functions at specific locations of the Java program, embodiments of the present application can seamlessly interface with a system level trace tool (e.g., linux uprobe) to enable timing of Java method call start, end, and mark, and corresponding event tracking. The stake-in manner in which the stake-in strategy described above is set as the second stake-in strategy has the advantage of low invasiveness and low performance overhead.

Through the steps S241 to S242, the embodiment of the present application provides comprehensive support for execution flow tracking of the application program through the instrumentation policy based on log information and the instrumentation policy based on probe functions. The user can select a proper instrumentation strategy according to the actual needs and performance considerations, so as to realize fine analysis of the execution overhead of the program code (such as Java method), including but not limited to method time consumption, call stack, virtual thread identification, etc. Meanwhile, by docking with a system-level trace tool, the scheme provided by the embodiment of the application can capture and analyze deeper performance data, thereby realizing cross-language and cross-system performance analysis and remarkably enhancing the performance monitoring and optimizing capability of Java application.

In an alternative embodiment, the instrumentation method of the application program further comprises the following method steps:

step S251, identifying a virtual thread corresponding to the program code to obtain the identification information of the virtual thread in response to the instrumentation policy being the first instrumentation policy;

Step S252, tracking the virtual thread by using the identification information and the target probe to obtain a tracking result of the virtual thread.

In the above alternative embodiment, when the instrumentation policy is the first instrumentation policy, the virtual thread corresponding to the program code is identified, and the identification information of the corresponding virtual thread is output in log.

In a Java application scene, the virtual thread is a newly introduced thread model of Java, and a plurality of tasks can be concurrently executed in the same operating system thread, so that concurrency capacity is improved, and switching overhead among threads is reduced. In Java applications, the identification information of a virtual thread typically includes thread identification and other metadata, which can be used to track the execution flow of the virtual thread.

In particular, the identification information may also refer to data capable of uniquely identifying the virtual thread, including, but not limited to, thread identification of the virtual thread, thread group information, priority, and the like. This identification information is used in dynamic instrumentation techniques to ensure that instrumentation code is accurately associated with the correct virtual thread, thereby collecting execution flow data associated with that virtual thread. The instrumentation code refers to a code segment dynamically inserted in a Java method for collecting execution stream data.

The tracking result refers to the collected detailed data reflecting the execution flow of the virtual thread after the virtual thread is inserted and tracked. The data in the trace results may include CPU usage time of the virtual thread, I/O latency, context switch time, call stack information, etc. The tracking results provide critical information for evaluating and optimizing virtual thread performance.

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

Further, the virtual thread is tracked by using the identification information and the target probe, and a tracking result of the virtual thread is obtained. After obtaining the identification information of the virtual thread, the system can use the identification information and the target probe set previously to track and record the activity of the virtual thread in detail. In particular, the tracking process involves executing specific code at the instrumentation location to capture the state and behavior of the virtual thread at a certain point in time, and then generating tracking results from the collected data. For example, if a virtual thread triggers a probe when a method is called, the system will record the timestamp, entry, exit, execution time, and call stack information of the call as tracking results. The tracking results can be used to analyze and optimize the performance of the virtual threads.

Through the steps S251 to S252, the embodiment of the present application can dynamically instrumentation and track the virtual thread without restarting the process of the application program when the application program runs, so as to obtain high-precision virtual thread execution stream data. Based on the method, the embodiment of the application can directly promote deep understanding and quick positioning of the virtual thread performance problem, and can help developers and operation and maintenance personnel to analyze and optimize the concurrency performance of the application program more effectively and promote user experience especially in a large-scale distributed system and a micro-service architecture. In addition, based on the scheme, a new tool can be provided for a developer, so that the developer can know the running mechanism and performance bottleneck of the virtual thread more carefully, and the concurrent processing capacity of the application can be improved by utilizing the virtual thread better.

In an alternative embodiment, the configuration information further comprises at least one of:

the starting configuration information is used for representing the function of starting the pile inserting operation;

class configuration information, which is used for representing the class where the instrumentation operation is executed;

The position configuration information is used for indicating a pile inserting position corresponding to pile inserting operation;

policy configuration information, which is used for representing pile inserting policies corresponding to pile inserting operations;

the identification configuration information is associated with the pile inserting position and is used for identifying events occurring in the process of tracking the data of the application program;

behavior configuration information, which is used for representing the operation behavior corresponding to the target probe.

The start configuration information is used to indicate the function of starting the instrumentation operation, including when and how to start instrumentation. The start configuration information may be started by a specific command line parameter, or may be started by a specific API call when the program runs.

For example, a user may initiate instrumentation by commanding < jdk >/bin/java-jar rtinstr. Jar < pid > < myclass. Mymethod >, where < jdk >, < pid >, and < myclass mymethod > are all part of the initiation configuration information. Therefore, the embodiment of the application supports dynamic loading of the instrumentation without restarting the application program, and improves the efficiency and convenience of online debugging.

The class configuration information is used for indicating the class in which the instrumentation operation is performed, namely the Java class name of which the user wants to perform instrumentation. By specifying the class configuration information, the embodiment of the application can accurately perform instrumentation in the class of interest to the user without affecting other parts of the program, which provides high focusing and control force for the developer of the application program.

The location configuration information is used to indicate the instrumentation location corresponding to the instrumentation operation, i.e. at which stage of the Java method call the probe is inserted, and may be a Java method entry (call) location, a Java method exit (ret) location, or an entire Java method full flow (full). The position configuration information ensures the accuracy and depth of the pile, and a user can select the most suitable monitoring point according to the needs, so that the required data type and coverage are obtained.

The policy configuration information is used to indicate the instrumentation policy corresponding to the instrumentation operation, i.e. the specific implementation manner of the instrumentation, such as based on log information (Bwlog instrumentation policy) or based on JNI call (JNI instrumentation policy). Each pile inserting strategy has unique advantages and applicable scenes, and strategy configuration information enables a user to select between low overhead and high information degree in a balanced mode, so that the usability of tracking data is improved.

The identification configuration information is associated with the instrumentation location and is used for identifying events occurring in the process of tracking the data of the application program. The identification of the configuration information is achieved through user-defined tag parameters (tags). The tag parameter may be a hexadecimal number that is used to distinguish between different types of events, particularly when tracing nested or overlapping execution streams, the tag parameter helps ensure a clear identification and classification of events.

The behavior configuration information is used to indicate the corresponding operation behavior of the target probe, such as timing start (start), timing end (end), or mark. The behavior configuration information directs the probe to perform specific actions at different stages of program execution, ensuring the accuracy and integrity of the trace data.

In an exemplary application scenario, according to the instrumentation method of the application program, an API function definition corresponding to the instrumentation tool may be provided, and the API may be called to implement a flexible Java method-level instrumentation function, so as to support implementation of fine-grained runtime tracking through configuration instructions. The calling format of the API is expressed as: "

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

Target class method [ (type of) pile placement ] [ event name ] [ operation [ (tag) ] ]

[ Other class. Method. ] \is provided

[ Log Path ] \

[ Local library Path ] \

[ Unload option ] ".

The main configuration items of the above API are described below.

First, the basic call is to launch the instrumentation tool by specifying the JDK path, target Java process PID, and rtinstr. JAR, which encapsulates all instrumentation function implementations.

Second, the target method is configured to support simultaneous specification of multiple class methods (e.g., myClass. MyMethod), instrumentation location optional method entry (call), before each return point (ret), and full flow (full, inclusive of call and ret).

Thirdly, the type of the instrumentation strategy is Bwlog instrumentation strategy or JNI instrumentation strategy.

Fourthly, event tracking is that pile inserting points are named through event parameters, subsequent data aggregation analysis is facilitated, and percentile statistical data acquisition is supported.

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

Sixth, the extended configuration includes a 16-ary tag (tag) to distinguish between different execution flows, a custom log storage path (logpath), a specified local dependency library path (nativepath), and a restoration of original state (uninstall) by removing all instrumentation.

Based on the above API, a complete monitoring link from Java methods to system calls is achieved by Linux uprobe interfacing to the system level trace tool. Different types of instrumentation (Bwlog/JNI) are each characterized.

Through the definition and the use of the configuration information, the embodiment of the application realizes the dynamic instrumentation of the highly customized application program. The user can flexibly specify the starting conditions, target classes, the pile inserting positions, the pile inserting strategies and the identification and behavior definition of the tracking events, and the mechanism can widen the application scene of executing stream tracking, so that the tracking is not only limited to a single method, but also can cover the whole program execution link, and meanwhile, the capability of dynamically adjusting the pile inserting strategies ensures that the tracking process can adapt to the performance requirements in different environments, reduces the influence of the tracking on the application program, and improves the quality and reliability of the tracking data. Based on the customized instrumentation approach, a powerful tool can be provided for developers and operators to more finely understand and optimize the performance of applications, particularly in terms of processing complex multithreading and micro-service architectures, which can exhibit significant advantages.

In an alternative embodiment, the instrumentation method of the application program further comprises the following method steps after inserting the target probe at the instrumentation position:

In step S206, the target probe is used to execute the operation behavior corresponding to the behavior configuration information, so as to track and obtain the data generated by the application program at the code level and the data generated by the application program at the system level.

The target probe is a code segment or a function call inserted at a designated instrumentation location for capturing critical information during program execution. The target probe can be log information in a specific format, can also be a probe function, and the concrete expression form is determined by the pile-inserting strategy. In the Java application scenario, the target probe is designed to work cooperatively with a system level trace tool (such as Linux uprobe) to together complete the tracking of the Java program execution flow.

The behavior configuration information may refer to a instrumentation policy. The behavior configuration information includes a instrumentation location (call, ret, or full), an instrumentation mode (log or JNI), an event name (event), a timing action (action), a distinction flag (tag), and the like. In the Java application scenario, these behavior configuration information constitute an instruction set of how the target probe executes, determining when the probe triggers (start, end or mark) during execution of the Java method, and how to identify and sort the collected data.

The above-mentioned operation behavior refers to a specific operation performed by the target probe at the time of program execution based on behavior configuration information. For example, when using Bwlog instrumentation policies, the target probe may log at the start and end points of the method call, providing detailed time information for Java method calls and method call stack information. When the JNI call instrumentation policy is adopted, the target probe calls JNI functions predefined in a local file (such as library. So), and the JNI functions are used as probes to cooperate with a system level trace tool to capture performance data of a lower layer.

The trace data obtained by using the target probe to execute the operation behavior corresponding to the behavior configuration information can comprise two levels of data, namely code level execution flow data comprising the calling time, the calling sequence and the calling relation of a method, and system level performance data relating to events of an operating system layer, such as context switching and I/O operation cost. The tracking data is obtained by executing the operation behavior configured by the target probe, and provides key information for subsequent performance analysis and optimization.

Through the step S206, the embodiment of the present application realizes dynamic and fine granularity tracking of application program execution, and simultaneously considers data acquisition at both the code level and the system level. The tracking scheme can capture and record the calling time, calling link and dependent system resource consumption of program codes (such as Java methods) in the program execution process, so that a developer can not only know the performance of the program codes, but also can know the performance bottleneck (such as multithreading competition and I/O delay) of an operating system level. The comprehensive tracking data provides powerful support for performance optimization of application programs, and particularly in complex server-side applications (such as HTTP SERVER, web servers, micro services and the like), the method can help to locate and solve delay problems, and improves user experience. In addition, the dynamic performance of the scheme means that the pile inserting and tracking can be performed without restarting the application program, and the practicability of the scheme is enhanced.

In an alternative embodiment, in step S204, the program code is instrumented according to an instrumentation strategy to insert a target probe at an instrumentation location, comprising the following method steps:

Step S243, performing instrumentation operation on the program codes in the running process according to the instrumentation strategy so as to insert the target probe in the instrumentation position.

Based on the above alternative embodiment, during the running process of the application program, the program code is subject to the instrumentation operation according to the instrumentation strategy to insert the target probe at the instrumentation position, which represents the dynamic and non-invasive performance of the scheme, and is an important improvement over the static instrumentation technology in the related art.

In the Java application scene, the instrumentation operation is carried out according to the instrumentation strategy, and the system inserts probes in the appointed program code positions in real time according to the functions and rules configured by the user through the target interface. For example, if the user selects the first instrumentation policy (i.e., bwlog instrumentation policy), the system will insert log information in a particular format at the instrumentation location of the program code based on the application's log information, which records the beginning, ending, and marker points of the method call, providing an exhaustive execution flow trajectory. On the other hand, if the user selects the second instrumentation policy (JNI instrumentation policy), the system will insert probe functions pre-defined in a local file (such as library. So) at instrumentation locations based on the object type program code, thereby tracking the time and events of method calls.

It should be noted that, the instrumentation operation is performed on the program code in the running process, which is a key point of the dynamic instrumentation technology. While conventional instrumentation methods typically require the application to be recompiled and deployed after being modified, embodiments of the present application enable the bytecode to be dynamically modified while the application is running without restarting the process. Based on the method, developers or operation and maintenance personnel of the application program can instantly adjust and enable the instrumentation strategy without affecting the application service, and performance problems in the online environment can be monitored and analyzed in real time.

Through the step S243, the embodiment of the present application can dynamically and non-invasively perform execution flow tracking on the application program. By inserting the target probe as required when the application program runs, the time point and related data of the program code call can be captured in real time, and powerful support is provided for tracking the delay of the request, analyzing the multithreading competition, I/O delay and the like, regardless of the log-based instrumentation strategy or the JNI-based instrumentation strategy. That is, the step S243 directly provides a means for monitoring and analyzing the real-time performance of the application program, without undergoing a complicated restarting and deploying process, thereby improving the efficiency of on-line problem positioning and performance optimization.

In an alternative embodiment, in step S204, program code in the process of running is instrumented according to an instrumentation policy to insert a target probe at an instrumentation location, comprising the following method steps:

Step S244, determining target program codes of target probes;

step S245, calling a byte code modification tool according to the instrumentation strategy, and instrumentation is carried out on the program codes in the running process so as to insert target program codes in the instrumentation positions.

In the Java application scenario, the target probe refers to a code or a function inserted in a Java program for tracking a specific event or collecting runtime data. The target probe may take a variety of forms. The target probe may be log information in a specific format or may be a probe function according to different instrumentation strategies.

When the instrumentation policy selects Bwlog instrumentation policy for instrumentation based on log information, the target program code is a code segment for generating log information in a target format at a specified location. When the instrumentation policy selects a JNI instrumentation policy based on JNI calls, then the object code is a code fragment that calls the JNI function predefined in the local file (e.g., library. So). The selection and insertion of object code is performed dynamically according to a user-specified instrumentation policy, ensuring flexibility and low invasiveness of instrumentation operations.

The above-described bytecode modification tool refers to a tool capable of reading and modifying Java bytecodes. With the bytecode modification tool, even though a Java program has been compiled into bytecode, additional code can be dynamically inserted at runtime. Common bytecode modification tools have Javassist and Byte add, etc. Through the byte code modification tools, the embodiment of the application can modify the program code and insert the target probe under the condition of not restarting the Java process.

The program code in the running process refers to code being executed by the Java virtual machine, not code in the editing or compiling stage. Based on the above, the embodiment of the application can dynamically perform instrumentation operation on the codes under the condition of not interrupting program execution, which means that Java developers or operation and maintenance personnel can adjust instrumentation strategies in real time on the premise of not influencing application services, and the execution flow of the application is tracked in a fine manner.

According to step S244, the process of determining the target program code of the target probe is to analyze the specific positions of the Java class and Java method to be instrumented based on the configuration information provided by the user through the target interface. The system will determine what type of object code to insert based on the instrumentation policy.

According to step S245, the bytecode modification tool is invoked to instrumentation the program code in the process of running to insert the target program code at the instrumentation location according to the instrumentation policy. The process involves reading the bytecode of the Java class at run-time, dynamically modifying the bytecode according to the instrumentation policy, inserting the object probe code, and then reloading the modified bytecode into the Java virtual machine for execution.

Through the steps S244 to S245, the embodiment of the present application can dynamically instrumentation the program code without restarting the application program process. The user can flexibly select the instrumentation strategy, configure the instrumentation position and the probe type, and insert specific tracking codes into the program codes of the application program, so that the cost of on-line problem positioning is reduced, the execution flow is allowed to be analyzed in a fine manner, the execution cost and the performance bottleneck of the request can be more accurately understood particularly when complex multithreading and micro-service scenes are processed, and the stability and the user experience of the application are improved. In addition, the realization of dynamic instrumentation also avoids redundant codes and compatibility problems possibly brought by traditional static instrumentation, so that instrumentation strategies can be adjusted at any time according to requirements, and the practicability and flexibility of the scheme are improved.

In an alternative embodiment, in step S201, the program code to be instrumented is determined from the application program, comprising the following method steps:

In step S211, in response to the application running in the operating system, program code to be instrumented in the application is determined based on a request message, where the request message is used to request information of the application to be acquired and/or request the application to execute a task.

In the above alternative embodiments, the request message may be a request sent by the user to the Java virtual machine through a specific tool or command line, in order to obtain the running information of the application or request the application to perform a specific task. Such request messages typically contain information about the particular Java method or Java class that the user wishes to trace or analyze. For example, in a Java application scenario, when executing the command < jdk >/bin/Java-jar rtinstr. Jar < pid > < MyClass. Mymethod >, the < MyClass. Mymethod > is part of the request message, which is used to specify the program code to be instrumented. The format and content of the request message will vary depending on the particular application scenario and tool design. The request message is used as a trigger condition and a configuration basis for dynamic pile inserting operation.

The program code to be instrumented in the application is determined based on information contained in the request message. In particular, the program code refers to Java classes and Java methods in which a user wishes to insert probes or trace code. The flexibility of the dynamic instrumentation technique is that a user can specify instrumentation locations in any Java method, which means that regardless of the frequency or complexity of invocation of a Java method, the user can specify instrumentation locations for the Java method via a request message, so that the Java method can be monitored and analyzed in real time.

The dynamic instrumentation is a technique that modifies bytecode to insert trace or monitor code without restarting the process when the program is running. According to the above step S211, the triggering of the dynamic instrumentation is based on the precondition that the application program is running in the operating system. When the request message is received, the system executes the instrumentation operation in real time according to the program code location specified in the message. In a Java application scene, the process of executing the instrumentation operation utilizes Instrumentation API of a Java virtual machine, so that the instrumentation operation can be performed under the condition of not interrupting the service of an application program, and the efficiency of performance monitoring and problem positioning in an on-line environment is improved.

Through the step S211, the embodiment of the present application dynamically determines and posts the program code (such as Java class and Java method) to be monitored by responding to the running state of the application program and the received request message, thereby implementing real-time monitoring and tracking of the program code in the execution process of the application program. The above steps support the developer and operator of the application to instantly adjust and enable performance monitoring by sending a request message without restarting the application. The scheme not only reduces the cost of on-line problem positioning, but also allows the capturing of real application program behaviors under the actual load, thereby providing powerful support for performance optimization and fault detection. Particularly, for the scene requiring continuous operation and response request, the dynamic pile insertion can perform fine performance analysis on the premise of not interfering with normal service, so that the efficiency and the flexibility are greatly improved.

In an alternative embodiment, in step S211, in response to the application running in the operating system, program code to be instrumented in the application is determined based on the request message, comprising the method steps of:

Step S212, in response to the running of the application program in the operating system, identifying different types of request messages, wherein the different types of request messages are mutually independent;

in step S213, different program codes to be instrumented in the application program are determined in response to the different types of request messages, wherein the different program codes correspond to the different types of request messages.

In the above alternative embodiments, the different types of request messages may be custom probe type request messages, additional information type embedded request messages, and the like. The different types of request messages do not interfere with each other.

In the application scenario, the request message refers to information that is sent by the client to the server and includes an operation or a data request. These request messages may be of different types, e.g., HTTP requests, web service calls, database queries, etc. The processing logic and execution flow of each type of request message may be distinct.

Further, the system needs to dynamically identify and distinguish between different types of request messages as the application runs, i.e., in the operating system environment. The type of request message is identified based on the format, content, or context of the request message being sent. For example, for an HTTP request, the type of the HTTP request may be identified by parsing the method type (GET, POST, etc.) or URL in the request header, and for a micro-service request, the type of the micro-service request may be identified by an inter-service call protocol or message format.

The different types of request messages are independent from each other, that is, the different types of request messages are independent in processing and tracking, that is, the instrumentation code and strategy for processing one type of request message cannot influence other types of request messages, so that the accuracy and pertinence of tracking are ensured, and confusion and interference between execution flows of the different types of request messages are avoided.

Further, the system determines specific parts, i.e. different program codes, of the application program, which need to be instrumented according to different types of request messages. These different program codes refer to Java methods or Java classes that are responsible for handling the corresponding type of request message. For example, code that handles HTTP requests may be located in the request processor of the Web server, while code that handles database calls may be located in the database access interface layer.

Further, based on the type of request message and processing logic, different program code to be instrumented is determined. For each type of request message, the system identifies the program code most relevant to the request message and then applies dynamic instrumentation techniques to the program code to track the execution flow of the program code.

Through the steps S212 to S213, the embodiment of the present application can intelligently identify and distinguish different types of request messages when an application program runs, and accordingly determine and perform dynamic instrumentation of different program codes to be instrumented. This not only means that developers and operators can track the request execution flow fine-grained without modifying code or restarting applications, but also ensures independence and accuracy of each type of request message processing logic. The dynamic performance and pertinence obviously improve the efficiency and effect of executing flow tracking, particularly in the application scene of processing complex multithread and micro-service architecture, the performance bottleneck and the optimization point can be more accurately positioned, and the response speed and the user experience of the application program are improved. In addition, the intelligent request message type recognition capability enables the scheme to adapt to a wide application scene and a request mode, and the practicability and flexibility of the scheme are enhanced.

In an alternative embodiment, the instrumentation method of the application program further comprises at least one of the following method steps after inserting the target probe at the instrumentation position:

step S207, deleting the target probe from the application program after pile insertion to obtain the application program before pile insertion;

step S208, performing de-duplication operation on the plurality of target probes inserted in the pile inserting positions;

step S209, recording call stack information of the threads of the application program in the running process.

In the Java application scenario, based on the step S207, the target probe is deleted from the application program after instrumentation by using the dynamic bytecode modification capability of the Java virtual machine, thereby obtaining the application program before instrumentation. Specifically, when a user issues a instrumentation restore command 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 inserted before, and reload the restored bytecode into the Java virtual machine for execution. Based on the method, the embodiment of the application allows the user to dynamically recover the state before the pile is inserted under the condition that the application program is not required to be restarted, thereby avoiding the continuous influence of the performance overhead introduced by the pile insertion operation on the normal operation of the application program and improving the practicability and the flexibility of the embodiment of the application.

Based on the step S208, the deduplication operation is performed on the plurality of target probes inserted at the stake-inserting positions. In a Java application scenario, a user may specify instrumentation multiple times, perform instrumentation operations for the same Java method or different Java methods, and in particular, when tracing a complex execution stream, may insert the same target probe at multiple locations. The above-described deduplication operation for multiple target probes ensures that even if a user repeatedly specifies the same stake-in position and probe type, the system will only insert one probe, avoiding redundancy of codes and potential performance impact. Based on the above, the embodiment of the application not only improves the efficiency of pile inserting operation, but also ensures the accuracy of pile inserting and ensures the consistency and the effectiveness of tracking data. By probe de-duplication, the error and resource waste caused by repeated probe insertion during operation are avoided, and the performance of the dynamic pile is further optimized.

Based on the above step S209, call stack information of the thread of the application program in the running process is recorded. In the Java application scene, in the process of realizing the tracking function of the Java STACK TRACE tool, no matter whether the instrumentation strategy selects the first instrumentation strategy (Bwlog instrumentation strategy) or the second instrumentation strategy (JNI instrumentation strategy), the system records the call stack information, namely the method call path, when the Java method is called. For Bwlog instrumentation policy, the system adds call stack information in the output of the target probe, while for JNI instrumentation policy, although the probe itself does not directly output the call stack, embodiments of the present application may provide a mapping mechanism for generating and maintaining Java memory to symbols, so that a system level trace tool (such as Linux uprobe) may parse and record Java STACK TRACE according to the mapping mechanism. Based on this, the embodiment of the application provides necessary Java STACK TRACE information for trace tools at the system level, so that a developer can track the time cost of Java method call and can see a specific call path, which is helpful for understanding complex multi-thread interaction and execution flow links. By recording call stack information, the embodiment of the application improves the depth and precision of executing stream tracking, and ensures that the performance analysis is more detailed and comprehensive.

Through the steps S207 to S209, the embodiment of the application can further optimize the recovery, the deduplication and the call stack tracking functions of the instrumentation on the basis of dynamic instrumentation, and provides a powerful execution flow tracking tool for developers and operation and maintenance personnel of application programs. The state before the pile is inserted can be restored without restarting the application program, so that the influence of the continuous performance caused by pile insertion is avoided, and the efficiency and convenience of on-line problem positioning are improved. Pile insertion de-duplication ensures the accuracy and efficiency of pile insertion and avoids resource waste and operation errors caused by repeated probe insertion. The record of the call stack information deepens the understanding of the execution flow, so that the performance analysis can cover the details of the method call, and the capability of the scheme in tracking the complex execution flow is improved. Based on the method, the device and the system for dynamic pile inserting can further enhance flexibility, high efficiency and comprehensiveness of the dynamic pile inserting technology, and provide powerful support for performance optimization and problem solving of application programs.

In the foregoing operating environment, the present application also provides a instrumentation method of an application program as shown in fig. 3. FIG. 3 is a flow chart of another instrumentation method of an application applied to a tracking tool according to an embodiment of the present application, as shown in FIG. 3, the instrumentation method of the application includes:

Step S301, determining program codes to be instrumented from an application program, wherein the program codes are codes of an object-oriented programming language;

step S302, calling an application programming interface corresponding to an operating system, and determining a target probe configured for a program code, wherein the target probe is used for performing stream tracking on data generated on a code level and data generated on a system level of the application program in the running process of the operating system;

Step S303, determining a instrumentation position in the program code by using an application programming interface, and determining an instrumentation strategy corresponding to the target probe, wherein the instrumentation strategy is used for representing a rule for instrumentation operation on the program code;

step S304, performing instrumentation operation on the program codes according to the instrumentation strategy so as to insert the target probe in the instrumentation position;

in step S305, the data generated at the code level and the data generated at the system level by the application program are subjected to stream tracing by using the target probe inserted at the instrumentation position, and a tracing result is obtained.

The trace tool may be an execution flow trace tool (i.e., trace tool) of an application. That is, the execution flow tracking tool may perform instrumentation operation on the program code according to the instrumentation policy according to the instrumentation method of the application program, so as to insert the target probe at the instrumentation position. Further, the execution flow tracking tool performs flow tracking on data generated by the application program at the code level and data generated at the system level by using the target probe inserted at the instrumentation position, so as to obtain a tracking result.

In the embodiment of the application, program codes to be instrumented are determined from application programs, wherein the program codes are codes of an object-oriented programming language, an application programming interface corresponding to an operating system is called, target probes configured for the program codes are determined, the target probes are used for performing flow tracking on data generated by the application program on a code level and data generated by the application program on a system level in the running process of the operating system, instrumentation positions in the program codes are determined by using the application programming interface, instrumentation strategies corresponding to the target probes are determined, the instrumentation strategies are used for representing rules for instrumentation on the program codes, instrumentation is performed on the program codes according to the instrumentation strategies to insert the target probes into the instrumentation positions, and flow tracking is performed on data generated by the application program on the code level and data generated by the system level by using the target probes inserted into the instrumentation positions to obtain tracking results. Therefore, the embodiment of the application inserts the target probe into the program code running in the operating system in a mode of calling the target interface, in particular to the method and the device, which can determine the instrumentation position and the instrumentation strategy in the program code, achieves the aim of automatically instrumentation into the application program so as to support the execution flow tracking of the operating system level, achieves the technical effects of improving the code instrumentation efficiency in the application program and facilitating the execution flow tracking of the application program in the operating system level, and further solves the technical problem that the efficiency is lower because the code instrumentation is manually conducted to the application program in the related technology. Further, based on an efficient code instrumentation mode, stream tracking is performed on data generated on a code level of an application program and data generated on a system level, so that timeliness and accuracy of a tracking result are improved.

It should be noted that, the above preferred embodiments of step S301 to step S305 can be referred to the above related description, and will not be repeated here.

In the foregoing operating environment, the present application also provides another method for instrumentation of an application program as shown in fig. 4. FIG. 4 is a flowchart of another instrumentation method of an application program according to an embodiment of the present application, as shown in FIG. 4, the instrumentation method of the application program includes:

step S401, acquiring a program code to be instrumented in an application program by calling a first interface, wherein the first interface comprises a first parameter, and a parameter value of the first parameter comprises the program code;

Step S402, a target interface corresponding to an operating system is called, and a target probe configured by a program code is determined, wherein the target probe is used for tracking data generated by an application program in the running process of the operating system;

step S403, determining a instrumentation position in the program code by using the target interface, and determining an instrumentation policy corresponding to the target probe, wherein the instrumentation policy is used for representing a rule for instrumentation operation on the program code;

Step S404, performing instrumentation operation on the program codes according to the instrumentation strategy so as to insert the target probe in the instrumentation position;

step S405, outputting the instrumented program code by calling a second interface, where the second interface includes a second parameter, and a parameter value of the second parameter includes the instrumented program code.

The instrumentation method of the application program can be operated in the cloud server, and instrumentation cloud service of the application program is provided for the client. The client calls the first interface to send the instrumentation request of the application program, and the cloud server obtains the program codes to be instrumented in the application program corresponding to the instrumentation request of the application program through the first interface, generates the instrumented program codes according to the instrumentation method of the application program, and further returns the instrumented program codes to the client through the second interface.

The first interface and the second interface may be the same interface or different interfaces. In an alternative 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 signing key, an interface timestamp, an interface request identifier, a system call credential identifier, and the like. The first interface may acquire the file processing request using an acquire request (GET) or a submit request (POST) as an interface request manner. The second interface may process the response using a lightweight data exchange format (e.g., javaScript Object Notation format, JSON format for short) feedback file.

In the embodiment of the application, in response to the running of an application program in an operating system, a program code to be instrumented in the application program is obtained by calling a first interface, wherein the first interface comprises a first parameter, a parameter value of the first parameter comprises 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 for tracking data generated by the application program in the running process of the operating system, determining an instrumented position in the program code by using the target interface and determining an instrumented strategy corresponding to the target probe, wherein the instrumented strategy is used for representing a rule for instrumented operation on the program code, instrumented operation is performed on the program code according to the instrumented strategy so as to insert the target probe in the instrumented position, and the second interface is called to output the instrumented program code, wherein the second interface comprises a second parameter, and the parameter value of the second parameter comprises the instrumented program code. Therefore, the embodiment of the application inserts the target probe into the program code running in the operating system in a mode of calling the target interface, in particular to the method and the device, which can determine the instrumentation position and the instrumentation strategy in the program code, achieves the aim of automatically instrumentation into the application program so as to support the execution flow tracking of the operating system level, achieves the technical effects of improving the code instrumentation efficiency in the application program and facilitating the execution flow tracking of the application program in the operating system level, and further solves the technical problem that the efficiency is lower because the code instrumentation is manually conducted to the application program in the related technology.

It should be noted that, the above preferred embodiments of step S401 to step S405 may be referred to the above related descriptions, and are not repeated here.

It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region, and provide corresponding operation entries for the user to select authorization or rejection.

It should be noted that, for simplicity of description, the foregoing method embodiments are all described as a series of acts, but it should be understood by those skilled in the art that the present application is not limited by the order of acts described, as some steps may be performed in other orders or concurrently in accordance with the present application. Further, those skilled in the art will also appreciate that the embodiments described in the specification are all preferred embodiments, and that the acts and modules referred to are not necessarily required for the present application.

From the description of the above embodiments, it will be clear to a person skilled in the art that the method according to the above embodiments may be implemented by means of software plus a necessary general hardware platform, but that it may also be implemented by means of hardware. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. Read-Only Memory (ROM), random access Memory (Random Access Memory, RAM), magnetic disk, optical disk), comprising instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method according to the embodiments of the present application.

According to the embodiment of the application, an embodiment of a device for implementing the pile inserting method of the application program is also provided. Fig. 5 is a schematic structural diagram of an instrumentation device of an application program according to an embodiment of the present application, as shown in fig. 5, where the instrumentation device includes a first determining module 501 configured to determine a program code to be instrumented from the application program, a second determining module 502 configured to call a target interface corresponding to an operating system, determine a target probe configured to the program code, where the target probe is configured to track data generated by the application program during an operation process of the operating system, and determine an instrumentation policy corresponding to the target probe by using the target interface, where the instrumentation policy is configured to indicate a rule for performing an instrumentation operation on the program code, and an instrumentation module 504 configured to perform an instrumentation operation on the program code according to the instrumentation policy, so as to insert the target probe at the instrumentation location.

Optionally, the third determining module 503 is further configured to determine a set of instrumentation positions by using the target interface, where different program codes correspond to different instrumentation positions in the set of instrumentation positions, and determine the instrumentation positions corresponding to the program codes in the set of instrumentation positions by using the target interface.

Optionally, the third determining module 503 is further configured to obtain configuration information of the target interface, where the configuration information is used to describe a function configured for the target interface, the function is associated with a instrumentation operation, and determine an instrumentation policy from the configuration information.

Optionally, the third determining module 503 is further configured to select, in response to the policy selection operation, a first instrumentation policy or a second instrumentation policy from the configuration information, where the first instrumentation policy is used to represent a rule for performing an instrumentation operation on the program code based on log information of the application program, and the second instrumentation policy is used to represent a rule for performing an instrumentation operation on the program code based on a target type of program code, and the target type is other types than the type of the program code.

Optionally, the target probe may be expressed in a form including log information or probe functions in a target format, and the instrumentation module 504 may be further configured to 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 location in response to the instrumentation policy being a first instrumentation policy, and perform an instrumentation operation on the program code based on the target type program code to insert the probe functions at the instrumentation location in response to the instrumentation policy being a second instrumentation policy.

Optionally, the instrumentation device of the application program further comprises a tracking module (not shown in the figure) for identifying the virtual thread corresponding to the program code to obtain the identification information of the virtual thread in response to the instrumentation policy being the first instrumentation policy, and tracking the virtual thread by using the identification information and the target probe to obtain the tracking result of the virtual thread.

Optionally, in the instrumentation device of the application program, the configuration information further comprises at least one of starting configuration information for indicating a function of starting the instrumentation operation, class configuration information for indicating a class in which the instrumentation operation is performed, position configuration information for indicating an instrumentation position corresponding to the instrumentation operation, policy configuration information for indicating an instrumentation policy corresponding to the instrumentation operation, identification configuration information associated with the instrumentation position and used for identifying an event occurring in the process of tracking data of the application program, and behavior configuration information for indicating an operation behavior corresponding to the target probe.

Optionally, the instrumentation device of the application program further comprises an execution module (not shown in the figure) for executing the operation behavior corresponding to the behavior configuration information by using the target probe after inserting the target probe at the instrumentation position, so as to track and obtain the data generated by the application program at the code level and the data generated by the application program at the system level.

Optionally, the instrumentation module 504 is further configured to perform an instrumentation operation on the program code in the running process according to an instrumentation policy, so as to insert the target probe at the instrumentation location.

Optionally, the instrumentation module 504 is further configured to determine the target program code of the target probe, and invoke the bytecode modification tool according to the instrumentation policy to instrumentation the program code in the running process to insert the target program code in the instrumentation location.

Optionally, the first determining module 501 is further configured to determine, in response to the application running in the operating system, program code to be instrumented in the application based on a request message, where the request message is used to request information of the application to be obtained and/or request the application to perform a task.

Optionally, the first determining module 501 is further configured to identify different types of request messages in response to the application running in the operating system, where the different types of request messages are independent of each other, and determine different program codes to be instrumented in the application in response to the different types of request messages, where the different program codes correspond to the different types of request messages.

Optionally, the instrumentation device of the application program comprises all the modules, and further comprises a processing module (not shown in the figure) for deleting the target probe in the application program after instrumentation to obtain the application program before instrumentation, performing de-duplication operation on the multiple target probes inserted in the instrumentation position, and recording call stack information of the threads of the application program in the running process.

It should be noted that, the first determining module 501, the second determining module 502, the third determining module 503, and the pile inserting module 504 correspond to steps S201 to S204 in the embodiment, and the four modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to those disclosed in the foregoing embodiments.

According to the embodiment of the application, another device embodiment for implementing the pile-inserting method of the application program is also provided. Fig. 6 is a schematic structural diagram of another instrumentation device of an application program according to an embodiment of the present application, as shown in fig. 6, where the instrumentation device includes a first determining module 601 configured to determine a program code to be instrumented from the application program, where the program code is a code of an object-oriented programming language, a second determining module 602 configured to call an application programming interface corresponding to an operating system, determine a target probe configured to the program code, where the target probe is configured to perform flow tracking on data generated at a code level and data generated at a system level by the application program during operation of the operating system, and a third determining module 603 configured to determine an instrumentation position in the program code by using the application programming interface, and determine an instrumentation policy corresponding to the target probe, where the instrumentation policy is used to represent a rule for instrumentation operation on the program code, and an instrumentation module 604 configured to perform instrumentation operation on the program code according to the instrumentation policy to insert the target probe at the instrumentation position, and a tracking module 605 configured to perform tracking result on the data generated at the system level and the data generated at the system level by using the target probe inserted at the instrumentation position.

It should be noted that, the first determining module 601, the second determining module 602, the third determining module 603, the pile inserting module 604 and the tracking module 605 correspond to the steps S301 to S305 in the embodiment, and the five modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the disclosure of the foregoing embodiments.

According to the embodiment of the application, a device embodiment for implementing the pile-inserting method of the application program is also provided. Fig. 7 is a schematic structural diagram of a instrumentation device of another application program according to an embodiment of the present application, as shown in fig. 7, where the instrumentation device includes an acquisition module 701 configured to acquire a program code to be instrumented in the application program by calling a first interface, where the first interface includes a first parameter, a parameter value of the first parameter includes the program code, a first determination module 702 configured to call a target interface corresponding to an operating system, determine a target probe configured to the program code, where the target probe is configured to track data generated by the application program during an operation process of the operating system, a second determination module 703 configured to determine an instrumentation position in the program code by using the target interface, and determine an instrumentation policy corresponding to the target probe, where the instrumentation policy is used to indicate a rule for performing an instrumentation operation on the program code, an instrumentation module 704 configured to perform an instrumentation operation on the program code according to the instrumentation policy, and an output module 705 configured to output the instrumented program code by calling a second interface, where the second interface includes a second parameter, and the parameter value of the second parameter includes the instrumented program code.

Here, it should be noted that the above-mentioned obtaining module 701, the first determining module 702, the second determining module 703, the pile inserting module 704, and the output module 705 correspond to steps S401 to S405 in the embodiment, and the five modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the disclosure of the foregoing embodiments.

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, or the above modules may be run in a computer terminal as part of an apparatus.

It should be noted that, the preferred implementation manner of this embodiment may refer to the related descriptions in the foregoing embodiments, which are not repeated herein.

It should be noted that, the preferred embodiments of the present application in the foregoing examples are the same as the schemes, application scenarios and implementation processes provided in the foregoing examples, but are not limited to the schemes provided in the foregoing examples.

Embodiments of the present application may provide a instrumentation system for an application. Fig. 8 is a block diagram of a instrumentation system of an application according to an embodiment of the present application. As shown in fig. 8, the instrumentation system of an application program includes a client 801 and a server 802.

The client 801 sends a request message, where the request message is used to request to acquire information of an application program and/or request the application program to execute a task;

The method comprises the steps of determining program codes to be instrumented in an application program based on a request message, calling a target interface corresponding to an operating system to determine a target probe configured for the program codes, wherein the target probe is used for tracking data generated by the application program in the running process of the operating system, determining the instrumentation position in the program codes by using the target interface, determining an instrumentation strategy corresponding to the target probe, wherein the instrumentation strategy is used for representing rules for instrumentation operation of the program codes, and performing instrumentation operation on the program codes according to the instrumentation strategy so as to insert the target probe in the instrumentation position.

The embodiment of the application can provide electronic equipment which comprises a memory and a processor, wherein the memory stores an executable program, and the processor is used for running the program, wherein the program runs to execute the instrumentation method of any application program.

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

The above-mentioned electronic device may be understood as an integrated intelligent terminal, including, but not limited to, a server, a desktop computer, a personal computer (Personal Computer, abbreviated as PC), a model all-in-one machine, etc., and the electronic device may be preset with the model described in the above-mentioned embodiment of the present application.

In particular, the electronic device may preset various types of models, including, but not limited to, models in the fields of natural language processing, visual processing, speech processing, code processing, multi-modal task processing, etc., to provide diversified model selections. In different product forms, the electronic device may support one or more model usage patterns including, but not limited to, model training, model invocation, model tuning, model deployment, model reasoning, and applications, etc. In some product forms, the electronic device also supports model management, including, but not limited to, multi-type model management (management of multiple types of models supporting discriminant, generative, etc.), model version control (control supporting different model versions), model evaluation (evaluating performance and effect of models based on model evaluation tools), and the like. In other product forms, the electronic device can also create an application based on the model, provide an application programming interface (Application Programming Interface, abbreviated as API) calling capability, call the model into the created application through the API interface, and provide an application management tool to manage and monitor the application.

Further, the electronic device may further include data management (supporting creation and management of a model tuning data set), a training center (providing rich training resources, helping users learn and master artificial intelligence (ARTIFICIAL INTELLIGENCE, abbreviated as AI) technology), basic control capability (providing enterprise-level basic control capability, ensuring safety and efficient operation of the system), and through the above functions, a comprehensive and integrated AI development, training, deployment and application device is provided.

The memory may be used to store software programs and modules, such as program instructions/modules corresponding to the instrumentation method and apparatus of the application program in the embodiments of the present application, and the processor executes the software programs and modules stored in the memory, thereby executing various functional applications and data processing, that is, implementing the instrumentation method of the application program in the embodiments described above. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory may further include memory remotely located with respect to the processor, which may be connected to terminal a through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

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

It will be appreciated by those skilled in the art that the structure shown in fig. 9 is merely schematic, and the electronic device may also be a terminal device such as a smart phone (e.g. an Android phone, an iOS phone, etc.), a tablet computer, a palm computer, and a Mobile internet device (Mobile INTERNET DEVICES, abbreviated as MID). Fig. 9 does not limit the structure of the electronic device. For example, the electronic device 90 may also include more or fewer components (e.g., network interfaces, display devices, etc.) than shown in FIG. 9, or have a different configuration than shown in FIG. 9.

It will be appreciated by those skilled in the art that all or part of the steps in the instrumentation method of the various application programs of the above embodiments may be implemented by a program for instructing hardware associated with a terminal device, and the program may be stored in a computer readable storage medium, where the storage medium may include a flash disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory RAM), a magnetic disk, or an optical disk.

Embodiments of the present application also provide a computer-readable storage medium. Optionally, in this embodiment, the computer readable storage medium includes a stored executable program, where the executable program controls a device in which the computer readable storage medium is located to execute the instrumentation method of the application program of any one of the foregoing items.

Alternatively, in the present embodiment, the storage medium described above may be located in an electronic device.

Optionally, in this embodiment, the computer readable storage medium is configured to store an executable program, and when the executable program runs, control a device in which the computer readable storage medium is located to execute the instrumentation method of the application program according to any one of the foregoing embodiments.

Embodiments of the present application also provide a computer program product. Alternatively, in this embodiment, the computer program product may include a computer program that, when executed by a processor, implements the instrumentation method of the application program provided in the embodiment above.

Embodiments of the present application also provide a computer program product. Alternatively, the computer program product may include a non-volatile computer readable storage medium, where the non-volatile computer readable storage medium may be used to store a computer program, where the computer program when executed by a processor implements the instrumentation method of the application program provided by the above embodiment.

Embodiments of the present application also provide a computer program. Optionally, in this embodiment, the foregoing computer program, when executed by a processor, implements the instrumentation method of the application program provided in the foregoing embodiment.

In the foregoing embodiments of the present application, the descriptions of the embodiments are emphasized, and for a portion of this disclosure that is not described in detail in this embodiment, reference is made to the related descriptions of other embodiments.

In the several embodiments provided in the present application, it should be understood that the disclosed technology may be implemented in other manners. The above-described embodiments of the apparatus are merely exemplary, and the division of the units, such as the above, is merely a logical function division, and may be implemented in another manner, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interfaces, units or modules, or may be in electrical or other forms.

The units described above as separate components may or may not be physically separate, and components shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units described above, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or partly in the form of a software product, or all or part of the technical solution, which is stored in a storage medium, and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the instrumentation method of the application program according to the embodiments of the present application. The storage medium includes various media capable of storing program codes such as a U disk, a ROM, a RAM, a mobile hard disk, a magnetic disk or an optical disk.

The foregoing is merely a preferred embodiment of the present application and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the principles of the present application, which are intended to be comprehended within the scope of the present application.

Claims

1. A method for instrumenting an application, comprising:

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, further comprising:

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, wherein determining the instrumentation strategy from the configuration information comprises:

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, wherein the target probe is expressed in a target format, log information or a probe function, and the program code is instrumented according to the instrumentation strategy to insert the target probe at the instrumentation location, comprising:

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, further comprising:

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, wherein the configuration information further comprises 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 into the insertion position, the method further comprises:

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, wherein the step of inserting the target probe at the insertion position into the program code in the running process according to the insertion strategy comprises:

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, wherein determining the program code to be instrumented from the application comprises:

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, wherein, in response to the application running in the operating system, determining the program code to be instrumented in the application based on a request message comprises:

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 comprises 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 it is applied to a tracking tool, comprising:

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;

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, comprising:

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;

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;

14. An application instrumentation system, comprising:

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, comprising:

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, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements the method according to any one of claims 1 to 13.