日志轮转与磁盘打满

磁盘被日志打满是最低级也最常见的事故。logrotate 几乎所有发行版都预装，缺的往往只是一份配置和一次检查。

logrotate 基本配置

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    dateext
    copytruncate
}

• daily 每天轮转，rotate 14 保留 14 份；
• compress 旧日志 gzip（delaycompress 让最新一份延迟一天压缩，便于即时查看）；
• dateext 用日期做后缀，比 .1 .2 直观。

copytruncate 的取舍

标准轮转是「改名旧文件、通知进程重开新文件」，需要进程响应信号（nginx reopen、logrotate 的 create + postrotate）。应用不支持时用 copytruncate：先复制再清空原文件。代价是复制与清空之间写入的少量日志会丢失——对多数应用可以接受。

验证配置而不真正执行：

logrotate -d /etc/logrotate.d/myapp    # dry run
logrotate -f /etc/logrotate.d/myapp    # 强制执行一次，验证效果

磁盘告警后的处理顺序

df -h                          # 哪个分区满了
du -xh --max-depth=1 / | sort -rh | head   # 逐层往下找
lsof +L1                       # 已删除但仍被进程占用的文件（空间未释放）

已删除但进程还握着句柄的大文件是最阴的：rm 后 df 不变，必须重启对应进程或 truncate。处理顺序：先清大日志腾空间 → 找根因（为什么没轮转/异常刷屏）→ 补配置和告警。

告警要提前

磁盘监控的阈值建议两级：80% 预警、90% 告急。加上保留策略的检查——「rotate 14 的日志每天涨 3GB」意味着保留策略本身就需要调整，而不是等打满再说。

日志的价值在于被查询。该归档的归档、该清的清，留一堆从没人打开过的 error.log 只会消耗磁盘和注意力。