System Specifications for a 13 million events per day

[Asmit Desai]

Hi Team 

I am planning to have a all-in-one wazuh deployment that is expected to have a traffic of around 13-15 million events in a day. I would like to know what the best system configuration for the amount of log ingestion would be. Currently its assigned 4 cores and 32GB RAM. What are the changes that need to be made? I would like your advice on the same.

Thanks 

[Olamilekan Abdullateef Ajani]

Hi,

13–15 million events per day is about 150–175 EPS on average, but the real sizing should not be based only on the daily event count. You also need to consider peak EPS, retention period, average event size, enabled modules, number of agents/event sources, and the disk performance.

With the current setup of 4 CPU cores and 32 GB RAM, you need to rethink the setup. The RAM may be acceptable for a small all-in-one setup, but 4 cores is likely low for that volume, especially because the same server will run the Wazuh manager, Wazuh indexer, dashboard, and Filebeat.

For sizing, I would evaluate the following:

EPS / peak EPS
13–15 million events per day is around 150–175 EPS average, but peak traffic may be much higher during business hours or during noisy events.
Retention period
How long you keep alerts and archives will decide the disk size. Storage can grow fast too if archives are enabled.
Disk type and speed
Use SSD/NVMe if possible. Indexing performance depends a lot on disk I/O, not only CPU and RAM.
All-in-one limitation
For production, all-in-one is easier to deploy but does not scale so well. If the environment grows, it is better to move to a distributed deployment.

As a general starting point, for larger environments Wazuh manager nodes are commonly sized around 8 CPU cores and 16 GB RAM, while Wazuh indexer nodes may need around 16 CPU cores and 32 GB RAM, depending on ingestion and retention.

Since you want all-in-one, I would not stay with 4 cores. I would consider at least the following:

16 CPU cores
32 GB RAM
Fast SSD/NVMe storage
Enough disk based on retention

If you plan to keep data for a long time, enable archives, or expect high peak traffic, then consider:

32 CPU cores
64 GB RAM
Fast SSD/NVMe storage

To know when the Wazuh manager is hitting limits and experiencing performance issues, monitor these files:

/var/ossec/var/run/wazuh-analysisd.state
/var/ossec/var/run/wazuh-remoted.state

Check for:

events_dropped
discarded_count

If events_dropped or discarded_count increases, it means the manager is not keeping up, and you may need more resources or add manager nodes.

So my recommendation would be, increase the CPU first, use an SSD, calculate disk based on retention, and monitor the Wazuh state files after going live. If the system starts dropping events or indexing becomes slow, then move away from all-in-one and scale horizontally via distributed architecture.

Please let me know if you require further clarification.