Skip to content
Calcrivo

Distributed Tracing Storage Calculator

Calculate daily distributed tracing storage from trace volume, spans per trace, average span size and sampling rate.

Inputs

traces/day

Total distributed traces generated per day before sampling.

spans

Average number of spans (operations) within one trace.

bytes

Average serialized size of one span, including tags and attributes.

%

Percent of traces actually retained after head/tail sampling.

Storage per Day

7.20GB/day

Projected Monthly Storage

216.0GB/month

Sampled Traces per Day

1,000,000traces

Traces Dropped by Sampling

9,000,000traces

Step by step

  1. Sampled traces/day: traces × sampling%

    10,000,000 × 10%

    = 1,000,000 traces/day

  2. Sampled spans/day: sampled traces × spans/trace

    1,000,000 × 12

    = 12,000,000 spans/day

  3. Storage/day: spans × avg span bytes

    12,000,000 × 600

    = 7.20 GB/day

How it works

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.

Formula

storage_GB_per_day = traces_per_sec × avg_trace_size_KB × 86400 / (1024 × 1024)

traces_per_sec
Traces ingested per second
avg_trace_size_KB
Average trace size including all spans (KB)

Frequently Asked Questions

What sampling rate is typical in production?

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.

Why does sampling rate matter more than trace count?

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.

How does tail-based sampling change this calculation?

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.

Does span size vary a lot between services?

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.

You might also need