A request tracking method and device, a storage medium and a computer device

Abstract

This application provides a request tracing method, apparatus, storage medium, and computer device. The method includes: for any service node in a microservice system, using an eBPF program deployed on the service node, capturing data packets corresponding to requests in the kernel space of the service node's operating system; determining, based on the currently maintained connection state table, whether the target connection corresponding to the data packet is a new connection; if so, performing type parsing on the data packet in the kernel space to determine the target protocol type used by the target connection; determining the feature extraction position for the data packet from the kernel space and user space based on the target protocol type, and extracting the metadata features of the data packet at the feature extraction position; and generating span data corresponding to each request in the user space based on the metadata features of each captured data packet.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a request tracking method, apparatus, storage medium, and computer device. Background Technology

[0002] With the development of cloud-native technologies, microservice architecture has become a common architecture for building large-scale distributed systems. In microservice architecture, a single application is broken down into a large number of loosely coupled microservice components and deployed on different microservice nodes. Different microservice components interact through network calls (such as Remote Procedure Calls, RPCs) and application programming interfaces (APIs) that follow representational state transfer (RESTful APIs) to process user requests. Although microservice architecture improves the scalability and development agility of distributed systems, it also greatly increases the complexity of system operation and maintenance and fault diagnosis. For example, when system performance degradation or request failure occurs, system failures often propagate through complex call chains of microservice nodes, posing a significant challenge to locating the root cause of the failure. To address this challenge, non-intrusive distributed request tracing systems are currently commonly used. These systems parse the data packets corresponding to requests and construct span models to achieve request tracing and fault location in microservice systems.

[0003] However, current non-intrusive distributed request tracing systems either suffer from high data transfer overhead between kernel space and user space when parsing data packets and constructing the span corresponding to the request, or they have limited parsing capabilities due to kernel security restrictions, thus failing to accurately construct the span. They cannot achieve a performance balance between data transfer overhead and parsing capabilities. Summary of the Invention

[0004] In view of this, this application provides a request tracing method, apparatus, storage medium, and computer device to improve the accuracy of span construction while reducing the data transfer overhead between kernel space and user space, thereby achieving a performance balance between data transfer overhead and parsing capability.

[0005] Specifically, this application is implemented through the following technical solution: In a first aspect, embodiments of this disclosure provide a request tracing method, including: For any service node in a microservice system, the extended Berkeley packet filter (eBPF) program deployed on the service node is used to capture the data packets corresponding to the request in the operating system kernel space of the service node. Based on the currently maintained connection status table, determine whether the target connection corresponding to the data packet is a new connection; If so, the data packet is type-parsed in the kernel space to determine the target protocol type used by the target connection; Based on the target protocol type, the feature extraction location for the data packet is determined from the kernel space and user space, and the metadata features of the data packet are extracted at the feature extraction location; In user space, span data corresponding to each request is generated based on the metadata characteristics of each captured data packet; the span data is used to construct the request tracing chain in the microservice system.

[0006] In one possible implementation, the step of performing type parsing on the data packet in the kernel space to determine the target protocol type used by the target connection includes: Retrieve the protocol type templates and metadata templates set for various non-multiplexed protocol types; In the kernel space, each protocol type template is traversed sequentially according to a preset traversal order, and for the target offset indicated by the currently traversed protocol type template, byte features that match the target offset are extracted from the data packet. Based on the byte characteristics and the metadata characteristic information indicated by the metadata template corresponding to the currently traversed protocol type template, determine whether the data packet matches the currently traversed protocol type template; If not, continue traversing the next protocol type template until a target protocol type template matching the data packet is determined, and the target protocol type is determined to be a non-multiplexed protocol type, or until all protocol type templates have been traversed, and the target protocol type is determined to be a multiplexed protocol type.

[0007] In one possible implementation, determining the feature extraction location for the data packet from kernel space and user space based on the target protocol type, and extracting the metadata features of the data packet at the feature extraction location, includes: When the target protocol type is a non-multiplexing protocol type, the feature extraction location is determined to be the kernel space; Based on the matching time between the data packet and the target protocol type template, the arrival time of the data packet is determined, and the network features of the data packet are extracted in the kernel space according to the byte offset range indicated by the target protocol type template. In the kernel space, the five-tuple corresponding to the data packet is determined based on the target connection corresponding to the data packet, and the context information of the data packet is determined based on the arrival time of the data packet and the five-tuple. The network characteristics and context information of the data packet are sent to the user space as the metadata characteristics.

[0008] In one possible implementation, determining the feature extraction location for the data packet from kernel space and user space based on the target protocol type, and extracting the metadata features of the data packet at the feature extraction location, includes: If the target protocol type is a multiplexing protocol type, the feature extraction location is determined to be user space; The data packet is forwarded to the user space, and the protocol library resources set in the user space are used to perform feature decoding and extraction on the data packet to obtain the network features of the data packet; The context information of the data packet is determined based on the extraction time of the network features and the target connection corresponding to the data packet; The network characteristics and context information of the data packet are used as the metadata characteristics.

[0009] In one possible implementation, the method further includes: If the target connection corresponding to the data packet is not a new connection, the target protocol type is determined according to the protocol type stored for the target connection in the currently maintained connection state table.

[0010] In one possible implementation, generating span data corresponding to each request in user space based on the metadata characteristics of each captured data packet includes: In the user space, each metadata feature is divided into different time windows based on the context information corresponding to each captured metadata feature; For each time window, span data corresponding to each request under the time window is generated based on the metadata characteristics of each time window.

[0011] In one possible implementation, generating span data corresponding to each request within the time window based on various metadata features within the time window includes: For each first metadata feature within the time window and for each target protocol type that is a non-multiplexed protocol type, based on each first metadata feature and the strictly sequential interaction feature between requests and responses under the non-multiplexed protocol type, the span data corresponding to each request-response pair is constructed. For each second metadata feature within the time window and whose target protocol type is multiplexing protocol, the span data corresponding to each request-response pair is constructed based on each second metadata feature and the protocol differentiation attribute carried in the protocol header of the data packet corresponding to the second metadata feature.

[0012] In one possible implementation, after performing type resolution on the data packet in the kernel space to determine the target protocol type used by the target connection, the method further includes: Update the currently maintained connection state table based on the target connection and the target protocol type used by the target connection; The updated connection state table is used as the new currently maintained connection state table; wherein, the new currently maintained connection state table is used to determine whether the target connection corresponding to the newly captured data packet is a new connection.

[0013] Secondly, embodiments of this disclosure also provide a request tracking device, the device comprising: The capture module is used to capture data packets corresponding to requests in the operating system kernel space of any service node in the microservice system, using an extended Berkeley packet filter (eBPF) program deployed on the service node. The determination module is used to determine whether the target connection corresponding to the data packet is a new connection based on the currently maintained connection status table; The parsing module is used to perform type parsing on the data packet in the kernel space if the condition is met, and to determine the target protocol type used by the target connection. The extraction module is used to determine the feature extraction position for the data packet from the kernel space and user space according to the target protocol type, and extract the metadata features of the data packet at the feature extraction position; The generation module is used to generate span data corresponding to each request in user space based on the metadata characteristics of each captured data packet; the span data is used to construct the request tracing chain in the microservice system.

[0014] Thirdly, an optional implementation of this disclosure also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the first aspect above, or any possible implementation of the first aspect.

[0015] Fourthly, an optional implementation of this disclosure also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps as described in the first aspect above, or any possible implementation of the first aspect.

[0016] The request tracing method, apparatus, storage medium, and computer device provided in this disclosure utilize a connection state table to determine the target connection corresponding to the captured data packets. This saves computational resources consumed by parsing the data packets for the target protocol type when the target connection is an old connection. Based on the target protocol type of the target connection, feature extraction locations are determined from kernel space and user space. This allows for intelligent routing of data packet parsing to different paths based on the target protocol type. This avoids the high data transmission overhead caused by importing the entire data packet into user space for parsing in traditional methods, and also avoids the problem of insufficient kernel space parsing capabilities preventing the parsing of data packets under the specified protocol type, thus ensuring parsing accuracy. In summary, this application breaks through the single mode of traditional distributed tracing systems that rely on full user space parsing. Through a dynamic diversion mechanism based on protocol characteristics, data packets are selectively imported into kernel space or user space for parsing. This avoids memory copying and context switching of invalid data from kernel space to user space, fundamentally reducing the performance overhead of data acquisition. It also overcomes kernel limitations in the eBPF environment, achieving accurate parsing of data packets under the specified payload protocol type, thus achieving a performance balance between data transmission overhead and parsing capability.

