Freeze?

[Brent Putman]

On 10/27/16 9:42 AM, Cantor, Scott wrote:
>> Having reviewed the Metrics docs again, I was planning on making some
>> changes to what I initially checked in yesterday for the dynamic
>> metadata resolver.  But didn't get to it by tonight.  I plan to do
>> tomorrow afternoon at the latest.  I sort of think of that stuff as
>> like logging, so it's not really core function, as you say.
> That's fine. 

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.

> The only real issue I have is whether I want to somehow agglomerate the new metadata metrics into the original group I built up in the IdP or not.
>
> What I did was build these objects that implement MetricSet and MetricFilter. The idea was to be able to register them all as unit with one Spring bean, and then also be able to access them with the API as a unit by labeling them (e.g. /idp/profile/admin/metrics/metadata). I just want to see if there's any way of integrating the new stuff in.

Sounds interesting, but I haven't looked at any of that yet.  I'm don't
understand yet how it all works.

>
> One point I guess, which relates to your question about counters specific to entityIDs: when I exposed (for example) the update time of the metadata resolvers, the way I decided to do it was just to make the Gauge for that a Map<String,DateTime> with the mapping from resolver ID to the value.
>
> That way the access to the metric isn't specific to any one configuration of resolvers, but you can still access the specific one if you want to.
>
> You might want to do something similar for the counters. You could have a Map<String,Long> and just expose the Map as the Gauge.



In this approach, is the Map<String,whatever> returned by the gauge
dynamic?  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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161027/5171dc7c/attachment-0001.html>