Voto de consenso en monitoreo de uptime | por qué tiene sentido

El monitoreo multirregión clásico reduce falsos negativos pero sube los positivos. El voto por consenso resuelve ambos. Análisis didáctico del patrón.

El punto débil del monitoreo mono-región

El monitoreo mono-región significa que su checker se ejecuta desde una sola ubicación. Si ocurre un problema de red en la ruta entre esta ubicación y su servidor (BGP flap, cambio de enrutamiento, mantenimiento de un ISP), el monitor reporta DOWN aunque el servidor funcione correctamente.

Esto es un falso positivo. Recibe la alerta, se despierta a las 3 de la madrugada, abre su portátil y descubre que el sitio funciona.

Los falsos positivos perjudican por dos razones:

Fatiga de alerta. Si recibe notificaciones que resultan ser falsas, gradualmente empieza a ignorarlas. Incluso las reales.
Pérdida de confianza en el monitoreo. El equipo deja de reaccionar a las alertas porque «probablemente sea BGP otra vez».

El multi-región ingenuo resuelve un problema y empeora el otro

La forma común de abordar esto es el monitoreo multi-región. El checker se ejecuta desde varias ubicaciones y una alerta se dispara cada vez que cualquiera de ellas reporta DOWN.

Esto mejora la detección de caídas reales: cuando el servidor es realmente inalcanzable, no es solo un checker el que queda en silencio, sino varios a la vez. Hasta aquí, bien.

Sin embargo, el problema de los falsos positivos empeora. Con un checker tenía cierta tasa de falsas alertas. Con tres checkers es matemáticamente más probable que al menos uno de ellos reporte falsamente DOWN. El resultado son más falsas alertas, no menos.

El voto de consenso resuelve ambos lados

El voto de consenso funciona de forma diferente: al primer signal DOWN no se dispara ninguna alerta. Primero se consulta a las otras regiones. Si la mayoría de ellas también reporta DOWN, es una caída real. Si no, es solo una anomalía de red en una sola región.

Pseudocódigo:

result = check_http(monitor)  # primary region
if result.status == 'down':
    secondary_results = check_from_other_regions(monitor)
    if secondary_results:
        # Default rule: 2 of 3 regions must agree on DOWN
        if count_down(secondary_results) + 1 >= 2:
            result.status = 'down'
        else:
            result.status = 'up'
            result.note = 'consensus mismatch'

Ejemplo de escenario:

primary  -> DOWN  (un checker tuvo un BGP flap)
region_a -> UP    (otras regiones ven el servidor con normalidad)
region_b -> UP

Resultado: UP. Sin alerta. Entrada en el debug log.

Y lo contrario, una caída real:

primary  -> DOWN
region_a -> DOWN
region_b -> DOWN

Resultado: DOWN. La alerta sale por Telegram/email/webhook.

Compromiso: latencia

El voto de consenso tiene un coste: ante un signal DOWN añade unos segundos extra de latencia mientras consulta las otras regiones. Para la mayoría de casos de uso (uptime monitoring con intervalo de un minuto) es insignificante. Para SLAs extremadamente estrictos con tiempo de detección por debajo de 30 segundos puede convertirse en un compromiso notable.

Cuándo el multi-región no tiene sentido

APIs internas en 192.168.x.x. Nadie fuera de su red puede alcanzarlas, así que el multi-región desde Internet no tiene sentido. Para LAN use un patrón pull-agent: el agente se ejecuta en su red y empuja los resultados hacia fuera por HTTPS.
Aplicación interna de un único cliente. Si solo unas pocas personas la usan y usted es una de ellas, sabrá de una caída antes que el monitoreo.
Un servicio que solo funciona en una región del mundo. Si su servicio es solo para la UE y lo ve como DOWN desde EE. UU., no es un falso positivo, sino lo esperado.

Cómo lo hacemos en ePulz.io

ePulz.io tiene voto de consenso en su arquitectura. gather_multiregion() y combine_consensus() en monitoring.py implementan el patrón anterior. El umbral (cuántas regiones deben confirmar DOWN) es configurable mediante el parámetro min_down.

En la tabla Check cada fila almacena un campo consensus con CSV (por ejemplo "primary:up,region_a:up,region_b:down"), de modo que para depurar tiene el registro exacto de cómo se tomó la decisión.

Conclusión

El voto de consenso no es una solución mágica. No le dará cero falsos positivos y no le salvará en una caída real. Pero es un mejor compromiso que el mono-región (alta tasa de falsos positivos durante anomalías de red) o el multi-región ingenuo (multiplicación de falsos positivos).

Eche un vistazo a ePulz.io. Prueba de 7 días, 3 monitores, sin tarjeta de crédito.

Voto de consenso en monitoreo de uptime - por qué tiene sentido