[0017] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] Figure 1a This is a schematic diagram illustrating a communication process between microservice components according to an exemplary embodiment of this application; Figure 1b This is a schematic diagram illustrating a span tree according to an exemplary embodiment of this application; Figure 2 This is a flowchart illustrating a request tracing method in an exemplary embodiment of this application; Figure 3a This is a schematic diagram illustrating a connection update process according to an exemplary embodiment of this application; Figure 3b This is a schematic diagram illustrating the data packet parsing process under a multiplexing protocol type, as shown in an exemplary embodiment of this application; Figure 3cThis is a schematic diagram illustrating the data packet parsing process under a non-multiplexing protocol type, as shown in an exemplary embodiment of this application; Figure 4 This is a schematic diagram illustrating a request tracking device according to an exemplary embodiment of this application; Figure 5 This is a schematic diagram of the structure of a computer device shown in an exemplary embodiment of this application. Detailed Implementation

[0019] 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 denote 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.

[0020] 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.

[0021] 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," "when," or "in response to determination."

[0022] Research has revealed two traditional approaches to tracing request flows in microservice architectures: one relies on intrusive code instrumentation in distributed system tracing, such as Dapper and Zipkin; the other is non-intrusive distributed system tracing, such as DeepFlow (a cloud monitoring and analysis platform) and Traceweaver (a tracing weaver). Intrusive code instrumentation requires developers to modify business logic code within the microservice architecture or manually inject tracing context into service nodes. This not only incurs high maintenance costs but also makes it difficult to cover legacy systems that are not open-source or that do not allow / support code instrumentation for third-party components. Furthermore, in a microservice architecture, each microservice component is independent, allowing the development team to choose the most suitable programming language based on the specific needs of that component. In practice, microservice components iterate extremely rapidly. Using traditional intrusive instrumentation methods requires cross-team collaboration and source code modification, resulting in high costs and maintenance difficulties. This necessitates a non-intrusive tracing system, capable of tracing the entire request path without modifying any business logic code. Therefore, in recent years, non-intrusive distributed system tracing methods, utilizing Extended Berkeley Packet Filter (eBPF) for request tracing, have gradually become the mainstream research and application direction due to their transparency and kernel-level observability. Typically, non-intrusive distributed systems commonly use a span-based model to construct request records. A span encapsulates the execution lifecycle of a request within a single microservice component, usually represented as a request-response pair. For example... Figure 1a The diagram illustrates a communication process between microservice components according to an embodiment of this application. A user can initiate a request R1 to the frontend. While processing R1, the frontend can initiate a request R2 to the backend and a request R3 to the non-relational database MongoDB. The backend can, for example, be a service node where a microservice component resides. The backend can generate a response S2 corresponding to R2 and send it back to the frontend. MongoDB can generate a response S3 corresponding to R3 and send it back to the frontend. The frontend can then generate a response S1 for R1 based on S2 and S3 and send it back to the user. Figure 1a For the communication process shown, a span-based request trace tree can be constructed, such as... Figure 1b The diagram shown is a schematic representation of a span tree provided in an embodiment of this application. Figure 1b The span tree shown is for Figure 1aThe communication process shown is constructed as follows: Span1((R1, S1)) represents the span data corresponding to the front end, Span2((R2, S2)) represents the span data corresponding to the back end, and Span3((R3, S3)) represents the span data corresponding to MongoDB. Each span also contains request metadata, such as request start time, response end time, API endpoint, resource utilization, etc. The timeline between spans is determined based on the earliest start time and latest end time of each span, and a parent-child relationship exists between spans, which reflects the causal relationship between different spans. For example, the parent-child relationship R1→R2 indicates that R2 was called during the processing of R1; the parent-child relationship R1→R3 indicates that R3 was called during the processing of R1.

[0023] However, as the scale of microservice components and service nodes in a microservice architecture continues to increase, the scale of requests in the microservice architecture grows exponentially. Coupled with the increasing diversity of network protocols, this presents a severe challenge to distributed tracing. Although non-intrusive tracing solutions based on technologies such as eBPF have significant advantages, the following core challenges still need to be overcome in the process of deploying them in large-scale production environments: 1. To cope with diverse business scenarios and performance standards, microservice systems employ various network protocols, such as Hypertext Transfer Protocol (HTTP) / 1.x, MySQL, Redis, MongoDB, Kafka, Google Remote Procedure Call (gRPC), HTTP / 2, and others. These network protocols differ in their technical attributes and development complexity. To achieve accurate request tracing, the tracing system must be able to efficiently process these independent protocols to identify potential errors (such as malicious requests or configuration errors).

[0024] 2. Implementing end-to-end monitoring for microservices presents significant challenges. Specifically, to improve the performance of microservice architectures, they widely employ multithreading or asynchronous I / O mechanisms to handle concurrent requests. When a large number of threads run simultaneously to process requests, the processing order becomes highly unpredictable. In non-intrusive tracing models, the lack of explicitly passed context identifiers (IDs) from the application layer makes accurately associating numerous requests with responses a major challenge. Incorrect request associations can lead to abnormal tracing structures or loss of faulty data, severely weakening the effectiveness of the tracing system in fault diagnosis and performance debugging.

[0025] To address these two challenges, existing non-intrusive tracing technologies have evolved into two main solutions. The first is a user-space-based full-data parsing solution (such as DeepFlow and DeepTrace). These solutions utilize eBPF programs to intercept network packets in the operating system kernel within kernel space and copy all network packets to user space for parsing. While this mechanism can leverage the rich protocol library resources in user space to accurately parse each network packet, it suffers from significant drawbacks in high-concurrency scenarios. The full network packet copying leads to frequent kernel-user space context switching and high data transmission overhead, causing a surge in microservice system load. Furthermore, if the parsing process in user space experiences processing delays, the data packet buffer in kernel space can quickly overflow, resulting in the loss of critical tracing data and compromising the integrity of the call chain.

[0026] The second approach is a pure kernel-mode parsing scheme, which attempts to completely offload the parsing logic of all application-layer protocols into the eBPF program. However, to ensure kernel security, the eBPF virtual machine in kernel space imposes strict constraints on the total number of instructions, loop depth, and memory access of eBPF programs. This makes it extremely difficult and unreliable to build eBPF programs in the kernel specifically for complex protocols (such as HTTP / 2 Header Compression Algorithm (HPACK) decompression or Transmission Control Protocol (TCP) out-of-order reordering state machines), thus making accurate parsing of complex protocol packets within kernel space impossible. Furthermore, the kernel parsing logic corresponding to hard-coded eBPF programs lacks extensibility and struggles to adapt to the rapid iteration of protocol versions or the need for custom protocols in microservice architectures, resulting in poor flexibility.

[0027] Therefore, it is evident that the two existing non-intrusive tracking solutions struggle to strike a balance between tracking performance overhead and flexibility.

[0028] Based on the above research, this disclosure provides a request tracing method, apparatus, storage medium, and computer device. It utilizes a connection state table to determine the target connection corresponding to the captured data packets, saving computational resources consumed by parsing the target protocol type of the data packets when the target connection is an old connection. By determining the feature extraction location from kernel space and user space based on the target protocol type of the target connection, it can intelligently guide the parsing of data packets to different paths based on the target protocol type. This avoids the large data transmission overhead caused by importing the entire data packet into user space for parsing in traditional methods, and also avoids the problem of insufficient kernel space parsing capabilities, which prevents the parsing of data packets under the specified protocol type, thus ensuring parsing accuracy. In summary, this application breaks through the single mode of traditional distributed tracing systems that rely on full user space parsing. Through a dynamic diversion mechanism based on protocol characteristics, it selectively imports data packets into kernel space or user space for parsing. This avoids memory copying and context switching of invalid data from kernel space to user space, fundamentally reducing the performance overhead of data acquisition. It also overcomes the kernel limitations in the eBPF environment, achieving accurate parsing of data packets under the specified payload protocol type, thus achieving a performance balance between data transmission overhead and parsing capability.

[0029] The shortcomings of the above solutions are the result of the inventor's practical experience and careful research. Therefore, the discovery process of the above problems and the solutions proposed in this disclosure below are all contributions made by the inventor to this disclosure.

