Network link tracking method, device, equipment and medium

Abstract

The invention relates to the technical field of computer networks, and discloses a network link tracking method and device, equipment and a medium. The method comprises the steps of obtaining a corresponding trace identifier in response to a received link tracking request; searching a corresponding network link identifier based on the trace identifier; the network link identifier is an identifier field which is generated at the starting point of the request link and corresponds to the trace identifier, and the network link identifier is propagated to corresponding network equipment in a service calling process; and determining a target request processing link based on the trace identifier and the network path identifier. According to the embodiment of the invention, tracking of an application layer and a network layer can be realized, complete visualization of a request processing link is realized, and accurate distinguishing of problem roots is facilitated.

Description

Technical Field

[0001] This application relates to the field of computer network technology, and in particular to a network link tracing method, apparatus, device, and medium. Background Technology

[0002] With the rapid development of cloud-native technologies, modern applications are generally designed and deployed using microservice architecture, breaking down a single application into multiple independently running service units. These microservices are interconnected through complex network infrastructure, forming call chains across multiple service instances and network devices. As the number of microservices continues to grow, requests must pass through network components such as routers and switches during transmission, resulting in an increasingly large and dynamically changing topology of the underlying network path. Existing link tracing tools mainly focus on collecting application-layer spanning data, such as recording the start and end times of service calls, but fail to effectively integrate network-layer transmission information. This makes it difficult for operations personnel to distinguish whether the root cause of a problem stems from application logic defects or network transmission anomalies when analyzing request latency or failures. For example, when user requests experience slow response times, it is impossible to accurately determine whether it is due to inefficient service processing or network congestion, because there is a lack of a unified mechanism for identifier propagation and path association between network devices. Therefore, there is an urgent need for a tracing method that can connect the application layer and the network layer to achieve complete visualization of the request processing chain. Summary of the Invention

[0003] The purpose of this application is to provide a network link tracing method, apparatus, device, and medium, which has the advantages of being able to trace across the application layer and the network layer, realizing complete visualization of the request processing link, and helping to accurately distinguish the root cause of the problem.

[0004] This application provides a network link tracing method, including: In response to a received link tracing request, obtain the corresponding trace identifier; Based on the trace identifier, the corresponding network link identifier is searched; the network link identifier is an identifier field generated at the starting point of the request link and corresponding to the trace identifier, and the network link identifier is propagated to the corresponding network device during the service call process; Based on the trace identifier and the network path identifier, the target request processing link is determined.

[0005] In some embodiments, before obtaining the corresponding trace identifier in response to a received link tracing request, the method further includes: Upon receiving a service call request, the trace identifier is generated; Based on the trace identifier, a corresponding network link identifier is generated; When responding to the service call request and invoking the corresponding service, the network link identifier is propagated to the network device running the called service.

[0006] In some embodiments, propagating the network link identifier to the network device running the invoked service includes: The network link identifier is written into the context propagator; the context propagator is an HTTP request header, a TLS client handshake message, and / or a predefined protocol propagator. The Baggage mechanism based on Open Telemetry propagates the network link identifier to the network device running the invoked service through the context propagator.

[0007] In some embodiments, searching for the corresponding network link identifier based on the trace identifier includes: Obtain application span data and network span data; Based on a preset identifier mapping relationship, the network link identifier corresponding to the trace identifier is determined; The application span data and the network span data are sampled to search for the network link identifier corresponding to the trace identifier.

[0008] In some embodiments, the time information of the application span data and the network span data is aligned using a sliding window mechanism, wherein the time information of the application span data is determined based on TCP packet timestamps, and the time information of the network span data is determined based on service clock information.

[0009] In some embodiments, determining the target request processing link based on the trace identifier and the network path identifier includes: Based on the trace identifier, the corresponding target application span is determined, and based on the time information of the trace identifier, the target application span is sorted to obtain the application layer call chain; Based on the network path identifier, the corresponding target network span is determined, and based on the time information of the network path identifier, the target network span is sorted to obtain the network layer call chain; The application layer call chain and the network layer call chain are aligned across layers and spliced ​​together to obtain the target request processing chain.

[0010] In some embodiments, the cross-layer alignment and link splicing of the application layer call chain and the network layer call chain includes: Align the time information of the trace identifier and the network path identifier; After aligning the time information, the target application span and target network span that are in the same time window and involve the same service endpoint are matched to obtain the target request processing link.

[0011] This application also provides a network link tracing device, including: The first module is used to obtain the corresponding trace identifier in response to the received link tracing request; The second module is used to search for the corresponding network link identifier based on the trace identifier; the network link identifier is an identifier field generated at the starting point of the request link and corresponding to the trace identifier, and the network link identifier is propagated to the corresponding network device during the service call process; The third module is used to determine the target request processing link based on the trace identifier and the network path identifier.

[0012] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the network link tracing method described above.

[0013] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the network link tracing method described above.

[0014] The beneficial effects of this application are as follows: Based on the trace identifier corresponding to the tracing request, a network link identifier corresponding to the trace identifier is generated at the starting point of the request link. This network link identifier is propagated to the corresponding network device during the service call. Finally, the target request processing link is determined based on the trace identifier and the network path identifier. Because a network link identifier corresponding to the trace identifier is generated at the starting point of the request link and propagated to the corresponding network device during the service call, and the target request processing link is determined based on the trace identifier and the network path identifier after searching for the corresponding network link identifier, integrated tracing at the application layer and network layer can be achieved. This provides the advantages of being able to connect the application layer and network layer tracing, achieving complete visualization of the request processing link, and helping to accurately identify the root cause of the problem. Attached Figure Description

[0015] Figure 1 This is a diagram illustrating the application environment of the network link tracing method provided in the embodiments of this application.

[0016] Figure 2 This is a flowchart of the network link tracing method provided in the embodiments of this application.

[0017] Figure 3 This is a flowchart of the method provided in the embodiments of this application before obtaining the corresponding trace identifier.

[0018] Figure 4 This is a flowchart of a method for searching for corresponding network link identifiers provided in an embodiment of this application.

[0019] Figure 5 This is a flowchart of a method for determining a target request processing link provided in an embodiment of this application.

[0020] Figure 6 This is a schematic diagram of the network link tracing device provided in the embodiments of this application.

[0021] Figure 7 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0023] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and drawings are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0025] The network link tracing method provided in this application can be executed by a computer device, which can be a terminal or a server. The terminal includes, but is not limited to, mobile phones, computers, smart home appliances, vehicle terminals, and aircraft. The server can be a standalone physical server, a server cluster consisting of multiple physical servers, a distributed system, or a cloud server.

