8000 Make metrics names compatible with Prometheus Java library by mberndt123 · Pull Request #9740 · zio/zio · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Make metrics names compatible with Prometheus Java library #9740

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

Merged
merged 3 commits into from
Apr 4, 2025

Conversation

mberndt123
Copy link
Contributor
@mberndt123 mberndt123 commented Apr 1, 2025

Hi there,

When the Default JVM metrics were initially added to ZIO, they were written to be compatible with the metrics in the Prometheus simpleclient library.
That library has since been replaced by the Prometheus client_java library, which has changed the names of a dozen metrics:

https://github.com/prometheus/client_java/blob/main/docs/content/migration/simpleclient.md#jvm-metrics

This PR intends to make ZIO compatible with the Prometheus library and the OpenMetrics specification once more.
Since changing metrics names is an incompatible change that will break everybody's monitoring, I have left the existing layers in place, deprecated them and added new V2 layers that do the same thing but use the new names. I'm open to other suggestions, but I do think it's important to keep the metrics stable.

@mberndt123 mberndt123 changed the title add new layers for new metrics names Make metrics names compatible with Prometheus Java library Apr 1, 2025
@987Nabil
Copy link
Contributor
987Nabil commented Apr 1, 2025

In zio logging we have some metrics for logging too. There we can configure the names of the metrics if we like. I think I would like to have a such a constructor as well.

@mberndt123
Copy link
Contributor Author

Well right now the names of the metrics are just function parameters. That is OK for a private method but unsuitable as a public API because a new parameter would have to be added every time we add a new metric, breaking binary compatibility. So we'd need some configuration object with all the metrics names, and I'm not sure if it's worth the hassle. Maybe we should add that feature when somebody actually has a use case for it.

"This app exposes JVM metrics with the non-OpenMetrics-compliant names used in prometheus client_java 0.16: https://github.com/prometheus/client_java/blob/main/docs/content/migration/simpleclient.md#jvm-metrics. Use `appV2` instead, it uses names compatible with the client_java 1.0 library"
)
lazy val app = withMetrics(live)
lazy val appV2 = withMetrics(liveV2)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should we use a name like OpenMetricsApp? v2 doesn't have much meaning.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

V2 does indeed have a meaning: it means that this is the direct successor to live that you should switch to as soon as you've adapted your monitoring. openMetrics does not convey this. And actually the OpenMetrics project has been archived because it was merged into Prometheus:
https://horovits.medium.com/openmetrics-is-archived- 8000 merged-into-prometheus-d555598d2d04
And prometheus would also not be a good name because the previous version was also designed to be compatible with an earlier Prometheus library (the simpleclient library which was replaced by the client_java library).
For these reasons, I think that the V2 name is better overall.

@ghostdogpr ghostdogpr merged commit 77206ce into zio:series/2.x Apr 4, 2025
18 checks passed
@mberndt123 mberndt123 deleted the new-metric-names branch April 28, 2025 00:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0