Incidente 24-08-2026 · el cortacircuitos mixto silenció el SNMP vivo del CCIB 15 minutos

Cuándo

24-08-2026, 18:37–18:52 (unos 15 minutos), justo tras el reinicio del Agente Local con la versión 2.21.0 en el CCIB (Centre de Convencions Internacional de Barcelona) — la organización de la flota con 123 puntos de acceso (APs), 122 de ellos con ICMP bloqueado por firewall pero con SNMP accesible.

Síntomas visibles

• Ese conjunto de APs se quedó 15 minutos seguidos sin una sola muestra SNMP en VictoriaMetrics, con el ping funcionando con normalidad todo el rato (falso positivo de “todo va bien”).
• En otra ronda de medición (sonda W-H5) se detectaron huecos de ~200 segundos en las series SNMP de los mismos equipos.
• Un equipo realmente caído producía 5 lecturas en cero (ping_reachable=0) y luego 5 minutos de silencio total — ni una muestra más, de ningún protocolo — mientras el circuito estaba abierto.
• El cálculo de disponibilidad (avg_over_time(ping_reachable)) ignoraba esos huecos de silencio y sobreestimaba el uptime real del equipo.

Causa raíz

El Agente Local (versión 2.21.0) compartía un único cortacircuitos (circuit breaker) entre los tres protocolos de sondeo de un mismo equipo — ping, TCP y SNMP. Cuando el ping fallaba varias veces seguidas, el circuito se abría y saltaba también los bucles SNMP y TCP de ese mismo equipo, aunque esos protocolos siguieran respondiendo con normalidad.

En redes como la del CCIB, donde el firewall filtra ICMP (ping) pero deja pasar SNMP, esto invertía el propósito del breaker: en vez de proteger de un equipo realmente caído, silenciaba datos sanos por el fallo de un protocolo que ese equipo nunca iba a responder. Y en el estado intermedio HALF_OPEN, el ping se quedaba con el turno de la sonda de prueba y reabría el circuito antes de que el SNMP tuviera ocasión de demostrar que funcionaba, cerrando el paso una y otra vez.

Fix aplicado

Commit 72239ae4 (PR #430, v1.83.1 + Agente 2.21.1, task #263 — ciclo 2 de la auditoría #261, hallazgo A03):

• El cortacircuitos pasa a ser puro de SNMP: solo los bucles SNMP lo consultan (should_skip) y lo alimentan (record_success/record_failure).
• terminal/agent/sentinel/ping.py y terminal/agent/sentinel/tcp_check.py dejan de consultarlo y de alimentarlo — un equipo con ICMP bloqueado y SNMP vivo ya no pierde sus muestras SNMP por los fallos del ping.
• Un equipo caído sigue emitiendo ping_reachable=0 a su cadencia normal en vez de callar 5 minutos, así que el uptime (avg_over_time) deja de inflarse por los huecos.
• De paso (hallazgo A11 del mismo ciclo): sin respuesta del ping ya no se emite ping_latency=0 — esa muestra falsa hundía la gráfica de latencia y falseaba el mínimo/promedio.

Lecciones

Un cortacircuitos compartido entre protocolos con vías de red distintas (ICMP vs SNMP vs TCP) puede terminar silenciando la señal sana de uno por el fallo del otro: el fallo no siempre correlaciona entre protocolos, y agregarlos en un único breaker asume que sí. El caso del CCIB (122 de 123 APs con ICMP filtrado) es el escenario donde ping y SNMP divergen más — el peor caso posible para un breaker compartido, y el que lo destapó en producción el mismo día del reinicio de 2.21.0.

Preventivos futuros

• El cortacircuitos queda dedicado a SNMP, la señal con coste real que justifica protegerse de reintentos (sesiones SNMP, no solo paquetes ICMP). Ping y TCP, al ser sondeos baratos, siguen intentándolo siempre.
• Test de regresión en tests/agent/test_sync_and_ping_honesty.py: verifica que el bucle de ping no consulta el breaker y no emite latencia sin respuesta.

Véase también

• [[entity—terminal—service—sentinel-tcp-check]]
• [[entity—terminal—endpoint—agent-metrics-bulk]]
• [[crearack-tech—architecture—sentinel-mode]]
• [[crearack-tech—agents—dev-terminal]]
• [[feature—monitoring—sonda-tcp]]
• [[concept—monitoring—cns]]
• [[feature—monitoring—sesion-107-auditoria-suprema-sub-area-2]]