定位问题解决问题-记录一次事件

好久没更，记录一次线上系统异常与恢复。

临近明天向客户展示系统，结果快下班测试同事的一组聚合图表的查询，10余台es节点cpu全部飙红，load居高不下。等待10余分钟，丝毫未有下降的趋势，老大有点躁了，系统重启下。简单粗暴的办法，因为快下班了，想赶快解决问题。我们认为这是一次由于聚合字段查询过多导致的cpu使用率较高，正常情况下，用户是不会有如此批量的查询动作。

就在重启了2台es之后，我突然惊奇的发现，我们的Load Blance节点无法ssh了！！！ping的通，但是无论如何连不上。这个比较麻烦，Load Blance 不仅是各个组件的沟通桥梁。上面还安装了kafka,zookeeper。还有日志处理模块。

简直麻烦了，必须保证各个节点通讯，所以必须重新搭建一个新的Load Blance。今晚的加班不可避免了。吭哧吭哧搭好新环境，更改各个配置。基本稳定了，数据吐过来了。剩下一点活，老大说明天在搞吧，然后说了下再连load blance看一下。结果真的又活了，我们都很惊讶，“linux 就是牛逼”。

节点ssh后又再次配置回来，来回折腾了，不过最终恢复了系统正常运行。保存了load blance的日志待进一步分析。该节点es已经挂了，但是进程任然存在，所以supervisor也无法起作用拉起来的新的也无效。因为9200还是被那个不服务的es占用着。

总的来说这是一次，因为并发查询导致的，es中tasks较多，cpu使用飙升，但是为何会引发ssh无法登录还需要进一步考证。

下楼的时候我问，你怎么想到最后在连接一下的。“我们什么操作都没做，却无法连上ssh,cpu肯定忙的没有机会处理连接了，虽然这种几率很小。但是我们折腾一圈后，应该有所缓解，所以在连接一下”