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

朴灿烈づ我的快乐病毒、 2022-09-01 14:54 155阅读 0赞

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

*   *  背景
     *  小风波一：预备的配置脚本不适用
     *  小风波二：ES查询慢且拒绝大量请求
     *  小风波三：jmeter压测端配置不全
     *  总结

## 背景 ##

这是一个月黑风高的夜晚，时间22点，“宜发版“。  
这次只是一次平平无奇的对ES集群的配置进行修改：设置登录密码、memory\_lock、打开慢查询等。为了确认修改配置后对ES性能是否有影响，我们让测试在优化配置前进行了一次压测，当然我们是压测应用接口，应用接口查询ES。测试压测了1000并发持续10分钟，效果如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70]  
虽然很奇怪怎么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命令设置。具体设置和验证命令可以查看[这里][Link 1]。  
这消耗了不少时间，凌晨1点40左右终于成功发好了，查看了ES集群健康状态，都是green。也验证了慢查询和锁内存是否生效。验证锁内存是否成功命令如下：

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

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

ES启好后，我们的测试小姐姐开始压测。压完后给我们上了下面这张图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 1]  
这飙升的错误率，平均时长看的我们是一脸黑人问号。更可怕的是，我手动访问业务接口，每多点几次都有可能和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点半了。想着终于是能解放回家了，然而测试小姐姐又发来了下面这个结果图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 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测试了一把。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 3]  
果然乱码的错误没了。成功了一半了。然后发现可以看到jemeter上的报错返回的信息，发现本地基本都是如下报错：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 4]  
这就很明显了，是socket连接数不够。立马配置了下我本地window10的连接数配置

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 5]

配置后再压本地服务果然0错误，于是我们合理怀疑压测机可能也是socket连接数不够。于是看了线上之前压测的报错，发现大部分都是如下报错  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 6]  
终于破案了，发版前后压测端环境竟有差异

## 总结 ##

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70]: /images/20220829/77b079a897a04823a921cd2afe1c17fd.png
[Link 1]: https://blog.csdn.net/xd15074483478/article/details/119081836
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 1]: /images/20220829/a088a0e1cca642208a67da456455c536.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 2]: /images/20220829/d8a099b64c604616a1c51ef6241ddada.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 3]: /images/20220829/fdb8cfcb7f424e77843151f413d10b8c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 4]: /images/20220829/4fecd544888044eab41c3ff04a4f356f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 5]: /images/20220829/46eca4ef00724b8da394421d7c333602.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hkMTUwNzQ0ODM0Nzg_size_16_color_FFFFFF_t_70 6]: /images/20220829/7cbb58deb36b48fda688f035d5374010.png