What are OpenTelemetry exporters and name common ones?

Think of exporters as shipping carriers for your telemetry data. Your application packages the data (spans, metrics, logs), and the exporter is the carrier (FedEx, UPS, DHL) that delivers it to the destination. Different destinations accept different carriers, but OTLP is like a universal carrier that most modern destinations accept. You can even ship to multiple destinations simultaneously using different carriers for the same package.

Exporters in OpenTelemetry are the final stage of the telemetry pipeline, responsible for serializing and transmitting data to external systems. They exist in two places: within the application SDK and within the OpenTelemetry Collector. SDK exporters are configured in your application code and send data directly to a backend or to a Collector. Collector exporters are configured in the Collector's YAML file and send processed data to one or more backends. In a production setup with payments-api, checkout-service, and order-processing-service, each application typically uses the OTLP exporter to send data to the Collector, and the Collector uses backend-specific exporters to forward data to its final destinations.

The OTLP (OpenTelemetry Protocol) exporter is the recommended default. OTLP is OpenTelemetry's native protocol, supporting traces, metrics, and logs over both gRPC (port 4317) and HTTP/protobuf (port 4318). All major observability backends now support OTLP natively: Grafana Tempo, Jaeger, Datadog, New Relic, Honeycomb, Splunk, and Elastic APM. Using OTLP means you are sending data in OpenTelemetry's own format without any conversion, which preserves all metadata and avoids lossy translations. When inventory-sync sends a span with 20 attributes and 5 events via OTLP, every attribute and event arrives intact at the backend.

Beyond OTLP, several protocol-specific exporters exist for backward compatibility and specific use cases. The Jaeger exporter sends traces in Jaeger's Thrift or gRPC format, useful when migrating from a Jaeger-native setup. The Zipkin exporter sends traces in Zipkin's JSON format. The Prometheus exporter is unique because it does not push data; instead, it exposes a metrics endpoint that Prometheus scrapes at regular intervals. This pull-based model matches how Prometheus fundamentally works. For cloud vendors, there are exporters for AWS X-Ray, Google Cloud Trace, Azure Monitor, Datadog, and New Relic. These vendor exporters handle the format translation and authentication required by each platform.

In production, the choice of exporter is usually made at the Collector level, not in application code. Applications export to the Collector using OTLP, and the Collector handles the fan-out. This pattern is powerful because changing your observability backend requires updating only the Collector configuration, not redeploying every service. Consider a team running user-auth-service and checkout-service that decides to switch from self-hosted Jaeger to Grafana Cloud. With the Collector in place, they change the exporter in the Collector config from Jaeger to OTLP pointing at Grafana Cloud's endpoint, redeploy the Collector, and every service is migrated without touching application code. During migration, they can even export to both backends simultaneously by adding two exporters to the same pipeline, running old and new systems in parallel until validation is complete.