Pieter's answer is valid, though people should generally be aware that Audit Trail 11 includes updates to 3rd party libraries that contain security fixes we can't realistically backport to Audit Trail 10. If you do go with that approach, I'd run the Audit Trail 10 instance on its own small VM and lock down network access pretty hard. If its sole purpose is to keep an audit database populated for Splunk (etc.) to look at, end users certainly don't need to be able to reach it.
The answer for Audit Trail 11 (and soon, 12) is to programmatically export the audit data of interest as a tab-separated csv (yes, that's a real thing) on a schedule and ingest those exported logs into your SIEM/log aggregation solution like Splunk.
Refer to:
And when @Bill Payton says:
--Read the FAQ carefully, especially the notes about the application pool identity and its permissions.
--The script syntax must be followed exactly.
I cannot stress enough how important that is. The script is not forgiving of a single thing being slightly out of line.