Ebpf-based container network tcp connection latency monitoring method and apparatus

Abstract

The application discloses a kind of container network TCP connection delay monitoring method and device based on eBPF, the TCP connection delay condition between Pod on kubernetes is analyzed, the handshake RTT when Pod is calculated TCP three times handshaking, including the acquisition of basic metadata, the collection of kernel protocol stack event, the analysis process of kernel protocol stack event, monitoring index data is visualized and shown.The application is based on the behavior characteristics of kernel network protocol stack under the complex container network scene of cloud native, constructs a method for monitoring index that is specially used for analyzing the TCP handshake condition between Pod, can capture and intercept the key kernel protocol stack point through which network data packet flows, and directly calculate TCP handshake packet RTT in kernel in real time, accurately calculate the TCP handshake RTT index of kernel granularity, save the packet copy overhead of user mode, with excellent performance.

Description

Technical Field

[0001] This invention relates to the field of cloud-native observability, and more particularly to a method and apparatus for monitoring TCP connection latency in container networks based on eBPF. Background Technology

[0002] With the rapid development of cloud-native applications, more and more enterprises are choosing to upgrade monolithic applications to cloud-native applications. Cloud-native offers capabilities such as elastic scaling of capacity and computing power, service isolation, and one-click deployment, allowing business personnel to focus only on business logic without worrying about the underlying infrastructure implementation. While cloud-native brings efficiency and stability to application development and deployment, it also brings new challenges to the observability domain. Cloud-native environments rely on containers and Kubernetes (k8s) technology as their underlying support. Container technology itself is a virtualization technology that shields many physical details. Meanwhile, k8s, a container orchestration technology, also introduces many virtualization techniques, such as communication between containers through virtual overlay networks, creating new challenges for traditional observability techniques. These virtualization technologies make it difficult for traditional observability techniques to accurately and efficiently monitor and analyze network faults between containers. Therefore, by monitoring and analyzing relevant points in the kernel protocol stack using eBPF technology, fine-grained data acquisition of TCP (Transmission Control Protocol) network data can be achieved. Simultaneously, the analysis and calculation of RTT (Round-Trip Time) metrics can be performed directly within the kernel, eliminating the need to copy raw data packets to user space. This results in superior performance for accurately calculating the TCP handshake RTT metrics between containers. The inter-container TCP handshake RTT metrics help identify network problems and time bottlenecks, enabling targeted troubleshooting and resolution. Summary of the Invention

[0003] The purpose of this invention is to address the problems of coarse granularity and high resource consumption in existing invasive monitoring technologies by providing a method and apparatus for monitoring TCP connection latency in container networks based on eBPF. This invention can calculate TCP and RTT latency metrics more accurately, efficiently, and in a lighter weight.

[0004] The objective of this invention is achieved through the following technical solution: The first aspect of this invention provides a method for monitoring TCP connection latency in container networks based on eBPF, comprising the following steps:

[0005] (1) Obtain the network card metadata information of the local machine, wherein the network card metadata information includes the mapping relationship between various virtual network cards and network card index numbers;

[0006] (2) Monitor key events of the Linux kernel protocol stack in the kernel based on the network card metadata information of the local machine, and parse the relevant data packets. The relevant data packets specifically include received data packets and sent data packets to obtain container network card data packet information;

[0007] (3) Based on the obtained container network card data packet information, establish a mapping from a 5-tuple to a TCP handshake RTT tuple in the kernel through eBPF Map. This mapping is a key-value pair, where the key is a 5-tuple and the key value is a 2-tuple (SYNRTT, ACKRTT). For each data packet passing through the container, determine whether it is a handshake packet by parsing the flag field of its TCP data packet header, and at the same time obtain the current timestamp information.

[0008] (4) Calculate the round-trip latency of the TCP three-way handshake between Pods based on the handshake packet determined in step (3) and the current timestamp information obtained.

[0009] (5) Send the RTT metric calculated in step (4) to user space through the ring buffer of eBPF;

