-
Notifications
You must be signed in to change notification settings - Fork 478
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
refactor(layers/prometheus-client): remove useless scheme
field from PrometheusAccessor
and PrometheusMetricWrapper
type
#5026
Conversation
…PrometheusAccessor and PrometheusMetricWrapper type
PrometheusAccessor
and PrometheusMetricWrapper
typescheme
field from PrometheusAccessor
and PrometheusMetricWrapper
type
registry.register("opendal_requests", "", requests_total.clone()); | ||
registry.register("opendal_errors", "", errors_total.clone()); | ||
registry.register( | ||
"opendal_requests", |
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.
@Xuanwo What do you think of removing the opendal_
prefix of these metrics?
Users can customize prefix through the following code:
let builder = services::Memory::default();
let mut registry = prometheus_client::registry::Registry::default();
let op = Operator::new(builder)
.expect("must init")
.layer(PrometheusClientLayer::new(registry.sub_registry_with_prefix("opendal")))
.finish();
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 want to retain the opendal_
prefix to clearly indicate that these metrics are emitted by opendal, similar to how alertmanager
does.
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.
But for PrometheusLayer
(not PrometheusClientLayer
), there is no builtin opendal_
prefix in the metrics.
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.
Actually, I want the metrics exported by these two layers to be the same, the only difference being the different prometheus libraries they use, but that is not the case now.
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 prefer to add prefix for PrometheusLayer
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.
Ok, I will consider unifying the metrics of these two prometheus layers in a later PR.
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.
Ok, I will consider unifying the metrics of these two prometheus layers in a later PR.
Thanks a lot for the effort!
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.
Great, thanks a lot!
Which issue does this PR close?
No
Rationale for this change
simplify the code
What changes are included in this PR?
scheme
field fromPrometheusAccessor
andPrometheusMetricWrapper
typeAre there any user-facing changes?
No