Manual de Operación para Imagen Stable-Diffusion-v1-5-archive: Scripts de Rotación de Logs, Limpieza de Disco y Verificación de Salud

1. Introducción: ¿Por qué necesitamos scripts de operación?

Si estás utilizando el modelo clásico Stable Diffusion v1.5 Archive, podrías enfrentar algunos "problemas agradables": las imágenes generadas aumentan constantemente, el espacio en disco del servidor se agota; con el tiempo, los archivos de registro crecen hasta varios gigabytes; o una mañana descubres que la interfaz web no se abre y necesitas investigar manualmente.

Estos problemas, aunque no son complejos, consumen tiempo y son propensos a errores si se manejan manualmente con frecuencia. Hoy, compartiré un conjunto de scripts diseñados específicamente para la imagen stable-diffusion-v1-5-archive para ayudarte a automatizar la resolución de problemas de operación diaria como rotación de logs, limpieza de disco y verificación de salud del servicio.

A través de este artículo, obtendrás:

Un conjunto de scripts de operación listos para usar, cubriendo los tres escenarios principales: logs, disco y servicio.
Explicaciones claras de los principios de los scripts, comprensibles incluso para principiantes en operación.
Pasos detallados de configuración e implementación para que puedas ponerlos en funcionamiento rápidamente.
Enfoques prácticos para solucionar problemas, sabiendo qué hacer cuando los scripts alertan.

Despidamos la operación manual y usemos scripts automatizados para garantizar el funcionamiento estable de tu servicio de creación de arte con IA.

2. Desafíos de Operación y Soluciones Automatizadas

Antes de profundizar en los detalles de los scripts, primero veamos los desafíos operativos específicos que generalmente se enfrentan al ejecutar la imagen stable-diffusion-v1.5-archive.

2.1 Puntos débiles operativos comunes

Crecimiento infinito de archivos de registro Por defecto, los registros del servicio se escriben continuamente en el mismo archivo (como /root/workspace/sd15-archive-web.log). Después de un tiempo de ejecución, este archivo puede volverse muy grande, ocupando mucho espacio en disco y haciendo lenta la visualización con tail o vim.
Imágenes que ocupan mucho espacio en disco Este es el "problema feliz" más típico. Los usuarios generan imágenes constantemente, y los archivos de imagen en la ruta de guardado predeterminada se acumulan rápidamente. Sin una gestión adecuada, el disco se llenará pronto, impidiendo el guardado de nuevas imágenes e incluso afectando otros servicios del sistema.
El servicio se cae silenciosamente Aunque la imagen está configurada con un Supervisor que puede reiniciar automáticamente el servicio si sale anormalmente, en algunos casos el servicio puede estar en un estado "zombie": el proceso todavía existe, pero el puerto no responde. O, el Supervisor mismo podría tener problemas. Necesitamos un mecanismo para descubrir activamente estos estados no saludables.

2.2 Enfoque de diseño para scripts automatizados

Para abordar estos puntos débiles, nuestra solución es escribir tres scripts independientes en Shell y usar las tareas programadas de Linux crontab para ejecutarlos automáticamente.

Script de rotación de logs: Regularmente archiva el archivo de registro actual (renombrándolo y comprimiéndolo), luego notifica al servicio para que abra un nuevo archivo de registro y continúe escribiendo. Esto mantiene el tamaño de los archivos de registro individuales bajo control y conserva los registros históricos para su posterior análisis.
Script de limpieza de disco: Escanea periódicamente el directorio de almacenamiento de imágenes, eliminando automáticamente imágenes antiguas que superen un número especificado de días según su "última modificación" o "fecha de creación", liberando espacio en disco.
Script de verificación de salud del servicio: Verifica periódicamente si el puerto del servicio web (7860) es accesible y si los procesos clave existen. Si la verificación falla, intenta reiniciar el servicio automáticamente y envía notificaciones de alerta mediante correo electrónico o Webhook.

A continuación, desglosaremos la implementación de cada script.

3. Detallado de los Scripts de Operación Clave

Crearemos tres archivos de script, recomendamos colocarlos en un directorio común, como /root/scripts/.

