xpack 监控日志 index 写入出错，导致正常写操作耗时高
fatpower · 2021-11-22 10:00:06 +08:00 · 1556 次点击这是一个创建于 879 天前的主题，其中的信息可能已经有所发展或是发生改变。
集群 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 写入失败的情况，可能是数据量比较小。
有大佬遇到过这种类似问题吗？可能会是哪些原因？
线上监控到写 es 操作耗时高，查看日志报错‘ShardNotFoundException’，显示往 monitoring-es-7-xxxx 的 index 写数据报错。
利用 /_cat/shards 命令查看发现报错 index replica ，docs 、store 都不显示，手动 reroute 把这个 replica 分配到其他 node 报错消失。但是过几天这个监控日志 index 只要分配到之前报错的 node ，就有可能出现日志写不进的情况，但也不是 100%。目前还没有遇到过业务 index 写入失败的情况，可能是数据量比较小。
有大佬遇到过这种类似问题吗？可能会是哪些原因？
 |
1
redial39 2021-11-22 13:38:04 +08:00
2c4g 的话,堆配置就是 2g,默认的 40%就是将近 800m,800m 在分片分配种很容易出现错误,特别是 monitoring 这种 index 里.按你说的 3 个节点都使用 metricbeat,如果不关闭 system 模块,每天可以产生将近 1.5g 或者更大的分片,不管你怎么调整,都是会出错的
所以,总结一下就是....机器太烂了 |
|
3
redial39 2021-11-22 16:05:33 +08:00
@fatpower emmm..是我理解错了,你不是查询的时候出问题..我以为是查询报错,40%是 indices.breaker.fielddata.limit...你的情况,建议查一下集群的线程情况 /_cat/thread_pool , 由于堆很小.也可能引发高频 fullgc 导致大量 io,分片分配达到了最大尝试次数,所以...结论还是不变 233
|
 |
4
julyclyde 2021-11-23 12:53:12 +08:00
听 lz 的描述，似乎对那个 node 有些意见啊
如果真的确认故障和具体 node 有关联关系，那可能还需要进一步调查 |
Select Language