System and method for tracing event chains in distributed microservices data processing networks

Abstract

A method for tracing a chain of events in a distributed microservices data processing network is provided. The network includes one or more nodes (202A-N), each of which includes an agent component (206A-C, 306A-E, 404A-E, 506A-C) integrated with the operating system kernel (320). This agent intercepts Transport Control Protocol, TCP, events related to request handling. The method involves receiving a request at a first-hop node (202A), assigning a request identifier, RID, and injecting this RID into TCP options (318) of upstream requests. The RID is propagated across the network as nodes process the request, allowing for continuous tracking of the request across various operations. Each node reports intercepted TCP events to a controller component (208, 500), which reconstructs the full sequence of events. This method enables efficient monitoring and tracing of microservices operations, improving observability and troubleshooting within distributed systems.

Description

SYSTEM AND METHOD FOR TRACING EVENT CHAINS IN DISTRIBUTED MICROSERVICES DATA PROCESSING NETWORKSTECHNICAL FIELD

[0001] The disclosure relates generally to tracing event chains in distributed microservices data processing networks, and more particularly, the disclosure relates to a method of tracing a chain of events associated with the handling of a request in a distributed microservices data processing network. Moreover, the disclosure relates to a system of tracing the chain of events associated with the handling of the request in the distributed microservices data processing network.BACKGROUND

[0002] Service provisioning in cloud infrastructures has evolved from monolithic applications to a distributed, microservice-based architecture. Traditionally, platform providers have relied on monitoring frameworks to detect malfunctions, analyze service patterns, and optimize performance. However, these traditional monitoring frameworks are inadequate in a new microservice environment, where new challenges emerge due to the dispersed nature of service chains and the heterogeneity of components and programming languages involved.

[0003] Handling a single request may require the interaction of numerous service frameworks (e.g., service A, service B, service C, etc. ) and components, often developed by different parties, with complex dependency relationships as illustrated in FIG. 1A. FIG. 1A illustrates a trace report that details the time spent by each component involved in the handling of a single request and also shows their dependency relationship. Due to the distributed nature of microservice deployments, tracing a chain of events behind the handling of a single request becomes crucial for the platform providers to effectively identify the root causes of malfunctioning, detect bottlenecks in their deployments, understand service patterns, and optimize service placement.

[0004] This shift towards distributed microservices underscores the need for more advanced monitoring and tracing tools capable of managing the complexity of these environments.

[0005] Over the past few decades, several solutions for service tracing have emerged from both industry and academia, utilizing diverse approaches ranging from application to kernel-level instrumentation. FIG. 1B illustrates the large variety of service frameworks (e.g., a Gateway, an Artificial Intelligence, AI, model, Spring, Mongo, Flask, etc. ) that demand for a high-coverage and stable tracing strategy. These approaches offer different trade-offs in terms of coverage, stability, and overhead.

[0006] An existing system, for example an open-source system, implements tracing through application-level instrumentation, requiring modifications to the source code of all involved microservices with an additional layer to trace network communications. While this minimizes additional processing overhead, it introduces a high level of intrusiveness to the monitored microservices. This makes it difficult to maintain the framework functional across various service versions and results in incomplete coverage due to inevitable blind spots in unsupported frameworks or versions.

[0007] Another existing system avoids modifying the source code of microservices by leveraging common networking libraries (e.g., Python’s requests library for Hypertext Transfer Protocol, HTTP) . This enables tracing for any microservice utilizing these libraries with minimal processing overhead. However, its limitation is that it only supports applications using specific libraries. In cloud environments, the microservices may run in separate containers with different instances or versions of these libraries. However, this approach lacks the necessary granularity.

[0008] To reduce intrusiveness, another existing category of approaches employs external agents that run alongside microservices, intercepting and reporting network communications between them. For instance, this system deploys language-specific agents, each designed to monitor network interactions within applications built using a particular language or framework (e.g., one agent for Python services, another for Golang services) . While this method avoids  direct interference with the microservices, it requires dedicated implementations for each language or framework, making it reliant on prior knowledge of the service architecture. Furthermore, version updates in the monitored languages can cause agents to malfunction, and in some cases, certain applications may need to be recompiled for tracing to function properly.

[0009] Another agent-based existing solution addresses the coverage issue by utilizing extended Berkeley Packet Filter, eBPF, based agents. These agents, deployed per machine, transparently instrument the kernel to intercept network-related system calls. This system performs tracing at a lower level, abstracting from application-specific details and generalizing the tracing task. While eBPF-based tracing does not compromise system stability and avoids recompilation, it incurs significant CPU overhead due to the high amount of additional processing required. Aside from performance, another limitation of this system assumes that all monitored microservices propagate a special HTTP header (e.g., x-request-id) to determine which events belong to the same request chain, especially when middleware is involved in the service chain.

[0010] Similarly, yet another agent-based existing solution employs an eBPF-based tracing solution, which injects a Trace ID into HTTP headers to propagate trace context across hosts. This approach requires a custom HTTP header parsing on the receiver side using eBPF, which is a complex task constrained by eBPF’s safety rules that limit the amount of processing allowed. Consequently, this eBPF-based tracing solution only supports short HTTP request lines (i.e., headers with an offset greater than 400 characters are impractical to parse) and introduces considerable processing overhead due to the resource-intensive parsing operation on every message. That is, the eBPF-based tracing solution often operates the maximum allowable eBPF processing overhead for each incoming message) .

[0011] The main challenges in service tracing are: (i) the diverse and constantly evolving landscape of service frameworks, which makes it difficult to support new, previously unknown services while maintaining compatibility with existing ones across various version updates; (ii) the tracing system must be non-intrusive, meaning it should not require modifications to the source code of the services being monitored; (iii) tracing must be comprehensive, extending to infrastructure components like middleware, as blind spots could hinder the accurate diagnosis of malfunctions; and (iv) the system's performance impact must be minimized to avoid degrading the applications'performance.

