Beat.db grows to 12G Bytes in windows

Elastic Stack Beats
1

I installed auditbeat in windows (with the windows package). part of the configuration file is as following

# =========================== Modules configuration ============================
auditbeat.modules:

- module: file_integrity
  paths:
# ========== config paths start ==========
  - c:\
# ========== config paths end ==========

With file_integrity module enabled and I put the whole "c:" in the path, and at same time, there's a software is keeping writing log in a folder under "c:". The beat.db file grows fast. It reaches 1G Bytes within 12 hours and we have another machine has already went to 12G Bytes.

For me it looks like a bug. beat.db is saving some state informations, it shouldn't be that big.

I'm using auditbeat 8.5.3

Anyone else has ever met similar issue? Any idea to fix it or have any quick workaround for it?

Thanks!

2

Not sure if this is really a bug, the beat.db file is a bolt db file where auditbeat/elastic agent will store the filename and the hash for the file content, since you configured the path to be C:\ and it looks like that you also configured it to be recursive it will monitor every single file created, updated and deleted on your system, this alone can generated a lot of entries in the local db file.

But you said that in the same server you also have a software writing logs, this could also increase the number of entries in the local db file.

The beat.db size will depend on the number of monitored files, if you are running it on a server where you write/change/delete a lot of files I would expect its size to grow.

It may also be a bug, but in this case you need to replicate this issue on a newer version as 8.5.3 is more than 1 year old and there were a lot of changes in beats since it was released, it does not make much sense to try to troubleshoot an old version like this for a bug that may be already solved.

3

I recently had the same problem on Auditbeat Linux. The beat.db file reached 16GB. I'm using Auditbeat 8.13.2 in Oracle Linux 7.9. I did the same installation process on similar servers and only saw this behavior in one of them. The auditbeat installation is monitoring recursively a lot of subdirectories

Server infos:

NAME="Oracle Linux Server"
VERSION="7.9"
ID="ol"
ID_LIKE="fedora"
VERSION_ID="7.9"
PRETTY_NAME="Oracle Linux Server 7.9"

Kernel: 3.10.0-1160.41.1.el7.x86_64