Link tracking method and device and storage medium

Abstract

The invention relates to a link tracking method and device and a storage medium, and the method comprises the steps: creating a link tracking identifier and an operation position identifier when a head node detects a target monitoring flow, and injecting the link tracking identifier and the operation position identifier into a message; responding to the message of the previous node at each downstream node, and recording an operation position identifier of a response source in the parent operation position identifier; and summarizing links called by the nodes based on the link tracking identifiers, and generating a calling relationship of each node in each link according to the parent operation position identifier and the operation position identifier so as to display a link path. Therefore, the problems that in the prior art, development invasiveness and maintenance cost are high, tracking blind areas exist and reliability is low are solved, transparent tracking of the calling link between the micro-services is achieved, development and maintenance cost is greatly reduced, and observability construction of the micro-service architecture is more efficient and reliable.

Description

TECHNICAL FIELD

[0001] The present application mainly relates to the field of software development, and in particular, to a link tracking method, device and storage medium. BACKGROUND

[0002] In the field of large-scale distributed software system development, micro-service architecture design has become mainstream. Micro-service design is an architecture pattern that splits a complex application into small services that are independent, autonomous, and focus on a single business domain. Its technology stack is flexible, allowing the selection of the most suitable technology as needed, enabling independent development and deployment by multiple teams, and shortening the iteration cycle. It also has precise scalability, combined with container technology to scale high-load services as needed during peak periods, reducing resource waste. Combined with distributed technology, it can isolate faults and limit them to a single service, reducing the scope of the fault and improving the overall stability of the system. Micro-services focus on a single business domain, have low code volume, and are less coupled to other services, reducing maintenance costs.

[0003] However, while using micro-services brings a variety of benefits, it also introduces new challenges, one of which is the full-link tracking problem. A specific business request is associated with multiple micro-services, and micro-services are independent of each other. In order to understand the complete path of the request, analyze system bottlenecks, and perform fault diagnosis, the call chain must be globally tracked and reconstructed. Currently, the mainstream solution is to modify the code of each micro-service by adding a point. This modification not only increases development workload, but also may damage the integrity of the original code. In addition, as the number of services increases (e.g., from 10 to 50), the maintenance cost of the point increases exponentially. When a new service or an iteration interface is added, the point logic needs to be updated simultaneously, otherwise a "tracking blind area" will occur. SUMMARY

[0004] An object of the present application is to provide a link tracking method, device and storage medium to solve the problems of development invasiveness, high maintenance cost, existence of tracking blind area and low reliability in the prior art.

[0005] According to one aspect of the present application, a link tracking method is provided, which comprises: when a target monitoring flow is detected at a first node, creating a link tracking identifier and an operation location identifier, and injecting the link tracking identifier and the operation location identifier into a packet; at each downstream node, responding to the packet of the previous node and recording the operation location identifier of the response source in the parent operation location identifier; based on the link tracking identifier, summarizing the calls of the nodes in each link, and generating the call relationship of each node in each link according to the parent operation location identifier and the operation location identifier, to display the link path.

[0006] Optionally, the method further comprises: deploying a user mode agent on all nodes for configuring traffic ingress and egress rules and loading eBPF programs, wherein the eBPF programs are used to interact with the user mode agent to realize the egress and ingress traffic binding of each node.

[0007] Optionally, the configuring traffic ingress and egress rules comprises: configuring an ingress node and an egress node in the traffic ingress and egress rules, and traffic flowing through the ingress node and the egress node is judged as target monitoring traffic.

[0008] Optionally, the method further comprises: establishing a first mapping relationship according to a mapping relationship between a network connection corresponding to the target monitoring traffic and a processing thread; establishing a second mapping relationship according to a mapping relationship between the processing thread and tracking context information; and determining the tracking context information corresponding to the target monitoring traffic based on the first mapping relationship and the second mapping relationship, wherein the tracking context information comprises the link tracking identifier, the operation position identifier, and the parent operation position identifier.

[0009] Optionally, the responding to a packet of a previous node at each downstream node and recording an operation position identifier of a response source in the parent operation position identifier comprises: extracting tracking context information in the packet from ingress traffic of a node according to the first mapping relationship and the second mapping relationship; recording an operation position identifier of the node processing a request of a parent node, and recording an operation position identifier of the node called by the parent node in the parent operation position identifier to complete updating of the tracking context information and update the second mapping relationship accordingly; and removing the tracking context information in the packet after reporting the updated tracking context information.

[0010] Optionally, the method further comprises: extracting tracking context information from egress traffic of a node according to the first mapping relationship and the second mapping relationship; recording an operation position identifier of the node calling a child node, and recording an operation position identifier of the node processing a request of a parent node in the parent operation position identifier to complete updating of the tracking context information and update the second mapping relationship accordingly; and injecting the updated tracking context information into a packet of the egress traffic and reporting.

[0011] Optionally, when the target monitoring traffic is detected at the first node, creating a link tracing identifier and an operation location identifier, and injecting the link tracing identifier and the operation location identifier into the message, includes: capturing the outgoing traffic of the first node, determining whether the outgoing traffic is the target monitoring traffic; if so, determining the processing thread of the target monitoring traffic based on the first mapping relationship, where the second mapping relationship is empty; generating a link tracing identifier and an operation location identifier, where the parent operation location identifier is empty, to complete the process of creating the first node tracking context information, and constructing the second mapping relationship accordingly.

