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
Problema:
- El panel web y logs.html no mostraban las apps descubiertas
- /api/apps solo listaba apps registradas vía API (AppManager en memoria)
- Las apps descubiertas por discovery solo estaban en monitored_apps.json
- El AppManager no conocía las apps existentes en systemd
Solución:
- Modificar /api/apps para leer directamente desde monitored_apps.json
- Consultar estado de systemd en tiempo real para cada app
- Modificar get_app_status para leer desde JSON y consultar métricas
- Buscar procesos por nombre de app o entry_point
Cambios:
- list_apps_handler: Lee desde ConfigManager, consulta systemd
- get_app_status_handler: Lee desde JSON, obtiene PID/CPU/RAM de sysinfo
- Retorna status correcto: Running, Stopped, Failed, Starting, Stopping
- Incluye puerto y service_name en respuesta de /api/apps
Ahora el panel web mostrará todas las apps (descubiertas + registradas)
- 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
Mejora la generación de archivos .service para incluir automáticamente
el PATH de NVM y NODE_ENV, siguiendo las mejores prácticas de systemd.
PROBLEMA RESUELTO:
- Servicios generados no incluían Environment=PATH con NVM
- Faltaba NODE_ENV=production por defecto
- Variables de entorno desordenadas
- Sin logging de detección de NVM
MEJORAS IMPLEMENTADAS:
1. Auto-detección de NVM en ejecutable:
- Si el ejecutable contiene '/.nvm/', extrae el directorio bin
- Agrega Environment=PATH=/path/to/.nvm/.../bin:...
- Log: "Agregando PATH de NVM: /path/to/bin"
2. NODE_ENV por defecto:
- Apps Node.js obtienen NODE_ENV=production automáticamente
- Solo si el usuario no lo definió explícitamente
- Previene errores de módulos dev en producción
3. Orden lógico de variables:
- PATH primero (crítico para encontrar node/npm)
- NODE_ENV segundo
- Variables del usuario después
- ExecStart después de todas las env vars
4. Construcción mejorada del servicio:
- Usa StringBuilder para mejor control
- Separa secciones lógicamente
- Más fácil de leer y mantener
SERVICIO GENERADO (ejemplo):
[Unit]
Description=App para gestionar Tareas
After=network.target
[Service]
Type=simple
User=user_apps
WorkingDirectory=/home/user_apps/apps/app_tareas
Environment=PATH=/home/user_apps/.nvm/versions/node/v24.12.0/bin:/usr/local/bin:/usr/bin:/bin
Environment=NODE_ENV=production
Environment="PORT=3000"
ExecStart=/home/user_apps/.nvm/versions/node/v24.12.0/bin/npm start
Restart=always
RestartSec=10
SyslogIdentifier=siax-app-TAREAS
[Install]
WantedBy=multi-user.target
COMANDOS SYSTEMD (ejecutados automáticamente por AppManager):
✅ sudo systemctl daemon-reload
✅ sudo systemctl enable siax-app-TAREAS.service
✅ sudo systemctl start siax-app-TAREAS.service
BENEFICIOS:
✅ Servicios funcionan con NVM sin configuración manual
✅ PATH correcto para encontrar node/npm
✅ NODE_ENV=production mejora rendimiento y seguridad
✅ Logging claro cuando se detecta NVM
✅ Orden profesional de variables de entorno
Archivos modificados:
- src/systemd/service_generator.rs: +50/-20 líneas
- test_service_generation.sh: nuevo (ejemplo de uso)
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
