Slow request determination method, device, storage medium and program product

Abstract

The embodiments of the present application provide a slow request determination method, device, storage medium and program product. In the embodiments of the present application, the first time when the kernel senses the data packet corresponding to the target request can be obtained, and when the data packet leaves the kernel, the kernel monitoring program is triggered to run. The kernel monitoring program can obtain the second time when the data packet leaves the kernel, and determine the processing delay of the data packet in the kernel based on the first time when the kernel senses the data packet corresponding to the target request and the second time when the data packet leaves the kernel; thereafter, it can be determined whether the target request is a slow request generated in the kernel processing stage based on the processing delay. The slow request determination method utilizes the kernel tracking mechanism to monitor slow requests on the path of the data packet corresponding to the kernel processing request, realizes the normalized monitoring of slow requests, and can capture slow requests in the kernel processing stage in a timely manner.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a slow request determination method, device, storage medium and program product. Background Art

[0002] In latency-sensitive network scenarios, once slow requests are generated, they often have an adverse impact on service quality and affect user experience. Therefore, it is necessary to capture slow requests in a timely manner. From the perspective of end-to-end network communication, the path of network requests can be divided into three parts: network links, operating systems (OS), and applications. Among them, OS is the core link between lower-layer network processing and upper-layer applications. Abnormal request processing by the kernel in the OS is one of the main causes of slow requests. Therefore, it is necessary to capture slow requests generated in the kernel processing stage in a timely manner. Summary of the invention

[0003] Multiple aspects of the present application provide a slow request determination method, device, storage medium and program product, which are used to timely determine slow requests generated in a kernel processing stage.

[0004] The embodiment of the present application provides a slow request determination method, which is applicable to an electronic device, including:

[0005] Obtaining the first time when the kernel of the electronic device senses a data packet corresponding to the target request;

[0006] When the data packet leaves the kernel, triggering a kernel monitoring program to obtain a second time when the data packet leaves the kernel;

[0007] Determining, by the kernel monitoring program, a processing delay of the data packet in the kernel according to the first time and the second time;

[0008] The kernel monitoring program determines whether the target request is a target slow request generated in the kernel processing stage according to the processing delay of the data packet in the kernel.

[0009] The embodiment of the present application further provides an electronic device, comprising: a memory and a processor; wherein the memory is used to store a computer program;

[0010] The processor is coupled to the memory and is configured to execute the computer program to perform the steps in the above-mentioned slow request determination method.

[0011] An embodiment of the present application further provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the steps in the above-mentioned slow request determination method.

[0012] An embodiment of the present application further provides a computer program product, including a computer program. When the computer program is executed by one or more processors, the one or more processors are caused to execute the steps in the above-mentioned slow request determination method.

[0013] In an embodiment of the present application, the first time when the kernel senses the data packet corresponding to the target request can be obtained, and when the data packet leaves the kernel, the kernel monitoring program is triggered to run. The kernel monitoring program can obtain the second time when the data packet leaves the kernel, and determine the processing delay of the data packet in the kernel based on the first time when the kernel senses the data packet corresponding to the target request and the second time when the data packet leaves the kernel; thereafter, it can be determined whether the target request is a slow request generated in the kernel processing stage based on the processing delay. This slow request determination method utilizes the kernel tracking mechanism to monitor slow requests on the path of the data packet corresponding to the kernel processing request, realizes the normalized monitoring of slow requests, and can timely capture slow requests in the kernel processing stage. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Figure 1 A schematic diagram of the internal structure of an electronic device provided in an embodiment of the present application;

[0016] Figure 2 A flowchart of a method for determining a slow request provided in an embodiment of the present application;

[0017] Figure 3 A schematic diagram of the analysis process of a slow request execution of a kernel monitoring program provided in an embodiment of the present application;

[0018] Figure 4 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

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

[0021] Before describing the solutions provided in the embodiments of the present application, the terms or concepts involved in the embodiments of the present application are first explained.

[0022] eBPF: Extended Berkeley Packet Filter (eBPF) is a subsystem in the kernel of an operating system (such as the Linux system) that can be used for packet processing, system tracing, security detection, and performance tuning.

[0023] TCP: Transmission Control Protocol (TCP) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol. In the Open System Interconnect (OSI) model of computer networks, it completes the functions specified by the transport layer.

[0024] Socket: A socket is a software structure inside a computer network node, acting as an endpoint for sending and receiving data over the network, or a software endpoint for process communication within a node.

[0025] skb: Socket Buffer (skb) is a data structure in the kernel network subsystem of an operating system (such as Linux system), which represents the abstract representation of network data packets in the kernel. It carries the content of data packets received or sent from the network and is transmitted and processed in the kernel network protocol stack.

[0026] OS: OS, or Operating System (OS), is system software that manages computer hardware and software resources and provides various services and interfaces to support the operation and execution of applications. It is a bridge between application software and hardware.

[0027] Kprobe: Kprobe, or kernel probe, is a dynamic tracing technology in the kernel of an operating system (such as Linux), which allows debugging code to be inserted into kernel functions without modifying the kernel source code. Kprobe can monitor the execution of specific functions in the kernel for analysis and debugging, but it has a certain performance overhead.

