## 2 Related Work
### Industrial Sampling Examples  
Various companies and researchers are developing end-to-end DT technologies in which sampling is one of the core components as the prevailing approach to reducing tracing overheads. Instead of tracing every request, the sampling only captures and persists traces for a subset of requests to the system. To ensure that the captured data are useful, sampling decisions are coherent per request--a trace is either sampled in its entirety, capturing the full end-to-end execution, or not at all. Sampling effectively reduces computational overheads; these overheads are only paid if a trace is sampled, so they can be easily reduced by reducing the sampling probability ([32; 33; 34; 35] with references therein). Large technology companies such as Google, Microsoft, Amazon, and Facebook often develop methods to monitor and analyze the performance of their own systems and applications. Early tracing systems such as Google's Dapper [36] and later Facebook's Canopy [37] make sampling decisions immediately when a request enters the system. This approach, known as head-based sampling, avoids the runtime costs of generating trace data as they occur, uniformly at random, and the resulting data are simply a random subset of requests. In practice, sampling rates can be as low as 0.1% [32]. Tail-based sampling is an alternative to head-based sampling. It captures traces for all requests and only decides whether to keep a trace after it has been generated. While OpenTelemetry [38] offers a tail-based sampling collector, its implementation presents challenges as storing all spans of a trace until the request concludes demands a sophisticated data architecture and solutions. One such end-to-end tracing method to enhance distributed system dependability by dynamically verifying and diagnosing correctness and performance issues is proposed in paper [39]. The idea is based on clustering execution graphs to bias sampling towards diverse and representative traces, even when anomalies are rare. Google has developed DT technologies, such as Google Cloud Trace and OpenCensus, which allow users to collect and analyze trace data from applications running on Google Cloud Platform and other environments. Each Google Cloud service makes its own sampling decisions. When sampling is supported, that service typically implements a default sample rate or a mechanism to use the parent's sampling decision as a hint as to whether to sample the span or maximum sampling rate [40]. OpenCensus provides \"Always\", \"Never\", \"Probabilistic\", and \"RateLimiting\" samplers. The last one tries to sample with a rate per time window, which by default is 0.1 traces/s [41]. Azure Application Insights sampling [42] aims to reduce telemetry traffic, data, and storage costs while preserving a statistically correct analysis of application data. It enables three different types of sampling: adaptive sampling, fixed-rate sampling, and ingestion sampling. Adaptive filtering automatically adjusts the sampling to stay within the given rate limit. If the application generates low telemetry, like during debugging or low usage, it does not drop items as long as the volume stays under the limits. The sampling rate is adjusted to hit the target volume as the telemetry volume rises. Fixed-rate sampling reduces the traffic sent from web servers and web browsers. Unlike adaptive sampling, it reduces telemetry at a fixed rate that a user decides. Ingestion sampling operates where web servers', browsers', and devices' telemetry reaches the Application Insights service endpoint. Although it does not reduce the telemetry traffic sent from an application, it does reduce the amount processed and retained (and charged for) by Application Insights. Microsoft researchers introduced an observability-preserving trace sampling method, denoted as STEAM, based on Graph Neural Networks, which aims to retain as much information as possible in the sampled traces [43].