Calculate total telemetry data volume from OpenTelemetry traces, metrics and logs.
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.
volume_per_day_GB = services × spans_per_sec × avg_span_bytes × (sampling_rate / 100) × 86400 / (1024³)
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.
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.
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.
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.