0
点赞
收藏
分享

微信扫一扫

ElasticSearch primary shard is not active Timeout问题

环境

运行在CentOS-8上,使用docker-compose部署的elasticsearch:7.14.2,四节点集群。

故障现象

打开kibana管理台--> Stack Monitoring--> Nodes,发现监控信息报错,如下图所示(原图忘记截图了):

点击Index Management管理界面上索引均是正常的,使用docker-compose ps看到容器也是正常running状态。

故障排查

容器服务

登录elasticsearch节点服务器终端,使用docker logs -n 100 es-node01命令获取最新 log 信息:

## 报错提示有很多,这里我重点说明两个
"Caused by: org.elasticsearch.action.UnavailableShardsException: [.monitoring-kibana-7-2024.04.28][0] primary shard is not active Timeout: [1m], request: [BulkShardRequest [[.monitoring-kibana-7-2024.04.28][0]] containing [2] requests]",
...
"Caused by: org.elasticsearch.xpack.monitoring.exporter.ExportException: bulk [default_local] reports failures when exporting documents",
"at org.elasticsearch.xpack.monitoring.exporter.local.LocalBulk.throwExportException(LocalBulk.java:122) ~[?:?]",
"... 28 more"] }

第一个报错通常意味着尝试索引文档到索引中的一个或多个分片时出现了问题。在这种情况下,错误消息中明确指出了是由于.monitoring-es-7-2024.04.28索引的第0号分片(primary shard)没有处于活跃状态导致的。

第二个报错这个错误消息表明Elasticsearch X-Pack监控导出器(exporter)在尝试将文档批量导出时遇到了错误。

这两个信息并没有直接给出报错的根本原因,因为造成它们报错的原因还有很多,我们需要再深入排查下。

ES集群

打开kibana管理台--> Dev Tools,查看上述索引的分片状态:

GET /_cat/shards/.monitoring-es-7-2024.04.28

获取到如下信息:

.monitoring-es-7-2024.04.28 0 p UNASSIGNED
.monitoring-es-7-2024.04.28 0 r UNASSIGNED

当前集群状态(Red):

GET _cluster/stats

执行GET _cluster/allocation/explain?pretty发现:

the node is above the low watermark cluster setting [cluster.routing.allocation.disk.watermark.low=85%], using more disk space than the maximum allowed [85.0%], actual free: [8.168769364810071%]"

这个错误消息说明一个节点的磁盘使用率已经超过了集群的低水位标记(low watermark),即超过了集群允许的最大磁盘使用百分比(在此例中为85%)。

使用df -h命令查看当前系统磁盘使用情况:

Filesystem           Size  Used Avail Use% Mounted on
devtmpfs              16G     0   16G   0% /dev
tmpfs                 16G     0   16G   0% /dev/shm
tmpfs                 16G   17M   16G   1% /run
tmpfs                 16G     0   16G   0% /sys/fs/cgroup
/dev/mapper/cl-root  4.1T  3.8T  339G  92% /

到此,我们查到了引起这次elasticsearch服务宕机的真正原因,我们使用GET /_cluster/settings?include_defaults=true查看下我们集群对于该值的配置信息:

故障处理

这里有两种方式,本次我才用的是方式一即清理+扩容。

清理+扩容

在 kibana 管理台或命令行终端执行清理废弃数据或将数据冷备其他存储上,根据业务需要决定是否对存储进行扩容。

空间释放到集群的低水位标记(low watermark)以下后,无需重启 ES 服务,kibana 管理台监控信息会自动刷新,等待一段时间就能获取到正常监控信息了。

调整集群设置

可以考虑修改集群的磁盘空间水位标记,允许更高的磁盘使用率。这可以通过修改cluster.routing.allocation.disk.watermark.lowcluster.routing.allocation.disk.watermark.high的配置值来实现。不过这样做需要谨慎,要确保在修改这些设置之前进行充分评估。

参考文档

  • 个人技术私库
举报

相关推荐

0 条评论