[0026] Furthermore, the information, data, and signals involved in the embodiments of this application are all authorized by the relevant parties or fully authorized by all parties, and the collection, use, and processing of the relevant data comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0027] In traditional cloud-native application environments, the widespread adoption of microservice architectures leads to highly dynamic and distributed inter-service call paths. Traditional trace methods face technical bottlenecks due to the lack of an effective mechanism for linking application layer and network layer data. Specifically, trace identifiers generated at the application layer cannot be recognized and propagated by the network device layer during service calls. This results in a disconnect between the network device-generated span data and the application layer span data in both temporal and logical dimensions. Consequently, the reconstruction of the end-to-end request processing chain cannot achieve completeness and accuracy, affecting system observability and fault diagnosis capabilities. For example, in an online retail platform's order processing scenario, a user's order request sequentially passes through an API gateway, load balancer, user authentication service, inventory service, and payment service. This request chain involves interactions between multiple network devices and microservice instances. In this scenario, when a service call request is transmitted to the load balancer via the TLS protocol, the trace identifier in the application layer request header is not written into the TLS client handshake message. This prevents the load balancer from associating network layer span data (such as packet forwarding timestamps) with the trace identifier. At the same time, the time information of the application layer span data is generated based on the service clock, while the time information of the network layer span data is determined based on the TCP packet timestamp. The two cannot be matched due to the lack of a unified alignment mechanism, making it impossible for operations and maintenance personnel to establish a correspondence between the processing delay of the payment service and the forwarding behavior of specific network devices.

[0028] If the above problems are not resolved, the fragmentation of link tracing data will hinder the process of locating performance bottlenecks in distributed systems, potentially leading to technical consequences such as extended troubleshooting cycles and reduced service recovery efficiency, thereby weakening the reliability and maintainability of the system.

[0029] Based on this, embodiments of this application provide a network link tracing method, apparatus, device, and medium. By generating and propagating network link identifiers and combining them with trace identifiers, it achieves integrated tracing of application layer and network layer and complete visualization of request processing links, helping to accurately distinguish the root cause of problems.

[0030] Figure 1 This diagram illustrates the application environment of the network link tracing method provided in this embodiment. (See attached diagram.) Figure 1This method is applied to a network link tracing system. The system includes a terminal 110 and a server 120. The terminal 110 and server 120 are connected via a network. The terminal 110 can be a desktop terminal or a mobile terminal; the mobile terminal can be at least one of a mobile phone, tablet, or laptop. The server 120 can be a standalone server or a server cluster consisting of several servers. The terminal 110 sends a received link tracing request to the server 120. The server 120 responds to the received link tracing request by obtaining the corresponding trace identifier, searching for the corresponding network link identifier based on the trace identifier, and determining the target request processing link based on the trace identifier and the network path identifier. The network link identifier is an identifier field generated at the starting point of the request link and corresponding to the trace identifier; the network link identifier is propagated to the corresponding network devices during the service call process.

[0031] It should be understood that Figure 1 The application scenarios shown are merely examples. In practical applications, the network link tracing method provided in this application embodiment can also be applied to other scenarios. For example, the above-described network link tracing method can be directly applied to terminal 110. Terminal 110 is used to respond to a received link tracing request, obtain the corresponding trace identifier, search for the corresponding network link identifier based on the trace identifier, and determine the target request processing link based on the trace identifier and the network path identifier.

[0032] See Figure 2 In one embodiment, a network link tracing method is provided. The execution subject of the method can be a terminal or a server, including but not limited to steps S201 to S203.

[0033] Step S201: In response to the received link tracing request, obtain the corresponding trace identifier.

[0034] A tracing request is an instruction initiated by a user, monitoring system, or automation tool to obtain complete execution path information for a specific service call or business process. This request typically includes one or more parameters to identify the target tracing link, such as a unique tracing identifier.

[0035] A trace identifier is a globally unique identifier used to uniquely identify an end-to-end request or business operation. In a distributed system, when a request is issued from the starting point and processed by multiple services, the trace identifier will propagate through all relevant service calls, ensuring that all operations related to the request can be associated.

[0036] In response to a received trace request, the corresponding trace identifier needs to be obtained. This trace identifier is crucial for identifying a specific request. For example, a trace system might receive a query request containing a specific trace identifier. To obtain this trace identifier, the execution entity can be configured to directly parse the identifier from the received request message. Alternatively, the execution entity can be configured to, upon receiving a request, search a pre-stored list of identifiers based on the request's metadata (e.g., request source, time range) to match and obtain the corresponding trace identifier. For instance, an operations engineer might input a known trace identifier through a management interface; upon receiving this input, the execution entity would directly use it as the target trace identifier for subsequent processing.

[0037] Step S202: Based on the trace identifier, search for the corresponding network link identifier.

[0038] The network link identifier is an identifier field generated at the beginning of the request path, corresponding to the trace identifier. This identifier is propagated to the relevant network devices during the service call process. In short, the network link identifier is an identifier field corresponding to the trace identifier, generated at the beginning of the request path. During the service call, this identifier is propagated to the relevant network devices along with the request data. This identifier is primarily used to trace the request path at the network layer, such as the network infrastructure traversed, including routers and switches.

[0039] A service invocation process refers to the entire interactive flow in which one service sends a request to another and waits for a response. In a microservice architecture, a complex business function typically needs to be completed through mutual invocation between multiple services.

[0040] Network devices refer to hardware devices used in data communication networks for transmitting, routing, switching, or processing data streams, such as routers, switches, load balancers, and firewalls. These devices carry out data transmission functions during service calls.

[0041] The network link identifier is generated at the starting point of the request link and corresponds to the identifier field of the trace identifier. This network link identifier is propagated to the relevant network devices during the service call. For example, the execution entity can be configured to maintain a simple mapping table that directly associates each trace identifier with one or more network link identifiers. Upon obtaining a trace identifier, the execution entity retrieves the corresponding network link identifier by querying this mapping table. Alternatively, the network link identifier can be encoded in a specific field of the trace identifier, and the execution entity extracts it by parsing specific bits or substrings of the trace identifier. For example, when a request is processed in a microservice architecture, its trace identifier might be T-12345-N-67890, where T-12345 is the application layer trace identifier, and N-67890 represents the network layer trace identifier. After receiving T-12345-N-67890, the execution entity directly extracts N-67890 as the network link identifier using a pre-defined parsing rule.

[0042] Step S203: Determine the target request processing link based on the trace identifier and network path identifier.

