Distributed Wazuh 4.13 Sizing

[MSS]

Hello everyone, 

I am going to implement Wazuh 4.13 in production environment. 

Requirements: 

EPS= 20,000

Alert Retention/Hot = 90 Days

Archive Log Retention/Cold = 365 Days

Based on this what should be my system architecture and sizing? 

System Requirement: 

Wazuh Server:

No of Node = ?

Ram = ? GB

CPU = ? Core

Storage = ? GB

Wazuh Indexer:

Node = ?

Ram = ? GB

CPU = ? Core

Storage = ? GB

Dashboard:

Ram = ? GB

CPU = ? Core

Storage = ? GB

I have read official documentation, which is based on number of agents. However, I have to calculate the sizing based on number of EPS, which is 20,000. Can you help me to make the sizing?

[Gabriel Diaz Lopez de la Llave]

Hello! 

There's no one-size-fits-all formula for Wazuh deployment sizing since there are many variables you won't know until agents start sending data. Here's the iterative approach I'd recommend:

Start small and scale up: Begin with modest server capacity, then gradually feed in events while monitoring the system. Once you hit around 60% constant resource usage (CPU, RAM, network), increase resources incrementally based on your needs.

Initial setup recommendations depends on the required availability and resiliency, for example:

• Indexer nodes: For production, start with at least 3 indexer nodes distributed across multiple availability zones for reliability
• Wazuh servers: Match this with 3 servers using the same distribution strategy
• Dashboard: A single dashboard is usually sufficient since all data lives in the indexers and servers, though you might want a second one for failover

Capacity starting point for all nodes:

• 8 CPUs
• 16 GB RAM
• Scale up from there to maintain stability, targeting ~60% average usage

Add your data sources gradually over time rather than all at once. This gives you room to monitor performance and adjust capacity as needed. The nature of your events and collection mechanisms will determine whether you need to adjust the number of servers or their individual capacity to properly distribute the load.

After the process, servers might have more capacity than indexers. and usually the dashboard uses less resources than the rest. 

Hope this helps with your planning!

[MSS]

Dear Gabriel ,

Apologies for the delayed response and thank you for your detailed explanation.

I understand your point; however, I’m still unclear about the storage estimation. In my case, the estimated event rate for my environment is approximately 20,000 EPS. I’ve outlined the detailed requirements below for your reference:

Requirements:

• EPS: 20,000

• Alert Retention (Hot): 90 days

• Archive Log Retention (Cold): 365 days

Could you please assist me in calculating the required storage based on these parameters?

[Gabriel Diaz Lopez de la Llave]

Hello! 

You can calculate an estimation  like this:

(20,000 EPS * 90 days * 86400 seconds a day * 0.5 Kb per event ) / 5 compression ratio ~= 15 TB estimated hot storage

The same calculation would apply to the archive log retention. The compression ratio can vary depending on the events themselves and the wazuh indexer exact configuration, it could reach a ratio of 7 or 8 if the environment is homogeneous and the events are of the same types. 

apologies for the delay!

Gabriel

[MSS]

Thank you!

It was a great help.

Small follow-up question:

If I estimate that I need 15 TB of storage to meet my log retention requirements, does this entire storage need to be allocated to the Indexer/indexers only?

Or do I also need to allocate separate storage space for the Manager?

If I have to distribute this space in indexers, should I divide it by the number of indexer nodes?

[Gabriel Diaz Lopez de la Llave]

Hello!

The final destination is the indexer, so that will be the requirement for the indexer cluster, but wazuh server store agents information like keys, states (package list, vulnerabilities database, etc.) so you will need to allocate more storage for the managers.

You can distribute the storage across the indexer nodes. Remember you might need more space for replicas to ensure information availability if a node crashes. Depending on the number of replicas your deployment will tolerate losing indexer nodes.

Gabriel

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/lP-OWauFH78/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wazuh/d45d045e-7edd-4c08-881a-752ffb164fe3n%40googlegroups.com.