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
MP Config properties for Histogram and Timers to extend and customize output #779
Conversation
api/src/main/java/org/eclipse/microprofile/metrics/Snapshot.java
Outdated
Show resolved
Hide resolved
api/src/main/java/org/eclipse/microprofile/metrics/Snapshot.java
Outdated
Show resolved
Hide resolved
api/src/main/java/org/eclipse/microprofile/metrics/Snapshot.java
Outdated
Show resolved
Hide resolved
api/src/main/java/org/eclipse/microprofile/metrics/Snapshot.java
Outdated
Show resolved
Hide resolved
9004c69
to
945efb7
Compare
After discussion with the liberty team. Also the
Further more, the |
Thanks for tagging me on this. A few thoughts...
|
@tjquinno
**Not sure if the publishPercentiles was just used as a quick example. The @donbourne wdyt? |
I would suggest to use |
054b951
to
5fb8984
Compare
For (2), I'm in favor of having a default (s or ms). Assuming we have a default, the worst case scenario is that the person configuring the value thinks the default unit is different than what it actually is -- but since the metrics we generate show the buckets, that should be a fairly easy thing for the ops person to spot and fix. If we didn't have a default unit then the error handling would be more complex, both for the runtime (do we not start the app if the slo is configured in a file in the app? do we not start the server if it's configured in an env var?), and for the ops person (more ways to get something wrong that you have to correct). @Channyboy , which unit do the timer bucket values in the /metrics output have (our unit default should match, IMO)? For (3), another argument for sticking with |
The buckets for a Timer in Prometheus output will be converted to seconds. For any incompatible values (either server or app level), I wouldn't think we would prevent the runtime from starting. We would just ignore it (with a warnning/error). |
Re: 2. (default units) I guess I will (reluctantly) step back from urging a start-up failure for unit-less settings! Then the question is what's a good default unit. I mentioned the FT default not necessarily to advocate for that as the default for this usage but because, in the FT case, everyone knows that it is method invocations being measured and so ms seems like reasonable units for that. If we expect that most uses of timers are for measuring method invocations, then ms makes sense here as well. Re: 3. (config key suffix for bucket/slos) The config key(s) must unambiguously identify what is being set. IIUC (and I could well be wrong), the Micrometer API, as an example, allows setting bucket boundary values and also, via a separate method, SLOs. The JavaDoc for Timer says (to me at least) that setting SLOs makes sure that those values are among those (perhaps along with others?) in the set of bucket boundaries. My point is that we need to very clear exactly what we are allowing the user to set via config, and we should use a strong key name to achieve that clarity. If we are going to interpret the settings as bucket boundaries, then On the other hand, if we are going to use the configured values as parameters to the Or would we expose both? |
Springboot's |
Will go ahead and update PR with the change to use |
I expect most timings will be for methods or services, and generally
while Micrometer calls these SLOs, that doesn't surface in the MP Metrics API, so I don't think we need to do things the same as Micrometer here. I'm ok with either |
14bfbd5
to
bdd60e0
Compare
@tjquinno We're aiming to release an RC1 this friday (or sooner!) May you please review. |
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.
A couple suggested changes.
//alpha.timer will publish histogram-buckets with maximum values of 500 milliseconds, 2 seconds, and 3 minutes while the beta.timer will publish histogram buckets with maximum values of 10 seconds, 2 minutes and 5 hours. Timer metrics that do not match will not have any histogram buckets. | ||
mp.metrics.distribution.timer.buckets=alpha.timer=10,500ms,2s,3m;beta.timer=10s,2m,5h |
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.
The setting for alpha.timer
specifies 10
first, but the command describing the setting does not mention it.
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, fixed!
mp.metrics.distribution.timer.buckets=alpha.timer=10,500ms,2s,3m;beta.timer=10s,2m,5h | ||
|
||
//any timer that matches with `alpha.*` will publish histograms buckets with maximum values of 50 seconds and 100 seconds while the alpha.test.timer which will publish a bucket with a maximum value 100 milliseconds due to precedence. Timer metrics that do not match will not have any histogram buckets. | ||
mp.metrics.distribution.timer.buckets=alpha.*=50s, 100s;alpha.test.timer=100 |
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.
Do we want the space in the example? Does/should the spec language say anything about spaces in the settings?
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.
fixed!
bdd60e0
to
78796cb
Compare
api/src/main/java/org/eclipse/microprofile/metrics/Snapshot.java
Outdated
Show resolved
Hide resolved
...i/src/main/java/org/eclipse/microprofile/metrics/tck/config/BadHistogramTimerConfigTest.java
Outdated
Show resolved
Hide resolved
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.
awaiting changes on 2 previously submitted comments...(pinged @Channyboy to let him know)
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.
LGTM!
Fixes #587, #674, #675, #676, #691