Docker容器健康检查：stable-diffusion-webui-docker服务可用性监控

Docker容器健康检查：stable-diffusion-webui-docker服务可用性监控

【免费下载链接】stable-diffusion-webui-docker Easy Docker setup for Stable Diffusion with user-friendly UI 项目地址: https://gitcode.com/gh_mirrors/st/stable-diffusion-webui-docker

引言：AI绘画服务中断的隐形代价

你是否遇到过这样的场景：Stable Diffusion WebUI界面显示正常，但生成图片时却无限加载？或API调用返回502错误，却找不到任何错误日志？作为基于Docker部署的AI绘画系统，stable-diffusion-webui-docker虽然简化了安装流程，但服务可用性监控仍是被忽视的关键环节。本文将系统讲解如何为容器化的Stable Diffusion服务构建完整的健康检查体系，通过12个实用配置示例和4种故障自动恢复方案，让你的AI绘画平台达到99.9%的服务可用性。

读完本文你将掌握：

• Docker Compose健康检查配置的5个核心参数
• 针对AUTOMATIC1111和ComfyUI的定制化健康检查脚本
• 服务异常时的自动恢复机制实现
• Prometheus+Grafana监控面板搭建
• 完整的监控告警流程设计

Docker健康检查核心机制

Docker容器健康检查（Health Check）是Docker Engine提供的内置功能，用于定期检测容器内应用的运行状态。与简单的进程存活检测不同，健康检查能深入应用内部，验证服务是否真正可用。

健康检查的三种实现方式

Docker提供三种健康检查方式，适用于不同场景：

检查方式	实现方式	适用场景	优势	局限性
命令检查	CMD ["curl", "-f", "http://localhost:7860"]	简单HTTP服务	配置简单，无需额外依赖	无法处理复杂业务逻辑检查
脚本检查	CMD-SHELL ./healthcheck.sh	复杂应用状态验证	可实现任意复杂度检查逻辑	需要维护额外脚本
无健康检查	未配置HEALTHCHECK	开发环境或简单服务	减少资源消耗	无法检测应用假死状态

对于Stable Diffusion这类AI服务，推荐使用脚本检查方式，因为需要验证的不仅是Web服务可用性，还包括模型加载状态、GPU资源分配等关键指标。

健康检查生命周期

容器健康状态会经历以下状态转换：

Docker Compose中与健康检查相关的核心参数：

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:7860/health"]  # 检查命令
  interval: 30s  # 检查间隔
  timeout: 10s   # 检查超时时间
  retries: 3     # 失败重试次数
  start_period: 300s  # 启动宽限期

stable-diffusion-webui-docker健康检查实现

基础环境分析

通过分析项目的docker-compose.yml文件，我们发现当前配置中缺少健康检查相关设置。现有服务定义如下：

services:
  auto: &automatic
    <<: *base_service
    profiles: ["auto"]
    build: ./services/AUTOMATIC1111
    image: sd-auto:78
    environment:
      - CLI_ARGS=--allow-code --medvram --xformers --enable-insecure-extension-access --api

  comfy: &comfy
    <<: *base_service
    profiles: ["comfy"]
    build: ./services/comfy/
    image: sd-comfy:7
    environment:
      - CLI_ARGS=

这意味着默认配置下，Docker只会检查容器内主进程是否存活，无法发现服务假死、模型加载失败等问题。

针对不同UI的健康检查方案

1. AUTOMATIC1111 WebUI健康检查

AUTOMATIC1111提供了API接口，我们可以通过调用/sdapi/v1/healthcheck端点来验证服务健康状态。

步骤1：创建健康检查脚本

在services/AUTOMATIC1111/目录下创建healthcheck.sh：

#!/bin/bash

# 检查Web服务是否响应
if ! curl -s -o /dev/null "http://localhost:7860"; then
    echo "Web UI未响应"
    exit 1
fi

# 检查API可用性
if ! curl -s -o /dev/null "http://localhost:7860/sdapi/v1/healthcheck"; then
    echo "API接口不可用"
    exit 1
fi

# 检查模型加载状态
MODEL_STATUS=$(curl -s "http://localhost:7860/sdapi/v1/options" | jq -r ".sd_model_checkpoint")
if [ -z "$MODEL_STATUS" ] || [ "$MODEL_STATUS" == "null" ]; then
    echo "未加载任何模型"
    exit 1
fi

# 检查GPU内存使用情况
GPU_MEM=$(nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits)
if [ "$GPU_MEM" -gt 10240 ]; then  # 10GB阈值
    echo "GPU内存使用过高: ${GPU_MEM}MB"
    exit 1
fi

echo "服务健康"
exit 0

步骤2：修改Dockerfile

更新services/AUTOMATIC1111/Dockerfile，添加健康检查依赖和脚本：

# 安装健康检查依赖
RUN apt-get update && apt-get install -y curl jq

# 添加健康检查脚本
COPY healthcheck.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/healthcheck.sh