[0012] Optionally, injecting the updated tracking context information into the packets of the outgoing traffic and reporting it includes: setting the packet option type and packet length according to the updated tracking context information, updating the checksum in the packet header to complete the injection process of the updated tracking context information; and reporting the updated tracking context information.

[0013] According to another aspect of this application, an electronic device is also provided, the electronic device comprising: one or more processors; and a memory storing computer-readable instructions, which, when executed, cause the processor to perform the operations of any of the methods described above.

[0014] According to another aspect of this application, a computer-readable storage medium is also provided, having stored thereon computer instructions that can be executed by a processor to implement the steps of any of the methods described above.

[0015] Compared with existing technologies, this application uses eBPF technology to automatically inject, transmit, and extract tracing context information at the operating system kernel level by hijacking network data packets. This enables transparent tracing of call chains between microservices, bypassing the need to modify business code. While ensuring the integrity of the tracing chain, it significantly reduces development and maintenance costs, making the construction of observability for microservice architecture more efficient and reliable. Attached Figure Description

[0016] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the specific embodiments of this application will be described in detail below with reference to the accompanying drawings, wherein:

[0017] Figure 1 This application illustrates the link tracing architecture based on eBPF.

[0018] Figure 2 A flowchart illustrating a link tracing method according to one aspect of this application is shown.

[0019] Figure 3 This diagram illustrates the mapping structure of traffic inflow and outflow rules in one embodiment of this application.

[0020] Figure 4 This illustrates a mapping structure diagram of the first mapping relationship in one embodiment of this application;

[0021] Figure 5 This diagram illustrates the mapping structure of the second mapping relationship in one embodiment of this application.

[0022] Figure 6 This diagram illustrates message processing between microservice nodes in one embodiment of this application.

[0023] Figure 7 This invention illustrates a call relationship diagram between microservice nodes in one embodiment of the present application.

[0024] Figure 8 A schematic diagram of a frame of an electronic device provided according to another aspect of this application is shown.

[0025] The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0026] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the specific embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0027] Many specific details are set forth in the following description in order to provide a full understanding of this application. However, this application may also be implemented in other ways different from those described herein, and therefore this application is not limited to the specific embodiments disclosed below.

[0028] As indicated in this application and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include plural forms. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0029] The technical solution of this application is deployed on a computing node running a Linux operating system. The core architecture utilizes the eBPF (extended Berkeley Packet Filter) capability provided by the operating system kernel. eBPF is a technology for running sandboxed programs in the Linux kernel. It allows developers to dynamically add functionality to the kernel without modifying it, thereby improving the kernel's flexibility and scalability.

[0030] exist Figure 1In the illustrated embodiment, this scheme can be divided into two main execution environments: kernel space and user space. A series of eBPF programs are deployed in the kernel space. The eBPF program set includes the XDP ingress entry handler, the cgroup / sock hook program, and the TC egress exit handler. The cgroup / sock hook program is attached to the kernel's cgroup / sock hook point and is used to establish and dynamically maintain the sk2proc_map mapping table in the kernel. It monitors and records the mapping relationship between sockets (network connections) and the processes / threads that created them in real time, providing a foundation for subsequently associating network traffic with specific service processing units.

[0031] The XDP ingress handler is attached to the XDP (eXpress Data Path) hook point and is used to process ingress traffic. It matches ingress packets against rules issued by user space. If a rule is matched, it extracts tracing context information from the packet's TCP options. For the first request on a link (without context information), it initializes and creates a completely new tracing link. After processing, the extracted or created tracing context information is written to the proc2trac_map mapping table and bound to the current processing process. Simultaneously, the tracing information in the original packet is removed, and the packet is handed over to the kernel protocol stack for further processing.

[0032] The TC egress handler is attached to the TC (Traffic Control) egress hook point in the network protocol stack to handle all egress traffic. It also matches traffic according to rules. For egress traffic that matches a rule, it first reads the sk2proc_map mapping table to determine the process handling the connection, then reads the proc2trac_map mapping table to obtain the current tracing context of that process. Next, it updates this context according to the call chain (e.g., generating a new Span ID), writes the updated context to the proc2trac_map mapping table, and injects it as a TCP option into the egress packet to achieve cross-service transmission of tracing information.

[0033] In kernel space, the cgroup / sock program provides the basic identity mapping relationship for the entire system. The output sk2proc_map is read by the TC egress program to associate sockets with processes. The XDP ingress and TC egress programs jointly maintain the proc2trac_map mapping table. The entry program writes to / creates this table, and the exit program reads and updates it, ensuring that the lifecycle of the tracing context and the processing process is synchronized. The XDP ingress is responsible for extracting and removing the tracing context at the entry point, ensuring that the business application receives clean packets; while the TC egress is responsible for injecting the tracing context at the exit point, ensuring that the call information can be passed to downstream services. The two programs, one extracting and the other injecting, work together to achieve transparent end-to-end tracing for the business.

