What Is the OpenTelemetry Collector?

The OpenTelemetry Collector is a standalone service that receives telemetry from applications, processes it, and sends it to one or more backends. In AI engineering, it gives you one place to batch, filter, redact, sample, and route the traces your LLM applications and agents produce.

For example, suppose a Python service exports its traces to a Collector running next to it. The Collector batches the spans, adds a deployment.environment attribute set to production, and forwards them to your tracing backend. The service never holds backend credentials. Switching backends means changing the Collector’s configuration, not redeploying the application.

The Collector handles three kinds of telemetry: traces, metrics, and logs. It is optional. Many teams start without one.

Try Arize AX

Build better agents with Arize

Trace, evaluate, and learn. Build agents that work with Arize AX and start tracing your runs today.

Get started View AX docs

Prefer open source? Try Arize Phoenix for self-hosted, open source agent observability.

Why the OpenTelemetry Collector matters

Without a Collector, every service exports telemetry directly to a backend. Each one needs its own credentials, retry logic, and export configuration.

A Collector moves that work into one shared service. Its value is centralization.

The Collector is useful for:

• Centralizing export: Give many services one destination, so none of them needs backend credentials.
• Processing in one place: Batch, filter, sample, redact, and enrich telemetry with rules you maintain once.
• Changing backends safely: Switch or add a backend without redeploying applications.
• Fanning out: Send the same telemetry to two backends, for example during a migration.
• Protecting sensitive data: Remove or mask fields before telemetry leaves your network.

Where the Collector sits

Telemetry passes through roles that are easy to confuse. It helps to name each one.

Instrumentation creates spans inside your application. This might be an OpenTelemetry software development kit (SDK) or an instrumentation library such as OpenInference for AI applications.

An exporter sends those spans out of the application. It usually uses the OpenTelemetry Protocol (OTLP).

A backend receives, stores, and serves queries over the data. This is where you search and inspect traces.

The Collector sits between the exporter and the backend as an intermediary that you operate. The OpenTelemetry components documentation describes this component model. The signals it carries are described in the OpenTelemetry concepts documentation on traces.

How a Collector pipeline works

A Collector pipeline has three parts. Each part has a single job.

Receivers accept data. Applications usually send data over OTLP, but the Collector also has receivers for other formats such as Jaeger, Zipkin, and Prometheus.

Processors transform data in flight. They batch spans, filter out unwanted data, sample, add attributes, or remove fields.

Exporters send data onward to one or more backends.

A pipeline connects specific receivers to specific processors and exporters. Most configuration errors are a mismatch among those three parts.

A minimal Collector configuration

The following configuration matches the opening example. It accepts OTLP from application SDKs, batches spans, adds a deployment attribute, and forwards traces to a backend. It is illustrative and minimal. Real deployments add authentication, TLS, and resource limits.

# Illustrative Collector pipeline (minimal; real deployments add auth, TLS, and limits)
receivers:
  otlp:                       # accept OTLP from app SDKs
    protocols:
      grpc:
      http:
processors:
  batch:                      # batch spans before export
  attributes:                 # add a deployment attribute
    actions:
      - key: deployment.environment
        value: production
        action: upsert
exporters:
  otlphttp:                   # forward to the tracing backend
    endpoint: https://backend.example.com
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, attributes]
      exporters: [otlphttp]

Here is what each section does:

• receivers: The otlp receiver listens for OTLP data over both gRPC and HTTP.
• processors: The batch processor groups spans before export. The attributes processor sets deployment.environment to production on every span.
• exporters: The otlphttp exporter sends data to the backend endpoint over HTTP.
• service: The traces pipeline wires the receiver, both processors, and the exporter together.

A component defined in the top sections does nothing until a pipeline under service uses it. Forgetting that wiring is a frequent cause of missing data.

Agent and gateway deployments

You can run the Collector in two main shapes. They trade local isolation against central control.

Agent or sidecar: A Collector runs next to each service and handles local batching and buffering. A failure affects only that service.

Gateway: One Collector, or a scaled tier of them, serves many services. This is the natural place for organization-wide sampling or redaction rules.

Gateway deployments centralize policy but concentrate risk. If the gateway is down or misconfigured, every connected service’s telemetry is affected. Treat it with the same care as any shared production service.

Worked example: one Python service

Here is the opening example, traced along its path.

The service only knows the address of its local Collector. It holds no backend credentials.

