犯罪现场~~
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又暴毙了一次，发现客户方没有加内存限制，加了内存限制之后，解决了
