What is the difference between a telemetry processor and a connector in the OpenTelemetry Collector?

What each component does in the Collector

In opentelemetry collector design, the difference is about where the logic sits. A processor modifies telemetry while it is already in a pipeline, so it is best for filtering, sampling, enrichment, batching, or transformation. A connector sits between pipelines and can hand telemetry from one path to another, which makes it useful when data needs to be forwarded, replicated, correlated, or condensed across collection flows.

The practical distinction matters because processors keep work inside a single stream, while connectors create relationships between streams. That means a processor changes the shape or content of records, but a connector changes how pipelines relate to each other. If a team wants to keep one pipeline simple, processors usually stay local; if the design needs fan-out, fan-in, or a derived telemetry path, connectors become the more natural fit.

How to choose between them in practice

The easiest way to decide is to ask whether the change belongs to one pipeline or to the boundary between pipelines. If the answer is “inside,” a processor is the right abstraction. If the answer is “between,” a connector is usually the better fit. That distinction keeps the Collector configuration easier to reason about, because each component has a clearer role in the telemetry flow.

• Use a processor when you want to drop noisy spans, redact fields, enrich records, or adjust telemetry before export.
• Use a connector when one pipeline needs to feed another, such as when data must be routed into a different signal path or aggregated for a second destination.
• Prefer a processor for local record manipulation, and a connector for structural pipeline composition.

This distinction also helps with troubleshooting. When a value disappears or changes unexpectedly, processors are the first place to inspect. When a pipeline starts producing duplicate, missing, or unexpectedly merged telemetry, the connector is often where the behaviour is being introduced. OpenTelemetry’s Collector concepts page is the most direct reference for the component model, while the Collector documentation is the best place to verify current component behaviour and supported patterns.

In practice, these designs break down when teams use connectors as a substitute for clear pipeline boundaries, because that makes telemetry flows harder to follow and debug.

Common variations and edge cases

Tighter Collector design often increases configuration complexity, so teams have to balance simplicity against flexibility. In simple deployments, processors may be enough for most needs, and adding connectors too early can make the data path harder to understand than the observability problem itself. In larger environments, though, connectors become valuable when telemetry must be reused across multiple downstream purposes.

A common edge case is correlation. A processor can annotate records with metadata, but a connector may be needed when the goal is to create a separate derived stream or move telemetry into another pipeline for a different purpose. Another edge case is aggregation, where a connector may condense information before forwarding it, while a processor merely reshapes each item in place.

The best current guidance is to treat processors as in-pipeline mutators and connectors as pipeline-to-pipeline bridges. That mental model scales well, but it becomes less obvious when a deployment chains many components together and the same signal is transformed multiple times. In those environments, documentation discipline matters as much as component choice.

Risk and Threat Considerations

Misusing processors and connectors usually creates operational risk rather than direct security failure, but the consequences can still be material. If teams blur the distinction, they may duplicate telemetry, drop signals before export, or build flows that are difficult to validate during incidents. That weakens confidence in what the Collector is actually observing and forwarding.

Failure mechanism: A processor can remove or alter records before they reach downstream systems, while a connector can re-route or replicate telemetry across pipelines. If either is configured with the wrong scope, the resulting pipeline may hide important events, multiply data unexpectedly, or make root-cause analysis depend on undocumented path logic.

Impact: The practical impact is loss of observability integrity, slower troubleshooting, and higher odds of making decisions from incomplete telemetry. In regulated or high-availability environments, that can also complicate evidence retention and change control because the effective data path is no longer obvious from the configuration alone.

Practitioner Guidance

What to prioritise: Decide first whether the requirement is content transformation or pipeline composition. If the goal is to change records, choose a processor; if the goal is to move or relate streams, choose a connector.

What to verify: Confirm where telemetry changes occur in the chain, then test a sample event end-to-end. The important check is not just whether data arrives, but whether it arrives in the expected shape and at the expected downstream path.

Practitioner takeaway: The most reliable Collector designs keep mutation local and pipeline bridging explicit, because that separation makes observability flows easier to explain, test, and operate.

Related resources from NHI Mgmt Group

• What is the difference between the core OpenTelemetry Collector and the contrib collector?
• What is the difference between Windows Event Forwarding and an OpenTelemetry collector for Windows logs?
• What is the difference between the OpAMP extension and the OpAMP supervisor in OpenTelemetry Collector deployments?
• What is the difference between using an OpenTelemetry collector on the same host and using a gateway pattern?