Freeze?

[Cantor, Scott]

> Mainly what I was going to do was change use of Counter to Meter.  It seems
> more appropriate.  You can still get the total count from the Meter, but also
> get 1, 5, 15 minute averages.  The Counter seems more appropriate for
> increment/decrement cases.

Wasn't sure (and I haven't fully grokked Meter yet) but I wondered about that.

> In this approach, is the Map<String,whatever> returned by the gauge
> dynamic?

It's dynamic because I'm building it in the Gauge's getValue() method, yes. Could be cached, but it's not expensive to build so I didn't make it cached.

>  Meaning that the Gauge itself is "backed" by other Metrics
> objects, so that the data is essentially live, based on when you read data out
> of the gauge?

The Gauge isn't currently backed by Metrics objects because the public API for that data is sitting on RefreshableMetadataResolver as explicit DateTime-returning methods (and we can't go changing the interface), not as Gauges.

So the Gauge builds a Map out of raw data.

> Since this is all new to me, I don't know what if anything I could do on this
> today.  But I can certainly work on it when I get back end of next week.  But
> that's pushing into the release schedule.  If you have concrete ideas that you
> can implement in the meantime, that's also fine.

Yeah, I will look but none of this is super-essential, and it's pretty easy to tweak. I may suggest we just explicitly document that the actual metric names and groupings are not considered stable API for the time being, just so people don't make assumptions we're locked into.

-- Scott