[0012] To overcome these challenges, there is a need to address the aforementioned technical problems / drawbacks in tracing microservice-based systems.SUMMARY

[0013] It is an object of the disclosure to provide a method of tracing a chain of events associated with the handling of a request in a distributed microservices data processing network. Moreover, the disclosure relates to a system of tracing the chain of events associated with the handling of the request in the distributed microservices data processing network.

[0014] This object is achieved by the features of the independent claims. Further, implementation forms are apparent from the dependent claims, the description, and the figures.

[0015] The disclosure provides a method of tracing a chain of events associated with the handling of a request in a distributed microservices data processing network. Moreover, the disclosure relates to a system of tracing the chain of events associated with the handling of the request in the distributed microservices data processing network.

[0016] According to a first aspect, there is provided a method of tracing a chain of events associated with the handling of a request in a distributed microservices data processing network. The distributed microservices data processing network includes a plurality of nodes. The method includes receiving, at a first-hop node of the distributed microservices data processing network, the request originating from outside of the distributed microservices data processing network and requesting the network to carry out processing of a distributed microservices series of operations. The method includes reporting an event to a controller component which is part of a microservices tracing system. The event indicates that the request has been received. Each node of the network which contributes to the processing of the distributed  microservices series of operations has an agent component, which is also part of the microservices tracing system. The agent component is integrated with the operating system kernel of the node, which intercepts receiving and sending events of Transport Control Protocol, TCP, segments of the kernel. The first hop node selects a request identifier and injects the selected request identifier in at least one TCP option of any upstream request. Each of the other nodes of the plurality of nodes that observes the request identifier in the at least one TCP option propagates the observed request identifier to any upstream requests until a response is sent. The intercepted receiving and sending events that include an injected request identifier are sent by the nodes to the controller component, which uses the receiving and sending events to reconstruct the chain of events associated with the handling of the request.

[0017] The method operates in a non-intrusive manner, focusing on microservices while ensuring comprehensive coverage of all components involved in processing request chains with minimal overhead. The method operates at the kernel level and does not interfere with application-level components. The method deploys a dynamic extended Berkeley Packet Filter, eBPF, program within the operating system kernel on machines running the microservices. The eBPF program transparently leverages kernel functions related to TCP socket operations and intercepts TCP segment’s send and receive events, which are universal across all connection-oriented communications. By intercepting these events, the method provides consistent and stable monitoring across both application and infrastructure components, independent of programming languages, as it relies solely on the TCP protocol. Specifically, the eBPF program reports relevant events to user-space and injects a TCP option containing a request identifier into outgoing segments. This identifier enables tracking of requests and responses across microservices and facilitates a sampling mechanism that selectively traces specific request chains, thereby reducing the overhead of reporting excessive events to user-space. The method effectively improves tracing in microservice-based systems by identifying events behind each request, measuring their duration, and reconstructing their relationships (i.e., service chains) .

[0018] Preferably, the agent component includes an eBPF, extended Berkeley Packet Filter, program. Optionally, the agent component uses kernel probes to intercept the receiving and sending events. As the eBPF program is directly to TCP-related kernel functions using the kernel probes, the method significantly reduces processing overhead compared to the existing approaches by minimizing hook frequency and leveraging network processing performed by the kernel's network stack.

[0019] Optionally, the first-hop node determines whether to trace the received request based on a sampling mechanism. Preferably, the intercepted events that include an injected request identifier are sent to the controller component until a response to the request is detected.

[0020] Optionally, once a response to the request is detected, the controller component pairs matching events into spans. An event which represents a request to a specific microservice is paired with the response from that microservice. Optionally, the matching is carried out using TCP-related data. Optionally, the TCP-related data includes sequence numbers and payload size.

[0021] Preferably, the spans are combined into a request trace which includes information regarding relationships between the microservices. Optionally, each agent component populates a map of service Internet Protocol, IP, addresses of tracked services. Optionally, the eBPF program uses a parent thread map to keep track of thread parent-child relationships.

[0022] According to a second aspect, there is provided a system comprising means adapted for carrying out all the steps of the above described method.

[0023] The system operates in a non-intrusive manner, focusing on microservices while ensuring comprehensive coverage of all components involved in processing request chains with minimal overhead. The system operates at the kernel level and does not interfere with application-level components. The system deploys a dynamic extended Berkeley Packet Filter, eBPF, program within the operating system kernel on machines running the microservices. The  eBPF program transparently leverages kernel functions related to TCP socket operations, and intercepts TCP segment’s send and receive events, which are universal across all connection-oriented communications. By intercepting these events, the system provides consistent and stable monitoring across both application and infrastructure components, independent of programming languages, as it relies solely on the TCP protocol. Specifically, the eBPF program reports relevant events to user-space and injects a TCP option containing a request identifier into outgoing segments. This identifier enables tracking of requests and responses across microservices and facilitates a sampling mechanism that selectively traces specific request chains, thereby reducing the overhead of reporting excessive events to user-space. The system effectively improves tracing in microservice-based systems by identifying events behind each request, measuring their duration, and reconstructing their relationships (i.e., service chains) .

[0024] According to a third aspect, there is provided a computer program including instructions for carrying out all the steps of the above described method, when the computer program is executed on a computer system.

[0025] Therefore, in contradistinction to the existing solutions, the method operates in a non-intrusive manner, focusing on microservices while ensuring comprehensive coverage of all components involved in processing request chains with minimal overhead. The method operates at the kernel level and does not interfere with application-level components. The method effectively improves tracing in microservice-based systems by identifying events behind each request, measuring their duration, and reconstructing their relationships (i.e., service chains) .

[0026] These and other aspects of the disclosure will be apparent from the implementation (s) described below.BRIEF DESCRIPTION OF DRAWINGS

[0027] Implementations of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0028] FIG. 1A (PRIOR ART) illustrates a trace report that details the time spent by each component involved in the handling of a single request and their dependency relationship;

