Linux环境下ElasticSearch索引管理实战之shell脚本

一、问题背景

       昨天还好好的，今天一大早就发现ESB服务器的日志看不了了，日志存储使用的是elasticsearch8.1.2,故事从这里就开始了！

进入ES的服务器df -h查看/目录已用100%,并且此时应用中集成es索引管理的页面也查看不了了，不能进行前端删除操作！

二、解决思路

2.1、猛操作

      问题出现了，导致测试业务不能正常使用，如何快速的让es恢复可用状态是当务之急，于是第一时间去服务器删除了其他应用的日志文件，让/目录的使用率<100%，然后再去应用中集成es的索引管理页面进行删除之前的索引，一番操作猛如虎后业务恢复了。

2.2、平静后的可能操作

    当时只是应用中查看日志的列表不能用了，并没有通过es自带的api进行尝试删除，因为磁盘满了可能只是不能写里面数据，api是否还能正常使用？这个只是一个假想，砖还很烫手，就不过多尝试了。

三、思考和反思

     一切问题不是偶然，有了那就是你考虑的不周全。业务不能停，日志肯定也是要记录的，这个问题必须避免在生产环境发生！于是便去问了DeepSeek,如何定时的删除es的索引文件？将得到的回复总结成以下三种方法：

3.1、使用索引生命周期管理（ILM）

适用版本：Elasticsearch 6.6 及以上。
优点：原生集成，无需外部工具，自动化程度高。

缺点（个人理解）：这种方式还需要了解以下环节如何做：创建生命周期策略、绑定策略到索引模板、验证策略生效、手动管理旧索引，过程比较繁琐。

3.2、使用 Curator 工具

适用版本：所有 Elasticsearch 版本
优点：灵活性强，支持复杂过滤条件（如磁盘使用率、文档数）。

缺点（个人理解）：这种方式需要安装第三方工具，生产环境实现起来麻烦。

3.3、使用Linux原始shell脚本

适用版本：所有 Elasticsearch 版本
优点：灵活性强，想怎么办自己去想。

四、使用Linux原始shell脚本定时删除ES索引实战

可以说这种是最笨的方法，但是容易理解，几句话理解一下；

1. es本身有自带有api，如新建索引、查找索引，删除索引的方法，并且支持curl方式调用
2. linux服务器已经装了curl,可以把curl写入到shell脚本
3. linux支持配置原生定时任务crontab
4. linux支持crontab脚本写入到日志文件

综上，从执行到监控的一条龙服务已经打通了，直接贴上auto_delete_es.sh的脚本如下：

前提是es的索引文件命名是按照es_index_202501、es_index_202502这样的规则命名的。

now_date=$(date);
month1=$(date -d"-9 months" +%Y%m);

echo -e "\n"
echo -e "\n$now_date根据$month1模糊匹配批量删除索引开始==================begin"
echo -e“$now date 1、开始删除es_index_$month1索引"
curl -X DELETE -k -u es-username:es-password "https://ip:9200/es_index_${month1}";
echo -e "\n$now_date 模糊匹配批量删除索引操作结束========================end"

脚本关键解释：

now_date=$(date); --定义当前日期，输出日志中的操作时间时使用
month1=$(date -d"-9 months" +%Y%m);--定义索引关键字，如202405

curl -X DELETE -k -u es-username:es-password "https://ip:9200/es_index_${month1}";--根据索引关键字拼接索引名称，根据名称调用es的api接口进行删除操作。

crontab -e设置liinux定时任务,如下：

30 2 * * *  /es/auto_delete/auto_delete_es.sh >> /es/auto_delete/auto_delete_es.log

需要注意的是>>是向日志文件的最后面进行追加,>是清空原有内容，注意使用>>，这样才可以看到历史日志。

运行效果如下：