# Choosing Backends — OpenTelemetry

Source: https://www.skillbyai.com/en/opentelemetry/b-backends

> Open-source and commercial options.

## 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.

![Three ideas: choosing backends, debugging latency, Kubernetes integration.](assets/figures/opentelemetry/section-7-map.svg) — Figure 7.1 — Backends, latency debugging and Kubernetes.

## Sending traces to two backends during a migration

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

```yaml
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.

**Quiz:** Why is switching observability vendors easier with OpenTelemetry?

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

*Answer:* Applications emit OTLP, so only Collector exporter configuration changes. Decoupled instrumentation.