磁盘告警需定位、清理、预防三步解决：先用df/du/lsof定位空间占用和大文件，再分系统日志、应用日志、缓存等场景安全清理，最后通过阈值分级、自动巡检、容量基线和应用层日志限流实现长效防控。
磁盘告警频繁，不是单纯删几个日志就能解决的——关键得看清空间去哪了、谁在持续写、未来会不会再爆。下面从定位、清理、预防三步说清楚。
快速定位“真凶”：哪些目录吃掉了空间
别一上来就 rm -rf，先用命令摸清底数：
-
df -h看哪个分区满（重点关注/、/var、/home） -
du -sh /* 2>/dev/null | sort -hr | head -10查根下前10大目录 - 进可疑目录（如
/var/log）后执行：du -sh * | sort -hr | head -5，快速揪出最大日志或缓存文件 - 对运行中的服务，用
lsof +L1找已删除但进程仍占句柄的大文件（常见于未重启的旧日志）
安全清理：别删错，也别留“尾巴”
清理不是越狠越好，要分场景处理：
-
系统日志：优先用
journalctl --disk-usage查 systemd 日志占用；用journalctl --vacuum-size=200M或--vacuum-time=2weeks安全收缩，避免直接删/var/log/journal -
应用日志：检查 Nginx、MySQL、Tomcat 等配置中 logrotate 是否启用；若没配，补上
/etc/logrotate.d/xxx规则，加copytruncate防服务中断 -
临时与缓存：清理
/tmp（确认无活跃进程依赖）、/var/cache/apt/archives（Debian/Ubuntu：运行apt clean）、/var/lib/docker/tmp（Docker 主机需定期docker system prune -f） -
残留大文件：用
find /var -type f -size +100M -mtime +30找出 30 天前的超大文件，人工确认后再删
长效防控：让告警变“稀客”，而不是常客
光救火不行，得建机制：
- 设置合理阈值：Zabbix/Prometheus 告警别卡死 90%，建议按业务节奏设阶梯阈值（如 85% 邮件提醒、92% 企业微信告警、95% 自动触发清理脚本）
-
加自动巡检脚本：每天凌晨跑一次，检测
/var/log、/var/lib/docker等高危路径，超限则压缩归档或通知负责人 -
容量基线管理：记录每周
df -h输出，画趋势图；若/var每周涨 2GB，按此推算扩容时间点，提前申请资源 -
应用层约束：给日志服务配
max-size和max-file（如 Docker 的--log-opt max-size=10m --log-opt max-file=3），从源头控量
不复杂但容易忽略：很多告警反复出现，是因为只清了表面，没关住“水龙头”。盯住增长源，比反复擦水渍管用得多。
