Hello, I recently setup auditd rules within auditbeat. Awesome solution that will really help us make better sense of audit logs. Obviously a big issue with auditd is performance. We are working on generating metric around auditd, with and without auditbeat. Is this a valid use of my time, or will the performance hit be the same with either solution? I was hoping auditbeat would give performance advantages but maybe I'm being too optimistic?
1 Like
I haven't compared the two. Auditbeat is doing a lot more work that auditd. auditd receives the individual audit messages and writes the raw data to a file. In comparison Auditbeat receives individual audit messages, it collates them because they can arrive out of order or mixed in with other audit events, then parses the related messages, joins them into a single event, and finally it does some enrichment (e.g. converting contants to names, uids to usernames).
This extra work is cost having data that is a cleaner and easier to make sense of.
We did make some changes for the upcoming 6.4 release that allows Auditbeat to use multiple worker threads to parse the incoming stream. This should make it a little more performant. So if you do any comparisons I'd wait for 6.4 to be released or use a snapshot build.
Auditbeat uses a library called go-libaudit to receive data from the kernel and parse it. There's an open issue to do some testing of the library to determine it's limits. Setting up a benchmark that pushes a static set of audit messages through the parser to measure its throughput would be really interesting.
1 Like