[0034] Continue to refer to Figure 1 In user space, the YAML / JSON rule file defines the microservice instances (such as IP addresses and port numbers) that need to be monitored, i.e., it sets which IP addresses and ports' incoming and outgoing traffic should be captured and processed. eTrace-ChainAgent is a tracing agent service responsible for parsing the rule configuration file described in YAML / JSON format. At the same time, it communicates with the program in kernel space through the eBPF Map mechanism, loads and updates the rules into the rule_map, and collects the processed tracing context data from the kernel. After aggregating and packaging it, it pushes it to the backend visualization platform. The visualization platform finally writes the call chain data into the database (db) for persistent storage and provides a query interface for development and operations personnel to analyze and diagnose. It can display the application of service chains, such as open source projects like Prometheus.

[0035] The proposed solution achieves zero-intrusion microservice tracing based on eBPF technology. Through configurable user-space rules, eBPF programs are dynamically loaded into the kernel space. Cgroup / sock hooks establish the first mapping between sockets and process threads, while the user-space agent maintains a second mapping between process threads and the tracing context, thus achieving complete binding from network connection to the tracing context. Traffic processing logic is deployed at the XDP entry point and TC exit point in the operating system kernel layer to automatically capture, identify, and process TCP packets between microservices. The tracing context is extracted and removed at the entry path, and generated or updated at the exit path with injected packets. Finally, the link data is aggregated and reported to the visualization platform through the user-space agent, completing full-link tracing. This solution achieves cross-node, cross-language tracing capabilities without modifying any microservice business code, effectively avoiding the shortcomings of traditional solutions such as strong code invasiveness, high maintenance costs, and tracing blind spots. It boasts advantages such as rapid deployment, low resource overhead, and language independence, significantly reducing the development and operation costs of observability construction in microservice architectures.

[0036] Figure 2 The diagram shows a flowchart of a link tracing method according to one aspect of this application, the method comprising steps S11, S12 and S13.

[0037] Step S11: When the target monitoring traffic is detected at the first node, a link tracing identifier and an operation location identifier are created and injected into the message.

[0038] The first node is the starting point of link tracing. Tracing is triggered at the first node where the target monitoring traffic enters the link. By generating a unique identifier and injecting a message, it provides the foundation for subsequent association of the entire link. Specifically, the target monitoring traffic is the specific traffic that needs to be tracked, such as business requests and abnormal messages. It can be determined by matching preset rules such as port, protocol, and message characteristics.

[0039] When tracing is triggered, the trace identifier and operation location identifier are first initialized and created. The trace identifier (trace_id) identifies an entire trace; it is globally unique and remains unchanged throughout the entire trace, always carried along with the data packets from the first node to the downstream node. The operation location identifier (span_id) marks an operation within a single node in the trace; it is generated independently by each node to distinguish different parts of the trace. The span_id does not represent the node itself, but rather a specific operation or unit of work within a node, such as processing an HTTP request or performing a database query.

[0040] After creation, the trace_id and span_id are injected into the message. The specific injection location depends on the protocol type. For example, for HTTP / HTTPS protocols, they are placed in the request header; for TCP / UDP protocols, they are added to the reserved fields or extended fields in the message header, without affecting the business content of the TCP data segment.

[0041] Through the above steps, a unique link tracing identifier is assigned to the entire link to ensure that the traffic of all subsequent nodes can be associated; a unique operation location identifier is assigned to a specific operation within the node to clarify the specific operation link; by using injected messages, the identifier can be automatically transmitted with the traffic without additional cross-node communication overhead.

[0042] Step S12: Each downstream node responds to the message from the previous node and records the operation location identifier of the response source in the parent operation location identifier.

[0043] As an intermediate step in link tracing, downstream nodes, upon receiving the tagged message, establish hierarchical relationships between and within nodes by recording the parent operation location identifier, thus forming a parent-child relationship chain. Specifically, downstream nodes (all nodes after the first node) receive a message from the upstream triggering source, which already contains the link tracing identifier and the operation location identifier of the upstream triggering operation. At this point, the downstream node extracts the operation location identifier (span_id) of the upstream triggering operation from the received message and uses it as the parent operation location identifier (parent_id). The downstream node also processes requests corresponding to the upstream triggering operation, such as receiving cross-node HTTP requests or responding to database query calls within its own node, generating a new span_id for each processing action—a unique identifier for the current operation.

[0044] The parent operation location identifier records the operation location identifier of the response source. The response source refers to the upstream trigger source, which can be an operation of other nodes (cross-node trigger) or a preceding operation of this node (internal node trigger), but does not specifically refer to the parent node itself. Even on the same node, different operations will generate different span_ids, and the trace_id remains unchanged throughout the entire chain, ensuring that all operations belong to the same chain.

[0045] Step S13: Based on the links called by the summary node according to the link tracing identifier, generate the calling relationship of each node in each link according to the parent operation position identifier and the operation position identifier, so as to display the link path.

[0046] After the trace tracing is completed, all nodes in the same trace are aggregated based on the trace tracing identifier (trace_id). The call relationships between nodes in the trace are then parsed using the association between the parent operation location identifier (parent_id) and the operation location identifier (span_id), ultimately displaying the entire trace operation path. Specifically, all nodes with the same trace_id are first filtered and aggregated, including cross-node operations and intra-node operations, to form a complete set of nodes representing a single request or traffic flow.

[0047] Next, the call relationships between node operations are generated based on `span_id` and `parent_id`. For example, a node with an empty `parent_id` is identified as the first node in the chain. If the `parent_id` of an operation by node B is the same as the `span_id` of an operation by node A, then node B is a subordinate node of node A, forming an A→B relationship. This allows for the reconstruction of the operational dependencies between and within nodes throughout the entire chain from scattered node operation data, and provides a visual representation, meeting the observability requirements of distributed tracing.

