Before learning the details, let us see why people ask this question at all.

Why the confusion happens

Many teams already run Prometheus. It has been the favourite metrics tool for years, especially in Kubernetes. Then they hear about OpenTelemetry, which also deals with metrics. They wonder: “Does OpenTelemetry replace Prometheus? Do I need both? Do I have to rewrite everything?” The honest answer is that they overlap in some areas, but they are built for different jobs, and they were designed to work together.

The core difference in one idea

OpenTelemetry is a standard for producing and moving telemetry, which is information that software sends out about itself. It covers traces, metrics and logs. It does not store or show the data. Prometheus is a system for storing and querying metrics. It does not cover traces or logs. One is mainly the delivery service. The other is mainly the warehouse and the search desk.

First the tool by itself, with no OpenTelemetry in the picture yet.

Prometheus is an open-source monitoring system and a time-series database. It began at SoundCloud in the early 2010s and later became a graduated project of the Cloud Native Computing Foundation, the same neutral foundation that looks after Kubernetes and OpenTelemetry. It has become a standard choice for numeric monitoring and alerting.

The key words, one by one

What Prometheus is not

• It is not a tracing system. It cannot show the journey of one request through many services.
• It is not a log store. It does not keep text messages for searching.
• It is not built for unlimited history on one machine. A single Prometheus server keeps data locally for a limited time, and long-term storage usually needs helper systems.
• It does not like unlimited label values. Too many unique label combinations make it slow and hungry for memory.

The biggest practical difference between the two worlds is how data moves.

Prometheus is famous for the pull model. It reaches out and collects data. OpenTelemetry is mainly built around the push model. Applications and Collectors send data out using the OpenTelemetry Protocol, called OTLP. Neither is right or wrong. They are two ways of moving the same numbers.

sequenceDiagram
    participant P as Prometheus Server
    participant A as Application with metrics endpoint
    participant S as Application with OTel SDK
    participant C as OTel Collector
    P->>A: Scrape request every interval
    A-->>P: Current metric values
    S->>C: Push metrics using OTLP
    C->>P: Remote write or OTLP push
    

There are several bridges between OpenTelemetry and Prometheus. Here they are on one map.

flowchart LR
    subgraph SRC["Sources of metrics"]
        APP1["App with OpenTelemetry SDK"]
        APP2["Legacy app with Prometheus endpoint"]
        INF["Infrastructure exporters"]
    end
    APP1 -->|"OTLP push"| COL["OpenTelemetry Collector"]
    APP2 -->|"Scraped by Prometheus receiver"| COL
    INF -->|"Scraped by Prometheus receiver"| COL
    COL -->|"Remote write"| LTS["Prometheus-compatible long term storage"]
    COL -->|"OTLP push"| PROM["Prometheus server with OTLP receiver"]
    COL -->|"Prometheus exporter endpoint"| PROM2["Prometheus scraping the Collector"]
    PROM --> GR["Dashboards and alerts"]
    LTS --> GR
    PROM2 --> GR
    

The four main bridges

There is also a fifth, smaller bridge on the application side: some OpenTelemetry SDKs offer a Prometheus exporter that exposes a metrics endpoint inside the application, so that a Prometheus server can scrape the app directly. The status of this exporter differs between languages, so check your language’s documentation.

Bringing the old Prometheus world into the OpenTelemetry Collector.

Years of work have gone into small programs called exporters that expose metrics in the Prometheus format. There are exporters for databases, hardware, message queues and operating systems. Thousands of applications also expose a metrics endpoint. Rewriting all of these would be impossible. The Prometheus receiver solves this by letting the Collector behave like a Prometheus scraper. It even understands the same scrape configuration style, including how to discover targets, so teams can often move their existing setup over with little change.

Scaling the receiver with the Target Allocator

