wazuh indexer nodes max shards limit

61 views
Skip to first unread message

Fernando André

unread,
Nov 5, 2025, 8:57:45 AM11/5/25
to Wazuh | Mailing List
Hello,

I had seen already a few messages related to this, but they are from 2021 and I believe they are now outdated since wazuh uses now opensearch fork.

This https://groups.google.com/g/wazuh/c/soGE3gcKrpc/m/MqjDg6BGAAAJ from August 2025 as litle information on why the max shards can be increased.

I have a wazuh cluster with 5 indexer nodes, each with 8GB RAM , 4GB RAM JVM Heap
Total disk usage of the cluster is about 780MB. Shards now are at a 4533 shards more or less, nearing 5000 which will total the cluster amount.

This feels like I can increase the number of shards to have more out of the existing setup.
Am I correct?

What can be done?
What additional information do you need to advise here?

GET /_template/wazuh-custom
"refresh_interval": "5s",
        "number_of_shards": "4",
        "auto_expand_replicas": "0-1",
        "number_of_replicas": "0",

/_cluster/health?pretty
{
  "cluster_name": "wazuh",
  "status": "green",
  "timed_out": false,
  "number_of_nodes": 5,
  "number_of_data_nodes": 5,
  "discovered_master": true,
  "discovered_cluster_manager": true,
  "active_primary_shards": 2262,
  "active_shards": 4458,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 0,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 100
}

/_cat/nodes?pretty
100.66.158.19  64 80 2 0.06 0.03 0.02 dimr cluster_manager,data,ingest,remote_cluster_client - wazuh-indexer-0
100.66.142.246 74 81 2 0.02 0.08 0.08 dimr cluster_manager,data,ingest,remote_cluster_client - wazuh-indexer-2
100.66.157.155 78 79 2 0.01 0.03 0.06 dimr cluster_manager,data,ingest,remote_cluster_client * wazuh-indexer-4
100.66.152.100 77 80 4 0.34 0.44 0.38 dimr cluster_manager,data,ingest,remote_cluster_client - wazuh-indexer-1
100.66.137.106 73 81 2 0.16 0.18 0.12 dimr cluster_manager,data,ingest,remote_cluster_client - wazuh-indexer-3



Best regards,

Carlos Ezequiel Bordon

unread,
Nov 5, 2025, 10:16:57 AM11/5/25
to Wazuh | Mailing List

This will mainly depend on your environment and your need to retain old logs.

To add more information to the answer you shared, you can check this guide: https://documentation.wazuh.com/current/user-manual/wazuh-indexer/wazuh-indexer-tuning.html#shards-and-replicas, which explains shards and replicas. Please review it before making any changes.

On the other hand, before modifying the shards, I would recommend checking if you have any log rotation policies applied to reduce the space occupied by old logs. https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/index-lifecycle-management.html

André

unread,
Nov 6, 2025, 7:18:11 AM11/6/25
to Carlos Ezequiel Bordon, Wazuh | Mailing List
Hello,

I have read the documentation and I should say two things:
1. I have 5 nodes, and have 3 shards per indice.
2. I don't have lifecycle policies and right now I do not need them because I have not passe the retention period of the data.

Currently we are using 890 shards per node more or less.

Any sugestions?

Best regards,


--
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/1lRSSbbTgZY/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/850f9457-68f0-4d85-aa50-50fb9c27a1a2n%40googlegroups.com.

Carlos Ezequiel Bordon

unread,
Nov 25, 2025, 10:56:09 AM11/25/25
to Wazuh | Mailing List

Increasing the shard limit is not recommended because it can affect the tool's performance. While you can increase the limit, keep this in mind when making your decision.

Our recommendation is to use an ISM policy and reduce the number of shards instead of increasing it. An ISM policy serves many purposes, not just deletion. If you still need to keep that data, you can simply merge old indexes. For example, instead of having one daily index with three shards each, merge them into one monthly index with one shard, freeing up 3 x 30 - 1 = 89 shards for just one month's data, while still having the information available.

Reply all
Reply to author
Forward
0 new messages