es集群状态red排查流程

es集群状态red

问题描述

公司有一套kibana日志收集系统，组合方式为filebeat elasticsearch kibana，elasticsearch使用三台服务器组合成集群。近期公司的zabbix服务器持续告警某台服务器cpu使用率在80%以上，
登录服务器首先查看是哪个服务器对cpu占用过多，查看是因为es导致。

排查思路

  1. 针对es集群占用cpu使用率过高问题
# 因es集群仅作为kibana日志收集使用，所以使用es-head首先查看集群状态
  1. 针对es集群red状态问题
# es集群的几种状态green：所有主分片和副本都可用yellow：所有主分片都可用，但不是所有副本分片都可用red：不是所有主分片都可用，这意味着缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。# 查看es集群当前状态（当前集群都在线，没有问题）[root@VM-30-28-centos logs]# curl -s 172.31.30.28:9200/_cat/nodes172.31.30.28 63 96 4 0.02 0.16 0.36 dilm - VM-30-28-centos172.31.30.88 20 98 9 0.32 0.50 0.56 dilm * VM-30-88-centos172.31.30.48 60 97 9 0.91 0.73 0.83 dilm - VM-30-48-centos

疑问：虽然处于red状态，但是集群状态没有问题

# 1.查看系统最大打开文件描述符数是否够用[root@VM-30-28-centos logs]# df -i      # 使用都在百分之一左右，丝毫不影响Filesystem       Inodes  IUsed    IFree IUse% Mounted ondevtmpfs        2030545    346  2030199    1% /devtmpfs           2033272      7  2033265    1% /dev/shmtmpfs           2033272    469  2032803    1% /runtmpfs           2033272     16  2033256    1% /sys/fs/cgroup/dev/vda1       3276800  65778  3211022    3% /tmpfs           2033272      1  2033271    1% /run/user/0/dev/vdb1      32768000 161045 32606955    1% /opt

查看当前健康状态，发现未分配分片数居然达到了三千多，并且集群中所有活跃的分片数和主分片数达成了一致，也就是未分配的都是副本分片，主分片处于活跃状态，
由于灾备原则，主分片和其对应副本不能同时在一个节点上,es无法找到其他节点来存放第三个副本的分片，所以导致了集群处于red状态

但是为什么会出现es无法找到其他节点来存放第三个副本分片呢？

原因如下：

① 副本太多，节点太少，es无法完成分片

​解决方式：1. 减少副本数 2. 增加节点数

② 分片被锁住了

​解决方式： 尝试分配，或者手动分配， 可以指定"accept_data_loss" : true。但这样会导致数据完全丢失。

③ 有节点短暂离开集群，然后重新加入，并且有线程对某个分片做bulk或者scroll等长时间写入操作，等节点重新加入集群，由于分片 lock灭有释放，master无法分配这个分片，
通常/_cluster/reroute?retry_failed=true可以解决问题，如果依然无法解决，可能还有其他原因导致锁住该shard的线程长时间操作该shard无法释放锁（长时间GC?)。 所以有可能是索引过大导致。

# 查看所有索引的状态，大小等curl -XGET 'http://172.31.30.28:9200/_cat/indices?v'

这里的截图并不完整，当时有red状态的索引和yellow状态的索引，这里的解决办法直接将red状态索引删除处理

删除red状态索引方式，但我这里仅作为日志索引，所以影响不大，删除需要结合实际情况考虑

curl -XGET 'http://172.31.30.28:9200/_cat/indices?v'|grep 'red' |awk '{print $3}'|xargs -i curl  -XDELETE  "http://172.31.30.88:9200/{}"

后续查看es-head状态，es集群状态从red转为yellow，删除red索引后个别索引从yellow状态变为green状态

总结：

遇到集群Red时，我们可以从如下方法排查 :

  • 集群层面：curl -s 172.31.30.28:9200/_cat/nodes 或者 GET _cluster/health
  • 索引层面：GET _cluster/health?pretty&level=indices
  • 分片层面：GET _cluster/health?pretty&level=shards
  • 恢复情况：GET _recovery?pretty

有unassigned分片的排查思路 ：

  • 先诊断：GET _cluster/allocation/explain
  • 重新分配： /_cluster/reroute

