Metrics follow-up thoughts

[Cantor, Scott]

On 9/16/16, 5:34 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:

> 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.

Yes, it's in memory.

A lot of them are point in time (counters, gauges) and so the data's either a long, or it's a piece of data you're returning on the fly as the implementation of Gauge (this is the interesting one, there is no such class, it's an interface you have to implement to return the value to report). So that's not significant.

Metrics that are time series data implement on top of something called a Reservoir, which have different subtypes for different eviction policies to control how data is measured (for example, do you care more about current data than old data?). Those have size arguments or time-based settings for eviction, so you can control how data leaves and how that influences the measurement.

I think none of the metrics are ever accessed except by Reporters (or explicitly by code). Most are poked by the application to give them data, so those are push, Gauges are pull).

> 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.

Yes, I had straw-man'd net.shibboleth.idp.metric rather than net.shibboleth.idp in my example.

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

I think counter() is, the others are not. They mention it in the guide, and now that I understand Gauge better, I see the reason.

Since Gauge is an interface, you don't really create it in the same way as a named counter, and creating separation between the source of the Gauge and other code would depend exclusively on whether there's a getter. It's really down to whether you expose the data publically or not, and if not, then the only code that could create the Gauge is the source of the data.

The other types are mostly concrete objects that can be created separately and then accessed by the code conditionally to report data to them.

I dunno if Java has method objects you can pass around? I seem to recall it does...

-- Scott