[0010] (6) Analyze, correlate and process the obtained RTT metrics in user space to invalidate data in the tuple that does not pass through the network;

[0011] (7) The event data processed by the user mode in step (6) will be summarized and displayed.

[0012] Further, step (1) includes the following sub-steps:

[0013] (1.1) Obtain the corresponding network card index number based on the virtual network card name;

[0014] (1.2) Establish a mapping relationship between network card index number and network card type, wherein the network card type includes container network card and non-container network card.

[0015] Furthermore, step (2) includes the following sub-steps:

[0016] (2.1) For the kernel's receiving data packet process, the eBPF program of type TRACEPOINT listens for the netif_receive_skb event and parses the incoming kernel socket to obtain the container network card data packet information during the receiving process.

[0017] (2.2) For the kernel's data packet sending process, the KPROBE type eBPF program listens for the dev_hard_start_xmit event and parses the incoming kernel socket to obtain the container network card data packet information during the sending process.

[0018] Furthermore, the container network interface card (NIC) data packet information includes the 5-tuple of the data packets on the container NIC, the data packet capture timestamp, and the flag field of the TCP data packets;

[0019] The five-tuple of the data packet on the container network card includes the source IP, destination IP, source port, destination port, and network card index number.

[0020] Furthermore, the flag field in the TCP packet header includes the SYN synchronization flag and the ACK acknowledgment flag;

[0021] The method of determining whether a packet is a handshake packet by parsing the flag field of its TCP packet header specifically includes:

[0022] If SYN=1 and ACK=0, it indicates that this is the first handshake packet;

[0023] If SYN=1 and ACK=1, it indicates that it is the second handshake packet;

[0024] If the first data packet with SYN=0 and ACK=1 after the second handshake is the third handshake packet.

[0025] Furthermore, step (4) includes the following sub-steps:

[0026] (4.1) When the container network card parses the data of the first handshake packet, it stores the five-tuple of the current data packet as the key and the two-tuple (current timestamp, 0) as the key value in the eBPF Map.

[0027] (4.2) When the container network card parses the data of the second handshake packet, the five-tuple of the current data packet is used as the key and the two-tuple (SYNRTT, current timestamp) is used as the key value to update the eBPF Map; the specific calculation method of SYNRTT is: SYNRTT = current timestamp - current timestamp already existing in eBPF Map;

[0028] (4.3) When the container network card parses the data of the third handshake packet, the five-tuple of the current data packet is used as the key and the two-tuple (SYNRTT, ACKRTT) is used as the key value to update the eBPF Map; where the specific calculation method of ACKRTT is: ACKRTT = current timestamp - current timestamp already existing in eBPF Map.

[0029] Furthermore, step (5) includes the following sub-steps:

[0030] (5.1) Create an eBPF Map of type BPF_MAP_TYPE_PERF_EVENT in the kernel space. Its key and key value represent the CPU core number and the pmu_fd value of the performance monitoring counter initialized by the performance monitoring unit on the core, respectively. Write the round-trip delay index calculated in step (4) to the ring buffer in the kernel through the bpf_perf_event_output function.

[0031] (5.2) Create a PMC for each CPU in user space and write the corresponding pmu_fd value into the eBPF Map created in step (5.1); the user space implements memory mapping of the ring buffer through the mmap mechanism and reads the round-trip latency metrics sent from the kernel space.

[0032] Further, step (7) specifically involves transmitting the event data processed in user mode in step (6) to the Prometheus platform in the form of Metrics, and then visualizing it using Grafana.

[0033] A second aspect of this invention provides an eBPF-based container network TCP connection latency monitoring device, comprising one or more processors and a memory, wherein the memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the above-described eBPF-based container network TCP connection latency monitoring method.

[0034] A third aspect of the present invention provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, is used to implement the above-described eBPF-based container network TCP connection latency monitoring method.

[0035] The beneficial effect of this invention is that it can accurately calculate the TCP handshake packet latency during inter-container communication in complex container networks with extremely low performance overhead, thereby helping to discover and locate container network faults and bottlenecks. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the monitoring and analysis module design scheme in this invention;

