Problem of audits overloading the database
Published: May 6, 2026 - 10:41
Hello,
we've been having issues for some time with the management of audit log storage on the server in the database, which tends to cause it to grow unnecessarily large.
There's a discrepancy between the retention parameters we specify in our audit package and the parameters the server uses.
For example, max_count=10, keep_days=30.
The WAPT agent correctly uses both parameters with their values, but the WAPT server only uses keep_days and not max_count. This means, for example, that for an audit using the LLDP protocol we've implemented, which retrieves the switch and the workstation's connection port, we've specified max_count as 10 and keep_days as 365 to only retain the last 10 audit logs over 365 days. However, the server doesn't take max_count into account, only keep_days. This results in one audit of the packet every 2 hours for 365 days across nearly 9,000 machines... you can imagine the volume; it represented 8 GB in the database audit table.
Another problematic audit is BitLocker. There are 1,117,000 BitLocker key audits for almost 9,000 machines. In fact, the encryption value is different with each audit, generating a new entry. We're looking at approximately 600 BitLocker audit entries per machine in the database.
Currently, the WAPT audit table represents 40 GB out of the database's total 49 GB.
I think there are things that need improvement to prevent this database from exploding with audit management.
Thank you for your feedback,
Rémy Esberard
we've been having issues for some time with the management of audit log storage on the server in the database, which tends to cause it to grow unnecessarily large.
There's a discrepancy between the retention parameters we specify in our audit package and the parameters the server uses.
For example, max_count=10, keep_days=30.
The WAPT agent correctly uses both parameters with their values, but the WAPT server only uses keep_days and not max_count. This means, for example, that for an audit using the LLDP protocol we've implemented, which retrieves the switch and the workstation's connection port, we've specified max_count as 10 and keep_days as 365 to only retain the last 10 audit logs over 365 days. However, the server doesn't take max_count into account, only keep_days. This results in one audit of the packet every 2 hours for 365 days across nearly 9,000 machines... you can imagine the volume; it represented 8 GB in the database audit table.
Another problematic audit is BitLocker. There are 1,117,000 BitLocker key audits for almost 9,000 machines. In fact, the encryption value is different with each audit, generating a new entry. We're looking at approximately 600 BitLocker audit entries per machine in the database.
Currently, the WAPT audit table represents 40 GB out of the database's total 49 GB.
I think there are things that need improvement to prevent this database from exploding with audit management.
Thank you for your feedback,
Rémy Esberard