# 设置健康检查
HEALTHCHECK --interval=30s --timeout=10s --start-period=300s --retries=3 \
  CMD /usr/local/bin/healthcheck.sh

2. ComfyUI健康检查

ComfyUI没有内置健康检查端点，我们需要通过模拟工作流执行来验证服务可用性。

健康检查脚本实现：

#!/bin/bash

# 检查Web服务是否可用
if ! curl -s -o /dev/null "http://localhost:7860"; then
    echo "Web UI未响应"
    exit 1
fi

# 检查自定义节点加载状态
if [ ! -d "/data/config/comfy/custom_nodes" ] || [ -z "$(ls -A /data/config/comfy/custom_nodes)" ]; then
    echo "自定义节点未正确加载"
    exit 1
fi

# 检查模型目录是否存在
REQUIRED_MODELS=("stable-diffusion-v1-5" "vae-ft-mse-840000-ema-pruned")
for model in "${REQUIRED_MODELS[@]}"; do
    if [ ! -f "/data/models/${model}.safetensors" ] && [ ! -f "/data/models/${model}.ckpt" ]; then
        echo "必需模型缺失: ${model}"
        exit 1
    fi
done

# 简单工作流测试
WORKFLOW='{"3": {"inputs": {"seed": 12345, "steps": 10, "cfg": 7.0, "sampler_name": "euler_ancestral", "scheduler": "normal"}, "class_type": "KSampler"}, "4": {"inputs": {"text": "a photo of a cat", "clip": ["6", 1]}, "class_type": "CLIPTextEncode"}, "5": {"inputs": {"text": "", "clip": ["6", 1]}, "class_type": "CLIPTextEncode"}, "6": {"inputs": {"model_name": "stable-diffusion-v1-5"}, "class_type": "CheckpointLoaderSimple"}, "7": {"inputs": {"samples": ["3", 0], "vae": ["6", 2]}, "class_type": "VAEDecode"}, "8": {"inputs": {"filename_prefix": "healthcheck", "images": ["7", 0]}, "class_type": "SaveImage"}}'

RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" -X POST "http://localhost:7860/prompt" \
  -H "Content-Type: application/json" \
  -d "{\"prompt\": ${WORKFLOW}}")

if [ "$RESPONSE" -ne 200 ]; then
    echo "工作流提交失败，HTTP状态码: ${RESPONSE}"
    exit 1
fi

echo "服务健康"
exit 0

Docker Compose健康检查集成

修改项目根目录下的docker-compose.yml，为各服务添加健康检查配置：

