Las gráficas de SAI, vivas de fábrica — walk_first, validación de tipos OID y guardia de frescura (task #255, v1.82.5)

Valor para el usuario

La mitad de las gráficas de la pantalla de SAI (UPS Monitor) no podían pintar NUNCA, para ningún fabricante, desde que existe la pantalla: los perfiles de 14 modelos de SAI (y switches Arista/Aruba/Huawei/Juniper, Synology, Raritan — 12 claves en 21 perfiles) declaraban un modo de lectura SNMP (walk_first) que el programa Agente jamás llegó a implementar — el dato se descartaba en silencio, sin error visible en ningún registro. A partir de esta versión el modo ya está implementado (viaja con el próximo release del Agente) y el sistema rechaza al guardar cualquier modo de lectura que el Agente no sepa leer, para que el fallo no vuelva a colarse sin avisar. De regalo: la pantalla de SAI hereda la misma protección que Wireless estrenó diez días antes — un SAI apagado ya no puede presentarse “online” con los datos de su última foto (en un SAI, eso es un dato de seguridad eléctrica) — y la ficha del SAI muestra por fin de cuándo es esa foto.

Cómo usarla

La corrección de walk_first es transparente: no exige acción del usuario, se activa cuando el .exe del Agente Local se actualice al próximo release (el bump de AGENT_VERSION queda deliberadamente pendiente — bump = compilar en el mismo ciclo).
Al dar de alta un SAI nuevo, o al subir un MIB con el asistente de IA, cualquier tipo de OID que el Agente no sepa leer se rechaza al guardar con un error explícito, en vez de crear una métrica muerta.
La ficha de cada SAI (GET /api/monitoring/ups/deep-data) expone deep_data_as_of con la fecha de la última foto profunda.

Implementación

`walk_first` en el Agente (`terminal/agent/sentinel/snmp_extras.py`)

Cuarto tipo de lectura SNMP, junto a gauge (GET escalar), walk_sum (WALK + suma) y walk_count (WALK + cuenta filas):

walk_first: WALK + valor de la PRIMERA fila de la tabla (p. ej. upsOutputLoad, columna de tabla sin índice fijo — un GET nunca la resuelve, y sumar cargas de salidas no significa nada).
Sin filas en la tabla → logger.warning y la métrica se descarta esa ronda, sin romper el resto del poll.

Validación al escribir (`monitoring/api/schemas.py`)

AGENT_SUPPORTED_OID_TYPES = {"gauge", "walk_sum", "walk_count", "walk_first"} — la lista de tipos que el Agente sabe leer de verdad.
TargetConfigIn rechaza (ValueError) cualquier type fuera de esa lista en monitoring_oids/fast_poll_oids al guardar un target.
Antes de este cambio, un tipo sin dispatch producía una métrica que no nacía nunca, sin error en ningún log — así entraron 12 claves walk_first en 21 perfiles sin que nadie lo notara durante meses.

Test de contrato (`tests/network/test_vendor_profile_oid_types.py`, nuevo)

Tres tests que cierran el círculo completo entre servidor, Agente y el origen del desajuste:

test_supported_set_matches_agent_dispatch: lee el código real de snmp_extras.py y comprueba que AGENT_SUPPORTED_OID_TYPES no promete más de lo que el Agente implementa.
test_ningun_vendor_profile_declara_un_tipo_que_el_agente_no_implementa: recorre los VendorProfile sembrados por migración y falla si alguno declara un tipo sin soporte.
test_mib_assistant_solo_ofrece_tipos_implementados: comprueba que el prompt del MIB assistant (el origen del desajuste original) no vuelva a ofrecer un tipo sin implementación.

Guardia de frescura portada de Wireless (`monitoring/api/ups.py`)

Mismo criterio y mismo motivo que [[feature—wireless—clientes-vivos-ahora]] (task #225): _ups_status() dejó de considerar “online” a un SAI con deep_snmp_data pero sin target vivo.

_has_current_ups_data(profile): ¿el MonitoringTarget ve vivo al SAI ahora mismo (last_status == "up")?
_current_ups_metrics(profile): métricas del SAI, o {} si la foto no es del ahora.
Aplicado en las 7 llamadas que antes leían deep_snmp_data directamente: get_ups_summary, get_ups_status_list, get_ups_deep_data, get_ups_dashboard_rankings, get_ups_report, get_ups_fleet_report, get_ups_group_summary.
get_ups_deep_data expone además deep_data_as_of (de deep_snmp_updated_at, el campo de la migración network/0060 que [[feature—wireless—deep-discovery-timestamp]] introdujo para Wireless).

Pieza 3: la tarjeta de grupo de Wireless, el fleco que quedó fuera de la #225

De paso, get_wireless_group_summary() (que sumaba clientes de fotos viejas, el mismo fallo que el resumen general) se cerró en este mismo commit — detalle en [[feature—wireless—clientes-vivos-ahora]].

Deuda declarada

El .exe del Agente Local que implementa walk_first no se publica en este ciclo: AGENT_VERSION queda sin tocar a propósito (bump = compilar y publicar release en el mismo ciclo). Hasta que el usuario actualice el Agente instalado, las gráficas afectadas siguen sin datos.

Commits relacionados

9396d3824dc96dab7ee4684c97413fdb9b3d96e3 (PR #423, 2026-08-23) — v1.82.5, task #255.

Véase también

[[feature—wireless—clientes-vivos-ahora]]
[[feature—wireless—deep-discovery-timestamp]]
[[entity—network—model—vendor-profile]]
[[entity—monitoring—service—snmp-service]]
[[crearack-tech—backend—multi-vendor-snmp-guide]]
[[crearack-tech—architecture—wireless-monitor]]