Explains OpenTelemetry Collector exporters, their roles delivering telemetry to backends, configuration examples, fan-out, resilience patterns, processors, and best practices for reliability and security.
This lesson dives into exporters in the OpenTelemetry Collector — the components that send processed telemetry (traces, metrics, logs) from the Collector to one or more external destinations (APMs, metrics stores, log storage, or other systems).All telemetry flows into the Collector from applications, services, and systems. Exporters are responsible for delivering that telemetry to its final destination while preserving correct formatting and compatibility with the backend. Exporters can also fan out the same telemetry to multiple backends in parallel.Key exporter responsibilities:
Efficient delivery of telemetry.
Correct formatting and backend compatibility.
Integration with processors and pipelines to support resilience and observability.
Table: Exporter role and examples
Responsibility
Why it matters
Example
Delivery
Ensures telemetry reaches backends with low overhead
OTLP exporter to APM
Compatibility
Formats data to match backend expectations
Logging exporter for debugging
Fan-out
Send same telemetry to multiple systems in parallel
One pipeline → OTLP + logging
Observability
Monitor exporter performance to detect failures
Use logging exporter to inspect payloads
When an exporter name contains special characters (for example, a slash /), wrap the name in quotes in YAML (for example: "otlp/primary") to avoid YAML parsing issues.
receivers accepts telemetry; here the otlp receiver accepts traces, metrics, and logs via gRPC and HTTP.
exporters defines endpoints and exporter-specific settings (TLS, headers, compression).
service.pipelines.traces connects receivers -> processors -> exporters. Listing multiple exporters enables fan-out: the same trace data will be delivered to "otlp/primary" and logging.
Exporters focus on delivering data; end-to-end resilience is typically implemented with processors placed in the pipeline before exporters. Common processors and patterns:
Processor / Pattern
Purpose
batch
Amortizes network cost and improves throughput
queued/retry
Provides buffering and retry semantics during backend failures
memory_limiter
Prevents Collector from OOM during telemetry spikes
retry_on_failure
Ensures transient delivery failures are retried
The batch processor in the example reduces overhead and increases throughput. For stronger guarantees (queueing, retries, backpressure protection), add appropriate processors prior to exporters.
Keep exporter endpoints and credentials secure. Many exporters support TLS, authentication headers, and other security settings—configure them to avoid leaking sensitive telemetry or credentials.
Multiple exporters: Define exporters for different destinations (cloud APMs, logging systems, metrics backends) and reference combinations of them from pipelines to enable fan-out.
Observability: Monitor exporter performance (latencies, errors). Use logging exporter or a debug-level exporter during troubleshooting to inspect payloads.
Security: Store and reference credentials securely (secrets management). Enable TLS and validate certificates for production backends.
Performance: Tune processors like batch and queued_retry to match backend throughput and network characteristics.
Transform, batch, queue, throttle, or retry telemetry
Exporter
Deliver telemetry to external backends
Service pipeline
Wires receivers → processors → exporters together
Exporters are a core piece of Collector configuration. They define where your telemetry ends up and, together with processors, determine how reliably and efficiently it gets there.
