-
Notifications
You must be signed in to change notification settings - Fork 984
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 time window length in documentation #4625
Comments
The behavior described is intentional. Unlike the count/sum, the max is intended to be a "recent" max value. It is explained in the Note of the Timer section of the docs.
If you wanted the max to expire after one step interval, then yes, your configuration is what you should do. The default is not that because we believe it is useful when some degradation/failure is occurring to be able to see the max from a bit farther back, especially considering the degradation/failure may have also prevented metrics from being published. |
I see two issues, both having to do with this line in the documentation you quoted: "Time window size will be the step size of the meter registry unless expiry in DistributionStatisticConfig is set to other value explicitly." The step size of the meter registry in my example is one minute, is it not? Why then is the time window size three minutes? Also, it suggests changing the "expiry" setting to get a different behavior. However, "expiry" is set to one minute by default, but that doesn't result in a time window size of one minute. It's also a different configuration option than what I'm overriding in my workaround code. |
The ring buffer is expiry * bufferLength long. This is explained in the JavaDoc for both the |
I believe that I have found a bug when using the DynatraceMeterRegistry class. It looks like it would apply to all children of the StepMeterRegistry class though.
Steps to reproduce the bug:
The initial statistics that are published will be consistent with what was recorded and with each other. ("count" == 1, "avg" == , and "max" == .) After the first minute, "count" and "avg" will drop to zero, but "max" will still be for two more minutes.
To work around this I am doing the following after creating the registry:
What this does is override the size of the ring buffer used by TimeWindowMax instances to be one instead of the default, which is three. (As determined by defaults set in the DistributionStatisticConfig class.)
My workaround is only lightly tested, but the only issue I have seen so far is that the summary statistics can still occasionally be inconsistent with each other. I don't see that the Micrometer code makes any attempt at updating and resetting the summary statistics atomically, which I think explains what I am seeing.
The text was updated successfully, but these errors were encountered: