Estimate storage requirements for distributed tracing spans across a sampling rate.
Distributed tracing storage depends on how many traces are actually retained after sampling, how many spans each trace contains, and the serialized size of each span: storage_per_day = traces × spans_per_trace × avg_span_bytes × sampling%. Sampling is the dominant lever for controlling cost — most production systems sample well under 100% of traces, since full tracing at high request volumes would be prohibitively expensive to store.
storage_GB_per_day = traces_per_sec × avg_trace_size_KB × 86400 / (1024 × 1024)
1-10% head-based sampling is common for high-traffic services, often combined with tail-based sampling that always retains traces with errors or high latency regardless of the base rate.
Since storage scales linearly with sampled trace volume, halving the sampling rate roughly halves storage cost — it's usually the cheapest lever to pull before optimizing span size or retention.
Tail-based sampling makes retention decisions after seeing the full trace (favoring errors/slow requests), so the effective sampling rate can vary by trace characteristics rather than being a flat percentage — model it as a blended average rate for this calculator.
Yes — spans with rich attributes (SQL queries, HTTP headers, custom tags) can be several KB, while simple internal spans might be under 200 bytes; profile actual span sizes from your tracing backend for accuracy.