Grafana Cloud with
OpenTelemetry.

We make Telemtra, an OpenTelemetry-native backend. So our framing here has an obvious bias, and the honest version of this comparison is that Grafana Cloud is a strong product solving a slightly different shape of problem. Both accept OTLP. Both compete for the team that's instrumenting with OpenTelemetry and shopping a hosted backend. If you came here to get data flowing into Grafana Cloud, the next section is the working config; the rest of the post is the architectural choice you're making when you use it.

Sending OpenTelemetry data to Grafana Cloud

Every Grafana Cloud stack exposes an OTLP gateway that fans your data out to the right store — metrics to Mimir, logs to Loki, traces to Tempo (the "LGTM" stack: Loki, Grafana, Tempo, Mimir). Three things to collect from the Grafana Cloud portal under Connections → OpenTelemetry:

• The OTLP endpoint — https://otlp-gateway-<zone>.grafana.net/otlp, where the zone matches your stack's region (e.g. prod-eu-west-2).
• Your instance ID — a numeric stack identifier, used as the basic-auth username.
• A Cloud Access Policy token with write scopes for metrics, logs, and traces — the basic-auth password.

With those, a minimal OpenTelemetry Collector pipeline looks like this:

extensions:
  basicauth/grafana_cloud:
    client_auth:
      username: "<your instance ID>"
      password: ${env:GRAFANA_CLOUD_TOKEN}

exporters:
  otlphttp/grafana_cloud:
    endpoint: https://otlp-gateway-<zone>.grafana.net/otlp
    auth:
      authenticator: basicauth/grafana_cloud

service:
  extensions: [basicauth/grafana_cloud]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/grafana_cloud]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/grafana_cloud]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/grafana_cloud]