[0030] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0031] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0032] To facilitate understanding of this embodiment, a request tracing method disclosed in this disclosure will first be described in detail. The execution subject of the request tracing method provided in this disclosure is generally a terminal device or other processing device with certain computing power. The terminal device can be a user equipment (UE), a mobile device, a terminal, a personal digital assistant (PDA), a handheld device, a computer device, a server, a microservice node in a microservice architecture, etc. In some possible implementations, the request tracing method can be implemented by the processor calling computer-readable instructions stored in memory.

[0033] The following describes the request tracing method provided in this embodiment, taking a microservice node as the execution subject as an example.

[0034] like Figure 2 The flowchart shown is a request tracing method provided in an embodiment of this disclosure, which may include the following steps: S201: For any service node in a microservice system, use the extended Berkeley packet filter eBPF program deployed on the service node to capture the data packets corresponding to the request in the operating system kernel space of the service node.

[0035] First, it should be noted that the request tracing method provided in this application is a tracing method applied in a microservice architecture, capable of tracing requests corresponding to microservice components deployed on various service nodes in a microservice architecture. A service node can be a host in a microservice architecture, and a service node can be used to run at least one microservice component, with different microservice components corresponding to different application functions.

[0036] The eBPF program can be a pre-written program that is triggered to execute when a service node makes an API call. It captures the data packets corresponding to the request in the operating system kernel space and determines whether to directly parse the packets or send them to user space based on the protocol type used. The eBPF program can be implemented using a smart agent. One agent can be deployed on each service node, and each service node can utilize the eBPF program carried by its deployed agent to implement the request tracing method provided in this application embodiment.

[0037] Since the execution process of each service node in implementing the request tracing method provided in this application embodiment is similar, the following description will use a service node in a microservice architecture as the execution subject to illustrate the request tracing method provided in this application embodiment: In practical implementation, for any service node, raw traffic (i.e., data packets) can be collected through an Agent deployed on the service node. At the data collection level, considering the characteristic that "communication between microservice components must rely on transport layer API calls," this application pre-selects a set of key system calls closely related to network communication (such as read calls, write calls, socket-directed send functions (sendto), socket-directed receive functions (recvfrom), etc.) as monitoring anchors. After initializing the customized eBPF program, the Agent deployed on the service node hooks the eBPF program to each key network call via kernel hooks, thus eliminating the need to modify any application code or restart the service. When a network system call occurs on the service node (such as when any of the aforementioned key system calls is triggered), it can be determined that data packet sending and receiving behavior has occurred on the service node. At this time, the eBPF program carried by the Agent deployed on the service node can be automatically triggered. Then, using the eBPF program, the data packets corresponding to the request are captured in real time in the operating system kernel space of the service node, achieving zero-intrusion monitoring. A data packet is specifically a captured data message. One data packet can correspond to one or more requests, or multiple requests can correspond to one data packet.

[0038] S202: Based on the currently maintained connection state table, determine whether the target connection corresponding to the data packet is a new connection.

[0039] Here, the connection state table is used to dynamically maintain the real-time connection status of various network connections on the service node. These network connections can be, for example, socket connections. Specifically, the connection state table can be an eBPF map maintained in the service node's kernel space. The eBPF map can include key-value pairs corresponding to different network connections. The key can be the process ID of the process corresponding to the network connection, the offset file descriptor corresponding to the network connection, and the value can be information such as the 5-tuple, sequence number, connection direction, protocol type, and connection liveness status of the network connection. The key-value pairs corresponding to the network connections thus represent the connection status of the network connections.

[0040] A new connection is a network connection that does not appear in the currently maintained connection state table. The target connection is the network connection used by the currently captured data packet.

[0041] In practical implementation, a connection tracing module can be used to maintain the connection status of each network connection in the kernel space of the service node using a connection state table. After capturing any data packet, the file descriptor and / or process ID of the target connection corresponding to that data packet can be determined. Based on the file descriptor and / or process ID, it can be determined whether a matching network connection exists in the currently maintained connection state table. If not, the target connection is determined to be a new connection, and then the following step S203 can be executed to determine the target protocol type of the target connection.

[0042] If a matching network connection exists, the target connection is determined to be an old connection. Then, based on the key-value pairs associated with the target connection in the connection state table, the target protocol type used by the target connection can be determined. The target protocol type can be one of two preset protocol types, determined in advance based on the complexity of the network protocol and the order of request interactions on the network connection. Specifically, these can include non-multiplexing protocols and multiplexing protocols. Non-multiplexing protocols, for example, can include HTTP / 1.x, MySQL, Redis, MongoDB, Kafka, etc. This protocol type requires that requests and responses be strictly sequential within a single network connection; that is, the request-response pattern is typically serial or pipelined. Multiplexing protocols, for example, can include gRPC, HTTP / 2, RESTful API, Database Calls, etc. This protocol type supports the concurrent transmission of multiple out-of-order request streams on a single connection; that is, the order of requests and responses is out of order.

[0043] S203: If so, perform type parsing on the data packet in the kernel space to determine the target protocol type used by the target connection.

[0044] In practice, if the target connection is determined to be a new connection, the data packet can be forwarded to the kernel parsing module in the kernel space. This module uses the ePBF program to perform type parsing on the data packet, determining the target protocol type used by the target connection from two preset protocol types. Specifically, if the protocol type can be directly parsed during type parsing, it can be used as the target protocol type; otherwise, the multiplexing protocol type can be used as the target protocol type for the target connection.

[0045] Furthermore, after executing S203, the currently maintained connection state table can be updated according to the target connection and the target protocol type used by the target connection; the updated connection state table is used as the new currently maintained connection state table; wherein, the new currently maintained connection state table is used to determine whether the target connection corresponding to the newly captured data packet is a new connection.

[0046] Specifically, for any data packet corresponding to a target connection, after determining that the target connection is a new connection and resolving the target protocol type used by the target connection in the kernel space, a key-value pair corresponding to the target connection can be constructed and stored in the currently maintained connection state table based on the process ID, file descriptor, target protocol type, and metadata features extracted later. This ensures that new connections are updated to the connection state table in a timely manner, completing the timely recording of information such as new connections and their target protocol types. Storing the key-value pairs corresponding to the target connections in the currently maintained connection state table also achieves timely updates to the currently maintained connection state table, resulting in an updated connection state table. Furthermore, the updated connection state table can be used as the new currently maintained connection state table, so that when new data packets are captured subsequently, the latest currently maintained connection state table can be used to determine whether the target connection corresponding to a newly captured data packet is a new connection. In this way, whenever a new connection is detected, the currently maintained connection state table is updated using the new connection, ensuring that the key-value pairs corresponding to each new connection are promptly added to the connection state table, thereby improving the timeliness of the information stored in the connection state table.

[0047] S204: Based on the target protocol type, determine the feature extraction location for the data packet from the kernel space and user space, and extract the metadata features of the data packet at the feature extraction location.

[0048] Here, different feature extraction locations correspond to different packet parsing paths. When the feature extraction location is in kernel space, it can be determined as a kernel-mode parsing path, which indicates that the metadata extraction of the packet is completed within kernel space. When the feature extraction location is in user space, it can be determined as a user-mode parsing path, which indicates that the metadata extraction of the packet is completed within user space. Metadata features are used to indicate the metadata information corresponding to the packet and its target connection. Specifically, this can include network features and context information. Network features may include, but are not limited to, the target protocol type used by the target connection, the operation type, the packet sequence number, the request ID corresponding to the packet, etc. The operation type indicates whether the packet corresponds to a request or a response. Context information may include, but is not limited to, the target connection's five-tuple, timestamp, process ID, file descriptor, etc.

[0049] This application considers the significant differences in packet structure and session management among different application layer protocols in the network traffic of service nodes, and proposes a dual-path protocol feature parsing mechanism. Based on whether the network connection protocol type supports multiplexing, this mechanism divides the packet feature extraction process into the following two independent parsing paths: 1. Kernel Space Fast Path (i.e., Kernel-mode Resolution Path): For non-multiplexed protocol types (such as HTTP / 1.x, MongoDB, etc.), since the request-response model in network connections under this type is mostly serial or simple pipeline mode, the packet boundaries are clear and the state maintenance cost is low, this application adopts eBPF technology to directly complete the protocol header identification of the data packet in kernel mode and extract metadata features in the identified protocol header, thereby avoiding the expensive data transmission overhead of copying massive raw data packets to user space, as well as avoiding the context switching overhead between user space and kernel space.

