Metrics follow-up thoughts

[Brent Putman]

On 9/16/16 4:36 PM, Cantor, Scott wrote:
>
> I think the whole metrics-core code base is fairly small and mostly taken up by the built-in Reporters and the rest is just a bunch of map maintenance code.

Presumably all the collected data is just maintained in memory. Do they
discuss how/when data is reaped?  Maybe it's obvious, I haven't read
up.  But I'm just thinking in general about memory usage if the IdP is
running for months at a time.

>
> I hadn't thought of that. The two could probably be combined, meaning a simple implementation of the code to return the objects that might be no-op'd might be based on use of logging categories, just to save the work of reimplementing something exactly like it.
>     

Yes, marrying the two would work well, I think.


>> That granularity and hierarchical config does seem nice to have, if it
>> can be made to work.
> The naming's entirely up to us so there's no reason we can't do it. I don't think that the metrics necessarily correspond to class names like the loggers do, particularly since so many are impl classes, but the same general package names should apply.

Just so as to not mix and conflate the actual logging config and the
metrics, might want to optionally auto-prepend a separate prefix or
something for the metrics categories.  So logging and metrics
categories are really separate.


>> Hmm, yeah, good point.  I thought they mentioned stuff about being
>>    thread-safe everywhere, but maybe it doesn't work if you are literally
>>    trying to register an existing name.At least the ones like
>>  counter(...) though use a getOrAdd approach, so I think those might
>>  actually work within the prototypes.  Maybe for the register(...), e.g.
>>  of a Guage, they have a way to get an existing one rather than create a
>>  new one.  They do have Maps of all these things on the registry.
>     
> Are they documented that way, or did you just look at the counter() code? I didn't see any sign that's a contract they're making.

No, I don't see any docs.  I just noticed the code.  So you're right in
that it might not be guaranteed.


>
> If something in particular is expensive to even gather and push into a metric, we could define an interface (DisabledMetric) to implement on the no-op cases so that we'd have the ability to guard that in the classes if we needed it. That's what I envisioned with the logging idea, but that could be abstracted away.

Yeah, the conceptual equivalent and use case of Logger isDebugEnabled()
and friends.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160916/afd82220/attachment.html>