Telemtra
Sign in Start free
/blog/prometheus-grafana-opentelemetry
4 architectures
free plan / 1 gb-mo
telemtra.io
// stack architecture

Prometheus, Grafana, and OpenTelemetry:
how they fit together.

The three names get used interchangeably in the same conversation, but they do different jobs. Here's what each actually does, the four architectures teams run in 2026, and the migration decisions in between.

> Start free ~ Browse blog

Walk into any observability discussion and the three names come up together: Prometheus, Grafana, OpenTelemetry. Sometimes as alternatives, sometimes as a stack, sometimes as steps in a migration. The confusion is fair. The names blur in marketing copy but the tools do genuinely different things. This post unpacks them and shows the four architectures most teams actually run.

What each one actually is

One sentence each, sharper than the marketing pages:

  • Prometheus is a metrics database that pulls (scrapes) metrics from HTTP endpoints, stores them as time series, and has its own alerting and query language (PromQL). It is not a dashboard, not a tracing system, not a log store.
  • Grafana is a dashboard UI that reads from many backends (Prometheus, Loki, Tempo, Mimir, ClickHouse, Postgres, OpenSearch) and renders them on shared dashboards. It is not a database; it stores no telemetry of its own.
  • OpenTelemetry is a standard: SDKs for applications, a Collector binary for pipelines, and OTLP for the wire format. It is not a backend; data goes through it to somewhere else.

So the literal question "Prometheus vs OpenTelemetry?" is malformed. OpenTelemetry can feed Prometheus, can replace the Prometheus scrape model, or can bypass Prometheus entirely, depending on the architecture you choose.

The four architectures, in increasing OTel content

1. Pure Prometheus + Grafana (no OTel)

The original CNCF stack. Prometheus scrapes /metrics endpoints, stores time series. Grafana reads from Prometheus and renders dashboards. Alertmanager handles paging.

apps (export /metrics)  →  Prometheus  →  Grafana
                                       →  Alertmanager

When this is right: metrics-only observability, mature Prometheus operators on the team, infrastructure-heavy workloads where the pull model is a natural fit. No traces, no logs at the platform level.

When it breaks down: the moment you need traces or structured logs at scale. Prometheus has no story for either; you bolt on Jaeger/Tempo and Loki/Elastic, and now you have three storage systems with three operational models. The complexity ramp is steep.

2. Prometheus + Grafana, plus OTel for traces and logs

Most teams' first OTel deployment. Prometheus keeps doing metrics. Applications add OTel SDK for traces, exporting OTLP to Tempo (or Jaeger, or a SaaS backend). Logs go to Loki via Promtail or Vector. Grafana stitches the three together with linked correlations.

apps (export /metrics)  →  Prometheus  →  ┐
apps (OTel SDK traces)  →  Tempo       →  ├→  Grafana
apps (write logs)       →  Loki        →  ┘

When this is right: teams adding traces to an existing Prometheus deployment without disrupting it. The OTel layer is additive; nothing about the metrics pipeline changes.

When it breaks down: three storage systems, three query languages (PromQL, TraceQL, LogQL), three operational concerns. The Grafana UI papers over the gaps but the engineering team still owns three things.

3. OTel Collector as the universal pipeline

The Collector becomes the single ingestion plane. It scrapes Prometheus targets (via the prometheus receiver), receives OTLP from applications, processes everything (batching, filtering, sampling), and exports each signal to its appropriate backend.

Prometheus /metrics targets ┐
apps (OTel SDK)            ─┼→ OTel Collector → ┬→ Prometheus / Mimir
apps (filelog)             ┘                   ├→ Tempo
                                               └→ Loki / OTLP log backend

The exporters look like this:

exporters:
  prometheusremotewrite:
    endpoint: http://mimir:9009/api/v1/push
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

When this is right: consolidating three ingestion pipelines (node_exporter scraping, Promtail, in-app tracers) into one Collector pipeline. The Collector becomes the place where filtering, sampling, and attribute enrichment happen.

When it breaks down: you still operate three storage systems. The Collector reduced the agent footprint but not the backend footprint.

4. Pure OTel + OTel-native backend

