-
Notifications
You must be signed in to change notification settings - Fork 41.6k
Support more Micrometer histogram properties #14139
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
Support more Micrometer histogram properties #14139
Conversation
|
paging @jkschneider for a review. |
| * specified as a long or as a Duration value (for timer meters, defaulting to ms | ||
| * if no unit specified). | ||
| */ | ||
| private final Map<String, ServiceLevelAgreementBoundary> minimumExpectedValue = new LinkedHashMap<>(); |
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.
While ServiceLevelAgreementBoundary is a convenient type to deserialize this value, minimumExpectedValue is unconnected from SLAs conceptually.
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.
WDYT @snicoll?
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.
Agree. Which alternative do you recommend:
- copy ServiceLevelAgreementBoundary to a better named class with exactly the same code
- rename ServiceLevelAgreementBoundary
- other?
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.
ping @snicoll
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 frankly have no opinion as I am not sure I've grasped those concepts fully just yet. I've flagged for team attention to get this one more visibility. We have a call today so we should provide a smarter feedback soon.
Thanks for your patience.
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.
It's unfortunate that the ideal type is either a long or a Duration. Separate properties for distribution summaries (long) and timers (Duration) would offer more type-safety in the configuration and could also simplify the property descriptions. I'm not sure what those properties would be called though.
Failing that, I'd type the value as String and then convert that to a long or Duration using the conversion service. That should ensure the same conversion behaviour as if the properties themselves had been more strongly typed.
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 guess that ship has sailed with the sla property (or we can make this compromise only there). The problem by having two target types depending on the meter type is that we can't really get proper IDE support for this.
I am not sure how we could find a proper name for those and the convenience of doing it on a per meter id is quite appealing. So a String to long or Duration looks like the way to go.
@alexanderabramov are you interested to revisit the PR short term? RC1 is due soon.
| "distribution.maximum-expected-value.[spring.boot]=5000")); | ||
| assertThat(filter.configure(createMeterId("spring.boot"), | ||
| DistributionStatisticConfig.DEFAULT).getMaximumExpectedValue()) | ||
| .isEqualTo(5000000000L); |
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.
For those that aren't used to seeing the difference in significant digits between nanoseconds and milliseconds, it might be more clear to write Duration.ofMillis(5000).toNanos()
| management.metrics.binders.processor.enabled=true # Whether to enable processor metrics. | ||
| management.metrics.binders.uptime.enabled=true # Whether to enable uptime metrics. | ||
| management.metrics.distribution.percentiles-histogram.*= # Whether meter IDs starting with the specified name should publish percentile histograms. | ||
| management.metrics.distribution.minimum-expected-value.*= # Minimum limit on the histogram buckets for IDs starting with the specified name. The longest match wins, the key `all` can also be used to configure all meters. |
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.
May or may not be worth mentioning that minimum/maximum can affect the accuracy of client-side percentiles if not set to realistic values.
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'm not sure how to phrase it in a useful way, and the docs already invite the reader to check Micrometer documentation for more details.
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 don't think we can support all here. A Duration can specify a unit, for example 30s. How would that be converted to a plain long for those meters that require that rather than a Duration?
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.
We've decided to drop support for sla so we shouldn't add support for all here either.
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.
Dropping sla is a usability concern, as this is going be a frequently set property. What is the reasoning behind this decision?
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.
We’re not dropping support for sla as a whole, just all as it doesn’t make sense given the mixture of long and duration values depending on the meter type.
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.
Oh, I see. Many thanks.
Adds configuration properties for Micrometer histogram settings: "minimumExpectedValue", "maximumExpectedValue"
|
|
@snicoll @jkschneider So what are the next steps on this PR? |
|
@alexanderabramov there is some additional discussion in the comments above. It would be nice to know if you intend to look at them soon as RC1 is due next week. |
This commit adds configuration properties for Micrometer histogram settings: "minimumExpectedValue" and "maximumExpectedValue". See spring-projectsgh-14139
|
I've started to review and polish the PR since RC1 is around the corner. I was trying to find a common type for the meter value and renamed I may have found a side effect in the binder while doing that so I am investigating that. Perhaps we'll have to postpone this one I am afraid. |
As we just discussed on Slack, I think it's worth having two separate types here as, conceptually, the two things are quite different. Given that we have
Unless of course this forces us to use a |
This commit adds configuration properties for Micrometer histogram settings: "minimumExpectedValue" and "maximumExpectedValue". See gh-14139
* pr/14139: Polish "Improve Micrometer histogram properties support" Improve Micrometer histogram properties support
|
@alexanderabramov thank you very much for making your first contribution to Spring Boot. I've merged it with a polish commit. I didn't want to force users to wraps their meter IDs with brackets so I went ahead with a |
Adds configuration properties for Micrometer histogram settings:
"minimumExpectedValue", "maximumExpectedValue"