本篇内容介绍了“ElasticSearch突然采集不到日志问题怎么解决”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
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突然采集不到日志问题怎么解决”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注编程网网站，小编将为大家输出更多高质量的实用文章！