[0029] FIG. 1B (PRIOR ART) illustrates the large variety of service frameworks that demand for a high-coverage and stable tracing strategy;

[0030] FIG. 2 illustrates a system of tracing a chain of events associated with the handling of a request in a distributed microservices data processing network in accordance with an implementation of the disclosure; FIG. 3A illustrates agent components of a microservices tracing system for tracing a chain of events associated with the handling of a request in a distributed microservices data processing network in accordance with an implementation of the disclosure;

[0031] FIG. 3B illustrates extended Berkeley Packet Filter, eBPF, programs that run a custom program before or after the execution of a TCP function in the kernel in accordance with an implementation of the disclosure; FIGS. 4A-4F illustrate exemplary agent components for handling a request in a distributed microservices data processing network in accordance with an implementation of the disclosure;

[0032] FIG. 5 illustrates a controller component of a microservices tracing system for tracing a chain of events associated with the handling of a request in a distributed microservices data processing network in accordance with an implementation of the disclosure;

[0033] FIGS. 6A-6B illustrate exemplary use cases of the system of FIG. 2 in accordance with an implementation of the disclosure;

[0034] FIG. 7 is a flow diagram that illustrates a method of tracing a chain of events associated with the handling of a request in a distributed microservices data processing network in accordance with an implementation of the disclosure; and

[0035] FIG. 8 is an illustration of a computer system in which the various architectures and functionalities of the various previous implementations may be implemented.

[0036] DETAILED DESCRIPTION OF THE DRAWINGS

[0037] Implementations of the disclosure provide a method of tracing a chain of events associated with the handling of a request in a distributed microservices data processing network. Moreover, the disclosure relates to a system of tracing the chain of events associated with the handling of the request in the distributed microservices data processing network.

[0038] To make solutions of the disclosure more comprehensible for a person skilled in the art, the following implementations of the disclosure are described with reference to the accompanying drawings.

[0039] Terms such as "a first" , "a second" , "a third" , and "a fourth" (if any) in the summary, claims, and foregoing accompanying drawings of the disclosure are used to distinguish between similar objects and are not necessarily used to describe a specific sequence or order. It should be understood that the terms so used are interchangeable under appropriate circumstances, so that the implementations of the disclosure described herein are, for example, capable of being implemented in sequences other than the sequences illustrated or described herein. Furthermore, the terms "include" and "have" and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, a method, a system, a product, or a device that includes a series of steps or units, is not necessarily limited to expressly listed steps or units but may include other steps or units that are not expressly listed or that are inherent to such process, method, product, or device.

[0040] FIG. 2 illustrates a system of tracing a chain of events associated with the handling of a request in a distributed microservices data processing network in accordance with an implementation of the disclosure. The distributed microservices data processing network includes one or more nodes (i.e., a cluster of nodes) 202A-N. The system includes a microservices tracing system 204. The microservices tracing system 204 includes one or more agent components 206A-C and a controller component 208. The agent components 206A-C are integrated with an operating system kernel (i.e., a server) of the one or more nodes 202A-N, and the agent components 206A-C intercept receiving and sending events of Transport Control Protocol, TCP, segments / packets of the operating system kernel. Preferably, the agent components 206A-C include an eBPF, extended Berkeley Packet Filter, program. The eBPF program hooks / attaches to two types of kernel functions: sending events (e.g., tcp_sendmsg) and receiving events (e.g., tcp_recvmsg) . These intercepted events are sent to the controller component 208. The controller component 208 uses the intercepted events to reconstruct the chain of events associated with the handling of the request (i.e., a request chain) . Based on a cluster controller 210 (e.g., Kubernetes) of the distributed microservices data processing network, the agent components 206A-C are dynamically providing with a list of endpoints to trace, which corresponds to the current / active instances of a targeted distributed microservice (e.g., 212A) . In an embodiment, the microservices tracing system 204 automatically determines the list of endpoints.

[0041] When a request is issued / originated from outside of the distributed microservices data processing network (as depicted in step 1 of FIG. 2) , the agent component 206A running on a first-hop node 202A of the one or more nodes 202A-N receives the request to carry out processing of series of operations of the distributed microservices 212A-N. The agent component 206A intercepts an event (as depicted in step 2 of FIG. 2) and enriches the event with cluster related data / services information (e.g., names of the services involved in the communication) (as depicted in step 3 of FIG. 2) . The event indicates that the request has been received. Preferably, the agent component 206A uses kernel probes to intercept the receiving and sending events. Preferably, the first-hop node 202A determines whether to trace the received request based on a sampling mechanism. The agent component 206A running on the first-hop node 202A selects a request identifier, ID and injects the selected request ID in at least one TCP option of any upstream request. This request ID is propagated within the TCP option subsequent messages so that the other nodes 202B-N know whether to trace them or not.

[0042] All events exported by the agent components 206A-C may be collected by an event collector 214 (as depicted in step 4 of FIG. 2) . The intercepted receiving and sending events that include an injected request ID are sent by the agent  components 206A-C to the controller component 208, which uses the receiving and sending events to reconstruct the chain of events associated with the handling of the request (as depicted in step 5 of FIG. 2) . Each of the other nodes of the one or more nodes 202A-N that observes the request ID in the at least one TCP option propagates the observed request identifier to any upstream requests until a response is sent to the first request / message (as depicted in step 6 of FIG. 2) . Preferably, the intercepted events that include an injected request identifier are sent to the controller component 208 until a response to the request is detected. Preferably, once a response to the request is detected, the controller component 208 pairs matching events into spans. That is, an event which represents a request to a specific microservice is paired with the event that represents the response from that microservice. Optionally, the matching is carried out using TCP-related data attached to the exported event. Optionally, the TCP-related data includes sequence numbers and payload size. The controller component 208 provides granular information on how long each microservice (e.g. 212A-N) spent handling a certain request or waiting for a response from an upstream service. The spans are finally combined into a request trace (e.g. a trace report) (as depicted in step 7 of FIG. 2) , which illustrates the interactions between the various microservices 212A-N and depicts the whole request life-cycle.

