-
Notifications
You must be signed in to change notification settings - Fork 923
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add armeria-prometheus1 module for Prometheus version 1 and deprecate older classes. #5698
Conversation
Motivation: Micrometer 1.13.0 updates its Prometheus dependency from 0.x to 1.x. In Prometheus 1.x, the package of `PrometheusMeterRegistry` has changed and `CollectorRegistry` is no longer used. More details can be found in the [migration guide](https://github.com/micrometer-metrics/micrometer/wiki/1.13-Migration-Guide). Modifications: - Updated Micrometer from 1.12.4 to 1.13.0. - Removed the Micrometer 1.3 integration test module. - We dropped supporting Micrometer <= 1.5 already: line#5661 - Updated Prometheus from 0.16.0 to 1.3.0. - Added `PrometheusVersion1MeterRegistries`, `PrometheusVersion1ExpositionService`, and its builder classes. - Deprecated `PrometheusMeterRegistries`, `PrometheusExpositionService`, and its builder classes. Result: - New Prometheus version 1 classes are added to support the updated Micrometer dependency. - The older `PrometheusMeterRegistries`, `PrometheusExpositionService`, and its builders are deprecated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple of minor comments, but looks good to me 👍 Thanks @minwoox 🙇 👍 🙇
dependencies.toml
Outdated
[libraries.prometheus] | ||
module = "io.prometheus:simpleclient_common" | ||
version.ref = "prometheus-legacy" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question) Is this used?
[libraries.prometheus] | |
module = "io.prometheus:simpleclient_common" | |
version.ref = "prometheus-legacy" |
If it is used, should the version.ref
be prometheus
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, forgot to remove it. Thanks!
core/src/main/java/com/linecorp/armeria/server/metric/PrometheusVersion1ExpositionService.java
Outdated
Show resolved
Hide resolved
* Provides the convenient factory methods for {@link PrometheusMeterRegistry}. | ||
*/ | ||
@UnstableApi | ||
public final class PrometheusVersion1MeterRegistries { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Optional) It is not easy to find this new class to use the new API.
How about removing public static
methods and adding an accessor to PrometheusMeterRegistries
?
For example:
PrometheusMeterRegistries.V0.defaultRegistry()
PrometheusMeterRegistries.V1.defaultRegistry()
We may deprecate all static methods in PrometheusMeterRegistries
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same reason. 😉
#5698 (comment)
try (ByteBufOutputStream byteBufOutputStream = new ByteBufOutputStream(buffer)) { | ||
final ExpositionFormatWriter writer = expositionFormats.findWriter(accept); | ||
format = writer.getContentType(); | ||
writer.write(byteBufOutputStream, prometheusRegistry.scrape()); | ||
success = true; | ||
} finally { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of consolidating this class with the original one? This will help users perform a more smooth migration.
class PrometheusExpositionService {
@Deprecate
public static PrometheusExpositionServiceBuilder builder(CollectorRegistry collectorRegistry) {
...
}
public static PrometheusExpositionServiceBuilder builder(PrometheusRegistry prometheusRegistry) {
...
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of consolidating this class with the original one?
If so, users have to add two different modules even though they want the new one or the old one.
That's why I have created a separate class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, it would be clearer to split PrometheusExpositionService
and PrometheusMeterRegistries
as a separate module such as :prometheus1
. This direction is an Armeria way to support multiple versions for a library like other dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, so you prefer @jrhee17's opinion: #5698 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still looks good 👍 Left a minor question 🙇
@@ -48,7 +48,7 @@ | |||
import com.linecorp.armeria.common.logging.RequestLogAccess; | |||
import com.linecorp.armeria.common.logging.RequestLogProperty; | |||
import com.linecorp.armeria.common.metric.MeterIdPrefix; | |||
import com.linecorp.armeria.common.metric.PrometheusMeterRegistries; | |||
import com.linecorp.armeria.common.prometheus.PrometheusMeterRegistries; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question) I'm wondering if to minimize breaking changes, we could keep the package structure the same. I think this could be done by also declaring a separate prometheus0
module.
The upside would be:
- Guaranteed one-line breaking change for users since they only need to add a dependency. (no need to touch java code)
- The symmetry between
prometheus0
andprometheus1
is just easier to reason about. - Users using
prometheus1
don't need code forprometheus0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this could be done by also declaring a separate prometheus0 module.
Had a chat about this and I don't want to add prometheus0
right now because we have to maintain the same classes in the core module and prometheus0
module.
Having said this, we might introduce prometheus0
later if we want to keep supporting Prometheus 0 dependency when we reach Armeria v2.0.
we could keep the package structure the same.
We can't do this without breaking change for now. 😢
final boolean hasPrometheus = hasAllClasses( | ||
prometheusMeterRegistryClassName, | ||
"io.prometheus.client.CollectorRegistry"); | ||
"io.prometheus.metrics.model.registry.PrometheusRegistry"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:prometheus1
is a compile scope that we need to check in runtime if it exists.
"io.prometheus.metrics.model.registry.PrometheusRegistry"); | |
"io.prometheus.metrics.model.registry.PrometheusRegistry", | |
"com.linecorp.armeria.server.prometheus.PrometheusExpositionService"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed this. Added thanks! 😉
@@ -3,8 +3,8 @@ dependencies { | |||
api libs.jakarta.inject | |||
compileOnly libs.jakarta.validation | |||
|
|||
// TODO(anuraaga): Consider removing these since this module does not have related functionality. | |||
optionalApi libs.micrometer.prometheus | |||
optionalApi project(':prometheus1') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Users may not know they have to add :prometheus1
dependency to use Prometheus exposition. What do you think of advertising for prometheus1
where PrometheusExpositionService
is linked in ArmeriaSettings
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good idea. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! 👍
… older classes. (line#5698) Motivation: Micrometer 1.13.0 updates its Prometheus dependency from 0.x to 1.x. In Prometheus 1.x, the package of `PrometheusMeterRegistry` has changed and `CollectorRegistry` is no longer used. More details can be found in the [migration guide](https://github.com/micrometer-metrics/micrometer/wiki/1.13-Migration-Guide). Modifications: - Updated Micrometer from 1.12.4 to 1.13.0. - Removed the Micrometer 1.3 integration test module. - We dropped supporting Micrometer <= 1.5 already: line#5661 - Updated Prometheus from 0.16.0 to 1.3.0. - Added `armeria-prometheus1` module. - `PrometheusMeterRegistries`, `PrometheusVersion1ExpositionService`, and its builder classes are added. - Deprecated `PrometheusMeterRegistries`, `PrometheusExpositionService`, and its builder classes. Result: - The older `PrometheusMeterRegistries`, `PrometheusExpositionService`, and its builders are deprecated. - Use the same classes in the `armeria-prometheus1`.
Motivation:
Micrometer 1.13.0 updates its Prometheus dependency from 0.x to 1.x. In Prometheus 1.x, the package of
PrometheusMeterRegistry
has changed andCollectorRegistry
is no longer used. More details can be found in the migration guide.Modifications:
serviceLevelObjectives
in timer histogram metrics #5661armeria-prometheus1
module.PrometheusMeterRegistries
,PrometheusVersion1ExpositionService
, and its builder classes are added.PrometheusMeterRegistries
,PrometheusExpositionService
, and its builder classes.Result:
PrometheusMeterRegistries
,PrometheusExpositionService
, and its builders are deprecated.armeria-prometheus1
.