3.1 Script 1: Rotación y Gestión de Logs

El objetivo de este script es gestionar los crecientes archivos de registro de la aplicación.

#!/bin/bash
# Nombre de archivo: /root/scripts/rotate_logs_sd15.sh
# Función: Rotar los archivos de registro de stable-diffusion-v1-5-archive

ARCHIVO_LOG="/root/workspace/sd15-archive-web.log"
DIRECTORIO_RESPALDO="/root/workspace/log_backup"
TAMANO_MAX_LOG="100M" # Cuando el archivo de registro alcance 100M, se activa la rotación
DIAS_MANTENER=30 # Mantener los respaldos de los últimos 30 días

# 1. Crear directorio de respaldo (si no existe)
mkdir -p "$DIRECTORIO_RESPALDO"

# 2. Verificar el tamaño actual del archivo de registro
if [ -f "$ARCHIVO_LOG" ]; then
    TAMANO_LOG=$(du -m "$ARCHIVO_LOG" | cut -f1)
    # Si el tamaño del archivo de registro supera el valor establecido, realizar rotación
    if [ "$TAMANO_LOG" -gt 100 ]; then # Corresponde a TAMANO_MAX_LOG de 100M
        echo "$(date) - Tamaño del archivo de registro: ${TAMANO_LOG}M, iniciando rotación..." >> /root/scripts/registro_rotacion.log
        
        # 3. Generar nombre de archivo de respaldo con marca de tiempo
        NOMBRE_RESPALDO="registro_sd15_$(date +%Y%m%d_%H%M%S).log.gz"
        
        # 4. Comprimir el archivo de registro actual y moverlo al directorio de respaldo
        gzip -c "$ARCHIVO_LOG" > "$DIRECTORIO_RESPALDO/$NOMBRE_RESPALDO"
        
        # 5. Vaciar el archivo de registro original (notificar al servicio para que abra uno nuevo)
        > "$ARCHIVO_LOG"
        # Alternativamente, una forma más elegante sería enviar una señal para que el servicio abra el registro nuevamente, aquí se usa el vaciado como ejemplo simple
        
        echo "$(date) - Registro rotado, respaldo en: $DIRECTORIO_RESPALDO/$NOMBRE_RESPALDO" >> /root/scripts/registro_rotacion.log
        
        # 6. Limpiar los respaldos de registros caducados
        find "$DIRECTORIO_RESPALDO" -name "*.log.gz" -mtime +$DIAS_MANTENER -delete
    else
        echo "$(date) - Tamaño del archivo de registro: ${TAMANO_LOG}M, no alcanzó el umbral de rotación." >> /root/scripts/registro_rotacion.log
    fi
else
    echo "$(date) - Advertencia: No se encontró el archivo de registro $ARCHIVO_LOG" >> /root/scripts/registro_rotacion.log
fi

Puntos clave del script:

du -m: Calcula el tamaño del archivo en unidades de MB.
gzip -c: Comprime el contenido y lo envía a la salida estándar, luego se redirige al archivo de respaldo, permitiendo una rápida compresión y movimiento.
> "$ARCHIVO_LOG": Usa redirección para vaciar el contenido del archivo. Para algunos servicios, puede ser necesario enviar una señal específica (como SIGUSR1) para notificar que debe abrir un nuevo archivo de registro. Si después de vaciar el servicio deja de escribir en el registro, podría ser necesario reiniciar el servicio o encontrar un método de rotación más adecuado.
find … -mtime +$DIAS_MANTENER -delete: Busca y elimina los archivos de respaldo cuya fecha de modificación sea superior a $DIAS_MANTENER días.

3.2 Script 2: Limpieza Inteligente del Espacio en Disco

Este script se encarga de limpiar las imágenes antiguas generadas, liberando espacio en disco.

#!/bin/bash
# Nombre de archivo: /root/scripts/limpieza_imagenes_sd15.sh
# Función: Limpiar imágenes antiguas generadas por stable-diffusion-v1.5-archive

