ES定时清理索引
ES 定时清理索引
ES会将索引存放在内存中,以加速查询性能,但如果长期将使用不频繁的数据放入内存,将会浪费我们的一些资源,下面先举例子一个由于无用数据过多导致的问题
自动清理脚本
#!/bin/bash###################################
#删除早于十天的ES集群的索引
###################################
function delete_indices() {comp_date=`date -d "10 day ago" +"%Y-%m-%d"`date1="$1 00:00:00"date2="$comp_date 00:00:00"t1=`date -d "$date1" +%s` t2=`date -d "$date2" +%s` if [ $t1 -le $t2 ]; thenecho "$1时间早于$comp_date,进行索引删除"#转换一下格式,将类似2017-10-01格式转化为2017.10.01format_date=`echo $1| sed 's/-/\./g'`curl -XDELETE http://127.0.0.1:9200/*$format_datefi
}curl -XGET http://127.0.0.1:9200/_cat/indices | awk -F" " '{print $3}' | awk -F"-" '{print $NF}' | egrep "[0-9]*\.[0-9]*\.[0-9]*" | sort | uniq | sed 's/\./-/g' | while read LINE
do#调用索引删除函数echo "delete indexes..."delete_indices $LINEecho "deleted success"
done
不清理的危害
我有一个自己的服务器,部署了一些常见的中间件docker容器,通过 fluentd 将他们的日志输出到 ES中,在 kibana 中进行展示。
有天手机收到邮件告警,说ES占用CPU异常(自己整的docker监控,对自己部署的容器进行了监控与告警)。
于是到 Grafana 中查看,发现ES的CPU占用开始尖刺形而后长期过高,猜测是GC导致的。

登录服务器查看ES的GC日志,如下:频繁触发GC,可回收垃圾较少,且占用时间过高(5s)。

而正常应该是这种,偶尔一次young GC,年轻代每次回收约90%的垃圾

因为我服务器配置较低,只能给ES很少的资源,限制了其内存,当因为索引过多,内存达到上限后不断触发GC(可以看到基本每两个安全点都要触发一次GC),由于JVM认为他们是不能回收的,故每次基本不会回收东西,导致频繁触发,我这里使用的是ES默认CMS 垃圾回收器,CMS垃圾回收器在识别垃圾时,会扫描JVM堆空间中的对象,这部分会占用较多CPU。
既然找到了根本原因(频繁触发GC),那就要对症下药,把无用垃圾的干掉,将CPU占用降下去。
进入ESHD,发现索引数量确实有点多,内存占用达到限定值。
进入 kibana,将无用的索引先手动清理如
DELETE /fluentd.*.202007*
删掉过旧的日志索引,清理后再到grafana查看。

为了更好的避免该问题,需要定时清理ES中无用的索引。这里为了省事,写了一个脚本,在文章首部。
总结
因为没有特别重要的服务,故没及时清理与优化,旧的日志太多,2个月前都有,导致ES中无用索引较多,导致频繁GC,导致CPU占用过高。
这里还有其他几个点可以探索,为什么是早上8点开始有"着火"的趋势?
- 每新过一天,fluentd 都会为每个采集的容器生成新的日志索引,可以看到其实每天的早上8点都有上升的趋势。
- 差8小时?时区原因(+8时区)

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场,不承担相关法律责任。如若转载,请注明出处。 如若内容造成侵权/违法违规/事实不符,请点击【内容举报】进行投诉反馈!
