nginx worker进程无直接iops指标，需通过iotop查实时写入、iostat看磁盘%util/await/w/s、lsof结合配置定位日志或缓存落盘行为，分层归因而非监控单进程吞吐。
Nginx 多进程架构下，不能直接监控“每个 worker 进程的 IO 吞吐量（如 IOPS 或 MB/s）”，因为 Nginx 本身不主动执行大量磁盘读写；真正可测的是其 worker 进程引发的底层磁盘 I/O 行为，且必须结合宿主机设备级指标与进程行为交叉验证。关键不是看单个进程“吞吐多少”，而是判断哪些 worker 是否在触发异常日志刷盘、缓存落盘或小文件服务——这些行为会间接抬高磁盘负载。
监控核心思路：分层定位，不盯进程盯行为
Nginx 的 worker 进程是用户态轻量进程，静态文件读取走内核 page cache，日志写入可缓冲，SSL 证书只加载一次。因此：
- 没有持续、可观测的“进程级 IO 吞吐”指标（如 /proc/PID/io 中的 rchar/wchar 不反映真实磁盘 I/O）
- 真正要监控的，是 worker 进程是否成为磁盘 I/O 的主要触发源，这需通过三类工具协同判断
用 iotop 实时聚焦活跃 worker 进程
这是最直观的起点，用于发现“谁在写、写得多不多”：
- 先获取所有 worker PID：
pgrep -f "nginx: worker" - 以 root 运行并过滤：
sudo iotop -o -p $(pgrep -f "nginx: worker" | tr '\n' ',' | sed 's/,$//') - 观察
WRITE列（单位 KB/s 或 MB/s），重点关注：- 某个 worker 持续 >5 MB/s 写入 → 很可能在刷 access_log（未配 buffer）或 proxy_cache 落盘
- 多个 worker 同时高频 WRITE → 检查是否日志路径在慢盘、或 cache_path 配置了
use_temp_path=on
- 按
Shift+P切换进程视图，按O只显示有 IO 的进程，避免干扰
用 iostat 关联设备压力，确认是否真瓶颈
iotop 告诉你“谁在动”，iostat 告诉你“动得有多狠”：
- 运行
iostat -xdm 1，紧盯以下三项：
%util：持续 >80% 表示磁盘饱和，需立即排查来源
await：平均等待时间 >10ms（HDD）或 >1ms（SSD）说明响应延迟高
w/s：每秒写入请求数，若数值突增（如从 200 跳到 2000），大概率是日志或缓存批量刷盘 - 若 w/s 高但 iotop 中 worker WRITE 很低 → 真正写盘的可能是其他进程（如数据库、备份脚本）
用 lsof + 配置比对，归因到具体行为
光看数字不够，得知道“为什么写”：
- 对高 IO 的 worker PID 执行：
lsof -p <pid> | grep -E "(log|cache|html|jpg|png)"</pid> - 结合 Nginx 配置快速判断来源：
- 若看到
/var/log/nginx/access.log→ 检查access_log ... buffer=64k flush=5s是否启用 - 若看到
/data/cache/...→ 查proxy_cache_path是否设use_temp_path=off和inactive=10m - 若看到大量
.jpg.js文件但没开sendfile on→ 小文件服务绕过零拷贝，增加内核拷贝压力
- 若看到
长期可观测：用 Prometheus + Node Exporter 抓设备级 I/O
对生产环境，建议采集以下指标并打标签（如 instance="nginx-prod-01", role="static-server"）：
-
rate(node_disk_writes_completed_total[5m])→ 真实写 IOPS -
node_disk_io_time_seconds_total→ 磁盘忙时占比（对应 %util） -
node_disk_written_bytes_total→ 写吞吐量（MB/s 级别） - 关键：把指标和日志路径、缓存路径做 label 区分，例如：
job="nginx", mountpoint="/var/log"→ 日志盘压力job="nginx", mountpoint="/data/cache"→ 缓存盘压力
不复杂但容易忽略