Three practical notes. First, the gateway speaks OTLP over HTTP (protobuf) — use otlphttp, not the gRPC otlp exporter; see OTLP: HTTP vs gRPC for why that distinction matters. Second, you don't need a collector at all for a first test — every OTel SDK can export OTLP directly to the gateway with the same endpoint and an Authorization: Basic header — but you'll want one in production for batching, retry, and enrichment. Third, Grafana Alloy (Grafana's distribution of the OTel Collector, successor to Grafana Agent) accepts the same OTLP inputs; it's convenient if you're all-in on Grafana, while the upstream Collector keeps the config portable to any OTLP backend — which is exactly what makes the rest of this post a live question.

The shape difference

Grafana Cloud is the managed version of the open-source Grafana observability stack. Under one Grafana UI sit three independent storage systems: Mimir (Prometheus-compatible metrics), Loki (logs), Tempo (traces), plus the dashboarding layer. OTLP-in is supported on all three; they accept OTel-instrumented apps as a first-class citizen alongside Prometheus scrape and Promtail.

An OTel-native backend (Telemtra, SigNoz, Honeycomb, each in different ways) collapses that into a single storage engine for all three signals. One query model. One retention policy. One backup target. One bill line. The trade-off is that you no longer have three best-in-class single-purpose engines; you have one engine doing all three jobs.

OpenTelemetry vs Tempo, Loki, Mimir: not actually a versus

A quick disambiguation, because these searches land here: OpenTelemetry doesn't compete with any individual Grafana store. They sit at different layers of the stack.

• OpenTelemetry vs Tempo: OTel produces and ships traces; Tempo stores them. Tempo is one possible destination for OTel trace data — the alternatives are Jaeger, an OTel-native SaaS backend, or any OTLP endpoint. The real comparison is Tempo vs other trace stores, and it turns on TraceQL (Tempo's query language) versus whatever the alternative offers.
• OpenTelemetry vs Loki: same layering. The OTel Collector's filelog receiver plus OTLP export replaces Promtail as the shipper; Loki remains one possible log store. If you adopt OTel logs end-to-end, the question becomes whether you still want a separate log store at all — that's the single-store vs three-store decision this post is about.
• OpenTelemetry vs Telegraf: the closest thing to a real versus in this list, because both are collection agents. Telegraf collects metrics for the InfluxDB ecosystem; the OTel Collector collects all three signals for any OTLP backend. If you're standardising on OpenTelemetry, the Collector's contrib receivers cover most of Telegraf's input plugins.

So if you searched "OpenTelemetry vs Tempo" the honest answer is: you'll likely use OTel either way, and the decision is which storage architecture receives the data. That's the rest of this post.

Where Grafana Cloud's three-store model wins

• Existing PromQL investment. If your team already writes PromQL and has dashboards full of it, Mimir keeps that working unchanged. Migrating PromQL to a non-Prometheus query language is real work; staying inside the Prometheus query ecosystem avoids it.
• You want the OSS escape hatch. Mimir, Loki, Tempo, and Grafana are all Apache 2.0 open source. You can self-host the same components Grafana Cloud runs as a managed service. Migration to self-hosted is a configuration change, not a re-instrumentation.
• Grafana the dashboarding tool. Grafana is the most popular observability dashboard in the world. The library of community dashboards, panel types, and alerting integrations is bigger than any vendor-specific equivalent. If you live in Grafana already, Grafana Cloud puts the backend behind the UI you know.
• You want each store optimised for its signal. Tempo is built specifically for traces; Loki specifically for logs; Mimir specifically for metrics. Each can be operated and tuned independently. An OTel-native single store has to be reasonable at all three.
• Generous free tier. 10k metric series, 50GB logs, 50GB traces, 14-day retention. Grafana Cloud's free tier covers a small production deployment indefinitely. Most OTel-native vendors have meaningful free tiers but the limits vary.

Where a single OTel-native backend wins

• Fewer moving parts on the bill. One ingest meter, one storage meter, one retention setting. Grafana Cloud's three-store model means three sets of cost levers; you can save money by tuning each, or accidentally overspend on one while underusing the others.
• One query model end-to-end. Grafana Cloud means PromQL for metrics, LogQL for logs, TraceQL for traces. Three syntaxes, three mental models, three sets of operator quirks. An OTel-native backend usually offers one query language across all three signals.
• OTel semantic conventions preserved. Mimir/Loki/Tempo all came from a Prometheus-first lineage and translate OTel's service.name / http.request.method / etc. into their respective conventions. Sometimes the translation is lossless, sometimes attributes land under unexpected names. OTel-native backends keep OTel naming end-to-end.
• Less operational burden if you ever self-host the backend. Grafana Cloud is a managed offering; if you outgrow it and self-host, you're suddenly running three independent storage systems. Self-hosting an OTel-native backend means one.
• Faster decisions on trace-log-metric correlation. When the three signals live in one store, correlation is a join inside the engine. When they live in three stores, correlation is a UI-level federation across data sources. The federated model works but adds latency and edge cases.

Pricing shape, not pricing math

Specific numbers move; the pricing shape is the durable thing.

Grafana Cloud is per-signal: $X per metric series per month, $Y per GB of logs ingested + indexed, $Z per GB of traces ingested. Optimisation work is per-store: dropping metric cardinality reduces the Mimir bill; sampling traces reduces the Tempo bill; dropping log noise reduces the Loki bill. Each lever is independent. Some teams find this granular and welcome it; others find it three places to track instead of one.

OTel-native backends (Telemtra included) usually charge per workspace tier and per GB ingested across all signals. Optimisation is one lever: reduce ingest. Simpler to reason about, less granular control. Some teams find this less expressive; others find it less to think about.

Both shapes can be cheap or expensive depending on usage; neither is universally lower-cost than the other. The decision is about which shape you'd rather operate against.

A decision shortcut

• You already write PromQL or have a Grafana investment → Grafana Cloud. Path of least resistance.
• You want one query language, one bill, one mental model → OTel-native backend (Telemtra, SigNoz, Honeycomb).
• You want the OSS escape hatch → Grafana Cloud. Mimir/Loki/Tempo/Grafana all run yourself if you want.
• You're instrumenting with OTel and want the data model preserved end-to-end without Prometheus translation → OTel-native backend.
• You need 100+ best-in-class community dashboards day one → Grafana Cloud.
• You want trace-log-metric correlation to be a database join rather than a UI federation → OTel-native backend.

What this comparison doesn't help with

If your decision is "do I switch off Datadog", neither of these answers it directly. See Datadog alternatives in 2026 for the broader vendor landscape. Grafana Cloud and OTel-native backends are both on that list, but the comparison includes other shapes (events-first like Honeycomb, self-hosted DIY like Prometheus + Tempo + Loki, lower-cost commercial like Better Stack) that deserve consideration too.

A trial pattern that doesn't pick winners early

If you're genuinely evaluating, the OTel Collector's multi-exporter pattern lets you fan out to both backends in parallel for a billing cycle:

exporters:
  otlphttp/grafana_cloud:
    endpoint: https://otlp-gateway-prod-us-central-0.grafana.net/otlp
    auth:
      authenticator: basicauth/grafana
  otlphttp/telemtra:
    endpoint: https://ingest.telemtra.io
    headers:
      x-api-key: ${env:TELEMTRA_API_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/grafana_cloud, otlphttp/telemtra]

Cost goes up by the second vendor's per-GB rate for the trial month. What you get in return: empirical numbers on which UI your team actually opens, which queries run faster, which pricing shape matches your workload. Decision becomes obvious instead of theoretical.

Frequently asked questions

What is the Grafana Cloud OTLP endpoint?

https://otlp-gateway-<zone>.grafana.net/otlp — zone and instance ID are shown under Connections → OpenTelemetry in the portal. Auth is HTTP basic: instance ID as username, a Cloud Access Policy token as password. Full collector config in the setup section above.

Do I need the OTel Collector or Grafana Alloy to use Grafana Cloud?

Neither is required — SDKs can export straight to the gateway — but run one in production for batching and retry. Alloy is Grafana's collector distribution; the upstream OTel Collector does the same job and keeps your pipeline portable to any OTLP backend.

Is Grafana Cloud compatible with OpenTelemetry?

Yes — OTLP-in is first-class. Each signal routes to its own store (Mimir, Loki, Tempo), with OTel semantic conventions translated into each store's native naming on the way in. Usually lossless, occasionally surprising; see the shape difference section above.

What's the difference between OpenTelemetry and Tempo or Loki?

Different layers: OTel is the instrumentation and transport standard, Tempo and Loki are storage backends that consume its data. There's no either/or — the choice is which storage architecture sits behind your OTel pipeline.

Can I keep Grafana dashboards with an OTel-native backend?

Usually yes. Grafana reads from many backends via data sources, and most OTel-native vendors expose one — you keep the dashboard layer and swap the storage underneath.

Further reading

See Prometheus, Grafana, and OpenTelemetry for the architectures behind both choices, Datadog alternatives in 2026 for the broader vendor map, and OpenTelemetry vs Prometheus for the standards-level view. Start a Telemtra workspace if you want to point an OTLP exporter at an OTel-native backend for a side-by-side trial.