Magento 2 的 var/log、PHP-FPM 日志和 Web 服务器日志如果持续增长，可能最终占满磁盘。直接删除文件只能暂时释放空间，首先要确认是哪条错误在高频重复。

找出增长最快的文件

du -h var/log/* | sort -h
tail -n 200 var/log/system.log
tail -n 200 var/log/exception.log

观察同一异常是否每秒重复出现，并按时间与 Cron、消费者或外部接口任务对应。日志爆增常见原因包括失败任务无限重试、第三方 API 超时、索引异常和自定义代码在循环中记录 info。

先修复日志源头

不要简单关闭全部日志。应让重复任务设置退避和最大重试次数，避免在商品循环中为每条成功记录写日志，并为异常增加业务 ID 和关联 ID，而不是输出完整敏感数据。

配置 logrotate

可在服务器的 logrotate 配置中加入项目日志规则，具体路径和运行用户按部署环境调整：

/var/www/magento/var/log/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

copytruncate 适用于进程持续持有文件句柄、又无法主动重新打开日志的情况，但轮转瞬间可能有少量竞争。更可靠的方式是让日志进程收到信号后重新打开文件，需结合 PHP-FPM 和日志系统配置决定。

先测试配置

logrotate -d /etc/logrotate.d/magento
logrotate -f /etc/logrotate.d/magento

调试模式只检查计划；强制执行会真实轮转，应在确认路径和权限后使用。轮转后的文件所有者必须允许 Magento 继续写入。

数据库和第三方日志

有些 SMTP、导入或审计扩展把日志写入数据库。应查看扩展是否提供保留天数和 Cron 清理功能，不要在不了解关联关系时直接删除表记录。

磁盘已经接近满时

先确认占用来源，再压缩或移动明确可归档的旧日志。不要在生产服务器执行针对宽泛目录的递归删除命令。磁盘恢复后还要检查 MySQL、Redis 和搜索服务是否因空间不足进入只读或异常状态。

验证

  1. 确认日志按天轮转并保留 14 份。
  2. 新日志文件的用户和权限正确。
  3. 压缩文件能够正常读取。
  4. 监控磁盘使用率和日志增长速度。
  5. 确认原始高频异常已经消失。