Kibana Shrink Index

Elastic Stack Elasticsearch
1

Good morning friends. I am a little new to the Elastic topic. The problem is that in the company we have a Kibana version 7.5.1, I know that the version is old, but for the moment it is impossible to change it. The indexes have grown too much and are taking up a lot of disk space on the server. I have seen that a reduction of the indexes (shrink) can be done, and I have read some information, but I am afraid of doing it wrong and losing information, since it is a production server. Can someone guide me on how I could do the shrink without losing information and with the server active?, or if it is necessary to do it with the server down? Any help would be greatly appreciated. Thank you very much.

Some information:

Indez-Size
Indez-Size1626×1009 174 KB

NODES-1
NODES-12511×400 69.5 KB

SHARDS-1
SHARDS-12516×491 122 KB

INDEX-1
INDEX-12514×423 99.4 KB

I read something on a page like Shrink index API | Elasticsearch Guide [8.17] | Elastic
Where they show some steps on how to shrink an existing index to a new index with fewer primary fragments.

POST /my-index-000001/_shrink/shrunk-my-index-000001

But then there are several steps that confuse me a little. It is not clear to me if following that step by step is very safe.

Maybe there is some tool that simplifies all these steps?

2

I think there is a little confusion here, the shrink API is used to reduce the number of primary shards of an index, it has no relation to the size of the index, it will not reduce the size of an index.

The indices you shared already have one primary shard.

You would the shrink API in the case where you have for example an indice with 3 primary shards and want to reduce to 1 primary shard, the number of primary shards would change, but the size would be the same.

Are you still writing into those indices? Do you update documents on it?

3

Leandro, Thank you very much for your response and you are right, what I need is to reduce the size of the largest indexes, to recover some disk space. These indexes are in write mode and are being updated every moment of the day, since they are monitoring the traffic of some nginx. In some Nginx, some logstash are running that send data to the elastic server, where Kibana is. This elastic server is almost full of disk. That is the situation.
But the idea is not lost information, and i understand that there is a way that "shrink" the index, without lost information.

4

By update I mean if you are using a custom id to update the documents in the index, but from what you described it doesn't seem that.

When you update documents using custom id, the deleted documents will still occupy some space until they are purged, but this does not seem to be your case.

Can you run GET _cat/indices?v in Kibana Dev Tools and share the result?

It seems that you are justing sending the more recent logs into the index, is that right?

From your description your index is just a time series index with logs.

The main issue here is that you cannot free up space without removing data.

I think that best approach would be to change your logstash configurations to write into a new indice and then delete the old ones.

5

No, as far as I know there is not. This guide shows how to reduce the size of indices, but it requires reindexing to optimise mappings, which can not be done to an active index.

I believe you either will need to delete data, which may temporarily increase the amount of disk used if you do not delete complete indices, or exapnd the cluster.

1 Like
6

Leandro, the result is this, there is a lot of indices, but the marked in red is that i want to reduce:

INDICES
INDICES1920×962 197 KB

7

One way to save some space if you are not already doing so is to enable best_compression. This will require you to force merge down to a reasonable number of segments, e.g. 10, but the new segments should shrink in size a bit. I recall seeing a space saving of about 20% or so, but it will depend a lot on the data. The only other way to reduce the size of those indices is to delete data from them.

1 Like
8

Thanks guys for your posts. I'll tell you that I finally solved the issue with 2 queries. One to delete documents by date and then do a "forcemerge" of the index to effectively reduce the disk space.

Delete documents:

POST /index_name/_delete_by_query?conflicts=proceed&slices=auto
{
"query": {
"range": {
"@timestamp": {
"lt": "now-30d"
}
}
}
}

Force merge

POST /index_name/_forcemerge