[0028] In actual applications, the occurrence of slow requests is somewhat accidental and usually cannot be stably reproduced in a small-scale test environment, which requires slow request monitoring tools to have normalized monitoring capabilities. However, due to their large performance overhead, traditional slow request monitoring tools are not suitable for normalized monitoring of slow requests, and cannot capture slow requests generated in the kernel processing stage in a timely manner. For example, the network diagnostic tool (Nettrace): the delay statistics and filtering functions do not support normalized activation, have high overhead, and are not suitable for normalized monitoring scenarios. The TCP event tracking tool (tcptracer-bpf) is implemented based on Kprobe technology, has high performance overhead, and is not suitable for normalized monitoring scenarios.

[0029] In order to promptly discover slow requests generated in the kernel processing stage, in some embodiments of the present application, the first time when the kernel senses the data packet corresponding to the target request can be obtained, and when the data packet leaves the kernel, the kernel monitoring program is triggered to run. The kernel monitoring program can obtain the second time when the data packet leaves the kernel, and determine the processing delay of the data packet in the kernel based on the first time when the kernel senses the data packet corresponding to the target request and the second time when the data packet leaves the kernel; thereafter, it can be determined whether the target request is a slow request generated in the kernel processing stage based on the processing delay. This slow request determination method utilizes the kernel tracking mechanism to monitor slow requests on the path of the data packet corresponding to the kernel processing request, realizes normalized monitoring of slow requests, and can capture slow requests generated in the kernel processing stage in a timely manner.

[0030] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0031] It should be noted that the same reference numerals denote the same objects in the following drawings and embodiments, and therefore, once an object is defined in one drawing or embodiment, it does not need to be further discussed in the subsequent drawings and embodiments.

[0032] Figure 1 This is a schematic diagram of the internal structure of an electronic device provided in an embodiment of the present application. Figure 1 As shown, the electronic device includes: a processor 10 and a network card 20. The processor 10 runs an operating system 101 and an application 102 of the application layer. The request obtained by the electronic device can be a request received by the electronic device or a request sent out by the electronic device.

[0033] To determine the processing delay of the data packet corresponding to the request in the kernel, the time when the data packet enters the kernel and the time when the data packet leaves the kernel can be determined; the difference between the time when the data packet leaves the kernel and the time when it enters the kernel is the processing delay of the data packet in the kernel.

[0034] Combine the following Figure 1 The internal structure of the electronic device shown uses a target request as an example to exemplarily illustrate the processing process of the request obtained by the electronic device within its structure.

[0035] like Figure 1 As shown, in the direction where the electronic device receives the target request, the network card 20 receives the data packet corresponding to the target request; the kernel 101a of the operating system 101 creates a skb structure to store the data packet. Specifically, the kernel 101a runs a driver for the network card 20, namely the network card driver. When the network card receives the data packet, the network card driver can create a skb structure and fill the relevant information of the data packet in the skb structure. After that, the skb structure is passed to the kernel's protocol stack for further processing. After the protocol stack processes the skb structure, it passes the skb structure to the application 102. Among them, the protocol stack can be a TCP protocol stack, a User Datagram Protocol (UDP) protocol stack or an Internet Protocol (IP) stack, etc., but is not limited thereto.

[0036] Specifically, the receive (receive, recv) system call calls the corresponding protocol stack function in the operating system kernel to receive data. Among them, recv is a system call for receiving data from a socket. When data is received, the protocol stack unpacks the datagram and passes the data to the receive buffer in the operating system kernel. When the application calls the recv system call function, the operating system kernel reads the data from the receive buffer and copies the data to the application's receive buffer.

[0037] According to the processing flow of the data packet corresponding to the target request in the request receiving direction, in the request receiving direction, the time point when the kernel perceives the data packet can be the time point when the network card driver creates the skb structure. In the embodiment of the present application, for the convenience of description and distinction, the time point when the kernel perceives the data packet is defined as the first time t1.

[0038] In some embodiments, the network card 20 has a hardware timestamp function, that is, the network card 20 has a function of recording timestamps. In this embodiment, the network card 20 can record the time when the network card receives the data packet when receiving the data packet, and store the time in the memory buffer corresponding to the network card. The network card driver in the kernel can obtain the time when the network card receives the data packet from the memory buffer as the time point when the kernel perceives the data packet, that is, as the first time t1. Further, the network card driver can construct an skb structure according to the first time t1 (here is the time when the network card receives the data packet) and the data packet received by the network card. Specifically, the network card driver can create an skb structure, and write the first time t1 (here is the time when the network card receives the data packet) and the data packet received by the network card into the skb structure.

[0039] In other embodiments, the network card 20 does not have a hardware timestamp function, or even if the network card 20 has a hardware timestamp function, the function is not used to record the time when the network card receives the data packet. In this embodiment, software timestamp timing can be used. The network card driver can construct an skb structure corresponding to the data packet. Specifically, the network card driver can create an skb structure and write the data packet into the skb structure to obtain the skb structure corresponding to the data packet. Accordingly, the kernel can obtain the construction completion time of the skb structure as the first time t1. In this embodiment, the kernel can also write the first time t1 (here, the construction completion time of the skb structure) into the skb structure.

[0040] It should be noted that for electronic devices whose network cards have hardware timestamp functions, hardware timestamps are preferred to be used to time the time when the kernel perceives the data packet. Because in the hardware timestamp timing method, the time when the network card receives the data packet is used as the time when the kernel perceives the data packet. In this way, when determining the kernel's processing delay for the target request, the time from when the network card receives the data packet to when the skb structure corresponding to the data packet is completed can be included, which can cover more kernel processing stages of the request and provide more comprehensive delay monitoring information. The software timestamp timing method will lose the time from when the network card receives the data packet to when the skb structure corresponding to the data packet is completed. Therefore, the kernel processing delay for the target request determined by hardware timestamp timing is more accurate.

