把日志升级成"可分析"的
log_format main u0027$remote_addr - $time_local "$request" u0027
u0027$status $body_bytes_sent "$http_user_agent" u0027
u0027rt=$request_time uct=$upstream_connect_time u0027
u0027uht=$upstream_header_time urt=$upstream_response_timeu0027;
access_log /var/log/nginx/access.log main;
#
# rt：Nginx 处理总耗时
# uct：与后端建连耗时（连接池耗尽时这里暴涨）
# uht/urt：后端响应耗时（慢在后端，这两个数字大）
# rt 大而 urt 小 → 慢在 Nginx 自己（带宽、压缩、磁盘）
# rt 大且 urt 大 → 慢在后端——证据链就是这么建立的这行格式是排障神器：用户投诉慢，先拉 access_log 算出 rt 与 urt 的分布，慢在网络、慢在 Nginx、慢在后端，一条日志三类证据。要做集中式分析（呼应 ELK/Loki 那套统一日志），建议直接改用 JSON 格式输出，采集端免解析。
三类错误的标准剧本
| 状态码 | 高频原因 | 首查动作 |
|---|---|---|
| 403 | 文件权限、autoindex、目录无 index 文件、deny 规则 | error_log 里的 "Permission denied" 或 "directory index" |
| 404 | root/alias 拼接错误、正则 location 截胡、文件名大小写 | 确认命中的 location，核对最终物理路径 |
| 502/504 | 后端挂了/超时（反向代理篇的分诊） | 先 ping 后端进程，再看 uct/urt |
404 的两大惯犯值得点名：root 与 alias 用错（动静分离篇的大坑），和Linux 大小写敏感——本地 Windows 开发好好的 Logo.PNG 上 Linux 就是 404。
排错三板斧
# 1. nginx -t：配置对不对（改配置后的第一反应）
$ nginx -t
# 2. curl -v：请求从头到尾经历了什么（跳转、头、状态码）
$ curl -v http://example.com/api/user
# 看 < HTTP/1.1 与 Location 头，重定向环路与缓存头一览无余
# 3. tail -f 双窗口：access 看命中与耗时，error 看原因
$ tail -f /var/log/nginx/access.log /var/log/nginx/error.log
# error_log 级别：平时 warn，排查时临时调 debug（记得改回来）日志治理
高流量站点的 access_log 一天几个 G，必须切割：logrotate 按天轮转加压缩，kill -USR1（或 reopen）让 Nginx 平滑换日志文件。另一个细节：buffer 写日志——access_log ... main buffer=64k flush=5s; 攒批落盘，高并发下少几十万次磁盘写。日志是给机器和人共同消费的资产，格式稳定比内容详尽更重要——格式一改，下游所有解析脚本集体报废。下一篇性能调优：把连接模型与长连接这两个大头先理顺。
评论 (0)