[0043] The system operates in a non-intrusive manner, focusing on the microservices 212A-N while ensuring comprehensive coverage of all components involved in processing request chains with minimal overhead. The system operates at the kernel level and does not interfere with application-level components. The system deploys a dynamic extended Berkeley Packet Filter, eBPF, program within the operating system kernel on machines running the microservices 212A-N. The eBPF program transparently leverages kernel functions related to TCP socket operations, and intercepts TCP segment’s send and receive events, which are universal across all connection-oriented communications. By intercepting these events, the system provides consistent and stable monitoring across both application and infrastructure components, independent of programming languages, as it relies solely on the TCP protocol. Specifically, the eBPF program reports relevant events to user-space and injects a TCP option containing a request identifier into outgoing segments. This identifier enables tracking of requests and responses across microservices and facilitates a sampling mechanism that selectively traces specific request chains, thereby reducing the overhead of reporting excessive events to user-space. The system effectively improves tracing in microservice-based systems by identifying events behind each request, measuring their duration, and reconstructing their relationships (i.e., service chains) .

[0044] The system provides a stable and comprehensive tracing that avoids blind spots while maintaining minimal processing overhead. The system enables (i) abstraction from the diversity and evolution of service frameworks, (ii) comprehensive coverage of both application and infrastructure components, and (iii) significant reduction in processing overhead using a request-scoped sampling mechanism that injects an identifier into messages within the same request chain through the TCP option.

[0045] FIG. 3A illustrates agent components of a microservices tracing system for tracing a chain of events associated with the handling of a request in a distributed microservices data processing network in accordance with an implementation of the disclosure. The distributed microservices data processing network includes one or more nodes. The microservices tracing system includes one or more agent components and a controller component. The agent components include a user-space agent component 306A and a series of kernel-space eBPF, extended Berkeley Packet Filter, programs 306B-E. The kernel-space eBPF programs 306B-E are integrated with an operating system kernel (i.e., a server) of the nodes. The kernel-space eBPF programs 306B-E trigger before (i.e., enter) and after (i.e., exit) a series of TCP kernel functions. The kernel-space eBPF programs 306B-E hooks / attaches to two types of kernel functions: sending events (e.g., tcp_sendmsg, tcp_sendpage) and receiving events (e.g., tcp_recvmsg) . Optionally, the agent components include a series of additional programs to implement the TCP option writing and reading mechanism.

[0046] In the user space as depicted in FIG. 3A, the user-space agent component 306A performs two primary operations: (i) the user-space agent component 306A populates a shared eBPF map of service Internet Protocol, IP, 302 (i.e., the IP addresses of tracked services) , which are periodically retrieved through interaction with a cluster controller 310 of the one or more nodes; and (ii) the agent component 306A periodically pops / retrieves TCP events 316 (i.e., sending events and receiving events) from an event buffer 304, which is populated by the kernel-space agent components or eBPF programs 306B-E as sending events and receiving events are detected. The user-space agent component 306A selects a request identifier, ID, and injects the selected request ID, RID, in at least one TCP option 318 of any upstream request. This request ID is propagated within the TCP option 318 subsequent messages so that the kernel-space eBPF programs 306B-E know whether to trace them or not.

[0047] The kernel space eBPF programs 306B-E implement a process as described in FIG. 3A. The kernel space eBPF programs 306B-E receives the request from the user-space to carry out the processing of a series of operations of a microservice (e.g., a distributed microservice) 314. In the kernel space, upon receiving a message / request (as depicted in step 1 of FIG. 3A) , a first eBPF program 306B first checks the map of service IPs 302 to determine whether the observed event pertains to the microservice 314 that is tracked. If it is the tracked microservice 314, the eBPF program 306B extracts the request ID from the received TCP segment / packet through the TCP option 318. If no request ID is present in the TCP segment, the first eBPF program 306B initializes a new request ID (e.g., by setting it to zero) . The first eBPF program 306B stores the association between a current thread and the request ID in a RID eBPF map 308 of the current thread that tracks request IDs for active threads. The RID eBPF map 308 of the current thread is used to propagate the request context from the enter to the exit hooks of the same kernel function. The current thread is a sequence of execution within the microservice 314.

[0048] After the kernel function completes (as depicted in step 2 of FIG. 3A) , a second eBPF program 306C retrieves the request ID from the previous map (i.e., the RID eBPF map 308 of the current thread) using a thread identifier of the current thread as a key. If the request ID is zero, this indicates that no request ID was previously extracted from the TCP option 318 by the first eBPF program 306B, and therefore, the request has not been traced yet. If a source address matches an entry point with a list of entry point addresses dynamically updated by the user space, the message / request is identified as the start of a new request that may potentially be traced. The second eBPF program 306C then randomly decides, based on the current sampling rate, whether to trace the new request. If the decision is to trace, a new request ID is generated and pushed to a thread-RID map 312, which links the current thread to the last pending request ID awaiting forwarding, either upstream or downstream. Then, a new receiving event including a timestamp, TCP sequence numbers, payload size, and endpoint addresses is reported to the user-space through the event buffer 304.

[0049] Upon sending a message / request (as depicted in step 3 of FIG. 3A) , a third eBPF program 306D applies the same filtering process as shown in step 1 to check if the event involves the tracked microservice (e.g., 314) . The third eBPF program 306D then checks the thread-RID map 312 to determine if the current thread is expected to forward a request ID. If the current thread forwards the request ID, the request ID is retrieved and injected into an outgoing packet as a TCP option 318. If the message represents a response to the initial request from the entry point, the request ID propagation is halted, and no TCP option 318 is written. The request ID is stored in the RID eBPF map 308 of the current thread to enable context propagation for the exit program. Upon exit (as depicted in step 4 of FIG. 3A) , a fourth eBPF program 306E extracts information regarding the payload size and sequence numbers from the RID eBPF map 308 of the current thread, and the sending event is reported to the user-space through the event buffer 304.

