磁盘告警需定位、清理、预防三步解决：先用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），从源头控量

不复杂但容易忽略：很多告警反复出现，是因为只清了表面，没关住“水龙头”。盯住增长源，比反复擦水渍管用得多。