Nginx配置日志记录请求时间、上游处理时间、打印定义请求头字段。实践后亲测有效,这对检查系统性能非常有用。包括检查网络是否有问题、程序是否有问题等。

整体思路

在nginx配置接收请求时间,同时打印出请求时间、上游处理时间。然后在前端将业务操作的时间放在request header里面,并且将其打印在nginx的日志中。将用户操作的时间,接到请求的时间和处理完的时间一比较自然就清楚地知道,是哪个地方出了问题,包括网络、程序是否有问题。

1、配置格式

在http配置

这里配置打印的格式,

请求时长: rt=$request_time ,

上游处理时长:urt=$upstream_response_time ,

自定义request head: mt=$http_myrequestdate';

这里要特别注意:前面要加上http_,要不然会报变量找不到。


    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"'
                      'rt=$request_time urt=$upstream_response

### Nginx 返回 302 状态码的原因 当Nginx服务器返回302状态码时,这表示临时重定向。客户端发出的请求以及任何随附的数据(如果有的话),都应当重复发送到Location头字段指示的新URI下[^2]。 通常情况下,302响应只缓存一小段时间。对于HTTP/1.1协议来说,除非另有说明,否则浏览器会自动跳转至新的URL而无需用户交互。然而,在某些特定的应用场景中,这种行为可能会引发问题,比如破坏应用程序逻辑流程或影响用户体验。 #### 可能导致302重定向的具体情况: - **上游应用服务主动设置**:有时后端Web框架或其他中间件会在处理过程中显式地设置了302响应来引导客户端转向另一个页面。 - **配置不当引起的循环重定向**:错误的location匹配规则可能导致无限次内部重写操作,最终触发302响应并指向原始路径以外的位置。 - **认证机制相关**:一些安全措施如OAuth授权过程也会涉及多个阶段间的跳转动作,从而造成预期之外的状态码变化。 ### 解决方案 为了有效应对上述提到的各种可能性,可以采取以下几种策略来进行调试和修正: #### 审查现有配置文件中的指令集 仔细检查`server{}`上下文中定义的各项参数,特别是涉及到转发(`proxy_pass`)、重写(`rewrite`)等功能的部分。确保这些命令不会意外改变初始请求的目标地址或者附加额外查询字符串。 ```nginx server { listen 80; server_name example.com; location / { proxy_set_header Host $host; proxy_pass http://backend_server_address/; # 防止不必要的头部修改引起的问题 proxy_redirect off; } } ``` #### 调整日志级别以便获取更多信息 通过提高Nginx日志记录等级可以帮助定位具体哪个环节出现了偏差。可以在http{}块内加入如下语句开启更详细的跟踪模式: ```nginx error_log /var/log/nginx/error.log debug; access_log /var/log/nginx/access.log combined; ``` #### 试环境下的逐步排除法 创建一个独立于生产系统的试实例用于重现现象,并逐一移除可疑因素直到找到根本原因所在。此期间应保持密切监控网络流量走向及其携带的内容特征。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值