[0041] In the receiving direction of the data packet, the time point when the data packet leaves the kernel is the time when the skb structure corresponding to the data packet is transmitted from the protocol stack. In each embodiment of the present application, the time point when the data packet leaves the kernel is defined as the second time t2.

[0042] In the direction of sending data packets by the electronic device, the data packet corresponding to the target request is transmitted from the application 102 to the kernel. The kernel constructs the skb structure corresponding to the data packet and transmits the skb structure to the protocol stack for processing. Specifically, the skb structure can be transmitted to the protocol stack for processing through the send system call. Among them, send is a system call for sending data from user space to kernel space so as to send data through the network or other socket types. The send system call will call the corresponding protocol stack function in the operating system kernel to send the data. Afterwards, the data packet processed by the protocol stack is sent to the network card 20, and the network card 20 sends the data packet.

[0043] In the direction in which the electronic device sends a data packet, the time point when the kernel senses the data packet (i.e., the first time t1) can be the time when the skb structure corresponding to the data packet is completed. Accordingly, the kernel can obtain the time when the skb structure corresponding to the data packet is completed as the first time t1, and write the first time t1 into the skb structure corresponding to the data packet. The time point when the data packet leaves the kernel is the time when the skb structure corresponding to the data packet is transmitted from the protocol stack. In each embodiment of the present application, the time point when the data packet leaves the kernel is defined as the second time t2.

[0044] Regardless of whether the target request is sent or received by the electronic device, the starting point of the target request entering the kernel is the time point when the kernel of the electronic device perceives the data packet corresponding to the request, that is, the first time t1. The time point when the target request leaves the kernel is the time point when the data packet is transmitted from the protocol stack, that is, the second time t2.

[0045] In the embodiment of the present application, the first time t1 when the kernel senses the data packet can be obtained by the kernel on the processing path of the target request in the kernel, and the time point when the data packet leaves the kernel needs to be obtained by configuring the kernel monitoring program. In the embodiment of the present application, the specific implementation method of configuring the kernel monitoring program is not limited.

[0046] The kernel monitoring program may be an eBPF program. Accordingly, the kernel monitoring program may be inserted into the output interface of the protocol stack in the kernel 101a using the eBPF technology. Using the eBPF program to monitor the kernel can implement complex functions without modifying the kernel code, thereby improving the performance and security of the system. In some embodiments, the kernel monitoring program may use kernel static tracking points to insert the kernel monitoring program (such as the eBPF program) into the output port of the protocol stack in the kernel 101a. Static tracking points are specific locations predefined in the kernel source code for recording the occurrence of specific events. These tracking points are fixed at compile time and cannot be dynamically modified at runtime. Using static tracking points can record key events in the kernel without modifying the kernel code or inserting probes. Among them, using static tracking technology to monitor the kernel has a lower performance overhead than other kernel tracking methods.

[0047] Specifically, a tracking point can be defined in the kernel source code, and the tracking point is usually defined using the TRACE_EVENT macro. The tracking point defined in the kernel source agent in the present application can be the output port of the protocol stack in the kernel 101a. Accordingly, the tracking point can be defined in the kernel source code as the output port of the protocol stack in the kernel 101a. Further, the kernel source agent can be compiled, and the tracking point will be compiled into a part of the kernel. After the compilation is completed, the tracking point becomes a part of the kernel and cannot be dynamically modified at runtime. The eBPF program can run when the tracking point is triggered and process the corresponding event. In other embodiments, the dynamic tracking technology can be used to insert the kernel monitoring program (such as the eBPF program) into the output port of the protocol stack in the kernel 101a. The dynamic tracking technology allows the probe to be dynamically inserted into any position of the kernel when the kernel is running. This method is more flexible and has a relatively large performance overhead. Specifically, when the kernel runs to the output port of the protocol stack, the kernel monitoring program (such as the eBPF) program can be inserted into the output port of the protocol stack in the kernel 101a.

[0048] The kernel monitoring program configured based on the output port of the protocol stack in the kernel can trigger the kernel monitoring program (such as the eBPF program) to run when the data packet leaves the kernel. Further, the kernel monitoring program (such as the eBPF program) can obtain the time point when the data packet leaves the kernel, that is, the second time t2.

[0049] Specifically, the kernel monitoring program can determine that the data packet leaves the kernel when the output interface of the protocol stack outputs the data packet. Accordingly, the kernel monitoring program (such as the eBPF program) can obtain the time point when the data packet is output to the output interface of the protocol stack, that is, the second time t2.

[0050] In other embodiments, since the kernel monitoring program is triggered when a data packet leaves the kernel, the kernel monitoring program can obtain the time point when it is triggered as the second time t2.

[0051] Based on the processing of the target request in the kernel and the kernel monitoring program configured by the kernel shown in the above embodiment, the slow request determination method provided in the embodiment of the present application can be summarized as follows: Figure 2 The slow request determination process is shown in FIG. Figure 2 As shown, the slow request determination method mainly includes:

[0052] 201. Obtain the first time when a kernel of the electronic device senses a data packet corresponding to a target request.

[0053] 202. When the data packet leaves the kernel, trigger a kernel monitoring program to obtain a second time when the data packet leaves the kernel.