[0050] 2. User-space slow path (i.e., user-space resolution path): For multiplexed protocol types (such as HTTP / 2, gRPC, Dubbo, etc.), given the complex binary framing, header compression (HPACK / QPACK), and flow state management mechanisms of data packets under this type, and limited by the strict constraints of the kernel eBPF instruction set size and memory verification, this application chooses to copy data packets under this type to user space on demand, and use the rich resource library and logical flexibility of user space for deep decoding to accurately extract metadata features.

[0051] Thus, the distributed request tracing architecture based on dual-path protocol feature parsing in kernel and user space proposed in this application, compared with traditional schemes such as Deepflow and DeepTrace that use "full data packet parsing in user space," can achieve extreme performance optimization for non-multiplexed protocol types while ensuring full functional support for multiplexed protocol types. By minimizing invalid data movement and context switching under non-multiplexed protocol types, the CPU and memory acquisition overhead of service nodes is reduced, achieving the best balance between high-performance acquisition and high protocol compatibility.

[0052] In the specific implementation of S204 above, after determining the target protocol type of the target connection corresponding to the data packet, the feature extraction position matching the target parsing path can be determined from both kernel space and user space based on the target parsing path that matches the target protocol type. For example, if the target protocol type is a non-multiplexed protocol type, the target parsing path is a fast path in kernel space, and the feature extraction position is in kernel space; if the target protocol type is a multiplexed protocol type, the target parsing path is a slow path in user space, and the feature extraction position is in user space. After determining the feature extraction position, the data packet can be parsed and features extracted at the feature extraction position to obtain various metadata features corresponding to the data packet.

[0053] S205: In user space, based on the metadata characteristics of each captured data packet, span data corresponding to each request is generated; the span data is used to construct the request tracing chain in the microservice system.

[0054] Here, span data is used to indicate the trace information corresponding to a request-response pair, with one span data point per request-response pair. Span data may include, but is not limited to, information such as request start time, response end time, API endpoint, and resource utilization. The request trace chain is used to indicate the call order between different requests within a service node; specifically, the request trace chain can be a span tree built based on the various span data points.

[0055] In practice, after extracting metadata features at the feature extraction location, these features can be stored in the user space. Then, using the Agent in the service node, Span data corresponding to each request in different time windows can be generated based on the metadata features stored in different preset time windows. Subsequently, existing request tracing chain construction technology can be used to construct request tracing chains between service nodes based on the Span data corresponding to each service node in each time window.

[0056] Alternatively, regarding the metadata features corresponding to each data packet aggregated in user space, we can first divide each metadata feature into first metadata features under the non-multiplexing protocol type and second metadata features under the multiplexing protocol type, based on the target protocol type corresponding to each data packet. Then, for each first metadata feature, given the characteristic of the non-multiplexing protocol type strictly maintaining the request-response order within a single network connection, we can determine the response sequence and request sequence based on the operation type in each first metadata feature. Then, we can perform sequential matching according to the sequence numbers of each first metadata feature in the response sequence and the sequence numbers of each first metadata feature in the request sequence to obtain the span data corresponding to each request-response pair. For each second metadata feature, due to the characteristic of request-response interleaved transmission on a single network connection under the multiplexing protocol type, we can accurately match the span data corresponding to each request-response pair based on each second metadata feature and the distinguishing attributes embedded in the message header of each data packet corresponding to the second metadata feature (e.g., query ID in the DNS protocol, stream identifier in the HTTP / 2 protocol).

[0057] In this way, by aggregating the metadata features of data packets under various protocol types in the user space, and using the timestamps, 5-tuples, protocol types, and other information indicated by the metadata features, discrete requests and responses within the service node can be paired and accurately assembled into a complete distributed request tracing span, thereby achieving accurate tracing of each request in the service node.

[0058] In one embodiment, considering that the eBPF virtual machine imposes strict constraints on the total number of instructions, loop depth, and memory access to ensure kernel security, a deterministic parsing mechanism based on protocol type templates and metadata templates is proposed for the process of parsing data packets in kernel space, aiming to overcome the kernel security restrictions of eBPF. Specifically, the step of "determining the target protocol type" in S203 above can be implemented according to the following steps A1 to A4: A1: Retrieves the protocol type template and metadata template set for various non-multiplexed protocol types.

[0059] Here, since the kernel space can be used not only for type resolution but also for metadata extraction from data packets under non-multiplexed protocol types, protocol type templates and metadata templates can be pre-set for each non-multiplexed protocol type based on the analysis of publicly available protocol specifications such as Request for Comments (RFCs). Different non-multiplexed protocol types can correspond to different RFC protocol specifications. The protocol type template indicates the target offset within the data packet for the byte features to be extracted under the corresponding type. A protocol type template can include one or more target offsets. The metadata template indicates the preset metadata feature information of the data packet under the corresponding type at the target offset. The preset metadata feature information can be, for example, a preset enumeration value at the target offset. For instance, for the OpCode byte at bytes 12-16 of a MongoDB protocol type data packet, the preset metadata feature information in the metadata template could be OP_INSERT and OP_DELETE.

[0060] A non-multiplexed protocol type corresponds to one protocol type template and one metadata template. For example, the MongoDB protocol type corresponds to protocol type template 1 and metadata template 1, the HTTP / 1.x protocol type corresponds to protocol type template 2 and metadata template 2, and the MySQL protocol type corresponds to protocol type template 3 and metadata template 3.

[0061] In practice, for any new connection's data packet, the protocol type template and metadata template that are pre-set for various non-multiplexing protocol types can be obtained first.

[0062] A2: In the kernel space, each protocol type template is traversed sequentially according to the preset traversal order, and for the target offset indicated by the currently traversed protocol type template, the byte features that match the target offset are extracted from the data packet.

[0063] Here, the preset traversal order is used to indicate the order in which the templates of each protocol type are matched. This order can be set based on experience, and this embodiment does not impose specific limitations. For example, the preset traversal order of the templates of each protocol type can be determined according to the complexity of the various non-multiplexing protocol types. The target offset is the offset position that the protocol type template indicates needs to extract. The byte feature is the message feature extracted from the target offset of the data packet.

[0064] In practice, the protocol type templates corresponding to each non-multiplexing protocol type can be traversed sequentially in the kernel space according to a preset traversal order. For any currently traversed protocol type template, the byte features carried by the data packet can be extracted from the corresponding position of the data packet based on the target offset indicated by the protocol type template, so as to match the actual byte features carried by the data packet with the metadata value template.

[0065] A3: Based on the byte characteristics and the metadata characteristic information indicated by the metadata template corresponding to the currently traversed protocol type template, determine whether the data packet matches the currently traversed protocol type template.

[0066] Here, the metadata template corresponding to the protocol type template being traversed refers to the metadata template set for the non-multiplexed protocol type corresponding to the protocol type template being traversed.

[0067] In practice, the byte features extracted from the data packet can be matched with the metadata feature information indicated by the metadata template corresponding to the currently traversed protocol type template. The matching result determines whether the data packet matches the currently traversed protocol type template. For example, if the byte features match the metadata feature information, it can be determined that the data packet matches the currently traversed protocol type template, and traversal stops; if the byte features do not match the metadata feature information, it is determined that the data packet matches the currently traversed protocol type template, and traversal continues to the next protocol type template.

[0068] Understandably, if the currently traversed protocol type template has multiple target offsets, such as bytes 10-15, bytes 20-23, etc., then the byte features of bytes 10-15 and bytes 20-23 can be extracted from the data packet. Then, it is determined whether the preset metadata information set for bytes 10-15 in the metadata template matches the byte features of bytes 10-15, and whether the preset metadata information set for bytes 20-23 in the metadata template matches the byte features of bytes 20-23. If the byte features at both target offsets match, the data packet is determined to match the currently traversed protocol type template, and this protocol type template is taken as the target protocol type template corresponding to the data packet. The non-multiplexed protocol type corresponding to this protocol type template is taken as the target protocol type of the data packet. If the byte features at both target offsets do not match, then the data packet is determined not to match the currently traversed protocol type template.