[0037] Figure 2 This is a schematic diagram of data packet unpacking and analysis in this invention;

[0038] Figure 3 This is a schematic diagram of a container network TCP connection latency monitoring device based on eBPF in this invention. Detailed Implementation

[0039] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not intended to limit this application.

[0040] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0041] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to determination," or "includes." Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process or method. Without further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0042] The container network TCP connection latency monitoring method based on eBPF of the present invention is implemented based on Linux eBPF kernel technology and is applied to Kubernetes clusters.

[0043] It should be noted that Kubernetes, or k8s for short, is an open-source application used to manage containerized applications across multiple hosts in a cloud platform. Kubernetes is an open-source container orchestration engine that supports automated deployment, large-scale scalability, and containerized application management.

[0044] The container network TCP connection latency monitoring method based on eBPF of the present invention specifically includes the following steps:

[0045] (1) Obtain the network card metadata information of the local machine. The network card metadata information includes the mapping relationship between various virtual network cards and network card index numbers (ifindex).

[0046] It should be understood that the kernel filters container network packets based on the obtained network interface card (NIC) index numbers. First, the NIC index number is found based on the NIC name of the network covered by the Kubernetes container. Then, the kernel only considers packets from these NIC index numbers, thus achieving the purpose of packet filtering.

[0047] (1.1) Obtain the corresponding network card index number (ifindex) based on the virtual network card name.

[0048] Specifically, the `getifaddrs` function provided by Linux is used to obtain the local network interface card (NIC) data list, which includes NIC information for all NICs on the local machine. For each NIC, the container NIC name in two common Kubernetes virtual overlay networks, Flannel and Calico, is parsed. Here, the container NIC refers to the NIC outside the container connected via Veth Pair technology. The default container NIC name in the Flannel overlay network is prefixed with "veth," while the default container NIC name in the Calico overlay network is prefixed with "cali." Therefore, the virtual NIC name can be obtained through this NIC data list. In this embodiment, only the container NIC is needed; therefore, after obtaining the required container NIC name, the NIC index number (ifindex) corresponding to the container NIC name is obtained using the `if_nametoindex` function provided by Linux.

[0049] It should be noted that the mainstream communication components between Kubernetes hosts and containers are Flannel and Calico.

[0050] (1.2) Establish a mapping relationship between network interface card index (ifindex) and network interface card type. The network interface card type includes container network interface card and non-container network interface card. This mapping relationship enables the underlying eBPF kernel program to filter irrelevant data packets through the network interface card type corresponding to ifindex.

[0051] Specifically, the obtained container network interface card (NIC) index number is recorded in the eBPF Map through the user-space eBPF Helper function bpf_map_update_elem, establishing a mapping relationship between the NIC index number and the NIC type. This allows the underlying eBPF kernel program to filter out irrelevant data packets based on the NIC type corresponding to the NIC index number.

[0052] (2) Monitor key events of the Linux kernel protocol stack in the kernel based on the network card metadata information of the local machine, and parse the relevant data packets. The relevant data packets specifically include received data packets and sent data packets to obtain container network card data packet information.

[0053] (2.1) For the kernel's receiving data packet process, the eBPF program of type TRACEPOINT listens for the netif_receive_skb event and parses the incoming kernel socket to obtain the container network card data packet information during the receiving process.

[0054] It should be understood that an eBPF program of type TRACEPOINT can listen for the netif_receive_skb event. After listening for the event, it will obtain the kernel context data passed in by the event and then parse the data in the program.

