Maximum normal shards open achived

Hello, I have one node ELK, I know that is not the best solution, but I cannot change that. I put logs to ELK, and every day I have new index for example: alerts-2023-07-23. But after few months of working filebeat showed me error that maximum open shard is achived. Could you explain me what is the best solution in this case. It is possible that I join all of this indexes (one month) to one index?

You could index reindex to one single shard. But in most recent versions, I think that using data streams is much better and efficient.

What is the output of:

GET /
GET /_cat/nodes?v
GET /_cat/health?v
GET /_cat/indices?v

If some outputs are too big, please share them on gist.github.com and link them here.

Thanks for anserw. Unfortunately the problem appear in indexes generated by Wazuh, so probably I don't have possibility to use better option like data stream. It is possible to reindex automatically it every month? Below I attach the output: log.txt · GitHub

Looking at the indices info, you are wasting plenty of resources by oversharding.
You should have only one shard per index instead of 3 sometimes.
Also, some indices are super small which is indeed inefficient.

I'd ask Wazuh to change their settings and use datastreams. But in the meantime, I suppose that wazuh is generating an index template. May be you can change it and set the number of primary shard to 1.

Then you could reindex your data and squeeze them into one bigger index and shard.

It is possible to reindex automatically it every month?

Not automatically, no but you can probably write a simple cron script for that.

May be you can configure Wazuh to use an alias instead of an index by day? And then use the rollover API?

1 Like

I found options to change that in Wazuh (alerts - in pipeline, monitoring and statistics in Wazuh option). Moreover I reindexed this indexes and created one index with past data, new data will be create indexes per month. Also I changed number of primary shards to one.

I am grateful for the help, thank you.

If I think about auto jobs my idea is create job that will join indexes (that now is created per month) to groups that have 50GB of data. It is good idea?

If you have one or a few monthly indices with a single primary shard I would expect the shard count to be managable, so I do not think this is required nor adds much value.

thanks

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.