Linux下Nginx性能监控需分层协同：系统层用top/iotop/iostat/vmstat定位资源瓶颈；Nginx层通过stub_status和自定义日志分析连接与请求；日志层结合状态码（如499、5xx）和GoAccess深入诊断；vts模块提供虚拟主机级细粒度指标。
Linux 下 Nginx 的性能监控与瓶颈诊断不是靠单一工具，而是分层配合：系统层看资源争用，Nginx 层看连接与请求行为，日志层看响应细节。关键不在“装多少”，而在“查什么、怎么看、怎么串起来”。
系统级资源监控：定位底层瓶颈
先确认是 Nginx 本身卡住，还是被 CPU、内存、磁盘或网络拖慢。
- top / htop：运行后看 %Cpu(s) 中的 wa（I/O 等待）是否长期高于 20%；若单核 CPU 使用率持续超 80%，或软中断（si）占比 >30%，说明存在 CPU 瓶颈；按 P 排 CPU、M 排内存，快速识别异常 worker 进程。
- iotop：需 root 权限，专盯磁盘读写。重点看哪个进程在大量读写（如日志刷盘、临时文件生成），若某 Nginx worker 的 IO_RATE 显著偏高，结合 io_wait 时间可判断是否因日志同步或大文件传输阻塞。
- iostat -x 1：关注 %util 是否持续 >80%、await 是否 >10ms。若磁盘已饱和，Nginx 即使配置再优也会排队等待。
- vmstat 1：检查 si/so（swap 读写）是否非零、cs（上下文切换）是否每秒超 10 万次——前者提示内存不足，后者可能源于过多短连接或线程争抢。
Nginx 自身状态监控：看清连接与请求流转
不依赖外部组件，用好 Nginx 内置能力就能获取核心指标。
-
stub_status 模块：需在配置中启用（如
location /nginx_status { stub_status on; allow 127.0.0.1; deny all; }）。访问后返回三行数据：
• Active connections：当前活跃连接数
• accepts handled requests：分别表示接受、成功处理、总请求数，三者差值过大说明连接被拒绝或重置
• Reading/Writing/Waiting：反映请求所处阶段，Waiting 长期占高说明 keepalive 连接多但无新请求，Reading 高可能受客户端慢速上传影响。 -
自定义日志格式 + 时间字段：在
log_format中加入$request_time $upstream_response_time $upstream_connect_time等。例如：log_format main '$remote_addr [$time_local] "$request" $status $body_bytes_sent $request_time $upstream_response_time';
这样能区分延迟来自 Nginx 本体（rewrite、SSL、gzip）、上游服务（urt 大），还是连接建立阶段（uct 大）。
日志深度分析：定位具体路径与客户端问题
499、502、504 等状态码背后有明确归因逻辑，不能只统计数量。
-
499（Client Closed Request）：不是服务端错误，是客户端主动断开。用
awk '$9==499 {print $7,$1,$request_time}' /var/log/nginx/access.log提取路径、IP 和耗时，再聚合分析：
• 若某 API 路径下 499 集中且 request_time 接近某个固定值（如 5.0s、10.0s），大概率是前端或 App 设置了对应超时；
• 若多个路径都出现、且 upstream_response_time 为 "-" 或极小，说明卡在 Nginx 配置层（如复杂正则匹配、limit_req 触发排队）。 -
5xx 错误分布：用
awk '$9 ~ /^5[0-9]{2}$/ {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr查出错最多的接口；再结合 error_log 中的 upstream timed out、no live upstreams 等关键字，判断是后端挂了、健康检查失效，还是连接池打满。 -
GoAccess 实时分析：安装后执行
goaccess /var/log/nginx/access.log --log-format=COMBINED -o report.html，生成可视化报告，快速查看 TOP IP、TOP URL、状态码分布、响应时间热力图。
增强型监控模块：vts 模块提供虚拟主机级细粒度视图
适用于多站点共用一台 Nginx 的场景，弥补 stub_status 的粗粒度缺陷。
- 安装 nginx-module-vts 后，在配置中加载模块并配置 location：
location /status { vhost_traffic_status_display; vhost_traffic_status_display_format html; } - 访问
/status可查看每个 server_name、每个 upstream 的实时请求数、带宽、响应时间 P95/P99、各状态码计数，甚至支持 JSON 接口供 Prometheus 抓取。 - 特别适合识别“某个子域名突然流量激增”或“某组后端节点响应明显变慢”这类横向对比问题。
