Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
83 changes: 83 additions & 0 deletions _posts/2025-10-21-micrometer-prometheus-v1.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
---
layout: post
title: 'Quarkus Micrometer using Prometheus client v1'
date: 2025-06-12
tags: micrometer prometheus
synopsis: Micrometer has moved to use the Prometheus client v1. This post explains the migration path and required changes for applications.
author: brunobat
---

== Quarkus Micrometer using Prometheus client v1

Micrometer adopted Prometheus Client v1.x starting with version 1.13. However, Quarkus still uses Prometheus Client v0.x by default through the `quarkus-micrometer-registry-prometheus` extension which has been using the legacy `io.prometheus:simpleclient`.
This is now considered *deprecated* and will not be part of a future Quarkus 4.x version (still no timeline).

In parallel, we have introduced a new extension in Quarkiverse: https://docs.quarkiverse.io/quarkus-micrometer-registry/dev/micrometer-registry-prometheus-v1.html[`quarkus-micrometer-registry-prometheus-v1`], which integrates the new v1.x client.

[INFO]
====
Users should move to the new `quarkus-micrometer-registry-prometheus-v1` extension.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hold on, does this change the metrics? If so, sure they should move but be aware that they dashboards and alerts and queries are now incorrect

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of info it should be inclined, in the flow of the required changes. We should invite the users to check the breaking change section before making a decision.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, I can tone down the message, but they should work one migration, regardless. Will update.

====

Since the new client introduces *breaking changes*, we’ve prepared a migration plan designed to reduce the impact on existing users.

=== Migration plan

1. Keep current extension as is until Quarkus 4.0 (whenever that happens) so users can migrate at a time of their choice.
2. Introduce a new extension called https://docs.quarkiverse.io/quarkus-micrometer-registry/dev/micrometer-registry-prometheus-v1.html[`quarkus-micrometer-registry-prometheus-v1`].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if you use both at the same time? What happens?

Copy link
Contributor Author

@brunobat brunobat Oct 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory they could work at the same time but they will clash for sure because they will both try to publish the /q/metrics endpoint.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will test what happens.

3. Remove current `quarkus-micrometer-registry-prometheus` on Quarkus 4.0 (no timeline at this moment) while providing an alternative on Quarkiverse. Quarkus users will get an additional migration period by using an upcoming community supported Quarkiverse extension.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That list looks like implementation tasks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are, we are explaining what we are going to do next.

4. Refactor code on Quarkus 4.0 Core:
** Move the deprecated `quarkus-micrometer-registry-prometheus` extension from Quarkus core repo to Quarkiverse.
** Move the new https://docs.quarkiverse.io/quarkus-micrometer-registry/dev/micrometer-registry-prometheus-v1.html[`quarkus-micrometer-registry-prometheus-v1`] extension from Quarkiverse to Quarkus core repo and make it the default registry.
** Refactor the https://quarkus.io/guides/telemetry-micrometer[`quarkus-micrometer`] extension tests to use the new client.

=== Prometheus Client v1.x changes
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename it to "breaking changes"


The `quarkus-micrometer-registry-prometheus-v1` extension will be using the Prometheus Client v1.x and includes *breaking changes* expressed in detail on the https://github.com/micrometer-metrics/micrometer/wiki/1.13-Migration-Guide[Micrometer 1.13 Migration Guide], featuring package, API and semantic convention changes.

These are the main points to consider when migrating to the new Quarkus extension:

* Counters now use Longs instead of Doubles.
** Before: `"registry=\"prometheus\",status=\"200\",uri=\"/example/prime/{number}\"} 2.0`
** Now: `"registry=\"prometheus\",status=\"200\",uri=\"/example/prime/{number}\"} 2`
* `io.micrometer.prometheusmetrics.PrometheusMeterRegistry` must be used instead of the old `io.micrometer.prometheus.PrometheusMeterRegistry`.
* `io.prometheus.metrics.tracer.common.SpanContext` must be used instead of the old `io.prometheus.client.exemplars.ExemplarSampler`
* The new Prometheus client uses some reserved words that must not be used to name metrics, therefore some metrics were renamed. Some examples of reserved words and renamed metrics:
** `info`. Before: `jvm_info_total`. Now: `jvm_total`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have the list?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a list.
I would need to activate all metrics in a big nr of extensions to get that. It can be done... But I would prefer not to because this is a pattern change that can be extrapolated without an exhaustive list.