# Configuración clave
DIRECTORIO_BASE_IMAGENES="/root/workspace" # Modificar según la ruta real de almacenamiento de imágenes en la imagen
# Las imágenes suelen estar en /root/workspace/outputs o similar, confirmar la ruta después de generar una imagen mediante la interfaz web
PATRONES_BUSQUEDA=("*.png" "*.jpg" "*.jpeg")
DIAS_MANTENER=7 # Mantener las imágenes de los últimos 7 días
USO_MINIMO_DISCO_PORCENTAJE=80 # Cuando el uso del disco supere el 80%, realizar una limpieza más agresiva
EJECUCION_SECA=false # Establecer en true para mostrar solo los archivos que se eliminarán, sin eliminar realmente

# Obtener el uso del disco
USO_DISCO=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')

echo "$(date) - Iniciando verificación de limpieza de disco. Uso del disco: ${USO_DISCO}%" >> /root/scripts/registro_limpieza.log

TOTAL_ELIMINADO=0
TAMANO_TOTAL=0

# Recorrer y eliminar archivos antiguos
for patron in "${PATRONES_BUSQUEDA[@]}"; do
    # Usar el comando find para buscar archivos que coincidan con el patrón y superen los días especificados
    if [ "$EJECUCION_SECA" = true ]; then
        echo "[Ejecución de prueba] Se buscarán y eliminarán los siguientes archivos ${patron} con más de ${DIAS_MANTENER} días:" >> /root/scripts/registro_limpieza.log
        find "$DIRECTORIO_BASE_IMAGENES" -type f -name "$patron" -mtime +$DIAS_MANTENER -exec ls -lh {} \; >> /root/scripts/registro_limpieza.log
        CONTADOR_ELIMINADOS=$(find "$DIRECTORIO_BASE_IMAGENES" -type f -name "$patron" -mtime +$DIAS_MANTENER | wc -l)
        echo "[Ejecución de prueba] Se encontraron $CONTADOR_ELIMINADOS archivos para eliminar." >> /root/scripts/registro_limpieza.log
    else
        echo "Limpiando archivos ${patron} con más de ${DIAS_MANTENER} días..." >> /root/scripts/registro_limpieza.log
        # Eliminar archivo por archivo y registrar información
        find "$DIRECTORIO_BASE_IMAGENES" -type f -name "$patron" -mtime +$DIAS_MANTENER -exec sh -c '
            archivo="$1"
            tamano=$(stat -c %s "$archivo" 2>/dev/null)
            echo "Eliminando: $archivo (tamaño: $((tamano/1024))KB)" >> /root/scripts/registro_limpieza.log
            rm -f "$archivo"
            echo $tamano
        ' _ {} \; | awk '{suma+=$1} END {print "Tamaño total eliminado en este patrón: " suma/1024/1024 " MB"}' >> /root/scripts/registro_limpieza.log
    fi
done

# Si el uso del disco sigue siendo alto, ejecutar una segunda ronda de limpieza más agresiva
if [ "$USO_DISCO" -ge "$USO_MINIMO_DISCO_PORCENTAJE" ] && [ "$EJECUCION_SECA" = false ]; then
    DIAS_AGGRESIVOS=3 # Mantener solo los últimos 3 días
    echo "Uso del disco ${USO_DISCO}% demasiado alto, ejecutando limpieza agresiva (manteniendo solo ${DIAS_AGGRESIVOS} días más recientes)..." >> /root/scripts/registro_limpieza.log
    for patron in "${PATRONES_BUSQUEDA[@]}"; do
        find "$DIRECTORIO_BASE_IMAGENES" -type f -name "$patron" -mtime +$DIAS_AGGRESIVOS -delete
    done
    echo "Limpieza agresiva completada." >> /root/scripts/registro_limpieza.log
fi

echo "$(date) - Verificación de limpieza de disco completada." >> /root/scripts/registro_limpieza.log

Puntos clave del script:

