Understanding wazuh capabilities

[Aman Choudhary]

Hi Team,

First of all, thank you so much for putting so much effort you have put in this awesome product.

I have a few doubts related to wazuh-server capabilities:
1. Is no. of an agent one wazuh-server can hold/receive data depending upon RAM or vCPU?
2. How many agents I can get to connect with 1 wazuh-server with 1 vCPU? What will be the RAM required to server these agents?
3. If my previous question is unclear, I want to rephrase how many vCPU & RAM are required in one server to connect/receive data from 1000 agents?
4. What is the limit of vertical scaling wazuh? Let's say, can I have one server of 24 vCPU and will it be able to get the data? (I know it's better to have 3 servers of 8vCPU in a cluster than 1, but just wanted to know the max vCPU that is optimal for the wazuh server)?
5. If I stop taking logs ingestion in my wazuh-server (master node), what is the maximum number of registration/authentication requests it can serve?

Thank you for your time in answering these questions. I am trying to get an optimal number of agent vs wazuh-server calculation to serve my organization better.

Thanks,
Aman Choudhary

[Cedrick Foko]

Hello Aman,

Thank you for using Wazuh.
Regarding the Wazuh server hardware requirements:

1. Yes, the number of agents a wazuh-server can manage depends on the RAM and number of vCPU.
2. The minimum hardware for a wazuh-server is 2GB of RAM and 2vCPU. It is recommended to use at least 4GB RAM with 8 CPU cores.
   You can find more information in our documentation: https://documentation.wazuh.com/current/quickstart.html#requirements
3. To manage up to 1000 agents with a single wazuh-server, I'll recommend using at least 32 CPU cores and 64 GB RAM.
4. The vertical scaling doesn't really have a limit. However, as you said, it is recommended to use multi-node deployment for load balancing.
   Please note that the wazuh-indexer uses a Java Virtual Machine for its tasks. If the total memory required for the indexer operations is greater than the memory allowed to the JVM, some operations will be aborted no matter how much RAM or CPUs you have.
5. You don't need to stop ingesting logs to proceed with new registrations.

I hope you find those answers helpful. Please don't hesitate to ask if you have any other question or doubt.

Regards,

[Aman Choudhary]

Hi Cedrik, 

Thank you for your quick reply.

Please note I mean wazuh-manager only when I say wazuh-server.

The issue I have with quickstart is "Following this quickstart implies deploying the Wazuh server, the Wazuh indexer, and the Wazuh dashboard on the same host. ".

I am deploying distributed system. I am not worrying about wazuh-indexer right now. 

32 vCPU & 64 GB RAM for 1000 agent on wazuh-manager without wazuh-indexer and wazuh-dashboard is very resource consuming, I think.

Please correct me if I am wrong. 

Can you have a look at this link and tell me if it make sense?

remoted doesn't scale vertically · Issue #3008 · wazuh/wazuh · GitHub

[Cedrick Foko]

Hello Aman, 
Those specifications are not really fixed. In fact, the hardware resources needed to manage 1000 agents highly depends on my factors such as the amount of data generated by the agents, the integrations, the network bandwidth.  Generally, a server with higher RAM and CPU resources can handle more agents.

Basically, a server with 8 CPU and 32 GB RAM will be able to connect 1000 agents but smooth operations cannot be guaranteed. 

Regarding the vertical scaling, the issue related with the TCP session was fixed in Wazuh v3.9.0:  Optimize network performance in Remoted · Issue #1908 · wazuh/wazuh (github.com)

I hope this helps. Please let me know if you have any other question.

[Miguel Casares]

Hello Aman,

I would like to add some things to the previous comments:

We don't have a fixed limit for the number of agents that a server can hold and this highly depends on the OS, the EPS generated, and the type of log. In that sense, 16GB and 8vCPU should be enough to hold an average generation of 1000 agents. Additionally, we always recommend rolling out agents, and if the Wazuh manager starts to drop events, adding more nodes to the infrastructure to balance the load. What's more, Wazuh scales better horizontally than vertically so it will leverage better if you mirror a Wazuh manager with the same specs than doubling the resources of the current one.

Having said so, if you have the number of EPS generated we can recommend an architecture for your case.

I hope this helps. Let us know if you need anything else,

Miguel

[Aman Choudhary]

Hi Miguel & Cedrick, 

Thank you for taking out some time to answer my questions.

Let me share my assumptions with you. Keeping HA proxy and Network limitation aside.

Let's say 1 vCPU and 2 GB RAM can connect 100 agents, if we say 1 agent can generate 500 EPS then the server will be able to ingest 50,000 EPS max. 

Doubt : Can we ingest 50,000 eps with 1 vCPU and 2 GB RAM? 

 

If I assume the ideal vertical size of a server to be in a cluster is 8 vCPU and 16GB RAM. This server should be able to cater 800 agent, ingest 4,00,000 logs per server.

Doubt: Is this assumption true?

Having this in a cluster of 1 master and 2 worker node, can this system handle 2400 agent, and ingest 12,00,000 EPS? 

Doubt: What is the max number of EPS 1 server with 8 vCPU and 16GB RAM can handle?

Thanks in advance, 

Aman Choudhary

[Aman Choudhary]

Hi All, 

I have found some similar articles: 

Hardware specs by PSanchezR · Pull Request #202 · wazuh/wazuh-documentation · GitHub

Can someone please help me in understanding these benchmark for latest wazuh-server/agent?

[Cedrick Foko]

Hello Aman Choudhary,

Considering the number of EPS only, your mathematical assumptions are correct, but I strongly believe you cannot manage 100 agents with 1 vCPU.

As Miguel explained before, we don't have any fixed limits for the number of agents that a server can hold. Even with a specific number of EPS per agents, the type of log will have an impact on the manager's performance due to the decoding process and rules triggering.

As we don't have a fixed number of agents, we neither have a fixed number of EPS that a manager can hold.

Regarding the article, it just provides recommendations for hardware specifications but does not contain any fixed limit regarding the number of agents or EPS. The analysis is done for the agent side only, not the manager.

I hope this clarifies. Please don't hesitate to ask if you have any other question or doubt.