<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 10/27/16 4:10 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A77595@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Wasn't sure (and I haven't fully grokked Meter yet) but I wondered about that.
</pre>
</blockquote>
<br>
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. <br>
<br>
In any case, I don't know why I initially omitted, but I do think it
would be desirable to just time the whole resolve() method as well
as the origin fetch.<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A77595@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">In this approach, is the Map<String,whatever> returned by the gauge
dynamic?
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
Ok, so you inject the resolver instance(s) into the gauge, and then
you can pull data from its properties dynamically.<br>
<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A77595@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite"><br>
<pre wrap="">
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.</pre>
</blockquote>
<br>
Oh, right, b/c the data is the update time, etc from the resolvesr.
Ok, that's different than my case here.<br>
<br>
I may take a stab at a gauge backed by other metrics objects. They
have examples of that.<br>
<br>
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? 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?<br>
<br>
Or maybe somehow there's a shared Map that each component adds data
to, but I'm not clear on that yet...<br>
<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A77595@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite"><br>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
That seems prudent to me.
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A77595@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
</blockquote>
<br>
</body>
</html>