Comments (4)
Thank you for the extra added context, and for drawing out the key part of the migration guide that we can use io.micrometer:micrometer-registry-prometheus-simpleclient
in place of io.micrometer:micrometer-registry-prometheus
. This is helpful for others that may be running into unexpected build failures after the recent release.
from micrometer.
Please take a look at the Release Notes and the 1.13 Migration Guide.
Here's some background:
- After 9 years of being on 0.x, Prometheus released 1.x with breaking changes
micrometer-registry-prometheus
was migrated to the new 1.x client- At the same time the original bits of
micrometer-registry-prometheus
(Prometheus 0.x) were moved tomicrometer-registry-prometheus-simpleclient
The decision we needed to make: move to 1.x and offer a way going back to 0.x or stick with 0.x and let users opt-in to the upgrade. We decided to migrate micrometer-registry-prometheus
to 1.x and also offer micrometer-registry-prometheus-simpleclient
which is the exact copy of micrometer-registry-prometheus
before the migration.
The decision you need to make: migrate to 1.x (use micrometer-registry-prometheus
) or stay on 0.x (use micrometer-registry-prometheus-simpleclient
).
If you want to migrate to the new client, this is the change you should make:
- runtimeOnly 'io.micrometer:micrometer-registry-prometheus:1.12.6'
+ runtimeOnly 'io.micrometer:micrometer-registry-prometheus:1.13.0'
If you do not want to migrate to the new client, this is the change you should make:
- runtimeOnly 'io.micrometer:micrometer-registry-prometheus:1.12.6'
+ runtimeOnly 'io.micrometer:micrometer-registry-prometheus-simpleclient:1.13.0'
(Please notice that you need to change the version number and the name of the artifact in this case.)
If you use a framework that auto-configures things for you, like Spring Boot, I think the change should be transparent to you since Boot auto-configures the new client for you. Excluding some cases for example using the Prometheus API directly or the old PrometheusMeterRegistry
. In that case instead of depending on PrometheusMeterRegistry
, you should depend on MeterRegistry
.
from micrometer.
@jonatan-ivanov Our challenge was that we were receiving this dependency transiently and the dependency that pulled it in was pulling it in via latest.release
(yes, I agree that this is not a great idea), which forced it to use 1.13.0
. We did not choose to migrate to 1.13.0
, but we started encountering unexpected build failures as soon as this version was released.
I'm not well-versed enough in my Gradle dependency management to know when it automatically pulls in a higher minor version outside of latest.release
(my assumption is that it typically doesn't).
That said, 0.x Prometheus may have made a major version change to 1.x, but this specific library had breaking changes in a minor version bump, which feels incorrect. In these cases, I would usually expect a 2.x release of micrometer-registry-prometheus
.
from micrometer.
Our challenge was that we were receiving this dependency transiently and the dependency that pulled it in was pulling it in via latest.release (yes, I agree that this is not a great idea), which forced it to use 1.13.0. We did not choose to migrate to 1.13.0, but we started encountering unexpected build failures as soon as this version was released.
From latest.release
perspective you were broken if this would have happened in a major release, i.e.: Micrometer 2.0.0. How the component that brings this in transitively not broken, did they migrate? (Btw migration should be simple, most of the time is a package name change but please check the migration guide.) Can you ask them to bring in micrometer-registry-prometheus-simpleclient
instead?
With latest.release
you are sitting on multiple ticking bombs. (I also recommend using dependency lock files.)
I'm not well-versed enough in my Gradle dependency management to know when it automatically pulls in a higher minor version outside of latest.release (my assumption is that it typically doesn't).
latest.release
always pulls in the latest (hence the name), if someone releases a new major version and breaks everything, it pulls that in. major.+
(1.+
) is usually a safer bet.
In Gradle, you can exclude micrometer-registry-prometheus
and pull in micrometer-registry-prometheus-simpleclient
, you have control over what is transitively pulled in/not pulled in.
That said, 0.x Prometheus may have made a major version change to 1.x, but this specific library had breaking changes in a minor version bump, which feels incorrect. In these cases, I would usually expect a 2.x release of micrometer-registry-prometheus.
Last time we tried to do 2.x, we were not able to because of users/other libraries who did not want to migrate and breaking changes. :) I explained above what were our two options (2.0 is not really right now I think) and we are trying our best not to break people but is this change really that breaking when the fix is updating the name with the version? You don't need to change your code, but the dependency what you also do with the version.
from micrometer.
Related Issues (20)
- Apply test-retry settings to all tests
- Upgrade opentelemetry-collector-contrib to 0.104.0
- Value from environment variable `OTEL_EXPORTER_OTLP_ENDPOINT` is not being used HOT 2
- Add a metric for tracking heap size after last gc event HOT 2
- Migrate to io.spring.develocity.conventions:0.0.19
- Spring Boot 3.x Micrometer StatsD registry does not send metrics to UDP port when another StatsD client is active on the same port
- Excessive TLAB memory allocations from MetricsTurboFilter HOT 2
- Memory leak is suspected when searching meters in MeterRegistry HOT 4
- Metrics not collected after ExecutorService recreation
- Bump jersey3 from 3.0.4 to 3.0.12
- Bump jersey3 from 3.0.11 to 3.0.12
- Bump jersey3 from 3.0.11 to 3.0.12
- Bump jersey3 from 3.0.11 to 3.0.12
- Document ExponentialHistogram support in OTLP registry
- Add docs for ObservationValidator
- ObservationValidator fails with NullObservation
- The signature of MultiGauge.register should be Iterable<? extends Row<?>>
- Possibility to have non shadowed netty and reuse the dependency HOT 1
- Exponential Histogram should include minimumExpectedValue in positive buckets
- BOM contains a non-resolvable dependency: io.micrometer:concurrency-tests
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from micrometer.