## 1 Introduction  
Distributed tracing (DT) has emerged as a crucial tool for effectively monitoring and troubleshooting native cloud applications [1, 2, 3, 4, 5, 6, 7]. It plays a pivotal role in understanding the behavior and performance of applications across distributed environments. Native cloud applications often adopt microservices architecture, decomposing the application into smaller, loosely coupled services. Each service performs a specific function and communicates with others via Application Programming Interfaces (APIs). DT enables the inspection of the flow of requests across the microservices, providing insights into how requests are processed and identifying any bottlenecks or issues within the system [8]. Native cloud applications are designed to be highly scalable and dynamically allocate resources based on demand. DT accommodates this dynamic nature by providing visibility regarding the performance of services as they scale up or down in response to changes in workload. This ensures that performance issues are detected and addressed in real time, maintaining the application's reliability and responsiveness. They often utilize containerization and container orchestration via Docker and Kubernetes, respectively. Those technologies enable applications to be deployed and managed efficiently in a distributed environment. DT is integrated with container platforms for tracking requests as they traverse across containers and pods, providing insights into resource utilization and communication patterns. DT is typically part of a broader observability stack, including metrics and logging [2; 9]. Integration with metrics allows for correlation between trace data and performance metrics, enabling a more profound analysis of application behavior. Similarly, integration with logging platforms provides context around specific events or errors captured in logs, enhancing the troubleshooting process [10; 11; 12; 13; 14; 15; 16; 17; 18]. Several critical points are made regarding the complexities and challenges associated with DT. One is the volume of traces in which many requests are routine and unremarkable, often called normal traces. Sampling in DT involves capturing a subset of traces for analysis instead of storing every trace to manage costs. This subset includes \"interesting\" traces encompassing various events in a distributed architecture. Interest can be linked to a trace latency when traces surpassing a latency threshold are selectively sampled. This allows for the identification of performance bottlenecks and areas needing improvement. Interest can also be linked to errors. Erroneous traces or exceptions are sampled to investigate and address system reliability and stability issues. Requests or services can be prioritized to help determine which traces to sample. High-priority components, such as critical services or specific user interactions, are given preference for sampling. Companies typically adopt one of two strategies for capturing these events. The common sampling strategy is head-based sampling [2], in which traces are randomly sampled based on a predefined rate or probability, such as 0.1-1% of all traces. This approach relies on the principle that a sufficiently large dataset will capture the most interesting traces. However, it is worth noting that sampling meaningfully diminishes the value of DT. While sampling is necessary to manage costs, it can limit the effectiveness of DT for troubleshooting and debugging purposes. Developers may encounter situations where important traces are missed due to sampling, leading to a loss of trust in the tracing data. Consequently, developers may revert to traditional debugging methods, such as logs, undermining the value of DT [8]. A more intelligent strategy is called tail-based sampling, where the system waits until all spans within a request have been completed before determining whether or not to retain the trace based on its entirety.