[0048] In one embodiment of this application, a user-space agent is deployed on all nodes to configure traffic inbound and outbound rules and load an eBPF program. The eBPF program is used to interact with the user-space agent to achieve inbound and outbound traffic binding for each node.

[0049] A user-space agent can be a specific application running in user space, such as... Figure 1 The eTrace-Chain Agent in the kernel loads the eBPF assembly and interacts with it, configuring and resolving traffic inbound and outbound rules (such as...). Figure 1 The system uses YAML / JSON rules files to monitor specified inbound and outbound traffic, bind inbound and outbound traffic, and push link messages to the visualization platform for processing.

[0050] Furthermore, in the traffic inflow and outflow rules, ingress nodes and egress nodes are configured, and traffic flowing through the ingress nodes and egress nodes is determined as target monitoring traffic.

[0051] The traffic inbound and outbound rules define the microservice instances that need to be monitored, such as the IP address of the inbound node and the IP address and port number of the outbound node. That is, traffic flowing in or out from the specified IP address and port must be captured, processed, and identified as target monitoring traffic. Figure 3In the illustrated embodiment, the traffic inflow and outflow rules include the IP address and corresponding port number of the outflow node, such as 10.0.0.3:5000 and 10.0.0.7:7000; and the IP address of the inflow node, such as 10.0.0.7, 10.0.0.8, and 10.0.0.3. Traffic flowing in or out from the above IP addresses and ports is identified as target monitoring traffic.

[0052] In one embodiment of this application, a first mapping relationship is established based on the mapping relationship between the network connection and the processing thread corresponding to the target monitoring traffic; a second mapping relationship is established based on the mapping relationship between the processing thread and the tracking context information; and the tracking context information corresponding to the target monitoring traffic is determined based on the first mapping relationship and the second mapping relationship, wherein the tracking context information includes the link tracing identifier, the operation location identifier, and the parent operation location identifier.

[0053] The first mapping relationship is the binding between a network connection (socket) and the processing process / thread. This can be established and dynamically maintained in the kernel by cgroup / sock hooks, providing a foundation for further correlation of traffic. The second mapping relationship is the binding between the processing process / thread and the trace context information (trace_context), ensuring that the trace context and the processing process / thread remain synchronized at all times. Through the first and second mapping relationships, the binding relationship between the network connection and the trace context information is achieved.

[0054] exist Figure 4 In the illustrated embodiment, the first mapping relationship is shown as an sk2proc map. The left column of the table represents each network connection (socket_1, socket_2, socket_3), and the right column represents the corresponding processing process (A_10135_10139, A_10135_10140, A_10135_10141) for each network connection. This mapping enables the binding between network connections and processing processes, such as the binding relationship between socket_1 and A_10135_10139.

[0055] exist Figure 5In the illustrated embodiment, the second mapping relationship is displayed as a proc2trace map. The left column of the table represents each processing process (A_10135_10139, A_10135_10140, A_10135_10141), and the right column represents the matching trace context information (trace_context_1, trace_context_2, trace_context_3) for each processing process. The trace context information includes identifiers such as trace ID (trace_id), operation location ID (span_id), and parent operation location ID (parent_id). The second mapping realizes the binding between the processing process and the trace context information. For example, the binding relationship between A_10135_10139 and trace_context_1{trace_id, span_id, parent_id, …}.

[0056] By utilizing cgroup / sock hooks to establish the first mapping relationship between sockets and processes / threads, and simultaneously implementing a second mapping relationship between processes / threads and trace_context on the user-space proxy side, the binding association between sockets and trace_context is achieved, thereby realizing the relationship binding of trace_id for inbound and outbound traffic. This allows for tracing between microservices without modifying existing microservices, significantly reducing development and operational costs.

[0057] In one embodiment of this application, in step S11, the outgoing traffic of the first node is captured, and it is determined whether the outgoing traffic is the target monitoring traffic; if so, the processing thread of the target monitoring traffic is determined based on the first mapping relationship, and the second mapping relationship is empty; a link tracing identifier and an operation position identifier are generated, and the parent operation position identifier is empty, so as to complete the process of creating the first node tracing context information and construct the second mapping relationship accordingly.

[0058] The system identifies target monitoring traffic from the outgoing traffic of the first node, locates the corresponding processing thread through a first mapping relationship, creates a new tracking context for that thread, and establishes a second mapping relationship between the processing thread and this tracking context. Specifically, the outgoing traffic of the first node is first filtered according to preset rules; only traffic that meets the rules needs to be tracked, avoiding indiscriminate tracking that consumes resources. Target monitoring traffic can be determined based on traffic inflow / outflow rules. For example, if the IP address of the first node A is 10.0.0.3 and the port number is 5000, and the traffic inflow / outflow rules specify the IP address and port number of the outgoing node as 10.0.0.3:5000, then the outgoing traffic from the first node A is the target monitoring traffic.

[0059] The target monitored traffic corresponds to a specific network connection (socket), such as a TCP connection established between a gateway and an application server. Since the first mapping relationship is maintained by the cgroup / sock hook in the kernel to bind network connections to processing threads, querying the first mapping through the target traffic's socket can accurately locate the processing thread responsible for sending that traffic.

