Metrics interface
Cantor, Scott
cantor.2 at osu.edu
Fri Oct 7 17:04:33 EDT 2016
Barring Jenkins blowing up, I've moved the supporting code down into opensaml-core as discussed, more or less. This is all pretty negotiable, so Brent is welcome to adjust things, but for now I went ahead with an Initializer that installs a disabled MetricRegistry into the ConfigurationService.
That is, it's a real registry but it has no MetricFilter installed, and so it always returns disabled objects. i.e. OpenSAML default behavior should not be instrumenting anything if any code is added.
The IdP overrides this via our magic hack (OpenSAMLConfigBean), checks for a compatible MetricRegistry and installs the logger-driven filter I created to activate metrics by default on INFO.
MetricContext and the hooks for action timers/counters were moved down, and tested successfully. I'll review the MessageHandler classes, I can't remember if we supported pre/post hooks on those. I think not, it's in my action wrapper for now.
All of this is irrelevant to instrumenting code.
If you want to instrument anything directly, call MetricsSupport.getMetricRegistry().
If you have access to the ProfileRequestContext, or can get access to it, you can check for a child MetricContext and call its methods to do counters or timers based on an object's ID or class name. Anything expensive is better handled that way usually.
The only outstanding TODO is to get the special action I created into the CAS flows, I'll file an issue for that.
-- Scott
More information about the dev
mailing list