[0050] In an embodiment, when a thread in a microservice (e.g., 314) performs a sending event (i.e., a send operation) immediately after receiving a request from agent components, two scenarios are possible: (i) the message / request being sent is a response to the received request, or (ii) a new request is being sent to an upstream service to gather additional information before responding downstream. In the first scenario, it’s straightforward to determine that the sending  event (i.e., the send message) is the response to a previously received request based on the TCP sequence numbers. The thread-RID map mechanism for tracing a chain of events, as described in FIG. 3A, addresses both cases by propagating the request ID using the thread identifier from a downstream to an upstream request and vice versa when receiving the response.

[0051] FIG. 3B illustrates extended Berkeley Packet Filter, eBPF, programs 306B-E that run a custom program before or after the execution of a TCP function in a kernel 320 in accordance with an implementation of the disclosure. The eBPF programs 306B-E provide a flexible mechanism to execute custom programs in the kernel (e.g., Linux kernel) 320 without recompiling it and ensuring that the injected code is safe to be run. The eBPF programs 306B-E may be executed before or after system calls and (almost) any desired kernel function such as sending events (e.g., tcp_sendmsg, tcp_sendpage) and receiving events (e.g., tcp_recvmsg) . The kernel 320 has visibility on all communications and may access network information, and the kernel 320 is the ideal spot in the system for implementing a transparent and exhaustive tracing method.

