- Agregado campo 'user: String' a MonitoredApp
- Función default_user() que obtiene usuario del sistema ($USER/$LOGNAME)
- Actualizado todos los lugares donde se crea MonitoredApp:
* config.rs (add_app)
* app_manager.rs (register_app) - usa config.user
* discovery.rs (sync) - extrae de .service file
* handlers.rs (update_app) - usa config.user
- El campo se guarda en monitored_apps.json
- Formulario de edición ahora carga el usuario correcto
- Resuelve problema: antes ponía 'pablinux' por defecto
- Ahora muestra el usuario real (ej: 'user_apps')
- Construir script_path completo combinando path + entry_point
- Usar valores por defecto cuando campos no existen en JSON
- Agregar console.log para debug
- El campo user usa 'pablinux' por defecto (no está en JSON)
- Ahora los campos se llenan correctamente en lugar de mostrar solo placeholders
Backend:
- Endpoint PUT /api/apps/:name para actualizar configuración completa
- Endpoint GET /api/apps/:name para obtener datos de una app específica
- update_app_handler(): detiene servicio, regenera .service, daemon-reload, actualiza JSON, reinicia
- Soft delete de versión anterior al actualizar (mantiene historial)
- Logs detallados en cada paso del proceso de actualización
- Recarga automática de variables desde .env al actualizar
Frontend:
- Nueva página /edit?app=NOMBRE para editar apps
- Formulario pre-poblado con datos actuales de la app
- Nombre de app readonly (no se puede cambiar para evitar inconsistencias)
- Botón Editar (morado) en panel principal junto a logs/eliminar
- PUT en lugar de POST, mensaje de éxito actualizado
- Redirección automática al panel después de 2 segundos
Casos de uso resueltos:
✅ Cambiar usuario (ej: GatewaySIGMA con usuario incorrecto)
✅ Actualizar puerto
✅ Modificar variables de entorno
✅ Cambiar política de reinicio
✅ Actualizar ruta del script
✅ Recargar .env sin eliminar la app
Completa el patrón CRUD: Create, Read, Update, Delete ✨
- Mostrar nombre exacto del servicio (siax-app-NOMBRE.service) en lugar de comodín
- Actualizar texto para aclarar que es soft delete
- Agregar icono de archivo para indicar que se mantiene en historial
- Agregar mensaje informativo: 'Podrás restaurarla desde el historial'
- Cambiar colores para diferenciar eliminación física vs lógica
- Agregado overflow-x-auto a contenedores de logs
- Agregado break-words y overflow-wrap-anywhere a líneas de logs
- Aplicado tanto en logs de aplicaciones como en errores del sistema
- Las líneas largas ahora se ajustan correctamente sin scroll horizontal
- 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
Problema:
- Sidebar de logs.html no mostraba las apps
- Accedía a data.apps en lugar de data.data.apps
- La estructura de respuesta de /api/apps cambió a:
{ success: true, data: { apps: [...], total: N } }
Solución:
- Actualizar loadApps() en logs.html
- Acceder a result.data.apps correctamente
- Validar result.success antes de procesar
Ahora el sidebar muestra las apps correctamente como en index.html
Backend (handlers.rs + main.rs):
- Nuevo endpoint GET /api/logs/errors
- Lee logs/errors.log y retorna últimas 500 líneas
- Parsea y formatea logs con niveles (INFO, WARN, ERROR)
Frontend (logs.html):
- Sistema de tabs con 2 pestañas:
* Tab 1: "Logs de App" - logs en tiempo real vía WebSocket (journalctl)
* Tab 2: "Errores del Sistema" - logs del archivo errors.log
- Carga apps desde /api/apps (ya usaba el JSON correctamente)
- Colorización por nivel de log:
* ERROR = rojo
* WARN = amarillo
* INFO = azul
- Auto-scroll en ambos tabs
- Diseño consistente con el resto de la UI
Ahora logs.html muestra:
✅ Logs de aplicaciones individuales (systemd/journalctl)
✅ Logs de errores del sistema SIAX Monitor (logs/errors.log)
✅ Navegación por tabs
✅ Lista de apps desde monitored_apps.json
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
