Wan2.1-UMT5自动化运维：编写Shell脚本监控服务与自动重启

Wan2.1-UMT5自动化运维：编写Shell脚本监控服务与自动重启

你是不是也遇到过这种情况：辛辛苦苦部署好的Wan2.1-UMT5 WebUI服务，跑着跑着就自己停了，或者因为显存爆了导致整个服务卡死。半夜收到报警，还得爬起来手动重启，别提多折腾了。

对于需要长期、稳定运行AI服务的用户来说，手动维护不仅效率低下，还容易出纰漏。今天，我就来分享一套简单实用的自动化运维方案，教你用Bash Shell脚本，给你的Wan2.1-UMT5服务加上一个“7x24小时贴身管家”。这个方案能帮你自动检查服务状态、监控GPU资源，一旦发现问题就自动重启，还能及时给你发通知，让你高枕无忧。

1. 为什么需要自动化运维？

在深入代码之前，我们先聊聊为什么这件事值得做。Wan2.1-UMT5这类大模型WebUI服务，通常需要长时间运行以处理推理请求。但在实际运行中，可能会遇到几个头疼的问题：

• 进程意外退出：可能是程序内部bug、系统资源不足（如OOM Killer介入），或者依赖服务异常。
• GPU显存泄漏：长时间运行后，显存未被完全释放，逐渐累积直至占满，导致新的推理任务无法执行，服务“假死”。
• 响应超时或无响应：服务进程还在，但已经无法正常处理请求，需要重启才能恢复。

手动解决这些问题，意味着你需要时刻盯着，或者准备好随时响应告警。而一个简单的Shell脚本，就能把这些重复、枯燥且要求及时响应的任务自动化，极大提升服务的可靠性和你的运维幸福感。

2. 环境准备与脚本规划

我们的目标是编写一个功能完整的监控脚本。在动手之前，确保你的环境已经准备好。

2.1 基础环境确认

这个脚本主要针对Linux环境，尤其是Ubuntu、CentOS等常见的发行版。你需要有：

• 一个已经安装并可以正常启动的Wan2.1-UMT5 WebUI服务。
• bash环境（绝大多数Linux系统默认已安装）。
• 基本的命令行操作权限。
• 如果要用GPU监控，需要安装nvidia-smi工具（通常安装CUDA驱动后会自带）。

你可以通过以下命令快速检查：

# 检查bash which bash # 检查nvidia-smi (如果使用GPU) nvidia-smi --help | head -5

2.2 脚本功能设计

我们的脚本monitor_wan2_umt5.sh将实现以下核心功能，你可以根据需求增减：

1. 服务存活检查：判断Wan2.1-UMT5的WebUI进程是否在运行。
2. GPU显存监控（可选）：检查GPU显存使用率是否超过安全阈值。
3. 自动重启：当服务不存活或GPU异常时，执行重启命令。
4. 日志记录：将所有检查、操作及时间戳记录到日志文件，方便溯源。
5. 通知发送（可选）：在服务重启后，通过邮件、钉钉机器人、企业微信等渠道发送通知。

3. 手把手编写监控脚本

接下来，我们一步步构建这个脚本。我会先给出完整脚本，然后拆解关键部分讲解。

3.1 完整脚本示例

创建一个新文件，比如monitor_wan2_umt5.sh，将以下内容复制进去：

