Navigation Menu

Skip to content
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

Clarify documentation on disabling web client request metrics #32136

Closed
NihalGoel opened this issue Aug 22, 2022 · 3 comments
Closed

Clarify documentation on disabling web client request metrics #32136

NihalGoel opened this issue Aug 22, 2022 · 3 comments
Assignees
Labels
type: documentation A documentation update
Milestone

Comments

@NihalGoel
Copy link

Spring Boot configures http clients (resttemplate & webclient) by default to gather metrics using micrometer.

We use the property management.metrics.enable.http.client.requests to disable http client request metrics by default but under the hood micrometer Meter.Id instances are still being created for every permutation of tags measured.

Given enough permutations this can create something close to a memoryleak as it will create (and cache) all these Meter.Ids and cause severe pressure on GC or even apps dying due to an OOME.

as a workaround we can set management.metrics.web.client.request.autotime.enabled to false but I would expect this to be disabled automatically when http client request metrics are disabled.

This is on Spring boot 2.7.3

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Aug 22, 2022
@wilkinsona
Copy link
Member

The management.metrics.enable property is described as "whether to prevent meters from emitting any metrics". As such, the behavior that you have observed is to be expected – the meters for HTTP client requests are still created but no metrics are emitted from them.

To disable auto-timing of client request metrics, you should set management.metrics.web.client.request.autotime.enabled to false as you have done. Alternatively, you can exclude HttpClientMetricsAutoConfiguration entirely.

@wilkinsona wilkinsona closed this as not planned Won't fix, can't repro, duplicate, stale Aug 31, 2022
@wilkinsona wilkinsona added status: invalid An issue that we don't feel is valid and removed status: waiting-for-triage An issue we've not yet triaged labels Aug 31, 2022
@breun
Copy link
Contributor

breun commented Aug 31, 2022

Based on the description of the property me and my colleagues expected no meters would be created with management.metrics.enable set to false. It was only after they investigated out-of-memory issues that they discovered that lots of meter objects were still being created.

Maybe we could expand the property description to make it explicit that it affects emitting metrics, but doesn’t affect creation of meters? And maybe add a reference to management.metrics.web.client.request.autotime.enabled for the latter? We could create a PR for this.

@wilkinsona wilkinsona changed the title Metrics should not be gathered when Http client request metrics are disabled Clarify documentation on disabling web client request metrics Aug 31, 2022
@wilkinsona wilkinsona added type: documentation A documentation update and removed status: invalid An issue that we don't feel is valid labels Aug 31, 2022
@wilkinsona wilkinsona reopened this Aug 31, 2022
@wilkinsona wilkinsona added this to the 2.6.x milestone Aug 31, 2022
@wilkinsona wilkinsona self-assigned this Aug 31, 2022
@wilkinsona wilkinsona modified the milestones: 2.6.x, 2.6.12 Aug 31, 2022
@wilkinsona
Copy link
Member

Thanks, @breun. I hadn't noticed that management.metrics.web.client.request.autotime.enabled is only mentioned in the appendix. I've added something about it to the main section on HTTP client metrics and tried to clarify the filtering behavior in 7d983be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: documentation A documentation update
Projects
None yet
Development

No branches or pull requests

4 participants