背景
有一天收到告警，显示用于存储日志的es集群磁盘使用率超过了85%，因此登陆kibana进行一番查看，发现该集群有很多几个月之前的索引，直接DELETE filebeat-7.8.0-2021-*一把把所有的2021年的索引都清理掉，结果一看傻眼了，集群没索引了，很快创建出了一个名为filebeat-7.8.0的索引继续写入，这个索引名称是被删除的索引名如filebeat-7.8.0-2021.12.21-000001的别名，现在filebeat-7.8.0成为一个实体索引，后续索引也没法滚动了，ILM也执行不下去了。
如何解决
因为我们日志采集的方式是filebeat（版本7.8）采集日志直接发送到es，filebeat会自带一个ILM策略（默认开启），在首次启动时会创建这个名为filebeat的ILM策略：
这个策略比较简单，只有一个Rollover Action，也就是在索引超过50GB或者创建时间超过30天就触发滚动，哪个条件先达到就触发。问题就是我们的日志量并不大，最近一次创建的索引是2021年12月25号创建的，并且没有触发滚动，直接一把把2021年的索引删除掉之后，当前集群没有正在写入的索引了filebeat写入时实际上是通过别名"filebeat-7.8.0"进行写入，在索引删掉之后后续es又自动创建了名为"filebeat-7.8.0"的索引进行写入。
因为我们还是需要对索引进行滚动的，现在别名成了实体索引，所以必须解决这个问题。
解决方式1
如果日志本身不是很重要的话，可以先把action.auto_create_index(动态配置)关掉，禁止在bulk写入时如果发现索引不存在就自动创建索引，然后把"filebeat-7.8.0"索引删除掉，最后重启一台filebeat，再次生成如filebeat-7.8.0-2022.01.21-000001这种带滚动后缀000001的索引。
解决方式2
如果不想重启filebeat，也不想把已有的"filebeat-7.8.0"索引删除掉，此时可以借助于default_pipeline进行索引重定向，把写入到"filebeat-7.8.0"索引的数据重定向到新的可滚动的索引进行写入：
- 修改filebeat-7.8.0索引模板，配置滚动别名为filebeat-7.8.0-1
- 创建新的可滚动的索引并设置别名
// 索引名称为filebeat-7.8.0-1-{now/d}-000001 , 使用URI编码:
PUT %3Cfilebeat-7.8.0-1-%7Bnow%2Fd%7D-000001%3E
{
"aliases": {
"filebeat-7.8.0-1": {
"is_wirte_index":true
}
}
}
- 创建pipeline
PUT _ingest/pipeline/redirect
{
"description": "_description",
"processors": [
{
"set": {
"field": "_index",
"value": "filebeat-7.8.0-1"
}
}
]
}
- 配置default_pipeline
PUT filebeat-7.8.0/_settings
{
"index.default_pipeline": "redirect"
}
之后索引会写入到filebeat-7.8.0-1-2022.01.21-000001， 并且可以正常以别名filebeat-7.8.0-1进行滚动。
这种方式可以不用删除filebeat-7.8.0实体索引，但是随着时间的推移，当需要清理该索引时，则需要把上述filebeat-7.8.0索引模板中的滚动别名改回为"filebeat-7.8.0"并且把当前正在写入的最新的别名修改为"filebeat-7.8.0", 否则会导致又重新创建出filebeat-7.8.0实体索引（可以通过关闭action.auto_create_index禁止自动创建该索引）。
