107901 Una regla de alerta que jamás puede ser cierta

vigilancia_que_no_puede_dispararse

El servicio tiene este código declarado, pero todavía no lo emite.

Clase común a toda la flota (familia «dependencia»): Dependencia no contestó a tiempo. El fallo está en algo de lo que depende fleet-telemetry, no en la petición.

Qué ha pasado

Una regla sintácticamente correcta y bien intencionada cuya expresión no puede ser verdadera en los objetivos que dice cubrir: la métrica no existe, la serie nunca llega, o el umbral es inalcanzable por construcción en ese host. En el panel se ve igual que una regla sana esperando a que algo pase.

Cómo se soluciona

Ejecutar central/prometheus/comprobar-reglas-mudas.py contra el Prometheus de producción y clasificar cada resultado en las tres clases: contador que aún no nació (sano), señal intermitente (sano) y vigilancia inexistente (el fallo). Para lo tercero: o se alimenta la señal, o se retira la regla. Dejarla es peor que no tenerla, porque da sensación de cobertura.

Qué hacer mientras tanto

Hasta arreglarlo, tratar ese plano como NO vigilado y comprobarlo a mano.

Ya costó tiempo

30-ago-2026: de 61 reglas, dos llevaban más de 30 días sin una sola serie. CertExpired y CertExpiringSoon no vigilaban NINGÚN certificado de la flota porque la lista del colector está vacía. Antes, SwapSaturation miraba el swap de un host que no tenía swap —cero por construcción— y las reglas matrix_adapter_* quedaron huérfanas al cambiar de transporte.

Dónde se lanza

central/prometheus/rules.yml — cualquier grupo

Cómo se lee el código

1: origen: Fortiseg
07: servicio: fleet-telemetry
901: clase común a toda la flota: Dependencia no contestó a tiempo