[0055] Specifically, the kernel socket here refers to the sk_buff structure in the Linux kernel. This is one of the core data structures of the Linux kernel protocol stack, used to record information and status of kernel data packets. The mac_header and network_header members provided by the sk_buff structure can be used to parse the header information of the data link layer and network layer in the network data packets. Based on the upper-layer network protocol contained in the header information, the actual data packet information transmitted by the container can be further parsed (i.e., the five-tuple (source IP, destination IP, source port, destination port, network interface index ifindex) of the data packet on the container's network interface card, the packet capture timestamp, and the flag field of the TCP packet).

[0056] Furthermore, the container network interface card (NIC) packet information includes the 5-tuple of the packet on the container NIC, the packet capture timestamp, and the flag field of the TCP packet, etc.

[0057] Furthermore, the five-tuple of a data packet on a container network interface card includes the source IP, destination IP, source port, destination port, and network interface card index number.

[0058] (2.2) For the kernel's data packet sending process, the KPROBE type eBPF program listens for the devhard start xmit event and parses the incoming kernel socket to obtain the container network card data packet information during the sending process.

[0059] It should be understood that an eBPF program of type KPROBE can listen for the dev_hard_start_xmit event. After listening for the event, it will obtain the kernel context data passed in by the event and then parse the data in the program.

[0060] It should be noted that the process of parsing the incoming kernel socket during the sending of data packets by the kernel is the same as the parsing process during the receiving process.

[0061] In summary, data packets are captured at key points in the network data packet flow through the kernel protocol stack. For example... Figure 1 As shown, the eBPF program is mounted at the `netif_receive_skb` and `dev_hard_start_xmit` points. It parses the `sk_buff` and `net_device` structures from the register context data. The former is used for packet unpacking and analysis, and the latter is used to obtain the network interface card (NIC) index (`ifindex`). The `ifindex` field under the `net_device` structure can be used to determine which NIC the packet passed through. Using the obtained `ifindex`, a match is performed in the eBPF Map to determine if it originates from the container NIC. The eBPF program only parses packets from the container NIC. Then, the packet is parsed using the `sk_buff` structure obtained in step two, as shown... Figure 2 As shown, the data packets will be parsed layer by layer from the ETH, IP, and TCP layers to obtain the required five-tuple (source IP, destination IP, source port, destination port, container network interface index number ifindex) data and the flag field of the TCP data packet, and other data information such as the timestamp will be obtained through the eBPF Helper function.

[0062] like Figure 2 As shown, when parsing data packets layer by layer from the ETH, IP, and TCP layers, the offsets of the ETH and IP headers in the network packet can first be parsed using the mac_header and network_header members provided by the sk_buff structure. Based on the IP header information, it can be determined whether it is an IPv4 or IPv6 protocol, thus obtaining the tuple (source IP, destination IP) and the packet offset of the transport layer header. After parsing the transport layer header, the necessary TCP header information can be obtained, including the tuple (source port, destination port) and the flag field.

[0063] It should be noted that the sk_buff structure is one of the core data structures of the Linux kernel protocol stack, used to record information and status of kernel data packets. The net_device structure is a structure in the Linux kernel protocol stack that stores network device information.

[0064] (3) Based on the obtained container network card data packet information, establish a mapping from a 5-tuple to a TCP handshake RTT tuple in the kernel through eBPF Map. This mapping is a key-value pair, where the key is a 5-tuple and the key value is a tuple (SYNRTT, ACKRTT). For each data packet passing through the container, determine whether it is a handshake packet by parsing the flag field of its TCP data packet header, and at the same time obtain the current timestamp information.

[0065] Specifically, based on the relevant data information obtained and parsed in step (2), namely the container network card packet information, an eBPF Map of type BPF_MAP_TYPE_HASH is created in the kernel. Its key is defined as the quintuple mentioned in step (2), and its value is a binary tuple (SYNRTT, ACKRTT). This establishes a mapping from the quintuple to the TCP handshake RTT binary tuple, where the key is the quintuple mentioned in step (2), and the value is a binary tuple (SYNRTT, ACKRTT). This definition is specified in the "map" section, and then the defined eBPF Map is created and loaded into the kernel in user space using the eBPF loader. Executable Linkable Format, abbreviated as ELF, is the storage format for executable files on the Linux platform, and this section is a component of the ELF file.

[0066] Furthermore, for each data packet passing through the container, the flag field of its TCP header is parsed to determine whether it is a handshake packet, and the current timestamp information is obtained at the same time.

[0067] It should be noted that the flag field in the TCP packet header includes two flags: SYN and ACK. The TCP protocol uses these two flags to determine whether a packet is a handshake. SYN represents the synchronization flag, which is 1 only during the first and second handshakes. ACK represents the acknowledgment flag, which is 1 after the second handshake.

[0068] Specifically, for each data packet passing through the container, it is determined whether it is a handshake packet by parsing the flag field of its TCP header:

[0069] If SYN=1 and ACK=0, it indicates that this is the first handshake packet;

[0070] If SYN=1 and ACK=1, it indicates that it is the second handshake packet;

[0071] If the first data packet with SYN=0 and ACK=1 after the second handshake is the third handshake packet, it corresponds to the last handshake process and the data packet transmission process after the connection is established.

[0072] (4) Calculate the round-trip time (RTT) metric for the TCP three-way handshake between Pods based on the handshake packet determined in step (3) and the obtained current timestamp information. Specifically, this includes:

[0073] (4.1) When the container network interface parses the data of the first handshake packet, the five-tuple of the current data packet is used as the key and the two-tuple (current timestamp, 0) is used as the value, and stored in the eBPF Map.

[0074] It's important to note that the tuple is (SYNRTT, ACKRTT). However, during the first handshake, the current timestamp is temporarily used as SYNRTT, and 0 is assigned to ACKRTT. These two values ​​are not the final SYNRTT and ACKRTT at this point; they are intermediate values. The actual SYNRTT and ACKRTT can only be calculated after the three-way handshake is fully established. Furthermore, as the formula shows, the final calculation of SYNRTT and ACKRTT depends on the current timestamp. During the second handshake, the actual SYNRTT can be calculated, but ACKRTT cannot yet be calculated; only the current timestamp is temporarily stored. The final calculation results are the SYNRTT and ACKRTT obtained after the three-way handshake.

[0075] (4.2) When the container network interface card parses the data of the second handshake packet, the eBPF Map is updated with the five-tuple of the current data packet as the key and the two-tuple (SYNRTT, current timestamp) as the value. The specific calculation method of SYNRTT is: SYNRTT = current timestamp - current timestamp already existing in eBPF Map.

[0076] (4.3) When the container network interface card parses the data of the third handshake packet, the eBPF Map is updated with the five-tuple of the current data packet as the key and the two-tuple (SYNRTT, ACKRTT) as the value. The specific calculation method of ACKRTT is: ACKRTT = current timestamp - current timestamp already existing in the eBPF Map.

[0077] (5) Send the RTT metric calculated in step (4) to user space through the Perfbuffer (circular buffer) of eBPF.

[0078] (5.1) Create an eBPF Map of type BPF_MAP_TYPE_PERF_EVENT in the kernel space. Its key and value represent the CPU core number and the pmu_fd value of the performance monitor counter (PMC) initialized by the performance monitor unit (PMU) on the core, respectively. Write the RTT metric calculated in step (4) to PerfBuffer (circular buffer) in the kernel through the bpf_perf_event_output function.

[0079] It's important to note that `PerfBuffer` is a circular buffer in eBPF used to push kernel events so that user-space programs can access data from the kernel eBPF. The `bpf_perf_event_output` function is a well-known function in eBPF that pushes events from kernel space to user space. The `pmu_fd` value is the file descriptor for the PMU; Linux assigns such a file descriptor to each device to identify it.

[0080] (5.2) Create a PMC for each CPU in user space and write the corresponding pmu_fd value into the eBPF Map created in step (5.1). User space can implement memory mapping of the Perf Buffer through the mmap mechanism to read the RTT metrics sent from kernel space.

[0081] At this point, the kernel-related programs are complete. They can be compiled into eBPF bytecode using the llvm-clang compiler. The loader logic for the eBPF kernel program is then implemented in user space, responsible for mounting the written eBPF program to the corresponding points in the kernel. These corresponding points refer to the `netif_receive_skb` tracepoint and the `net_hard_start_xmit` kprobe point. llvm-clang is a compiler that can compile eBPF kernel programs into bytecode.

[0082] (6) Analyze, correlate and process the obtained RTT metrics in user space to invalidate data in the tuple that does not pass through the network.

[0083] Specifically, the kernel data obtained is further analyzed, correlated, and processed in user space. Since the TCP three-way handshake packets appear once on each side of the communication, and to reflect the actual network transmission time, the RTT metric should only calculate the RTT latency of packets transmitted through the actual physical network. Specific cases are discussed as follows: For events where the current container initiates the first TCP handshake, ACKRTT is marked as invalid; for events where the current container receives the first TCP handshake, SYNRTT is marked as invalid.

[0084] It should be understood that the obtained RTT metrics are analyzed, correlated, and processed in user space. The SYNRTT and ACKRTT values ​​finally obtained after the three-way handshake are processed, and data that does not pass through the network is invalidated in order to reflect the real container network conditions.

[0085] (7) The event data processed by the user mode in step (6) will be summarized and displayed.

[0086] Specifically, the event data processed in user space in step (6) is transmitted to the Prometheus platform in the form of metrics and visualized using Grafana. The metrics are the average SYNRTT and the average ACKRTT over a period of time.

[0087] It should be understood that the Prometheus platform is an open-source platform that combines monitoring, alerting, and time-series databases. The Prometheus platform has a Grafana component, and monitoring information can be generated through Prometheus and Grafana, thus allowing user-level event data to be visualized on the platform.

[0088] Corresponding to the aforementioned embodiments of the container network TCP connection latency monitoring method based on eBPF, the present invention also provides embodiments of a container network TCP connection latency monitoring device based on eBPF.

[0089] See Figure 3 The present invention provides an eBPF-based container network TCP connection latency monitoring device, which includes one or more processors and a memory, wherein the memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the eBPF-based container network TCP connection latency monitoring method in the above embodiment.

[0090] The embodiment of the container network TCP connection latency monitoring device based on eBPF of this invention can be applied to any device with data processing capabilities, such as a computer or other similar device. The device embodiment can be implemented in software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of any data processing device loading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 3 The diagram shown is a hardware structure diagram of any data processing-capable device where the eBPF-based container network TCP connection latency monitoring device of this invention is located. (Except for...) Figure 3 In addition to the processor, memory, network interface, and non-volatile memory shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0091] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0092] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the present invention according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0093] This invention also provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the eBPF-based container network TCP connection latency monitoring method described in the above embodiments.