Suppose you later move to a new backend. You change the exporter’s endpoint in the Collector configuration. The service’s export path stays the same, so it does not need a redeploy.

When you need a Collector and when you do not

You probably do not need a Collector when one or two services export to one backend, volumes are modest, and you need no cross-service processing. Direct export keeps the path short and removes a component to operate.

The Arize Phoenix documentation and Arize AX documentation both describe direct OTLP export from applications. That is the common starting point for LLM tracing.

A Collector earns its place when several of these hold:

• Many services or languages: Several teams export telemetry and need shared rules.
• Redaction before export: Data must be filtered or masked before it leaves your network.
• Central sampling: You need tail-based or organization-wide sampling decisions.
• Fan-out: You send telemetry to two backends, for example during a migration.
• Credential policy: Applications must not hold backend credentials.

In distributed tracing setups that span many services, that central control point is usually worth more than the extra hop costs. For more on removing sensitive fields, see PII redaction.

How to debug the telemetry path

Debug in order along the path: application, then Collector, then backend.

Step 1: Confirm the application is producing spans. A missing instrumentation step produces silence that no Collector setting can fix.

Step 2: Check the receiver. Confirm its protocol and port match what your exporter targets. OTLP over HTTP versus gRPC is a frequent mismatch.

Step 3: Check the pipeline wiring. Confirm the pipeline actually connects that receiver to an exporter.

Step 4: Read the Collector logs. Look for export errors or queue drops.

Step 5: Check the backend. Look for ingestion errors or project and key mismatches.

Finally, review the resulting trace in the backend. This confirms the whole path, including whether processors added or removed what you expected.

Two habits that prevent most incidents

Version and test Collector configuration like application code. A bad processor rule can silently drop or change all telemetry.

Monitor the Collector itself. Watch queue depth, dropped spans, and export latency. Otherwise its failure shows up only as missing data, the exact blind spot AI observability is meant to remove.

Limitations of the OpenTelemetry Collector

A Collector adds a hop, and with it some costs and limits.

• Operational overhead: It adds latency, a deployment to scale and upgrade, and its own failure modes.
• Organization-wide errors: A configuration mistake affects every connected service, not just one.
• No missing spans: It cannot create spans that were never instrumented or repair broken context propagation between services.
• No storage: It stores nothing for later querying. It is a relay and processing hop, not a backend.
• Finite buffering: A long backend outage still loses telemetry once queues fill.
• Central rules fail centrally: A wrongly dropped span attribute can break downstream evaluations that depended on it.

Adopt a Collector when the centralization benefits are real, not by default.

OpenTelemetry Collector vs. SDK vs. backend

The SDK lives in your process. It creates and exports telemetry.

The Collector is a separate process. It relays and processes telemetry.

The backend stores telemetry and serves queries over it.

Saying “we use OpenTelemetry” does not say which of these you have. A complete setup description names all three.

OTLP is the wire protocol, not the Collector. SDKs send OTLP directly to backends every day without any Collector involved.

Frequently asked questions

Do I need the OpenTelemetry Collector to use OpenTelemetry?

No. SDKs can export directly to backends over OTLP. The Collector is an optional intermediary that helps at multi-service scale, or when you need central processing, redaction, or routing.

Is the OpenTelemetry Collector a database or tracing backend?

No. It receives, processes, and forwards telemetry. It does not provide the storage and query interface you use to inspect traces. That is the backend’s role.

Does the Collector create spans?

No. Instrumentation in the application creates spans. The Collector can add or modify attributes on spans in flight, but it cannot recover steps that were never instrumented.

Should I deploy the Collector as an agent or a gateway?

Start with the simpler shape that meets your requirement. An agent or sidecar keeps failures local to one service. A gateway centralizes policy and backend changes, but you must scale and monitor it as shared infrastructure.

Why is my data not reaching the backend through the Collector?

The most common causes are a protocol or port mismatch between exporter and receiver, a component that is defined but not wired into a pipeline, or an export error in the Collector logs. Check the path in order from application to backend.

Putting the OpenTelemetry Collector to work

Start with direct export if you run one or two services. Add a Collector when you need shared processing, redaction, fan-out, or credential isolation.

Keep the Collector configuration in version control and test changes before rollout. Monitor its queue depth, dropped spans, and export latency.

Instrument your AI application with OpenInference, and decide whether spans go straight to the backend or through a Collector. Arize AX and Arize Phoenix both accept OTLP, so the same spans work either way.