V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
fatpower
V2EX  ›  Elasticsearch

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

  •  
  •   fatpower · 177 天前 · 856 次点击
    这是一个创建于 177 天前的主题,其中的信息可能已经有所发展或是发生改变。
    集群 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 写入失败的情况,可能是数据量比较小。
    有大佬遇到过这种类似问题吗?可能会是哪些原因?
    4 条回复    2021-11-23 12:53:12 +08:00
    redial39
        1
    redial39  
       177 天前
    2c4g 的话,堆配置就是 2g,默认的 40%就是将近 800m,800m 在分片分配种很容易出现错误,特别是 monitoring 这种 index 里.按你说的 3 个节点都使用 metricbeat,如果不关闭 system 模块,每天可以产生将近 1.5g 或者更大的分片,不管你怎么调整,都是会出错的
    所以,总结一下就是....机器太烂了
    fatpower
        2
    fatpower  
    OP
       177 天前
    @redial39 确实机器比较烂哈哈,准备升级。另外 40%这个是什么设置,麻烦告知我去了解下,感谢~
    redial39
        3
    redial39  
       177 天前
    @fatpower emmm..是我理解错了,你不是查询的时候出问题..我以为是查询报错,40%是 indices.breaker.fielddata.limit...你的情况,建议查一下集群的线程情况 /_cat/thread_pool , 由于堆很小.也可能引发高频 fullgc 导致大量 io,分片分配达到了最大尝试次数,所以...结论还是不变 233
    julyclyde
        4
    julyclyde  
       176 天前
    听 lz 的描述,似乎对那个 node 有些意见啊
    如果真的确认故障和具体 node 有关联关系,那可能还需要进一步调查
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2981 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 14:14 · PVG 22:14 · LAX 07:14 · JFK 10:14
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.