Incidente: Informante reportaba "0 alertas" con 128 devices caídos (s56)

Incidente: Informante reportaba “0 alertas” con 128 devices caídos

Resumen

Fecha detección: 2026-05-11 (prueba PROD por @Edu / @Esquembri) Severidad: Alta — el Informante daba respuestas materialmente incorrectas al operador Estado: Resuelto en commit 06a228a (s56) Componente: core/services/help_state.py → _build_alerts_context

Síntoma observado

Al preguntar “¿hay alertas?” en el Help Widget de crearack.com, el Informante respondía:

“0 alertas activas (sin incidencias).”

Cuando la org tenía simultáneamente:

• 128 MonitoringTarget con last_status="down" (devices caídos con ping fallido)
• 5 AIInsight con status=PENDING (diagnósticos CNS Sentinel pendientes de aplicar)

Causa raíz

_build_alerts_context solo consultaba AlertEvent (alertas configuradas manualmente por el admin en Observatory con umbrales de latencia, packet loss, etc.).

La org afectada no tenía alertas AlertEvent configuradas, por lo que el conteo era literalmente 0 — pero tenía 128 devices operativamente caídos y 5 diagnósticos IA sin resolver.

El modelo LLM solo disponía del contexto inyectado por help_state.py; si ese contexto decía “0 alertas”, el modelo respondía con “sin incidencias” aunque la realidad fuera distinta.

# Código ANTES del fix (incorrecto):
qs = AlertEvent.objects.filter(alert__organization=org, resolved_at__isnull=True)
total = qs.count()
if total == 0:
    return "Alertas activas: 0 (sin incidencias)."  # ← nunca consultaba devices ni insights

Fix aplicado (commit 06a228a, s56)

_build_alerts_context ahora agrega 3 fuentes:

1. AlertEvent activos (resolved_at IS NULL) — alertas configuradas
2. MonitoringTarget(last_status="down") — devices con ping caído
3. AIInsight(status in [PENDING, EXECUTING]) — diagnósticos CNS pendientes

El total se calcula como suma de las tres, y el resumen etiqueta cada categoría para que el modelo pueda enfocar la respuesta:

Alertas activas: 133 (devices caídos: 128, alertas configuradas: 5, insights IA pendientes: 0).

Adicionalmente, _build_devices_context añade (+N más sin detallar) cuando la lista de devices caídos está truncada a 5, para que el modelo no infiera que solo hay 5 cuando hay más.

Tests añadidos

• test_build_context_with_targets_down — device last_status=down → contado como alerta
• test_build_context_with_pending_insight — AIInsight.Status.PENDING → contado como alerta
• Tests existentes adaptados al nuevo formato de 3 categorías

Validación PROD pendiente

Repetir “¿hay alertas?” en Help Widget de crearack.com con la org de prueba y verificar que ahora se reportan los devices caídos correctamente. Marcar este incidente como resolved tras confirmación.

Lecciones aprendidas

1. El Informante es tan bueno como su contexto: el modelo LLM no puede compensar un contexto incompleto. Cualquier fuente operativa no incluida en help_state.py es invisible para el asistente.
2. “0 alertas” es una respuesta de alta confianza para el operador — si es incorrecta, genera confianza falsa en un sistema degradado.
3. Los builders de contexto deben cubrir todas las fuentes semánticas que el usuario final entiende como “alertas”, no solo las entidades técnicas que el dev llamó “alertas” al diseñar el modelo.

Véase también

• [[entity—core—service—help-state]]
• [[entity—monitoring—model—alertevent]]
• [[entity—monitoring—model—monitoringtarget]]
• [[entity—monitoring—model—aiinsight]]
• [[crearack—redes-infra—monitorizacion]]