Preconfigured metrics in IdP 3.3.1

[Cantor, Scott]

On 7/5/17, 11:00 AM, "users on behalf of Etienne Dysli-Metref" <users-bounces at shibboleth.net on behalf of etienne.dysli-metref at switch.ch> wrote:

> Ok I understand that no metrics are instantiated by default. What's the
> connection with DEFAULT_METRIC_NAME then? Does a counter or timer
> magically appear if I use "net.shibboleth.idp.something" in the script?

No, the only place that's used is the built in metric sets, it's just a static constant, nothing special.

> Does it make sense to time whole profile requests? If they contain user
> interaction, that kind of thrashes the measure's value, doesn't it?

It depends what you're measuring. For one thing, you can audit whether SSO occurred also, so you can eliminate the other set of cases from the data if you want to. What it tells you is how long people are taking to get through the process, which tells you things about your UI, how long people sit on the page, things like that.

> Some more things I'd like to measure:
> - count usage of each profile (script above), as in "Can I turn off
> SAML1 already?"

Of course that's also possible to get in the audit log.

> - time LDAP requests (both authn and attributes)

I believe resolver plugin IDs are also usable as triggered counters and timers. If not, they should be, but I think I included that.

> So if I understand the docs correctly, this is only a matter of finding
> the right Actions beans to instrument.

Not always actions, and a lot of that is probably easier to get from logs via tools like Splunk, but if you wanted to, yes.

The problem with the metrics is you have to have a way to collect them, which can be more work in the end than just using the log with good tools.

-- Scott