[0060] The currently found processing thread has not been bound to any tracing context before, meaning the second mapping relationship is empty. This indicates that this is the first traffic that needs to be traced processed by this thread, or the thread may be newly created with no historical tracing information. Therefore, a new tracing context and a second mapping relationship need to be created. First, a link tracing identifier (trace_id) is generated, which is a globally unique string. The trace_id remains consistent from the first node to the downstream nodes to ensure the uniqueness of link identification. An operation position identifier (span_id) is generated for the current operation. The current operation is the outgoing traffic sending operation of the first node, which is the first operation in the entire link. This span_id is a unique identifier for the current operation. The parent operation position identifier (parent_id) is empty because this is the first operation in the entire link, and there is no upstream triggering operation.

[0061] The three identifiers (trace_id, span_id, and parent_id) are encapsulated in the tracing context information, completing the creation of the first node's tracing context information. Next, the processing thread found through the first mapping relationship is bound to the newly created tracing context information, forming a second mapping relationship. If this thread subsequently triggers other operations, such as calling the local cache or continuing to send traffic downstream, it can obtain the trace_id and the current span_id through the second mapping relationship, thereby generating the span_id for the sub-operation and achieving seamless link transmission.

[0062] exist Figure 6 In the illustrated embodiment, microservice node A (10.0.0.3:5000) sends a request to microservice node B (10.0.0.7:7000), with node A being the head node. The sendto() request reaches the TC egress hook point mounted on node A. The TC egress egress handler processes the egress traffic, first determining it to be target monitoring traffic based on the traffic ingress / egress rules (RuleMap), and matching the egress IP and port 10.0.0.3:5000 in the RuleMap.

[0063] The thread responsible for sending the traffic is found through the first mapping relationship (Sk2Proc) between the socket and the processing process / thread. This thread belongs to the business process (ptid_A) of node A. At this time, the second mapping relationship (ProcMap) is empty. This thread is handling the traffic for the first time and has no tracing context information. A new tracing context for the first node A is created, generating a globally unique tracing identifier (trace_id). The operation of node A calling node B is recorded in the operation location identifier (span_id), where parent_id is empty. The processing thread ptid_A is bound to the newly created tracing context information, completing the initialization of the first node's tracing context information and the second mapping relationship. The tracing context information (trace_context) is injected into the packet, such as... Figure 6 The IPv4Option / GRE Key indicates that the trace_context is stored in the packet options. Node A then sends the request to the network, which then flows to the serving node B. Figure 6 TC_ACT_OK indicates that node A's sendto() request was successfully sent.

[0064] In one embodiment of this application, in step S12, according to the first mapping relationship and the second mapping relationship, the tracking context information in the packet is extracted from the ingress traffic of the node; the operation position identifier of the node processing the request of the superior node is recorded, and the operation position identifier of the superior node calling the node is recorded in the parent operation position identifier to complete the update of the tracking context information, and the second mapping relationship is updated accordingly; after the updated tracking context information is reported, the tracking context information in the packet is removed.

[0065] The system accurately extracts the tracking identifier passed by the parent node from the ingress traffic of the node, creates a new operation position identifier (span_id) for the current node's operation to process the parent request, associates it with the parent operation position identifier (parent_id) of the parent node's operation, updates the binding relationship between the thread and the tracking context, i.e., the second mapping relationship, and finally reports the tracking data and cleans up the tracking metadata in the message to avoid redundant transmission.

[0066] Continue to refer to Figure 6 Taking the ingress traffic received by microservice node B (10.0.0.7:7000) from microservice node A (10.0.0.3:5000) as an example, when the packet sent by node A arrives at the XDP hook point of node B, the XDP ingress ingress processing program processes the packet. First, it determines whether the ingress traffic is the target monitoring traffic according to the traffic ingress and egress rules (RuleMap). The ingress traffic matches the ingress node IP address 10.0.0.7 in the RuleMap and is therefore determined to be the target monitoring traffic.

[0067] The inbound traffic of node B (the request from node A) corresponds to a unique network connection (socket). Based on the first mapping relationship, the processing thread (ptid) responsible for handling this socket is queried. Based on the processing thread obtained from the first mapping, the trace context information (trace_context) bound to this processing thread is queried from the second mapping relationship (ProcMap).

[0068] The core operation of node B is to receive and process requests from node A, generating a unique `span_id` for this operation. Simultaneously, the `span_id` of the parent node's call operation, extracted from the message sent by node A, is recorded as the parent operation position identifier (`parent_id`) of the current `span_id`. In other words, the `span_id` corresponding to the operation of node A calling node B is assigned to the `parent_id`. The updated identifier information is encapsulated in `trace_context`, which includes: `trace_id` (remaining unchanged, the same for node B and node A), `span_id` (the operation identifier for node B processing node A's request), and `parent_id` (the operation identifier for node A calling node B). This completes the update process of the tracing context information, and the second mapping relationship is updated accordingly, i.e., the binding of the processing thread to the new tracing context information. The updated `trace_context` is reported along with the message. `XDP_PASS` indicates that after node B's XDP ingress completes the message restoration, the original message is returned to node B, and the extracted and used tracing data is deleted from the original message, thus avoiding redundant transmission.

[0069] The user-space agent (eTrace Agent) aggregates the tracing context information reported by node A and node B, and pushes the specific identifiers therein to the visualization platform to establish the complete call relationship between and within each node in the chain.

