当前位置:主页 > 查看内容

记一次生产环境大面积404问题!

发布时间:2021-05-15 00:00| 位朋友查看

简介:作者个人研发的在高并发场景下,提供的简单、稳定、可扩展的延迟消息队列框架,具有精准的定时任务和延迟队列处理功能。自开源半年多以来,已成功为十几家中小型企业提供了精准定时调度方案,经受住了生产环境的考验。为使更多童鞋受益,现给出开源框架地址……

 

作者个人研发的在高并发场景下,提供的简单、稳定、可扩展的延迟消息队列框架,具有精准的定时任务和延迟队列处理功能。自开源半年多以来,已成功为十几家中小型企业提供了精准定时调度方案,经受住了生产环境的考验。为使更多童鞋受益,现给出开源框架地址:https://github.com/sunshinelyz/mykit-delay

写在前面

发布到线上的接口服务一直好端端的,今天突然运营反馈说很多功能无法正常使用。经过排查,发现前端调用后端接口时,部分接口出现404的现象。今天,我到公司比较晚,肯定是哪个小伙伴昨晚下班,走出办公室前没有祈祷服务器不要出问题。要把这个人揪出来,吊在服务器上——祭天!

文章已收录到:

https://github.com/sunshinelyz/technology-binghe

https://gitee.com/binghe001/technology-binghe

问题复现

得知运营的反馈后,我迅速登录服务器排查问题。首先,查看了接口服务的启动进程正常。验证接口服务的ip和端口是否正常,结果也是没啥问题。接下来,通过Nginx转发请求,此时出现了问题,无法访问接口。同时Nginx的access.log文件中输出了如下日志信息。

  1. 192.168.175.120 - - [26/Feb/2021:21:34:21 +0800] "GET /third/system/base/thirdapp/get_detail HTTP/1.1" 404 0 "http://192.168.175.100/api/index.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0" 
  2. 192.168.175.120 - - [26/Feb/2021:21:34:22 +0800] "GET /third/system/base/thirdapp/get_detail HTTP/1.1" 404 0 "http://192.168.175.100/api/index.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0" 
  3. 192.168.175.120 - - [26/Feb/2021:21:34:26 +0800] "GET /third/system/base/thirdapp/get_detail HTTP/1.1" 404 0 "http://192.168.175.100/api/index.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0" 

此时,从Nginx日志中发现,输出的状态为404,未找到后端的接口服务。为了进一步定位问题,我直接在线上环境通过curl命令的方式来访问接口服务,结果是正常的。

经过这一系列的操作之后,我们就可以确定问题是出在Nginx上了。

问题分析

Nginx开启debug模块

既然已经定位到问题了,那我们接下来就要分析下产生问题的具体原因了。既然是Nginx的问题,我第一时间想到的就是调试Nginx查找错误原因。于是我在服务器命令行输入了如下命令来查看安装Nginx时的配置情况。

  1. nginx -V 

注意:这里已经为Nginx配置了系统环境变量,如果没有配置系统环境变量,则需要输入nginx命令所在目录的完整路径,例如:

  1. /usr/local/nginx/sbin/nginx -v 

命令行输出了如下信息。

  1. configure arguments: --prefix=/usr/local/nginx --with-http_stub_status_module --add-module=/usr/local/src/fastdfs/fastdfs-nginx-module-1.22/src --with-openssl=/usr/local/src/openssl-1.0.2s --with-pcre=/usr/local/src/pcre-8.43 --with-zlib=/usr/local/src/zlib-1.2.11 --with-http_ssl_module 

可以看到,安装Nginx时没有配置Nginx的debug模块。

于是我在服务器上找到了Nginx的安装文件,在命令行输入如下命令重新编译Nginx。

  1. cd /usr/local/src/nginx/  #进入Nginx的安装文件根目录 
  2. make clean                #清除编译信息 
  3. ./configuration --prefix=/usr/local/nginx-1.17.8 --with-http_stub_status_module --add-module=/usr/local/src/fastdfs/fastdfs-nginx-module-1.22/src --with-openssl=/usr/local/src/openssl-1.0.2s --with-pcre=/usr/local/src/pcre-8.43 --with-zlib=/usr/local/src/zlib-1.2.11 --with-http_ssl_module --with-debug  #设置编译Nginx的配置信息 
  4. make     #编译Nginx,切记不要输入make install 

上述命令中,切记不要输入make install 进行安装。