[0054] 203. Determine the processing delay of the data packet in the kernel according to the first time and the second time through the kernel monitoring program.

[0055] 204. Determine whether the target request is a target slow request generated in the kernel processing stage according to the processing delay of the data packet in the kernel through the kernel monitoring program.

[0056] In some embodiments, the target request is a request received by an electronic device. The network card has a hardware timestamp function. When receiving a data packet, the network card can record the time when the network card receives the data packet, and store the time in the memory buffer corresponding to the network card. Further, the network card driver in the kernel can obtain the time when the network card receives the data packet from the memory buffer as the time point when the kernel perceives the data packet, that is, as the first time t1. Further, the network card driver can construct an skb structure according to the first time t1 (here is the time when the network card receives the data packet) and the data packet received by the network card. Specifically, the skb structure can be created by the network card driver, and the first time t1 (here is the time when the network card receives the data packet) and the data packet received by the network card are written into the skb structure as the skb structure corresponding to the data packet.

[0057] In other embodiments, the network card does not have a hardware timestamp function, or even if the network card has a hardware timestamp function, the function is not used to record the time when the network card receives the data packet. In this embodiment, software timestamp timing can be used. Accordingly, the skb structure corresponding to the data packet can be constructed by the network card driver in the kernel. Specifically, the skb structure can be created by the network card driver, and the data packet can be written into the skb structure to obtain the skb structure corresponding to the data packet. Accordingly, the construction completion time of the skb structure can be obtained through the kernel as the first time t1. In this embodiment, the first time t1 (here, the construction completion time of the skb structure) can also be written into the skb structure through the kernel.

[0058] It should be noted that for electronic devices whose network cards have hardware timestamp functions, hardware timestamps are preferred to be used to time the time when the kernel perceives the data packet. Because in the hardware timestamp timing method, the time when the network card receives the data packet is used as the time when the kernel perceives the data packet. In this way, when determining the kernel's processing delay for the target request, the time from when the network card receives the data packet to when the skb structure corresponding to the data packet is completed can be included, which can cover more kernel processing stages of the request and provide more comprehensive delay monitoring information. The software timestamp timing method will lose the time from when the network card receives the data packet to when the skb structure corresponding to the data packet is completed. Therefore, the kernel processing delay for the target request determined by hardware timestamp timing is more accurate.

[0059] In the direction in which the electronic device sends a data packet, the time point when the kernel senses the data packet (i.e., the first time t1) can be the time when the skb structure corresponding to the data packet is completed. Accordingly, the time when the skb structure corresponding to the data packet is completed can be obtained by the kernel as the first time t1, and the first time t1 is written into the skb structure corresponding to the data packet.

[0060] Regardless of whether the target request is sent or received by the electronic device, the starting point of the target request entering the kernel is the time point when the kernel of the electronic device perceives the data packet corresponding to the request, that is, the first time t1. The time point when the target request leaves the kernel is the time point when the data packet is transmitted from the protocol stack, that is, the second time t2.

[0061] In the embodiment of the present application, the first time t1 when the kernel senses the data packet can be obtained by the kernel on the processing path of the target request in the kernel, and the time point when the data packet leaves the kernel needs to be obtained by configuring the kernel monitoring program. In the embodiment of the present application, the specific implementation method of configuring the kernel monitoring program is not limited.

[0062] The kernel monitoring program may be an eBPF program. Accordingly, the kernel monitoring program may be inserted into the output interface of the protocol stack in the kernel using the eBPF technology. Among them, the eBPF technology for monitoring the kernel has a lower performance overhead than other kernel tracking methods.

[0063] The kernel monitoring program configured based on the output port of the protocol stack in the kernel can trigger the kernel monitoring program (such as the eBPF program) to run when the data packet leaves the kernel. Further, the time point when the data packet leaves the kernel, that is, the second time t2, can be obtained through the kernel monitoring program (such as the eBPF program).

[0064] Specifically, when the output interface of the protocol stack outputs the data packet, it can be determined that the data packet leaves the kernel. Accordingly, the time point when the data packet is output to the output interface of the protocol stack, that is, the second time t2, can be obtained through the kernel monitoring program (such as the eBPF program). Alternatively, the time point when the kernel monitoring program (such as the eBPF program) is triggered can be obtained as the second time t2.

[0065] Since the first time t1 when the kernel senses the data packet is obtained by the kernel or the network card, and is output to the output interface of the protocol stack through the skb structure corresponding to the data packet, accordingly, when the kernel monitoring program outputs the data packet at the output interface of the protocol stack, the first time t1 when the kernel senses the data packet can be obtained from the skb structure corresponding to the data packet.

[0066] Furthermore, the kernel monitoring program can determine the processing delay of the data packet in the kernel according to the first time t1 when the kernel perceives the data packet and the second time t2 when the data packet leaves the kernel. .

[0067] Furthermore, the kernel monitoring program can be used to monitor the processing delay of the data packet in the kernel. , determine whether the target request is a slow request generated in the kernel processing stage. Specifically, the kernel monitoring program can be used to determine the processing delay of the data packet in the kernel. Is it greater than or equal to the preset delay threshold? If the processing delay of the data packet in the kernel If the latency is greater than or equal to the preset latency threshold, the target request is determined to be a slow request generated during the kernel processing phase. The preset latency threshold determines that the target request is not a slow request generated in the kernel processing stage.

