核心是确认日志是否真为元凶、句柄是否卡死、i/o是否瘫痪：用du查日志大小、lsof +l1找deleted句柄、iostat看%util和await、tail/grep分析错误刷屏。
排查 Nginx 日志目录磁盘写满导致服务崩溃，核心不是“看空间满没满”，而是快速确认日志是否真为元凶、是否句柄卡死、是否 I/O 已瘫痪。不能只跑 df -h 就动手删文件——删了也不释放，还可能中断服务。
一、确认是不是日志惹的祸
磁盘 100% 是表象，得验证日志是否真的异常膨胀：
- 查日志目录真实占用：
du -sh /var/log/nginx/* 2>/dev/null | sort -hr | head -3，看access.log或error.log是否单个突破几 GB； - 对比历史大小：用
ls -lh /var/log/nginx/查最近 3 天日志，若某天突然暴涨 10 倍以上（比如从 200MB 跳到 8GB），基本可锁定； - 排除其他干扰：运行
find /var/log -type f -size +500M -mtime -1，确认除 Nginx 外无其他大日志（如应用日志、系统 journal）在刷盘。
二、检查日志文件是否被进程“吊着”
删了日志文件但空间不释放？大概率是 Nginx 还握着已删文件的句柄。这是最常被忽略的关键点：
- 精准定位卡住的句柄：
lsof +L1 | grep nginx（+L1表示查找已 unlink 但仍在使用的文件）； - 典型输出示例：
nginx 12345 nobody 3w REG 253,0 1284567890 1234567 /var/log/nginx/access.log (deleted)—— 括号里带(deleted)就是罪魁； - 别只 grep deleted：
lsof | grep nginx | grep log也能看到当前打开的日志路径和文件描述符，辅助判断是否还在写旧文件。
三、观察磁盘 I/O 是否已陷入阻塞
即使空间还有余量，I/O 饱和也会让 Nginx 写日志失败、缓存落盘卡住，最终表现为请求超时或 worker 僵死：
- 执行
iostat -x 1 3，重点关注：%util是否持续 100%，await是否长期 >100ms； - 配合
iotop -oP（需 root），看 nginx worker 进程是否在大量 write 等待； - 如果
top中 nginx 进程状态是D（不可中断睡眠），基本就是卡在磁盘写入上，不是 CPU 或内存问题。
四、验证错误日志是否在疯狂刷屏
很多崩溃不是空间满，而是日志内容本身出问题——比如代码死循环打日志，一秒几万行：
- 用
tail -n 50 /var/log/nginx/error.log看末尾是否有重复堆栈、相同错误反复出现； - 查高频关键词：
grep -c "Connection refused\|timeout\|upstream prematurely closed" /var/log/nginx/error.log，数值异常高（如每分钟上千次）说明上游故障引发连锁刷错； - 若 access.log 也异常：运行
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -5，看 HTTP 状态码是否大量 500/502，再结合时间戳确认是否集中爆发。
