Method for obtaining operation information of application program and related equipment
By performing performance analysis in kernel space using the eBPF virtual machine and combining it with the collector to analyze application operation information in user space, the limitations of existing performance analysis technologies in terms of scalability and security are resolved, achieving efficient and secure performance analysis.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-04-11
- Publication Date
- 2026-03-10
AI Technical Summary
Existing technologies for adding performance analysis features to applications are inflexible when directly accessing the source code, while using Java proxies to inject performance analysis code poses potential risks, is not efficient in terms of scalability, and lacks sufficient security.
The extended Berkeley Packet Filter (eBPF) virtual machine runs in kernel space. By obtaining thread data and stack trace results, and combining them with the collector, it analyzes the operational information of the performance analysis application in user space, thus achieving efficient performance analysis.
It enables performance analysis of multiple applications without modifying kernel source code or injecting user-space code, reducing memory consumption and being independent of the JVM, thus improving analysis efficiency and security.
Smart Images
Figure CN121646764A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of this application relate to the field of information technology, and more specifically, to a method and related apparatus for obtaining application operation information. Background Technology
[0002] Performance analysis is an essential part of any large system, including those in the cloud. It helps estimate the efficiency of different parts of the system, identify performance regressions and their root causes, and discover and optimize inefficient algorithms.
[0003] Continuous profiling is a technique for monitoring and analyzing system performance. Instead of attempting to simulate a production environment and create user service request flows, continuous profiling collects and analyzes performance data while the system is running. In other words, performance analysis can be performed directly in the production environment.
[0004] Currently, there are two methods to add profiling features to an application. The first method is to directly access the application's source code, and the second method is to use a Java agent to inject profiling code into the process. The first method (direct access to the source code) is not always feasible and does not scale well with the number of services. The second method (injecting profiling code using a Java agent) is faster, but it has potential risks, such as introducing errors if the new code is not implemented correctly. Summary of the Invention
[0005] Embodiments of this application provide a method and related apparatus for obtaining operational information. This application provides an efficient solution for obtaining operational information of an application.
[0006] According to a first aspect, one embodiment of this application provides a method for obtaining operational information, the method comprising: when a stream transformation method in a performance analysis application is triggered, obtaining thread data from an extended Berkeley packet filter (eBPF) virtual machine (VM) running in kernel space, wherein the first thread data includes N entries, each of the N entries corresponding to a method in the performance analysis application, the N entries including a first entry corresponding to the triggered stream transformation method, and N being a positive integer greater than 1; the eBPF VM determining a target method based on the thread data, wherein the target method is invoked by the triggered stream transformation method; the eBPF VM performing performance analysis on the performance analysis application to obtain stack trace results, wherein the stack trace results include multiple entries, each of the multiple entries corresponding to multiple methods, the multiple entries including a second entry corresponding to the target method; and a collector running in user space obtaining data from the eBPF. The VM obtains the thread data and the stack trace results; the collector determines the operation information of the performance analysis application based on the thread data and the stack trace results.
[0007] According to the above technical solution, the eBPF VM can perform performance analysis on the performance analysis application within the kernel space. Besides the performance analysis application, the eBPF VM can also obtain thread data and stack trace results from other applications. In other words, the performance analysis application is one of multiple applications that can be performance analyzed by the eBPF VM. The eBPF VM and collector can obtain operational information for any type of application without requiring specific adjustments for each application. The eBPF VM can be loaded into the kernel space once to perform performance analysis on multiple applications, and memory can be occupied only once per host / VM rather than per process. No code is injected into the performance analysis application and / or its user space, thus preventing any damage due to code injection. Furthermore, call stack collection is independent of the JVM because the stack trace results and thread data are obtained by the eBPF VM.
[0008] In one possible implementation of the first aspect, before the collector determines the operation information of the performance analysis application based on the thread data and the stack trace result, the method further includes: the eBPF VM obtaining identification information of the thread data and identification information of the stack trace result; the collector obtaining the identification information of the thread data and the identification information of the stack trace result from the eBPF VM; and the collector determining the thread data and the stack trace result corresponding to the performance analysis application based on the identification information of the thread data and the identification information of the stack trace result.
[0009] In one possible implementation of the first aspect, the collector determining the operation information of the performance analysis application based on the thread data and the stack trace results includes: the collector determining the first entry from the thread data; the collector determining the second entry from the stack trace results; and the collector determining the operation information of the performance analysis application based on the first entry, the second entry, and the thread data.
[0010] In one possible implementation of the first aspect, the collector determining the operation information of the performance analysis application based on the first entry, the second entry, and the thread data includes: the collector replacing the first entry with method information obtained from the second entry to obtain a first call stack; and the collector determining the operation information of the performance analysis application based on the first call stack.
[0011] In one possible implementation of the first aspect, the collector determining the operation information of the target process based on the first call stack includes: the collector determining whether the first call stack is the same as a second call stack obtained according to the performance analysis application, wherein the call stack is determined before the first call stack; when the first call stack is the same as the second call stack, the collector determines the operation information of the target process based on one of the first call stack or the second call stack.
[0012] In one possible implementation of the first aspect, the operational information is one of a flame diagram, a heat map, or an icicle diagram.
[0013] According to a second aspect, one embodiment of this application provides an electronic device having the function of implementing the method described in the first aspect. The function can be implemented by hardware or by hardware executing corresponding software. The hardware corresponding to the software includes one or more modules corresponding to the function.
[0014] According to a third aspect, one embodiment of this application provides a computer-readable storage medium including instructions. When the instructions are executed on an electronic device, they cause the electronic device to perform the method described in the first aspect or any possible implementation thereof.
[0015] According to a fourth aspect, one embodiment of this application provides an electronic device including a processor and a memory. The processor is connected to the memory. The memory is used to store instructions, and the processor is used to execute the instructions. When the processor executes the instructions stored in the memory, the processor performs the method of the first aspect or any possible implementation thereof.
[0016] According to a fifth aspect, one embodiment of this application provides a computer cluster. The computer cluster includes at least one computer. The computer includes one or more processors and memory coupled to the one or more processors. The memory is used to store instructions. When the instructions are executed by the one or more processors, the at least one computer performs the method described in the first aspect or any possible implementation of the first aspect.
[0017] According to a sixth aspect, one embodiment of this application provides a computer program product, wherein when the computer program product is run on an electronic device, the electronic device causes the electronic device to perform the method described in the first aspect or any possible implementation thereof. Attached Figure Description
[0018] Figure 1 A schematic diagram of eBPF is shown.
[0019] Figure 2 Methods for obtaining operational information provided by some embodiments of this application are illustrated.
[0020] Figure 3 These are schematic block diagrams of electronic devices provided in some embodiments of this application.
[0021] Figure 4 These are schematic block diagrams of electronic devices provided in some embodiments of this application.
[0022] Figure 5 This is a schematic diagram of the structure of a computer cluster provided in some embodiments of this application. Detailed Implementation
[0023] The technical solutions in this application are described below with reference to the accompanying drawings.
[0024] The embodiments of this application do not limit the programming language. For example, the programming language can be Java, Python, C, etc. However, for convenience, the embodiments of this application use Java and the Java Virtual Machine (JVM) for description.
[0025] In computer programming, both methods and functions are used to perform specific operations or accomplish specific tasks. Depending on the programming paradigm, programming language, and the organization of the required functions and code, one can choose either a method or a function. The distinction between methods and functions does not affect the technical solutions outlined in this application. In the embodiments of this application, the terms "method" and "function" can be used interchangeably. The embodiments primarily use methods for illustration, but the term "method" can be replaced by "function".
[0026] This application provides a method for obtaining process operation information. Based on the embodiments provided in this application, process performance analysis can be performed efficiently with less memory consumption. The embodiments provided in this application are based on the extended Berkeley packet filter (eBPF) technology. Typically, adding new functionality to the kernel space requires modifying the kernel source code or developing kernel modules. However, eBPF allows programs to run without modifying the kernel source code or adding additional kernel modules.
[0027] Figure 1 A schematic diagram of eBPF is shown.
[0028] like Figure 1 As shown, eBPF can consist of two parts: a user-space program and a kernel-space program. The user-space program is used to load the eBPF bytecode into kernel space. Once the eBPF bytecode is loaded into kernel space, it is verified by the eBPF verifier to confirm its security. This verification process ensures that the eBPF bytecode is not corrupted. After verifying the eBPF bytecode, the eBPF virtual machine (VM) can execute it. eBPF mapping can be used to transfer data collected by the eBPF VM executing the eBPF bytecode to user space via system calls.
[0029] Figure 2 Methods for obtaining operational information provided by some embodiments of this application are illustrated.
[0030] 201: When a stream transformation method in a performance analysis application is triggered, the eBPF VM obtains thread data.
[0031] A stream transformation method refers to a method that can convert a stream (also known as an "execution stream") into an asynchronous method. The stream transformation method and the method called by the stream transformation method (hereinafter referred to as the "target method") can be executed asynchronously. For example, the stream transformation method and the target method can be executed by different cores of a processor. Stream transformation methods can include filter(), map(), block(), checkpoint(), flatMap(), repeat(), zip(), etc.
[0032] Thread data can include N entries, where N is a positive integer greater than 1. Each of the N entries corresponds to a method in the performance analysis application. The N entries include a first entry, which corresponds to the triggered stream transformation method.
[0033] For example, suppose the performance analysis application is an HTTP service that handles any arbitrary request. The code for the HTTP service is as follows: @GetMapping(" / v1 / process / ") public Mono <string>processRequest(RequestData request) { return Flux.just(request) .filter(this::validateRequest) .filter(this::complicatedAndSlowRequestValidation) .map(this::convertRequest) .map(this::processInternalRequest); } Table 1 shows the thread data obtained by the eBPF VM.
[0034] Table 1
[0035] The thread data shown in Table 1 includes three entries. Entry 0 corresponds to the method "filter()" in the performance analysis application, entry 1 corresponds to the method "processRequest" in the performance analysis application, and entry 2 corresponds to the state indicating that the performance analysis application has been started.
[0036] Taking the JVM as an example, the eBPF VM can parse data within the JVM to find the current method name and its caller. The eBPF VM can then continue this process until the entire stack is collected.
[0037] Each of the N entries may include the method operation status of the corresponding method. In some embodiments, the method operation status may include the name of the method. Taking the thread data shown in Table 1 as an example, entry 0 includes the name of the method "filter()", i.e., "filter", and entry 1 includes the name of the method "processRequest", i.e., "processRequest".
[0038] In other embodiments, the method operation state of the corresponding method may also include some additional information. For example, the method operation state of the corresponding method may include the context of the corresponding method, the parameters of the corresponding method, and the variable information of the corresponding method (e.g., local variables).
[0039] For convenience, in the following embodiments, it is assumed that the method operation state of the corresponding method only includes the name of the corresponding method.
[0040] 202: The eBPF VM determines the target method based on thread data.
[0041] The target method is the method invoked by the triggered stream conversion method. As mentioned above, the method invoked by the stream conversion method (i.e., the "target method") can be executed asynchronously. Therefore, the target method may be converted to a different stream, and the state of the target method may not be obtained in the same way as thread data.
[0042] Taking an HTTP service as an example, there are two streams: the first stream and the second stream. The first stream includes the initial methods of the performance analysis application (i.e., the HTTP service), which are methods that transform from the first method (i.e., "processRequest") to the first stream transformation method (i.e., "filter()"). The second stream includes the method called by the filter() method, namely the validateRequest method. The eBPF VM can trace the first stream to obtain thread data as shown in Table 1. However, the eBPF VM cannot trace the validateRequest method because it belongs to the second stream, not the first stream. In addition to the first and second streams, multiple streams can be processed, and the eBPF VM cannot directly locate the second stream. In this case, the eBPF VM can execute step 203 to obtain the state of the target method (i.e., the validateRequest method).
[0043] 203: The eBPF VM performs performance analysis on the application to obtain stack trace results.
[0044] In some embodiments, the eBPF VM can periodically perform performance analysis on a performance analysis application to collect one or more call stacks. The performance analysis frequency can be 5 Hz, 10 Hz, 15 Hz, 20 Hz, etc. Assuming the performance analysis frequency is 10 Hz, in this case, the eBPF VM can execute 10 times per second in kernel space to collect call stacks. The eBPF VM can collect 9, 10, or 11 call stacks. Each call stack in the call stack can include one or more entries, each of which corresponds to a method. One call stack in the call stack includes an entry corresponding to the target method; this call stack can be called the stack trace result or the target call stack. The eBPF VM can obtain the stack trace result from the collected call stacks based on the target method. The stack trace result can include multiple entries, each corresponding to a specific method. The stack trace result includes an entry corresponding to the target method. For convenience, the entry corresponding to the target method can be called the second entry.
[0045] Each of the multiple entries includes the method operation status of the corresponding method. For example, the method operation status may include at least one of the following: the name of the corresponding method, the parameters of the corresponding method, and the variable information of the corresponding method (e.g., local variables).
[0046] Taking HTTP service as an example, the eBPF VM can obtain the stack trace results shown in Table 2: Table 2
[0047] Table 2 shows the stack trace results, which include four entries. Entry 0 corresponds to the method validateRequest, entry 1 corresponds to the method Next, entry 2 corresponds to the method Switch, and entry 3 corresponds to the method OnSubscribe.
[0048] As shown in Table 2, the methods corresponding to the entries in the stack trace results belong to different applications. Therefore, the stack trace results do not reflect the operation information of a specific application, and can be called meaningless results or meaningless call stacks. Similar to the stack trace results, other call stacks collected by the eBPF VM may also be meaningless call stacks.
[0049] 204: Collectors running in user space can obtain thread data and stack trace results from the eBPF VM.
[0050] For example, the eBPF VM can forward thread data and stack trace results to the collector running in user space via eBPF mappings. In some embodiments, the eBPF VM can forward thread data and stack trace results to the collector simultaneously. In other embodiments, the eBPF VM can forward thread data and stack trace results to the collector separately.
[0051] In some embodiments, thread data and stack trace results may be forwarded together to the collector. In other embodiments, thread data and stack trace results may be forwarded to the collector separately.
[0052] 205: The collector can determine the operational information of the performance analysis application based on thread data and stack trace results.
[0053] In some embodiments, the collector (also known as a "call stack collector") may obtain only one thread data and the corresponding stack trace result for that thread data. In this case, the collector can determine operation information based on the obtained thread data and the corresponding stack trace result.
[0054] In other embodiments, the collector can obtain multiple thread data sets, which can be obtained from different applications. Each thread data set has a corresponding stack trace result. In this case, the collector can also obtain multiple stack trace results. The collector can then establish a relationship between the obtained thread data sets and the stack trace results. In other words, the collector can determine the stack trace results and their corresponding thread data. The collector can then determine operational information based on the stack trace results and their corresponding thread data.
[0055] For convenience, the stack trace result of the performance analysis application can be referred to as the first stack trace result, and the thread data of the performance analysis application can be referred to as the first thread data. Based on the above, the collector can determine the first thread trace result from multiple thread trace results and the first stack trace result from multiple stack trace results. To achieve this, the eBPF VM can also obtain the identification information of the thread data and the identification information of the stack trace result. For convenience, the identification information of the first thread data can be referred to as the first ID information, and the identification information of the first stack trace result can be referred to as the second ID information. For example, the eBPF VM can use the Berkeley packet filter (BPF) helper function bpf_get_current_pid_tgid() to obtain the first ID information and the second ID information. The eBPF VM can then forward the first ID information and the second ID information to the collector. bpf_get_current_pid_tgid can return the ID (PID) of the captured process and the ID (TID) of the thread. In some embodiments, the first ID information and the second ID information may include the captured PID. In other embodiments, the first ID information and the second ID information may include the captured PID and the captured TID. The collector can obtain a first PID (i.e., the captured PID included in the first ID information) and a second PID (i.e., the captured PID included in the second ID information) from the eBPF VM. The profiling application can have one or more processes, each with a PID. When the first PID is the same as the PID of a process belonging to the profiling application (hereinafter referred to as the target process), the collector can determine that the thread data belongs to the target process of the profiling application. Similarly, when the second PID is the same as the PID of the target process, the collector can determine that the stack trace result belongs to the target process of the profiling application. In other words, both the first PID and the second PID are the same as the PID of the target process. The collector can then determine that the first stack trace result corresponds to the first thread data and determine the operational information of the profiling application based on the first stack trace result and the first thread data.
[0056] In some embodiments, the collector can determine a second entry from a first stack trace and a first entry from first thread data. Based on the first entry, the second entry, and the thread data, operational information of the performance analysis application can be determined.
[0057] For example, in some embodiments, the collector can obtain method information from the second entry. For instance, the method information could be the name of the target method. The collector can replace the first entry in the thread data with the name of the target method. For example, the collector can delete the first entry and copy the method name into the thread data. Therefore, the first entry is replaced by a new entry corresponding to the target method. In other words, the collector can obtain partial information from the second entry and replace the first entry with that partial information.
[0058] In other embodiments, the collector may replace the first entry with a second entry. For convenience, assume that the first thread data includes one first entry and N-1 third entries. The collector may delete the first entry and copy the second entry into the first thread data. The new thread data may include the second entry and N-1 third entries.
[0059] Taking Tables 1 and 2 as examples, entry 0 in Table 1 is the first entry, and entry 0 in Table 2 is the second entry. For convenience, it is assumed that both the first and second entries include method names. Therefore, the collector can replace the first entry with the second entry to obtain new thread data, as shown in Table 3.
[0060] Table 3
[0061] Compared to Table 1, the data carried by entry 0 in the thread data shown in Table 1 has been replaced by entry 0 in the stack trace results shown in Table 2.
[0062] For convenience, the new thread data can be referred to as the first call stack.
[0063] In some embodiments, the organizer may obtain two or more identical call stacks. Table 4 shows a second call stack, which was also obtained based on thread data and stack trace results from the performance analysis application.
[0064] Table 4
[0065] Figure 4 The second call stack shown is the same as the first call stack shown in Table 3. In this case, the collector may remove additional thread information. For example, the collector may remove the second call stack and determine the operation information based on the first call stack.
[0066] In some embodiments, the operational information is a flame graph.
[0067] In other embodiments, the operational information may be a heat map, icicle diagram, etc.
[0068] according to Figure 2 The illustrated technical solution allows the eBPF VM to perform performance analysis on a performance analysis application within kernel space. Besides the performance analysis application, the eBPF VM can also obtain thread data and stack trace results from other applications. In other words, the performance analysis application is one of multiple applications that can be performance analyzed by the eBPF VM. The eBPF VM and collector can obtain operational information for any type of application without requiring specific adjustments for each application. The eBPF VM can be loaded into kernel space once to perform performance analysis on multiple applications, and memory usage is limited to one instance per host / VM rather than per process. No code is injected into the performance analysis application and / or its user space, thus preventing any corruption due to code injection. Furthermore, call stack collection is independent of the JVM, as stack trace results and thread data are obtained by the eBPF VM.
[0069] Figure 3 These are schematic block diagrams of an electronic device 300 provided in some embodiments of this application. See also... Figure 3 Electronic device 300 includes eBPF VM 301 and collector 302. eBPF VM 301 runs in kernel space, and collector 302 runs in user space.
[0070] The eBPF VM 301 is used to obtain thread data when a stream transformation method in a performance analysis application is triggered. The first thread data includes N entries, each of which corresponds to a method in the performance analysis application. The N entries include a first entry, which corresponds to the triggered stream transformation method. N is a positive integer greater than 1.
[0071] The eBPF VM 301 is also used to determine the target method based on thread data, where the target method is invoked by a triggered stream transformation method.
[0072] The eBPF VM 301 is also used to perform performance analysis on performance analysis applications to obtain stack trace results, which include multiple entries that correspond one-to-one with multiple methods. The multiple entries include a second entry that corresponds to the target method.
[0073] Collector 302 is used to obtain thread data and stack trace results from eBPF VM 301.
[0074] Collector 302 is also used to determine operational information for the performance analysis application based on thread data and stack trace results.
[0075] The eBPF VM 301 and collector 302 can be implemented by the processor. Details on obtaining thread data, stack trace results, and operational information for the performance analysis application can be found in the above embodiments and will not be repeated here.
[0076] like Figure 4 As shown, the electronic device 400 may include a processor 401 and a memory 402. The memory 402 may be used to store code, instructions, etc., executed by the processor 401.
[0077] It should be understood that processor 401 can be an integrated circuit chip with signal processing capabilities. In implementation, the various steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a central processing unit (CPU), a graphics processing unit (GPU), a neural processing unit (NPU), a system-on-chip (SoC), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The processor can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor, or it can be any conventional processor, etc. The steps of the methods disclosed in conjunction with the embodiments of this application can be directly executed and completed by the processor, or executed and completed by using a combination of hardware and software modules in the processor. The software modules can reside in mature storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.
[0078] It is understood that the memory 402 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).
[0079] It should be noted that the memory of the electronic devices and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0080] This application provides a computer-readable storage medium including instructions. When the instructions are executed on an electronic device, the electronic device causes the electronic device to perform the above-described method.
[0081] This application provides a computer cluster. The computer cluster includes at least one computer. The computer includes one or more processors and memory coupled to the one or more processors. The memory is used to store instructions. When the instructions are executed by the one or more processors, the at least one computer performs the method described above.
[0082] Figure 5 This is a schematic diagram of the structure of a computer cluster provided in some embodiments of this application. For example... Figure 5 As shown, the computer cluster 50 includes at least one computer 500, which includes a bus 501, a processor 502, a communication interface 503, and a memory 504. The processor 502, the memory 504, and the communication interface 503 communicate with each other via the bus 501.
[0083] Bus 501 can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 5 In this context, a single thick line represents a bus. However, this does not mean that there is only one bus, nor does it mean that there is only one type of bus.
[0084] Processor 502 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), digital signal processor (DSP).
[0085] Communication interface 503 is used for communication with external devices. For example, communication interface 503 can be used to communicate with a target device and send operation information of the performance analysis application to the target device.
[0086] Memory 504 may include volatile memory, such as random-access memory (RAM). Memory 504 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD).
[0087] The memory 504 stores executable code, and the processor 502 executes the executable code to perform the above-described method.
[0088] This application provides a chip system. The chip system includes a memory for storing a computer program and a processor for retrieving and running the computer program from the memory, causing an electronic device equipped with the chip system to perform the methods described above.
[0089] This application provides a computer program product. When the computer program product is run on an electronic device, it causes the electronic device to perform the above-described method.
[0090] In embodiments of this application, "at least one" means one or more, and "more than" means two or more. The term "and / or" describes the association between associated objects and indicates that three relationships may exist. For example, A and / or B can represent the following three cases: only A exists, both A and B exist, and only B exists, where A and B can be singular or plural. The character " / " generally represents an "OR" relationship between associated objects. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of one or more. For example, at least one of a, b, and c can represent: a, b, c; a and b, a and c, b and c, or a, b, and c, where a, b, and c can be singular or plural.
[0091] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electrical hardware, or a combination of computer software and electrical hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0092] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the above-described systems, devices, and units can be referred to the corresponding processes in the above-described method embodiments. Further details will not be repeated here.
[0093] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the described apparatus embodiments are merely illustrative. For example, the unit division is only a logical functional division, and other division methods may be used in actual implementation. For example, multiple units or components may be merged or integrated into another system, or some features may be ignored or not performed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed can be implemented through some interfaces. Indirect coupling or communication connection between devices or units can be implemented electronically, mechanically, or in other forms.
[0094] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected based on actual needs to achieve the purpose of this embodiment.
[0095] Furthermore, in the various embodiments of this application, each functional unit can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0096] If implemented as software functional units and sold or used as independent products, these functions can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be implemented in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to instruct a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0097] The above descriptions are merely some specific implementations of this application and are not intended to limit the scope of protection of this application. Any variations or substitutions easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / string>
Claims
1. A method of obtaining operational information, characterized by, The method comprises: When a flow conversion method in a performance analysis application is triggered, an extended Berkeley packet filter (eBPF) virtual machine (VM) running in a kernel space obtains thread data, wherein the first thread data comprises N table entries, each of the N table entries corresponds to a method in the performance analysis application, the N table entries comprise a first table entry, the first table entry corresponds to the triggered flow conversion method, and N is a positive integer greater than 1; The eBPF VM determines a target method according to the thread data, wherein the target method is called by the triggered flow conversion method; The eBPF VM performs performance analysis on the performance analysis application to obtain a stack trace result, wherein the stack trace result comprises a plurality of table entries, the plurality of table entries correspond to a plurality of methods one by one, and the plurality of table entries comprise a second table entry, the second table entry corresponds to the target method; A collector running in a user space obtains the thread data and the stack trace result from the eBPF VM; The collector determines operation information of the performance analysis application according to the thread data and the stack trace result.
2. The method of claim 1, wherein, Before the collector determines the operation information of the performance analysis application according to the thread data and the stack trace result, the method further comprises: The eBPF VM obtains identification information of the thread data and identification information of the stack trace result; The collector obtains the identification information of the thread data and the identification information of the stack trace result from the eBPF VM; The collector determines the thread data and the stack trace result corresponding to the performance analysis application according to the identification information of the thread data and the identification information of the stack trace result.
3. The method of claim 2, wherein, The collector determines the operation information of the performance analysis application according to the thread data and the stack trace result comprises: The collector determines the first table entry from the thread data; The collector determines the second table entry from the stack trace result; The collector determines the operation information of the performance analysis application according to the first table entry, the second table entry and the thread data.
4. The method of claim 3, wherein, The collector determines the operation information of the performance analysis application according to the first table entry, the second table entry and the thread data comprises: The collector replaces the first table entry with method information obtained from the second table entry to obtain a first call stack; The collector determines the operation information of the performance analysis application according to the first call stack.
5. The method of claim 4, wherein, The collector determines the operation information of the target process according to the first call stack comprises: The collector determines whether the first call stack is the same as a second call stack obtained according to the performance analysis application, wherein the call stack is determined before the first call stack; When the first call stack is the same as the second call stack, the collector determines the operation information of the target process according to one of the first call stack or the second call stack.
6. The method according to any one of claims 3 to 5, characterized in that, The operation information is one of a flame graph, a heat map, or a call stack.
7. An electronic device, comprising: Comprise: a memory storing instructions; a processor coupled to the memory to execute the instructions to cause the processor to: run an extended Berkeley packet filter (eBPF) virtual machine (VM) in a kernel space, run a collector in a user space, wherein the eBPF VM is configured to: obtain thread data when a flow conversion method in a performance analysis application is triggered, wherein first thread data includes N table entries, each of the N table entries corresponds to a method in the performance analysis application, the N table entries include a first table entry, the first table entry corresponds to the triggered flow conversion method, N is a positive integer greater than 1; determine a target method according to the thread data, wherein the target method is called by the triggered flow conversion method; perform performance analysis on the performance analysis application to obtain stack trace results, wherein the stack trace results include a plurality of table entries, the plurality of table entries correspond one-to-one to a plurality of methods, the plurality of table entries include a second table entry, the second table entry corresponds to the target method; the collector is configured to: obtain the thread data and the stack trace results from the eBPF VM; determine operation information of the performance analysis application according to the thread data and the stack trace results.
8. The electronic device of claim 7, wherein, Before determining the operation information of the performance analysis application according to the thread data and the stack trace results, the eBPF VM is further configured to: obtain identification information of the thread data and identification information of the stack trace results; the collector is further configured to: obtain the identification information of the thread data and the identification information of the stack trace results from the eBPF VM; determine the thread data and the stack trace results corresponding to the performance analysis application according to the identification information of the thread data and the identification information of the stack trace results.
9. The electronic device of claim 8, wherein, The collector is specifically configured to: determine the first table entry from the thread data; determine the second table entry from the stack trace results; determine the operation information of the performance analysis application according to the first table entry, the second table entry, and the thread data.
10. The electronic device of claim 9, wherein, The collector is specifically configured to: replace the first table entry with method information obtained from the second table entry to obtain a first call stack; determine the operation information of the performance analysis application according to the first call stack.
11. The electronic device of claim 10, wherein, The collector is specifically configured to: determine whether the first call stack is the same as a second call stack obtained according to the performance analysis application, wherein the call stack is determined before the first call stack; When the first call stack is the same as the second call stack, the operation information of the target process is determined according to one of the first call stack or the second call stack.
12. The electronic device of any of claims 7-11, wherein, The operation information is one of a flame graph, a heat map, or a column chart.
13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on an electronic device, cause the electronic device to perform the method according to any one of claims 1-6.
14. A computer cluster, characterized by Comprising: at least one computer comprising: one or more processors; a memory coupled to the one or more processors and storing instructions that, when executed by the one or more processors, cause the at least one computer to perform the method according to any one of claims 1-6.
15. A computer program product, characterised in that, When the computer program product is executed on an electronic device, the electronic device performs the method according to any one of claims 1-6. When the computer program product is executed on an electronic device, the electronic device performs the method according to any one of claims 1-6.