[0070] In one embodiment of this application, tracking context information is extracted from the egress traffic of a node based on the first mapping relationship and the second mapping relationship; the operation location identifier of the node calling the lower-level node is recorded, and the operation location identifier of the node processing the request of the upper-level node is recorded in the parent operation location identifier to complete the update of the tracking context information, and the second mapping relationship is updated accordingly; the updated tracking context information is injected into the packet of the egress traffic and reported.

[0071] For outbound traffic from non-first nodes, similarly, the outbound traffic is first judged according to preset rules. Once identified as target monitoring traffic, the thread to handle this outbound traffic is determined based on the first mapping relationship. The second mapping relationship is then queried. If there is already bound tracing context information, `span_id` and `parent_id` are updated based on the extracted identifiers. `span_id` is the operation identifier for the current node calling a lower-level node, and `parent_id` is the operation identifier for the current node processing a request from a higher-level node. The trace identifier `trace_id` remains unchanged, thus completing the update of `trace_context`, and the second mapping relationship between the socket and `trace_context` is updated accordingly. Finally, the updated `trace_context` is injected into the outbound traffic packet and reported to the visualization platform.

[0072] exist Figure 7 In the illustrated embodiment, the IP address of microservice node A is 10.0.0.3, the IP address of microservice node B is 10.0.0.7, and the IP address of microservice node C is 10.0.0.8. When there is a call relationship where node A calls node B, and node B then calls node C, the call chain relationship A→B→C needs to be bound to achieve call chain tracing. First, user-space proxies are deployed on nodes A, B, and C. The user-space proxies parse the configuration rules and load them into the eBPF Map, while simultaneously completing the kernel loading of the XDPingress entry handler, cgroup / sock hook program, and TC egress exit handler.

[0073] Node A (10.0.0.3) sends a request to Node B, namely... Figure 7 The "1" in the diagram represents the calling relationship. Since node A is the first node in the link, a new trace_id and span_id are created (parent_id is empty), injected into the message, and reported to the visualization platform. Node B (10.0.0.7) receives the request, extracts the tracing context from the ingress traffic, updates the second mapping relationship, removes the tracing option from the message, and reports it to the platform.

