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
查看更多关于ElasticSearch突然采集不到日志问题解决分析的详细内容...