OpenTelemetry gives an organization a place to make telemetry decisions before a vendor bills for them. It does not make those decisions for free, and a poorly built Collector layer can cost more than the vendor charges it was meant to reduce.
Short answer
An OpenTelemetry Collector positioned between applications and observability backends can filter, sample, transform and route telemetry before it reaches a billed destination — which is real cost control, not a marketing claim. But the Collector is a distributed system with its own failure modes: badly designed pipelines can duplicate telemetry across exporters, drop data silently under memory pressure, or become an operational dependency that itself requires the engineering effort it was meant to save. OpenTelemetry is not free observability infrastructure. It is a genuine cost-control layer only when its processors, memory limits and ownership are designed as carefully as the vendor billing it is trying to manage.
What the Collector actually is, structurally
The OpenTelemetry Collector is a pipeline: telemetry enters through receivers, passes through an ordered chain of processors, and leaves through exporters — with connectors available to link the output of one pipeline into the input of another, which is how routing and fan-out between multiple destinations get built. Two deployment patterns are common and solve different problems: an agent Collector runs close to the workload — as a sidecar or a per-node DaemonSet on Kubernetes — and a gateway Collector runs centrally, aggregating telemetry from many agents before forwarding it onward. Cost-optimization processors can run at either layer, and the choice affects both how early filtering happens and how much processing work gets centralized versus distributed.
This architecture is what makes preprocessing-before-ingestion possible at all: decisions that would otherwise require support from every observability backend individually — filter this, sample that, route this elsewhere — can instead be made once, in a layer the organization controls, before telemetry reaches any billed destination.
The processors that actually control cost
Filtering and transformation
The Filter processor uses the OpenTelemetry Transformation Language (OTTL) to define conditions under which telemetry — spans, span events, metrics, datapoints or logs — is dropped entirely before reaching an exporter. This is the most direct lever: telemetry that never leaves the Collector cannot be billed by whatever receives the Collector's output.
The Transform and Attributes processors modify telemetry rather than dropping it — adding, renaming, deleting or rewriting attributes on metrics, spans and logs. This matters for cost in a less obvious way than filtering does: normalizing attribute names and values before export prevents the same underlying label from becoming multiple distinct dimensions on the far side simply because different services encoded it inconsistently — a schema-hygiene function that reduces cardinality without dropping any information.
Head sampling versus tail sampling
Head-based sampling makes the keep-or-drop decision early, typically at or near the point of generation, based on information available at that moment — a fixed percentage, or a probabilistic decision per trace. It is cheap and simple, but it cannot see how a trace ends before deciding whether to keep it, which means it cannot guarantee that a trace containing an eventual error or unusual latency will be the one that gets sampled.
Tail-based sampling, implemented in the Collector's Tail Sampling processor, evaluates a trace after it has substantially completed, once its spans have arrived, and makes the keep-or-drop decision against policies that can reference the trace's actual outcome — for example, sampling every trace with an error status, every trace above a latency threshold, and only a small percentage of ordinary successful traces. This produces a fundamentally more useful sampled population than head sampling for the same or lower total volume, because the traces retained are disproportionately the ones with diagnostic value.
That capability is not free. Tail sampling requires the Collector to buffer spans for a trace until a decision window closes, which has real memory implications, and — critically for multi-instance Collector deployments — it requires all spans belonging to a given trace to reach the same Collector instance, or the sampling decision cannot be made correctly. This is precisely the load-balancing problem discussed below, and it is the most common reason tail sampling deployments fail in production despite being architecturally sound on paper.
Routing
Routing determines which telemetry goes to which destination, and the current OpenTelemetry-recommended mechanism for this is the Routing Connector rather than the now-deprecated Routing Processor. The distinction matters operationally, not just semantically: a connector routes to other pipelines rather than directly to exporters, which means processors can still run after a routing decision has been made — for example, applying a different sampling policy to logs routed toward long-term archival storage than to logs routed toward a low-latency operational backend.
This is the mechanism that makes a genuinely tiered telemetry architecture possible: not one Collector pipeline sending everything to one destination, but a pipeline that inspects telemetry and sends different subsets to different backends based on what that telemetry actually needs — echoing, at the collection layer, the same tiering logic covered for Datadog specifically in Datadog Logs Pricing: Ingestion, Indexing and Retention Explained.
Batching
The Batch processor groups telemetry into batches before export, primarily for transport efficiency rather than cost reduction in the billing sense — but transport efficiency has second-order cost effects: fewer, larger export calls reduce network overhead and backend-side per-request processing, which matters at meaningful scale even though it does not change the underlying billed volume the way filtering or sampling does.
Why a badly built Collector layer can increase cost
Every mechanism above is a genuine lever when designed correctly. Each has a corresponding failure mode when it is not, and these failure modes are specific enough to name.
Duplication instead of routing. A pipeline misconfigured to export the same telemetry to multiple destinations when only routing — sending different subsets to different places — was intended will duplicate billed volume rather than control it. This is a configuration error, not a limitation of the architecture, but it is common enough in early Collector deployments to call out explicitly.
Silent data loss under memory pressure. The Memory Limiter processor exists specifically to prevent Collector out-of-memory crashes by monitoring usage and applying backpressure — refusing new data with a signal that upstream components are expected to retry — once configured thresholds are approached. Correctly configured, this is a stability mechanism. Incorrectly ordered in the pipeline — the Memory Limiter needs to run first, ahead of Batch and especially ahead of Tail Sampling, to be effective — or configured with limits that do not account for tail sampling's buffering requirement, it can instead produce silent, hard-to-diagnose telemetry loss precisely when the system is under the load conditions that make the missing data most valuable.
An operational dependency that itself needs engineering. A Collector fleet — especially a gateway tier running tail sampling, routing and multiple exporters — is a piece of production infrastructure with its own reliability requirements: capacity planning, upgrade management, monitoring of the Collector's own health, and an on-call owner when it breaks. An organization that adopts OpenTelemetry expecting to eliminate operational burden and instead discovers it has added a new distributed system to operate has not achieved the cost reduction the architecture promised — it has partially relocated cost from vendor billing into internal engineering time, which is a legitimate trade only when accounted for honestly.
Load-balancing failures specific to tail sampling. Because tail sampling requires all spans of a trace to arrive at one Collector instance to make a correct decision, a gateway tier running tail sampling behind a naive load balancer that does not route by trace ID will make sampling decisions on incomplete traces — silently degrading sampling quality in a way that is difficult to detect without deliberately checking for it, since the pipeline does not error out; it simply samples less accurately than intended.
Backpressure that shifts, rather than removes, the problem. Backpressure applied correctly protects the Collector from crashing by slowing ingestion or triggering retries upstream. Applied without a plan for what upstream does with that pressure, it can move the failure mode to wherever telemetry originates — an application that blocks on a full export queue, for instance — trading a Collector-level problem for an application-level one that is often harder to diagnose.
When preprocessing before ingestion makes sense, and when it does not
Preprocessing earns its complexity when at least one of these is true: telemetry volume is large enough that even a modest reduction in billed volume outweighs the engineering cost of running the Collector layer; the organization needs one control point across multiple observability backends rather than configuring similar logic separately inside each vendor's product; or tail-based trace sampling's diagnostic-value improvement over head sampling is worth the additional infrastructure it requires.
Vendor-side controls remain preferable, or at least sufficient on their own, when telemetry volume does not yet justify the operational investment in a Collector fleet, when the organization lacks the capacity to own a new piece of production infrastructure responsibly, or when a vendor's native controls — index-level exclusion filters, tag-based indexing configuration, usage attribution — already solve the specific cost problem at hand without requiring a new architectural layer. The Datadog-specific version of several of these native controls is covered in Datadog Bill Too High? 12 Configuration Mistakes That Inflate Observability Costs; where those controls are sufficient, adding a Collector layer purely for cost reasons is added complexity without a proportional benefit.
The honest framing is that OpenTelemetry and vendor-side controls are not mutually exclusive alternatives. A mature architecture generally uses both: Collector-level filtering and routing to control what reaches each backend in the first place, and that backend's native indexing, retention and attribution controls to manage what happens after arrival.
A decision table
| Situation | Preprocessing before ingestion | Vendor-side controls |
|---|---|---|
| High telemetry volume across multiple backends | Strong fit — one control point instead of several | Weaker — logic duplicated per vendor |
| Small or moderate volume, single backend | Often unnecessary complexity | Usually sufficient on its own |
| Need tail-based sampling for trace quality | Requires a Collector — no vendor provides this pre-ingestion | Not available as a vendor-side substitute |
| No capacity to operate new production infrastructure | Risk of the Collector becoming its own incident source | Lower operational risk |
| Multi-vendor or migration-in-progress architecture | Strong fit — portable collection layer, covered in How to Run a Parallel Observability Migration Without a Big-Bang Cutover | Vendor-specific logic does not transfer |
| Cost driver is Kubernetes-specific label and churn design | Collector-level relabeling and filtering is the right layer | Vendor-side tag-cardinality settings help but do not address the source; see How Kubernetes Labels and Container Churn Increase Observability Costs |
Ownership: the part that determines whether this stays cheap
A Collector fleet that nobody owns tends to accumulate the same governance failures that cause vendor bills to grow unchecked in the first place — pipelines added ad hoc, filters that were never revisited, a routing configuration that made sense for the workload that existed when it was written and has not been reviewed since. The mechanism is different from a vendor-side governance gap, but the pattern is the same: a genuinely useful control, left unowned, decays into either uncontrolled cost or, worse, silent data loss that nobody notices until an incident postmortem asks why a specific signal was missing.
Treat Collector pipeline configuration with the same ownership discipline as any other piece of production infrastructure: someone accountable for reviewing changes, someone who understands what each filter and sampling policy is actually removing, and periodic validation that the pipeline still reflects current telemetry needs rather than a snapshot of decisions made during initial rollout.
FAQ
No. OpenTelemetry provides the architectural capability to filter, sample, transform and route telemetry before it reaches a billed destination, but that capability only reduces cost when the Collector pipeline is designed and operated correctly. A poorly configured pipeline can duplicate telemetry, drop data silently, or become an operational burden that offsets the savings it was meant to produce.
Head sampling makes the keep-or-drop decision early, based on information available at or near the point of generation, and cannot account for how a trace eventually turns out. Tail sampling, implemented in the Collector's Tail Sampling processor, waits until a trace has substantially completed and can apply policies based on outcome — such as keeping all traces with errors or high latency — producing a more diagnostically useful sampled population for a given volume.
Tail sampling requires the Collector to buffer a trace's spans until a decision window closes, which has real memory implications, and it requires all of a trace's spans to reach the same Collector instance to make a correct decision — which means a gateway tier running tail sampling needs load balancing that routes by trace ID, not naive round-robin distribution, or sampling quality degrades silently.
The Routing Connector is the current recommended mechanism, replacing the deprecated Routing Processor. Connectors route to other pipelines rather than directly to exporters, which allows processors to run after a routing decision — for example, applying different retention or sampling logic to telemetry routed toward different destinations.
Yes. The Memory Limiter processor is designed to prevent Collector crashes under memory pressure by applying backpressure, but if it is not placed first in the pipeline — ahead of batching and especially ahead of tail sampling's span buffering — or if its thresholds do not account for tail sampling's memory requirements, telemetry can be silently dropped precisely during high-load conditions, which is often when the missing data would have been most valuable.
When telemetry volume does not yet justify the operational cost of running a Collector fleet, when the organization lacks the capacity to operate new production infrastructure responsibly, or when a single vendor's native controls already solve the specific problem without requiring a new architectural layer. Most mature architectures use both: Collector-level control over what reaches each backend, and that backend's native controls over what happens after arrival.
Sources
- OpenTelemetry — Collector architecture documentation (receivers, processors, connectors, exporters, agent and gateway deployment patterns).
- OpenTelemetry Collector Contrib — Filter Processor, Tail Sampling Processor and Routing Connector documentation.
- OpenTelemetry Collector — Memory Limiter Processor documentation (backpressure mechanics and recommended pipeline ordering).
- OpenTelemetry — Transforming Telemetry guide (Attributes and Transform processor behavior).
OpenTelemetry Collector components change status and behavior across releases, particularly within collector-contrib. Validate current processor and connector capabilities against official OpenTelemetry documentation for the version deployed.