[0068] In this embodiment, the first time when the kernel senses the data packet corresponding to the target request can be obtained, and when the data packet leaves the kernel, the kernel monitoring program is triggered to run. The kernel monitoring program can obtain the second time when the data packet leaves the kernel, and determine the processing delay of the data packet in the kernel based on the first time when the kernel senses the data packet corresponding to the target request and the second time when the data packet leaves the kernel; then, it can be determined whether the target request is a slow request generated in the kernel processing stage based on the processing delay. This slow request determination method uses the kernel tracking mechanism to monitor slow requests on the path of the data packet corresponding to the kernel processing request, realizes the normalized monitoring of slow requests, and can capture slow requests in the kernel processing stage in a timely manner.

[0069] On the other hand, the embodiment of the present application adopts a kernel tracking mechanism to monitor slow requests in the kernel processing stage without modifying the application program, thereby decoupling the kernel monitoring program from the application program and realizing out-of-band monitoring of slow requests in the kernel processing stage.

[0070] In addition, the kernel monitoring program only focuses on high-latency data packets whose processing delay in the kernel processing stage is greater than or equal to the delay threshold, and can filter non-abnormal data packets whose processing delay in the kernel processing stage is less than the delay threshold as early as possible. There are only a small number of memory reads and arithmetic operations for the processing of non-abnormal data packets, and the overall performance overhead is small, which can meet the performance requirements of normalized slow request monitoring. Among them, the memory read operation for the processing of non-abnormal data packets refers to obtaining the first time t1 when the kernel perceives the data packet from the skb structure corresponding to the data packet. The arithmetic operation for the processing of non-abnormal data packets refers to calculating the time difference between the first time t1 when the kernel perceives the data packet and the second time t2 when the data packet leaves the kernel, that is, calculating the processing delay of the data packet in the kernel.

[0071] In some embodiments, when it is determined that the target request is a slow request generated in the kernel processing stage, an exception log of the target request can be generated by the kernel monitoring program according to the identifier of the target request and the delay exception data of the target request. Among them, the identifier of the target request refers to information that can uniquely represent a request. Optionally, the target request may be a network quad. For TCP requests, the network quad may include: source IP address, source port number, destination IP address and destination port number. The delay exception data of the target request may include: the processing delay of the data packet corresponding to the target request in the kernel and / or the time point when the target request is determined to be a slow request generated in the kernel processing stage, that is, the time point when the delay exception is determined. Accordingly, the exception log of the target request may include the identifier of the target request and the delay exception data of the target request.

[0072] In an embodiment of the present application, relevant exception logs can be generated for all slow requests generated in the kernel processing stage. In actual use, not all slow requests may be of interest to the user, that is, not all slow requests are of concern to the user. Based on this, filtering conditions can also be set, and the filtering conditions are used to filter out slow requests that the user is concerned about, and generate exception logs for slow requests that meet the filtering conditions. Based on the pre-set filtering conditions, when it is determined that the target request is a target request generated in the kernel processing stage, the kernel monitoring program can be used to determine whether the target request meets the pre-set filtering conditions. If the target request meets the filtering conditions, the kernel monitoring program outputs the target request identifier and the target request latency exception data. For example, the kernel monitoring program can generate an exception log of the target request based on the target request identifier and the target request latency exception data; further, the kernel monitoring program can output the target request exception log. For example, the kernel monitoring program can display the target request exception log; or, the kernel monitoring program can perform persistent storage of the target request exception log, etc. Or, such as Figure 1 As shown, the exception log of the target request is output to the application monitoring program of the application layer through the kernel monitoring program.

[0073] In an embodiment of the present application, the filtering dimension of the filtering condition is not limited. In some embodiments, the filtering condition may be the identifier of the request. If the identifier of the request in the filtering condition includes the identifier of the target request, it is determined that the target request satisfies the filtering condition. In other embodiments, the filtering condition may be the source IP address of the request. Accordingly, if the source IP address of the request in the filtering condition includes the source IP address of the target request, it is determined that the target request satisfies the filtering condition. Alternatively, the filtering condition may be the destination IP address of the request. Accordingly, if the destination IP address of the request in the filtering condition includes the destination IP address of the target request, it is determined that the target request satisfies the filtering condition. Alternatively, the filtering condition may be the source IP address and the destination IP address of the request. Accordingly, if the source IP address of the request in the filtering condition includes the source IP address of the target request, and the destination IP address of the request in the filtering condition includes the destination IP address of the target request, it is determined that the target request satisfies the filtering condition.

[0074] In other embodiments, the filtering condition may be an exception processing delay threshold of a slow request in the kernel. Accordingly, if the processing delay of the target request in the kernel is greater than or equal to the exception processing delay threshold, it is determined that the target request meets the filtering condition.

[0075] Alternatively, the filtering condition may include: the identifier of the request and the exception processing delay threshold of the slow request in the kernel. Accordingly, if the identifier of the request in the filtering condition includes the identifier of the target request, and the processing delay of the target request in the kernel is greater than or equal to the exception processing delay threshold, it is determined that the target request meets the filtering condition.

[0076] The filtering condition may be pre-set. In some embodiments, a filtering condition setting page may be provided. Users may independently set filtering conditions through the filtering condition setting page to limit the range of abnormal data packets. The filtering condition may filter slow requests generated during the kernel processing phase, reduce the monitoring range of the kernel monitoring program, and reduce performance overhead.