[0052] FIGS. 4A-4F illustrate exemplary agent components for handling a request in a distributed microservices data processing network in accordance with an implementation of the disclosure. A thread (i.e., a thread #1) in a microservice (e.g., a distributed microservice) 402 may receive multiple requests before sending a response or issuing a new upstream request. For instance, if some of the requests are not fully received yet, the agent components 404A-E continue to listen for additional TCP segments / packets before deciding how to process a request. For example, as shown in FIG. 4A, the thread #1 receives two requests (e.g., a first request identifier, RID #1 and a second request identifier, RID #2) , one of which (the first request identifier, RID #1) may be fragmented at a transport layer. The thread #1 sends two messages, each associated to the previous two requests (i.e., RID #1 and RID #2) . After receiving the first complete request, the thread (i.e., the thread #1) sends the first message (i.e., the last RECV, RID #2, at a TCP level may correspond to the first SEND, RID #2) , and associates it with the last-received request identifier (in this case, RID #2) . Once a thread fully receives a request (in this case, RID #2) , it immediately handles that request, i.e., the RIDs are linked in a last-in, first-out, LIFO, order. The agent components 404A-E update a thread-RID map 406 with the most recent request ID (i.e., the last extracted RID) for each new receive operation. This method of tracing is applicable for application-level microservices, where a single thread handles the entire request lifecycle.

[0053] FIG. 4B illustrates a queue-based mechanism for request ID, RID, propagation in middleware components. Most infrastructure components, such as middleware (e.g., proxies) , operate asynchronously, i.e., the same thread handles multiple requests simultaneously. In these cases, a message / request may be forwarded even before it is fully received, making the thread-RID map mechanism, as described in FIG. 3A, insufficient for propagating the RID between requests. To address this, while handling common middleware components, the pending requests are forwarded in a first-in, first-out, FIFO manner. The thread-RID map 406 is replaced with a series of thread-RID queues 408, for the common middleware components, which track the RIDs currently managed by a thread between receiving and sending events. When a sending event / operation occurs, the oldest RID is popped from the thread-RID queue 408 as shown in FIG. 4B.

[0054] In an embodiment, the agent components of a system distinguish between service-level components and infrastructure components. The agent components use the thread-RID map 406 for the service-level components and the thread-RID queue 408 for the infrastructure components to propagate RIDs from the receiving events to the sending events.

[0055] In another embodiment, in certain microservice 402, a single request may be processed by multiple threads. This typically occurs when the thread that initially receives the request is different from the threads managing subsequent upstream requests as shown in FIG. 4C. For instance, the thread #1 may receive a request but delegate the handling of an upstream request to a thread #2 before providing a downstream response. In such cases, the thread-RID map  mechanism, as described in FIG. 3A, is insufficient for propagating the RID between requests, as the newly spawned 'upstream' thread does not have an existing entry in the thread-RID map 406. To address the cross-thread scenario (i.e., the single request handling by multiple threads) , FIG. 4D illustrates a mechanism designed for scenarios where the microservice 402 utilizes on-demand thread spawning. In this case, the second (upstream) thread (e.g., the thread #2) is created by the first thread (e.g., the thread #1) after receiving the initial request. In contrast, in other specific use cases, such as the coroutines and envoy proxy use cases to be described below, a different mechanism is required, as described in FIGS. 6A-6B.

[0056] Preferably, the system utilizes a parent thread map 410 in eBPF programs to track parent-child relationships between threads. The parent thread map 410 is managed transparently alongside the thread-RID map mechanism for tracing a chain of events as described in FIG. 3A, with an additional eBPF program hooked into a system call (e.g., alloc_pid) . This additional eBPF program registers the relationship between a calling thread (i.e., a parent thread, the thread #1) and a newly created thread (i.e., a worker thread, the thread #2 and a thread #3) in the parent thread map 410, as illustrated in FIG. 4D. FIG. 4D illustrates the parent thread map 410 associating each worker thread with its parent thread. The parent thread map 410 is initialized by the eBPF program hooked into the alloc_pid system call. When an upstream sending event / operation occurs, a lookup in the parent thread map 410 identifies whether the current thread is handling a request originally received by a different parent thread. In such cases, the RID is propagated from the thread-RID map 406 using the parent thread’s identifier as shown in FIG. 4E. FIG. 4E illustrates RID propagation when the thread #1 creates the thread #2 and the thread #3 to handle received requests, RID #1 and RID #2. The worker thread (i.e., the thread #2 or the thread #3) extracts the correct RID from the thread-RID map 406 based on the parent-child relationships recorded in the parent thread map 410. Similarly, when a receiving event / operation occurs, the RID is stored in the thread-RID map 406 using the parent thread’s identifier, if applicable. This ensures proper RID propagation even when receiving responses from upstream as shown in FIG. 4F. FIG. 4F illustrates RID propagation when the worker threads (i.e., the thread #2 or the thread #3) receive responses from upstream and the parent thread (i.e., the thread #1) sends the responses to the initial downstream request (s) .

[0057] In yet another embodiment, the RID propagation requires adjustments for concurrent scenarios, where multiple receiving events may occur before their associated sending events. The thread-RID map 406 may only store one entry at a time for the parent thread. To handle this, during the eBPF program attached to the alloc_pid system call, the entry in the thread-RID map 406 is replaced using both the parent and child thread identifiers as a key, ensuring that the child thread may uniquely access the correct RID later. In an embodiment, the eBPF program may record information that links request sequence numbers to the worker thread. When the response is sent downstream, the parent thread may use the observed sequence numbers to identify the worker thread and retrieve the correct entry from the thread-RID map 406.

[0058] FIG. 5 illustrates a controller component 500 of a microservices tracing system for tracing a chain of events associated with the handling of a request in a distributed microservices data processing network in accordance with an implementation of the disclosure. The distributed microservices data processing network includes one or more nodes (i.e., a cluster of nodes) . The microservices tracing system includes one or more agent components 506A-C and a controller component 500. The agent components 506A-C are integrated with an operating system kernel (i.e., a server) of the nodes, and the agent components 506A-C intercept receiving and sending events of Transport Control Protocol, TCP, segments of the operating system kernel. Preferably, the agent components 506A-C include an eBPF, extended Berkeley Packet Filter, program. The eBPF program hooks / attaches to two types of kernel functions: sending events (e.g., tcp_sendmsg) and receiving events (e.g., tcp_recvmsg) . These intercepted events are sent to the controller component 500 and the controller component 500 uses the intercepted events to reconstruct the chain of events associated with the handling of the request (i.e., a request chain) . Based on a cluster controller (e.g., Kubernetes) of the  nodes, the agent components 506A-C are dynamically providing with a list of endpoints to trace, which corresponds to the current / active instances of a targeted microservice.

[0059] When a request is issued / originated from outside of the distributed microservices data processing network, the agent component 506A running on a first-hop node of the one or more nodes receives the request to carry out the processing of a series of operations of a distributed microservice. The agent component 506A intercepts an event and enriches the event with cluster related data (e.g., names of the services involved in the communication) . The event indicates that the request has been received. The agent component 506A running on the first hop node selects a request identifier, ID and injects the selected request ID in at least one TCP option of any upstream request. This request ID is propagated within the TCP option subsequent messages so that the other nodes know whether to trace them or not.

[0060] The controller component 500 operates with two key processes as illustrated in FIG. 5. The controller component 500 includes a data collector 502 and a service tracer 504. All events exported by the agent components 506A-C are collected by an event collector 508 of the microservices tracing system. The event collector 508 sends the intercepted receiving and sending events to the data collector 502. The data collector 502 periodically processes the gathered events exported by the agent components 506A-C, and merges any event that relates to fragmented TCP segments. The data collector 502 organizes these events into per-node lists of events 510, sorted by timestamp. The data collector 502 uses thread identifiers and sequence numbers to decide whether the events may be merged or not. The data collector 502 retains the latest timestamp for receiving events and the earliest timestamp for sending events in accordance with the mechanism as described in FIG. 3A. In an embodiment, only the earliest timestamp is used for infrastructure-level components.

[0061] The service tracer 504 receives and processes the collected events to generate trace reports. The service tracer 504 groups the events by their request identifier, RID and matches the events to form spans (i.e., pairs of events) , where a request-receiving event is matched with the corresponding response-sending event, and vice versa (i.e., an event that refers to the receiving of a request is paired with an event that refers to the sending of its response, and vice versa, thus creating receive-send and send-receive span pairs) . Preferably, once a response to the request is detected, the service tracer 504 of the controller component 500 pairs the matching events into the spans. An event which represents a request to a specific microservice is paired with the response from that microservice. Preferably, the spans are combined into a request trace which includes information regarding relationships between the microservices. Optionally, the matching of events is carried out using TCP-related data. Optionally, the TCP-related data includes sequence numbers and payload size. Once all spans for a given RID are identified, the service tracer 504 constructs a trace, starting from the entry point span and determines the relative order of other spans based on the timestamps (i.e., for spans occurring on the same node) and TCP sequence numbers (i.e., for multi-node requests) . The trace is completed when every send-receive span is followed by a corresponding receive-send span, and the entry point span is present. The controller component 500 may then validate and output the completed traces, discarding any pending traces that are incomplete within a defined timeout.

[0062] FIGS. 6A-6B illustrate exemplary use cases of the system of FIG. 2 in accordance with an implementation of the disclosure. The system, as described in FIG. 2 through FIG. 4F, are sufficiently flexible to accommodate the common distributed microservices data processing network, abstracting away from specific frameworks or programming languages. However, certain specialized use cases require complementary mechanisms to ensure full compliance with the system. These mechanisms are integrated into the system as optional, dedicated plug-ins.

[0063] In an embodiment, the thread-RID map mechanism, as described in FIG. 3A, is not entirely sufficient when a child thread is pre-created and scheduled as needed to handle new upstream requests. In this scenario, the system requires an additional mechanism to dynamically track the relationships between threads when a TCP event occurs.  This is achieved through a per-language plug-in (e.g., a thread pool plug-in for Java) that determines and updates a parent-child thread relationship in real time, maintaining a parent thread map accordingly.

[0064] The implementation of this mechanism is highly language or framework-dependent. For example, the thread pool plug-in for Java uses the Java Agent instrumentation tool. This thread pool plug-in continuously monitors all Java Virtual Machines, JVMs, running across the one or more nodes, and attaches a Java agent module to any JVM that loads relevant thread pool classes (e.g., ThreadPoolExecutor) . The Java agent module loads transformers that modify specific Runnable and Callable classes, ensuring that worker threads perform additional operations before and after executing their run or call methods. Specifically, when a thread is scheduled from the pool, the thread pool plug-in establishes the association between a main thread and a scheduled thread. Before executing a run method, the scheduled thread invokes a custom system call (i.e., ID = 60319) , and passes the identifiers of the two threads as arguments. The agent component of the microservices tracing system deploys an eBPF program that hooks into this custom system call, and records the thread relationship in the parent thread map so that the mechanism, as described in FIG. 4C, operates transparently. The same system call is invoked after the run method completes and removes the relationship from the parent thread map.

[0065] Certain libraries may implement parallel processing through abstract units called coroutines, which may be suspended and resumed at any time to optimize performance. Unlike kernel threads, co-routines do not maintain a 1: 1 relationship with system threads, and a single co-routine may be rescheduled on different threads throughout its lifecycle. As a result, relying on the thread identifiers to propagate the RID from a receiving event to the corresponding sending event is impractical. To address this, a plug-in is developed for co-routines in Golang, which is used to build microservices. This plug-in installs application-level hooks (i.e., uprobes) through eBPF programs to (i) track which system thread is executing a given co-routine, and (ii) store an entry in the parent thread map for each scheduled thread on both sides of the communication, using the identifier of a serving co-routine as the "parent thread. " This enables the agent component of the microservices tracing system to propagate the RID, as described in FIG. 4C. FIG. 6A illustrates the co-routines use case, where downstream and upstream communications are managed by two different co-routines, each potentially scheduled on more than two different threads over time.

[0066] The first-in, first-out, FIFO, mechanism, as described in FIG. 4B, generally applies to most infrastructure components. However, it may not hold for certain middleware, such as the Envoy proxy, which employs complex processing and forwarding behaviors influenced by system events (e.g., Envoy relies on libevent, an event-driven networking library) . In these cases, correlating downstream and upstream messages and vice versa becomes challenging, even if both are handled by the same thread as shown in FIG. 6B. To address this, an Envoy-specific plug-in is developed that uses uprobes to intercept the beginning and end of stream handling events. The Envoy-specific plug-in updates entries in the thread-RID map accordingly, transparently adapting the mechanism, as described in FIG. 2, to ensure that the correct RID is propagated. FIG. 6B illustrates the Envoy-specific use case, where the correspondence between the downstream and upstream messages does not follow a predictable temporal pattern (e.g., FIFO or LIFO) and depends on software-specific behaviors.

[0067] FIG. 7 is a flow diagram that illustrates a method of tracing a chain of events associated with the handling of a request in a distributed microservices data processing network in accordance with an implementation of the disclosure. The distributed microservices data processing network includes one or more nodes. At a step 702, a request originating from outside of the distributed microservices data processing network is received at a first-hop node of the distributed microservices data processing network and the network is requested to carry out processing of a distributed microservices series of operations. At a step 704, an event is reported to a controller component which is part of a microservices tracing system. The event indicates that the request has been received. Each node of the network which contributes to the processing of the distributed microservices series of operations has an agent component, which is  also part of the microservices tracing system. The agent component is integrated with the operating system kernel of the node, which intercepts receiving and sending events of Transport Control Protocol, TCP, segments of the kernel. The first hop node selects a request identifier and injects the selected request identifier in at least one TCP option of any upstream request. Each of the other nodes of the one or more nodes that observes the request identifier in the at least one TCP option propagates the observed request identifier to any upstream requests until a response is sent. The intercepted receiving and sending events that include an injected request identifier are sent by the nodes to the controller component, which uses the receiving and sending events to reconstruct the chain of events associated with the handling of the request.

[0068] The method operates in a non-intrusive manner, focusing on microservices while ensuring comprehensive coverage of all components involved in processing request chains with minimal overhead. The method operates at the kernel level and does not interfere with application-level components. The method deploys a dynamic extended Berkeley Packet Filter, eBPF, program within the operating system kernel on machines running the microservices. The eBPF program transparently leverages kernel functions related to TCP socket operations, and intercepts TCP segment’s send and receive events, which are universal across all connection-oriented communications. By intercepting these events, the method provides consistent and stable monitoring across both application and infrastructure components, independent of programming languages, as it relies solely on the TCP protocol. Specifically, the eBPF program reports relevant events to user-space and injects a TCP option containing a request identifier into outgoing segments. This identifier enables tracking of requests and responses across microservices and facilitates a sampling mechanism that selectively traces specific request chains, thereby reducing the overhead of reporting excessive events to user-space. The method effectively improves tracing in microservice-based systems by identifying events behind each request, measuring their duration, and reconstructing their relationships (i.e., service chains) .

[0069] Preferably, the agent component includes an eBPF, extended Berkeley Packet Filter, program. Optionally, the agent component uses kernel probes to intercept the receiving and sending events. As the eBPF program is directly to TCP-related kernel functions using the kernel probes, the method significantly reduces processing overhead compared to the existing approaches by minimizing hook frequency and leveraging network processing performed by the kernel's network stack. Preferably, the first-hop node determines whether to trace the received request based on a sampling mechanism. Preferably, the intercepted events that include an injected request identifier are sent to the controller component until a response to the request is detected.

[0070] Preferably, once a response to the request is detected, the controller component pairs matching events into spans. An event which represents a request to a specific microservice is paired with the response from that microservice. Optionally, the matching is carried out using TCP-related data. Optionally, the TCP-related data includes sequence numbers and payload size.

[0071] Preferably, the spans are combined into a request trace which includes information regarding relationships between the microservices. Optionally, each agent component populates a map of service Internet Protocol, IP, addresses of tracked services. Optionally, the eBPF program uses a parent thread map to keep track of thread parent-child relationships.

[0072] FIG. 8 is an illustration of a computer system in which the various architectures and functionalities of the various previous implementations may be implemented. As shown, the computer system 800 includes at least one processor 804 that is connected to a bus 802, wherein the computer system 800 may be implemented using any suitable protocol, such as PCI (Peripheral Component Interconnect) , PCI-Express, AGP (Accelerated Graphics Port) , Hyper Transport, or any other bus or point-to-point communication protocol (s) . The computer system 800 also includes a memory 806.

[0073] Control logic (software) and data are stored in the memory 806 which may take a form of random-access memory (RAM) . In the disclosure, a single semiconductor platform may refer to a sole unitary semiconductor-based integrated  circuit or chip. It should be noted that the term single semiconductor platform may also refer to multi-chip modules with increased connectivity which simulate on-chip modules with increased connectivity which simulate on-chip operation, and make substantial improvements over utilizing a conventional central processing unit (CPU) and bus implementation. Of course, the various modules may also be situated separately or in various combinations of semiconductor platforms per the desires of the user.

[0074] The computer system 800 may also include a secondary storage 810. The secondary storage 810 includes, for example, a hard disk drive and a removable storage drive, representing a floppy disk drive, a magnetic tape drive, a compact disk drive, digital versatile disk (DVD) drive, recording device, universal serial bus (USB) flash memory. The removable storage drive at least one of reads from and writes to a removable storage unit in a well-known manner.

[0075] Computer programs, or computer control logic algorithms, may be stored in at least one of the memory 806 and the secondary storage 810. Such computer programs, when executed, enable the computer system 800 to perform various functions as described in the foregoing. The memory 806, the secondary storage 810, and any other storage are possible examples of computer-readable media.

[0076] In an implementation, the architectures and functionalities depicted in the various previous figures may be implemented in the context of the processor 804, a graphics processor coupled to a communication interface 812, an integrated circuit (not shown) that is capable of at least a portion of the capabilities of both the processor 804 and a graphics processor, a chipset (namely, a group of integrated circuits designed to work and sold as a unit for performing related functions, and so forth) .

[0077] Furthermore, the architectures and functionalities depicted in the various previous-described figures may be implemented in a context of a general computer system, a circuit board system, a game console system dedicated for entertainment purposes, an application-specific system. For example, the computer system 800 may take the form of a desktop computer, a laptop computer, a server, a workstation, a game console, an embedded system.

[0078] Furthermore, the computer system 800 may take the form of various other devices including, but not limited to a personal digital assistant (PDA) device, a mobile phone device, a smart phone, a television, and so forth. Additionally, although not shown, the computer system 800 may be coupled to a network (for example, a telecommunications network, a local area network (LAN) , a wireless network, a wide area network (WAN) such as the Internet, a peer-to-peer network, a cable network, or the like) for communication purposes through an I / O interface 808.

[0079] It should be understood that the arrangement of components illustrated in the figures described are exemplary and that other arrangement may be possible. It should also be understood that the various system components (and means) defined by the claims, described below, and illustrated in the various block diagrams represent components in some systems configured according to the subject matter disclosed herein. For example, one or more of these system components (and means) may be realized, in whole or in part, by at least some of the components illustrated in the arrangements illustrated in the described figures.

[0080] In addition, while at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software that when included in an execution environment constitutes a machine, hardware, or a combination of software and hardware.

[0081] Although the disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein without departing from the spirit and scope of the disclosure as defined by the appended claims.

Claims

1.A method of tracing a chain of events associated with the handling of a request in a distributed microservices data processing network comprising a plurality of nodes (202A-N) , comprising steps of:receiving at a first-hop node (202A) of the distributed microservices data processing network, the request originating from outside of the distributed microservices data processing network and requesting the network to carry out processing of a distributed microservices series of operations; andreporting an event to a controller component (208, 500) which is part of a microservices tracing system (204) , the event indicating that the request has been received;wherein each node of the network which contributes to the processing of the distributed microservices series of operations has an agent component (206A-C, 306A-E, 404A-E, 506A-C) , which is also part of the microservices tracing system, integrated with the operating system kernel of the node, which intercepts receiving and sending events of Transport Control Protocol, TCP, segments of the kernel (320) ;wherein the first hop node selects a request identifier and injects the selected request identifier in at least one TCP option (318) of any upstream request, and wherein each of the other nodes of the plurality of nodes that observes the request identifier in the at least one TCP option propagates the observed request identifier to any upstream requests until a response is sent; andwherein the intercepted receiving and sending events that include an injected request identifier are sent by the nodes to the controller component, which uses the receiving and sending events to reconstruct the chain of events associated with the handling of the request.2.The method of claim 1, wherein the agent component includes an eBPF, extended Berkeley Packet Filter, program (306B-E) .3.The method of claim 1, wherein the agent component uses kernel probes to intercept the receiving and sending events.4.The method of claim 1, wherein the first-hop node determines whether to trace the received request based on a sampling mechanism.5.The method of claim 1, wherein the intercepted events that include an injected request identifier are sent to the controller component until a response to the request is detected.6.The method of claim 5, wherein, once a response to the request is detected, the controller component pairs matching events into spans, wherein an event which represents a request to a specific microservice (402, 314, 212A-N) is paired with the response from that microservice.7.The method of claim 6, wherein the matching is carried out using TCP-related data.8.The method of claim 7, wherein the TCP-related data includes sequence numbers and payload size.9.The method of claim 6, wherein the spans are combined into a request trace which includes information regarding relationships between the microservices.10.The method of claim 1, wherein each agent component populates a map of service Internet Protocol, IP, (302) addresses of tracked services.11.The method of claim 2, wherein the eBPF program uses a parent thread map (410) to keep track of thread parent-child relationships.12.A system comprising means adapted for carrying out all the steps of the method according to any preceding method claim.13.A computer program comprising instructions for carrying out all the steps of the method according to any preceding method claim, when said computer program is executed on a computer system.

Images