A single Collector scraping thousands of targets can become overloaded. If you run several Collector copies, you must make sure each target is scraped by exactly one of them. Otherwise, you get duplicates or gaps. The Target Allocator, part of the OpenTelemetry Operator for Kubernetes, solves this. It discovers targets, splits them fairly between Collector replicas, and hands each replica its own list. It can also read the same Kubernetes resources, called ServiceMonitor and PodMonitor, that many Prometheus users already have.

flowchart TD
    K["Kubernetes API with ServiceMonitors and PodMonitors"] --> TA["Target Allocator"]
    TA -->|"Assigns targets 1 to 100"| C1["Collector replica 1"]
    TA -->|"Assigns targets 101 to 200"| C2["Collector replica 2"]
    TA -->|"Assigns targets 201 to 300"| C3["Collector replica 3"]
    C1 --> T1["Scrape assigned pods"]
    C2 --> T2["Scrape assigned pods"]
    C3 --> T3["Scrape assigned pods"]
    C1 --> OUT["Exporters to storage"]
    C2 --> OUT
    C3 --> OUT
    

Two ways to hand OpenTelemetry metrics to a Prometheus world.

The Prometheus exporter: wait to be scraped

With the Prometheus exporter, the Collector holds the latest metric values in memory and shows them on a web address. A Prometheus server then scrapes that address like any other target. This is simple and fits teams who already use a Prometheus server and want it to stay in charge of collecting.

• Good: very simple, and works with any standard Prometheus setup.
• Watch: only the latest value is held, so the scrape interval decides the resolution. Data can go stale if nothing new arrives.
• Watch: a single Collector copy usually serves this endpoint, which can become a bottleneck for very large volumes.

The remote write exporter: push to storage

Remote write is a protocol that Prometheus created for sending its data to other systems. Many long-term storage and managed services accept it. The remote write exporter in the Collector converts OpenTelemetry metrics into this format and pushes them. This is the usual path for sending data to large, scalable backends.

The newest and simplest road, if your version supports it.

Recent versions of Prometheus can act as a receiver of OTLP metrics. When this feature is switched on, an application or Collector can push OTLP metrics straight to a Prometheus web address, with no remote write conversion needed in between. This removes a step and makes the path much shorter.

The two projects describe metrics in slightly different ways. Translation is where most surprises hide.

Metric types

Temporality: the quiet trap

Temporality describes whether a reported number is a running total since the start, called cumulative, or just the change since the last report, called delta. OpenTelemetry supports both. Prometheus works with cumulative values. If an application sends delta values and nobody converts them, the numbers in Prometheus will make no sense. The Collector can help by converting delta to cumulative before export.

Names and units

OpenTelemetry metric names often use dots, such as http.server.request.duration, and carry a separate unit field. Prometheus traditionally allows only letters, digits, underscores and colons in names, and it has a convention of putting the unit and type into the name itself. So the translation usually changes dots to underscores, adds a unit suffix such as seconds or bytes, and adds a total suffix for counters.

Newer Prometheus versions support a wider range of characters in names, so dots can sometimes be kept, and translation strategies can be chosen. This is helpful, but it means that two teams can end up with different names for the same metric if they choose different strategies. Agree on one approach for the whole company.

Labels, resources and scope

In OpenTelemetry, a measurement has attributes, which become Prometheus labels. The program that produced it is described by resource attributes, such as the service name and instance ID. The library that created the metric is described by the instrumentation scope. Prometheus has no separate place for these, so the translation follows a few conventions.

flowchart TD
    M["OpenTelemetry metric point"] --> A["Attributes"]
    M --> R["Resource attributes"]
    M --> S["Instrumentation scope"]
    A --> L1["Become Prometheus labels"]
    R --> L2["Service name and namespace form the job label"]
    R --> L3["Service instance ID forms the instance label"]
    R --> L4["Other resource attributes go into a target_info metric"]
    S --> L5["Scope name and version become otel_scope labels"]
    

