ManusAI部署后日志文件过大该如何清理【维护】

ManusAI部署后，日志文件一路膨胀到几十GB，磁盘告急、系统卡顿、备份失败、甚至容器启动超时——这已经不是一个可以忽视的小问题了。更关键的是，这些日志并非普通应用日志，而是AI任务执行链中各工作节点（Tool Executor、LLM Gateway、File Processor等）实时写入的结构化日志，直接删除文件，正在运行的推理流水线就会立刻中断。所以，必须采取安全、有效的措施来清理并彻底解决这个隐患。

确认日志路径与活跃状态

第一步，进入ManusAI部署目录，先用 docker-compose ps 看看服务状态——确保 manus-llm、manus-tool 等核心容器都处于 Up 状态，再进行后续操作。

第二步，运行 docker exec -it manus-llm ls -lh /app/logs/，观察日志文件大小和修改时间。如果看到类似 executor.log.2026-06-28、gateway.log.1 这样带日期或数字后缀的文件，说明logrotate已经启用，但配置可能不太合理；如果只有孤零零一个 executor.log 且体积超过5GB，那就是压根没启用轮转，需要紧急处理。

第三步，用 lsof -p $(pgrep -f "uvicorn.*main:app") | grep log 检查Python进程是否正持有日志文件句柄。如果返回结果中包含 /app/logs/executor.log，说明该文件被实时写入，绝对不能直接 rm 删除，只能清空内容。

安全清空正在写入的日志文件

有了上面的确认，就可以动手了。下面三个方法都可以安全清空正在被写入的日志文件，推荐优先使用第一个。

执行 docker exec -it manus-llm sh -c "> /app/logs/executor.log"。这条命令会把文件内容置空，但保留inode、权限和进程句柄。后续日志会继续追加写入同一个文件，服务完全无感，堪称优雅。

执行 docker exec -it manus-llm truncate -s 0 /app/logs/gateway.log。比重定向更底层，对百兆级别的日志响应更快。不过请注意：这个命令只适合ManusAI容器内 /app/logs 路径下的自定义日志，千万别拿来处理系统的 /var/log/syslog 等文件。

执行 docker exec -it manus-llm sh -c "cat /dev/null > /app/logs/fileprocessor.log"。效果和方法一相同，但语义更明确，适合写在自动化脚本里。

永久解决日志膨胀问题

清空一次只是治标，要想一劳永逸，得给日志配上轮转机制。

第一步，进入ManusAI配置目录，打开 config/logging.yaml。找到 handlers: file: filename: 这个字段，确认当前日志路径是 /app/logs/executor.log。

第二步，在这个handlers区块下方，添加轮转配置：
class: logging.handlers.RotatingFileHandler
maxBytes: 10485760 # 10MB
backupCount: 5 # 保留5个历史文件

第三步，重启服务让配置生效：docker-compose down → docker-compose up -d。重启后观察 /app/logs/ 目录，应该会看到 executor.log.1、executor.log.2 这样的滚动文件，主日志就不会再突破10MB了。

第四步，验证轮转效果——触发一次AI任务，比如上传一个PDF然后提问，等待任务完成。接着执行 docker exec -it manus-llm ls -1 /app/logs/ | wc -l。输出值应该稳定在6（1个主日志+5个备份）。如果超过这个数，说明 backupCount 可能被其他配置覆盖了，需要再检查一下。