- Agregados campos deleted, deleted_at, deleted_reason a MonitoredApp
- Implementado soft_delete_app() y restore_app() en ConfigManager
- Modificado get_apps() para filtrar apps eliminadas por defecto
- Agregados métodos get_all_apps() y get_deleted_apps()
- Actualizado unregister_app() para usar soft delete en lugar de hard delete
- Creados endpoints:
* GET /api/apps/deleted - Ver historial de apps eliminadas
* POST /api/apps/:name/restore - Restaurar app eliminada
- Agregada sección de Historial en index.html con UI completa
- Botón de restaurar para cada app eliminada
- El servicio systemd se elimina físicamente, solo el JSON mantiene historial
- Permite auditoría y recuperación de apps eliminadas accidentalmente
- Añadir campos al modelo MonitoredApp:
* service_name: Nombre del servicio systemd
* path: WorkingDirectory de la aplicación
* entry_point: Archivo de entrada (server.js, app.js, etc.)
* node_bin: Ruta completa al binario de node/python
* mode: Modo de ejecución (production, development, test)
* service_file_path: Ruta al archivo .service de systemd
* registered_at: Timestamp de registro (ISO 8601)
- Actualizar discovery.rs para extraer toda la información:
* Parsear ExecStart para obtener node_bin y entry_point
* Extraer NODE_ENV para determinar el modo
* Guardar ruta completa al archivo .service
* Usar add_app_full() con información completa
- Integrar ConfigManager en AppManager:
* Guardar automáticamente en monitored_apps.json al registrar apps
* Eliminar del JSON al desregistrar apps
* Extraer metadata desde ServiceConfig (puerto, entry_point, mode, etc.)
- Mantener retrocompatibilidad con JSON antiguo mediante campos deprecated
- Todos los nuevos campos usan #[serde(default)] para evitar errores de deserialización
Implementa la creación automática del directorio config/ y el archivo
monitored_apps.json si no existen al iniciar el agente.
PROBLEMA RESUELTO:
- Al ejecutar en servidor nuevo, faltaba el directorio config/
- Error al no encontrar monitored_apps.json
- Requería creación manual del directorio y archivo
SOLUCIÓN IMPLEMENTADA:
1. Verificación de existencia de directorio padre
2. Creación automática con create_dir_all() si no existe
3. Creación de monitored_apps.json vacío si no existe
4. Sistema de prioridad para rutas de configuración:
- Variable de entorno SIAX_CONFIG_PATH (override)
- /opt/siax-agent/config/monitored_apps.json (producción)
- ./config/monitored_apps.json (desarrollo)
5. Logging detallado de cada paso
COMPORTAMIENTO:
- Primera ejecución: Crea config/ y monitored_apps.json vacío
- Ejecuciones siguientes: Usa el archivo existente
- En producción (/opt/siax-agent/): Usa ruta absoluta
- En desarrollo: Usa ruta relativa ./config/
LOGS GENERADOS:
✅ "Creando directorio: /path/to/config"
✅ "Directorio creado: /path/to/config"
✅ "Archivo de configuración creado: /path/to/monitored_apps.json"
✅ "Usando archivo de configuración: /path"
BENEFICIOS:
✅ No requiere creación manual de directorios
✅ Funciona en cualquier entorno (dev/prod)
✅ Soporta override con variable de entorno
✅ Logs claros para debugging
✅ Archivo JSON vacío válido por defecto
Archivo modificado:
- src/config.rs: +38 líneas (auto-creación + prioridad de rutas)
- Implementado monitor de procesos Node.js con detección automática
- Sistema de logging con niveles (Info, Warning, Error, Critical)
- ConfigManager para gestión dinámica de apps monitoreadas
- Interfaz web básica con escaneo de procesos
- Integración con API central para reportar estados
- User-Agent tracking para identificación de agentes
- Persistencia de configuración en JSON
- Logs almacenados en archivo con rotación
- Sistema modular: monitor, interface, logger, config
Estructura:
- src/main.rs: Orquestador principal
- src/monitor.rs: Monitoreo de procesos y envío a API
- src/interface.rs: Servidor web Axum con endpoints
- src/logger.rs: Sistema de logging a archivo y consola
- src/config.rs: Gestión de configuración persistente
- web/: Templates HTML para interfaz web
- config/: Configuración de apps monitoreadas
- logs/: Archivos de log del sistema
Features implementadas:
✅ Detección automática de procesos Node.js
✅ Monitoreo de CPU y RAM por proceso
✅ Reportes periódicos a API central (cada 60s)
✅ Interfaz web en puerto 8080
✅ Logs estructurados con timestamps
✅ Configuración dinámica sin reinicio
✅ Script de despliegue automatizado
Próximos pasos:
- Integración con systemd para control de procesos
- Dashboard mejorado con cards de apps
- Logs en tiempo real vía WebSocket
- Start/Stop/Restart de aplicaciones
