Equipos fuera de servicio — Take out of Service / Return to Service

User value

Caso real del CCIB: puntos de acceso de refuerzo que salen al evento y vuelven a la estantería. Guardados en el almacén, salían como “caídos” en Observatory, encabezaban los rankings de “peores equipos” y bajaban artificialmente la salud de toda la flota. Take out of Service / Return to Service resuelve esto: un botón por ficha (cualquier tipo de equipo: puntos de acceso, SAI, pantallas) que lo saca del cómputo de caídos sin ocultarlo ni borrarlo — aparece en gris en las listas.

Decisiones de Edu (17-09, task #323): cualquier tipo de equipo puede marcarse · vuelve al servicio solo cuando contesta al ping (no automático por tiempo) · sigue contando para el plan de racks · nunca desaparece de las listas.

Cómo funciona

• Estado propio en MonitoringTarget (out_of_service_at / _by / _seen_down), deliberadamente distinto de enabled=False (que ya significa “su Device se borró del rack”) — migración 0035.
• monitoring/services/service_state.py: funciones idempotentes take_out_of_service / return_to_service, avisan al Agente en el acto; note_reachability decide cuándo procede la vuelta automática; for_agent filtra lo que el Agente recibe.
• Guarda de la vuelta automática: solo se reactiva un equipo si se le vio caído (_seen_down) DESPUÉS de sacarlo de servicio — si no, marcarlo con el equipo aún enchufado lo devolvería al instante al primer ping.
• Sin versión nueva del Agente: las dos vías de lista de targets (REST y WebSocket) le entregan solo el ping a un equipo fuera de servicio, nunca SNMP completo.
• Vía viva: sin alertas mientras está fuera de servicio; metric_update lleva el flag out_of_service; el Agente ya no abre incidencias del CNS por un equipo guardado (mismo patrón que la supresión por sonda TCP — evita correo al cliente, SLA e IA de diagnóstico de más).
• overview y los rankings de “peores” no cuentan un equipo fuera de servicio como caído.
• API: POST .../out-of-service y .../return-to-service, permiso observatory:edit.
• Frontend: static/js/services/ServiceState.js, componente compartido por las 4 fichas (Observatory, Wireless, UPS, Signage); confirma solo al sacar, la fila queda en gris, la vuelta automática llega por metric_update.

Implementación

Migración 0035 · monitoring/services/service_state.py (113 líneas) · monitoring/api/targets.py, wireless.py, insights.py, schemas.py · terminal/api/sentinel.py + sentinel_ingest.py + terminal/fleet_lifecycle.py (vía del Agente) · static/js/services/ServiceState.js (97 líneas) + integración en las 4 páginas de detalle · 17 tests pytest + 9 vitest (tests/monitoring/test_out_of_service.py, 270 líneas).

Commits relacionados

• cd881f980 (17-09-2026) — v1.138.0, motor + botones (los dos PRs de la task #323 llegaron en un solo commit a main).
• e49c55a1 (18-09-2026) — v1.138.2, remate: excluido de informes de flota y del Informante de la Ayuda.

Véase también

• [[feature—monitoring—dashboard-customize]]
• [[feature—monitoring—group-report-button]]
• [[incident—20260917—notificacion-agente-retraso-transaction-on-commit]]
• [[entity—monitoring—targetlistout-payload-slim]]