Instrumenting metadata resolvers

[Brent Putman]

On 10/5/16 2:57 PM, Cantor, Scott wrote:
> That's the big stuff, probably also some ratios on cache hits/misses. Might also be good to look at instrumenting the HttpClient as part of this.

I hadn't thought about HttpClient.  That sort of implies that some of
this (dependencies, disabled stuff, etc) needs to live as far down as
java-support, so that we could return wrapped (or otherwise modified)
HC instances from our HttpClientBuilder.  Would we want just basic
request/response timing?  That seems easy via wrapping it.  I guess
could also do # of requests to individual domains, or for particular
URIs, etc, if you can create the gauge name dynamically.

Probably would want a flag on the builder as to whether to return an
instrumented client instance.

> It isn't practical to wrap everything, there are too many interdependent classes (Histograms, Reservoirs). The work to wrap it would be more than the work to import all the code in the future and just take it over. What I like about Metrics is it's so brain-dead. It's basically the bare minimum you'd implement to do these things.
>
> All I dead was implement stubs for disabled metrics and a lot of work on managing them.

That's fine.  So at this point I'm mostly just wondering about the
dependency mgmt and where any necessary custom classes would live. 
Sounds like maybe it's lower than java-opensaml.

>
> I suppose it's similar, yes. But CriteriaSet only takes us so far, we'll run into something that doesn't have that kind of input model. 

Yeah, it's not a general solution.

> Either way, the basic issue is the API. We either have to create the dependency, or report the data out generically so I can wrap the resolver(s) like I just did with the services.

Well, unless we have other ideas, I suppose we just have to bite the
bullet and introduce the Metrics dependency.  It doesn't overwhelm me
with joy, but I guess ultimately it's like picking any other
dependency.  It's not unlike picking a logging library in fact (albeit
without the facade abstraction that slf4j provides).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161005/1dbb80b2/attachment-0001.html>