[0043] The target request processing chain refers to the complete sequence of all application services and network devices traversed from the starting point of a request to its final completion point. This chain includes all key processing nodes and events of the request at the application layer and network layer, and is crucial information for understanding the overall picture of request execution.

[0044] Based on the trace identifier and the network path identifier, the target request processing link is determined. Specifically, this involves integrating the trace information from the application layer and the network layer to form a complete request processing view. For example, the execution entity can be configured to query the application layer log system and the network device log system separately. The application layer log system returns a series of application service call events based on the trace identifier, while the network device log system returns a series of network device forwarding events based on the network link identifier. Then, the execution entity simply merges and sorts these two sets of events according to their timestamps to form a preliminary request processing link. As another implementation, the execution entity can be configured to use the trace identifier and the network link identifier as composite query conditions to query a unified, pre-processed event database. The events stored in this database already contain the association information between the application layer and the network layer, and the query result directly returns a sequence containing application service and network device nodes, thus constituting the target request processing link. For example, for an order processing request on an e-commerce platform, the execution entity obtains the call sequence of the order service, inventory service, and payment service through the trace identifier, and simultaneously obtains the network path of the load balancer, API gateway, and database server through which the request passes through through the network link identifier. Simply arranging this information in chronological order reveals the complete processing chain for this order request.

[0045] The following example will provide a more detailed explanation of the above technical solution: Suppose that in a cloud-native e-commerce platform, user A initiates a purchase request. This request first reaches the front-end service, then sequentially calls the order service, inventory service, and payment service to complete the transaction. During request processing, data passes through network devices such as load balancers, API gateways, and internal network switches. The method provided in this embodiment can be applied when user A or operations personnel need to trace the complete chain of this purchase request.

[0046] First, when the execution entity receives a trace request initiated by user A, it retrieves the corresponding trace identifier. For example, after user A submits an order, the execution entity might return an order number, which is associated with a pre-generated trace identifier. Alternatively, the operations and maintenance personnel might input a known trace identifier, such as ORDER-TRACE-XYZ, into the monitoring interface. Upon receiving the trace request, the execution entity will parse ORDER-TRACE-XYZ from the request as the target trace identifier.

[0047] Next, the executing entity searches for the corresponding network link identifier based on the trace identifier ORDER-TRACE-XYZ. At the origin of the request, for example, when the front-end service receives a request from user A, in addition to generating or associating ORDER-TRACE-XYZ, a corresponding network link identifier, such as NET-PATH-ABC, is also generated. This NET-PATH-ABC will be propagated to the various network devices involved during subsequent service calls, along with the request headers or other metadata. After obtaining ORDER-TRACE-XYZ, the executing entity queries a pre-defined mapping mechanism. This mapping mechanism may be a simple database table that stores the association between ORDER-TRACE-XYZ and NET-PATH-ABC. Through the query, the executing entity successfully obtains the network link identifier NET-PATH-ABC.

[0048] Finally, the executing entity determines the target request processing chain based on the acquired trace identifier ORDER-TRACE-XYZ and network path identifier NET-PATH-ABC. The executing entity queries both the application-layer log storage (e.g., a distributed tracing system) and the network device log storage (e.g., a network traffic analysis system). The application-layer log storage returns the call event sequence of the request in the front-end service, order service, inventory service, and payment service based on ORDER-TRACE-XYZ, including the start and end times of each service call. Simultaneously, the network device log storage returns the forwarding event sequence of the request through network devices such as load balancers, API gateways, and internal switches based on NET-PATH-ABC, also including timestamp information. The executing entity collects these two sets of event data and initially sorts them according to their respective timestamps. Subsequently, the executing entity performs a simple merging of the application-layer event sequence and the network-layer event sequence, for example, associating application-layer events and network-layer events that are close in time, thereby constructing a complete request processing chain that includes application service nodes and network device nodes. This link clearly shows the complete path of user A's purchase request from the front end to the back end, from the application layer to the network layer, including which service the request stayed on for how long, and which network devices it passed through.

[0049] Based on the above examples, the network link tracing method proposed in this embodiment provides a more comprehensive and in-depth view of the request processing link by combining the application layer trace identifier with the network layer network link identifier. Traditional link tracing schemes typically only focus on the call relationships between application layer services, ignoring the transmission path of requests in the underlying network infrastructure. When request delays or failures occur, it is difficult to accurately determine whether the problem lies in service logic, database queries, or underlying infrastructure such as network transmission or load balancer configuration based solely on application layer information.

[0050] This embodiment introduces a network link identifier and associates it with a trace identifier, enabling the tracing system to simultaneously acquire event information from both the application layer and the network layer. For example, in tracing a purchase request on an e-commerce platform, if a slow payment service response is detected, traditional application layer tracing might only show that the payment service call takes a long time. However, using the method in this embodiment, it can be further discovered that there is significant delay or packet loss on a network switch before the request reaches the payment service, thus pinpointing the problem to the network layer rather than the payment service itself. This cross-layer correlation analysis capability significantly improves the efficiency and accuracy of fault diagnosis.

[0051] Furthermore, this method ensures the consistency and relevance of network layer tracing information with application layer tracing information by generating a network link identifier at the start of the request link and propagating it during service calls. This design avoids link breaks or information loss due to information mismatch during tracing, guaranteeing the integrity and reliability of the identified target request processing link. Therefore, the technical concept of this embodiment can effectively solve the challenge of complex link tracing in microservice architectures, providing strong support for the operation and maintenance and troubleshooting of distributed systems.

[0052] See Figure 3 In one embodiment, the method prior to obtaining the corresponding trace identifier includes, but is not limited to, steps S301 to S303.

[0053] Step S301: When a service call request is received, a trace identifier is generated.

[0054] Step S302: Generate the corresponding network link identifier based on the trace identifier.

[0055] Step S303: When responding to a service call request and calling the corresponding service, the network link identifier is propagated to the network device running the called service.

[0056] Upon receiving a service call request, a trace identifier is generated. This identifier is designed to assign a unique global identifier to each service call request entering the system, serving as a unique tracing credential for the request throughout the distributed call chain. The trace identifier can be generated in several ways. For example, when a service gateway or ingress proxy receives an external request, a globally unique identifier can be generated using the UUID (Universally Unique Identifier) ​​algorithm; alternatively, a time-ordered and globally unique identifier can be generated at the application's entry point (such as an HTTP request handler) using the Snowflake algorithm.

