Kibana multitenant index management

After multiple upgrades, I now have a ton of kibana indices.
For instance, these are just my private ones:

☠ GET _cat/indices/.kibana\*wernli\*
HTTP/1.1 200 OK
content-length: 540
content-type: text/plain; charset=UTF-8

green open .kibana_-460255123_fwernli-6_9 yVU6btb3T5qqFNmAggpVjg 1 1  4 0 149.7kb  74.8kb
green open .kibana_-460255123_fwernli-6_7 RSLHmXyCRlCgskTVqNvOHA 1 1  4 0   140kb    70kb
green open .kibana_-460255123_fwernli_1   -xOkZrODSBa1p5X2VrksRQ 1 1  7 0 156.1kb    78kb
green open .kibana_-460255123_fwernli_3   EgDf-ha6QN-tLdC2EhCOBw 1 1 13 1 368.9kb 184.5kb
green open .kibana_-460255123_fwernli-6_8 LOmwNGkCTz6BSOGQQNHlQw 1 1  4 0   140kb    70kb
green open .kibana_-460255123_fwernli_2   4Z1KBojjQhuoa_bOAtAmnQ 1 1 11 1   361kb 180.5kb

☠ GET _cat/aliases/.kibana\*wernli\*
HTTP/1.1 200 OK
content-length: 132
content-type: text/plain; charset=UTF-8

.kibana_-460255123_fwernli   .kibana_-460255123_fwernli_3   - - -
.kibana_-460255123_fwernli-6 .kibana_-460255123_fwernli-6_9 - - -

Which ones are really used ?
Which ones can I safely DELETE ?

After migration fulfilled, there will be multiple Kibana indices in Elasticsearch: .kibana_-id_tenant-1, .kibana_-id_tenant-2, etc. Kibana only uses the index that the .kibana_-id_tenant alias points to. In your case they are .kibana_-460255123_fwernli_3 and .kibana_-460255123_fwernli-6_9. The other indices can be safely deleted, but are left for the historical record, and to help rolling Kibana back to previous versions. Also, you can delete indices if the related tenant, for example, fwernli isn’t used anymore and you don’t need the data.

It works exactly like the .kibana index migration Upgrade migrations | Kibana Guide [8.4] | Elastic

Thanks! But why are there two aliases _3 and 6_9 ?

SearchGuard (SG) calls the Kibana migration service in order to do the migrations. The last id in the index name is added by the Kibana migration service and it is not part of the SG code.

What versions of the Kibana did you have, in historical order? I guess it was v6.7, v6.8, v6.9, and 7.n where n is an integer from 0 to 9 included. Am I right? Kibana changed the migration implementation in v7. Probably it will change it again soon because it is not good enough. Read this RFC if you want to know more https://github.com/elastic/kibana/blob/master/rfcs/text/0013_saved_object_migrations.md

We’re not yet at 7 in this cluster. It was probably 2.x to 5.y then a few 6.z versions.
So I have to keep both ?

If you don’t think of rollback, you can leave only the indices you have aliases for. In your example they are .kibana_-460255123_fwernli_3 and .kibana_-460255123_fwernli-6_9.

1 Like

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