有一天收到告警,显示用于存储日志的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"的索引进行写入。
因为我们还是需要对索引进行滚动的,现在别名成了实体索引,所以必须解决这个问题。
如果日志本身不是很重要的话,可以先把action.auto_create_index(动态配置)关掉,禁止在bulk写入时如果发现索引不存在就自动创建索引,然后把"filebeat-7.8.0"索引删除掉,最后重启一台filebeat,再次生成如filebeat-7.8.0-2022.01.21-000001这种带滚动后缀000001的索引。
如果不想重启filebeat,也不想把已有的"filebeat-7.8.0"索引删除掉,此时可以借助于default_pipeline进行索引重定向,把写入到"filebeat-7.8.0"索引的数据重定向到新的可滚动的索引进行写入:
1 . 修改filebeat-7.8.0索引模板,配置滚动别名为filebeat-7.8.0-1
2 . 创建新的可滚动的索引并设置别名
// 索引名称为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
}
}
}
3 . 创建pipeline
PUT _ingest/pipeline/redirect
{
"description": "_description",
"processors": [
{
"set": {
"field": "_index",
"value": "filebeat-7.8.0-1"
}
}
]
}
4 . 配置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禁止自动创建该索引)。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。