[0057] The step of generating a corresponding network link identifier based on the trace identifier aims to associate the application-layer trace identifier with the network-layer identifier, thereby achieving unified tracing across the application and network layers. This can be achieved by directly using the trace identifier as part of the network link identifier, for example, by embedding the trace identifier into a custom network protocol header; or by hashing the trace identifier to generate a fixed-length network link identifier associated with the trace identifier, and then using it for network-layer identification.

[0058] The step of propagating the network trace identifier to the network device running the called service when responding to a service call request and invoking the corresponding service aims to ensure that the network trace identifier is passed throughout the service call chain, enabling subsequent tracing requests to obtain complete trace information. This can be achieved by using HTTP request headers (e.g., by adding custom fields such as X-Trace-ID or the traceparent field conforming to the W3C Trace Context specification) to pass the network trace identifier along with the request to downstream services; or by embedding the network trace identifier into the message through a custom RPC protocol or message queue metadata field, thus propagating it to the network device of the called service.

[0059] This application's solution proactively generates a trace identifier and a corresponding network link identifier at the initial stage of a service call request, ensuring that the network link identifier is continuously propagated to all relevant network devices during the service call process. This lays a solid foundation for subsequent link tracing requests. When a service call request enters the system, a unique trace identifier is first generated, which persists throughout the entire request lifecycle. Then, based on this trace identifier, an associated network link identifier is generated, used to identify and trace the request at the network layer. When the service responds and calls other services, this network link identifier is proactively and systematically propagated to the network devices running the called services. This pre-emptive identifier generation and propagation mechanism ensures that whenever a link tracing request is received, the executing entity can reliably obtain the existing trace identifier and efficiently search for the corresponding network link identifier based on it, as these identifiers have been pre-generated and propagated along the call path. This greatly simplifies the subsequent link search and determination process, ensuring the integrity and consistency of the trace data.

[0060] The following example illustrates this. In a microservice architecture, when a user request enters the system through an API gateway, the API gateway, as the entry point for receiving service call requests, immediately generates a globally unique trace identifier, such as a UUID string. Subsequently, the API gateway generates a network trace identifier based on this trace identifier, for example, embedding it into a custom HTTP request header field (such as X-Network-Trace-ID). When the API gateway forwards this request to downstream microservices such as authentication and order services, it sends the HTTP request header containing this network trace identifier to these services. When the authentication service processes the request and may call the inventory service, it will also propagate the network trace identifier to the network device where the inventory service resides. In this way, regardless of how many services and network devices the request passes through, the network trace identifier can be effectively transmitted and associated.

[0061] Through the above technical solution, this application ensures that all necessary tracing identifiers (including trace identifiers and network link identifiers) have been generated and effectively propagated during the service call process before a tracing request arrives. This solves the problem of missing or difficult-to-associate tracing identifiers in complex distributed systems, significantly improving the efficiency and accuracy of tracing. When tracing is required, the system can quickly and accurately obtain the necessary identifier information, thereby more reliably determining the target request processing link and greatly enhancing the ability to troubleshoot network faults and optimize performance.

[0062] In some embodiments, propagating the network link identifier to the network device running the invoked service includes: writing the network link identifier into a context propagator; and using the Open Telemetry Baggage mechanism to propagate the network link identifier to the network device running the invoked service through the context propagator.

[0063] Context propagators are used in HTTP request headers, TLS client handshake messages, and / or predefined protocol propagators. Essentially, a context propagator is a carrier used to carry and transmit tracing context information during distributed service calls. Its role is to ensure that network link identifiers can be passed between services, thereby enabling complete link tracing. As a common context propagator, HTTP request headers allow the network link identifier to be embedded as a specific header field (e.g., a custom X-Network-Link-ID or traceparent and tracestate headers conforming to the W3C Trace Context standard) into the HTTP request and sent along with the request to the called service. In scenarios involving secure communication using the TLS protocol, the network link identifier can be integrated into extended fields of the TLS client handshake message, for example, through custom TLS extensions or by carrying relevant information in the client certificate, thus propagating it when establishing a secure connection. For custom communication protocols other than HTTP or TLS, specific fields or message structures in the protocol can be predefined to encapsulate and transmit the network link identifier. For example, in RPC calls based on binary protocols, fields can be reserved in the protocol message body or headers to carry this identifier. Open Telemetry's Baggage mechanism is a context propagation capability provided by the Open Telemetry framework. It allows arbitrary key-value pairs of data to be carried throughout the entire call chain of distributed tracing. This data (including network link identifiers) can be appended to the current tracing context (span context) and automatically or manually passed to downstream services during service calls via context propagators (such as HTTP request headers). Its purpose is to provide a standardized and scalable way to transmit network link identifiers, ensuring they are not lost in complex distributed environments and can be retrieved and utilized by subsequent services.

[0064] This application's solution solves the challenge of cross-protocol and cross-layer propagation of network link identifiers in distributed service calls by writing the network link identifier into the context propagator and propagating it based on Open Telemetry's Baggage mechanism. Specifically, when a service call occurs, the generated network link identifier is first encapsulated as a key-value pair in Open TelemetryBaggage. Subsequently, Open Telemetry's propagator serializes and embeds the Baggage data (containing the network link identifier) ​​into the corresponding context propagator, depending on the communication protocol type used (e.g., HTTP, TLS, or a custom protocol). For example, for HTTP calls, the network link identifier is written into the HTTP request header; for TLS connections, it may be embedded in the TLS client handshake message. This mechanism ensures that the network link identifier is delivered to the network device running the called service along with the service call request. After receiving the request, the called service can extract the Baggage data from the corresponding context propagator through Open Telemetry's API, thereby obtaining the network link identifier. In this way, regardless of the underlying communication protocol, the network link identifier can be reliably propagated and obtained, thus laying the foundation for subsequent network link tracing. This approach, which combines a standardized propagation mechanism with flexible context-carrying capabilities, greatly enhances the propagation and traceability of network link identifiers in complex distributed systems.

[0065] As a specific implementation, when service A calls service B, service A, after generating a network link identifier, can add it as a key-value pair in the Open Telemetry Baggage (e.g., the key is network-link-id, and the value is the specific network link identifier string) to the current tracing context. If service A calls service B via the HTTP protocol, the Open Telemetry HTTP propagator (e.g., the W3C Trace Context propagator) will serialize the Baggage data and write the network link identifier along with other tracing information into the HTTP request header. For example, the network link identifier can be encoded and included in the traceparent or tracestate header, or as a custom baggage header field. When service B receives this HTTP request, its Open Telemetry SDK automatically parses the HTTP request header, extracts the Baggage data, and thus obtains the network link identifier. Service B can continue to use the network link identifier for subsequent operations while processing the request, or continue to propagate the identifier when calling other services.

