nginx中requesttime和upstreamresponsetime详解本文已参与「新人创作礼」活动，一起

最近监控报警有短暂的502，赶紧分析问题原因，查看nginx的access_log发现短暂报警的request_time比较大，但是upstream_response_time有2个值，一个比较小，一个比较大，日志如下：

request:GET/index/allHTTP/1.1request_time:30.049up_resp_time:0.015:30.033up_addr:11.11.11.11:80:22.22.22.22:80bytes:556status:502概念request_time

官网描述：

requestprocessingtimeinsecondswithamillisecondsresolution;timeelapsedbetweenthefirstbyteswerereadfromtheclientandthelogwriteafterthelastbytesweresenttotheclient。

upstream_response_time

keepstimesofresponsesobtainedfromupstreamservers;timesarekeptinsecondswithamillisecondsresolution.Severalresponsetimesareseparatedbycommasandcolonslikeaddressesinthe$upstream_addrvariable

所以如果使用nginx的accesslog查看php程序中哪些接口比较慢的话，记得在log_format中加入$upstream_response_time。

我们的情况是request_time比较大，猜测有可能是如下问题产生的：

我们的架构比较特殊，有2套项目，一套重构的项目，一套老项目，请求会先转发到重构的新项目上，如果返回404，则再转发到老的项目上，所以我们的upstream_response_time有2个值:

查看老项目nginx_error.log

[error]22705#0:*692770681recv()failed(104:Connectionresetbypeer)whilereadingresponseheaderfromupstream上面错误的两大主要原因：

1.php-fpm超时进程终止

2.可用内存不够进程终止

查看php-fpm配置

request_terminate_timeout=30我们得出结论：nginx告诉我们没有收到反馈，php-fpm告诉我们进程中断了

再查看老乡们的access.log

再去查看php-slow.log发现是因为请求一个外部接口导致的过慢

查看当时服务器日志是否有错误；

检查服务器资源使用情况是否正常，loadaverage、CPU使用率（尤其是单核CPU）是否有飙高现象；

检查是否出现磁盘短暂负载较高，比如iostatutil%飙高等；

确认当时网络情况是否正常，是否有网络丢包等现象。以上排查建议在有全面监控的基础上进行，偶现问题比较难定位，有全面的监控数据进行排查就方便多了。