services:
  auto: &automatic
    <<: *base_service
    profiles: ["auto"]
    build: ./services/AUTOMATIC1111
    image: sd-auto:78
    environment:
      - CLI_ARGS=--allow-code --medvram --xformers --enable-insecure-extension-access --api
    healthcheck:
      test: ["CMD", "/usr/local/bin/healthcheck.sh"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 300s  # 给予足够时间加载模型

  comfy: &comfy
    <<: *base_service
    profiles: ["comfy"]
    build: ./services/comfy/
    image: sd-comfy:7
    environment:
      - CLI_ARGS=
    healthcheck:
      test: ["CMD", "/usr/local/bin/healthcheck.sh"]
      interval: 45s  # ComfyUI检查间隔可适当延长
      timeout: 15s
      retries: 3
      start_period: 480s  # ComfyUI模型加载通常较慢

依赖服务健康检查

download服务作为前置依赖，也需要添加基础健康检查：

services:
  download:
    build: ./services/download/
    profiles: ["download"]
    volumes:
      - *v1
    healthcheck:
      test: ["CMD", "test -f /data/models/stable-diffusion-v1-5.safetensors || test -f /data/models/stable-diffusion-v1-5.ckpt"]
      interval: 60s
      timeout: 10s
      retries: 120  # 允许2小时的下载时间
      start_period: 30s

服务可用性监控体系

健康状态查询与自动恢复

手动查询容器健康状态

# 查看所有服务健康状态
docker compose ps --format "table {{.Name}}\t{{.Status}}\t{{.Health}}"

# 查看单个服务详细健康日志
docker inspect --format '{{json .State.Health}}' webui-docker_auto_1 | jq

自动恢复机制实现

通过Docker Compose的restart策略实现基础故障恢复：

services:
  auto:
    <<: *automatic
    restart: unless-stopped  # 除手动停止外，其他情况均自动重启
    deploy:
      restart_policy:
        condition: on-failure  # 仅在失败时重启
        delay: 30s            # 重启延迟
        max_attempts: 5       # 最大重启次数
        window: 60s           # 观察窗口

对于更复杂的恢复策略，可使用外部工具如docker-autoheal：

services:
  autoheal:
    image: willfarrell/autoheal:latest
    restart: always
    environment:
      - AUTOHEAL_CONTAINER_LABEL=all
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    healthcheck:
      disable: true

Prometheus+Grafana监控方案

1. 容器指标收集

添加cadvisor容器收集Docker指标：

services:
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:v0.47.0
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    ports:
      - "8080:8080"
    restart: always
    deploy:
      resources:
        limits:
          cpu: 200m
          memory: 256M

2. Prometheus配置

创建prometheus.yml：

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'docker'
    static_configs:
      - targets: ['cadvisor:8080']
  
  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100']

3. Grafana监控面板

推荐导入以下预制面板：

• Docker监控：面板ID 893
• GPU监控：面板ID 12239
• 系统监控：面板ID 1860

自定义Stable Diffusion监控面板：

告警系统设计

基于Prometheus Alertmanager的告警

groups:
- name: stable-diffusion-alerts
  rules:
  - alert: ContainerUnhealthy
    expr: sum(container_last_seen{health_status="unhealthy"}) > 0
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "容器 {{ $labels.name }} 健康检查失败"
      description: "容器 {{ $labels.name }} 已持续不健康超过5分钟"
      
  - alert: HighGpuMemoryUsage
    expr: avg(nvidia_smi_gpu_memory_used_bytes) / avg(nvidia_smi_gpu_memory_total_bytes) > 0.9
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "GPU内存使用率过高"
      description: "GPU内存使用率已超过90%达10分钟"

企业级告警通知渠道整合

receivers:
- name: 'team-slack'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/XXXXXX/XXXXXX/XXXXXX'
    channel: '#ai-infrastructure'
    send_resolved: true
    title: '{{ .CommonAnnotations.summary }}'
    text: '{{ .CommonAnnotations.description }}'
    
- name: 'pagerduty'
  pagerduty_configs:
  - service_key: 'your-service-key'
    send_resolved: true

最佳实践与性能优化

健康检查资源优化

健康检查本身会消耗系统资源，可通过以下方式优化：

1. 合理设置检查间隔：AI服务通常不需要高频检查，建议30-60秒一次
2. 优化检查脚本：避免在检查脚本中执行耗时操作，控制在10秒内完成
3. 资源限制：对健康检查进程设置CPU和内存限制
4. 分层检查：简单检查失败后才进行复杂检查

#!/bin/bash
# 分层健康检查示例

# 第一层：快速端口检查
if ! nc -z localhost 7860; then
    exit 1
fi

# 第二层：HTTP状态检查
if ! curl -s -o /dev/null -w "%{http_code}" "http://localhost:7860" | grep -q "200"; then
    exit 1
fi

# 第三层：业务逻辑检查（每5次基础检查执行一次）
CHECK_COUNT=$(cat /tmp/healthcheck_count 2>/dev/null || echo 0)
if [ $((CHECK_COUNT % 5)) -eq 0 ]; then
    # 执行复杂检查...
    echo $((CHECK_COUNT + 1)) > /tmp/healthcheck_count
else
    echo $((CHECK_COUNT + 1)) > /tmp/healthcheck_count
    exit 0
fi

生产环境监控策略

大型部署建议采用以下监控策略：

常见问题与解决方案

健康检查误报

问题：Stable Diffusion服务偶尔因生成复杂图像导致健康检查超时。

解决方案：

1. 增加健康检查超时时间：timeout: 20s
2. 实现检查请求优先级队列
3. 为健康检查创建专用API端点，不受生成任务影响

GPU资源竞争

问题：健康检查脚本中的GPU检查与主服务争夺GPU资源。

解决方案：

# 使用nvidia-smi替代直接GPU访问
GPU_MEM=$(nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits)

模型加载期间误判

问题：大型模型加载时间长，导致健康检查失败。

解决方案：

healthcheck:
  start_period: 600s  # 对于大型模型，设置10分钟启动宽限期

总结与展望

本文详细介绍了如何为stable-diffusion-webui-docker构建完整的健康检查和监控体系，从基础的Docker健康检查配置，到复杂的Prometheus+Grafana监控平台搭建，再到故障自动恢复机制实现。通过实施这些措施，可以显著提升AI绘画服务的可用性和稳定性。

关键要点回顾：

1. 健康检查应覆盖Web服务、模型加载、GPU状态等多维度
2. AUTOMATIC1111和ComfyUI需采用不同的健康检查策略
3. 监控体系应包含基础设施、容器和应用三层监控
4. 健康检查需平衡准确性和资源消耗

未来发展方向：

• 基于机器学习的异常检测，提前预测服务故障
• 自适应健康检查频率，根据系统负载动态调整
• 分布式健康检查，避免单点监控失效
• 与CI/CD流程集成，实现健康检查自动化测试

通过本文提供的方案，你的Stable Diffusion服务将具备企业级的可靠性，无论是个人爱好者还是商业服务场景，都能从中获益。实施这些最佳实践后，你可以将更多精力专注于AI绘画创作本身，而非服务维护工作。

如果觉得本文对你有帮助，请点赞、收藏并关注，下期将带来《Stable Diffusion模型自动更新与版本管理》专题内容。

【免费下载链接】stable-diffusion-webui-docker Easy Docker setup for Stable Diffusion with user-friendly UI 项目地址: https://gitcode.com/gh_mirrors/st/stable-diffusion-webui-docker