[0094] The computer-readable storage medium can be an internal storage unit of any data processing device described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be any data processing device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units of any data processing device and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the data processing device, and can also be used to temporarily store data that has been output or will be output.

[0095] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for monitoring TCP connection latency in container networks based on eBPF, characterized in that, Includes the following steps: (1) Obtain the network card metadata information of the local machine, wherein the network card metadata information includes the mapping relationship between various virtual network cards and network card index numbers; (2) Monitor key events of the Linux kernel protocol stack in the kernel based on the network card metadata information of the local machine, and parse the relevant data packets. The relevant data packets specifically include received data packets and sent data packets to obtain container network card data packet information; (3) Based on the obtained container network card data packet information, establish a mapping from a 5-tuple to a TCP handshake RTT tuple in the kernel through eBPF Map. This mapping is a key-value pair, where the key is a 5-tuple and the key value is a 2-tuple (SYNRTT, ACKRTT). For each data packet passing through the container, determine whether it is a handshake packet by parsing the flag field of its TCP data packet header, and at the same time obtain the current timestamp information. (4) Calculate the round-trip latency of the TCP three-way handshake between Pods based on the handshake packet determined in step (3) and the current timestamp information obtained. (5) Send the RTT metric calculated in step (4) to user space through the ring buffer of eBPF; (6) Analyze, correlate and process the obtained RTT metrics in user space to invalidate data in the tuple that does not pass through the network; (7) The event data processed by the user mode in step (6) will be summarized and displayed.