• The service name, with the namespace if present, becomes the job label.
• The service instance ID becomes the instance label.
• The remaining resource attributes are stored in a separate metric called target_info, which you can join with your other metrics in queries. Many setups also promote a few chosen resource attributes, such as the environment or cluster, directly into labels so queries are easier.
• The instrumentation scope often appears as labels such as otel_scope_name.

Follow one number from your code to a dashboard.

Exemplars: a link from numbers to traces

Prometheus can store exemplars, which are sample values with a trace ID attached. OpenTelemetry metrics can carry exemplars too. When this link is kept through the pipeline, an engineer who sees a spike on a graph can click a dot and jump straight to an example slow trace. This ties together Prometheus for metrics and a tracing system for traces, and shows why the two work well together.

Which bridge should you use? It depends on where you are starting.

flowchart TD
    Q["Where are you starting?"] --> A{"Do you already have Prometheus exporters and endpoints?"}
    A -->|Yes| B["Use the Prometheus receiver in the Collector, with Target Allocator on Kubernetes"]
    A -->|No| C{"Are your apps instrumented with OpenTelemetry SDKs?"}
    C -->|Yes| D{"Do you need long term storage or a managed service?"}
    D -->|Yes| E["Collector with remote write exporter"]
    D -->|No| F{"Does your Prometheus version support OTLP ingestion?"}
    F -->|Yes| G["Push OTLP directly to Prometheus"]
    F -->|No| H["Use the Prometheus exporter and let Prometheus scrape the Collector"]
    C -->|No| I["Start with auto-instrumentation and then pick a path above"]
    

An honest look at combining the two.

Key trade-offs

Metrics endpoints and ingestion paths are doors into your systems. Treat them that way.

The pipeline that carries your metrics should itself be watched.

• Target health: the scrape health of every target. Prometheus-style scraping records whether a target answered, which is the first thing to check when data goes missing.
• Scrape duration and failures: slow or failing scrapes may mean overloaded targets or a busy Collector.
• Collector send failures: watch the counts of failed and dropped metric points from the exporters, and the size of their queues.
• Remote write lag: if data arrives in storage minutes late, queues may be full or the destination may be slow.
• Series count and growth: a sudden jump in the number of series is the classic warning of a cardinality problem.
• Target Allocator balance: check that targets are spread fairly and that none are left unassigned.
• Duplicate data: look for the same series arriving from two sources, which suggests double scraping.
• Collector resources: memory and CPU, especially when scraping many targets.

Common symptoms and likely causes

Habits worth copying and traps worth avoiding.

Good design patterns

Anti-patterns

A practical checklist for a healthy setup.

Best practices

• Understand the translation. Learn how names, types, labels and resources are converted, before building dashboards.
• Prefer cumulative temporality for Prometheus. Convert delta values where needed.
• Keep label values bounded. Review every new label for how many distinct values it can take.
• Set a clear service name and instance ID. They become the job and instance labels that every query relies on.
• Use the Target Allocator when scaling scraping. Avoid duplicates and gaps.
• Use batching, queues and retries on remote write. Protect data during short outages.
• Secure every endpoint. Encrypt, authenticate and restrict networks for scraping and ingestion.
• Monitor the pipeline. Watch scrape health, send failures, queue sizes and series growth.
• Migrate gradually. Run old and new paths side by side and compare before cutting over.
• Check version notes. Native OTLP ingestion, name handling and histograms have been changing, so confirm behaviour for your versions.

Common mistakes beginners make

• Thinking OpenTelemetry replaces Prometheus, or the reverse. They do different jobs and often cooperate.
• Expecting metric names to look the same on both sides.
• Forgetting that Prometheus handles only metrics, not traces or logs.
• Ignoring temporality and getting strange counters.
• Scraping the same targets from several places.
• Letting high-cardinality attributes become labels.
• Leaving metrics endpoints open to the public internet.

How the two projects appear together in tools and platforms you may already know.

A typical journey for a growing company

Quick answers to questions beginners ask most.

If you remember only a few things, remember these.