[0069] A4: If not, continue traversing the next protocol type template until a target protocol type template matching the data packet is determined, and the target protocol type is determined to be a non-multiplexed protocol type, or until all protocol type templates have been traversed and the target protocol type is determined to be a multiplexed protocol type.

[0070] Here, the target protocol type template is a protocol type template that matches the data packet.

[0071] In practice, if it is determined that the currently traversed protocol type template does not match the data packet, it can be determined whether there is an untraversed protocol type template. If not, it can be determined that all protocol type templates have been traversed and there is no target protocol type template that matches the data packet. At this time, the target protocol type can be determined to be a multiplexing protocol type. If yes, the next protocol type template can be traversed, and the step of "extracting the byte features that match the target offset from the data packet for the target offset indicated by the currently traversed protocol type template" in A2 above can be returned until a target protocol type template that matches the data packet is determined from all protocol type templates. At this time, the target protocol type of the data packet can be determined to be a non-multiplexing protocol type. Alternatively, in the process of looping, until all protocol type templates have been traversed, if the last traversed protocol type template also does not match, the target protocol type can be determined to be a multiplexing protocol type.

[0072] In this way, by traversing various protocol type templates in the kernel space, microsecond-level inference of the protocol type of unknown data packets can be achieved. Thus, the template-based deterministic protocol fingerprinting technology proposed in this application for a constrained eBPF environment utilizes lightweight type parsing of "protocol type templates" and "metadata templates," abandoning traditional and expensive regular expression matching and string traversal, and achieving fast fingerprint matching based on fixed offsets and feature keywords (i.e., byte features). By pre-analyzing the protocol rules under the RFC standard, protocol type templates and byte type templates for data packets under various non-multiplexed protocol types are accurately constructed, enabling accurate identification of methods (such as GET / POST) and key protocol headers under various protocol type data packets. This achieves microsecond-level protocol feature extraction while meeting the security requirements of the kernel verifier.

[0073] In one embodiment, since this application proposes a "kernel-user space" dual-path adaptive traffic splitting architecture based on protocol type multiplexing characteristics, the specific parsing process of the parsing path under the two traffic splitting architectures will be described below: When the data packet type is not a multiplexing protocol type, the above S204 can be implemented as follows (B1~B4): B1: When the target protocol type is a non-multiplexed protocol type, the feature extraction location is determined to be the kernel space.

[0074] Here, this application leverages an Agent deployed on service nodes to construct a dual-path processing architecture that coordinates kernel and user space without modifying the application source code throughout the entire process. The Agent first establishes an adaptive traffic splitting mechanism at the kernel layer, intelligently guiding data packets to different parsing paths based on the target protocol type. Specifically, when the target protocol type is a non-multiplexed protocol, such as HTTP / 1.x or MySQL, the data packet parsing can be directed to a fast kernel space parsing path, allowing parsing to be completed directly within the eBPF environment. Therefore, the feature extraction location can be determined to be in kernel space.

[0075] B2: Based on the matching time between the data packet and the target protocol type template, determine the arrival time of the data packet, and extract the network features of the data packet in the kernel space according to the byte offset range indicated by the target protocol type template.

[0076] The network characteristics can include at least the request identifier, operation type, and sequence number of the data packet.

[0077] In practical implementation, under the fast resolution path in kernel space, the matching time between the data packet and the target protocol type template can be used as the arrival time of the data packet (i.e., as the timestamp of the data packet). This arrival time can be used as the request arrival time if the data packet corresponds to a request, and as the response end time if the data packet corresponds to a response. Simultaneously, based on the various byte offset ranges defined by the target protocol type template, data packet information at each byte offset range can be extracted from the data packet. This includes information such as the request identifier, operation type, and sequence number corresponding to the data packet, and these data packet information can be used as network features. The byte offset range can be any target offset defined by the target protocol type template, or it can be an offset range different from the target offset. For example, the byte offset range can indicate the protocol header position of the data packet. The operation type indicates whether the data packet corresponds to a request or a response.

[0078] B3: In kernel space, determine the 5-tuple corresponding to the data packet based on the target connection corresponding to the data packet, and determine the context information of the data packet based on the arrival time and the 5-tuple corresponding to the data packet.

[0079] Here, context information is used to indicate the environmental context corresponding to the data packet, such as including but not limited to the data packet's arrival time, 5-tuple, process ID, file descriptor, etc.

[0080] In practice, if the target connection is a new connection, the eBPF program can extract the five-tuple information of the target connection in kernel space to obtain the five-tuple corresponding to the target connection. This five-tuple can then be used as the five-tuple of the currently captured data packet. If the target connection is an old connection, the five-tuple of the target connection can be obtained from the connection state table and used as the five-tuple of the currently captured data packet. Then, the context information of the data packet can be generated based on the five-tuple corresponding to the data packet and its arrival time.

[0081] Understandably, because the number of network system calls in the operating system kernel does not strictly correspond one-to-one with the number of requests or responses, a single data packet may carry information for multiple requests / responses, or multiple requests / responses may correspond to a single data packet. For example, if the request payload is small, multiple requests will be merged into a single data packet for invocation; if the request payload is large, a single request will be split into multiple data packets for invocation. Therefore, during data packet parsing in kernel space, if a data packet corresponds to multiple requests / responses, it can be split into multiple data packets corresponding to each request / response in kernel space, and the network characteristics and context information corresponding to each data packet can be determined. If multiple data packets correspond to a single request / response, they can be merged into a single data packet corresponding to a single request / response in kernel space, and the network characteristics and context information corresponding to each data packet can be determined.

[0082] B4: Send the network characteristics and context information of the data packet as metadata characteristics to user space.

[0083] In practice, the network characteristics and context information determined for the data packet can be used as metadata features of the data packet and uploaded to the user space for storage, so that the Span data can be constructed in the user space later.

[0084] Understandably, if the target connection is a new connection, the network characteristics and context information of the data packets can be used to store the target connection in the connection state table.

[0085] Thus, the zero-copy kernel offloading and metadata extraction mechanism for non-multiplexed protocol types proposed in this application designs an eBPF-based kernel offloading scheme for widely existing non-multiplexed protocol types (such as RESTful APIs and Database Calls). Specifically, by directly extracting the metadata features (such as protocol type, 5-tuple, and timestamp) required for request / response pairing from the data packet within the kernel eBPF program, useless application-layer load can be directly discarded, and only minor metadata features are reported to user space. This avoids more than 90% of invalid data being copied from kernel space to user space and requiring context switching, fundamentally reducing the CPU and memory overhead of data acquisition. Zero-copy kernel offloading can be understood as directly extracting metadata features from non-multiplexed protocol data packets using eBPF technology in kernel space, and then reporting only lightweight metadata features to user space, without copying the entire data packet to user space for parsing. This minimizes data transport costs in user space and significantly reduces data transmission overhead.

[0086] In another embodiment, when the data packet type is a multiplexing protocol type, S204 above can be implemented as follows (C1~C4): C1: When the target protocol type is a multiplexing protocol type, the feature extraction location is determined to be user space.

[0087] In practical implementation, if the Agent in the service node determines that the target protocol type is a multiplexed protocol, such as HTTP / 2 or gRPC, the packet parsing can be redirected to a slower parsing path in user space. This allows for deep decoding using the rich protocol library resources and advanced protocol templates available in user space, thereby extracting accurate metadata features. Therefore, the feature extraction location can be determined to be user space.

[0088] C2: Forwards data packets to user space and uses the protocol library resources set in user space to perform feature decoding and extraction on the data packets to obtain the network features of the data packets.

[0089] Here, the protocol library resources can be parsing resource libraries set up for various protocol types (including various multiplexed protocol types and various non-multiplexed protocol types).

[0090] In practice, when the Agent determines that the target protocol type is a multiplexing protocol type, the data packets captured in the kernel space can be transparently forwarded to the user space. Then, the protocol library resources set in the user space can be used to perform deep feature decoding and extraction on the uploaded data packets to obtain the network features of the data packets, such as extracting the request identifier, operation type and sequence number of the data packets.

[0091] C3: Determine the context information of the data packet based on the extraction time of network features and the target connection corresponding to the data packet.