[0066] Through the above technical solution, this application provides an efficient and reliable network link identifier propagation mechanism. By writing the network link identifier into context propagators such as HTTP request headers, TLS client handshake messages, and / or predefined protocol propagators, and combining it with Open Telemetry's Baggage mechanism, it ensures that the network link identifier can be accurately and error-free transmitted across different communication protocols and network layers in complex distributed service call chains. This effectively solves the problem of difficult network link identifier propagation caused by protocol diversity or context loss in traditional link tracing, greatly improving the completeness and accuracy of network link tracing, and providing a solid foundation for subsequent determination of the target request processing link based on the network link identifier.

[0067] See Figure 4 In one embodiment, the method for searching for the corresponding network link identifier includes, but is not limited to, steps S401 to S403.

[0068] Step S401: Obtain application span data and network span data.

[0069] Step S402: Based on the preset identifier mapping relationship, determine the network link identifier corresponding to the trace identifier.

[0070] Step S403: Sample the application span data and network span data to search for the network link identifier corresponding to the trace identifier.

[0071] Application span data refers to information recorded at the application level about the request execution process, typically including the request's start time, end time, service name, operation name, call relationships, and other custom tags. This data can be collected by integrating a distributed tracing SDK into the application or through bytecode injection.

[0072] Network span data refers to the processing information of data packets or connections within network devices recorded at the network layer. This includes information such as the source IP address, destination IP address, source port, destination port, protocol type, timestamp, and identifiers of the network devices the packets traverse. This data can be obtained through network traffic mirroring, network probes, or by parsing network device logs.

[0073] A pre-defined identifier mapping relationship refers to a set of rules or a database established beforehand to associate identifiers at different levels. For example, this mapping relationship can bind the unique identifier of an application service instance (such as service name or instance ID) to the IP address and listening port of the server it is deployed on. This mapping relationship can be statically configured and maintained through configuration files or a management interface; or it can be dynamically generated, for example, automatically updated through a service registration and discovery mechanism. Through this mapping relationship, the executing entity can associate the trace identifier obtained from the application layer with specific IP addresses and ports at the network layer, thereby initially establishing a cross-level connection.

[0074] Sampling refers to the process of selecting a subset of data from massive datasets for processing and analysis. In distributed tracing and network monitoring scenarios, due to the sheer volume of data and the high cost of processing the entire dataset, sampling strategies are typically employed. Sampling can be based on various rules, such as head sampling, tail sampling, probability-based sampling, or sampling based on specific business rules. By strategically sampling application-wide and network-wide data, the amount of data to be processed can be effectively reduced while preserving as much critical tracing information as possible. Within the sampled dataset, the executing entity then efficiently searches for and identifies network link identifiers corresponding to specific trace identifiers through comparison and matching.

[0075] This application's solution effectively bridges data at different levels by acquiring and integrating application span data and network span data, and utilizing pre-defined identifier mapping relationships. Application span data provides a high-level business logic view, while network span data provides a low-level infrastructure view. Through pre-defined mapping relationships and sampling strategies, the executing entity can overcome the heterogeneity between different levels of data and achieve cross-level correlation. This enables the search for network link identifiers based on trace identifiers not only to find relevant network layer information but also to complete the search in a more efficient and economical manner, thus laying a solid foundation for subsequently determining the target request processing link and significantly improving the accuracy and efficiency of network link tracing.

[0076] The following is a concrete example to illustrate this. After receiving a link tracing request and obtaining the corresponding trace identifier, the executing entity initiates a search process for network link identifiers. First, the executing entity obtains application span data from the OpenTelemetry collectors deployed in each microservice application. These collectors report the call chain information within the application in the form of spans. Simultaneously, the executing entity obtains network span data from network probes deployed on the network core switches. These probes capture data packets flowing through the switches and extract key network flow information, such as source IP, destination IP, source port, destination port, protocol type, and timestamp. After obtaining this data, the executing entity establishes associations using a pre-defined identifier mapping relationship. For example, this mapping relationship can be stored in a configuration database, recording the correspondence between the unique identifier of each application service instance (e.g., service name, instance ID) and its deployed server IP address and listening port. When the executing entity needs to determine the network link identifier corresponding to a certain trace identifier, it first finds the relevant application span based on the trace identifier and extracts the relevant service instance information from the application span. The executing entity then queries the configuration database, mapping these service instance information to specific IP addresses and port numbers. These IP addresses and port numbers constitute the initial network link identifiers. To improve search efficiency, the executing entity samples this data. For example, a sampling strategy can be configured to retain only application span data whose response time exceeds a preset threshold, or only network span data that exhibits packet loss or latency anomalies at the network layer. Alternatively, probabilistic sampling can be used, for example, retaining only one for every 100 application spans, or only one for every 1000 network flow data. In the sampled dataset, the executing entity further compares the call information recorded in the application spans (such as source service IP and destination service IP) with the network flow information recorded in the network spans (such as source IP and destination IP), and performs precise matching using timestamps. In this way, the executing entity can efficiently search for and determine the network link identifiers that precisely correspond to a specific trace identifier, for example, determining which IP addresses and ports a certain application request passed through in the network, and within what time period the transmission occurred.

[0077] Through the above technical solution, this application effectively addresses the problem of accurately associating application-layer tracing data with network-layer data in distributed systems. By acquiring and integrating application-layer and network-layer data, and utilizing a pre-defined identifier mapping relationship, effective bridging of data at different levels is achieved. Furthermore, the introduction of a sampling mechanism significantly reduces the complexity of data processing and resource consumption, making it possible to efficiently search for network link identifiers corresponding to trace identifiers in massive amounts of data. This not only improves the accuracy and completeness of network link tracing, ensuring a comprehensive understanding of the request flow path throughout the system, but also optimizes system performance and resource utilization, providing strong support for quickly locating and diagnosing cross-layer problems.

[0078] In some embodiments, the time information of application span data and network span data is aligned using a sliding window mechanism. The time information of application span data is determined based on TCP packet timestamps, while the time information of network span data is determined based on the service's clock information.

[0079] By aligning the time information of application span data and network span data using a sliding window mechanism, the problem of time inconsistency between different data sources is solved, ensuring that data within a specific time range can be effectively correlated. Specifically, a fixed-size time window can be defined, such as 5 seconds, 10 seconds, or 1 minute, and then application span data and network span data can be assigned to the windows corresponding to their respective occurrence times. When the timestamps of two data points fall within the same sliding window, they are considered time-alignable. Alternatively, a strategy of dynamically adjusting the window size can be adopted, adjusting the start and end times of the window based on the density of the data stream or the occurrence of specific events to adapt to time alignment requirements in different scenarios. Furthermore, a time tolerance can be set; if the difference between the timestamps of two data points is less than a preset threshold, they are considered time-aligned, and then all data pairs are traversed using a sliding window.