The Collector receives everything (scraped Prometheus, OTLP from apps, log files, host metrics) and exports OTLP to a single OTel-native backend. The backend stores traces, metrics, and logs in one place. Dashboarding happens in the backend's UI or Grafana querying it.

Prometheus targets ┐
apps (OTel SDK)    ┼→ OTel Collector → OTLP → OTel-native backend
filelog            ┘                              (UI included)

OTel-native backends in 2026 include Telemtra, SigNoz, Honeycomb (events-first), and Grafana Cloud (when configured for OTel ingest into Mimir/Tempo/Loki rather than the native Prometheus/Loki stack). For a deeper look at that last option, see OpenTelemetry-native backends vs Grafana Cloud.

When this is right: you're starting fresh, or willing to migrate. The operational simplification is real: one storage system, one set of upgrade cycles, one backup story. Pricing is usually flatter.

When it breaks down: you have existing PromQL dashboards or alert rules. Migrating PromQL queries to whatever the backend offers is real work. Most OTel-native backends try to be PromQL-compatible but the corner cases bite.

Quick architecture picker

If you scrolled here first:

  • You have Prometheus + Grafana, no traces yet → Add OTel for traces and logs (Architecture 2). Don't touch the metrics pipeline.
  • You have all three already and want fewer agents → Move to Architecture 3 (Collector as the universal pipeline).
  • You're hitting the operational tax of three storage systems → Consider Architecture 4 (pure OTel-native backend). Plan the PromQL migration carefully.
  • You're starting fresh, no existing Prometheus investment → Architecture 4 directly. Skip the Prometheus step.
  • Your team has deep Prometheus and PromQL expertise → Architecture 3. Keep what your team is good at.

Where each tool stays even after OTel adoption

None of this means Prometheus or Grafana goes away. The patterns we see most often:

  • Prometheus stays in teams that have deep Kubernetes Prometheus Operator deployments. Even when application telemetry shifts to OTel, the kube-state-metrics and node-exporter scraping pattern stays. The Collector ingests it alongside OTLP.
  • Grafana almost always stays. It's the most popular dashboarding UI in observability, and most OTel-native backends either embed Grafana or can be queried by it. Grafana is the most portable piece of the stack.
  • What gets replaced is usually Promtail/Vector (replaced by Collector filelog receiver), Jaeger (replaced by an OTel-native trace store), and per-language tracer libraries (replaced by OTel SDKs).

One specific PromQL/OTel gotcha

OpenTelemetry and Prometheus disagree on metric naming. Prometheus uses underscored snake case with unit suffix (http_server_request_duration_seconds). OpenTelemetry uses dotted semantic-convention naming (http.server.request.duration with unit s as a separate field). The Collector normalises in one direction or the other: either by converting OTel names to Prometheus convention via prometheusremotewrite, or by preserving OTel naming end-to-end.

Be deliberate about which convention is canonical in your stack. Dashboards and alerts will reference one or the other; mixing both in the same Grafana folder is a recipe for confusion. We've seen teams spend more time on this normalisation than on the receiver setup, so it's worth doing once, intentionally.

Frequently asked questions

Is OpenTelemetry a replacement for Prometheus?

Not directly. OpenTelemetry is a standard for producing and shipping telemetry (SDKs, Collector, OTLP); Prometheus is a metrics database. OTel can feed Prometheus, replace its scrape model with push, or bypass it entirely by sending OTLP to a different backend — it depends on which of the four architectures above you run.

Does Grafana work with OpenTelemetry?

Yes. Grafana is a dashboard layer that reads from many backends, so OTel data reaches it through whichever storage you export to — Mimir, Tempo, and Loki in the Grafana stack, or any OTel-native backend that exposes a Grafana data source.

Do I still need Prometheus if I use OpenTelemetry?

Only if you want its storage and PromQL ecosystem. The Collector's prometheus receiver scrapes existing /metrics endpoints, so you can keep exposition-format instrumentation while consolidating storage in an OTLP backend.

Further reading

See OpenTelemetry vs Prometheus for the standards-level view, the Collector quickstart for a working pipeline, OpenTelemetry metrics in production for the instrumentation side, and server monitoring with OpenTelemetry for the contrib-receiver tour. Start a Telemtra workspace if you want to trial the pure-OTel path on real telemetry.