0-前言
组内同学反馈，kibana上最新的k8s日志看不到了。由于我们是采用elk（elastic search+logstash+kibana）的方式下部署日志采集系统，其中logstash以Deamonset方式部署到k8s的每一个node节点上，先去查看logstash的pod日志，发现：
|
1
|
"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：
|
1
2
3
4
5
6
7
8
|
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接口调用
|
1
2
|
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
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
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采集不到日志的资料请关注服务器之家其它相关文章！
原文链接：https://juejin.cn/post/7187603949849935929
