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 -52.2 脚本功能设计我们的脚本monitor_wan2_umt5.sh将实现以下核心功能你可以根据需求增减服务存活检查判断Wan2.1-UMT5的WebUI进程是否在运行。GPU显存监控可选检查GPU显存使用率是否超过安全阈值。自动重启当服务不存活或GPU异常时执行重启命令。日志记录将所有检查、操作及时间戳记录到日志文件方便溯源。通知发送可选在服务重启后通过邮件、钉钉机器人、企业微信等渠道发送通知。3. 手把手编写监控脚本接下来我们一步步构建这个脚本。我会先给出完整脚本然后拆解关键部分讲解。3.1 完整脚本示例创建一个新文件比如monitor_wan2_umt5.sh将以下内容复制进去#!/bin/bash # # Wan2.1-UMT5 服务监控与自动重启脚本 # 功能检查进程、监控GPU、自动重启、记录日志 # # ---------- 配置区 (请根据实际情况修改) ---------- SERVICE_NAMEWan2.1-UMT5 WebUI # 服务名称用于日志和通知 PROCESS_KEYWORDpython.*app.py # 用于识别进程的关键词根据你的启动命令调整 RESTART_CMDcd /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_MONITORtrue GPU_ID0 # 监控的GPU ID一般是0 GPU_MEMORY_THRESHOLD90 # 显存使用率阈值(%)超过此值可能触发重启 # 通知配置 (这里以日志记录代替实际可集成邮件、钉钉等) 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-gpumemory.used,memory.total --formatcsv,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 21 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)这是脚本的核心动作。先用pkill根据关键词终止旧进程。等待几秒后用pgrep检查是否真的杀死了如果还在就用pkill -9强制杀死。最后用nohup ... 的方式在后台运行我们的启动命令并将输出重定向到另一个日志文件${LOG_FILE}.service避免和监控日志混在一起。等待几秒后再次调用check_process函数确认新进程是否成功启动。日志记录 (log_message)所有重要操作和信息都通过这个函数记录。tee -a命令既能将信息打印在屏幕上也能追加写入日志文件非常方便调试和回溯。4. 如何让脚本自动跑起来脚本写好了总不能每次都手动执行吧我们需要让它定时自动运行。4.1 给脚本执行权限在脚本所在目录执行chmod x monitor_wan2_umt5.sh4.2 测试脚本首先我们手动运行一下看看是否报错逻辑是否正确。# 先确保你的Wan2.1-UMT5服务是运行状态 ./monitor_wan2_umt5.sh查看屏幕输出和LOG_FILE指定的日志文件确认检查过程无误。然后我们可以模拟一下故障。手动停止你的WebUI服务再次运行脚本。你应该能看到脚本检测到进程消失并尝试自动重启的日志。去检查一下服务端口如7860是否重新监听了。4.3 配置定时任务CronLinux系统自带的cron服务是定时任务的绝佳工具。我们的目标是让脚本每分钟检查一次。打开当前用户的cron配置表crontab -e在文件末尾添加一行请将/path/to/your/script/替换为你的脚本绝对路径* * * * * /bin/bash /path/to/your/script/monitor_wan2_umt5.sh* * * * *表示“每分钟”。如果你想每5分钟检查一次可以改成*/5 * * * *。保存并退出。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定时任务。但它带来的收益是实实在在的你再也不用时刻担心服务会不会挂掉半夜被报警吵醒的次数也会大大减少。这个脚本的框架是通用的你完全可以根据自己服务的具体启动命令、监控需求和报警偏好进行调整和增强。自动化运维的精髓不在于工具多高级而在于将重复、规律性的操作固化下来。从这个简单的监控脚本开始你可以逐步构建起更完善的运维体系比如结合更专业的监控系统如PrometheusGrafana或者使用容器化技术如Docker来获得更一致的环境和更便捷的启停控制。但无论如何让机器去做机器该做的事把自己解放出来专注于更重要的任务这才是技术进步带给我们的便利。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。