xpack 监控日志 index 写入出错，导致正常写操作耗时高

[fatpower]

集群 3 个节点，都是 2c4g ，机器是 aws 的。es node 节点没有掉线，index 状态都是 green 。
线上监控到写 es 操作耗时高，查看日志报错‘ShardNotFoundException’，显示往 monitoring-es-7-xxxx 的 index 写数据报错。
利用 /_cat/shards 命令查看发现报错 index replica ，docs 、store 都不显示，手动 reroute 把这个 replica 分配到其他 node 报错消失。但是过几天这个监控日志 index 只要分配到之前报错的 node ，就有可能出现日志写不进的情况，但也不是 100%。目前还没有遇到过业务 index 写入失败的情况，可能是数据量比较小。
有大佬遇到过这种类似问题吗？可能会是哪些原因？

[redial39]

2c4g 的话,堆配置就是 2g,默认的 40%就是将近 800m,800m 在分片分配种很容易出现错误,特别是 monitoring 这种 index 里.按你说的 3 个节点都使用 metricbeat,如果不关闭 system 模块,每天可以产生将近 1.5g 或者更大的分片,不管你怎么调整,都是会出错的
所以,总结一下就是....机器太烂了

[fatpower]

@redial39 确实机器比较烂哈哈，准备升级。另外 40%这个是什么设置，麻烦告知我去了解下，感谢~

[redial39]

@fatpower emmm..是我理解错了,你不是查询的时候出问题..我以为是查询报错,40%是 indices.breaker.fielddata.limit...你的情况,建议查一下集群的线程情况 /_cat/thread_pool , 由于堆很小.也可能引发高频 fullgc 导致大量 io,分片分配达到了最大尝试次数,所以...结论还是不变 233

[julyclyde]

听 lz 的描述，似乎对那个 node 有些意见啊
如果真的确认故障和具体 node 有关联关系，那可能还需要进一步调查