OpenTelemetry Data Volume Calculator

Calculate total telemetry data volume from OpenTelemetry traces, metrics and logs.

About OpenTelemetry Data Volume Calculator

Trace data volume is driven by how many spans your services emit, how large each span is on the wire (attributes, events, resource metadata), and what fraction survive sampling before being exported and stored. Formula: volume_per_day = services × spans_per_sec × span_size × (sampling_rate / 100) × 86400. Sampling is the primary lever for controlling cost at scale, since unsampled tracing at high span rates can generate enormous data volumes.

Formula

volume_per_day_GB = services × spans_per_sec × avg_span_bytes × (sampling_rate / 100) × 86400 / (1024³)

services: Number of instrumented services
spans_per_sec: Spans emitted per second per service
avg_span_bytes: Average serialized span size (bytes)
sampling_rate: Percentage of traces retained after sampling

Worked example

With the default values below, OpenTelemetry Data Volume Calculator returns Trace Volume per Day of 3.22. Change any input above and every figure here is recalculated in your browser.

Inputs used

Number of Servicesaccepts 1–100,000 services: 25 services
Spans/sec per Serviceaccepts 0–1,000,000 spans/s: 20 spans/s
Avg Span Sizeaccepts 1–1,000,000 bytes: 800 bytes
Trace Sampling Rateaccepts 0–100 %: 10 %

Results

Trace Volume per Day: 3.22 GB
Trace Volume per Month: 96.6 GB
Sampled Spans/sec: 50.0 spans/s
Volume Avoided by Sampling: 28.97 GB/day

Step by step

1Raw spans/sec: services × spans/sec/service= 500.0 spans/s
2Sampled spans/sec= 50.0 spans/s
3Volume/day: sampled spans/sec × span size × 86400= 3.22GB/day
4Volume/month= 96.6GB

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

What's a typical trace sampling rate in production?

Head-based sampling commonly runs 1-10% for high-traffic services to control cost, while tail-based sampling can retain 100% of error/slow traces and a small percentage of 'normal' traces, giving better signal at similar overall volume.

What drives average span size?

The number and size of attributes (HTTP headers, DB queries, custom tags), span events, and resource/service metadata attached to each span — verbose auto-instrumentation libraries often produce larger spans than hand-tuned manual instrumentation.

Should I size my OTel collector/backend for raw or sampled volume?

Collectors that sit before the sampling decision (e.g. running tail-based sampling) must handle the raw volume in memory/buffer even though only the sampled fraction is exported to long-term storage — size collector resources for raw throughput and storage for sampled volume.

How does this compare to metrics or log volume?

Traces are typically the highest-volume telemetry signal per unit of application activity because each request can generate many spans with rich metadata, which is why aggressive sampling is standard practice for tracing but rare for metrics.