OpenMetrics, Prometheus, and OpenTelemetry: How They Fit Together

Prometheus is a very well known time-series database, built for monitoring system health. Anyone exposing metrics for Prometheus knows about a /metrics endpoint. But there is a new term coming up in conversations - OpenMetrics.

This led to an internal debate - if Prometheus already exists, why does OpenMetrics exist too? Is OpenMetrics just Prometheus with better branding? Is it a competing project? Is it a file format? Is it a protocol? Are we supposed to support one, both, or something in between.

For a while, it felt like we were doing the right thing without being able to explain why it was the right thing. The answer turned out to be much simpler than it first looked.

Prometheus is the monitoring system. OpenMetrics is the standard for exposing metrics. They feel very similar because OpenMetrics was built from the Prometheus exposition format on purpose.

So if the two names feel suspiciously close, that is because they are close. One is the system and the ecosystem around it. The other is the standard that formalized what that ecosystem had already made popular.

Prometheus came first

Prometheus is not just a text format. It is the full monitoring stack around that format. It scrapes targets over HTTP, stores time series data, lets you query it with PromQL, and powers alerting and dashboards across a huge chunk of the cloud native world. When most engineers say "we use Prometheus", they usually mean that whole model, not only the bytes returned by a /metrics endpoint.

One reason Prometheus spread so well is that the exposition format was simple. You could expose metrics as plain text. Humans could read it. Machines could parse it. Client libraries and exporters did not need to hide everything behind a complicated agent model. That simplicity made the format travel far beyond Prometheus itself.

It showed up in exporters, SDKs, sidecars, managed products, and integrations that wanted to speak the same metrics language. At that point, the format had effectively become bigger than one implementation.

Why OpenMetrics exists

That is where OpenMetrics comes in. Once a format becomes the de facto way a lot of systems expose metrics, people stop treating it like a detail of one project. They start treating it like shared infrastructure. And shared infrastructure needs a cleaner contract.

OpenMetrics is that contract. It takes the ideas that already worked in the Prometheus ecosystem and turns them into a more formal, better specified standard. It is not trying to replace the Prometheus mental model. It is trying to make that model easier for many tools to implement consistently.

That is also why OpenMetrics briefly lived as its own project. It was broken out so the widely used Prometheus exposition format could evolve as a more neutral, shared standard across the CNCF ecosystem, rather than staying only as a Prometheus implementation detail.

Later, that separate project was folded back under the Prometheus umbrella, which is why the story now feels less like two competing projects and more like one ecosystem standardizing itself.

That is the key shift. Prometheus made the format popular. OpenMetrics made it explicit.

How they are similar

They are the same in one very important way. If you already understand Prometheus-style metrics, OpenMetrics will feel familiar almost immediately. You still have metric names, labels, counters, gauges, histograms, and summaries. You still usually expose them over HTTP. That part did not get reinvented.

But they are not the same thing. Prometheus is a monitoring project with a server, a storage layer, a scrape model, PromQL, alerting, exporters, and an ecosystem around it. OpenMetrics is primarily a wire-format specification for how metrics are represented and exchanged.

That means one is a system you run. The other is a contract tools can agree on.

What changes in practice

At the application level, the overlap is real enough that engineers often wonder why the second name exists at all.

If your service exposes metrics like this, most people would casually call it "Prometheus metrics":

# HELP http_requests_total Total HTTP requests.
# TYPE http_requests_total counter
http_requests_total{method="GET",code="200"} 42
http_requests_total{method="POST",code="500"} 3

Now compare that with an OpenMetrics-style exposition:

# HELP http_requests Total HTTP requests.
# TYPE http_requests counter
http_requests_total{method="GET",code="200"} 42
http_requests_created{method="GET",code="200"} 1719981000.0
http_requests_total{method="POST",code="500"} 3
http_requests_created{method="POST",code="500"} 1719981000.0
# EOF

The family resemblance is obvious. That is not a coincidence. OpenMetrics deliberately grew out of the Prometheus text format. It was designed to feel like a natural continuation, not a completely separate system.

The differences live in the contract details, and those details matter more than they first appear to.

OpenMetrics gives the format a formal media type. It has a clearer end marker with # EOF. It is also stricter about the metric shape itself: flat metric names, key-value labels, metadata like # HELP, # TYPE, and # UNIT, and timestamps expressed in Unix epoch seconds.

Exemplars are one good example of why that matters. An exemplar is a small reference attached to a metric sample, often something like a trace ID. It gives you a way to connect a metric point to richer debugging context without turning that high-cardinality value into a normal metric label.

