Choosing Backends

One protocol, many destinations

Because data arrives over OTLP, you can send it to many systems: Jaeger and Grafana Tempo for traces, Prometheus, Mimir or VictoriaMetrics for metrics (via remote write, OTLP ingestion or scraping a Prometheus exporter), Loki or Elasticsearch/OpenSearch for logs, and many commercial observability platforms that accept OTLP natively. Exporting to two backends at once makes evaluations and migrations low-risk.

Turn telemetry into answers

Exported telemetry becomes useful when backends and good investigation habits turn it into answers.

Sending traces to two backends during a migration

Collector exporters fan out the same pipeline (endpoints illustrative).

exporters:
  otlp/jaeger:
    endpoint: jaeger:4317
    tls:
      insecure: true
  otlphttp/vendor:
    endpoint: https://otlp.vendor.example.com
    headers:
      api-key: ${env:VENDOR_API_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/jaeger, otlphttp/vendor]

Read secrets from the environment

The ${env:NAME} syntax keeps API keys out of configuration files.

Quick check: Why is switching observability vendors easier with OpenTelemetry?

• Applications must be rewritten anyway
• Vendors share one database
• Traces are not stored
• Applications emit OTLP, so only Collector exporter configuration changes