Monitoreo y avisos
Controles de salud de los contenedores, avisos al super administrador dentro de Moodle, correo de fallo de respaldo y dónde están los registros.
La Academia no tiene hoy un sistema de monitoreo externo (ver Pendientes operativos). La vigilancia se apoya en cuatro fuentes: los controles de salud que muestra Coolify, los avisos al super administrador dentro de Moodle, el correo de fallo de respaldo y los registros.
Controles de salud (healthchecks)
Definidos en docker-compose.yml. Coolify muestra cada servicio como healthy o unhealthy.
| Servicio | Qué comprueba | Intervalo | Margen de arranque |
|---|---|---|---|
mariadb | healthcheck.sh --su-mysql --connect --innodb_initialized | 10 s (5 s de espera, 10 reintentos) | 30 s |
moodle | Que http://localhost/login/index.php responda 200 o una redirección 30x | 60 s (15 s de espera, 3 reintentos) | 900 s |
moodle-cron | Que /tmp/cron-last-ok exista y tenga menos de 600 s: el cron de Moodle se ejecutó bien en los últimos 10 minutos | 60 s (10 s de espera, 3 reintentos) | 900 s |
moodleymoodle-cronesperan a quemariadbesté sano antes de arrancar (moodledepende demariadbconcondition: service_healthy).- El margen de 15 minutos existe porque el primer arranque (instalación y configuración) tarda varios minutos.
- Un
moodle-cronunhealthy no se reinicia en bucle: el contenedor sigue reintentando cada 60 segundos y escribe el error en su registro.
Todos los servicios tienen restart: unless-stopped y límites de memoria: mariadb 2 GB (con innodb-buffer-pool-size=1G), moodle 3 GB y moodle-cron 1 GB.
Avisos para el super administrador
Las cuentas de super administrador ven un recuadro Avisos para el super administrador en su Área personal y en todas las páginas de Administración del sitio. Solo aparece si hay algo que atender.
| Aviso | Cuándo aparece | Qué hacer |
|---|---|---|
| Las tareas programadas (cron) no se ejecutan desde (fecha) | La última ejecución del cron empezó hace más de 15 minutos (o nunca). Sin cron no se emiten certificados ni se reinicia la cuota de la IA | Revisar el servicio moodle-cron en Coolify (debe estar healthy) y sus registros |
| En el último despliegue (fecha) fallaron estos pasos: ... | local_deltamodules/deploy_errors no está vacío | Ver el detalle en los registros del contenedor moodle (Arranque y actualizaciones) |
| El último respaldo automático falló (fecha): motivo | El último fallo es igual o más reciente que el último respaldo correcto | Revisar /var/log/delta-lms-backup.log en el servidor |
| No hay respaldo automático activo en el servidor | Nunca se registró un respaldo correcto | Activarlo con setup-backup.sh (Respaldos) |
| El último respaldo es del (fecha) (más de un día) | El último respaldo correcto tiene más de 36 horas | Revisar el respaldo diario del servidor |
| Los respaldos se guardan solo en el mismo servidor | Hay respaldo correcto pero nunca se registró una copia externa | Configurar la copia fuera del servidor |
| La cuenta admin usa la contraseña por defecto que estuvo publicada | Quedó encendido por una versión anterior de la plataforma (alert_admin_defaultpass); el código actual ya no detecta esa contraseña | Cambiar la contraseña de admin (perfil → Cambiar contraseña). El aviso se quita solo cuando esa cuenta cambia su contraseña |
| La cuenta admin.respaldo tenía la contraseña publicada y se le puso una aleatoria | Solo si una versión anterior de la plataforma la reemplazó en los últimos 14 días; el código actual ya no lo hace | Ponerle una nueva desde la otra cuenta de super administrador |
Los avisos de respaldo se muestran en este orden de prioridad: fallo, sin respaldo, atrasado, sin copia externa (solo uno a la vez).
Correo cuando falla un respaldo
Si backup-daily.sh falla, llama a local/deltamodules/cli/backup_status.php --fail="<motivo>", que:
- Registra el fallo y el motivo en Moodle (lo ven el aviso y la página Respaldos de la Academia).
- Envía el correo "Falló el respaldo de la Academia Deltamontero" a todos los super administradores y al correo de soporte (
MOODLE_SUPPORT_EMAIL), con la fecha, el motivo y la indicación de revisar/var/log/delta-lms-backup.log.
El correo de fallo solo sale si el correo SMTP está configurado y las cuentas de super administrador tienen un correo válido. Si Moodle no está corriendo cuando falla el respaldo, el estado no se puede registrar: queda solo en el registro del servidor ("AVISO: Moodle no está corriendo; no se registró el estado").
Páginas de estado en Moodle
| Página | Ruta | Qué muestra |
|---|---|---|
| Respaldos de la Academia | Administración del sitio → Cursos → Copias de seguridad → Respaldos de la Academia | Estado del respaldo diario, último correcto, tamaño, hora, retención y copia externa |
| Correos de la Academia | Administración del sitio → Usuarios → Correos de la Academia | Si el correo está configurado o en pausa, correos en cola, enviados en 24 horas, con error en 7 días, diagnóstico de la conexión y registro de envíos (últimos 200; se conservan 180 días) |
| Revisar los módulos | Módulos → Revisar los módulos | Lo que impide avanzar o terminar cada módulo (videos que YouTube ya no deja ver, repasos sin preguntas o sin nota para aprobar, certificado), con reparación de lo que se puede |
| Tareas programadas de Moodle | Administración del sitio → Servidor → Tareas programadas (pantalla estándar de Moodle) | Última y próxima ejecución de cada tarea |
Tareas programadas propias
Además de las de Moodle, el plugin local_deltamodules define estas tareas (las ejecuta moodle-cron, en hora de Ecuador):
| Tarea | Cuándo | Qué hace |
|---|---|---|
send_mail | Cada minuto | Envía los correos en cola respetando el límite por minuto y por día (Office 365 acepta unos 30 por minuto); reintenta hasta 3 veces |
client_expiry | Todos los días, 01:30 | Suspende los usuarios de empresas cliente cuya fecha de acceso venció |
mail_reminders | Lunes, 09:00 | Recordatorio de módulos pendientes |
review_reminder | Día 1 de cada mes, 08:00 | Notifica a Talento Humano los módulos con revisión anual vencida, por vencer (60 días o menos) o sin revisión (notificación interna, no requiere correo) |
Registros
| Registro | Cómo verlo |
|---|---|
| Sitio (arranque, actualización, pasos de configuración, Apache) | Coolify → registros del servicio moodle. En local: docker compose logs -f moodle |
| Cron de Moodle | Coolify → registros del servicio moodle-cron. En local: docker compose logs -f moodle-cron. Los fallos aparecen como !!! [cron] ERROR |
| Respaldo diario | /var/log/delta-lms-backup.log en el servidor (rotación semanal, 8 semanas) |
| Registros de Moodle (actividad de usuarios) | Administración del sitio → Informes → Registros (solo super administrador) |
docker compose logs -f moodle
docker compose logs -f moodle-cron
tail /var/log/delta-lms-backup.logLíneas a buscar en los registros:
| Texto | Significado |
|---|---|
!!! ERROR: MOODLE_DB_PASSWORD (MYSQL_PASSWORD) no está definida | Falta la contraseña de la base: el contenedor no arranca |
!!! ERROR: no se pudo conectar a la base de datos en 5 minutos | Contraseña o servidor de base incorrectos, o MariaDB caída |
!!! ERROR: primera instalación sin MOODLE_ADMIN_PASSWORD | Falta la contraseña del administrador en una instalación nueva |
!!! ERROR: falló la actualización de Moodle (upgrade.php) | El despliegue se detuvo; revisar el registro de arriba |
!!! ERROR en un paso de seguridad del despliegue | Falló un paso crítico de configuración |
! Aviso: falló un paso no crítico | Falló un paso cosmético |
!!! [cron] Moodle dice 'upgrade pending' | Normal unos minutos durante un despliegue; si dura más de 10 minutos, la imagen del cron no coincide con la del sitio |
ERROR: / === Respaldo diario: correcto | Resultado de cada respaldo en /var/log/delta-lms-backup.log |
Registro de pruebas
Pruebas de respaldo y recuperación realizadas en la Academia Deltamontero, con sus resultados, tiempos y hallazgos.
Accesos y cuentas de administración
Super administradores, cuenta de respaldo, verificación en dos pasos (MFA), cuentas técnicas, dónde viven los secretos y cómo recuperar el acceso sin correo.