Skip to main content
This article explains common OpenTelemetry Collector (OTel Collector) exporter patterns, diagnostics, and operational best practices to build reliable, maintainable exporter configurations. It covers practical patterns (fan-out, attribute routing, cross-pipeline forwarding), how to diagnose exporter issues, and recommended configuration strategies for production-scale telemetry delivery.

​
Exporter patterns overview

Exporter configurations often follow one of three patterns depending on business needs: duplicating telemetry to multiple backends (fan-out), selecting destination based on attributes (route by attribute), or forwarding telemetry between pipelines for specialized processing (cross-pipeline forwarding).
The image outlines three common exporter patterns: "Fan-Out," "Route by Attribute," and "Cross-Pipeline Forwarding," each with a brief description of their use cases.

​
Pattern details and placement

  • Fan-out: perform duplication early in the pipeline so each downstream exporter receives the original telemetry payload. This preserves data fidelity across backends.
  • Attribute-based routing: use processors such as the routing processor (or exporters that support routing options) to inspect attributes and decide a destination. For traces, prefer routing by trace_id to preserve trace coherence.
  • Cross-pipeline forwarding: useful when a subset of data needs enrichment, normalization, or re-sampling in another pipeline. Forwarding supports intra-Collector flows and inter-Collector networks.

​
Notes on routing and fan-out

  • Implement fan-out early so processors that modify data (e.g., sampling, redaction) do not diverge between targets unless intentionally desired.
  • Routing decisions can be implemented in processors or exporter-level routing. Confirm whether your chosen exporter preserves trace_id when sharding traces.
  • For large-scale or multi-cluster deployments, design forwarding topologies that minimize duplication and control bandwidth — e.g., aggregate at a gateway Collector, then fan-out to long-term storage.

​
Diagnostics and quick fixes

Use a methodical approach to diagnose exporter failures and performance issues:
The image provides quick fixes and diagnostic tips for troubleshooting, including checking startup logs, verifying counters, simulating link outages, and using a small canary pipeline.
When testing resilience, run controlled outages against a canary pipeline first. This reduces risk and gives faster feedback about queued_retry and batch sizing behavior.

​
Best practices and configuration recommendations

  • Default exporter: Prefer OTLP as your primary exporter for portability and standardization. It’s broadly supported by vendors and integrates well with the Collector.
  • Vendor exporters: Use vendor-specific exporters only when they provide clear benefits (delivery guarantees, optimized auth, or performance improvements).
  • Reliability: Always pair exporters with batch and queued_retry processors to smooth bursts and retry transient failures.
  • Fan-out placement: Duplicate telemetry early if you must deliver identical payloads to multiple backends (e.g., a primary analytics backend plus a low-cost archival store).
  • Canary + debug: Maintain a debug exporter in lower environments and validate pipeline changes with a canary pipeline before production rollout.
  • Load distribution: For horizontal scale or tail-based sampling, use the load_balancing exporter to spread traffic across many backends.
  • Cross-pipeline/connectors: For cross-cluster or complex flows, prefer purpose-built connectors or forwarding pipelines designed for multi-cluster reliability.
  • batch: Tune timeout, send_batch_size, and send_batch_max_size to balance latency and throughput.
  • queued_retry: Configure queue_size, retry_on_failure, and timeout values to match backend SLAs.
  • load_balancing exporter: Choose a resolver (see below) and configure consistent hashing where trace-coherence is required.

​
Resolver and routing key selection

Choose resolvers and routing keys based on your deployment topology: If you require that requests for the same routing key always hit the same backend (e.g., stateful aggregation), use consistent hashing and ensure backend identity stability.

​
Backend and timeout considerations

  • Tune queued_retry and other timeouts individually per backend to reflect each destination’s SLA and performance profile.
  • If routing is consistent-hash based, ensure backend Collector identities are stable. In Kubernetes, run backend Collectors as a StatefulSet so their DNS/identity remains stable across restarts and scaling.
  • Consider separate retry/backoff behavior for long-term storage (which may accept larger queues) versus real-time monitoring backends (which require lower latency).

​
Quick reference / checklist

  • Start with OTLP as default exporter.
  • Always use batch + queued_retry.
  • Fan-out early and use attribute routing for selective delivery.
  • Validate changes with a canary pipeline and debug exporter in lower environments.
  • For scale and trace coherence, combine load_balancing with a consistent resolver and stateful backend Collectors.
Wrap-up: Applying these exporter patterns and operational practices will improve the reliability and maintainability of your Collector deployment while preserving trace coherence and enabling scalable delivery to multiple backends.

Watch Video