- 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')
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
Problema:
- WebSocket de logs usaba formato incorrecto: {app_name}.service
- Debería ser: siax-app-{app_name}.service
- Esto causaba que journalctl no encontrara el servicio
- Los logs de aplicaciones NO funcionaban
Solución:
- Corregir format!() en websocket.rs línea 96
- Ahora: format!("siax-app-{}.service", app_name)
- journalctl ahora busca el servicio correcto
Los logs de aplicaciones ahora funcionan correctamente vía:
journalctl -u siax-app-IDEAS.service -f --output=json -n 50
- Agregar logs detallados en discovery.rs:
* Mostrar cuántos archivos se escanean
* Mostrar cuántos servicios siax-app-* se encuentran
* Mostrar cuántos se parsean exitosamente
* Logs tanto en logger como en stdout para debugging
- Agregar endpoint GET /api/monitored:
* Retorna el contenido completo de monitored_apps.json
* Permite verificar qué apps están siendo monitoreadas
* Útil para debugging y diagnóstico
- Mejorar mensajes de error con emojis para mejor visibilidad
- Logs en cada paso del proceso de sincronización
- 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