Tarea principal: confirmar DIRECTORIO_BASE_IMAGENES: La configuración más crítica en el script es el directorio raíz donde se guardan las imágenes. Debes iniciar sesión en el contenedor, generar una imagen a través de la interfaz web y luego usar comandos como find / -name "*.png" -type f | head -5 para localizar la ruta real de guardado de las imágenes.
-mtime +$DIAS_MANTENER: Busca archivos cuya fecha de modificación sea superior a $DIAS_MANTENER días.
Modo EJECUCION_SECA: Esta es una característica de seguridad. Al ejecutar por primera vez, se recomienda encarecidamente establecerlo en true, ejecutarlo una vez para ver qué archivos se eliminarán y, solo después de confirmar, cambiarlo a false.
Estrategia de limpieza en dos niveles: Primero se limpia con la estrategia常规 (como 7 días), y si el uso del disco aún supera el umbral (como 80%), se ejecuta una estrategia más agresiva (manteniendo solo archivos de los últimos 3 días).

3.3 Script 3: Verificación de Salud del Servicio y Autocorrección

Este script asegura que el servicio web siempre esté disponible e intenta recuperarlo en caso de anomalías.

#!/bin/bash
# Nombre de archivo: /root/scripts/verificacion_salud_sd15.sh
# Función: Verificar el estado de salud del servicio stable-diffusion-v1.5-archive e intenta reiniciar en caso de fallo

NOMBRE_SERVICIO="sd15-archive-web"
PUERTO_SERVICIO=7860
URL_VERIFICACION="http://localhost:${PUERTO_SERVICIO}/" # Intentar acceder a la ruta raíz
ARCHIVO_LOG="/root/scripts/registro_verificacion.log"
CORREO_ALERTA="" # Opcional: configurar correo para alertas, requiere servicio de envío de correo configurado
# Opcional: configurar URL de Webhook para enviar mensajes a DingTalk, WeChat Work, etc.
URL_WEBHOOK=""

# Función: registrar logs
registrar_log() {
    echo "$(date) - $1" >> $ARCHIVO_LOG
}

# Función: enviar alerta simple (aquí solo se registra en el log, se puede extender a correo o Webhook)
enviar_alerta() {
    local mensaje="$1"
    registrar_log "Alerta: $mensaje"
    # Ejemplo: si está configurada URL_WEBHOOK, se puede usar curl para enviar mensaje
    # if [ -n "$URL_WEBHOOK" ]; then
    #     curl -s -X POST -H "Content-Type: application/json" -d "{\"msgtype\":\"text\",\"text\":{\"content\":\"$mensaje\"}}" $URL_WEBHOOK > /dev/null 2>&1
    # fi
}

# 1. Verificar si el puerto está escuchando
VERIFICACION_PUERTO=$(ss -ltnp | grep ":${PUERTO_SERVICIO} " | wc -l)
if [ "$VERIFICACION_PUERTO" -eq 0 ]; then
    registrar_log "El puerto del servicio ${PUERTO_SERVICIO} no está escuchando."
    ESTADO_PUERTO=false
else
    registrar_log "El puerto del servicio ${PUERTO_SERVICIO} está escuchando correctamente."
    ESTADO_PUERTO=true
fi

# 2. Verificar el estado del proceso Supervisor (si se usa Supervisor)
VERIFICATION_SUPERVISOR=$(supervisorctl status $NOMBRE_SERVICIO 2>/dev/null | grep -E "RUNNING|STOPPED|FATAL")
if [ $? -eq 0 ]; then
    registrar_log "Estado Supervisor: $VERIFICATION_SUPERVISOR"
    if echo "$VERIFICATION_SUPERVISOR" | grep -q "RUNNING"; then
        ESTADO_SUPERVISOR=true
    else
        ESTADO_SUPERVISOR=false
    fi
else
    registrar_log "Advertencia: No se puede obtener el estado de Supervisor o el servicio no está gestionado por Supervisor."
    ESTADO_SUPERVISOR=false # Por seguridad, se considera no saludable
fi

# 3. Intentar acceso HTTP (verificación de salud crítica)
CODIGO_HTTP=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 10 $URL_VERIFICACION 2>/dev/null)
if [ "$CODIGO_HTTP" -eq 200 ] || [ "$CODIGO_HTTP" -eq 302 ] || [ "$CODIGO_HTTP" -eq 403 ]; then
    # 200 éxito, 302 redirección, 403 sin permiso pero el servicio responde, todos se consideran servicio accesible
    registrar_log "Acceso al servicio HTTP exitoso, código de estado: ${CODIGO_HTTP}."
    ESTADO_HTTP=true