[0074] After node B processes the business request, it calls node C, that is... Figure 7 The "2" in the diagram represents the call relationship. Node B generates a new span_id (parent_id is the span_id used by B to process A's request), injects it into the message, and reports it to the platform. Node C (10.0.0.8) receives the request, extracts the tracing context from the ingress traffic, updates the second mapping relationship, removes the tracing option from the message, and reports it to the platform.

[0075] After processing, node C responds to node B, as shown by the call relationship represented by "3" in the diagram. Node C generates a new span_id (parent_id is the span_id used by C to process B's request), injects it into the message, and reports it to the platform. Node B receives C's response, extracts the tracing context from the ingress traffic, updates the second mapping relationship, removes the tracing option from the message, and reports it to the platform.

[0076] After processing, node B responds to node A, as shown by the call relationship indicated by "4" in the diagram. Node B generates a new span_id (parent_id is the span_id of B's ​​response to C), injects it into the message, and reports it to the platform. Node A receives B's response, extracts the tracing context from the ingress traffic, updates the second mapping relationship, removes the tracing option from the message, and reports it to the platform.

[0077] Finally, the tracing context information reported by all nodes is aggregated in the visualization platform. Based on the trace_id, all nodes in the same link are aggregated, and the complete call relationship of each node in the link is generated through span_id and parent_id.

[0078] In one embodiment of this application, the message option type and message length are set according to the updated tracking context information, and the checksum in the message header is updated to complete the injection process of the updated tracking context information; the updated tracking context information is then reported.

[0079] After the tracking context information is updated, the updated tracking context is first embedded into the outgoing TCP packet, so that the packet carries the tracking identifier in the transmission path for subsequent nodes to identify and process. Then, the updated tracking context information is reported separately, and the tracking data is synchronized to the monitoring system (such as a visualization platform).

[0080] The injection of trace context information requires modification of the packet according to the TCP protocol specification to ensure that the packet can be transmitted normally and recognized. The TCP header supports an "option field," allowing you to set a fixed TCP option type value to mark packets carrying trace context information, indicating that the packet requires additional processing to avoid confusion with ordinary TCP packets. The packet length needs to be set accordingly. Since the trace context information is appended to the end of the packet, the TCP header length field needs to be changed. For example, if the TCP header length is an integer in 4-byte units, and the original header is 20 bytes, after appending 8 bytes of trace_context, the header length needs to be changed from 5 (20 / 4) to 7 (28 / 4).

[0081] In addition, both TCP and IP protocols have a "checksum field" in the header to verify whether the message has been tampered with or corrupted during transmission. Since the original TCP message has been modified—that is, trace_context information has been appended and the length field has been updated—the original checksum is invalid and needs to be updated. Specifically, the TCP checksum update uses the bpf_csum_diff helper function provided by eBPF. bpf_csum_diff can efficiently calculate the difference between the original data checksum and the modified data checksum, avoiding a full recalculation, making it suitable for high-performance scenarios in kernel mode / eBPF. Based on the modified TCP header (including new option types and lengths) and the appended trace_context data, the TCP checksum is regenerated and written to the TCP header.

[0082] The steps for calculating the IP checksum are as follows: First, initialize the 32-bit accumulator to 0 to accumulate header data; set the data pointer, converting the IPv4 header pointer IP to a 16-bit unsigned integer pointer p, so that the data is processed in 16-bit words; accumulate the header data, looping through each 16-bit word of the header (IP header length / 2 times), each time using bpf_ntohs(p[i]) to convert the 16-bit data from network byte order (big-endian) to host byte order (little-endian), and accumulate it into sum; then perform carry folding. Since sum is 32 bits (there may be carry in the high 16 bits due to accumulation overflow), carry needs to be merged twice: sum = (sum >> 16) + (sum & 0xFFFF), adding the high 16 bits (carry part) to the low 16 bits to merge possible carry; sum += (sum >> 16) + (sum & 0xFFFF), merging the high 16 bits (carry part) with the low 16 bits. 16) Process any potential carry-overs again (ensuring the final result does not exceed 16 bits); finally, invert the result to generate a checksum and return it. Invert the sum bit by bit (~sum) to obtain the final 16-bit checksum, and write it into the IP header. This allows the receiving end to verify the integrity of the message through the checksum, confirming that the trace_context and message body have not been tampered with, and ensuring the reliability of trace data and business data.

[0083] The technical solution proposed in this application meets the core requirements of accurate, efficient, and non-intrusive link tracing. It achieves real-time hot-swapping of the ingress IP list and egress IP + port list through configurable YAML / JSON rules, tracing target traffic on demand, significantly filtering invalid events, and reducing resource consumption by over 90%. It proposes a two-level PID binding mechanism between cgroup / sock and TC / XDP. Leveraging cgroup / sock_create to collect PTIDs in the system call context, sk2proc map to store the mapping relationship between sockets and PTIDs, and TC egress to look up PTIDs via skb→sk and associate them with trace_context, it overcomes the technical common sense that soft interrupts lack task context, achieving precise binding between packets and processes. This solution solves the problem of existing TC programs being unable to obtain the actual sending process PID, achieving non-intrusive cross-language and cross-runtime tracing. It does not rely on language-specific instrumentation tools such as Java Agent, Gopprof, or Python decorator, achieving unified link tracing in mixed environments such as C / C++ / Rust / Go / Java / Node.js, thus solving the pain point of difficult unified instrumentation across multiple language stacks. This solution improves tracing efficiency and flexibility, achieving precise correlation between process and message levels. With its significant advantages of zero intrusion, cross-language compatibility, and low overhead, it provides a more efficient, universal, and reliable tracing solution for distributed systems and hybrid technology stack architectures.

[0084] The technical solutions proposed in this application can be widely applied in multiple fields. In cloud-native microservice governance scenarios, they can achieve zero-intrusive link tracing for the inbound and outbound traffic of any Pod within a Kubernetes cluster, replacing or enhancing the Istio / Linkerd sidecar and reducing resource overhead by over 30%. In the field of high-frequency trading in finance, they can perform microsecond-level latency tracing of messages between the brokerage matching host and the exchange's front-end server, meeting business traceability and compliance requirements and avoiding the loss of link data. In cloud gaming and ultra-low latency live streaming scenarios, they can detect hop-by-hop latency from GPU rendering process → encoding process → CDN → client, dynamically adjusting the bitrate in conjunction with the ABR algorithm. They can also be pre-installed in servers with various mainstream operating systems and hardware architectures as "out-of-the-box" network observability infrastructure, meeting relevant security technical standards. Furthermore, in critical infrastructure fields such as power grids, high-speed rail dispatching, and medical IoT, they can achieve millisecond-level fault location, reducing large-scale service interruptions caused by network anomalies and improving system reliability and the continuity of public services.

[0085] Figure 8 The diagram shows a schematic frame of an electronic device according to another aspect of this application, the electronic device including at least a processor 801 and a memory 802.

[0086] Processor 801 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 801 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 801 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 801 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 801 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0087] The memory 802 may include one or more computer-readable storage media, which may be non-transitory. The memory 802 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 802 are used to store at least one instruction, which is executed by the processor 801 to implement a link tracing method provided in the method embodiments of this application.

[0088] In some embodiments, the electronic device may also optionally include: a peripheral device interface and at least one peripheral device. The processor 801, memory 802, and peripheral device interface can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface via a bus, signal line, or circuit board. Indicatively, peripheral devices include, but are not limited to: radio frequency circuits, touch displays, audio circuits, and power supplies.

[0089] Of course, the electronic device may also include fewer or more components, and this embodiment does not limit this.

[0090] This application also provides a computer-readable storage medium storing computer instructions thereon, which can be executed by a processor to implement a link tracing method as described above.

[0091] When a link tracing method is implemented as a computer program, it can also be stored as an article of manufacture in a computer-readable storage medium. For example, a computer-readable storage medium may include, but is not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic stripes), optical discs (e.g., compact discs (CDs), digital multifunction discs (DVDs)), smart cards, and flash memory devices (e.g., electrically erasable programmable read-only memory (EPROM), cards, sticks, key drives). Furthermore, the various storage media described herein can represent one or more devices and / or other machine-readable media used for storing information. The term "machine-readable medium" may include, but is not limited to, wireless channels and various other media (and / or storage media) capable of storing, containing, and / or carrying code and / or instructions and / or data.

