Cadencia de sondeo por dispositivo · Dial interactivo (v1.43.0 + v1.43.1)

Propósito

Permitir al usuario ajustar la cadencia de sondeo y refresco de gráficas por dispositivo (APs, UPS, players de Signage, targets de Observatory) mediante un selector en la Edit Card. Un único dial gobierna tanto el polling como el ritmo de las gráficas; al guardarlo, las páginas abiertas se re-acompasan al momento sin recargar.

Iniciativa

Task #175 · sesión s195 (03-07-2026). Tres PRs: #259 (v1.42.0, motor + Agent 2.13.0) → #261 (v1.43.0, dial en UI) → #264 (v1.43.1, aplicación en caliente, feedback del click-test de Edu).

Las tres piezas

v1.42.0 · Motor (PR #259, con Agent 2.13.0)

El campo MonitoringTarget.interval_seconds existía desde la migración 0001 pero era inerte (los loops del Sentinel iban a 30/60 s fijos). Este PR lo hace efectivo:

• Los 4 loops del Sentinel (sentinel/ping.py, snmp_bandwidth.py, snmp_fast.py, snmp_extras.py) sondean solo los targets vencidos (scheduler.due_targets, tick 5 s, reloj monotónico por target).
• Suelos por protocolo (terminal/agent/config.py): PING_FLOOR=15 + PING_CAP=30 (el ping sigue el dial hacia abajo pero nunca va más lento de 30 s — detección de caídas), SNMP_FLOOR=15, FAST_SNMP_FLOOR=15, EXTRAS_FLOOR=60 (CPU/mem/temp nunca <60 s aunque el dial vaya más rápido).
• SyncManager (core/sync.py) acompasado al target más rápido (min_target_interval(), suelo MIN_SYNC_INTERVAL=15).
• Migración monitoring 0026: default honesto 60 s + backfill de la flota.
• Validación de entrada: MIN_INTERVAL_SECONDS=15 / MAX_INTERVAL_SECONDS=86400 (monitoring/api/schemas.py).
• Ventanas del report wireless dinámicas: max(3m, 2×cadencia+30s) — un equipo a 5 min no muestra huecos.

v1.43.0 · Dial en la UI (PR #261)

• Edit Card (static/js/network/device_card_editor.js): selector “Polling cadence” con 4 opciones — 15 s / 30 s / 1 min (default) / 5 min (CADENCE_OPTS); solo visible si el perfil tiene target de monitorización (polling_interval != null).
• API: GET/PUT /api/network/auto-provision/profiles/{id}/config, campo polling_interval (lee/escribe MonitoringTarget.interval_seconds; el PUT vive en network/api/assign.py y llama notify_agents() para re-empujar los targets al Agente en caliente).
• Timers de charts acompasados a la cadencia en detalles de Wireless/UPS/Signage y pestañas de Observatory (getRefreshInterval() en ObservatoryAutoRefresh.js, suelo 15 s).
• Retirado el selector de refresco por pestaña 5s/10s/20s de Observatory y su copia en Chart Defaults (era el “toggle cosmético”: no gobernaba el sondeo real).

v1.43.1 · Aplicación en caliente (PR #264)

Feedback del click-test de Edu: al guardar la cadencia, la página abierta exigía recargar para adoptar el ritmo.

Patrón CustomEvent — al guardar con cadencia cambiada, device_card_editor.js emite:

window.dispatchEvent(new CustomEvent('devicecard:cadence-changed', {
    detail: { profileId, ip, seconds: config.polling_interval },
}));

Listeners que re-acompasan sin recargar:

• Wireless (wireless.js): actualiza ap.polling_interval + WirelessDetail.repace(profileId, seconds).
• UPS (ups.js): actualiza ups.polling_interval + UpsDetail.repace(profileId, seconds).
• Observatory (observatory.js): actualiza target.interval_seconds + startTabRefresh(tab.id) de la pestaña del target.
• Signage NO escucha el evento: su detalle acompasa al abrirse (startChartRefreshTimer(tabId, device.polling_interval) en SignageDetail.js), pero la Edit Card no se abre desde esa página.

Invariantes

1. Suelo global 15 s en la validación del backend (15–86400); el Agente aplica además los suelos por protocolo y el techo del ping (§motor).
2. Un único dial: el mismo valor gobierna sondeo (SaaS/Agente) y refresco de charts — sin dos fuentes de verdad.
3. Solo re-acompasa lo abierto: el evento afecta a las páginas que están escuchando; el resto adopta la cadencia al cargar.

Impacto usuario

• Gráficas “vivas” a elección, por equipo (15 s para lo que se vigila de cerca, 5 min para lo tranquilo).
• El cambio aplica al instante tras Save — sin recargar la página, sin reiniciar el Agente.
• Reports sin huecos a cualquier cadencia (ventanas dinámicas).
• Cadencias rápidas suben la carga SNMP del dispositivo (avisado en el hint de la Edit Card).

Archivos clave

• Agente (2.13.0): terminal/agent/config.py, sentinel/scheduler.py, sentinel/ping.py, sentinel/snmp_bandwidth.py, sentinel/snmp_fast.py, sentinel/snmp_extras.py, core/sync.py, core/store.py
• Backend: network/api/assign.py, network/api/profiles.py, monitoring/api/schemas.py, monitoring/views.py, monitoring/migrations/0026_interval_seconds_honest_default.py, monitoring/api/wireless.py
• Frontend: static/js/network/device_card_editor.js, static/js/pages/{wireless,ups,observatory,signage}.js, wireless/WirelessDetail.js, ups/UpsDetail.js, signage/SignageDetail.js, observatory/ObservatoryAutoRefresh.js

Gotchas

1. ChartDefaultsIn.refresh_interval (monitoring/api/schemas.py) quedó inerte sin UI que lo escriba — retirada programada en la pasada R7 de schemas (cola auditoría s187).
2. Signage sin hot-repace: si se cambia la cadencia de un player con su detalle abierto, esa página no se entera hasta reabrir (arquitectura: su Edit Card no se abre desde allí).
3. La ficha técnica de referencia del modo Sentinel es [[crearack-tech—architecture—sentinel-mode]] (§4.2 cadencia por target).

Véase también

• [[crearack-tech—architecture—sentinel-mode]] — arquitectura Sentinel con la cadencia por target
• [[crearack—network—device-page]] — ayuda de usuario del dial
• [[entity—network—model—device-profile]]