else
    registrar_log "Acceso al servicio HTTP fallido, código de estado: ${CODIGO_HTTP} o tiempo de espera agotado."
    ESTADO_HTTP=false
fi

# 4. Evaluación integral del estado de salud y procesamiento
if $ESTADO_PUERTO && $ESTADO_HTTP; then
    registrar_log "Verificación de salud del servicio superada."
    exit 0
else
    registrar_log "Verificación de salud del servicio fallida, intentando reiniciar..."
    enviar_alerta "Servicio Stable-Diffusion-v1.5-archive anómalo, intentando reiniciar. Escucha de puerto: $ESTADO_PUERTO, Acceso HTTP: $ESTADO_HTTP"
    
    # Intentar reiniciar mediante Supervisor
    if command -v supervisorctl &> /dev/null; then
        registrar_log "Reiniciando servicio $NOMBRE_SERVICIO mediante Supervisor..."
        supervisorctl restart $NOMBRE_SERVICIO >> $ARCHIVO_LOG 2>&1
        RESULTADO_REINICIO=$?
        sleep 10 # Esperar a que el servicio inicie
        # Verificar nuevamente después del reinicio
        NUEVO_CODIGO_HTTP=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 15 $URL_VERIFICACION 2>/dev/null)
        if [ "$NUEVO_CODIGO_HTTP" -eq 200 ] || [ "$NUEVO_CODIGO_HTTP" -eq 302 ]; then
            registrar_log "Reinicio del servicio exitoso, código HTTP actual: ${NUEVO_CODIGO_HTTP}."
            enviar_alerta "Reinicio del servicio exitoso."
            exit 0
        else
            registrar_log "El servicio aún no es accesible después del reinicio, código HTTP: ${NUEVO_CODIGO_HTTP}."
            enviar_alerta "Reinicio del servicio fallido, verificación manual requerida."
            exit 1
        fi
    else
        registrar_log "No se encontró Supervisor, intentando terminar procesos e iniciar directamente (requiere ajuste del comando de inicio real)..."
        # Aquí necesitas complementar el comando según el método real de inicio de la imagen
        # Por ejemplo: pkill -f "python.*gradio" && cd /root/workspace && nohup python app.py > web.log 2>&1 &
        enviar_alerta "No se puede reiniciar mediante Supervisor, intervención manual requerida."
        exit 1
    fi
fi

Puntos clave del script:

Tres niveles de verificación de salud:

Verificación de puerto: Confirma si algún proceso está escuchando en el puerto 7860.
Verificación de gestión de proceso: Confirma si Supervisor está gestionando el servicio y su estado es RUNNING.
Verificación de aplicación: Realiza una solicitud HTTP al servicio, que es la forma más efectiva de verificar la salud.

Juicio flexible de códigos de estado: Para servicios web, 200 es éxito, 302 es redirección (posiblemente a una página de inicio de sesión), y 403 es sin permisos pero el servicio responde. Todos estos códigos indican que el servicio en sí está "vivo".
Lógica de autocorrección: Cuando la verificación falla, el script primero intenta reiniciar el servicio mediante supervisorctl restart, espera un momento y verifica nuevamente. Si el reinicio es exitoso, se recupera; si falla, se eleva la alerta.
Extensión de alertas: El script预留 interfaces para enviar alertas. Puedes integrar correo (requiere configuración de sendmail o SMTP externo) o herramientas de comunicación populares Webhook (como DingTalk, WeChat Work, Slack) según sea necesario.

4. Implementación y Configuración: Hacer que los scripts se ejecuten automáticamente

Los scripts están listos, ahora necesitamos que se ejecuten periódicamente de forma automática.

4.1 Pasos de Implementación

Crear directorio de scripts y subir archivos

mkdir -p /root/scripts
cd /root/scripts
# Usa tu editor favorito (vim/nano) para crear los tres archivos de script, o sube mediante SFTP.
# Por ejemplo: vim rotate_logs_sd15.sh
# Pega el contenido correspondiente del script, guarda y sale.

Dar permisos de ejecución a los scripts

