I've been documenting the audit event handlers, specifically the buffering options, and have come up against a comment in the help text "audit events are dropped." I believe this happens whenever buffers are exceeded. I see that this is a possibility for the JMS, Elasticsearch, and JDBC audit event handlers.
In a production environment, I'm pretty sure that it is unacceptable to drop audit events.
I looked for but couldn't find any MBeans you could use to monitor how full the audit event buffer is. If there are any such monitors, could you please let me know so I can add them to the doc?
If not - here's my RFE - there should be some way of monitoring the buffer so that if there are more events in the buffer then you expect, you can catch it before OpenAM starts dropping audit events.
For the 13.5 doc, I am adding a caveat in the docs that external data sinks should be monitored and probably HA so that if they go down, OpenAM can write to the buffers until they come back up again. If there's anything I could add for 13.5, please let me know. Should we recommend always logging to CSV/Syslog as a second audit sink in addition to JMS/Elasticsearch/JDBC for now, until some kind of monitoring is in place?
Also, what if you have a situation where the buffers are getting filled faster than the audit sinks can write to them? This could happen if the audit data sink were poorly configured, or if it was on slow hardware, or if the network connection from OpenAM to the audit sink was slow. Then users don't really have a way of protecting themselves from dropped audit events.
When/if this gets implemented, could you please file a doc bug so we can update the docs and let users know what actions they can take to protect themselves in case of buffers filling up?