[0092] In practical implementation, the extraction time of network features from data packets in user space can be used as the arrival time of the data packets. Simultaneously, information such as the 5-tuple of the data packets can be obtained based on the target connection corresponding to the data packets. Specifically, if the target connection is a new connection, the 5-tuple information of the target connection can be extracted in user space to obtain the corresponding 5-tuple, which can then be used as the 5-tuple of the currently captured data packets. If the target connection is an old connection, the 5-tuple of the target connection can be obtained from the connection state table and used as the 5-tuple of the currently captured data packets. Then, based on the arrival time, 5-tuple, process ID, file description, and other information of the data packets, the context information of the data packets can be determined.

[0093] Understandably, because the number of network system calls in the operating system kernel does not strictly correspond one-to-one with the number of requests or responses, a single data packet may carry information for multiple requests / responses, or multiple requests / responses may correspond to a single data packet. Therefore, during data packet parsing in user space, if a data packet corresponds to multiple requests / responses, it can be split into multiple data packets corresponding to each request / response, and the network characteristics and context information of each data packet can be determined separately. If multiple data packets correspond to a single request / response, they can be merged into a single data packet corresponding to a single request / response in user space, and the network characteristics and context information of each data packet can be determined.

[0094] C4: Use the network characteristics and context information of the data packet as metadata characteristics.

[0095] In practice, network features and context information extracted from data packets in user space can be used as metadata features of the data packets and stored.

[0096] Understandably, the process of parsing data packets and extracting metadata features in user space can use existing extraction methods, such as those found in user-space full parsing schemes (e.g., DeepFlow, DeepTrace).

[0097] Thus, the dynamic traffic splitting mechanism based on protocol characteristics proposed in this application breaks through the single mode of traditional distributed tracing systems (such as DeepFlow) that rely on full data packet user-space parsing. Specifically, by maintaining the connection state in real time in the kernel space, it intelligently directs data packets to different parsing paths based on whether the protocol type corresponding to the data packet supports multiplexing: data packets under simple non-multiplexed protocol types are directly parsed in kernel space, while data packets under complex multiplexed protocol types are transparently forwarded to user space for parsing. This "fast and slow combination" parsing architecture achieves optimal allocation of computing resources and effectively solves the performance bottleneck of single-path processing in high-concurrency scenarios.

[0098] In another embodiment, after capturing a data packet in the kernel space, if the Agent determines that the target connection corresponding to the data packet is not a new connection, it can determine the target protocol type based on the protocol type stored for the target connection in the currently maintained connection state table.

[0099] For example, if the target connection is determined to be an old connection, the target protocol type used by the target connection can be determined from the key-value pairs stored in the connection state table based on the process ID and file identifier corresponding to the target connection. Then, the Agent can directly perform adaptive traffic splitting. If the target protocol type is a non-multiplexed protocol type, the data packets can be parsed in kernel space to extract the structured metadata features corresponding to the data packets and upload them to user space. If the target protocol type is a multiplexed protocol type, the data packets can be forwarded to user space for deep decoding to maintain the flexibility in processing complex state machines in the data packets and obtain accurate metadata features. In this way, the protocol-type-based adaptive traffic splitting architecture minimizes the user space context switching overhead caused by non-multiplexed protocols, significantly optimizing overall processing efficiency. Thus, the metadata features of each data packet obtained under the two parsing paths can ultimately be converged in user space, and then a span assembly algorithm can be used to complete high-precision distributed request tracing assembly, obtaining the span data corresponding to each request and the request tracing chain composed of each request.

[0100] Optionally, while extracting metadata from data packets in kernel space or user space, multi-dimensional system operation metrics corresponding to the data packets can also be collected simultaneously, including microservice component performance metrics (such as execution latency), target connection connection status metrics (such as retransmission count), resource utilization (such as CPU consumption), and load characteristics (such as effective load size), so that various required system operation metrics can be provided in a timely manner when there is a need for in-depth performance analysis of data packets in the future.

[0101] In summary, this application proposes a distributed request tracing method based on a dual-path architecture of kernel space and user space. This method aims to overcome the performance bottleneck caused by copying all data packets to user space for parsing in traditional request tracing schemes. By intelligently allocating packet parsing tasks to two independent parsing paths, a performance balance between data transmission overhead and parsing capability can be achieved. Specifically, for packets under non-multiplexed protocol types, metadata feature extraction is performed directly in kernel space using eBPF technology, minimizing the data transport cost of moving packets to user space and significantly reducing data acquisition overhead. For packets under complex multiplexed protocol types, the parsing depth is guaranteed through the user space path. This adaptive hybrid architecture not only overcomes the resource limitations of the eBPF environment but also provides key technical support for building a low-latency, high-throughput next-generation microservice observability platform.

[0102] In one embodiment, to alleviate message timing disorder that may be caused by multi-core parallel processing and to achieve efficient merging of spanned request-response pairs, this application introduces an aggregation mechanism based on a time window (e.g., 60 seconds) for step S205. Specifically, the merging of spanned data can be achieved according to the following steps: S205-1: In user space, based on the context information corresponding to each captured metadata feature, divide each metadata feature into different time windows.

[0103] In practice, based on the metadata characteristics of each data packet aggregated in the user space, the metadata characteristics currently stored in the user space can be divided into different time windows according to the arrival time carried by the context information in each metadata characteristic and the preset time window length (such as 60 seconds, 5 minutes, etc.). For example, each metadata characteristic can be divided into 60-second time windows.

[0104] Optionally, since the metadata features corresponding to the data packets are constantly arriving in the user space, the metadata features under each time window can be statistically analyzed according to the preset time window length.

[0105] Understandably, if multiple data packets correspond to a single request / response, or a single request / response corresponds to multiple data packets, then during parsing in either kernel space or user space, the data packets corresponding to each request / response can be separated, and the metadata characteristics of each data packet can be determined separately. That is, the user space can store the metadata characteristics corresponding to each request / response for each service node. Then, for each request / response's metadata characteristics, the corresponding time window can be allocated according to the steps in S205-1.

[0106] S205-2: For each time window, generate span data corresponding to each request under the time window based on the metadata characteristics of each time window.

[0107] In practice, for each time window, the corresponding request-response pairs can be determined based solely on the metadata characteristics within that time window, and the span data for each request-response pair can be generated. Alternatively, the corresponding request-response pairs in adjacent time windows can be determined based on the metadata characteristics within those adjacent time windows, and the span data for each request-response pair can be generated. This method of constructing span data using time windows ensures the integrity of the request tracing data chain in complex, high-concurrency environments.

[0108] In one embodiment, S205-2 described above can also be implemented according to the following steps: S205-2-1: For each first metadata feature within the time window and for each target protocol type that is not a multiplexed protocol, based on each first metadata feature and the strictly sequential interaction feature between requests and responses under the non-multiplexed protocol type, construct the span data corresponding to each request-response pair.

[0109] Here, the first metadata feature consists of the metadata features carried for a target protocol type that is not a multiplexed protocol. The strictly ordered interaction feature means that requests and responses appear in strict order; a response to one request will only be given to the next request after the response to the previous request has been completed.

[0110] In practical implementation, for any given time window, the first metadata features of non-multiplexed protocol types can be determined based on the target protocol type carried in the metadata features within that time window. Then, for each first metadata feature, request and response sequences can be constructed based on the operation type carried in the first metadata feature. Then, each request-response pair is matched according to a strict request-response order (i.e., strictly sequential interaction features). Specifically, when matching request-response pairs, any matched request-response pair must have the same five-tuple, the arrival time order must conform to the temporal sequence between request and response, the sequence number order must conform to the sequential sequence between request and response, the protocol type must be consistent, and the operation type must be one request and one response. After matching each request-response pair, based on the existing span construction method, span data corresponding to each request-response pair can be constructed according to the first metadata features of each request-response pair. Then, a request tracing chain under the time window can be constructed based on this span data.

[0111] S205-2-2: For each second metadata feature within the time window and the target protocol type is a multiplexing protocol, construct the span data corresponding to each request-response pair based on each second metadata feature and the protocol differentiation attribute carried in the protocol header of the data packet corresponding to the second metadata feature.

[0112] Here, protocol-distinguishing attributes are protocol-specific attributes extracted from the protocol header of a data packet when parsing a data packet under a multiplexing protocol type in user space. For example, protocol-distinguishing attributes can be the query ID in the DNS protocol or the stream identifier in the HTTP / 2 protocol.

