记录一次elasticsearch-5.6.4宕机排查经历

犯罪现场~~

es: 三节点，配置相同
内存: 248G
CPU: 没注意看
磁盘: 2T
data: 380G左右
indices: 近9800条

在下才疏学浅，目前跟着大佬学习，这个问题还没解决，大佬猜测是indices数量过高，将es打爆了，由于机器是客户的，indices的删减需要客户方的同意，暂时不确定是否是这个原因导致的，后期成功处理恢复es集群后，再来更新（为什么不看日志？因为日志太大了，108G，不知道应该搜索哪些关键字，有大佬知道，望赐教）
下面分享两个遇到的犯罪现场~~~
客户环境，就不贴ip地址出来了，以node1,node2,node3来代替，不过这个也不重要

犯罪现场一：es重新启动后，无法加入老的集群

'开发说kibana异常，无法访问，于是登录es服务，查看es的状态'
# curl 'http://node1:9200/_cat/nodes'
{"error":{"root_cause":[{"type":"master_not_discovered_exception":"reason":null}],"type":"master_not_discovered_exception","reason":null},"status":503}
`_cat/nodes无法查看到es集群的node信息，只好通过ps查找es的进程，最后发现node1的es进程挂了，因为日志太大，所以无法定位问题，于是重新去启动es的进程（./bin/elasticsearch -d -p ./PID）`
'tailf log/cluster-es.log 看到started，并且ps和ss可以查看到es的进程和端口后，再次执行以上的curl，结果发现还是一样的报错'
# curl 'http://node1ip:9200'
# curl 'http://node2ip:9200'
# curl 'http://node3ip:9200'
发现:
node2和node3的"cluster_uuid"一致，但是node1和node2，node3不一致，看来，node2和node3与node1的爱消失了~~~
解决：
在下才疏学浅，没有妙招，只好将三个节点的es全部kill，然后重新$(./bin/elasticsearch -d -p ./PID)启动es三节点
验证：
# curl 'http://node1ip:9200/_cat/nodes'
等待总是让人抓耳挠腮。。。当然，集群查询正常，此时，发现了新的犯罪现场，请看下一回合~~~

犯罪现场二：indices好大

'es集群虽然暂时正常了，由于kibana显示es集群是red，所以，还是要继续破案'
# curl 'http://node1ip:9200/_cat/indices' | grep green | wc -l
  %  Total    %  Received   %  Xferd  Average   Speed    Time    Time     Time      Current
                                      Dload    Upload    Total   Spent    Left      Speed
100  1118k  100  1118k      0      0   261k        0   0:00:04  0:00:04  --:--:--    274k
# curl 'http://node1ip:9200/_cat/indices' | grep red | wc -l
  %  Total    %  Received   %  Xferd  Average   Speed    Time    Time     Time      Current
                                      Dload    Upload    Total   Spent    Left      Speed
100  1118k  100  1118k      0      0   309k        0   0:00:03  0:00:03  --:--:--    309k
8124
# curl 'http://node1ip:9200/_cat/indices' | grep yellow | wc -l
  %  Total    %  Received   %  Xferd  Average   Speed    Time    Time     Time      Current
                                      Dload    Upload    Total   Spent    Left      Speed
100  1118k  100  1118k      0      0   250k        0   0:00:04  0:00:04  --:--:--    343k
1665
'啊这...8124+1665=9789...由于集群刚刚恢复，数据需要同步，第二天再来查看吧~~~'

# one day过去了~~~果然早起的运维吃爆红，node1还活着，node2和node3殉情了~~~
# curl 'http://hostip:9200/_cat/nodes'
{"error":{"root_cause":[{"type":"null_pointer_exception":"reason":null}],"type":"null_pointer_exception","reason":null},"status":500}
通过日志，看到了几个报错，基本上也就是indices在恢复的时候，又暴毙了吧，只有等客户方沟通结束，删除一些indices后，再做破案吧，破案后，再来更新
截取四段日志做参考吧，希望有大佬可以带我飞~~~
1、fatal error on the network layer
2、[node1] failed to connect to master [node2]
3、MasterNotDiscoveredExcption: null
4、[node1] timed out while waiting for initial discovered state - timeout: 30s

--------------------------------更新与2020年12月13日---------------------------------

最终，在客户方同意下，删除了历史indices，只保留最近一个月的数据，indices从9789所见到了2785；
但是在恢复过程中，es又暴毙了一次，发现客户方没有加内存限制，加了内存限制之后，解决了