add CountSinceLastMeasurement and TotalSinceLastMeasurement that resets everytime its measured

[m-nagarajan]

1. add CountSinceLastMeasurement that resets the count everytime its measured
   Simple version of SampledCount, this aggregates counts as a single sample and gets reset to 0 every time it is measured. The sample window is just the time between measurements unlike SampledCount which can be defined by number of events or elapsed time. Measure every second to get count per second. Measure every minute to get count per minute. Measure adhoc to get the delta count since the last measurement.
2. add TotalSinceLastMeasurement that resets the total everytime its measured

These classes doesn't support quota currently as it resets everytime it's measured which probably need a refactoring where the measure call triggered from the quota path does not cause a reset, and only the measure call from the MetricsReporter end up triggering the reset.

[FelixGV]

Thanks, I think this is a useful change.

What do you think about calling these two classes CountSinceLastMeasurement and TotalSinceLastMeasurement? It doesn't roll off the tongue as much, but I feel it's more descriptive?

Also, I am thinking about two potential scope creeps, which probably do not need to be addressed in this PR, but I'd like to hear if you have thoughts on them...

1. I would like to be able to build a Rate and OccurrenceRate based on these ...SinceLastMeasurement stats. Why? Because I think their simplicity should make them even more efficient than SampledCount and SampledTotal. But...

2. Because rates are often used as part of quotas, we should also think about how these ...SinceLastMeasurement stats interact with quotas. In this PR's proposed implementation, I think quotas would be broken, which is maybe ok because it seems uncommon to have a quota configured on something else than a rate, but anyhow... To make interactions with quotas work, we would probably need a refactoring where the measure call triggered from the quota path does not cause a reset, and only the measure call from the MetricsReporter end up triggering the reset. I don't think we need to fix this in this PR, but maybe we should make the incompatibility explicit by having the two new stats implement Initializable and have them throw an exception if the passed in MetricConfig has quotas enabled?

[m-nagarajan]

Thanks @FelixGV for the comments

What do you think about calling these two classes CountSinceLastMeasurement and TotalSinceLastMeasurement? It doesn't roll off the tongue as much, but I feel it's more descriptive?

Though the names suggested feels a bit too descriptive, I believe it's better than being cryptic which was the case before. I am onboard. thanks.

2. Because rates are often used as part of quotas, we should also think about how these ...SinceLastMeasurement stats interact with quotas. In this PR's proposed implementation, I think quotas would be broken, which is maybe ok because it seems uncommon to have a quota configured on something else than a rate, but anyhow... To make interactions with quotas work, we would probably need a refactoring where the measure call triggered from the quota path does not cause a reset, and only the measure call from the MetricsReporter end up triggering the reset. I don't think we need to fix this in this PR, but maybe we should make the incompatibility explicit by having the two new stats implement Initializable and have them throw an exception if the passed in MetricConfig has quotas enabled?

Took a look at the code and it needs some refactoring like you mentioned as it's the same set functions that gets called on both the paths. For now, made these 2 new classes to throw an exception during init() if config has quota in it to make it explicit.

1. I would like to be able to build a Rate and OccurrenceRate based on these ...SinceLastMeasurement stats. Why? Because I think their simplicity should make them even more efficient than SampledCount and SampledTotal. But...

That is a good suggestion. I will take a stab at this along with the above refactoring with a separate PR.

[FelixGV]

Thanks Manoj, looks great!