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)
Reemplaza el hostname hardcodeado 'siax-intel' por detección automática
del hostname real del sistema.
PROBLEMA RESUELTO:
- server_name estaba hardcodeado como 'siax-intel'
- En servidor de producción (server-web) se reportaba con nombre incorrecto
- Imposible distinguir entre múltiples servidores en API central
SOLUCIÓN IMPLEMENTADA:
1. Función get_hostname() con fallbacks:
- Método 1: Ejecuta comando 'hostname'
- Método 2: Lee /etc/hostname
- Método 3: Fallback a 'siax-agent'
2. Cache con OnceLock en interface.rs (una sola lectura)
3. Detección al inicio en main.rs con logging
COMPORTAMIENTO:
- Desarrollo (siax-intel): Detecta 'siax-intel'
- Producción (server-web): Detecta 'server-web'
- Sin /etc/hostname: Usa 'siax-agent' como fallback
BENEFICIOS:
✅ Cada servidor se identifica correctamente en API central
✅ No requiere configuración manual
✅ Funciona en cualquier distribución Linux
✅ Log al inicio muestra hostname detectado
✅ Interface web muestra nombre correcto del servidor
Archivos modificados:
- src/main.rs: +28 líneas (función get_hostname)
- src/interface.rs: +35 líneas (función get_hostname con cache)
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