[0113] In practical implementation, for any given time window, the target protocol type carried in each metadata feature within that time window can be used to determine the various second metadata features under the corresponding multiplexing protocol type. Then, for each second metadata feature, a request sequence and a response sequence can be constructed based on the operation type carried in the second metadata feature. Next, using the second metadata features of each request in the request sequence, the second metadata features of each request in the response sequence, and the protocol distinguishing attribute corresponding to each second metadata feature, each request-response pair is matched. Specifically, when matching request-response pairs, any matched request-response pair must have the same 5-tuple, the arrival time order must conform to the temporal sequence between request and response, the sequence number order must conform to the sequential sequence between request and response, the protocol type must be consistent, the operation type must be one request and one response, and the protocol distinguishing attribute must satisfy the matching relationship between request and response. After matching each request-response pair, based on the existing span construction method, span data corresponding to each request-response pair can be constructed according to the second metadata features of each request-response pair. Then, a request tracing chain under the time window can be constructed based on this span data.

[0114] To facilitate understanding of the request tracing method provided in the embodiments of this application, the following will be combined with... Figures 3a-3c This application is described as follows: like Figure 3a The diagram illustrates a connection update process provided in an embodiment of this application. During the connection update process, for any service node, the probe of the eBPF program can be initialized in advance using the Agent and attached to key network calls (such as system read calls and system write calls) to begin the traffic collection phase (i.e., data collection). During the traffic collection phase, when any critical network call is triggered, the probe intercepts the socket read / write operations that triggered the call in real time, capturing the raw data packets and their context information. Then, connection tracking begins. In the connection tracing phase, the connection status of each active network connection in the service node is dynamically maintained using the eBPF map. The connection tracing module in the connection tracing phase introduces an intelligent, differentiated processing strategy. It determines the parsing path of the data packet by judging whether the network connection of the captured data packet matches the eBPF map (i.e., whether the network connection is a new connection). If a match is found, refer to the following section on... Figure 3b and Figure 3c The document describes how to parse data packets. If a connection is missed, indicating a new network connection, the document records the five-tuple of the new connection, the process ID, and other context information. The packet is then sent to kernel space for type resolution to determine the target protocol type. Based on the target protocol type, a parsing path is determined between kernel space and user space to extract network features. User space is used for rule-based user-space parsing of data packets. This is to determine the metadata characteristics of the data packets. Kernel space is used for kernel-space parsing of data packets based on rules. This process determines the metadata characteristics of data packets. Based on the network characteristics of the data packets, as well as context information such as the five-tuple of the new connection and the process ID, new connection records are added to the eBPF map. If the network connection of a data packet undergoes a state change (such as connection state modification or connection closure), a corresponding update operation is performed in the eBPF map. For example, when a connection is closed, the network connection is deleted from the eBPF map; when the connection state is modified, the context information stored in the eBPF map is updated based on the modified context information. Then, for any given data packet, after parsing the obtained metadata characteristics using either user space or kernel space, correlation can be performed in user space. This is used to generate span data for each request and to build the request tracing chain in the microservice system.

[0115] like Figure 3bThe diagram illustrates a data packet parsing process under a multiplexing protocol type according to an embodiment of this application. For any data packet under the multiplexing protocol type, after the data collection receives the packets, if the network connection corresponding to the data packet hits the eBPFmap, the packets can be sent to user space for user-space parsing. This process is used to obtain the protocol features corresponding to the data packets. These protocol features are the metadata features mentioned earlier. Then, the parsed protocol features can be used for correlation in user space. .

[0116] like Figure 3c The diagram illustrates a data packet parsing process under a non-multiplexing protocol type, as provided in an embodiment of this application. For any data packet under a non-multiplexing protocol type, after the data collection receives the packets, if the network connection corresponding to the data packet hits the eBPFmap, the packets can be sent to the kernel space. In the kernel space, kernel-space parsing can be performed on the data packets based on rules. This process retrieves the protocol features corresponding to the data packets. Specifically, the Rules mentioned above can be the deterministic parsing mechanism based on protocol type templates and metadata templates, as described earlier. The parsed protocol features can then be sent to user space for correlation. .

[0117] based on Figures 3a-3c As can be seen, this application introduces a core protocol fast parsing mechanism, performing adaptive traffic splitting based on the target protocol type: for non-multiplexed protocol types ( Figure 3c This directly extracts protocol features in kernel space and reports only lightweight metadata, achieving efficient kernel parsing; while for multiplexing protocol types ( Figure 3bIf the original data packet is forwarded to user space, it will be transferred to user space. Once in user space, the data enters the user space parsing stage, where deep decoding of the multiplexing protocol is performed to extract features, or metadata reported by the kernel is directly received. Finally, in the association processing stage, all protocol feature data are aggregated, and discrete requests and responses are paired based on timestamps, 5-tuples, protocol types, etc., ultimately assembling a complete distributed request tracing system. In summary, this application constructs a complete non-intrusive monitoring system at the kernel level, solving the problems of high overhead and strong intrusion of traditional monitoring methods through deep collaboration of data collection, connection tracing, kernel space parsing, and user space parsing.

[0118] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0119] Based on the same inventive concept, this disclosure also provides a request tracing device corresponding to the request tracing method. Since the principle of the device in this disclosure for solving the problem is similar to that of the request tracing method described above, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0120] like Figure 4 The diagram shown is a schematic representation of a request tracking device provided in an embodiment of this disclosure, comprising: The capture module 401 is used to capture data packets corresponding to requests in the operating system kernel space of any service node in the microservice system by using the extended Berkeley packet filter eBPF program deployed on the service node. The determination module 402 is used to determine whether the target connection corresponding to the data packet is a new connection based on the currently maintained connection status table; The parsing module 403 is used to perform type parsing on the data packet in the kernel space if the condition is met, and to determine the target protocol type used by the target connection. The extraction module 404 is used to determine the feature extraction position for the data packet from the kernel space and user space according to the target protocol type, and extract the metadata features of the data packet at the feature extraction position; The generation module 405 is used to generate span data corresponding to each request in the user space based on the metadata characteristics of each captured data packet; the span data is used to construct the request tracing chain in the microservice system.

[0121] In one possible implementation, the parsing module 403, when performing type parsing on the data packet in the kernel space to determine the target protocol type used by the target connection, is configured to: Retrieve the protocol type templates and metadata templates set for various non-multiplexed protocol types; In the kernel space, each protocol type template is traversed sequentially according to a preset traversal order, and for the target offset indicated by the currently traversed protocol type template, byte features that match the target offset are extracted from the data packet. Based on the byte characteristics and the metadata characteristic information indicated by the metadata template corresponding to the currently traversed protocol type template, determine whether the data packet matches the currently traversed protocol type template; If not, continue traversing the next protocol type template until a target protocol type template matching the data packet is determined, and the target protocol type is determined to be a non-multiplexed protocol type, or until all protocol type templates have been traversed, and the target protocol type is determined to be a multiplexed protocol type.

[0122] In one possible implementation, the extraction module 404, when determining the feature extraction location for the data packet from kernel space and user space according to the target protocol type, and extracting the metadata features of the data packet at the feature extraction location, is configured to: When the target protocol type is a non-multiplexing protocol type, the feature extraction location is determined to be the kernel space; Based on the matching time between the data packet and the target protocol type template, the arrival time of the data packet is determined, and the network features of the data packet are extracted in the kernel space according to the byte offset range indicated by the target protocol type template. In the kernel space, the five-tuple corresponding to the data packet is determined based on the target connection corresponding to the data packet, and the context information of the data packet is determined based on the arrival time of the data packet and the five-tuple. The network characteristics and context information of the data packet are sent to the user space as the metadata characteristics.

[0123] In one possible implementation, the extraction module 404, when determining the feature extraction location for the data packet from kernel space and user space according to the target protocol type, and extracting the metadata features of the data packet at the feature extraction location, is configured to: If the target protocol type is a multiplexing protocol type, the feature extraction location is determined to be user space; The data packet is forwarded to the user space, and the protocol library resources set in the user space are used to perform feature decoding and extraction on the data packet to obtain the network features of the data packet; The context information of the data packet is determined based on the extraction time of the network features and the target connection corresponding to the data packet; The network characteristics and context information of the data packet are used as the metadata characteristics.

[0124] In one possible implementation, the determining module 402 is further configured to: If the target connection corresponding to the data packet is not a new connection, the target protocol type is determined according to the protocol type stored for the target connection in the currently maintained connection state table.

