Implementada lógica idempotente en monitor.rs para evitar la creación
infinita de registros duplicados en la API central.
PROBLEMA RESUELTO:
- Monitor enviaba POST cada 60s sin verificar si app ya existe
- Resultado: Miles de registros duplicados en base de datos central
- Impacto: Saturación de BD y datos inconsistentes
SOLUCIÓN IMPLEMENTADA:
1. Cache local de IDs de apps (AppIdCache con HashMap + RwLock)
2. Función sync_to_cloud() con lógica idempotente:
- Verificar cache local primero
- Si no está en cache: GET para buscar en API central
- Si no existe en API: POST para crear (solo primera vez)
- Si existe: PUT para actualizar estado
3. Uso correcto de endpoints de API central:
- GET /api/apps_servcs/apps (buscar)
- POST /api/apps_servcs/apps (crear)
- PUT /api/apps_servcs/apps/:id/status (actualizar)
FUNCIONES IMPLEMENTADAS:
- sync_to_cloud() - Coordina flujo idempotente
- find_app_in_cloud() - Busca app por nombre + servidor
- create_app_in_cloud() - Crea nueva app (retorna ID)
- update_app_in_cloud() - Actualiza estado existente
CAMBIOS TÉCNICOS:
- Agregado cache AppIdCache (Arc<RwLock<HashMap<String, i32>>>)
- Tipos CloudApp y CloudAppsResponse para deserialización
- Box<dyn Error + Send + Sync> para compatibilidad tokio
- Revertido cambios incompletos en AppManager
RESULTADO:
✅ Primera ejecución: Crea app en API central (POST)
✅ Siguientes ejecuciones: Solo actualiza estado (PUT)
🚫 NO más duplicados infinitos
📊 Base de datos limpia y consistente
Archivos modificados:
- src/monitor.rs: +180/-50 líneas (lógica idempotente completa)
- src/orchestrator/app_manager.rs: Revertido cambios incompletos
- tareas.txt: Documentación completa de Fase 4.2
- Agregados campos custom_executable y use_npm_start a ServiceConfig
- Implementada auto-detección de ejecutables node/npm en rutas NVM
- Soporte para 'npm start' además de 'node script.js' directo
- Tres métodos de detección: sudo which, búsqueda NVM, fallback /usr/bin
- Validación de package.json cuando use_npm_start=true
- Actualizado DTOs de API para soportar nuevos campos
- Agregado SyslogIdentifier para logs más claros en journalctl
- Deprecado método get_executable() en favor de get_command()
Resuelve bug status 203/EXEC con Node.js instalado vía NVM.
Afecta: 80% de instalaciones Node.js en producción.
Cambios:
- src/models/service_config.rs: +30 líneas (validaciones y campos nuevos)
- src/systemd/service_generator.rs: +120 líneas (auto-detección)
- src/api/dto.rs: +6 líneas (nuevos campos DTO)
- src/api/handlers.rs: +2 líneas (mapeo campos)
- ESTADO_PROYECTO.md: actualizado con diagnóstico del bug
- tareas.txt: plan detallado Fase 4.1
- ejemplo_registro_ideas.sh: script de prueba
✨ 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