[0080] Determining the time information of application span data based on TCP packet timestamps provides a reliable, fine-grained time reference for application layer data, typically reflecting the data's point in time at the network transmission layer. When capturing or generating application span data, the timestamp field can be directly extracted from the TCP header carrying the application data, such as the timestamp option in the TCP options, as the time information for that application span. If the TCP packet itself does not have a timestamp option, the system timestamp recorded by the operating system or network interface card when receiving or sending TCP packets can be used as a substitute.

[0081] Determining the time information of network span data based on service clock information provides a time reference closely related to service processing logic for network layer data, reflecting the time points of events processed within the service. When network devices or service nodes process network traffic, they can directly record the system clock time of the device or service itself as the time information for network span data. The clocks of various service nodes can be synchronized through Network Time Protocol (NTP) or Precision Time Protocol (PTP) to ensure high consistency of time information recorded by different service nodes.

[0082] This application's solution establishes separate time information sources for application-span data and network-span data. Specifically, the time information for application-span data is determined based on TCP packet timestamps, while the time information for network-span data is determined based on service clock information. This provides reliable and representative time benchmarks for data at different levels. Furthermore, a sliding window mechanism aligns this time information. This mechanism systematically compares and groups data points within predefined or dynamically adjusted time intervals, effectively identifying and matching application-layer and network-layer events that are close in time. This method tolerates minor time discrepancies that may exist between different data sources, ensuring more accurate identification of truly relevant network events when searching for network link identifiers corresponding to trace identifiers, avoiding misjudgments or omissions caused by time misalignment.

[0083] The following example illustrates this. Suppose a network link tracing system needs to correlate application-layer requests (application span data) and underlying network traffic (network span data). When an application request occurs, the executing agent can capture the corresponding TCP packet and extract time information from the TCP timestamp option in the TCP header, for example, recording it as AppSpan_TS = 1678887400.123 (Unix timestamp, accurate to milliseconds). Simultaneously, when processing network traffic related to this request, network devices or service nodes can use their locally synchronized service clocks to record the network span time information, for example, recording it as NetSpan_TS = 1678887400.125. To align this data, the executing agent can set a 50-millisecond sliding window. When searching for network link identifiers corresponding to trace identifiers, the executing agent iterates through the application span data and network span data. For each application span data, the executing agent creates a time window centered on its AppSpan_TS, [AppSpan_TS - 25ms, AppSpan_TS + 25ms]. The execution entity then searches for all network span data whose NetSpan_TS falls within this window. For example, if AppSpan_TS = 1678887400.123, the window is [1678887400.098, 1678887400.148]. NetSpan_TS = 1678887400.125 falls within this window, so these two spans are considered time-aligned and can be further matched and correlated. In this way, even if there are slight discrepancies between the application layer and network layer time records, they can be effectively correlated through the sliding window mechanism, thereby accurately searching for network link identifiers.

[0084] Through the above technical solution, the time information of application span data and network span data can be effectively aligned. Specifically, the time information of application span data is determined based on TCP packet timestamps, and the time information of network span data is determined based on service clock information, providing reliable and representative time benchmarks for data at different levels. Furthermore, time alignment using a sliding window mechanism can tolerate minor time deviations that may exist between different data sources, thus significantly improving the accuracy and robustness of correlation matching between application span data and network span data. This enables more accurate identification of truly relevant network events when searching for network link identifiers corresponding to trace identifiers, avoiding misjudgments or omissions caused by time misalignment, thereby improving the overall accuracy and efficiency of network link tracing.

[0085] See Figure 5In one embodiment, the method for determining the target request processing link includes, but is not limited to, steps S501 to S503.

[0086] Step S501: Based on the trace identifier, determine the corresponding target application span, and based on the time information of the trace identifier, sort the target application span to obtain the application layer call chain.

[0087] Step S502: Based on the network path identifier, determine the corresponding target network span, and based on the time information of the network path identifier, sort the target network span to obtain the network layer call chain.

[0088] Step S503: Perform cross-layer alignment and link splicing on the application layer call chain and network layer call chain to obtain the target request processing link.

[0089] Determining the target application span involves filtering all application operation records related to a specific trace identifier from massive amounts of application performance monitoring data. These application operation records, i.e., the target application spans, typically include information such as operation name, service name, start time, end time, and parent-child relationships. Sort these target application spans based on the time information of the trace identifier, meaning they are arranged according to the chronological order of their occurrence (e.g., based on the start time), thereby constructing the logical execution path of the request at the application layer, i.e., the application layer call chain. This sorting can be achieved by comparing timestamps or by analyzing the parent-child relationships between spans to infer the execution order.

[0090] Determining the target network span involves identifying all network events or data transmission segments related to that network path identifier from network traffic monitoring data (such as flow logs and packet capture information). These network events or data transmission segments, i.e., the target network span, typically include information such as source IP, destination IP, port, protocol type, and precise timestamps. Sort these target network spans based on the time information of the network path identifier, arranging them according to the chronological order of network events to construct the physical transmission path of the request at the network layer, i.e., the network layer call chain. This sorting usually directly depends on the timestamps of the network events.

[0091] After obtaining the application layer call chain and the network layer call chain, the method of this application performs cross-layer alignment and link splicing on these two chains. Cross-layer alignment refers to establishing the correlation between the two by comparing common identifiers (such as trace identifiers and network path identifiers) and time information in the application layer and network layer data. For example, a call between application services (application span) is necessarily accompanied by corresponding network communication (network span). By matching these correlations, it can be determined which network activities correspond to which application operations. Link splicing integrates these aligned application spans and network spans to form a unified, end-to-end request processing link. This link not only shows the flow of the request in various application services, but also clearly depicts the transmission path of the request in the network infrastructure, thus obtaining a complete target request processing link.

[0092] This application's solution achieves a comprehensive and in-depth understanding of the request processing chain by constructing application-layer and network-layer call chains separately, and further aligning and stitching them together across layers. While the basic solution can search for relevant data based on trace identifiers and network path identifiers, it lacks a mechanism to organically integrate this data into a unified view. This application effectively bridges the gap between application-layer and network-layer data by introducing independent sorting of application and network spans, followed by cross-layer alignment and stitching. This integration allows information previously scattered across different monitoring systems to be correlated, thus clearly showing the complete lifecycle of a request from application logic to network transmission. For example, when application-layer latency occurs, the aligned network-layer data can immediately determine whether it is due to slow internal application processing or a network transmission bottleneck, greatly improving the efficiency and accuracy of fault location.

