I would like to inquire about the auditing mechanism in Percona Server for MongoDB (PSMDB).
We are currently using the latest Community Edition version, 8.0.23. We need to enable the auditing feature, and I would like to better understand how audit events are processed.
Specifically, I would like to know whether auditing is handled synchronously or asynchronously. Additionally, does the processing behavior differ depending on the audit destination (file vs. syslog), or is the underlying mechanism the same regardless of the destination?
Based on my research, I found documentation stating that audit events are recorded before the operation is written to the journal when a DML operation occurs. This led me to believe that auditing is handled synchronously. However, I have also come across information suggesting that database transactions may proceed independently of audit logging, which implies asynchronous behavior.
To summarize my questions:
Is the PSMDB auditing feature implemented synchronously or asynchronously? In other words, does audit logging affect or block transaction execution?
When using destination=file, both JSON and BSON formats are available. Is there a significant difference in server overhead or performance impact between these two formats?
I would appreciate any clarification you can provide.
Percona Server for MongoDB supports three destinations for audit log:
With the console destination, Percona Server for MongoDB writes each audit log entry to standard output, flushing the output buffer, so the handling is synchronous.
With the syslog destinations, it issues the syslog system call for each audit log entry; unless special measures are taken, the system call does not flush the system log file to disk, resulting in asynchronous handling.
With the file destination, it writes audit log entries to disk just before persisting the journal, making the handling synchronous. Writing audit log entries to disk is amortized to some extent because Percona Server for MongoDB buffers them in between writings.
Nevertheless, synchronous flushing of audit log entries in #1 and #3 does not necessarily mean enabling audit logging compromises performance. Auditing captures:
client authenticating and logging out;
creating, updating, and deleting users, roles, and privileges;
creating and deleting databases, collections, indexes, views;
creating, updating, and deleting replica sets and shards;
regular CRUD operations on documents, but only if they are performed in system collections.
Auditing ignores insertions, updates, reads, and deletes of documents in regular user collections. Loosely speaking, the audit log tracks changes to how a deployment and its data are organized, not the data itself.
Even though committing a transaction typically involves persisting the journal (and therefore, writing the audit log entries to disk in case of the file destination), if a transaction doesn’t involve the operations listed above, there is simply nothing to write to the audit log, and #3 above is skipped, as if auditing were disabled.
If there is something to write to the audit log, though, serializing in the BSON format is slightly more efficient than in JSON.