执行完 make 命令后,会在当前目录的objs目录下生成nginx命令,此时我们需要先停止Nginx服务,备份/usr/local/nginx/sbin/目录下的nginx命令,然后将objs目录下的nginx命令复制到/usr/local/nginx/sbin/目录下,然后启动Nginx服务。

  1. nginx_service.sh stop   #通过脚本停止Nginx服务 
  2. mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak #备份原有nginx命令 
  3. cp ./objs/nginx /usr/local/nginx/sbin/nginx #复制nginx命令 
  4. nginx_service.sh start #通过脚本启动Nginx服务 

注意:这里,在停止Nginx服务前,已经将此Nginx从接入层网关中移除了,所以不会影响线上环境。为了避免使用新编译的nginx命令重启Nginx出现问题,这里通过脚本先停止Nginx服务,然后复制nginx命令后,再启动Nginx服务。

配置Nginx输出debug日志

在Nginx的nginx.conf文件中配置如下信息。

  1. error_log  logs/error.log debug; 

此时,开启了Nginx的debug日志功能,并将debug信息输出到error.log文件中。

分析问题

接下来,在服务器命令行输入如下命令监听error.log文件的输出日志。

  1. tail -F /usr/local/nginx/logs/error.log 

然后模拟访问http接口,可以看到error.log文件中输出如下信息。

  1. 2021/02/26 21:34:26 [debug] 31486#0: *56 http request line: "GET /third/system/base/thirdapp/get_detail HTTP/1.1" 
  2. 2021/02/26 21:34:26 [debug] 31486#0: *56 http uri: "/third/system/base/thirdapp/get_detail" 
  3. 2021/02/26 21:34:26 [debug] 31486#0: *56 http args: "" 
  4. 2021/02/26 21:34:26 [debug] 31486#0: *56 http exten: "" 
  5. 2021/02/26 21:34:26 [debug] 31486#0: *56 posix_memalign: 0000000000FF6450:4096 @16 
  6. 2021/02/26 21:34:26 [debug] 31486#0: *56 http process request header line 
  7. 2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Host: 10.31.5.66" 
  8. 2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0" 
  9. 2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Accept: */*" 
  10. 2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2" 
  11. 2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Accept-Encoding: gzip, deflate" 
  12. 2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Referer: http://192.168.175.100/api/index.html" 
  13. 2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Connection: keep-alive" 
  14. 2021/02/26 21:34:26 [debug] 31486#0: *56 http header done 
  15. 2021/02/26 21:34:26 [debug] 31486#0: *56 rewrite phase: 0 
  16. 2021/02/26 21:34:26 [debug] 31486#0: *56 test location: "/" 
  17. 2021/02/26 21:34:26 [debug] 31486#0: *56 test location: "file/" 
  18. 2021/02/26 21:34:26 [debug] 31486#0: *56 test location: ~ "/base" 
  19. 2021/02/26 21:34:26 [debug] 31486#0: *56 using configuration "/base" 

从上面的输出日志中,我们可以看到:访问的接口地址为“/third/system/base/thirdapp/get_detail”,如下所示。

  1. 2021/02/26 21:34:26 [debug] 31486#0: *56 http uri: "/third/system/base/thirdapp/get_detail" 

Nginx在进行转发时,分别匹配了“/”,“file/”,“~/base”,最终将请求转发到了“/base”,如下所示。

  1. 2021/02/26 21:34:26 [debug] 31486#0: *56 test location: "/" 
  2. 2021/02/26 21:34:26 [debug] 31486#0: *56 test location: "file/" 
  3. 2021/02/26 21:34:26 [debug] 31486#0: *56 test location: ~ "/base" 
  4. 2021/02/26 21:34:26 [debug] 31486#0: *56 using configuration "/base" 

我们再来看看Nginx的配置,打开nginx.conf文件,找到下面的配置。

  1. location ~/base { 
  2.   proxy_pass                  http://base; 
  3.   proxy_set_header Host $host:$server_port; 
  4. location ~/third { 
  5.   proxy_pass                  http://third; 
  6.   proxy_set_header Host $host:$server_port; 

那么问题来了,访问的接口明明是“/third/system/base/thirdapp/get_detail”,为啥会走到“/base”下面呢?

说到这里,相信细心的小伙伴已经发现问题了,没错,又是运维的锅!!

解决问题

看了Nginx的配置后,相信很多小伙伴应该都知道如何解决问题了,没错那就是把nginx.conf中的如下配置。

  1. location ~/base { 
  2.   proxy_pass                  http://base; 
  3.   proxy_set_header Host $host:$server_port; 
  4. location ~/third { 
  5.   proxy_pass                  http://third; 
  6.   proxy_set_header Host $host:$server_port; 

修改为如下所示。

  1. location /base { 
  2.   proxy_pass                  http://base; 
  3.   proxy_set_header Host $host:$server_port; 
  4. location /third { 
  5.   proxy_pass                  http://third; 
  6.   proxy_set_header Host $host:$server_port; 

去掉“~”符号即可。

接下来,再次模拟访问http接口,能够正常访问接口。

接下来,将Nginx的debug功能关闭,也就是将nginx.conf文件中的 error_log logs/error.log debug; 配置注释掉,如下所示。

  1. # error_log  logs/error.log debug; 

重新加载nginx.conf文件。

  1. nginx_service.sh reload 

最终,将Nginx加入到接入层网关,问题解决。

科普Nginx的转发规则

Nginx的location语法

  1. location [=|~|~*|^~] /uri/ { … } 
  • = 严格匹配。如果请求匹配这个location,那么将停止搜索并立即处理此请求
  • ~ 区分大小写匹配(可用正则表达式)
  • ~* 不区分大小写匹配(可用正则表达式)
  • !~ 区分大小写不匹配
  • !~* 不区分大小写不匹配
  • ^~ 如果把这个前缀用于一个常规字符串,那么告诉nginx 如果路径匹配那么不测试正则表达式

示例1:

  1. location  / { } 

匹配任意请求

示例2:

  1. location ~* .(gif|jpg|jpeg)$ { 
  2.     rewrite .(gif|jpg|jpeg)$ /logo.png; 
  3. } 

不区分大小写匹配任何以gif、jpg、jpeg结尾的请求,并将该请求重定向到 /logo.png请求

示例3:

  1. location ~ ^.+\.txt$ { 
  2.     root /usr/local/nginx/html/; 

区分大小写匹配以.txt结尾的请求,并设置此location的路径是/usr/local/nginx/html/。也就是以.txt结尾的请求将访问/usr/local/nginx/html/ 路径下的txt文件

alias与root的区别

  • root 实际访问文件路径会拼接URL中的路径
  • alias 实际访问文件路径不会拼接URL中的路径

示例如下:

  1. location ^~ /binghe/ {   
  2.    alias /usr/local/nginx/html/binghetic/;   
  • 请求:http://test.com/binghe/binghe1.html
  • 实际访问:/usr/local/nginx/html/binghetic/binghe1.html 文件
  1. location ^~ /binghe/ {   
  2.    root /usr/local/nginx/html/;   
  • 请求:http://test.com/binghe/binghe1.html
  • 实际访问:/usr/local/nginx/html/binghe/binghe1.html 文件

last 和 break关键字的区别

(1)last 和 break 当出现在location 之外时,两者的作用是一致的没有任何差异

(2)last 和 break 当出现在location 内部时:

  • last 使用了last 指令,rewrite 后会跳出location 作用域,重新开始再走一次刚才的行为
  • break 使用了break 指令,rewrite后不会跳出location 作用域,其整个生命周期都在当前location中。

permanent 和 redirect关键字的区别

  • rewrite … permanent 永久性重定向,请求日志中的状态码为301
  • rewrite … redirect 临时重定向,请求日志中的状态码为302

综合实例

将符合某个正则表达式的URL重定向到一个固定页面

比如:我们需要将符合“/test/(\d+)/[\w-.]+” 这个正则表达式的URL重定向到一个固定的页面。符合这个正则表达式的页面可能是:http://test.com/test/12345/abc122.html、http://test.com/test/456/11111cccc.js等

从上面的介绍可以看出,这里可以使用rewrite重定向或者alias关键字来达到我们的目的。因此,这里可以这样做:

(1)使用rewrite关键字

  1. location ~ ^.+\.txt$ { 
  2.     root /usr/local/nginx/html/; 
  3. location ~* ^/test/(\d+)/[\w-\.]+$ { 
  4.     rewrite ^/test/(\d+)/[\w-\.]+$ /testpage.txt last

这里将所有符合条件的URL(PS:不区分大小写)都重定向到/testpage.txt请求,也就是 /usr/local/nginx/html/testpage.txt 文件

(2)使用alias关键字

  1. location ~* ^/test/(\d+)/[\w-\.]+$ { 
  2.     alias /usr/local/nginx/html/binghetic/binghe1.html; 

这里将所有符合条件的URL(不区分大小写)都重定向到/usr/local/nginx/html/binghetic/binghe1.html 文件

本文转载自微信公众号「冰河技术」,可以通过以下二维码关注。转载本文请联系冰河技术公众号


本文转载自网络,原文链接:https://mp.weixin.qq.com/s/ZoN3trzI2yETPvN4pWfO3Q
本站部分内容转载于网络,版权归原作者所有,转载之目的在于传播更多优秀技术内容,如有侵权请联系QQ/微信:153890879删除,谢谢!

推荐图文


随机推荐