[0125] In one possible implementation, the generation module 405, when generating span data corresponding to each request in user space based on the metadata characteristics of each captured data packet, is used to: In the user space, each metadata feature is divided into different time windows based on the context information corresponding to each captured metadata feature; For each time window, span data corresponding to each request under the time window is generated based on the metadata characteristics of each time window.

[0126] In one possible implementation, the generation module 405, when generating span data corresponding to each request within the time window based on various metadata features within the time window, is configured to: For each first metadata feature within the time window and for each target protocol type that is a non-multiplexed protocol type, based on each first metadata feature and the strictly sequential interaction feature between requests and responses under the non-multiplexed protocol type, the span data corresponding to each request-response pair is constructed. For each second metadata feature within the time window and whose target protocol type is multiplexing protocol, the span data corresponding to each request-response pair is constructed based on each second metadata feature and the protocol differentiation attribute carried in the protocol header of the data packet corresponding to the second metadata feature.

[0127] In one possible implementation, the apparatus further includes an update module 406, which, after performing type parsing on the data packet in the kernel space to determine the target protocol type used by the target connection, is used to: Update the currently maintained connection state table based on the target connection and the target protocol type used by the target connection; The updated connection state table is used as the new currently maintained connection state table; wherein, the new currently maintained connection state table is used to determine whether the target connection corresponding to the newly captured data packet is a new connection.

[0128] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0129] Based on the same technical concept, embodiments of this application also provide a computer device. (Refer to...) Figure 5 The diagram shown is a structural schematic of a computer device provided in an embodiment of this application, comprising: Processor 501, memory 502 and bus 503. The memory 502 stores machine-readable instructions executable by the processor 501. The processor 501 executes the machine-readable instructions stored in the memory 502. When the machine-readable instructions are executed by the processor 501, the processor 501 performs the following steps: S201: For any service node in the microservice system, using the extended Berkeley packet filter (eBPF) program deployed on the service node, captures the data packet corresponding to the request in the kernel space of the service node's operating system; S202: Based on the currently maintained connection state table, determines whether the target connection corresponding to the data packet is a new connection; S203: If so, performs type parsing on the data packet in the kernel space to determine the target protocol type used by the target connection; S204: Based on the target protocol type, determines the feature extraction position for the data packet from the kernel space and user space, and extracts the metadata features of the data packet at the feature extraction position; and S205: In the user space, based on the metadata features of each captured data packet, generates span data corresponding to each request; the span data is used to construct the request tracing chain in the microservice system.

[0130] The aforementioned memory 502 includes a main memory 5021 and an external memory 5022. The main memory 5021, also known as internal memory, is used to temporarily store the computational data in the processor 501, as well as the data exchanged with external memory such as a hard disk 5022. The processor 501 exchanges data with the external memory 5022 through the main memory 5021. When the computer device is running, the processor 501 and the memory 502 communicate through the bus 503, so that the processor 501 executes the execution instructions mentioned in the above method embodiments.

[0131] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the request tracing method described in the above-described method embodiments. The storage medium may be a volatile or non-volatile computer-readable storage medium.

[0132] This disclosure also provides a computer program product carrying program code. The program code includes instructions that can be used to execute the steps of the request tracing method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0133] The computer program product can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0134] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it can be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0135] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0136] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0137] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0138] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the user through pop-up information or by asking the user to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

[0139] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A request tracing method, characterized in that, The method includes: For any service node in a microservice system, the extended Berkeley packet filter (eBPF) program deployed on the service node is used to capture the data packets corresponding to the request in the operating system kernel space of the service node. Based on the currently maintained connection status table, determine whether the target connection corresponding to the data packet is a new connection; If so, the data packet is type-parsed in the kernel space to determine the target protocol type used by the target connection; Based on the target protocol type, the feature extraction location for the data packet is determined from the kernel space and user space, and the metadata features of the data packet are extracted at the feature extraction location; In user space, span data corresponding to each request is generated based on the metadata characteristics of each captured data packet; the span data is used to construct the request tracing chain in the microservice system.

2. The method according to claim 1, characterized in that, The step of performing type parsing on the data packet in the kernel space to determine the target protocol type used by the target connection includes: Retrieve the protocol type templates and metadata templates set for various non-multiplexed protocol types; In the kernel space, each protocol type template is traversed sequentially according to a preset traversal order, and for the target offset indicated by the currently traversed protocol type template, byte features that match the target offset are extracted from the data packet. Based on the byte characteristics and the metadata characteristic information indicated by the metadata template corresponding to the currently traversed protocol type template, determine whether the data packet matches the currently traversed protocol type template; If not, continue traversing the next protocol type template until a target protocol type template matching the data packet is determined, and the target protocol type is determined to be a non-multiplexed protocol type, or until all protocol type templates have been traversed, and the target protocol type is determined to be a multiplexed protocol type.

3. The method according to claim 2, characterized in that, The step of determining the feature extraction location for the data packet from kernel space and user space according to the target protocol type, and extracting the metadata features of the data packet at the feature extraction location, includes: When the target protocol type is a non-multiplexing protocol type, the feature extraction location is determined to be the kernel space; Based on the matching time between the data packet and the target protocol type template, the arrival time of the data packet is determined, and the network features of the data packet are extracted in the kernel space according to the byte offset range indicated by the target protocol type template. In the kernel space, the five-tuple corresponding to the data packet is determined based on the target connection corresponding to the data packet, and the context information of the data packet is determined based on the arrival time of the data packet and the five-tuple. The network characteristics and context information of the data packet are sent to the user space as the metadata characteristics.

4. The method according to claim 2, characterized in that, The step of determining the feature extraction location for the data packet from kernel space and user space according to the target protocol type, and extracting the metadata features of the data packet at the feature extraction location, includes: If the target protocol type is a multiplexing protocol type, the feature extraction location is determined to be user space; The data packet is forwarded to the user space, and the protocol library resources set in the user space are used to perform feature decoding and extraction on the data packet to obtain the network features of the data packet; The context information of the data packet is determined based on the extraction time of the network features and the target connection corresponding to the data packet; The network characteristics and context information of the data packet are used as the metadata characteristics.

5. The method according to claim 1, characterized in that, The method further includes: If the target connection corresponding to the data packet is not a new connection, the target protocol type is determined according to the protocol type stored for the target connection in the currently maintained connection state table.

6. The method according to claim 1, characterized in that, In the user space, based on the metadata characteristics of each captured data packet, span data corresponding to each request is generated, including: In the user space, each metadata feature is divided into different time windows based on the context information corresponding to each captured metadata feature; For each time window, span data corresponding to each request under the time window is generated based on the metadata characteristics of each time window.

7. The method according to claim 6, characterized in that, The step of generating span data corresponding to each request within the time window based on various metadata features within the time window includes: For each first metadata feature within the time window and for each target protocol type that is a non-multiplexed protocol type, based on each first metadata feature and the strictly sequential interaction feature between requests and responses under the non-multiplexed protocol type, the span data corresponding to each request-response pair is constructed. For each second metadata feature within the time window and whose target protocol type is multiplexing protocol, the span data corresponding to each request-response pair is constructed based on each second metadata feature and the protocol differentiation attribute carried in the protocol header of the data packet corresponding to the second metadata feature.

8. The method according to claim 1, characterized in that, After performing type parsing on the data packet in the kernel space to determine the target protocol type used by the target connection, the method further includes: Update the currently maintained connection state table based on the target connection and the target protocol type used by the target connection; The updated connection state table is used as the new currently maintained connection state table; wherein, the new currently maintained connection state table is used to determine whether the target connection corresponding to the newly captured data packet is a new connection.

9. A request tracking device, characterized in that, The device includes: The capture module is used to capture data packets corresponding to requests in the operating system kernel space of any service node in the microservice system, using an extended Berkeley packet filter (eBPF) program deployed on the service node. The determination module is used to determine whether the target connection corresponding to the data packet is a new connection based on the currently maintained connection status table; The parsing module is used to perform type parsing on the data packet in the kernel space if the condition is met, and to determine the target protocol type used by the target connection. The extraction module is used to determine the feature extraction position for the data packet from the kernel space and user space according to the target protocol type, and extract the metadata features of the data packet at the feature extraction position; The generation module is used to generate span data corresponding to each request in user space based on the metadata characteristics of each captured data packet; the span data is used to construct the request tracing chain in the microservice system.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 8.

11. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1 to 8.

Images