/var/ossec/queue/db overload

[Emar Flix]

Hello,

I am running a Wazuh cluster and in my cluster there are 4 manager, 3 indexer and 1 dashboard nodes and approximately 1900 Windows agents connected through a load balancer.

Each manager node has a /var/ossec/queue/db directory, and this directory is continuously growing on all nodes. Currently, each /db folder is already around 90–95 GB and keeps increasing over time, eventually filling up the storage.

Could you please help clarify:

• Is this expected behavior for the queue/db directory in a multi-manager cluster?
• What is the recommended way to control or limit the growth of this directory?
• Are there any known issues or configurations that could cause excessive accumulation of data in /var/ossec/queue/db?
• Should this directory be periodically cleaned, or is there a built-in mechanism that should handle this?

Any guidance or best practices for managing storage usage in this scenario would be appreciated.

Thank you.

[Victor Carlos Erenu]

Hello Emar

Wazuh DB space consumption depends heavily on the Wazuh version and the features you're using.

I need you to clarify some of your environment's configurations:
- What version of Wazuh are you using?
- What deployment method are you using? (Package installation, Docker, Kubernetes)
- Which Wazuh features are you using to monitor your agents? If you could attach your ossec.conf configuration file, removing all sensitive system information, that would be very helpful.

[Emar Flix]

Hello Carlos,

1. My Wazuh version is 4.14.3
2. It is package installation
3. I attached ossec.conf file

Victor Carlos Erenu yazdı, 16 aprel 2026, cümə axşamı, 19:06:56 UTC+4:

[Victor Carlos Erenu]

Hello Emar

The growth of the manager database is usually associated with agent configurations, specifically, with features like FIM, syscollector, etc.

I need you to send me the agent.conf file for your agents so I can determine if the configurations are the cause, since the growth of the managers depends on the growth of the agent databases.

If the configurations are OK, the other alternative is to increase the number of managers handling the agents. You have a fairly large number of agents, and the manager database stores all the information of the agents they handle, so increasing the number of managers distributes that resource consumption across more nodes.

[Emar Flix]

Hello, Carlos

Thank you for the explanation. It is possible that the configurations are contributing to the growth, however, I would like to share some additional context.

Currently, we are receiving approximately 20 million archives and 500,000 alerts per day. In my opinion, this number should actually be higher, but the queue is limiting the intake — so the growth we are seeing may not yet reflect the full load we expect.
With that in mind, I have a few questions:
1. Is there a way to increase the queue capacity so we can handle a higher volume without bottlenecks?
2. Will the database continue to grow indefinitely at this rate, or does it stabilize at some point?
3. As a temporary workaround, would it be advisable to periodically clean the database — for example, once a week — to keep the size manageable?

Victor Carlos Erenu yazdı, 17 aprel 2026, cümə, 17:49:40 UTC+4:

[Victor Carlos Erenu]

Hello Emar

About your questions:

1. In local_internal_options.conf, we have:
analysisd.event_queue_size: Size of the internal queue between remoted and analysisd. If events arrive faster than they are processed, they are queued here. If the queue fills up, events start being discarded. Watch out for RAM usage.

2. It shouldn't, but it depends on the configuration. For example:
syscollector should eventually stabilize once all vulnerabilities have been stored. Changes from then on should only be new vulns or solved vulns.
Finally, if new files were continuously created in monitored directories, it could grow uncontrollably. Review the configuration.

3. It's not a good idea. Furthermore, the agents, with their synchronizations, would fill it up again.

[Emar Flix]

Hi, Carlos

I think is will help me:

<syscheck> <disabled>no</disabled> <scan_on_start>no</scan_on_start> <!-- Periodic scan yox --> <frequency>0</frequency> <!-- Scheduled scan yox --> <!-- Yalnız realtime izlə --> <directories realtime="yes" restrict=".docx$|.xlsx$">D:\*\Desktop</directories> <directories realtime="yes" restrict=".docx$|.xlsx$">D:\*\Documents</directories> <directories realtime="yes" restrict=".docx$|.xlsx$">D:\*\Downloads</directories> </syscheck>

beacuse why we store all logs on /db? I think we only need last changes.

Victor Carlos Erenu yazdı, 21 aprel 2026, çərşənbə axşamı, 22:29:20 UTC+4: