Sentinel Mode: Prueba de Persistencia 24/7

Sentinel Mode: Prueba de Persistencia 24/7

Fecha: 08-02-2026 Versión: v6.5.40 Objetivo: Verificar que el Local Agent recopila datos continuamente aunque el SaaS (Docker) esté apagado

🎯 Objetivo de la Prueba

Confirmar que el sistema Sentinel Mode funciona correctamente:

• Local Agent recopila métricas 24/7 (independiente del navegador/Docker)
• Datos se almacenan localmente en SQLite
• Al reconectar, sincroniza automáticamente con SaaS
• Gráficas muestran datos continuos sin gaps

📐 Arquitectura de Persistencia 24/7

Flujo Completo de Datos

┌─────────────────────────────────────────────────────────────────┐
│ LOCAL AGENT (CreaRackAgent.exe) - Sentinel Mode                │
│                                                                 │
│ 1. Workers recopilan datos 24/7:                               │
│    • PingWorker: cada 30s                                      │
│    • SNMPWorker: cada 60s                                      │
│    • HTTPWorker: cada 60s                                      │
│                                                                 │
│ 2. TimeSeriesStore (SQLite WAL):                               │
│    • metrics.db (~500 MB/mes para 50 targets)                  │
│    • Retención local: 30 días                                  │
│    • ✓ SIEMPRE escribe (online u offline)                      │
│                                                                 │
│ 3. SyncManager:                                                 │
│    • Online: push tiempo real + buffer local                   │
│    • Offline: solo buffer local                                │
│    • Reconexión: bulk drain acumulado (batches de 1000)        │
└──────────────────┬──────────────────────────────────────────────┘
                   │ POST /api/agent/metrics/bulk
                   ▼
┌─────────────────────────────────────────────────────────────────┐
│ SAAS (CreaRack Cloud - Docker)                                  │
│                                                                 │
│ 4. Backend Django:                                              │
│    • Endpoint: /api/agent/metrics/bulk                          │
│    • Recibe hasta 5000 métricas por request                     │
│    • ✓ Escribe a VictoriaMetrics inmediatamente                │
│    • Fire-and-forget (no bloquea sincronización)                │
│                                                                 │
│ 5. VictoriaMetrics:                                             │
│    • Retención: 180 días                                        │
│    • ✓ Almacenamiento definitivo                                │
│    • Deduplicación nativa (mismo timestamp = overwrite)         │
│                                                                 │
│ 6. Observatory UI:                                              │
│    • Consulta: /api/monitoring/targets/{id}/vm/{metric}         │
│    • ✓ Lee desde VictoriaMetrics (NO solo tiempo real)         │
│    • Fallback automático a PostgreSQL si VM falla               │
└─────────────────────────────────────────────────────────────────┘

✅ Garantías del Sistema

🧪 Diseño de la Prueba

Esta Noche (Docker OFF)

1. Apagar Docker completamente:

   cd C:\dev\CreaRack_Pro_app_Django
   docker compose down

2. Verificar que Agent sigue corriendo:

   tasklist | findstr CreaRackAgent.exe
   # Debe mostrar: CreaRackAgent.exe

3. Dejar hasta mañana (8-12 horas)

Lo que DEBERÍA Pasar (Docker OFF)

┌────────────────────────────────────────────────────┐
│ Local Agent (CreaRackAgent.exe)                   │
│                                                    │
│ ✓ Sigue corriendo (independiente de Docker)       │
│ ✓ Recopila métricas cada 30s/60s                  │
│ ✓ Escribe en SQLite local (metrics.db)            │
│ ✓ Intenta sincronizar con SaaS → falla (offline)  │
│ ✓ Acumula en buffer local sin sincronizar         │
│                                                    │
│ Resultado: ~8-12 horas × 120 métricas/hora        │
│           = ~1000-1500 métricas acumuladas         │
└────────────────────────────────────────────────────┘

Mañana (Docker ON)

1. Arrancar Docker:

   cd C:\dev\CreaRack_Pro_app_Django
   docker compose up -d

2. SyncManager detecta reconexión (automático):

   • Detecta que SaaS está disponible
   • Inicia bulk drain del buffer acumulado
   • Envía batches de 1000 métricas vía POST /agent/metrics/bulk
   • Backend escribe a VictoriaMetrics

3. Verificar en Observatory:

   • Seleccionar un device
   • Rango “24h” o “12h”
   • Gráficas cargan desde VictoriaMetrics
   • ✓ Datos CONTINUOS de toda la noche (sin gaps)

📋 Checklist para Mañana

1️⃣ Antes de Arrancar Docker

# Verificar que Agent sigue corriendo
tasklist | findstr CreaRackAgent.exe
# Debe mostrar: CreaRackAgent.exe

# Verificar tamaño de metrics.db (debe haber crecido)
dir %APPDATA%\CreaRackAgent\metrics.db
# Anotar el tamaño (debe ser ~50-100 MB más que ayer)

# Ver últimas líneas de log (métricas recopiladas)
powershell Get-Content $env:APPDATA\CreaRackAgent\agent.log -Tail 20
# Debe mostrar: timestamps recientes con "Collected" o "Stored"

# OPCIONAL: Guardar referencia del tamaño antes
dir %APPDATA%\CreaRackAgent\metrics.db > antes.txt

2️⃣ Arrancar Docker

cd C:\dev\CreaRack_Pro_app_Django
docker compose up -d

# Esperar 30 segundos para que arranque completamente
timeout /t 30 /nobreak

3️⃣ Monitorear Sincronización (CRÍTICO)

Abrir nueva ventana CMD y ejecutar:

# Ver logs del Agent en tiempo real
powershell Get-Content $env:APPDATA\CreaRackAgent\agent.log -Wait -Tail 20

Buscar líneas como:

[INFO] Reconnected to SaaS, draining buffer...
[INFO] Pushed 1000 metrics to SaaS (batch 1/2)
[INFO] Pushed 500 metrics to SaaS (batch 2/2)
[INFO] Bulk sync complete: 1500 metrics synced

Tiempo esperado: 2-5 minutos para sincronizar ~1500 métricas

4️⃣ Verificar en Observatory

1. Abre: http://localhost:8000/monitoring/observatory

2. Ve al tab Overview → Widget Local Agent:
   • Status: Online (dot verde)
   • Sync: Online (dot verde)
   • Version: v6.0.7 (o superior)

3. Sidebar Sentinel panel:
   • Mode: "24/7 Sentinel" (no "Cloud Only")
   • Monitoring: Active (dot verde)
   • Sync: Online (dot verde)

4. Abre un device tab (cualquier target monitoreado):
   • Click en tab del dispositivo

5. Selecciona rango "24h" en botones de Range:
   • Click en botón "24h" (o "12h" si la prueba fue más corta)

6. Observa las 3 gráficas:
   • Heartbeat (Latency + Packet Loss)
   • Bandwidth (Inbound + Outbound)
   • HTTP (Response Time + Status Code)

5️⃣ Verificación de Datos Continuos

✅ Éxito si ves:

• Líneas continuas sin interrupciones
• Datos en la franja horaria de la noche (aprox. 22:00 → 08:00)
• No hay gaps ni saltos en el tiempo
• Valores realistas (no solo ceros o errores)
• Transición suave entre datos de ayer → noche → hoy

❌ Problema si ves:

• Gap horizontal donde no hay datos (línea cortada)
• Datos solo desde que arrancaste Docker (perdió la noche)
• Mensajes de error en console del navegador (F12)
• Widget Agent muestra “Offline” o “Buffering”
• Línea plana en 0 durante la noche

🔧 Diagnóstico si Algo Falla

Problema 1: No Hay Datos de la Noche

Verificar que Agent recopiló datos localmente

# Instalar SQLite (si no está instalado)
# Descargar de: https://www.sqlite.org/download.html

# Consultar métricas de las últimas 12 horas
sqlite3 %APPDATA%\CreaRackAgent\metrics.db "SELECT COUNT(*) FROM metrics WHERE timestamp > strftime('%s', 'now', '-12 hours');"
# Debe mostrar: ~1000-1500 registros

Si devuelve 0: Agent no recopiló datos → verificar que estaba corriendo

Si devuelve >1000: Agent recopiló correctamente → problema en sincronización

Verificar que sincronización funcionó

# Ver líneas de sincronización en logs
type %APPDATA%\CreaRackAgent\agent.log | findstr "Pushed.*metrics"
# Debe mostrar múltiples líneas con "Pushed X metrics to SaaS"

# Ver errores de sincronización
type %APPDATA%\CreaRackAgent\agent.log | findstr "ERROR"
# No debe mostrar errores de autenticación o conexión

Si no hay líneas “Pushed”: Sincronización no ocurrió → ver Problema 2

Verificar que VictoriaMetrics recibió datos

# Consultar VictoriaMetrics directamente
curl "http://localhost:8428/api/v1/query?query=ping_latency_ms" | jq .

# Buscar métricas con timestamps de la noche (epoch time)
# Ejemplo: 1675900000 = 2023-02-09 02:00:00 UTC

Si no hay métricas: VictoriaMetrics no recibió datos → verificar logs Django

# Ver logs de Django (en ventana donde corre docker compose)
docker compose logs -f web | grep "agent/metrics/bulk"
# Debe mostrar: POST /api/agent/metrics/bulk 200

Problema 2: Agent No Sincronizó

Verificar credenciales del Agent

# Verificar que archivo de credenciales existe
dir %APPDATA%\CreaRackAgent\credentials.enc
# Debe mostrar: credentials.enc (archivo binario)

