Skip to main content
Exporters are responsible for sending telemetry data (traces, metrics, and logs) from your application to observability backends. OpenTelemetry Rust provides several exporters to integrate with different monitoring platforms.

​
Available Exporters

​
OTLP Exporter

The OpenTelemetry Protocol (OTLP) exporter is the recommended choice for most use cases. It supports all three telemetry signals (traces, metrics, and logs) and can send data to:
  • OpenTelemetry Collector
  • Any OTLP-compatible backend (Jaeger, Prometheus, Grafana, etc.)
  • Commercial observability platforms
Protocols supported:
  • gRPC (port 4317)
  • HTTP with binary protobuf (port 4318)
  • HTTP with JSON
Learn more about OTLP →

​
Stdout Exporter

The stdout exporter prints telemetry data to standard output. It’s useful for:
  • Local development and debugging
  • Understanding the structure of telemetry data
  • Educational purposes and testing
Signals supported: Traces, metrics, and logs
The stdout exporter is not optimized for production use and should only be used for development and debugging.
Learn more about stdout →

​
Zipkin Exporter

The Zipkin exporter sends trace data to Zipkin, a popular distributed tracing system. Use this when:
  • You have an existing Zipkin infrastructure
  • You need compatibility with Zipkin’s data format
  • You’re migrating from Zipkin to OpenTelemetry
Signals supported: Traces only Learn more about Zipkin →

​
Prometheus Exporter

The Prometheus exporter has been discontinued as of version 0.29. It depends on an unmaintained protobuf crate with security vulnerabilities.
For Prometheus integration, use the OTLP exporter instead. Prometheus natively supports OTLP, providing a more stable and actively maintained solution. Learn more about Prometheus integration →

​
Choosing an Exporter

​
For Production Use

Use OTLP for production workloads. It’s:
  • Actively maintained and part of the OpenTelemetry specification
  • Supports all telemetry signals
  • Compatible with most observability backends
  • Optimized for performance with batching and compression

​
For Development

Use stdout for local development when you want to:
  • Debug telemetry data structure
  • Verify instrumentation without a backend
  • Learn how OpenTelemetry works

​
For Legacy Integration

Use Zipkin if you:
  • Have existing Zipkin infrastructure
  • Need to maintain compatibility with Zipkin clients
  • Are gradually migrating to OpenTelemetry

​
Common Configuration

All exporters share common configuration patterns:

​
Resource Configuration

Define service information that applies to all telemetry: 
use opentelemetry_sdk::Resource;

let resource = Resource::builder()
    .with_service_name("my-service")
    .with_service_version("1.0.0")
    .build();

​
Batch vs Simple Export

Batch export (recommended for production):
  • Exports telemetry in batches for better performance
  • Configurable batch size and timeout
  • Reduces network overhead
let provider = SdkTracerProvider::builder()
    .with_batch_exporter(exporter)
    .build();
Simple export (for development/testing):
  • Exports each span immediately when it ends
  • Simpler but less performant
let provider = SdkTracerProvider::builder()
    .with_simple_exporter(exporter)
    .build();

​
Shutdown

Always shutdown providers to ensure all telemetry is exported: 
tracer_provider.shutdown()?;
meter_provider.shutdown()?;
logger_provider.shutdown()?;

​
Next Steps

OTLP Exporter

Production-ready exporter for all telemetry signals

Stdout Exporter

Debug telemetry data during development

Zipkin Exporter

Send traces to Zipkin backends

Prometheus Integration

Export metrics to Prometheus via OTLP

Build docs developers (and LLMs) love

Get started for freeTalk to us