[0092] It should be understood that the embodiments described above are merely illustrative. The embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For hardware implementation, the processor may be implemented within one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, and / or other electronic units designed to perform the functions described herein, or combinations thereof.

[0093] Some aspects of this application can be executed entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. The aforementioned hardware or software may be referred to as a "data block," "module," "engine," "unit," "component," or "system." The processor may be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DAPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, or combinations thereof. Furthermore, aspects of this application may manifest as computer products residing in one or more computer-readable media, including computer-readable program code. For example, computer-readable media may include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic tapes, etc.), optical discs (e.g., compressed CDs, digital multifunction DVDs, etc.), smart cards, and flash memory devices (e.g., cards, sticks, key drives, etc.).

[0094] A computer-readable medium may contain a propagated data signal containing computer program code, for example, on baseband or as part of a carrier wave. This propagated signal may take various forms, including electromagnetic, optical, and so on, or suitable combinations thereof. A computer-readable medium can be any computer-readable medium other than a computer-readable storage medium, which can be connected to an instruction execution system, apparatus, or device to enable communication, propagation, or transmission of a program for use. The program code located on the computer-readable medium can be propagated through any suitable medium, including radio, cable, fiber optic cable, radio frequency signals, or similar media, or any combination of the above media.

[0095] The basic concepts have been described above. Obviously, for those skilled in the art, the above disclosure is merely illustrative and does not constitute a limitation of this application. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this application. Such modifications, improvements, and corrections are suggested in this application, and therefore remain within the spirit and scope of the exemplary embodiments of this application.

[0096] Furthermore, this application uses specific terms to describe embodiments of the application. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic related to at least one embodiment of the application. Therefore, it should be emphasized and noted that "an embodiment," "one embodiment," or "an alternative embodiment" mentioned twice or more in different locations in this specification do not necessarily refer to the same embodiment. In addition, certain features, structures, or characteristics in one or more embodiments of the application can be appropriately combined.

[0097] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of scope in some embodiments of this application are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

Claims

1. A link tracing method, characterized in that, The method includes: When target monitoring traffic is detected at the first node, a link tracing identifier and an operation location identifier are created and injected into the message; Each downstream node responds to the message from the previous node and records the operation location identifier of the response source in the parent operation location identifier; Based on the link tracing identifier, the link called by the summary node is used to generate the calling relationship of each node in each link according to the parent operation location identifier and the operation location identifier, so as to display the link path.

2. The method according to claim 1, characterized in that, The method further includes: Deploy user-space agents on all nodes to configure traffic inbound and outbound rules and load eBPF programs. The eBPF programs interact with the user-space agents to achieve inbound and outbound traffic binding for each node.

3. The method according to claim 2, characterized in that, The configured traffic inbound and outbound rules include: In the traffic inflow and outflow rules, ingress nodes and egress nodes are configured, and traffic flowing through the ingress nodes and egress nodes is identified as target monitoring traffic.

4. The method according to claim 1, characterized in that, The method further includes: A first mapping relationship is established based on the mapping relationship between the network connection and the processing thread corresponding to the target monitored traffic; Based on the mapping relationship between the processing thread and the tracking context information, a second mapping relationship is established; Based on the first mapping relationship and the second mapping relationship, the tracking context information corresponding to the target monitoring traffic is determined, wherein the tracking context information includes the link tracking identifier, the operation location identifier, and the parent operation location identifier.

5. The method according to claim 4, characterized in that, The step of responding to the message from the previous node at each downstream node and recording the operation location identifier of the response source in the parent operation location identifier includes: Based on the first mapping relationship and the second mapping relationship, the tracking context information in the packet is extracted from the ingress traffic of the node; Record the operation location identifier of the node processing the request of the parent node, and record the operation location identifier of the parent node calling the node in the parent operation location identifier, so as to complete the update of the tracking context information and update the second mapping relationship accordingly; After reporting the updated tracking context information, the tracking context information is removed from the message.

6. The method according to claim 5, characterized in that, The method further includes: Based on the first mapping relationship and the second mapping relationship, the tracking context information is extracted from the node's outbound traffic; Record the operation position identifier of the node calling the lower-level node, and record the operation position identifier of the node processing the request of the upper-level node in the parent operation position identifier, so as to complete the update of the tracking context information and update the second mapping relationship accordingly; The updated tracking context information is injected into the outgoing traffic packets and reported.

7. The method according to claim 4, characterized in that, When target monitoring traffic is detected at the first node, a link tracing identifier and an operation location identifier are created, and these identifiers are injected into the message, including: Capture the outgoing traffic of the first node and determine whether the outgoing traffic is the target monitoring traffic; If so, the processing thread for the target monitoring traffic is determined based on the first mapping relationship, and the second mapping relationship is empty; Generate a link tracing identifier and an operation location identifier, with the parent operation location identifier being empty, to complete the creation process of the first node tracing context information, and construct the second mapping relationship accordingly.

8. The method according to claim 6, characterized in that, The step of injecting the updated tracking context information into the outgoing traffic packets and reporting it includes: Based on the updated tracking context information, the message option type and message length are set, and the checksum in the message header is updated to complete the injection process of the updated tracking context information. The updated tracking context information is reported.

9. An electronic device, characterized in that, The electronic device includes: One or more processors; and A memory storing computer-readable instructions, which, when executed, cause the processor to perform the operations of the method as described in any one of claims 1 to 8.

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

Images