It also defines richer semantics around things like units, creation timestamps, exemplars, and additional metric family types such as info and stateset.

Here is a slightly richer OpenMetrics example:

# HELP http_request_duration_seconds Request latency.
# TYPE http_request_duration_seconds histogram
# UNIT http_request_duration_seconds seconds
http_request_duration_seconds_bucket{method="GET",le="0.1"} 124 # {trace_id="6f3d9c"} 0.08
http_request_duration_seconds_bucket{method="GET",le="0.3"} 482
http_request_duration_seconds_bucket{method="GET",le="+Inf"} 500
http_request_duration_seconds_sum{method="GET"} 61.7
http_request_duration_seconds_count{method="GET"} 500
http_request_duration_seconds_created{method="GET"} 1719981000.0
 
# HELP build Build information.
# TYPE build info
build_info{version="1.8.2",commit="abc123"} 1
# EOF

If you stare at that for a minute, the job of OpenMetrics becomes pretty clear. It is taking the old familiar shape and tightening the edges so producers and consumers do less guessing. That is what standards often look like from the outside.

Why both still exist

Because standards do not erase the system that inspired them.

Prometheus did not become irrelevant the moment OpenMetrics appeared. Prometheus is still the server many teams run. It is still the query engine many teams use. It is still the operational model most engineers recognize first.

At the same time, the ecosystem benefits from having the format itself become a standard instead of a behavior that every other tool has to reverse engineer from Prometheus.

That is why the two names live side by side. Prometheus is still the product and ecosystem and OpenMetrics is the standardized representation.

Prometheus itself can work with both Prometheus text formats and OpenMetrics text formats, which is why both names keep showing up in integrations, docs, and configuration flows.

OpenMetrics vs OpenTelemetry

OpenTelemetry belongs to a different part of the stack again. It is not the monitoring backend in the way Prometheus is, and it is not the wire-level exposition standard in the way OpenMetrics is.

OpenTelemetry is the instrumentation and telemetry pipeline layer. It helps applications produce metrics, logs, and traces in a vendor-neutral way, then send that data onward through SDKs, collectors, and exporters.

That means these three are not enemies:

• Prometheus is the time-series database, monitoring system, and query model many teams use for metrics.
• OpenMetrics is the standardized format for exposing metrics.
• OpenTelemetry is the instrumentation and collection ecosystem that can generate or move telemetry toward systems like Prometheus and others.

In practice, teams often use OpenTelemetry inside the application, Prometheus to scrape or ingest metrics, and OpenMetrics as part of the contract that makes the data understandable across tools. Once you see the layers separately, the names stop sounding like overlap and start sounding like cooperation.

What this means for your integration

The practical question is usually not "which side do we pick".

The practical question is "what does the producer expose, and what does the consumer understand".

If your source already emits OpenMetrics correctly, that is a strong default because you are using the formal standard.

If your source emits classic Prometheus text, that is still perfectly usable in a Prometheus-based pipeline.

If your integration sits in the middle, your job is mostly to preserve the semantics properly. Keep names stable. Keep labels meaningful. Keep units clear. Do not flatten everything into vague counters just because the text looks easy to parse.

For a basic scrape setup, the configuration still looks very familiar:

scrape_configs:
  - job_name: app
    static_configs:
      - targets: ["app:9464"]

That is another reason the confusion happens. The operational flow looks almost the same whether the endpoint is speaking the older Prometheus text format or OpenMetrics text.

The difference is not the existence of scraping. The difference is how formal and expressive the exposed contract is.

Conclusion

Prometheus is the monitoring system, and OpenMetrics is the language for exposing metrics that grew out of that system. Not the only language in the world, and not the whole monitoring stack, but the standard form of an idea that Prometheus made mainstream.

If you ever get stuck, ask two separate questions instead of one: what system is collecting, storing, and querying my metrics, and what format or standard is being used to expose those metrics on the wire. If the first answer is Prometheus and the second answer is OpenMetrics, that is normal. If the second answer is classic Prometheus text, that is also normal.

So why do Prometheus and OpenMetrics exist at the same time. Because they solve different parts of the same problem. Prometheus gave the industry a practical monitoring model that people actually adopted. OpenMetrics took the part of that model that needed to travel between tools and gave it a proper standard.

That is why they feel related. That is why they overlap. And that is why they are better understood as collaborators in the same ecosystem rather than competitors fighting for the same spot.

If you are building an integration today, that is the framing that saves the most confusion.

Prometheus is the system. OpenMetrics is the contract.