Wazuh Indexer Troubleshooting: Cluster Health, Disk and OOM

The Wazuh indexer is the heaviest component and the most common source of operational pain. This guide walks the standard diagnostic flow used in production.

1. Check cluster health

curl -k -u admin:<password> https://localhost:9200/_cluster/health?pretty
curl -k -u admin:<password> https://localhost:9200/_cat/indices?v
curl -k -u admin:<password> https://localhost:9200/_cat/shards?v | grep UNASSIGNED

• green = OK
• yellow = primaries assigned, some replicas missing (normal on single-node)
• red = at least one primary unassigned (data loss possible)

2. vm.max_map_count

If the indexer fails to start with bootstrap-check errors:

sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" | tee -a /etc/sysctl.conf
systemctl restart wazuh-indexer

3. Disk watermarks

OpenSearch enters read-only mode when disk usage crosses the flood-stage watermark (95% by default). Free space, then clear the read-only flag:

curl -k -u admin:<password> -X PUT https://localhost:9200/_all/_settings \
  -H "Content-Type: application/json" \
  -d '{"index.blocks.read_only_allow_delete": null}'

Long term, set an ILM policy that deletes or rolls over indices on a schedule.

4. JVM heap and OOM

Edit `/etc/wazuh-indexer/jvm.options` and set heap to roughly 50% of system RAM, capped at 32 GB:

-Xms4g
-Xmx4g

5. Unassigned shards

curl -k -u admin:<password> https://localhost:9200/_cluster/allocation/explain?pretty

The explain API returns the exact reason. Common causes: disk full, node missing, allocation filter blocking, mapping mismatch.

6. Read the logs

journalctl -u wazuh-indexer -n 200 --no-pager
tail -n 200 /var/log/wazuh-indexer/wazuh-cluster.log

7. Reinitialize security index

If admin login is broken after a cert rotation, re-run security init on one node:

/usr/share/wazuh-indexer/bin/indexer-security-init.sh

For repeated indexer pain in production, our team can audit your cluster sizing, ILM policies and snapshot strategy, get in touch via contact.