[0077] In the embodiment of the present application, the data packet leaves the kernel, triggering the kernel monitoring program to run. Afterwards, the kernel monitoring program can execute the slow request analysis process. Figure 3 The analysis of the slow request execution of the kernel monitoring program provided in the embodiment of the present application is exemplified. Figure 3 As shown in the figure, the analysis steps of the kernel monitoring program executing slow requests mainly include:

[0078] S1. Obtain the data packet output by the output interface of the protocol stack.

[0079] S2, determine whether the data packet carries a timestamp. If yes, execute step S3; if no, end the kernel monitoring program execution slow request analysis process.

[0080] S3. Obtain the timestamp carried by the data packet as the first time t1 when the kernel perceives the data packet.

[0081] S4. Obtain the timestamp of the output interface of the protocol stack outputting the data packet as the second time t2 of the data packet leaving the timestamp.

[0082] S5, calculate the time difference between the first time t1 and the second time t2 as the processing delay of the data packet in the kernel .

[0083] S6. Determine the processing delay of the data packet in the kernel Is it greater than or equal to the set delay threshold. If so, determine that the request corresponding to the data packet is a slow request, and continue to execute step S7; if not, end the kernel monitoring program to execute the slow request analysis process.

[0084] S7. Obtain the network quadruple of the target request.

[0085] S8, judging whether the network quadruple of the target request satisfies the filtering condition. The filtering condition includes the requested network quadruple. If yes, executing step S9; if no, ending the analysis process of the kernel monitoring program executing the slow request.

[0086] S9. Output the identification of the target request and delay abnormality data.

[0087] In an embodiment where the target request is a request received by an electronic device, in addition to determining the slow request generated in the kernel processing stage, the slow request can also be abnormally located. The sending device of the target request is defined as the target sending end. Specifically, the abnormal log of the slow request set monitored by the application side of the target sending end can be obtained. Among them, the application side monitors the slow request means that: the delay from the application sending the request to the application receiving the response data packet corresponding to the request is greater than or equal to the set delay threshold, then the request is determined to be a slow request monitored by the application side. The delay threshold set here is greater than the aforementioned delay threshold for determining that the target request is a slow request generated in the kernel processing stage.

[0088] For ease of description and distinction, when the target request is a slow request generated in the kernel processing stage, the slow request generated in the kernel processing stage is defined as a target slow request, and the exception log of the target slow request is defined as a target exception log.

[0089] In this embodiment, the scheduling duration of the receiving process corresponding to the application on the electronic device at the local end can also be obtained. The receiving process refers to the process of the application on the electronic device at the local end receiving the target request. The scheduling object of the electronic device is the application, that is, the process that receives the data packet (defined as the receiving process). The scheduling duration of the receiving process refers to the time from when the receiving process sleeps and vacates the processor to when the receiving process is again allocated to the processor to start receiving other data packets.

[0090] Furthermore, the target request can be abnormally located based on the target abnormality log of the target slow request, the abnormality log of the slow request set monitored by the application side of the target sending end, and the scheduling duration of the receiving process corresponding to the application on the electronic device at the local end. Among them, abnormal location of the target request refers to determining the cause of the abnormal delay of the target request.

[0091] Specifically, it is possible to determine whether the slow request set includes the target request based on the target exception log of the target slow request and the exception log of the slow request. Among them, the exception log of the slow request set includes: the identifier of the request included in the slow request set, and the time point when the request included in the slow request set is determined to be a slow request. The target exception log of the target slow request may include: the identifier of the target request and the time point when the target request is determined to be a slow request generated in the kernel processing stage. Accordingly, if the identifier of the request included in the slow request set includes the identifier of the target request, and the time difference when the target request is determined to be a slow request is less than or equal to a preset time difference threshold, it is determined that the slow request set includes the target request.

[0092] The time difference when the target request is determined as a slow request refers to the time difference between the time point when the identifier of the target request included in the slow request set is determined as a slow request and the time point when the target request is determined as a slow request generated in the kernel processing stage.

[0093] Furthermore, if the scheduling duration of the receiving process corresponding to the application on the electronic device at this end is greater than or equal to the preset duration threshold, it is determined that the abnormal processing delay of the target request in the kernel is caused by the application on the electronic device, that is, the data packet corresponding to the target request is queued in the kernel because the application is processed too slowly. If the scheduling duration of the receiving process corresponding to the application on the electronic device at this end is less than the preset duration threshold, it is determined that the abnormal processing delay of the target request in the kernel is caused by the kernel. For example, the kernel processes the data packet too slowly.

[0094] In an embodiment where the target request is a request sent by an electronic device, if the target request is determined to be a slow request generated in the kernel processing stage, it can be determined that the reason for the abnormal delay in processing the target request in the kernel is mainly due to abnormal kernel processing logic, such as flow control causing the data packet corresponding to the target request to queue in the kernel for a long time.

[0095] According to the abnormal location method provided in the above embodiment, it can be known that the target abnormal log of the target slow request generated in the kernel processing stage can provide a basis for locating the abnormal request delay. The user can determine whether the abnormal delay needs to be processed based on the target abnormal log of the target slow request, and locate the specific cause of the abnormal delay according to the needs.

[0096] In the embodiment of the present application, the processing delay of the corresponding data packet in the kernel can be determined for all requests received or sent by the electronic device, and the timestamp sampling frequency can also be set. The timestamp sampling frequency is determined by the timestamp sampling period. The timestamp sampling period refers to the time when the timestamp sampling period arrives, when the aforementioned Figure 2 The slow request determination method provided is to use the request received or sent by the electronic device when the timestamp sampling period arrives as the target request and execute Figure 2 The slow request determination method shown obtains the first time when the kernel perceives the data packet corresponding to the target request and the second time when the data packet leaves the kernel.