2. The method for monitoring TCP connection latency in container networks based on eBPF according to claim 1, characterized in that, Step (1) includes the following sub-steps: (1.1) Obtain the corresponding network card index number based on the virtual network card name; (1.2) Establish a mapping relationship between network card index number and network card type, wherein the network card type includes container network card and non-container network card.

3. The method for monitoring TCP connection latency in container networks based on eBPF according to claim 1, characterized in that, Step (2) includes the following sub-steps: (2.1) For the kernel's receiving data packet process, the eBPF program of type TRACEPOINT listens for the netif_receive_skb event and parses the incoming kernel socket to obtain the container network card data packet information during the receiving process. (2.2) For the kernel's data packet sending process, the KPROBE type eBPF program listens for the dev_hard_start_xmit event and parses the incoming kernel socket to obtain the container network card data packet information during the sending process.

4. The method for monitoring TCP connection latency in container networks based on eBPF according to claim 3, characterized in that, The container network interface card (NIC) data packet information includes the 5-tuple of the data packets on the container NIC, the data packet capture timestamp, and the flag field of the TCP data packets; The five-tuple of the data packet on the container network card includes the source IP, destination IP, source port, destination port, and network card index number.

5. The method for monitoring TCP connection latency in container networks based on eBPF according to claim 1, characterized in that, The flag field in the TCP packet header includes the SYN flag for synchronization and the ACK flag for acknowledgment. The method of determining whether a packet is a handshake packet by parsing the flag field of its TCP packet header specifically includes: If SYN=1 and ACK=0, it indicates that this is the first handshake packet; If SYN=1 and ACK=1, it indicates that it is the second handshake packet; If the first data packet with SYN=0 and ACK=1 after the second handshake is the third handshake packet.

