Preconfigured metrics in IdP 3.3.1

[Cantor, Scott]

> Hmm good point. I've tried this timer
> metricContext.addTimer("idp.profile." + profile, "DecodeMessage",
> "WriteAuditLog");
> but since there are several possible end states I'm not sure
> WriteAuditLog is a good choice. RecordResponseComplete maybe?

Honestly I abandoned that approach to do the measuring so I didn't ever try to find a good spot to do it. I don't think Record gets called when local errors occur, so it depends what you want to measure I guess.

And I forgot that I actually hadn't done this in the code base. Right now there's no audit extraction happening at the very start of the flows, and since I figured I should include the time to decode the SAML message, I just did this myself with a bit of a trick. I stuck this in the metric script:

importClass(Packages.org.joda.time.DateTime);
var auditCtx = input.getSubcontext("net.shibboleth.idp.profile.context.AuditContext", true);
auditCtx.getFieldValues("ST").add(new DateTime().toString("YYYY-MM-dd'T'HH:mm:ss.SSSZZ"));

I'm just taking advantage of the fact that the metric script runs as pretty much the second step of every flow.

> I think applications should provide their own metrics, instead of having
> to analyse theirs logs to get the information. For the moment, the only
> thing I have running in production is Munin scripts that grep the audit
> log and I don't consider grep a "good tool" for log analysis...
> Prometheus and ELK are on my wish list.

Definitely two schools of thought on it, but we have Splunk here so it's easier for me to just let it do the work for me. But please let me know what's missing, I do want to support the other approach as best we can.

-- Scott