chmod +x /root/scripts/*.sh

Ejecución de prueba inicial ¡Muy importante! Antes de ejecutar por primera vez, especialmente el script de limpieza, asegúrate de habilitar el modo EJECUCION_SECA.

# Probar script de rotación de logs
/root/scripts/rotate_logs_sd15.sh
cat /root/scripts/registro_rotacion.log # Verificar el registro de ejecución

# Probar script de limpieza de disco (modo EJECUCION_SECA)
# Primero, editar limpieza_imagenes_sd15.sh, asegurando que EJECUCION_SECA=true y DIRECTORIO_BASE_IMAGENES sea correcto
/root/scripts/limpieza_imagenes_sd15.sh
cat /root/scripts/registro_limpieza.log # Verificar cuidadosamente la lista de archivos que se eliminarán

# Probar script de verificación de salud
/root/scripts/verificacion_salud_sd15.sh
cat /root/scripts/registro_verificacion.log

Configurar tareas programadas (Cron) Editar el crontab del usuario actual:

crontab -e

En el editor abierto, agregar las siguientes líneas (ajusta la frecuencia de ejecución según tus necesidades):

# Ejecutar rotación de logs todos los días a las 2 AM
0 2 * * * /bin/bash /root/scripts/rotate_logs_sd15.sh

# Ejecutar limpieza de disco todos los días a las 3 AM
0 3 * * * /bin/bash /root/scripts/limpieza_imagenes_sd15.sh

# Ejecutar verificación de salud cada 5 minutos
*/5 * * * * /bin/bash /root/scripts/verificacion_salud_sd15.sh

Guardar y salir. Cron entrará en vigor inmediatamente.

4.2 Verificación de elementos de configuración clave

Antes de ejecutar oficialmente, verifica nuevamente los elementos de configuración clave en cada script:

Script	Elemento de configuración clave	Descripción y sugerencias
Rotación de logs	`ARCHIVO_LOG`	Confirmar si la ruta del archivo de registro es correcta, por defecto `/root/workspace/sd15-archive-web.log`.
	`TAMANO_MAX_LOG`	Tamaño del registro que activa la rotación, ajusta según la velocidad de generación de tus logs.
	`DIAS_MANTENER`	Cuántos días mantener los respaldos de logs.
Limpieza de disco	`DIRECTORIO_BASE_IMAGENES`	¡Lo más importante! Debe modificarse al directorio real donde la imagen guarda las imágenes.
	`DIAS_MANTENER`	Días a mantener en la limpieza normal.
	`EJECUCION_SECA`	Al ejecutar por primera vez, establecer definitivamente en `true` para simular.
Verificación de salud	`PUERTO_SERVICIO`	Asegurarse de que sea 7860 (puerto por defecto).
	`URL_VERIFICACION`	URL para la verificación de salud, por defecto `http://localhost:7860/`.
	`CORREO_ALERTA` / `URL_WEBHOOK`	Si se requieren alertas, configurar el método de envío correspondiente.

5. Solución de Problemas y Mantenimiento de Scripts

Aunque esté automatizado, a veces necesitamos intervenir manualmente para solucionar problemas.

5.1 Problemas Comunes y Soluciones

El script no se ejecuta

Verificar servicio Cron: Ejecutar systemctl status cron (o crond) para asegurarse de que el servicio está activo.
Verificar logs de Cron: Ver /var/log/cron o /var/log/syslog para ver si hay registros de ejecución de tareas cron o mensajes de error.
Verificar permisos y rutas de los scripts: Asegurarse de que los scripts tengan permisos de ejecución (x) y que en cron se usen rutas absolutas.

El script de limpieza eliminó archivos que no debía

Recuperar datos: Si el directorio de respaldo (DIRECTORIO_RESPALDO) es diferente, la operación de limpieza es una eliminación permanente. Detén inmediatamente el script y recupera desde repsaldo (si tienes respaldo). Esto resalta la importancia del modo EJECUCION_SECA y de confirmar DIRECTORIO_BASE_IMAGENES.
Verificar ruta: Volver a confirmar si la variable DIRECTORIO_BASE_IMAGENES apunta exactamente al directorio de almacenamiento de imágenes, sin incluir otros datos importantes.