6. The method for monitoring TCP connection latency in container networks based on eBPF according to claim 1, characterized in that, Step (4) includes the following sub-steps: (4.1) When the container network card parses the data of the first handshake packet, it stores the five-tuple of the current data packet as the key and the two-tuple (current timestamp, 0) as the key value in the eBPF Map. (4.2) When the container network card parses the data of the second handshake packet, the five-tuple of the current data packet is used as the key and the two-tuple (SYNRTT, current timestamp) is used as the key value to update the eBPF Map; the specific calculation method of SYNRTT is: SYNRTT = current timestamp - current timestamp already existing in eBPF Map; (4.3) When the container network card parses the data of the third handshake packet, the five-tuple of the current data packet is used as the key and the two-tuple (SYNRTT, ACKRTT) is used as the key value to update the eBPF Map; where the specific calculation method of ACKRTT is: ACKRTT = current timestamp - current timestamp already existing in eBPF Map.

7. The method for monitoring TCP connection latency in container networks based on eBPF according to claim 1, characterized in that, Step (5) includes the following sub-steps: (5.1) Create an eBPF Map of type BPF_MAP_TYPE_PERF_EVENT in the kernel space. Its key and key value represent the CPU core number and the pmu_fd value of the performance monitoring counter initialized by the performance monitoring unit on the core, respectively. Write the round-trip delay index calculated in step (4) to the ring buffer in the kernel through the bpf_perf_event_output function. (5.2) Create a PMC for each CPU in user space and write the corresponding pmu_fd value into the eBPF Map created in step (5.1); the user space implements memory mapping of the ring buffer through the mmap mechanism and reads the round-trip latency metrics sent from the kernel space.

8. The method for monitoring TCP connection latency in container networks based on eBPF according to claim 1, characterized in that, The specific steps (7) are as follows: the event data processed by the user space in step (6) is transmitted to the Prometheus platform in the form of Metrics and visualized using Grafana.

9. A container network TCP connection latency monitoring device based on eBPF, comprising one or more processors and a memory, characterized in that, The memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the container network TCP connection latency monitoring method based on eBPF as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, It stores a program that, when executed by a processor, is used to implement the eBPF-based container network TCP connection latency monitoring method according to any one of claims 1-8.

Images