[0093] The following example illustrates this. Suppose a distributed system where a user initiates a request. This request first reaches the front-end service, then calls the back-end order service, which in turn calls the payment service. When the executing entity receives a tracing request for this request, it will obtain the corresponding trace identifier.

[0094] First, the executing entity will query all relevant application spans from the application performance monitoring system based on the trace identifier. For example, it might query the application span of "Frontend service processing requests" (start time T1, end time T2), the application span of "Order service creating orders" (start time T3, end time T4), and the application span of "Payment service processing payments" (start time T5, end time T6). These application spans will be sorted according to their start time, forming an application layer call chain: Frontend service -> Order service -> Payment service.

[0095] Simultaneously, the executing entity will query all relevant network spans from the network traffic monitoring system based on the network path identifier corresponding to the trace identifier. For example, it might query the network span of "establishing a TCP connection from the front-end service to the order service" (time T2.1), the network span of "sending an HTTP request from the front-end service to the order service" (time T2.2), and the network span of "sending an HTTP request from the order service to the payment service" (time T4.1), etc. These network spans will be sorted according to their timestamps to form a network layer call chain.

[0096] Finally, the executing entity performs cross-layer alignment and link splicing on these two call chains. For example, the application span (T1-T2) of "frontend service processing request" is matched and associated with network spans such as "establishing a TCP connection from the frontend service to the order service" (T2.1) and "the frontend service sending an HTTP request to the order service" (T2.2) in terms of time. In this way, the logical operations of the application layer can be seamlessly connected with the physical transmission process of the network layer, ultimately resulting in a complete target request processing chain that includes application and network details.

[0097] The above technical solutions organically integrate tracing data scattered across the application and network layers, forming a unified and coherent view of the request processing chain. This allows developers and operations personnel to clearly see the end-to-end flow path of requests throughout the system, including their processing in various application services and transmission details within the network infrastructure. This cross-layer visualization capability significantly improves the efficiency and accuracy of fault diagnosis, enabling rapid identification of performance bottlenecks or error sources—whether they originate in application code, inter-service communication, or the underlying network—thereby significantly shortening fault recovery time and providing more comprehensive data support for system optimization.

[0098] In some embodiments, cross-layer alignment and link splicing are performed on the application layer call chain and the network layer call chain, including: aligning the time information of both the trace identifier and the network path identifier; after aligning the time information, matching the target application span and the target network span that are in the same time window and involve the same service endpoint to obtain the target request processing link.

[0099] Aligning the timing information of trace identifiers and network path identifiers aims to ensure that data from the application layer (associated via trace identifiers) and the network layer (associated via network path identifiers) are consistent or comparable in the time dimension. Direct comparison may lead to errors because data acquisition from the application layer and network layer may be performed by different systems at different times, or due to clock drift.

[0100] Matching target application spans and target network spans that are within the same time window and involve the same service endpoint significantly narrows the matching range and improves accuracy and efficiency by aligning time information and limiting the conditions to a time window and the same service endpoint. The time window can be set to a fixed time range, such as 50 milliseconds or 100 milliseconds. This means that after time alignment, if the start or end time of the application span and network span falls within this window, they are considered time-related. Alternatively, a dynamic time window can be used, adaptively adjusting its size based on historical data or real-time monitoring data such as network latency and service processing time to adapt to matching needs in different scenarios. The same service endpoint can be uniquely identified by a combination of IP address and port number. During matching, it checks whether the service endpoint information recorded in the application span (such as the IP address and port of the target service) matches the service endpoint information recorded in the network span (such as the target IP address and port of the TCP connection). In addition to IP address and port number, service endpoints can also be determined by combining logical identifiers such as service name and container ID. This is especially important in microservice architectures, where one IP address and port may correspond to multiple logical services.

[0101] This application's solution cleverly solves the problem of accurately associating application-layer and network-layer call chains by introducing precise time information alignment and a time-window-based matching mechanism with service endpoints. First, aligning the time information of both trace identifiers and network path identifiers ensures that subsequent matching operations are performed on a unified time base, thereby improving matching accuracy. Building on this, after aligning the time information, this solution further matches target application spans and target network spans that are within the same time window and involve the same service endpoint. Here, the time window defines the time range of the event, while the same service endpoint defines the physical or logical location of the event. The combination of these two conditions allows the executing entity to accurately identify request segments processed by the same service entity within a specific time period, which are recorded at both the application and network layers. Through this mechanism, the originally independent application-layer and network-layer call chains can be joined and connected at key interaction points. The application-layer call chain provides a view of the business logic and service call relationships, while the network-layer call chain provides a view of the underlying network transmission and infrastructure. By precisely matching the two, a complete target request processing chain that spans application and network layers can be obtained.

[0102] The following example illustrates this. Suppose a distributed system where service A calls service B. When service A initiates a call to service B, an application span is generated, recording the call start time, end time, service A's IP address, service B's IP address and port, and carrying a trace identifier. Simultaneously, at the network layer, when service A establishes a TCP connection with service B and transmits data, the network device generates a network span, recording the TCP connection establishment time, data transmission time, source IP, destination IP, and port, and carrying a network path identifier. To match these two spans, their time information must first be aligned. For example, if the application server and the network device hosting service B are both synchronized with a central time server via NTP, their recorded timestamps will be highly accurate. After time information alignment, the executing entity sets a time window, such as 50 milliseconds. Then, it checks if there exists a network span within 50 milliseconds of the start (or end) time of the application span where service A calls service B, with the same source IP address as service A, the same destination IP address as service B, and the same destination port as service B. For example, if the application span record shows service A initiating a call to service B (IP address and port 192.168.1.10:8080) at time T1 and ending at time T2, and the network span record shows data transmission from service A's IP address to 192.168.1.10:8080 via TCP connection at time T1+10ms, then since T1+10ms falls within a 50ms time window centered on T1 or between T1 and T2, and the service endpoint (192.168.1.10:8080) is the same, then these two spans will be successfully matched. In this way, multiple successfully matched application spans and network spans can be spliced ​​together according to their time sequence and calling relationship, ultimately forming a complete request processing chain from user request initiation, through application layer service calls, to network layer data transmission.

