日志半天爆满说明日志生产、落盘、归档三环节同时失控,需先定位php error_log、mysql慢日志或docker json-file等高频源头,再通过清空、压缩、logrotate(必配copytruncate)及容器日志限流等组合手段止血并长效治理。

日志半天就爆,说明写入速率远超当前轮转和清理策略的承载能力。这不是单纯“删日志”能解决的问题,而是日志生产、落盘、归档三个环节同时失守的结果。
查清日志爆炸源头在哪
别急着删文件,先定位真凶。高频日志通常来自三类地方:
-
PHP的error_log(尤其是Notice或Warning被大量触发) -
MySQL的slow_query_log或general_log(long_query_time设为 0 或 1 秒时极易失控) - Docker 容器的
json-file日志(默认不压缩、不限大小,单个容器每秒几百条就可能撑爆磁盘)
执行 du -sh /var/log/* 2>/dev/null | sort -hr | head -5 快速看哪个目录最大;再进该目录用 ls -ltS 找出最大的单个文件,用 head -20 和 tail -20 看内容判断类型。
立刻止血:安全清空 + 压缩归档
直接 rm 正在被进程写入的日志文件,空间不会释放——Linux 下文件句柄仍被占用。正确做法是清空内容并压缩旧文件:
- 清空正在写的日志:
echo '' > /var/log/php_errors.log(路径以php.ini中error_log配置为准) - 压缩已有大日志:
gzip /var/log/mysql/slow.log.20260907 - 若 MySQL 慢日志路径是
/var/lib/mysql/slow.log,先确认是否启用:SHOW VARIABLES LIKE 'slow_query_log';,再执行SET GLOBAL slow_query_log = 'OFF';临时关停
压缩后空间立减 80%~90%,且 zcat 仍可随时查看内容,不影响排障。
Docker 容器日志必须加 max-size 和 max-file
默认的 json-file 驱动会把所有 stdout/stderr 无节制写入主机磁盘,一个高 QPS 服务半天就能生成几十 GB。必须在 /etc/docker/daemon.json 中强制约束:
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3",
"compress": "true"
}
}
改完执行 sudo systemctl restart docker。注意:该配置只对新建容器生效,老容器需 docker stop && docker rm && docker run 重建才生效。
logrotate 不是万能的,关键要配 copytruncate
MySQL、Nginx、PHP 这类长期运行的进程不会自动重开日志句柄,所以 logrotate 默认的 rotate + create 会导致写入中断或丢失日志。必须加 copytruncate:
/var/log/nginx/access.log {
daily
missingok
rotate 7
compress
copytruncate
notifempty
}
它会先复制一份,再立刻清空原文件,进程完全无感知。没这行,轮转等于白配。
真正难的不是清理动作,而是让日志量回归可控范围:关掉非必要日志、调高采样阈值、在代码里加条件日志(比如只对特定用户 ID 或错误码记录),这些才是避免下次半夜被叫醒的根本。