[0097] In other embodiments, in addition to obtaining the first time when the kernel perceives the data packet corresponding to the target request and the second time when the data packet leaves the kernel, the kernel monitoring program can also monitor more tracking points in the kernel to achieve more fine-grained processing delay information. For example, the kernel monitoring program can be inserted into the input interface and output interface of the data packet entering the protocol stack, so that the kernel monitoring program can obtain the time point when the data packet arrives at the input interface of the protocol stack, and the time point when the data packet arrives at the output interface of the protocol stack, and can determine the processing delay of the data packet in the protocol stack based on the time point when the data packet arrives at the input interface of the protocol stack and the time point when the data packet arrives at the output interface of the protocol stack.

[0098] It should be noted that the execution subject of each step of the method provided in the above embodiment can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 201 and 202 can be device A; for another example, the execution subject of step 201 can be device A, and the execution subject of step 202 can be device B; and so on.

[0099] In addition, in some of the processes described in the above embodiments and the accompanying drawings, multiple operations appearing in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this document or may be executed in parallel, and the sequence numbers of the operations, such as 201, 202, etc., are only used to distinguish between different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel.

[0100] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the steps in the above-mentioned slow request determination method.

[0101] The embodiment of the present application also provides a computer program product, including a computer program, which, when executed by one or more processors, causes the one or more processors to execute the steps in the above-mentioned slow request determination method. In the embodiment of the present application, the specific implementation form of the computer program product is not limited. In some embodiments, the computer program product can be implemented as an application (Application, APP), a mini-program, a computer-side client, a program module, a plug-in, an installation package, a software development kit (Software Development Kit, SDK), an image file of a CD (such as an ISO file), a plug-in or software in the form of software as a service (Software as a Service, SaaS), etc., but is not limited to this.

[0102] Figure 4The hardware structure diagram of the electronic device provided in the embodiment of the present application is shown in FIG. Figure 4 As shown, the electronic device includes: a memory 40a and a processor 40b. The memory 40a is used to store computer programs.

[0103] The processor 40b is coupled to the memory 40a and is used to execute a computer program to execute the steps in the index processing method provided in the above embodiments. The specific implementation of each step can be found in the relevant description of the above embodiments, which will not be repeated here.

[0104] In some optional embodiments, such as Figure 4 As shown, the electronic device may also include optional components such as a communication component 40c, a power component 40d, a display component 40e and an audio component 40f. Figure 4 The components are shown schematically only, and do not mean that the electronic device must include Figure 4 The components shown do not necessarily mean that the electronic device can only include Figure 4 Components shown.

[0105] in addition, Figure 4 The components in the dashed box are optional components, not mandatory components, and may depend on the product form of the electronic device. The electronic device of this embodiment may be implemented as a terminal device such as a desktop computer, a laptop computer, a mobile phone, or an IoT device; or may be various server devices such as a traditional server, a cloud server, or a server cluster.

[0106] In an embodiment of the present application, the memory is used to store a computer program and can be configured to store various other data to support operations on the device where it is located. Among them, the processor can execute the computer program stored in the memory to implement the corresponding control logic. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (Static Random-Access Memory, SRAM), electrically erasable programmable read only memory (Electrically Erasable Programmable Read Only Memory, EEPROM), erasable programmable read only memory (Electrical Programmable Read Only Memory, EPROM), programmable read only memory (Programmable Read Only Memory, PROM), read only memory (Read Only Memory, ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0107] In the embodiment of the present application, the processor may be any hardware processing device that can execute the logic of the above method. Optionally, the processor may be a central processing unit (CPU), a graphics processing unit (GPU) or a microcontroller unit (MCU); it may also be a field programmable gate array (FPGA), a programmable array logic device (PAL), a general array logic device (GAL), a complex programmable logic device (CPLD) or other programmable devices; or it may be an advanced reduced instruction set (RISC) processor (Advanced RISC Machines, ARM) or a system on chip (System on Chip, SoC), etc., but not limited thereto.

[0108] In an embodiment of the present application, the communication component is configured to facilitate wired or wireless communication between the device in which it is located and other devices. The device in which the communication component is located can access a wireless network based on a communication standard, such as Wireless Fidelity (WiFi), 2G or 3G, 4G, 5G or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component can also be implemented based on Near Field Communication (NFC) technology, Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wide Band (UWB) technology, Bluetooth (BT) technology or other technologies.

[0109] In an embodiment of the present application, the display component may include a liquid crystal display (LCD) and a touch panel (TP). If the display component includes a touch panel, the display component may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.

[0110] In an embodiment of the present application, a power supply component is configured to provide power to various components of the device in which it is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component is located.

[0111] In an embodiment of the present application, the audio component may be configured to output and / or input audio signals. For example, the audio component includes a microphone (Microphone, MIC), and when the device where the audio component is located is in an operating mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal may be further stored in a memory or sent via a communication component. In some embodiments, the audio component also includes a speaker for outputting an audio signal. For example, for a device with a language interaction function, voice interaction with a user may be achieved through an audio component.

[0112] It should be noted that the descriptions such as “first” and “second” in this article are used to distinguish different messages, devices, modules, etc., and do not represent the order of precedence, nor do they limit “first” and “second” to different types.

[0113] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program codes.