** `duration`. Before: `http_server_requests_duration_seconds`. Now: `http_server_requests_seconds`
* Some metrics would display Tags ending in a comma (`,`). This tailing comma has now been removed. Example: `"hibernate_flushes_total{entityManagerFactory=\"<default>\",env=\"test\",env2=\"test\",registry=\"prometheus\",} 1.0"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we have the " ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was just to delimit the String and it can go away.

* It is no longer possible to create a metric generating Service Level Objectives and Percentiles at the same time.

Other changes:

* Metrics must be registered always with the same tags. Micrometer will now send a warning if we register the same metric more than once with different Tag names.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would separate these changes into 2 categories:

  • metric format changes (type, name..)
  • implementation changes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok


Quarkus automatic instrumentation will generate metrics reflecting these changes. If your application defines custom metrics, be sure to update their creation, associated tests, and any dashboard queries to align with the guidelines above.

=== About metrics in Quarkus

The https://quarkus.io/guides/telemetry-micrometer[Micrometer extension] is the recommended approach to generate metrics in Quarkus and this a rare occasions were breaking changes are being introduced.

Micrometer has become the default metrics framework in Quarkus due to its stability, maturity, and widespread adoption on the Java ecosystem — not https://quarkus.io/guides/opentelemetry-metrics[OpenTelemetry Metrics].

Micrometer support in Quarkus is built on top af a main extension `quarkus-micrometer`, then specific registries extensions include it as a dependency and implement a registry sending out the telemetry. The Prometheus registry (`quarkus-micrometer-registry-prometheus`) is the default and most commonly used, and it is the focus of this announcement.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of not af :-)


However, there are alternative ways to export metrics using Micrometer:

* Through the https://github.com/quarkiverse/quarkus-micrometer-registry/[Quarkiverse Micrometer registries]
* Via OpenTelemetry, using a bridge provided by the https://quarkus.io/guides/telemetry-micrometer-to-opentelemetry[Micrometer and OpenTelemetry] extension. This setup allows Micrometer metrics to be sent as OpenTelemetry metrics, offering a unified output via the https://opentelemetry.io/docs/specs/otlp/[OpenTelemetry OTLP protocol].

For more details on Observability in Quarkus please visit https://quarkus.io/guides/observability[this guide].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: do all these ways use the same metric conventions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, Micrometer and OpenTelemetry follow different semantic conventions, however, Micrometer metrics telemetry going out through the quarkus-micrometer-opentelemetry extension will keep the Micrometer semantic conventions alignment. It's not 1:1 but close and documented here: https://quarkus.io/guides/telemetry-micrometer-to-opentelemetry#semantic-convention-differences
Probably worth mentioning it... Will update.


=== Conclusion

While the existing Prometheus registry remains available for the Quarkus 3.x lifecycle, it is now deprecated, and users are encouraged to begin migrating to the new extension because the old client extension will be removed on Quarkus 4.0 (no timeline at this moment).

This change introduces a number of breaking updates aligned with Micrometer 1.13 and Prometheus Client v1.x, affecting metric types, naming conventions, and APIs.

To support users, a migration plan has been outlined to provide flexibility and minimize disruption.

The prometheus client is not the only option to send out telemetry, there are alternative options such as the Quarkiverse registries or our OpenTelemetry bridge.

You can follow Quarkus release dates here: https://github.com/quarkusio/quarkus/wiki/Release-Planning
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would remove this sentence.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just because we mention a future version with no estimated date, at least, they can keep an eye here... You still think we should remove it?


Loading