ElasticSearch突然采集不到日志问题解决分析
目录
- 0-前言
- 1-解决
- 2-延展
0-前言
组内同学反馈,kibana上最新的k8s日志看不到了。由于我们是采用elk(elastic search+logstash+kibana)的方式下部署日志采集系统,其中logstash以Deamonset方式部署到k8s的每一个node节点上,先去查看logstash的pod日志,发现:
"reason": "Validation Failed: 1: this action would add [2] shards, but this cluster currently has [999]/[1000] maximum normal shards open;"
可以看到,出错关键词是:maximum normal shards open.
1-解决
查阅资料发现,ES7版本以上,默认的最大分片数是1000, 所以最直接的解决方案就是增大ES的maximum shards:
PUT /_cluster/settings { "transient": { "cluster": { "max_shards_per_node":10000 # 这里可以修改 } } }
经过测试,kibana上可以重新展示最新的log信息。
2-延展
虽然现象问题解决了,但是本质问题依旧存在。
思考几个问题:
- shard能达到1000,那未来是不是会到达10000,导致出现同样的问题?
- 为了避免这样的问题再次出现,那就要控制shard的数量,那么shard的数量和什么有关系?
- 如何控制shard的数量?
首先,回答第一个问题,先要搞清楚,什么是shard?
- 分片是 Elasticsearch 在集群中分发数据的关键。
- 把分片想象成数据的容器。文档存储在分片中,然后分片分配到集群中的节点上。当集群扩容或缩小,Elasticsearch 将会自动在节点间迁移分片,以使集群保持平衡。
- 一个分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分。
- 这类似于 MySql 的分库分表,只不过 Mysql 分库分表需要借助第三方组件而 ES 内部自身实现了此功能。
- 默认情况下,一个索引被分配 5 个主分片
可以看到,分片的数量和索引的数量是成正比的,也就是说索引越多,分片越多;再结合我们ES的实际配置,索引命名方式:环境+日期,环境是固定的,但是日期是每天增加的,那么索引每天都会增加,也就是说分片的数量也会随着时间推移,逐日增加,直到达到最大索引。
所以,针对第一个问题,即使最大分片数是10000,也会出现同样的问题。
那么如何控制shard数量呢?
其实控制shard数量,就是控制索引的数量,控制索引的数量,就是控制保存的log的数量,而log的数量可以通过控制保存的日志有效期天数来决定。
那么,问题转换为:ES如何只保存固定时间段内的日志数据?
两个方案:
- 通过API接口调用
curl -H "Content-Type: application/json" -X POST -d '{"query":{"range":{"@timestamp":{"lt":"now-7d","format":"epoch_millis"}}}}' http://localhost:9200/*/_delete_by_query?conflicts=proceed # 这里根据默认的时间来作为查询的时 间字段,也可以是自定义的, now-7d保留7天的数据
- 通过ES官网工具curator
编写action.yml
actions: 1: action: delete_indices description: "delete index expire date" options: ignore_empty_list: True timeout_override: disable_action: False filters: - filtertype: age source: name direction: older unit: days # 可选days,weeks,months unit_count: 60 #保留最近60天 timestring: '%Y.%m.%d' #这里是跟在索引logstash-后面的时间的格式
加入到crontab定时器即可。
以上就是ElasticSearch突然采集不到日志问题解决分析的详细内容,更多关于ElasticSearch采集不到日志的资料请关注我们其它相关文章!
赞 (0)