Instrumenting metadata resolvers

Brent Putman putmanb at georgetown.edu
Wed Oct 5 14:35:15 EDT 2016



On 10/5/16 11:49 AM, Cantor, Scott wrote:
> Brent, any more thoughts on this? While I haven't exactly finalized my work, I'm pretty far along on a lot of proposed metric hooks but I'm staying confined to the IdP at the moment. But I know getting numbers out of the MDQ client will be important at a minimum.

I guess I don't have any definite thoughts yet.  It would be probably
helpful to talk about actual concrete metrics use cases.  What types of
things were you thinking?  I'm assuming some timer(s) around certain
operations, for example 1) total resolution time (literally bookending
the resolve() method) 2) time for executing remote fetches.  Any
gauges? Maybe 1) # of entities currently "live" 2) number of remote
fetches.

I haven't looked yet at where you wound up with the notion of using
Metrics interfaces directly vs having some kind of library-independent
abstraction.  But I guess if we wind up with the former that's not the
end of the world.

As far as how these are actually used: I liked your idea of using
presence/absence of stuff in the context tree to control whether
collection was on/off.  But of course in the metadata resolvers, unlike
the profile actions and message handlers, we don't actually have that. 
I guess maybe kinda sorta you could stuff criteria into the input
CriteriaSet to do a similar thing, but I'm not sure how I feel about
that yet, vs just hardwiring things right in the resolver.  (As a side
note, that would seem sort of like what we mused about for encryption
logging in OSJ-156 (which btw I was probably going to work on very
soon). So maybe it's not crazy.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161005/aba11e27/attachment.html>


More information about the dev mailing list