Wazuh Indexer High Disk Usage

[Mr VR]

Hi Team,

I have been recently checking disk space in the wazuh installed server. I found that wazuh-indexer directory consumes 1.3T.

I request you to help in minimizing the wazuh disk space in thsi wazuh-indexer directory.

Regards,

Vignesh

[Alejandro Ruiz Becerra]

Hi Vignesh,

Which version of Wazuh are you using?

We highly encourage implementing ISM policies for the automatic rollover and removal of old data and indices. You can find the relevant documentation here: https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/index-lifecycle-management.html

Please note that ISM policies apply automatically to indices created after the policy is established. For existing indices, you will need to apply the policy manually.

Regards,
Alex

[Mr VR]

Hi Alex,

I'm using wazuh v.4.14.6

I request you to help in manually deleting the indices directory.

Regards,

Vignesh

[Alejandro Ruiz Becerra]

Do not remove the indices directory. Follow the documentation shared previously to implement an ISM policy to remove old data and indices.

[Mr VR]

Hi Alex,

Wazuh-archives-* is consuming more disk space compared to other indices. So I have planned to disable archives in filebeat and delete wazuh-archives-* directory.

Regards,

Vignesh

[Alejandro Ruiz Becerra]

That's a good idea as well

[Francisco Sousa]

Hi Vignesh,

One thing about that last step, from your own ls -lrth: the directories under nodes/0/indices are index UUIDs, not index names. There is no directory called wazuh-archives-* on disk, so there is nothing for that pattern to match. Picking one by eye means picking an index you cannot identify, and the cluster keeps its own record either way: the metadata stays in cluster state, so the index comes back red rather than gone.

Where the names do exist is the API. In Dashboards, Index Management → Indices, filter for wazuh-archives-*, select and delete. That also covers the gap Alex flagged: ISM only governs indices created after the policy, so for the 1.3T you already have, either delete those indices directly or use Apply policy from the same screen, which attaches it to existing ones.

One thing that catches people out: turning archives off in Filebeat stops them being indexed, but if logall_json is still enabled in ossec.conf, the manager keeps writing archives.json locally. The growth moves from the indexer to the manager instead of stopping. Worth checking both ends.

And one part that is not about disk at all: wazuh-archives-* holds everything that arrived, whether or not it matched a rule, which is what wazuh-alerts-* does not do. Dropping archives is a fair call on a 1.3T box, but it is a retention decision rather than a storage one: what it really sets is how far back you can investigate something that did not alert at the time. Worth deciding on purpose rather than under disk pressure.

Francisco Sousa — Systems in Production, systemsinproduction.substack.com