实在无法分配：

  • 索引重建：

    ① 新建备份索引：

    curl -XPUT ‘http://xxxx:9200/a_index_copy/‘ -d ‘{“settings”:{“index”:{“number_of_shards”:3,“number_of_replicas”:2}}}

    ② 通过reindex api将a_index数据copy到a_index_copy：

    POST _reindex{"source": {"index": "a_index"},"dest": {"index": "a_index_copy","op_type": "create"}}

    ③ 删除a_index索引，这个必须要先做，否则别名无法添加

    curl -XDELETE 'http://xxxx:9200/a_index'

    ④ 给a_index_copy添加别名a_index

    curl -XPOST 'http://xxxx:9200/_aliases' -d '{"actions": [{"add": {"index": "a_index_copy", "alias": "a_index"}}]}'

    translog总结

    • translog在节点有问题时，能够帮助阻止数据的丢失

      设计目的：

      1、帮助节点从失败从快速恢复。

      2、辅助flush。避免在flush过程中数据丢失。

    插播一下，translog的知识

    • 我们把数据写到磁盘后,还要调用fsync才能把数据刷到磁盘中,如果不这样做在系统掉电的时候就会导致数据丢失,这个原理相信大家都清楚,elasticsearch为了高可靠性必须把所有的修改持久化到磁盘中。
    • 我们的数据先写入到buffer里面，在buffer里面的数据时搜索不到的，同时将数据写入到translog日志文件之中。如果buffer快满了，或是一段时间之后，就会将buffer数据refresh到一个新的OS cache之中。
    • translog的作用：在执行commit之前，所有的而数据都是停留在buffer或OS cache之中，无论buffer或OS cache都是内存，
      一旦这台机器死了，内存的数据就会丢失，所以需要将数据对应的操作写入一个专门的日志文件之中。
    • 一旦机器出现宕机，再次重启的时候，es会主动的读取translog之中的日志文件数据，恢复到内存buffer和OS cache之中。
      整个commit过程就叫做一个flush操作
    • 其实translog的数据也是先写入到OS cache之中的，默认每隔5秒之中将数据刷新到硬盘中去，也就是说，
      可能有5秒的数据仅仅停留在buffer或者translog文件的OS cache中，如果此时机器挂了，
      会丢失5秒的数据，但是这样的性能比较好，我们也可以将每次的操作都必须是直接fsync到磁盘，但是性能会比较差。

附：

查看es状态

# 附，命令方式查看es：  curl -uelastic:pwd  -XGET "http://172.31.30.28:9200/_cluster/health?pretty"{  "cluster_name" : "es-for-joyuai-log",# es集群名称  "status" : "green",   # es集群状态  "timed_out" : false,   # 是否出现超时  "number_of_nodes" : 3,   # es节点数  "number_of_data_nodes" : 3,    # es数据节点数  "active_primary_shards" : 1167,# 集群中所有活跃的主分片数  "active_shards" : 2334,   # 集群中所有活跃的分片数  "relocating_shards" : 0,    # 当前节点迁往其他节点的分片数量，通常为0，当有节点加入或者退出时该值会增加  "initializing_shards" : 0,# 正在初始化的分片  "unassigned_shards" : 0,# 未分配的分片数，通常为0，当有节点加入或者退出时该值会增加。  "delayed_unassigned_shards" : 0, # 延迟未分配的分片数  "number_of_pending_tasks" : 0, # 是指主节点创建索引并分配shards等任务，如果该指标数值一直未减小代表集群存在不稳定因素  "number_of_in_flight_fetch" : 0,  "task_max_waiting_in_queue_millis" : 0,  "active_shards_percent_as_number" : 100.0 # 集群分片的可用性百分比，如果为0则表示不可用}

脚本删除30天前的日志索引

#!/bin/bash#删除ELK30天前的日志DATE=`date -d "30 days ago"  %Y.%m.%d`curl -s  -XGET http://172.31.30.88:9200/_cat/indices?v| grep $DATE | awk -F '[ ] ' '{print $3}' >/tmp/elk.logfor elk in `cat /tmp/elk.log`do        curl  -XDELETE  "http://172.31.30.88:9200/$elk"done

来源：https://www.icode9.com/content-4-825801.html

赞 (0)

相关推荐