[0114] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0115] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0116] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0117] In a typical configuration, a computing device includes one or more processors (CPU, etc.), input / output interfaces, network interfaces, and memory.

[0118] Memory may include non-permanent storage in a computer-readable medium, in the form of random-access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0119] Computer storage media is readable storage media, also known as readable media. Readable storage media include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic cassettes, disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0120] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of further restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the above elements.

[0121] The above contents are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included within the scope of the claims of the present application.

Claims

1. A slow request determination method, applicable to an electronic device, characterized in that: include: Constructing a socket buffer structure corresponding to the data packet through a network card driver in the kernel of the electronic device; The data packet is a data packet corresponding to the target request; Obtaining the first time when the kernel senses the data packet; Writing the first time into the socket buffer structure by the kernel; When the data packet leaves the kernel, triggering a kernel monitoring program to obtain a second time when the data packet leaves the kernel; Obtaining the first time from the socket buffer structure through the kernel monitoring program; Determining, by the kernel monitoring program, a processing delay of the data packet in the kernel according to the first time and the second time; The kernel monitoring program determines whether the target request is a target slow request generated in the kernel processing stage according to the processing delay of the data packet in the kernel.

2. The method according to claim 1, characterized in that The kernel monitoring program is an extensible Berkeley Packet Filter (eBPF) program, and the eBPF program is inserted into the output interface of the protocol stack in the kernel; The method further comprises: in a case where the output interface outputs the data packet, determining that the data packet leaves the kernel; When the data packet leaves the kernel, triggering the kernel monitoring program to obtain the second time when the data packet leaves the kernel includes: When the data packet leaves the kernel, triggering the eBPF program to run; The time when the data packet is output to the output interface is obtained through the eBPF program as the second time.

3. The method according to claim 1, characterized in that The target request is a request received by the electronic device; the network card of the electronic device obtains a third time when the network card receives the data packet, and stores the third time in a memory buffer corresponding to the network card; The obtaining of the first time when the kernel of the electronic device senses the data packet includes: The third time is obtained from the memory buffer through the network card driver in the kernel as the first time.

4. The method according to claim 3, characterized in that The method of constructing a socket buffer structure corresponding to a data packet by a network card driver in the kernel of the electronic device includes: The first time and the data packet received by the network card are constructed into the socket buffer structure through the network card driver.

5. The method according to claim 1, characterized in that The obtaining of the first time when the kernel of the electronic device senses the data packet includes: The construction completion time of the socket buffer structure is obtained through the kernel as the first time.

6. The method according to claim 5, characterized in that The target request is a request sent by the electronic device; the step of constructing a socket cache structure corresponding to a data packet through a network card driver in the kernel comprises: constructing application data sent by an application program into the socket cache structure through the kernel; or, The target request is a request received by the electronic device; constructing the socket cache structure corresponding to the data packet through the kernel includes: constructing the data packet received by the network card of the electronic device into the socket cache structure through the network card driver in the kernel.

7. The method according to any one of claims 1 to 6, characterized in that: The determining, by the kernel monitoring program, whether the target request is a target slow request generated in the kernel processing stage according to the processing delay of the data packet in the kernel includes: Determining, by the kernel monitoring program, whether the processing delay of the data packet in the kernel is greater than or equal to a preset delay threshold; If the judgment result is yes, it is determined that the target request is a target slow request generated in the kernel processing stage.

8. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: When it is determined that the target request is a target slow request generated in the kernel processing stage, the kernel monitoring program generates a target exception log of the target request according to the identifier of the target request and the latency exception data of the target request.

9. The method according to claim 8, characterized in that The target request is a request received by the electronic device; the method further includes: Obtaining an exception log of a slow request set monitored by an application side of a target sending end; the target sending end is a sending end of the target request; Obtaining a scheduling duration of a receiving process corresponding to the application on the electronic device; the receiving process refers to a process of the application on the electronic device receiving the data packet; The target request is abnormally located according to the target abnormality log, the abnormality log of the slow request set and the scheduling duration.

10. The method according to claim 9, characterized in that The performing abnormal location on the target request according to the target abnormal log, the abnormal log of the slow request set and the scheduling duration includes: Determining whether the slow request set includes the target request according to the target exception log and the exception log of the slow request set; If included, determining whether the scheduling duration is greater than or equal to a preset duration threshold; If the scheduling duration is greater than or equal to a preset duration threshold, it is determined that the processing delay exception of the target request in the kernel is caused by the application on the electronic device; or, if the scheduling duration is less than the preset duration threshold, it is determined that the processing delay exception of the target request in the kernel is caused by the kernel.

11. The method according to claim 8, characterized in that The method further comprises: In the case where it is determined that the target request is a target slow request generated in the kernel processing stage, judging whether the target request satisfies a preset filtering condition through the kernel monitoring program; If the target request satisfies the filtering condition, the identifier of the target request and the abnormal latency data of the target request are outputted through the kernel monitoring program.

12. An electronic device, characterized in that: include: A memory and a processor; wherein the memory is used to store a computer program; The processor is coupled to the memory and configured to execute the computer program to perform the steps of the method according to any one of claims 1 to 11.

13. A computer-readable storage medium storing computer instructions, characterized in that: When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the steps in the method according to any one of claims 1 to 11.

14. A computer program product, characterized in that The method comprises a computer program, which, when executed by one or more processors, causes the one or more processors to execute the steps of the method according to any one of claims 1 to 11.

Images