Freeze?

[Cantor, Scott]

> Actually, I just commented in the issue, but I think maybe just timing things is
> better, and gives you a Meter as a part of that.  I think.

I think the idea is Timers tell you how long something takes and Meters how often something happens. Obviously each time you take a timer measure, you're recording an event so I guess it's a superset.

> Ok, so you inject the resolver instance(s) into the gauge, and then you can
> pull data from its properties dynamically.

Via the ReloadableService layer, yes, it's injected. I was reimplementing the status page just in metric form.

> Not sure yet how the Map<String,T> idea works.  If the String key is the
> component ID, then doesn't that Gauge have to be created and managed by
> something that knows about all the (in the this case) metadata resolvers?

Yeah, I don't know that it works for my situation, which is a conclusion I came to this AM when I studied this, but my point was it might work for your case of exposing the different values by entityID since that's more self-contained data.

> And then it gets the various metrics objects based on being able to construct
> the Metrics name from the component ID?  Or something like that?

My parallel point was that I didn't make the component ID part of the metric name. Instead I made the metric a Gauge over a Map keyed by the component ID.

> Or maybe somehow there's a shared Map that each component adds data
> to, but I'm not clear on that yet...

I think there are a lot of patterns, just will take some playing around and if we can try a few and reserve the right to change them later, we're ok.

-- Scott