Si no existe: Agent no autenticado → re-autenticar desde Observatory

Forzar re-autenticación

1. Abre: http://localhost:8000/monitoring/observatory
2. Sidebar Sentinel panel → Mode: "24/7 Sentinel"
3. Si hay botón "Link Agent" → clickearlo
4. Si ya está linked → modo ya configurado

Verificar conectividad SaaS

# Verificar que SaaS responde
curl http://localhost:8000/api/agent/health
# Debe devolver: {"status": "ok"}

# Verificar endpoint bulk
curl -X POST http://localhost:8000/api/agent/metrics/bulk \
  -H "Content-Type: application/json" \
  -d '{"agent_id": "test", "metrics": []}'
# Debe devolver: 401 Unauthorized (esperado sin token, pero endpoint existe)

Problema 3: Gráficas No Cargan

Verificar que Observatory consulta VictoriaMetrics

1. Abre: http://localhost:8000/monitoring/observatory
2. Abre DevTools del navegador: F12
3. Ve a tab "Network"
4. Abre un device tab
5. Buscar requests a: /api/monitoring/targets/{id}/vm/ping

Si devuelve 200: Endpoint funciona → datos en response?

Si devuelve 404: Endpoint no existe → verificar versión v6.5.40

Si devuelve 500: Error en backend → ver logs Django

Ver logs de errores en navegador

1. Abre: http://localhost:8000/monitoring/observatory
2. F12 → Console tab
3. Buscar errores en rojo
4. Buscar warnings relacionados con "VM" o "metrics"

📊 Resultados Esperados

Ejemplo Visual de Gráfica Exitosa

Gráfica Heartbeat (Latency):

  100ms ┤     ╭─╮     ╭─╮        ← Día anterior (ayer tarde)
   80ms ┤  ╭──╯ ╰─────╯ ╰──╮
   60ms ┤──╯              ╰─────  ← ESTA NOCHE (Docker OFF)
   40ms ┤    [22:00 → 08:00]      ← Datos continuos! Sin gaps!
   20ms ┤                    ╭──  ← Mañana (Docker ON)
    0ms └─────────────────────────
        20h  22h  00h  02h  04h  06h  08h  10h

✓ Línea continua sin cortes
✓ Valores realistas toda la noche
✓ Transición suave entre periodos

Comparación Tamaño metrics.db

# Antes de la prueba (ayer)
metrics.db: 150 MB

# Después de la noche (hoy antes de arrancar Docker)
metrics.db: 210 MB  (+60 MB)
# ~60 MB = ~8 horas × 50 targets × 120 métricas/hora

# Después de sincronizar (hoy después de 5 min)
metrics.db: 180 MB  (-30 MB)
# Redujo porque SyncManager limpió buffer sincronizado

🎯 Criterios de Éxito

📝 Registro de Resultados (Completar Mañana)

FECHA: ___________
HORA INICIO PRUEBA: ___________
HORA FIN PRUEBA: ___________

1. Agent corrió toda la noche:        [ ] SÍ  [ ] NO
2. metrics.db antes: ______ MB
3. metrics.db después: ______ MB  (crecimiento: ______ MB)
4. Sincronización exitosa:            [ ] SÍ  [ ] NO
5. Tiempo de sincronización: ______ minutos
6. Gráficas muestran datos noche:     [ ] SÍ  [ ] NO
7. Gaps en gráficas:                  [ ] SÍ  [ ] NO

SCREENSHOTS:
- [ ] Gráfica Heartbeat 24h
- [ ] Logs de sincronización
- [ ] Widget Agent Status

NOTAS ADICIONALES:
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

🔗 Referencias

• Arquitectura Sentinel: Documentation/architecture/SENTINEL_MODE.md
• Local Agent Guide: Documentation/backend/LOCAL_AGENT.md
• VictoriaMetrics Integration: Documentation/archive/plans/VICTORIAMETRICS_INTEGRATION_PLAN.md
• Changelog: CHANGELOG.md (v6.5.15 - Sentinel Mode implementation)

💡 Tips Finales

1. Tomar screenshots del tamaño de metrics.db antes y después
2. Abrir logs en tiempo real mientras sincroniza (punto 3️⃣)
3. No cerrar ventana de logs hasta ver “sync complete”
4. Probar con múltiples devices para confirmar consistencia
5. Documentar cualquier anomalía para análisis posterior

📋 Resultados del Test (Completado 09-02-2026)

✅ Test Ejecutado

Fecha inicio: 08-02-2026 (noche) Fecha fin: 09-02-2026 (mañana) Duración: ~16 horas Versión Agent: v6.0.7 Versión SaaS: v6.6.0 → v6.6.1

📊 Resultados Agent (Local)

📡 Resultados Sincronización (SaaS)

