Este documento resume malísimamente los pasos y desarrollos realizados hasta la fecha en el proyecto de monitoreo y registro de eventos para hosts y Backup Vaults.

• Se configuró la aplicación para que, al recibir datos, cree dinámicamente una tabla para cada host o Backup Vault si no existe.
• Cada tabla individual almacena los siguientes campos:
  • `id`: INT, AUTO_INCREMENT, PRIMARY KEY
  • `creationtime`: `VARCHAR(255)` - Hora de creación en formato cadena.
  • `vmname`: `VARCHAR(255)` - Nombre de la VM o recurso.
  • `type`: `VARCHAR(255)` - Tipo de tarea.
  • `result`: `VARCHAR(255)` - Resultado de la tarea.
  • `detail`: `TEXT` - Detalles adicionales.

• Se agregó una columna adicional `datetime` a las tablas por host.
• Esta columna almacena el tiempo de creación (`creationtime`) en formato `DATETIME`, estandarizando las fechas para facilitar futuras consultas y análisis.
• Se implementó un script para procesar y convertir los diferentes formatos de fecha/hora recibidos al formato `DATETIME`.

• Se añadió un mecanismo básico de autenticación por token en el endpoint `/upload`.
• Solo se permite la carga de datos si el token es válido.

• Se implementó una lógica para filtrar los eventos con resultados diferentes a 'Success'.
• Estos eventos se almacenan en una tabla central llamada `unsuccessful_tasks`.
• El objetivo de esta tabla es permitir la generación de reportes que muestren la frecuencia y distribución de fallos en los últimos 30 días.

• Columnas:
  • `id`: INT, AUTO_INCREMENT, PRIMARY KEY
  • `creationtime`: `DATETIME` - Timestamp del evento.
  • `hostname`: `VARCHAR(255)` - El nombre del host o Backup Vault.
  • `vmname`: `VARCHAR(255)` - El nombre de la VM o recurso.
  • `type`: `VARCHAR(255)` - El tipo de tarea (e.g., Backup, Snapshot).
  • `result`: `VARCHAR(255)` - El resultado (e.g., Fail, Warn).
  • `detail`: `TEXT` - Detalles adicionales del evento.

• Filtrado de Eventos No Exitosos:
  • Cada vez que se registre un evento en las tablas por host, la aplicación debe revisar el campo `result`. Si el valor no es 'Success' o el equivalente en Azure, se inserta un registro en `unsuccessful_tasks`.

• Job Automático de Monitoreo:
• Un script de Python podría ejecutarse cada 4 horas para:
  • Conectar a las tablas de cada host y revisar nuevos registros.
  • Filtrar los eventos no exitosos (`result != 'Success'`).
  • Insertar estos eventos en `unsuccessful_tasks`, eliminando cualquier duplicado que ya exista en esa tabla.
  • Mantener un historial de 30 días y eliminar registros más antiguos para mantener la tabla manejable.

• Reporte de Frecuencia de Fallos:
  • Crear una consulta que filtre por `hostname` y/o `vmname` para contar cuántas veces se ha registrado un fallo o advertencia en los últimos X días.
  • Este reporte es útil para identificar patrones de fallos o problemas recurrentes.

• Limpieza Regular:
  • Programar un job que elimine registros más antiguos de 30 días (o el período que se decida), para mantener la tabla `unsuccessful_tasks` ligera y rápida en sus consultas.

• Se diseñó un job en Python que se ejecuta cada 4 horas.
• Este script realiza las siguientes tareas:
  • Filtrar eventos no exitosos de las tablas por host.
  • Insertar estos eventos en la tabla `unsuccessful_tasks`.
  • Eliminar registros duplicados o más antiguos de 30 días.

• Se establecieron planes para la limpieza regular de la tabla `unsuccessful_tasks` para mantener su eficiencia.
• Además, se consideró la creación de reportes específicos para detectar patrones de fallos.

• Integrar más controles de calidad y validación de datos.
• Optimizar el rendimiento de la base de datos para manejar grandes volúmenes de eventos.
• Expandir la lógica de filtrado para incluir otros tipos de eventos importantes.

nginx/
├── config/
│   └── www/
│       └── demoBackups/
│           ├── app.py
│           ├── templates/
│           │   ├── admin.html
│           │   └── index.html
│           └── static/
│               └── styles.css