[0103] Through the above technical solution, this application effectively solves the problem of accurately correlating application-layer call chains and network-layer call chains. By aligning the time information of trace identifiers and network path identifiers, a solid foundation is laid for subsequent cross-layer matching, avoiding data mismatches caused by clock deviations. Furthermore, after aligning the time information, matching is performed using the two key conditions of "same time window" and "same service endpoint," greatly improving the accuracy and efficiency of matching. This refined matching mechanism allows the originally independent application-layer and network-layer data to be seamlessly spliced ​​together, forming a truly end-to-end request processing link that spans different technology stacks. This not only provides developers and operations personnel with unprecedented full-link visibility, enabling them to clearly understand every link of the request at the application and network levels, but also allows for rapid identification of whether the problem lies in application logic, inter-service calls, or underlying network transmission during troubleshooting, thereby significantly shortening fault diagnosis time and improving system stability and operational efficiency.

[0104] See Figure 6 This application also provides a network link tracing device that can implement the above-described network link tracing method. The device includes: The first module 601 is used to obtain the corresponding trace identifier in response to the received link tracing request; The second module 602 is used to search for the corresponding network link identifier based on the trace identifier; the network link identifier is an identifier field generated at the starting point of the request link and corresponding to the trace identifier, and the network link identifier is propagated to the corresponding network device during the service call process; The third module 603 is used to determine the target request processing link based on the trace identifier and network path identifier.

[0105] The specific implementation of this network link tracing device is basically the same as the specific implementation of the network link tracing method described above, and will not be repeated here.

[0106] Figure 7 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0107] The following reference Figure 7 To describe an electronic device 700 according to such an embodiment of the present disclosure. Figure 7 The electronic device 700 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0108] like Figure 7As shown, the electronic device 700 is presented in the form of a general-purpose computing device. The components of the electronic device 700 may include, but are not limited to: at least one processing unit 710, at least one storage unit 720, a bus 730 connecting different system components (including storage unit 720 and processing unit 710), a display unit 740, etc.

[0109] The storage unit stores program code, which can be executed by the processing unit 710, causing the processing unit 710 to perform the steps described in the above-described network link tracing method section of this specification according to various exemplary embodiments of this disclosure.

[0110] Storage unit 720 may include a readable medium in the form of a volatile storage unit, such as random access memory (RAM) 7201 and / or cache memory 7202, and may further include a read-only memory (ROM) 7203.

[0111] The storage unit 720 may also include a program / utility 7204 having a set (at least one) program module 7205, such program module 7205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0112] Bus 730 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0113] Electronic device 700 can also communicate with one or more external devices 700' (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 700, and / or with any device that enables electronic device 700 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 750. Furthermore, electronic device 700 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 760. Network adapter 760 can communicate with other modules of electronic device 700 via bus 730. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 700, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0114] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0115] The network link tracing method, apparatus, device, and medium provided in this application, based on the trace identifier corresponding to the link tracing request, search for a network link identifier generated at the starting point of the request link that corresponds to the trace identifier. This network link identifier is propagated to the corresponding network device during the service call process. Finally, the target request processing link is determined based on the trace identifier and the network path identifier. Because a network link identifier corresponding to the trace identifier is generated at the starting point of the request link and propagated to the corresponding network device during the service call process, and the target request processing link is determined based on the trace identifier and the network path identifier after searching for the corresponding network link identifier, integrated tracing at the application layer and network layer can be achieved. This provides advantages such as the ability to connect the application layer and network layer tracing, complete visualization of the request processing link, and accurate identification of the root cause of the problem.

[0116] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the methods described above according to the embodiments of this disclosure.

[0117] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0118] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0119] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0120] Exemplary embodiments of this disclosure have been specifically shown and described above. It should be understood that this disclosure is not limited to the detailed structures, arrangements, or implementations described herein; rather, this disclosure is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A network link tracing method, characterized in that, include: In response to a received link tracing request, obtain the corresponding trace identifier; Based on the trace identifier, search for the corresponding network link identifier; The network link identifier is an identifier field generated at the starting point of the request link and corresponding to the trace identifier. The network link identifier is propagated to the corresponding network device during the service call process. Based on the trace identifier and the network path identifier, the target request processing link is determined.

2. The network link tracing method according to claim 1, characterized in that, Before obtaining the corresponding trace identifier in response to a received link tracing request, the method further includes: Upon receiving a service call request, the trace identifier is generated; Based on the trace identifier, a corresponding network link identifier is generated; When responding to the service call request and invoking the corresponding service, the network link identifier is propagated to the network device running the called service.

3. The network link tracing method according to claim 2, characterized in that, The step of propagating the network link identifier to the network device running the invoked service includes: The network link identifier is written into the context propagator; the context propagator is an HTTP request header, a TLS client handshake message, and / or a predefined protocol propagator. The Baggage mechanism based on Open Telemetry propagates the network link identifier to the network device running the invoked service through the context propagator.

4. The network link tracing method according to claim 1, characterized in that, The step of searching for the corresponding network link identifier based on the trace identifier includes: Obtain application span data and network span data; Based on a preset identifier mapping relationship, the network link identifier corresponding to the trace identifier is determined; The application span data and the network span data are sampled to search for the network link identifier corresponding to the trace identifier.

5. The network link tracing method according to claim 4, characterized in that, The time information of the application span data and the network span data is aligned using a sliding window mechanism. The time information of the application span data is determined based on the TCP packet timestamp, and the time information of the network span data is determined based on the service clock information.

6. The network link tracing method according to claim 1, characterized in that, The step of determining the target request processing link based on the trace identifier and the network path identifier includes: Based on the trace identifier, the corresponding target application span is determined, and based on the time information of the trace identifier, the target application span is sorted to obtain the application layer call chain; Based on the network path identifier, the corresponding target network span is determined, and based on the time information of the network path identifier, the target network span is sorted to obtain the network layer call chain; The application layer call chain and the network layer call chain are aligned across layers and spliced ​​together to obtain the target request processing chain.

7. The network link tracing method according to claim 6, characterized in that, The cross-layer alignment and link splicing of the application layer call chain and the network layer call chain includes: Align the time information of the trace identifier and the network path identifier; After aligning the time information, the target application span and target network span that are in the same time window and involve the same service endpoint are matched to obtain the target request processing link.

8. A network link tracing device, characterized in that, include: The first module is used to obtain the corresponding trace identifier in response to the received link tracing request; The second module is used to search for the corresponding network link identifier based on the trace identifier; the network link identifier is an identifier field generated at the starting point of the request link and corresponding to the trace identifier, and the network link identifier is propagated to the corresponding network device during the service call process; The third module is used to determine the target request processing link based on the trace identifier and the network path identifier.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the network link tracing method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the network link tracing method according to any one of claims 1 to 7.

Images