- 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
Frontend (index.html):
- Modal elegante con backdrop blur y animación
- Muestra nombre de la app a eliminar
- Lista detallada de lo que se eliminará:
* Servicio systemd (siax-app-*.service)
* Archivo .service en /etc/systemd/system/
* Registro en monitored_apps.json
* Historial de monitoreo
- Botón de eliminar solo visible si app está Stopped/Failed
- Diseño rojo con iconos Material Symbols
- Dos botones: Cancelar (gris) y Eliminar (rojo)
- Función openDeleteModal(appName)
- Función closeDeleteModal()
- Función confirmDelete() que llama a DELETE /api/apps/:name
Backend (ya existente, no modificado):
- DELETE /api/apps/:name elimina completamente:
1. systemctl stop
2. systemctl disable
3. rm archivo .service
4. systemctl daemon-reload
5. Elimina de AppManager (memoria)
6. Elimina de monitored_apps.json
Flujo de eliminación:
1. Usuario detiene app
2. Aparece botón 🗑️ Eliminar
3. Click → Modal de confirmación
4. Confirm → DELETE request
5. Backend elimina todo
6. Frontend recarga tabla
7. App desaparece completamente del sistema
Consecuencias de eliminación completa:
✅ No queda rastro en systemd
✅ No re-aparece en discovery
✅ No se envía a Cloud Central
✅ Limpieza total del sistema
Cambios en el frontend (index.html):
- Cambiar header "Actions" a "Acciones"
- Agregar botones de control según estado de la app:
* Si está Running: botones Detener (rojo) y Reiniciar (amarillo)
* Si está Stopped: botón Iniciar (verde)
* Siempre: botón Ver logs (azul)
- Agregar función controlApp() para llamar a la API
- Diálogo de confirmación antes de ejecutar acciones
- Recarga automática de la tabla después de ejecutar acción
Cambios en el backend (lifecycle.rs):
- Corregir formato de service_name en start_app()
- Corregir formato de service_name en stop_app()
- Corregir formato de service_name en restart_app()
- Ahora usa: siax-app-{app_name}.service en lugar de {app_name}.service
Los botones ahora funcionan correctamente con los servicios systemd
Problema:
- La tabla mostraba [object Object] en lugar del nombre de la app
- El estado siempre aparecía como Unknown
- No usaba las propiedades del objeto JSON (name, status, port, service_name)
Solución:
- Actualizar displayApps() para acceder a app.name, app.status, app.service_name
- Agregar badges de colores según estado:
* Running: verde
* Stopped: gris
* Failed: rojo
* Starting: azul
* Stopping: amarillo
* Unknown: gris
- Cambiar botón de more_vert a visibility para ver logs
- Mostrar service_name debajo del nombre de la app
Ahora la tabla muestra correctamente la información de las apps detectadas
- 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
✨ Nuevas funcionalidades:
- API REST unificada en puerto 8080 (eliminado CORS)
- WebSocket para logs en tiempo real desde journalctl
- Integración completa con systemd para gestión de servicios
- Escaneo automático de procesos Node.js y Python
- Rate limiting (1 operación/segundo por app)
- Interface web moderna con Tailwind CSS (tema oscuro)
- Documentación API estilo Swagger completamente en español
🎨 Interface Web (todas las páginas en español):
- Dashboard con estadísticas en tiempo real
- Visor de escaneo de procesos con filtros
- Formulario de registro de aplicaciones con variables de entorno
- Visor de logs en tiempo real con WebSocket y sidebar
- Página de selección de apps detectadas
- Documentación completa de API REST
🏗️ Arquitectura:
- Módulo models: ServiceConfig, ManagedApp, AppStatus
- Módulo systemd: wrapper de systemctl, generador de .service, parser
- Módulo orchestrator: AppManager, LifecycleManager con validaciones
- Módulo api: handlers REST, WebSocket manager, DTOs
- Servidor unificado en puerto 8080 (Web + API + WS)
🔧 Mejoras técnicas:
- Eliminación de CORS mediante servidor unificado
- Separación clara frontend/backend con carga dinámica
- Thread-safe con Arc<DashMap> para estado compartido
- Reconciliación de estados: sysinfo vs systemd
- Validaciones de paths, usuarios y configuraciones
- Manejo robusto de errores con thiserror
📝 Documentación:
- README.md actualizado con arquitectura completa
- EJEMPLOS.md con casos de uso detallados
- ESTADO_PROYECTO.md con progreso de Fase 4
- API docs interactiva en /api-docs
- Script de despliegue mejorado con health checks
🚀 Producción:
- Deployment script con validaciones
- Health checks y rollback capability
- Configuración de sudoers para systemctl
- Hardening de seguridad en servicios systemd
- 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