#!/bin/bash # ============================================ # Wan2.1-UMT5 服务监控与自动重启脚本 # 功能：检查进程、监控GPU、自动重启、记录日志 # ============================================ # ---------- 配置区 (请根据实际情况修改) ---------- SERVICE_NAME="Wan2.1-UMT5 WebUI" # 服务名称，用于日志和通知 PROCESS_KEYWORD="python.*app.py" # 用于识别进程的关键词，根据你的启动命令调整 RESTART_CMD="cd /path/to/your/wan2-umt5 && python app.py --port 7860" # 你的启动命令 LOG_FILE="/var/log/wan2_umt5_monitor.log" # 日志文件路径 # GPU监控配置 (如果无需GPU监控，将ENABLE_GPU_MONITOR设为false) ENABLE_GPU_MONITOR=true GPU_ID=0 # 监控的GPU ID，一般是0 GPU_MEMORY_THRESHOLD=90 # 显存使用率阈值(%)，超过此值可能触发重启 # 通知配置 (这里以日志记录代替，实际可集成邮件、钉钉等) NOTICE_MSG="[INFO] 服务状态变化已记录至日志" # ---------- 函数定义 ---------- # 函数：记录日志 log_message() { local level=$1 local msg=$2 echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$level] $msg" | tee -a "$LOG_FILE" } # 函数：检查进程是否存活 check_process() { if pgrep -f "$PROCESS_KEYWORD" > /dev/null; then log_message "INFO" "服务进程存活检查: 正常" return 0 # 存活 else log_message "ERROR" "服务进程存活检查: 未找到进程 ($PROCESS_KEYWORD)" return 1 # 不存活 fi } # 函数：检查GPU显存使用率 check_gpu_memory() { if [ "$ENABLE_GPU_MONITOR" = false ]; then return 0 fi # 使用nvidia-smi获取显存信息 local gpu_info=$(nvidia-smi --query-gpu=memory.used,memory.total --format=csv,noheader,nounits -i $GPU_ID 2>/dev/null) if [ -z "$gpu_info" ]; then log_message "WARNING" "GPU监控: 无法获取GPU信息，请检查nvidia-smi或GPU_ID设置" return 0 fi local used_mem=$(echo $gpu_info | awk -F', ' '{print $1}') local total_mem=$(echo $gpu_info | awk -F', ' '{print $2}') local usage_percent=$(( used_mem * 100 / total_mem )) log_message "INFO" "GPU监控: GPU-$GPU_ID 显存使用 ${used_mem}MB / ${total_mem}MB (${usage_percent}%)" if [ $usage_percent -ge $GPU_MEMORY_THRESHOLD ]; then log_message "ERROR" "GPU监控: GPU-$GPU_ID 显存使用率超过阈值 ${GPU_MEMORY_THRESHOLD}%" return 1 # 显存异常 fi return 0 # 显存正常 } # 函数：重启服务 restart_service() { log_message "INFO" "正在尝试重启服务: $SERVICE_NAME" # 首先尝试温柔地杀死原有进程 pkill -f "$PROCESS_KEYWORD" sleep 3 # 检查是否还有残留进程 if pgrep -f "$PROCESS_KEYWORD" > /dev/null; then log_message "WARNING" "温柔终止失败，尝试强制终止" pkill -9 -f "$PROCESS_KEYWORD" sleep 2 fi # 启动新进程 (后台运行，并将输出重定向到日志) eval "nohup $RESTART_CMD >> ${LOG_FILE}.service 2>&1 &" local pid=$! sleep 5 # 等待服务启动 # 验证是否启动成功 if check_process; then log_message "INFO" "服务重启成功！新进程信息: $(pgrep -f \"$PROCESS_KEYWORD\")" # 此处可调用发送通知的函数，例如：send_notification "服务重启成功" echo "$NOTICE_MSG" return 0 else log_message "CRITICAL" "服务重启失败！请手动检查。" # 此处可调用发送紧急通知的函数 return 1 fi } # ---------- 主逻辑 ---------- log_message "INFO" "========== 开始服务监控检查 ==========" # 检查1: 进程是否存活 if ! check_process; then log_message "ERROR" "服务进程已停止，即将尝试自动重启。" restart_service exit $? # 退出脚本，返回重启函数的状态码 fi # 检查2: GPU显存是否异常 (如果启用) if ! check_gpu_memory; then log_message "ERROR” “GPU显存使用异常，为避免服务假死，即将尝试重启服务。” restart_service exit $? fi log_message “INFO” “服务检查全部通过，运行状态健康。” log_message “INFO” “========== 本次监控检查结束 ==========” echo “”

3.2 脚本关键点讲解

现在，我们来拆解一下这个脚本，看看每一部分是怎么工作的。

配置区：这是你需要重点修改的地方。

• PROCESS_KEYWORD：这个很重要，脚本靠它来识别你的Wan2.1-UMT5进程。打开你的终端，运行ps aux | grep python，找到你启动WebUI的那行命令，提取出唯一的关键词。比如你的启动命令是python app.py --share，那么关键词可以设为”python.*app.py”。
• RESTART_CMD：填入你平时手动启动服务的完整命令。确保路径和参数都正确。
• LOG_FILE：指定日志存放的位置。确保运行脚本的用户有该目录的写入权限。

进程检查 (check_process)：利用pgrep -f命令，通过我们设置的关键词在系统所有进程中查找。找到就返回正常，找不到就说明服务挂了。

GPU检查 (check_gpu_memory)：通过nvidia-smi这个英伟达显卡管理工具，查询指定GPU的显存使用量和总量，然后计算出使用百分比。如果超过了我们设定的阈值（比如90%），就认为需要重启来释放显存。

