记一次深夜发版的惊慌之旅

背景

这是一个月黑风高的夜晚，时间22点，“宜发版“。
这次只是一次平平无奇的对ES集群的配置进行修改：设置登录密码、memory_lock、打开慢查询等。为了确认修改配置后对ES性能是否有影响，我们让测试在优化配置前进行了一次压测，当然我们是压测应用接口，应用接口查询ES。测试压测了1000并发持续10分钟，效果如下图：

虽然很奇怪怎么1000就有0.13%的报错率，但是我们没当回事。这个报错率还在我们的承受范围内。

小风波一：预备的配置脚本不适用

23点40左右，繁忙的运维小哥哥开始忙我们这单。但是发现修改配置后ES起不来，查看启动日志发现是锁内存不成功。报错如下：

ERROR: bootstrap checks failed memory locking requested for elasticsearch process but memory is not locked

在网上寻觅了一圈，找到了解决办法

编辑/etc/security/limits.conf，添加如下配置
 soft memlock unlimited
 hard memlock unlimited

修改后再次尝试重启，还是起不来。这次是新的报错

Node settings must not contain any index level setting

打开慢查询的配置导致。看报错的意思这个版本改了配置方式，不能在elasticsearch.yml里直接配置了。于是又开始了一番寻觅测试ES7.3.1版本的打开慢查询的配置。而后，在官网找到了正确的方式，需要使用API命令设置。具体设置和验证命令可以查看这里。
这消耗了不少时间，凌晨1点40左右终于成功发好了，查看了ES集群健康状态，都是green。也验证了慢查询和锁内存是否生效。验证锁内存是否成功命令如下：

curl http://127.0.0.1:9201/_nodes?filter_path=**.mlockall

小风波二：ES查询慢且拒绝大量请求

ES启好后，我们的测试小姐姐开始压测。压完后给我们上了下面这张图：

这飙升的错误率，平均时长看的我们是一脸黑人问号。更可怕的是，我手动访问业务接口，每多点几次都有可能和500不期而遇。这很没道理，问了运维应用和ES服务器的负载情况，得到的回复是：毫无波澜。
于是我们很努力的分析了一波日志，应用日志确实有很多Broken pipe的错误，而ES日志上看到有很多请求被拒绝了，有些查询耗时确实挺长。然而ES服务器的负载是不高的，5个节点，最大的索引也只有1.8G左右的数据，ES肯定没这么弱。从日志上看不出ES怎么了，于是我们开始使用各种_cat的命令查看集群的运行情况，终于在下面这个命令里看出了端倪

curl http://1270.0.1:9201/_cat/nodes?v

ES的各个节点的名称竟然都是es2。ES集群估计各个节点的配置文件搞成一样的了。问了下运维小哥哥，果然，小哥哥全复制的一个配置文件。阴沟里翻了船。。。

小风波三：jmeter压测端配置不全

在我们重新改了配置，重启，再压测已经是凌晨2点半了。想着终于是能解放回家了，然而测试小姐姐又发来了下面这个结果图：

怎么肥事，这报错率凭什么？只能再去日志里找找答案，发现了比较多的以下这种乱码错误

HttpMessageNotReadableException: JSON parse error: Invalid UTF-8 middle byte 0x3f; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Invalid UTF-8 middle byte 0x3f

看起来是入参乱码了，我们尝试了入参中可能有问题的一些字符，手动postman发现接口能正常返回。于是怀疑是不是有爬虫在爬我们的数据引起的。各种日志查看无果后，我们选择了先回滚。
拿了测试的压测脚本过来分析，并发数不大的情况直接压自己的本地的服务，发现报错率也很高，且仍然有乱码的错误。恍然入参编码有问题，于是果然发现脚本配置没有设置Context encoding，立即设置为utf-8测试了一把。

果然乱码的错误没了。成功了一半了。然后发现可以看到jemeter上的报错返回的信息，发现本地基本都是如下报错：

这就很明显了，是socket连接数不够。立马配置了下我本地window10的连接数配置

1、regedit
2、找到如下目录HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters
3、新增或修改参数MaxUserPort

配置后再压本地服务果然0错误，于是我们合理怀疑压测机可能也是socket连接数不够。于是看了线上之前压测的报错，发现大部分都是如下报错

终于破案了，发版前后压测端环境竟有差异

总结

这次发版持续到凌晨5点，在这里总结以下几点血泪教训：
1、再忙，再自信的配置还是要在一个环境先验证，生产要做的操作在一个环境先预演
2、尽量不要凌晨发版，大家状态都不太好。
3、开发也要了解其他岗位的一些常用工具，能避免和更快定位问题。
4、大胆合理怀疑每一个可能影响的因素。