Curator removes kibana aliases even when filter is configured

I'm using elasticsearch and kibana 7.1.1 and curator 5.7.5.

Latest versions of elasticsearch (I think since 6.7 are using an alias .kibana which creates .kibana_1, .kibana_2,....)

From this page it seems I thought that elasticsearch-curator 5.7 takes care of all the aliases (kibana_1 ,...) using just the filtertype: kibana):

However, I'm not sure that it does that. I've noticed that the .kibana_1 gets removed even if filtertype:kibana is configured in curator.
See below details:

My curator yaml rules files includes always to exclude kibana (which for I mean to ignore all alias of .kibana, .kibana_1,.....) with this config:

- filtertype: kibana
  exclude: True

However, I'm seeing that the .kibana_1 index is being deleted, see the following logs in elasticsearch:

[2019-06-23T01:49:50,370][INFO ][o.e.c.r.a.AllocationService] [helsinki-mgmt] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[.kibana_1][0]] ...]).
[2019-06-23T02:14:18,201][INFO ][o.e.c.m.MetaDataMappingService] [helsinki-mgmt] [op-2019.06.22/vsN6FqBjRHGV0-eVvsuCqg] update_mapping [_doc]
[2019-06-23T03:00:01,530][INFO ][o.e.s.SnapshotsService ] [helsinki-mgmt] snapshot [es_backup:curator-20190623030001/SYOYPbTLT8SOVk0v6HE11A] started
[2019-06-23T03:02:09,876][INFO ][o.e.s.SnapshotsService ] [helsinki-mgmt] snapshot [es_backup:curator-20190623030001/SYOYPbTLT8SOVk0v6HE11A] completed with state [SUCCESS]
[2019-06-23T03:02:11,772][INFO ][o.e.c.m.MetaDataDeleteIndexService] [helsinki-mgmt] [op-2019.06.21/qZmmpTebSgWcRwkoSz9SLw] deleting index
[2019-06-23T03:02:11,774][INFO ][o.e.c.m.MetaDataDeleteIndexService] [helsinki-mgmt] [.kibana_1/X4iUFJj4R02FUFqKhUYXWA] deleting index
[2019-06-23T03:02:11,775][INFO ][o.e.c.m.MetaDataDeleteIndexService] [helsinki-mgmt] [ins-2019.06.22/R1kJPN0CRSO4nLwz6Cg7uw] deleting index
[2019-06-23T03:02:14,671][INFO ][o.e.c.m.MetaDataCreateIndexService] [helsinki-mgmt] [op-2019.06.22] creating index, cause [auto(bulk api)], templates , shards [1]/[1], mappings

After this, there's not .kibana index anymore.
Not sure yet if this is reproducible always.

Has somebody seen the same thing?

thanks for your work in curator @theuntergeek, I believe this is a bug with curator 5.7 (unless this is by design :slight_smile: )
From what I see, this happens everytime with elasticsearch 7.x since it always creates .kibana_[number] indices and the .kibana alias.

As a workaround to this issue, use filtertype: alias (instead of kibana) and aliases .kibana with curator.

Suggestions? Thanks.

Sorry for the delay. I've been on vacation.

The kibana filter is indeed out of date and could use some updating. In the meanwhile, it's recommended to use the alias filter with the .kibana alias, and also use a pattern filter to exclude system indices starting with . as needed.

Thanks @theuntergeek for confirming!

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