🎨 Resultados Frontend (Observatory)

🐛 Problema Encontrado: Bandwidth Vacío en Tabs Restaurados

Síntomas

• Tabs restaurados desde localStorage al iniciar la app mostraban gráficas bandwidth vacías
• Heartbeat y HTTP funcionaban correctamente
• Al cerrar y reabrir el tab manualmente, bandwidth cargaba correctamente
• Backend devolvía datos correctamente (verificado con curl)

Diagnóstico

Código afectado: static/js/pages/observatory/ObservatoryCharts.js

Línea 241 (ANTES):

const hasData = inData.length >= 2;  // ← Requiere mínimo 2 puntos

Problema:

• Heartbeat requiere ≥ 1 punto → carga rápido (ping cada 30s)
• Bandwidth requería ≥ 2 puntos → fallaba al iniciar (SNMP cada 60s)
• Al restaurar tabs, SNMP aún no había recopilado 2 puntos de datos
• Función retornaba mostrando “Collecting SNMP data…” sin crear la gráfica
• No había mecanismo de retry automático

Solución Aplicada (v6.6.1)

Línea 241 (DESPUÉS):

const hasData = inData.length > 0 || outData.length > 0;  // ← Consistente con Heartbeat

Commit: 0a66b29 - fix(observatory): bandwidth chart requires only 1 data point

Resultado: Bandwidth ahora carga correctamente en tabs restaurados, consistente con Heartbeat.

✅ Criterios de Éxito - Verificación Final

📈 Métricas de Rendimiento

Agent (Local):

• Uptime: 1 día 15 horas 40 minutos
• CPU total: 772.78s (proceso principal) + 104s (proceso secundario)
• Memoria: 50.45 MB (principal) + 2.4 MB (secundario)
• Métricas por hora: ~4,789 (76,630 / 16 horas)
• Errores: 0

SaaS (Backend):

• Endpoint /api/agent/metrics/bulk: 200 OK (cada 30s)
• VictoriaMetrics storage: Funcionando correctamente
• Respuesta promedio: ~6ms
• Tasa de éxito: 100%

🎓 Lecciones Aprendidas

1. Sentinel Mode funciona perfectamente 24/7:

   • Agent recopila datos continuamente sin depender de Docker/navegador
   • Sincronización REST robusta (incluso con WebSocket fallando)
   • Zero data loss durante 16 horas de operación

2. Frontend debe ser consistente:

   • Diferentes criterios de “datos mínimos” entre gráficas causa problemas
   • Heartbeat (≥1 punto) vs Bandwidth (≥2 puntos) causó comportamiento inconsistente
   • Fix: Uniformizar criterios para todas las gráficas

3. Tabs restaurados necesitan testing específico:

   • Funcionalidad que funciona al abrir tab manual puede fallar en tabs restaurados
   • Timing diferente: tabs restaurados cargan antes que datos estén disponibles
   • Recomendación: Agregar retry automático o reducir requisitos mínimos de datos

4. VictoriaMetrics + REST sync es robusto:

   • WebSocket fallando no afectó la funcionalidad
   • REST como fallback es suficiente y confiable
   • 76,630 métricas sincronizadas sin pérdida

🔧 Mejoras Futuras Identificadas

1. Fix WebSocket endpoint (baja prioridad):

   • Error 500 en /ws/agent?token=...
   • No afecta funcionalidad (REST funciona)
   • Investigar causa raíz del 500

2. Auto-retry en gráficas vacías (opcional):

   • Si gráfica muestra “Collecting data…”, reintentar después de 60s
   • Mejoraría UX en casos edge

3. Validación de persistencia multi-día (siguiente test):

   • Probar con 3-7 días de operación continua
   • Verificar que purge de 30 días funciona correctamente
   • Medir crecimiento de metrics.db a largo plazo

📝 Conclusión

El test de Sentinel Mode 24/7 fue exitoso. El sistema recopiló, almacenó y sincronizó 76,630 métricas sin pérdida de datos durante 16 horas de operación continua. Se identificó y corrigió un bug de frontend (bandwidth no cargaba en tabs restaurados) que fue resuelto en v6.6.1.

Estado final: ✅ Sentinel Mode VALIDADO para producción

¡Suerte con la prueba! 🚀

Si mañana encuentras algún problema, usa este documento para diagnosticar paso a paso.

Véase también

• [[crearack-tech—architecture—sentinel-mode]] — modo Sentinel 24/7
• [[concept—monitoring—cns]] — concepto del CreaRack Network Sentinel
• [[crearack—monitoring—cns-sentinel]] — CNS desde el punto de vista del usuario
• [[crearack-tech—guides—cns-guide]] — guía técnica de CNS
• [[crearack-tech—agents—dev-cns]] — perfil de subagente dev-cns
• [[crearack-tech—backend—network-observatory]] — backend del Network Observatory