5分钟学会DeOldify图像上色服务监控日志分析、健康检查、自动恢复1. 为什么你的AI服务需要监控想象一下这个场景你花了不少时间部署好了DeOldify图像上色服务看着它把一张张黑白老照片变得色彩鲜艳心里挺有成就感。但几天后你发现服务突然打不开了用户上传图片一直转圈圈最后显示“服务不可用”。你赶紧登录服务器发现服务进程早就挂了而且你完全不知道是什么时候、因为什么原因挂掉的。这就是没有监控的后果。AI服务不是部署完就一劳永逸了它需要持续运行会遇到各种问题内存不够用了、模型加载出错了、请求太多处理不过来了或者就是莫名其妙崩溃了。如果没有监控这些问题就像定时炸弹随时可能爆炸影响用户体验。今天我要分享的就是一套简单实用的监控方案让你用5分钟时间给DeOldify服务装上“眼睛”和“大脑”——能发现问题、能自动修复。这套方案包含三个核心部分日志分析让你知道发生了什么健康检查让你提前预防问题自动恢复让你睡个安稳觉。2. 第一步搭建日志系统让服务“开口说话”2.1 配置日志记录一切日志就像是服务的日记本它会把所有重要的事情都记下来。我们先给DeOldify服务配置一个完善的日志系统。打开你的app.py文件在开头添加日志配置# app.py开头添加 import logging import logging.handlers from pathlib import Path import os # 创建日志目录 log_dir Path(/root/cv_unet_image-colorization/logs) log_dir.mkdir(exist_okTrue) # 配置日志格式 log_format %(asctime)s - %(name)s - %(levelname)s - %(message)s # 主服务日志 service_logger logging.getLogger(deoldify_service) service_logger.setLevel(logging.INFO) # 文件处理器 - 按大小轮转最多保留5个10MB的文件 file_handler logging.handlers.RotatingFileHandler( log_dir / service.log, maxBytes10*1024*1024, # 10MB backupCount5, encodingutf-8 ) file_handler.setFormatter(logging.Formatter(log_format)) service_logger.addHandler(file_handler) # 控制台也输出 console_handler logging.StreamHandler() console_handler.setFormatter(logging.Formatter(log_format)) service_logger.addHandler(console_handler) # 错误日志单独记录 error_logger logging.getLogger(deoldify_error) error_logger.setLevel(logging.ERROR) error_handler logging.handlers.RotatingFileHandler( log_dir / error.log, maxBytes5*1024*1024, backupCount3, encodingutf-8 ) error_handler.setFormatter(logging.Formatter(log_format)) error_logger.addHandler(error_handler) # 访问日志 - 记录所有API请求 access_logger logging.getLogger(deoldify_access) access_logger.setLevel(logging.INFO) access_handler logging.handlers.RotatingFileHandler( log_dir / access.log, maxBytes10*1024*1024, backupCount5, encodingutf-8 ) access_handler.setFormatter(logging.Formatter(%(asctime)s - %(message)s)) access_logger.addHandler(access_handler)然后在你的Flask路由里加上日志记录app.route(/colorize, methods[POST]) def colorize_image(): access_logger.info(f收到上色请求文件大小: {request.content_length} bytes) try: # 处理图片... service_logger.info(图片处理完成) return jsonify({status: success, result: result_url}) except Exception as e: error_logger.error(f图片处理失败: {str(e)}, exc_infoTrue) return jsonify({status: error, message: str(e)}), 5002.2 实时监控日志快速发现问题配置好日志后我们怎么用呢这里有几个超级实用的命令让你一眼就能看出服务状态。创建一个监控脚本monitor_logs.sh#!/bin/bash # /root/cv_unet_image-colorization/scripts/monitor_logs.sh LOG_DIR/root/cv_unet_image-colorization/logs echo DeOldify服务日志监控 echo 监控时间: $(date) echo # 1. 查看最近错误 echo 1. 最近10条错误日志: tail -10 $LOG_DIR/error.log 2/dev/null || echo 暂无错误日志 echo # 2. 统计今天错误数量 today$(date %Y-%m-%d) error_count$(grep -c $today.*ERROR $LOG_DIR/error.log 2/dev/null || echo 0) echo 2. 今日错误总数: $error_count # 3. 查看服务状态 echo 3. 服务运行状态: if pgrep -f gunicorn.*app:app /dev/null; then echo ✅ 服务正在运行 else echo ❌ 服务已停止 fi echo # 4. 查看内存使用 echo 4. 内存使用情况: if pgrep -f gunicorn.*app:app /dev/null; then pid$(pgrep -f gunicorn.*app:app | head -1) memory_mb$(ps -p $pid -o rss | awk {print $1/1024}) echo 进程内存占用: ${memory_mb:.1f} MB else echo 服务未运行 fi echo # 5. 查看最近请求 echo 5. 最近5次请求: tail -5 $LOG_DIR/access.log 2/dev/null || echo 暂无访问日志给脚本执行权限然后运行chmod x /root/cv_unet_image-colorization/scripts/monitor_logs.sh /root/cv_unet_image-colorization/scripts/monitor_logs.sh你会看到类似这样的输出 DeOldify服务日志监控 监控时间: 2024-01-15 14:30:00 1. 最近10条错误日志: 2024-01-15 14:25:03 - deoldify_error - ERROR - 图片处理失败: CUDA out of memory 2. 今日错误总数: 3 3. 服务运行状态: ✅ 服务正在运行 4. 内存使用情况: 进程内存占用: 1567.3 MB 5. 最近5次请求: 2024-01-15 14:28:15 - 收到上色请求文件大小: 2456789 bytes2.3 实用日志分析技巧除了看实时日志你还可以用这些命令快速分析问题# 查看服务启动以来的总请求数 grep -c 收到上色请求 /root/cv_unet_image-colorization/logs/access.log # 找出最耗时的请求假设你记录了处理时间 grep 处理完成 /root/cv_unet_image-colorization/logs/service.log | \ awk -F耗时 {print $2} | sort -nr | head -5 # 统计每种错误出现的次数 grep ERROR /root/cv_unet_image-colorization/logs/error.log | \ awk -F- {print $NF} | sort | uniq -c | sort -nr # 实时监控错误日志新开一个终端窗口 tail -f /root/cv_unet_image-colorization/logs/error.log3. 第二步健康检查给服务做“体检”3.1 创建健康检查接口光有日志还不够我们需要主动去检查服务是否健康。首先在Flask应用里添加一个健康检查接口。在app.py中添加app.route(/health, methods[GET]) def health_check(): 健康检查接口 health_status { status: healthy, timestamp: datetime.now().isoformat(), service: DeOldify Image Colorization, checks: {} } # 检查1: 服务是否运行 health_status[checks][service_running] True # 检查2: 模型是否加载 try: # 这里检查你的模型是否正常加载 # 假设你有一个全局的model变量 if model in globals() and model is not None: health_status[checks][model_loaded] True else: health_status[checks][model_loaded] False health_status[status] unhealthy except: health_status[checks][model_loaded] False health_status[status] unhealthy # 检查3: 磁盘空间 import shutil disk_usage shutil.disk_usage(/) disk_free_gb disk_usage.free / (1024**3) health_status[checks][disk_space_gb] round(disk_free_gb, 2) if disk_free_gb 5: # 小于5GB警告 health_status[status] warning # 检查4: 内存使用 import psutil memory psutil.virtual_memory() health_status[checks][memory_percent] memory.percent if memory.percent 90: health_status[status] warning return jsonify(health_status)现在访问http://你的服务器IP:7860/health你会看到这样的JSON响应{ status: healthy, timestamp: 2024-01-15T14:30:00.123456, service: DeOldify Image Colorization, checks: { service_running: true, model_loaded: true, disk_space_gb: 25.67, memory_percent: 65.3 } }3.2 自动健康检查脚本手动检查太麻烦我们写个脚本自动检查。创建health_check.py#!/usr/bin/env python3 # /root/cv_unet_image-colorization/scripts/health_check.py import requests import json import time from datetime import datetime import smtplib from email.mime.text import MIMEText def check_service_health(): 检查服务健康状态 try: # 尝试访问健康检查接口 response requests.get(http://localhost:7860/health, timeout10) if response.status_code 200: data response.json() # 记录检查结果 log_entry { timestamp: datetime.now().isoformat(), status: data.get(status, unknown), checks: data.get(checks, {}), response_time: response.elapsed.total_seconds() } # 保存到日志文件 with open(/root/cv_unet_image-colorization/logs/health.log, a) as f: f.write(json.dumps(log_entry) \n) # 如果不健康发送告警 if data[status] ! healthy: send_alert(f服务不健康: {data[status]}, json.dumps(data, indent2)) return False return True else: # 服务无法访问 log_entry { timestamp: datetime.now().isoformat(), status: down, error: fHTTP {response.status_code}, response_time: response.elapsed.total_seconds() if hasattr(response, elapsed) else None } with open(/root/cv_unet_image-colorization/logs/health.log, a) as f: f.write(json.dumps(log_entry) \n) send_alert(服务无法访问, fHTTP状态码: {response.status_code}) return False except requests.exceptions.RequestException as e: # 连接错误 log_entry { timestamp: datetime.now().isoformat(), status: down, error: str(e) } with open(/root/cv_unet_image-colorization/logs/health.log, a) as f: f.write(json.dumps(log_entry) \n) send_alert(服务连接失败, str(e)) return False def send_alert(subject, message): 发送告警邮件可选 # 这里可以配置邮件发送 # 或者使用其他告警方式如钉钉、企业微信、Slack等 print(f[ALERT] {subject}: {message}) # 简单示例记录到告警日志 with open(/root/cv_unet_image-colorization/logs/alert.log, a) as f: f.write(f{datetime.now().isoformat()} - {subject}: {message}\n) if __name__ __main__: is_healthy check_service_health() if is_healthy: print(f{datetime.now().isoformat()} - 服务健康检查通过) else: print(f{datetime.now().isoformat()} - 服务健康检查失败) # 这里可以添加自动恢复逻辑 # 比如重启服务 import subprocess subprocess.run([supervisorctl, restart, cv-unet-colorization])3.3 设置定时检查让系统每5分钟自动检查一次。创建定时任务# 编辑crontab crontab -e # 添加这行每5分钟检查一次 */5 * * * * /usr/bin/python3 /root/cv_unet_image-colorization/scripts/health_check.py /root/cv_unet_image-colorization/logs/cron.log 21现在你的服务就会每5分钟自动“体检”一次发现问题会自动记录还能发送告警。4. 第三步自动恢复让服务“自己治病”4.1 用Supervisor管理服务进程Supervisor是个进程管理工具能让你的服务在崩溃后自动重启。如果你还没安装先安装一下pip install supervisor创建Supervisor配置文件/etc/supervisor/conf.d/deoldify.conf[program:deoldify] directory/root/cv_unet_image-colorization command/usr/local/bin/gunicorn --bind 0.0.0.0:7860 --workers 2 --timeout 120 app:app userroot autostarttrue autorestarttrue startsecs10 startretries3 stopwaitsecs30 stdout_logfile/root/cv_unet_image-colorization/logs/supervisor.out.log stdout_logfile_maxbytes10MB stdout_logfile_backups5 stderr_logfile/root/cv_unet_image-colorization/logs/supervisor.err.log stderr_logfile_maxbytes10MB stderr_logfile_backups5 environmentPYTHONPATH/root/cv_unet_image-colorization ; 重定向Python输出 redirect_stderrtrue启动Supervisor并启用配置# 启动supervisor supervisord -c /etc/supervisor/supervisord.conf # 更新配置 supervisorctl update # 启动服务 supervisorctl start deoldify # 查看状态 supervisorctl status deoldify你会看到类似这样的输出deoldify RUNNING pid 12345, uptime 0:05:304.2 智能重启策略有时候服务崩溃是有原因的比如内存泄漏。如果只是简单重启可能很快又会崩溃。我们需要一个更智能的重启策略。创建智能重启脚本smart_restart.sh#!/bin/bash # /root/cv_unet_image-colorization/scripts/smart_restart.sh RESTART_LOG/root/cv_unet_image-colorization/logs/restart.log ERROR_LOG/root/cv_unet_image-colorization/logs/error.log echo $(date): 开始检查服务状态... $RESTART_LOG # 检查服务是否运行 if ! supervisorctl status deoldify | grep -q RUNNING; then echo $(date): 服务未运行检查崩溃原因... $RESTART_LOG # 检查最近错误 last_error$(tail -n 20 $ERROR_LOG | grep -i error\|exception\|traceback | tail -n 1) # 如果是内存错误先清理内存 if echo $last_error | grep -qi memory\|oom\|out of memory; then echo $(date): 检测到内存错误清理内存缓存... $RESTART_LOG sync echo 1 /proc/sys/vm/drop_caches echo 2 /proc/sys/vm/drop_caches echo 3 /proc/sys/vm/drop_caches sleep 5 fi # 如果是模型加载错误可能需要重新下载模型 if echo $last_error | grep -qi model\|load\|weight; then echo $(date): 检测到模型加载错误尝试修复... $RESTART_LOG # 这里可以添加模型修复逻辑 fi # 重启服务 echo $(date): 尝试重启服务... $RESTART_LOG supervisorctl restart deoldify # 等待并检查重启结果 sleep 30 if supervisorctl status deoldify | grep -q RUNNING; then echo $(date): 服务重启成功 $RESTART_LOG else echo $(date): 服务重启失败需要人工干预 $RESTART_LOG # 这里可以发送紧急告警 fi else echo $(date): 服务运行正常 $RESTART_LOG fi然后设置定时检查比如每分钟检查一次# 编辑crontab crontab -e # 添加这行 * * * * * /bin/bash /root/cv_unet_image-colorization/scripts/smart_restart.sh4.3 完整的监控与恢复脚本把前面所有的功能整合到一个脚本里创建full_monitor.sh#!/bin/bash # /root/cv_unet_image-colorization/scripts/full_monitor.sh LOG_DIR/root/cv_unet_image-colorization/logs TIMESTAMP$(date %Y-%m-%d %H:%M:%S) echo 完整监控检查 - $TIMESTAMP $LOG_DIR/monitor.log # 1. 检查磁盘空间 DISK_USAGE$(df -h / | awk NR2 {print $5} | sed s/%//) if [ $DISK_USAGE -gt 90 ]; then echo $TIMESTAMP - 警告: 磁盘使用率 ${DISK_USAGE}% $LOG_DIR/monitor.log # 清理临时文件 find /tmp -name *.jpg -mtime 1 -delete 2/dev/null find /tmp -name *.png -mtime 1 -delete 2/dev/null fi # 2. 检查内存使用 MEMORY_FREE$(free -m | awk /Mem:/ {print $4}) if [ $MEMORY_FREE -lt 500 ]; then echo $TIMESTAMP - 警告: 可用内存不足 ${MEMORY_FREE}MB $LOG_DIR/monitor.log # 清理内存缓存 sync echo 3 /proc/sys/vm/drop_caches fi # 3. 检查服务进程 if ! pgrep -f gunicorn.*app:app /dev/null; then echo $TIMESTAMP - 错误: 服务进程不存在 $LOG_DIR/monitor.log # 尝试通过supervisor重启 supervisorctl restart deoldify fi # 4. 检查端口监听 if ! netstat -tlnp | grep -q :7860; then echo $TIMESTAMP - 错误: 端口7860未监听 $LOG_DIR/monitor.log supervisorctl restart deoldify fi # 5. 检查API响应 API_RESPONSE$(curl -s -o /dev/null -w %{http_code} http://localhost:7860/health --max-time 10) if [ $API_RESPONSE ! 200 ]; then echo $TIMESTAMP - 错误: API响应异常 (HTTP $API_RESPONSE) $LOG_DIR/monitor.log supervisorctl restart deoldify fi # 6. 检查错误日志频率 RECENT_ERRORS$(tail -100 $LOG_DIR/error.log | grep -c $(date %Y-%m-%d)) if [ $RECENT_ERRORS -gt 10 ]; then echo $TIMESTAMP - 警告: 今日错误数过多 ($RECENT_ERRORS 个) $LOG_DIR/monitor.log fi echo $TIMESTAMP - 监控检查完成 $LOG_DIR/monitor.log设置每小时运行一次# 编辑crontab crontab -e # 添加这行 0 * * * * /bin/bash /root/cv_unet_image-colorization/scripts/full_monitor.sh5. 总结你的5分钟监控套餐好了现在你已经有了一个完整的监控系统。让我帮你回顾一下这5分钟都做了什么第一步日志系统1分钟配置了三种日志服务日志、错误日志、访问日志学会了用几个简单命令查看和分析日志服务现在会“说话”了有问题它会告诉你第二步健康检查2分钟添加了健康检查接口随时知道服务状态设置了定时检查每5分钟自动“体检”发现问题会自动记录和告警第三步自动恢复2分钟用Supervisor管理进程崩溃了自动重启实现了智能重启不同问题不同处理完整的监控脚本每小时全面检查一次现在你的DeOldify服务有了眼睛日志系统看到所有问题体检健康检查提前发现问题自愈自动恢复小病自己治报告监控日志随时查看状态这套系统虽然简单但能解决80%的常见问题。最重要的是它能让你安心——不用时刻盯着服务有问题系统会自己处理处理不了会告诉你。最后给个小建议先部署日志和健康检查运行几天看看效果然后再加自动恢复。监控系统也需要“监控”根据实际运行情况调整参数比如检查频率、内存阈值等。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
5分钟学会DeOldify图像上色服务监控：日志分析、健康检查、自动恢复
5分钟学会DeOldify图像上色服务监控日志分析、健康检查、自动恢复1. 为什么你的AI服务需要监控想象一下这个场景你花了不少时间部署好了DeOldify图像上色服务看着它把一张张黑白老照片变得色彩鲜艳心里挺有成就感。但几天后你发现服务突然打不开了用户上传图片一直转圈圈最后显示“服务不可用”。你赶紧登录服务器发现服务进程早就挂了而且你完全不知道是什么时候、因为什么原因挂掉的。这就是没有监控的后果。AI服务不是部署完就一劳永逸了它需要持续运行会遇到各种问题内存不够用了、模型加载出错了、请求太多处理不过来了或者就是莫名其妙崩溃了。如果没有监控这些问题就像定时炸弹随时可能爆炸影响用户体验。今天我要分享的就是一套简单实用的监控方案让你用5分钟时间给DeOldify服务装上“眼睛”和“大脑”——能发现问题、能自动修复。这套方案包含三个核心部分日志分析让你知道发生了什么健康检查让你提前预防问题自动恢复让你睡个安稳觉。2. 第一步搭建日志系统让服务“开口说话”2.1 配置日志记录一切日志就像是服务的日记本它会把所有重要的事情都记下来。我们先给DeOldify服务配置一个完善的日志系统。打开你的app.py文件在开头添加日志配置# app.py开头添加 import logging import logging.handlers from pathlib import Path import os # 创建日志目录 log_dir Path(/root/cv_unet_image-colorization/logs) log_dir.mkdir(exist_okTrue) # 配置日志格式 log_format %(asctime)s - %(name)s - %(levelname)s - %(message)s # 主服务日志 service_logger logging.getLogger(deoldify_service) service_logger.setLevel(logging.INFO) # 文件处理器 - 按大小轮转最多保留5个10MB的文件 file_handler logging.handlers.RotatingFileHandler( log_dir / service.log, maxBytes10*1024*1024, # 10MB backupCount5, encodingutf-8 ) file_handler.setFormatter(logging.Formatter(log_format)) service_logger.addHandler(file_handler) # 控制台也输出 console_handler logging.StreamHandler() console_handler.setFormatter(logging.Formatter(log_format)) service_logger.addHandler(console_handler) # 错误日志单独记录 error_logger logging.getLogger(deoldify_error) error_logger.setLevel(logging.ERROR) error_handler logging.handlers.RotatingFileHandler( log_dir / error.log, maxBytes5*1024*1024, backupCount3, encodingutf-8 ) error_handler.setFormatter(logging.Formatter(log_format)) error_logger.addHandler(error_handler) # 访问日志 - 记录所有API请求 access_logger logging.getLogger(deoldify_access) access_logger.setLevel(logging.INFO) access_handler logging.handlers.RotatingFileHandler( log_dir / access.log, maxBytes10*1024*1024, backupCount5, encodingutf-8 ) access_handler.setFormatter(logging.Formatter(%(asctime)s - %(message)s)) access_logger.addHandler(access_handler)然后在你的Flask路由里加上日志记录app.route(/colorize, methods[POST]) def colorize_image(): access_logger.info(f收到上色请求文件大小: {request.content_length} bytes) try: # 处理图片... service_logger.info(图片处理完成) return jsonify({status: success, result: result_url}) except Exception as e: error_logger.error(f图片处理失败: {str(e)}, exc_infoTrue) return jsonify({status: error, message: str(e)}), 5002.2 实时监控日志快速发现问题配置好日志后我们怎么用呢这里有几个超级实用的命令让你一眼就能看出服务状态。创建一个监控脚本monitor_logs.sh#!/bin/bash # /root/cv_unet_image-colorization/scripts/monitor_logs.sh LOG_DIR/root/cv_unet_image-colorization/logs echo DeOldify服务日志监控 echo 监控时间: $(date) echo # 1. 查看最近错误 echo 1. 最近10条错误日志: tail -10 $LOG_DIR/error.log 2/dev/null || echo 暂无错误日志 echo # 2. 统计今天错误数量 today$(date %Y-%m-%d) error_count$(grep -c $today.*ERROR $LOG_DIR/error.log 2/dev/null || echo 0) echo 2. 今日错误总数: $error_count # 3. 查看服务状态 echo 3. 服务运行状态: if pgrep -f gunicorn.*app:app /dev/null; then echo ✅ 服务正在运行 else echo ❌ 服务已停止 fi echo # 4. 查看内存使用 echo 4. 内存使用情况: if pgrep -f gunicorn.*app:app /dev/null; then pid$(pgrep -f gunicorn.*app:app | head -1) memory_mb$(ps -p $pid -o rss | awk {print $1/1024}) echo 进程内存占用: ${memory_mb:.1f} MB else echo 服务未运行 fi echo # 5. 查看最近请求 echo 5. 最近5次请求: tail -5 $LOG_DIR/access.log 2/dev/null || echo 暂无访问日志给脚本执行权限然后运行chmod x /root/cv_unet_image-colorization/scripts/monitor_logs.sh /root/cv_unet_image-colorization/scripts/monitor_logs.sh你会看到类似这样的输出 DeOldify服务日志监控 监控时间: 2024-01-15 14:30:00 1. 最近10条错误日志: 2024-01-15 14:25:03 - deoldify_error - ERROR - 图片处理失败: CUDA out of memory 2. 今日错误总数: 3 3. 服务运行状态: ✅ 服务正在运行 4. 内存使用情况: 进程内存占用: 1567.3 MB 5. 最近5次请求: 2024-01-15 14:28:15 - 收到上色请求文件大小: 2456789 bytes2.3 实用日志分析技巧除了看实时日志你还可以用这些命令快速分析问题# 查看服务启动以来的总请求数 grep -c 收到上色请求 /root/cv_unet_image-colorization/logs/access.log # 找出最耗时的请求假设你记录了处理时间 grep 处理完成 /root/cv_unet_image-colorization/logs/service.log | \ awk -F耗时 {print $2} | sort -nr | head -5 # 统计每种错误出现的次数 grep ERROR /root/cv_unet_image-colorization/logs/error.log | \ awk -F- {print $NF} | sort | uniq -c | sort -nr # 实时监控错误日志新开一个终端窗口 tail -f /root/cv_unet_image-colorization/logs/error.log3. 第二步健康检查给服务做“体检”3.1 创建健康检查接口光有日志还不够我们需要主动去检查服务是否健康。首先在Flask应用里添加一个健康检查接口。在app.py中添加app.route(/health, methods[GET]) def health_check(): 健康检查接口 health_status { status: healthy, timestamp: datetime.now().isoformat(), service: DeOldify Image Colorization, checks: {} } # 检查1: 服务是否运行 health_status[checks][service_running] True # 检查2: 模型是否加载 try: # 这里检查你的模型是否正常加载 # 假设你有一个全局的model变量 if model in globals() and model is not None: health_status[checks][model_loaded] True else: health_status[checks][model_loaded] False health_status[status] unhealthy except: health_status[checks][model_loaded] False health_status[status] unhealthy # 检查3: 磁盘空间 import shutil disk_usage shutil.disk_usage(/) disk_free_gb disk_usage.free / (1024**3) health_status[checks][disk_space_gb] round(disk_free_gb, 2) if disk_free_gb 5: # 小于5GB警告 health_status[status] warning # 检查4: 内存使用 import psutil memory psutil.virtual_memory() health_status[checks][memory_percent] memory.percent if memory.percent 90: health_status[status] warning return jsonify(health_status)现在访问http://你的服务器IP:7860/health你会看到这样的JSON响应{ status: healthy, timestamp: 2024-01-15T14:30:00.123456, service: DeOldify Image Colorization, checks: { service_running: true, model_loaded: true, disk_space_gb: 25.67, memory_percent: 65.3 } }3.2 自动健康检查脚本手动检查太麻烦我们写个脚本自动检查。创建health_check.py#!/usr/bin/env python3 # /root/cv_unet_image-colorization/scripts/health_check.py import requests import json import time from datetime import datetime import smtplib from email.mime.text import MIMEText def check_service_health(): 检查服务健康状态 try: # 尝试访问健康检查接口 response requests.get(http://localhost:7860/health, timeout10) if response.status_code 200: data response.json() # 记录检查结果 log_entry { timestamp: datetime.now().isoformat(), status: data.get(status, unknown), checks: data.get(checks, {}), response_time: response.elapsed.total_seconds() } # 保存到日志文件 with open(/root/cv_unet_image-colorization/logs/health.log, a) as f: f.write(json.dumps(log_entry) \n) # 如果不健康发送告警 if data[status] ! healthy: send_alert(f服务不健康: {data[status]}, json.dumps(data, indent2)) return False return True else: # 服务无法访问 log_entry { timestamp: datetime.now().isoformat(), status: down, error: fHTTP {response.status_code}, response_time: response.elapsed.total_seconds() if hasattr(response, elapsed) else None } with open(/root/cv_unet_image-colorization/logs/health.log, a) as f: f.write(json.dumps(log_entry) \n) send_alert(服务无法访问, fHTTP状态码: {response.status_code}) return False except requests.exceptions.RequestException as e: # 连接错误 log_entry { timestamp: datetime.now().isoformat(), status: down, error: str(e) } with open(/root/cv_unet_image-colorization/logs/health.log, a) as f: f.write(json.dumps(log_entry) \n) send_alert(服务连接失败, str(e)) return False def send_alert(subject, message): 发送告警邮件可选 # 这里可以配置邮件发送 # 或者使用其他告警方式如钉钉、企业微信、Slack等 print(f[ALERT] {subject}: {message}) # 简单示例记录到告警日志 with open(/root/cv_unet_image-colorization/logs/alert.log, a) as f: f.write(f{datetime.now().isoformat()} - {subject}: {message}\n) if __name__ __main__: is_healthy check_service_health() if is_healthy: print(f{datetime.now().isoformat()} - 服务健康检查通过) else: print(f{datetime.now().isoformat()} - 服务健康检查失败) # 这里可以添加自动恢复逻辑 # 比如重启服务 import subprocess subprocess.run([supervisorctl, restart, cv-unet-colorization])3.3 设置定时检查让系统每5分钟自动检查一次。创建定时任务# 编辑crontab crontab -e # 添加这行每5分钟检查一次 */5 * * * * /usr/bin/python3 /root/cv_unet_image-colorization/scripts/health_check.py /root/cv_unet_image-colorization/logs/cron.log 21现在你的服务就会每5分钟自动“体检”一次发现问题会自动记录还能发送告警。4. 第三步自动恢复让服务“自己治病”4.1 用Supervisor管理服务进程Supervisor是个进程管理工具能让你的服务在崩溃后自动重启。如果你还没安装先安装一下pip install supervisor创建Supervisor配置文件/etc/supervisor/conf.d/deoldify.conf[program:deoldify] directory/root/cv_unet_image-colorization command/usr/local/bin/gunicorn --bind 0.0.0.0:7860 --workers 2 --timeout 120 app:app userroot autostarttrue autorestarttrue startsecs10 startretries3 stopwaitsecs30 stdout_logfile/root/cv_unet_image-colorization/logs/supervisor.out.log stdout_logfile_maxbytes10MB stdout_logfile_backups5 stderr_logfile/root/cv_unet_image-colorization/logs/supervisor.err.log stderr_logfile_maxbytes10MB stderr_logfile_backups5 environmentPYTHONPATH/root/cv_unet_image-colorization ; 重定向Python输出 redirect_stderrtrue启动Supervisor并启用配置# 启动supervisor supervisord -c /etc/supervisor/supervisord.conf # 更新配置 supervisorctl update # 启动服务 supervisorctl start deoldify # 查看状态 supervisorctl status deoldify你会看到类似这样的输出deoldify RUNNING pid 12345, uptime 0:05:304.2 智能重启策略有时候服务崩溃是有原因的比如内存泄漏。如果只是简单重启可能很快又会崩溃。我们需要一个更智能的重启策略。创建智能重启脚本smart_restart.sh#!/bin/bash # /root/cv_unet_image-colorization/scripts/smart_restart.sh RESTART_LOG/root/cv_unet_image-colorization/logs/restart.log ERROR_LOG/root/cv_unet_image-colorization/logs/error.log echo $(date): 开始检查服务状态... $RESTART_LOG # 检查服务是否运行 if ! supervisorctl status deoldify | grep -q RUNNING; then echo $(date): 服务未运行检查崩溃原因... $RESTART_LOG # 检查最近错误 last_error$(tail -n 20 $ERROR_LOG | grep -i error\|exception\|traceback | tail -n 1) # 如果是内存错误先清理内存 if echo $last_error | grep -qi memory\|oom\|out of memory; then echo $(date): 检测到内存错误清理内存缓存... $RESTART_LOG sync echo 1 /proc/sys/vm/drop_caches echo 2 /proc/sys/vm/drop_caches echo 3 /proc/sys/vm/drop_caches sleep 5 fi # 如果是模型加载错误可能需要重新下载模型 if echo $last_error | grep -qi model\|load\|weight; then echo $(date): 检测到模型加载错误尝试修复... $RESTART_LOG # 这里可以添加模型修复逻辑 fi # 重启服务 echo $(date): 尝试重启服务... $RESTART_LOG supervisorctl restart deoldify # 等待并检查重启结果 sleep 30 if supervisorctl status deoldify | grep -q RUNNING; then echo $(date): 服务重启成功 $RESTART_LOG else echo $(date): 服务重启失败需要人工干预 $RESTART_LOG # 这里可以发送紧急告警 fi else echo $(date): 服务运行正常 $RESTART_LOG fi然后设置定时检查比如每分钟检查一次# 编辑crontab crontab -e # 添加这行 * * * * * /bin/bash /root/cv_unet_image-colorization/scripts/smart_restart.sh4.3 完整的监控与恢复脚本把前面所有的功能整合到一个脚本里创建full_monitor.sh#!/bin/bash # /root/cv_unet_image-colorization/scripts/full_monitor.sh LOG_DIR/root/cv_unet_image-colorization/logs TIMESTAMP$(date %Y-%m-%d %H:%M:%S) echo 完整监控检查 - $TIMESTAMP $LOG_DIR/monitor.log # 1. 检查磁盘空间 DISK_USAGE$(df -h / | awk NR2 {print $5} | sed s/%//) if [ $DISK_USAGE -gt 90 ]; then echo $TIMESTAMP - 警告: 磁盘使用率 ${DISK_USAGE}% $LOG_DIR/monitor.log # 清理临时文件 find /tmp -name *.jpg -mtime 1 -delete 2/dev/null find /tmp -name *.png -mtime 1 -delete 2/dev/null fi # 2. 检查内存使用 MEMORY_FREE$(free -m | awk /Mem:/ {print $4}) if [ $MEMORY_FREE -lt 500 ]; then echo $TIMESTAMP - 警告: 可用内存不足 ${MEMORY_FREE}MB $LOG_DIR/monitor.log # 清理内存缓存 sync echo 3 /proc/sys/vm/drop_caches fi # 3. 检查服务进程 if ! pgrep -f gunicorn.*app:app /dev/null; then echo $TIMESTAMP - 错误: 服务进程不存在 $LOG_DIR/monitor.log # 尝试通过supervisor重启 supervisorctl restart deoldify fi # 4. 检查端口监听 if ! netstat -tlnp | grep -q :7860; then echo $TIMESTAMP - 错误: 端口7860未监听 $LOG_DIR/monitor.log supervisorctl restart deoldify fi # 5. 检查API响应 API_RESPONSE$(curl -s -o /dev/null -w %{http_code} http://localhost:7860/health --max-time 10) if [ $API_RESPONSE ! 200 ]; then echo $TIMESTAMP - 错误: API响应异常 (HTTP $API_RESPONSE) $LOG_DIR/monitor.log supervisorctl restart deoldify fi # 6. 检查错误日志频率 RECENT_ERRORS$(tail -100 $LOG_DIR/error.log | grep -c $(date %Y-%m-%d)) if [ $RECENT_ERRORS -gt 10 ]; then echo $TIMESTAMP - 警告: 今日错误数过多 ($RECENT_ERRORS 个) $LOG_DIR/monitor.log fi echo $TIMESTAMP - 监控检查完成 $LOG_DIR/monitor.log设置每小时运行一次# 编辑crontab crontab -e # 添加这行 0 * * * * /bin/bash /root/cv_unet_image-colorization/scripts/full_monitor.sh5. 总结你的5分钟监控套餐好了现在你已经有了一个完整的监控系统。让我帮你回顾一下这5分钟都做了什么第一步日志系统1分钟配置了三种日志服务日志、错误日志、访问日志学会了用几个简单命令查看和分析日志服务现在会“说话”了有问题它会告诉你第二步健康检查2分钟添加了健康检查接口随时知道服务状态设置了定时检查每5分钟自动“体检”发现问题会自动记录和告警第三步自动恢复2分钟用Supervisor管理进程崩溃了自动重启实现了智能重启不同问题不同处理完整的监控脚本每小时全面检查一次现在你的DeOldify服务有了眼睛日志系统看到所有问题体检健康检查提前发现问题自愈自动恢复小病自己治报告监控日志随时查看状态这套系统虽然简单但能解决80%的常见问题。最重要的是它能让你安心——不用时刻盯着服务有问题系统会自己处理处理不了会告诉你。最后给个小建议先部署日志和健康检查运行几天看看效果然后再加自动恢复。监控系统也需要“监控”根据实际运行情况调整参数比如检查频率、内存阈值等。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