El script de verificación de salud reinicia el servicio con frecuencia

Verificar red: Podría ser una fluctuación de red local temporal que causa tiempo de espera en curl. Puedes aumentar adecuadamente el valor de --connect-timeout (por ejemplo, a 15 o 20).
Verificar velocidad de inicio del servicio: El servicio puede necesitar más de 10 segundos para estar completamente listo después de reiniciar. Puedes aumentar el tiempo de espera después del reinicio (el valor después del comando sleep).
Verificar alertas: Ver el log de verificación de salud (/root/scripts/registro_verificacion.log), analizando la causa específica del reinicio (¿fallo de puerto, proceso o HTTP?).

Después de la rotación de logs, el servicio ya no escribe en el registro

Como se mencionó, el simple método de vaciar > logfile puede no ser adecuado para todos los servicios. Si esto ocurre, necesitas modificar el script de rotación, después de respaldar el log original, reiniciar el servicio de registro o la aplicación. Para servicios gestionados por Supervisor, puedes agregar una línea después de la rotación: supervisorctl restart sd15-archive-web. Esto interrumpirá breveemnte el servicio, pero garantizará que el registro comience a registrarse nuevamente.

5.2 Visualización y Monitoreo de Logs

Los tres scripts generan sus propios registros de ejecución, que son la primera fuente para solucionar problemas:

/root/scripts/registro_rotacion.log: Registra operaciones de rotación de logs.
/root/scripts/registro_limpieza.log: Registra operaciones de limpieza de archivos, especialmente los resultados de simulación en modo EJECUCION_SECA.
/root/scripts/registro_verificacion.log: Registra resultados de cada verificación de salud y cualquier operación de reinicio.

Se recomienda revisar regularmente estos logs para entender el estado de la operación automatizada del sistema.

6. Conclusión

Mediante la implementación de este conjunto simple de scripts en Shell, hemos construido una red de seguridad operativa automatizada para la imagen stable-diffusion-v1.5-archive:

El script de rotación de logs asegura que los archivos de registro no crezcan infinitamente, facilitando la gestión y consulta de registros históricos.
El script de limpieza de disco libera espacio ocupado por imágenes antiguas automáticamente, evitando errores en tiempo de ejecución debido a disco lleno.
El script de verificación de salud del servicio proporciona capacidades de monitoreo proactivo y autocorrección, garantizando al máximo la disponibilidad del servicio.

El valor central radica en la "automatización" y la "prevención". Te libera del trabajo de mantenimiento diario repetitivo y transforma los problemas de "detección pasiva" a "tratamiento proactivo", e incluso se resuelven antes de que los usuarios perciban el problema.

Siguientes pasos recomendados:

Probar completamente: Asegúrate de completar todas las pruebas de EJECUCION_SECA y ejecución inicial de los scripts en un entorno de prueba o durante períodos de baja actividad.
Ajustar parámetros: Según tu frecuencia de uso real (cantidad de imágenes generadas, velocidad de generación de logs), ajusta DIAS_MANTENER, TAMANO_MAX_LOG y la frecuencia de ejecución de Cron.
Mejorar alertas: Mejora la función de alerta en verificacion_salud_sd15.sh, integrándola con tu plataforma de monitoreo o herramienta de comunicación para lograr verdadera operación sin vigilancia.

Espero que este manual y los scripts adjuntos te permitan usar Stable Diffusion v1.5 Archive con mayor tranquilidad y eficiencia para la creación.

Obtén más imágenes de IA

¿Quieres explorar más imágenes y escenarios de aplicación? Visita la Plaza de Imágenes de CSDN Xingtu, que ofrece una rica variedad de imágenes preconfiguradas, cubriendo áreas como inferencia de modelos grandes, generación de imágenes, generación de video, ajuste fino de modelos y más, con implementación de un solo clic.

Etiquetas: scripts de shell automatización de sistemas gestión de logs limpieza de disco verificación de servicios

Publicado el 6-3 03:25

Friki Work

Manual de Operación para Imagen Stable-Diffusion-v1-5-archive: Scripts de Rotación de Logs, Limpieza de Disco y Verificación de Salud