重启服务 (restart_service)：这是脚本的核心动作。

1. 先用pkill根据关键词终止旧进程。
2. 等待几秒后，用pgrep检查是否真的杀死了，如果还在，就用pkill -9强制杀死。
3. 最后用nohup ... &的方式，在后台运行我们的启动命令，并将输出重定向到另一个日志文件（${LOG_FILE}.service），避免和监控日志混在一起。
4. 等待几秒后，再次调用check_process函数，确认新进程是否成功启动。

日志记录 (log_message)：所有重要操作和信息都通过这个函数记录。tee -a命令既能将信息打印在屏幕上，也能追加写入日志文件，非常方便调试和回溯。

4. 如何让脚本自动跑起来？

脚本写好了，总不能每次都手动执行吧？我们需要让它定时自动运行。

4.1 给脚本执行权限

在脚本所在目录，执行：

chmod +x monitor_wan2_umt5.sh

4.2 测试脚本

首先，我们手动运行一下，看看是否报错，逻辑是否正确。

# 先确保你的Wan2.1-UMT5服务是运行状态 ./monitor_wan2_umt5.sh

查看屏幕输出和LOG_FILE指定的日志文件，确认检查过程无误。

然后，我们可以模拟一下故障。手动停止你的WebUI服务，再次运行脚本。你应该能看到脚本检测到进程消失，并尝试自动重启的日志。去检查一下服务端口（如7860）是否重新监听了。

4.3 配置定时任务（Cron）

Linux系统自带的cron服务是定时任务的绝佳工具。我们的目标是让脚本每分钟检查一次。

1. 打开当前用户的cron配置表：

   crontab -e

2. 在文件末尾添加一行（请将/path/to/your/script/替换为你的脚本绝对路径）：

   * * * * * /bin/bash /path/to/your/script/monitor_wan2_umt5.sh

   * * * * *表示“每分钟”。如果你想每5分钟检查一次，可以改成*/5 * * * *。

3. 保存并退出。cron会自动加载新的配置。

现在，你的脚本就会每分钟自动执行一次，默默守护你的Wan2.1-UMT5服务了。你可以通过tail -f /var/log/wan2_umt5_monitor.log来实时查看监控日志。

5. 进阶优化与思路

基础的监控和重启功能已经实现，但我们可以让它更强大、更贴心。

5.1 添加更智能的通知

脚本中的通知部分目前只是打印日志。你可以集成真正的通知渠道：

• 邮件通知：使用mail命令或sendmail。
• 钉钉/企业微信机器人：使用curl命令调用机器人的Webhook地址，发送JSON格式的消息。
• 短信/电话报警：可以调用一些云服务商提供的API。

建议将通知封装成一个函数，如send_notification()，在restart_service函数中成功或失败时调用。

5.2 防止重启风暴

如果服务本身有致命问题，导致一启动就崩溃，那么监控脚本会每分钟重启一次，形成“重启风暴”，可能加重系统负载。可以加入简单的熔断机制：

• 记录重启次数：在日志或一个临时文件中记录短时间内（如10分钟）的重启次数。
• 设置上限：当重启次数超过阈值（如5次），则停止尝试重启，并发送最高级别的报警，通知人工介入。

5.3 监控更多指标

除了进程和显存，还可以监控：

• 服务端口响应：使用curl或nc命令检查WebUI的端口（如7860）是否真的能响应HTTP请求，这能发现“进程在但服务已死”的情况。
• 系统负载/内存：监控整个系统的负载和内存使用情况，避免因系统资源耗尽导致服务异常。
• 服务特定API：如果服务提供了健康检查API，直接调用它来判断服务内部状态是最准确的。

6. 总结

整套方案实践下来，其实并不复杂，核心就是一个百来行的Shell脚本，加上系统的Cron定时任务。但它带来的收益是实实在在的：你再也不用时刻担心服务会不会挂掉，半夜被报警吵醒的次数也会大大减少。这个脚本的框架是通用的，你完全可以根据自己服务的具体启动命令、监控需求和报警偏好进行调整和增强。

自动化运维的精髓不在于工具多高级，而在于将重复、规律性的操作固化下来。从这个简单的监控脚本开始，你可以逐步构建起更完善的运维体系，比如结合更专业的监控系统（如Prometheus+Grafana），或者使用容器化技术（如Docker）来获得更一致的环境和更便捷的启停控制。但无论如何，让机器去做机器该做的事，把自己解放出来专注于更重要的任务，这才是技术进步带给我们的便利。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。