OpenTelemetry Data Volume Calculator

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

Inputs

Number of Servicesservices

Number of instrumented services emitting spans.

Spans/sec per Servicespans/s

Average span emission rate per service before sampling.

Avg Span Sizebytes

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

Trace Sampling Rate%

Percent of traces retained after sampling (head or tail-based).

Trace Volume per Day

3.22GB

Trace Volume per Month

96.6GB

Sampled Spans/sec

50.0spans/s

Volume Avoided by Sampling

28.97GB/day

Step by step

Raw spans/sec: services × spans/sec/service
25 × 20
= 500.0 spans/s
Sampled spans/sec
500.0 × 10%
= 50.0 spans/s
Volume/day: sampled spans/sec × span size × 86400
50.0 × 800 × 86400
= 3.22GB/day
Volume/month
3.22 × 30
= 96.6GB

How it works

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

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.

You might also need

Metrics Cardinality Calculator Log Retention Calculator Prometheus Storage Calculator