Page 1 of 1

Problem of audits overloading the database

Published: May 6, 2026 - 10:41
by Esberard
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

Re: Problem of audits overloading the database

Published: May 6, 2026 - 8:58 PM
by sfonteneau
Hi Rémy,

actually the max_count only concerns the database of the local WAPT agent. The server only relies on keep_days; that's how it performs cleanup.
If the server were listening to the agent's max_count, the WAPT agent could modify its history with the max_count, which wasn't the intended behavior.

In the case of BitLocker, it's indeed an error because the package does use if_changed , but... since it also uses rsa_encrypted_data_str, it gets updated every time because rsa_encrypted_data_str is encrypted differently each time. It's definitely an error in the package; we need to look into improving it.

For example, we could implement a max_count on the server side, but not one decided by the client.

Re: Problem of audits overloading the database

Published: May 7, 2026 - 7:54 AM
by Esberard
Yeah, a server-side implementation would be perfect.

As for BitLocker, I'll let you keep us posted.

Re: Problem of audits overloading the database

Published: May 26, 2026 - 11:14
by Esberard
Hi Simon,

do you have any idea when this patch will be released?

Thanks a lot,

Rémy