es集群状态red
问题描述
公司有一套kibana日志收集系统，组合方式为filebeat+elasticsearch+kibana，elasticsearch使用三台服务器组合成集群。近期公司的zabbix服务器持续告警某台服务器cpu使用率在80%以上，
登录服务器首先查看是哪个服务器对cpu占用过多，查看是因为es导致。
排查思路
- 针对es集群占用cpu使用率过高问题
# 因es集群仅作为kibana日志收集使用，所以使用es-head首先查看集群状态
- 针对es集群red状态问题
# es集群的几种状态
green：所有主分片和副本都可用
yellow：所有主分片都可用，但不是所有副本分片都可用
red：不是所有主分片都可用，这意味着缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。
# 查看es集群当前状态（当前集群都在线，没有问题）
[root@VM-30-28-centos logs]# curl -s 172.31.30.28:9200/_cat/nodes
172.31.30.28 63 96 4 0.02 0.16 0.36 dilm - VM-30-28-centos
172.31.30.88 20 98 9 0.32 0.50 0.56 dilm * VM-30-88-centos
172.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 on
devtmpfs 2030545 346 2030199 1% /dev
tmpfs 2033272 7 2033265 1% /dev/shm
tmpfs 2033272 469 2032803 1% /run
tmpfs 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.log
for elk in `cat /tmp/elk.log`
do
curl -XDELETE "http://172.31.30.88:9200/$elk"
done