Nginx 日志里找慢请求：access 日志 + awk 快速定位接口瓶颈

接口变慢时，先别猜是数据库还是后端。Nginx 的 access 日志已经记录了每次请求耗时，关键是先把慢请求找出来，再按接口聚合，看它是普遍变慢，还是个别接口偶发变慢。

一、日志里要有耗时字段

默认日志往往只有状态码，没有耗时。建议加一个带耗时的格式：

log_format slow '$remote_addr [$time_local] "$request" $status $request_time $upstream_response_time';

$request_time 是请求总耗时，$upstream_response_time 是上游耗时。两者对比，就能先区分问题在 Nginx 自身，还是在上游。改完用 nginx -t 检查后平滑重载。

二、先看最慢的 10 条

不要先算平均值，平均值容易被极端值拉高。先把最慢请求原样找出来：

awk -F'"' '{split($2,r," "); split($3,t," "); print t[3], r[2]}' /var/log/nginx/access.log | sort -nr | head -10

按双引号切分后，r[2] 是 URI，t[3] 是总耗时。同一接口反复出现，它就是第一嫌疑对象；最慢的都是静态资源时，先怀疑缓存、磁盘或回源。

三、按接口算平均耗时

单条最慢只是个案，还要看接口整体是否都慢：

awk -F'"' '{split($2,r," "); split($3,t," "); s[r[2]]+=t[3]; n[r[2]]++} END{for(u in s) printf "%.3f %d %s\n", s[u]/n[u], n[u], u}' /var/log/nginx/access.log | sort -nr | head -10

输出依次是平均耗时、次数、接口。耗时高且次数多的接口优化收益最大；只有一两次的高耗时，可能是偶发抖动，先不要急着重构。

最后再对比总耗时与上游耗时：总耗时高、上游耗时低，排查 Nginx 侧的排队与限流；两者都高，再去查上游与数据库。日志量大时先用 grep 缩小时间段，含敏感参数的日志分享前要脱敏。