OpenTelemetry can give engineering teams a consistent way to collect traces, metrics, and logs, but an observability rollout needs more than adding an SDK. This practical guide explains how to estimate telemetry volume, storage demand, sampling impact, and implementation effort so you can choose useful signals, set sensible assumptions, and revisit the plan when traffic or pricing changes.
Overview
OpenTelemetry is a framework and set of components for generating, collecting, and exporting observability data. Its main signals are traces, metrics, and logs. A trace follows a request or operation across services; a metric records numeric measurements over time; and a log provides an event-oriented record with context.
The practical value of OpenTelemetry instrumentation is consistency. Services can use common resource attributes, propagation conventions, semantic names, and export paths instead of each team building a separate integration. A typical architecture places instrumentation in an application, sends telemetry to an OpenTelemetry Collector or another compatible endpoint, and then exports selected data to an observability backend.
The main planning question is not simply, “How do we enable OpenTelemetry?” It is, “Which data do we need, at what detail, for which operational decisions, and at what recurring volume?” Estimating those inputs helps prevent two common problems: collecting too little information to investigate incidents, or collecting so much high-cardinality and low-value data that retention and query costs become difficult to control.
Use this guide alongside an operational plan such as a practical SLO, SLA, and reliability guide. Observability is most useful when the signals connect to service objectives, incident response, and concrete engineering actions.
How to estimate telemetry volume
Start with a simple model for each signal. The numbers do not need to be perfect; they need to be explicit enough to test and revise.
1. Estimate trace spans
Use this formula for daily spans:
Daily spans = requests per second × seconds per day × average spans per request × trace sampling rate
If a service handles 20 requests per second, has an average of 12 spans per request, and retains 10% of traces, the illustrative calculation is:
20 × 86,400 × 12 × 0.10 = 2,073,600 retained spans per day
This is a planning example, not a performance benchmark. Measure the average spans per request from representative traffic because a simple endpoint and a workflow that calls several downstream services can have very different trace shapes.
2. Estimate metric series
Metrics are usually estimated by active time series rather than by the number of metric names alone. A series is affected by labels or attributes. Use:
Approximate samples per day = active series × collection frequency in seconds × seconds per day ÷ collection interval
For example, 2,000 active series collected every 60 seconds produce approximately:
2,000 × 86,400 ÷ 60 = 2,880,000 samples per day
Review labels carefully. A label such as deployment environment may have a small, predictable set of values. A label containing request ID, user ID, or an unrestricted URL can create a rapidly changing set of series and should generally be treated as a tracing or log concern instead.
3. Estimate log volume
For logs, estimate events and average encoded size:
Daily log volume = log events per second × seconds per day × average bytes per event
Then adjust for compression, retention, replicas, and any backend-specific indexing overhead. Keep those adjustments as separate assumptions instead of hiding them inside one percentage. That makes the model easier to update when a storage provider, export format, or retention policy changes.
4. Separate generated, exported, and retained data
Instrumentation may generate data that is filtered by the application, a Collector, a gateway, or the destination. Track at least three stages:
- Generated: what the applications create.
- Exported: what leaves the application or collection layer.
- Retained: what the backend stores for later query.
This distinction matters when evaluating sampling. A policy that retains 10% of traces can reduce retained trace volume, but it does not necessarily eliminate all instrumentation, network, or collection overhead.
Inputs and assumptions
Create a small worksheet before choosing exporters or retention periods. Record the value, unit, source, and confidence for each input.
- Traffic: average and peak requests per second, batch volume, scheduled jobs, and background work.
- Trace shape: average spans per request, downstream calls, asynchronous work, and error-path behavior.
- Sampling: head sampling rate, tail-sampling rules, error retention, latency-based retention, and special treatment for important workflows.
- Metrics: active series, scrape or collection interval, label cardinality, and whether infrastructure metrics are included.
- Logs: events per second, average event size, structured fields, multiline behavior, and debug logging during incidents.
- Retention: hot-query retention, archive retention, deletion schedule, and separate policies for security or audit data.
- Pipeline overhead: Collector replicas, queues, retries, batching, filtering, and temporary buffering during destination outages.
- Operational goals: the incidents, SLOs, deployment checks, or user journeys the telemetry must support.
Define service identity consistently. Useful resource attributes commonly include service name, service version, deployment environment, and a stable service instance or host identity where appropriate. Avoid placing highly variable values into metric dimensions. For traces and logs, include enough context to connect records without exposing secrets or unnecessary personal data.
Choose exporters based on the destination and the operational boundary you need. A Collector can provide a central place for batching, filtering, routing, and redaction, while direct export may be simpler for a small service. Validate the full path rather than assuming that successful SDK initialization means the backend is receiving usable data.
For related operational work, review the Kubernetes troubleshooting checklist and the guide to metrics monitoring options. They help place telemetry decisions in the context of containers, metrics storage, and incident diagnosis.
Worked examples
Example 1: reducing retained trace volume
Assume an application handles 50 requests per second, averages 8 spans per request, and initially retains every trace. The daily span estimate is:
50 × 86,400 × 8 = 34,560,000 spans per day
If the team changes the baseline sampling rate to 5%, the illustrative retained estimate becomes:
34,560,000 × 0.05 = 1,728,000 spans per day
The team could then add a rule to retain all traces containing errors or unusually slow operations, subject to backend and privacy requirements. The resulting volume will be higher than the baseline 5% calculation, so the worksheet should include an estimated exception rate rather than treating the sample rate as the final answer.
Example 2: comparing metric label designs
Suppose a request-duration metric has 4 environments, 6 regions, 10 services, and 3 response classes. Its estimated combinations are:
4 × 6 × 10 × 3 = 720 series
If a team adds an unbounded route label with 500 observed values, the theoretical combinations become:
720 × 500 = 360,000 series
This simplified calculation demonstrates why route normalization matters. Prefer a controlled route template or a trace attribute for detailed request identity, and verify the resulting series count in a staging or limited production rollout.
Example 3: planning a rollout outcome
Define success in operational terms rather than only by data volume. A first rollout might aim to make every production service identifiable in traces, connect a request to its downstream calls, expose a small set of latency and error metrics, and preserve enough context to investigate one agreed incident scenario. Track coverage, export failures, dropped records, collector queue pressure, and time required to move from an alert to a probable cause.
Instrumentation can be introduced through the same controlled gates used for application delivery. The CI/CD pipeline checklist provides a useful structure for testing configuration, validating security checks, and preventing an observability change from silently breaking deployments.
When to recalculate
Revisit the estimate whenever an input changes materially. Common triggers include a traffic increase, a new service-to-service workflow, a change in average span count, a new metric label, a longer retention period, or a change in backend pricing inputs. Also recalculate after enabling debug logs, adding a new exporter, changing collection intervals, or moving sampling from the application to a Collector.
Review the model on a regular operational cadence as well. Compare estimated and observed generated, exported, and retained volume. Investigate gaps caused by dropped spans, retries, compression assumptions, cardinality growth, or sampling rules that behave differently on error paths.
- Export the current telemetry counts and storage or usage measurements.
- Compare them with the worksheet’s traffic, size, sampling, and retention assumptions.
- Identify the largest source of unexpected volume, such as a label, log field, or high-span workflow.
- Test a targeted change in a limited environment or service group.
- Confirm that the change preserves the traces, metrics, and logs needed for defined SLOs and incident scenarios.
- Update the assumptions, owner, and review date in the observability plan.
OpenTelemetry instrumentation is most sustainable when it is treated as a maintained engineering system rather than a one-time setup task. Start with the signals that answer real reliability questions, make volume assumptions visible, and adjust sampling, attributes, exporters, and retention as the system changes.
