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

El monitoreo multi-región clásico reduce los falsos negativos pero aumenta los falsos positivos. El voto de consenso resuelve ambos. Un 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. Bien.

Pero 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. Recibe 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 dispara una alerta. Primero pregunta a las otras regiones. Si la mayoría de ellas también reporta DOWN, es una caída real. Si no, es 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 - en un signal DOWN añade unos segundos de latencia para consultar 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 ser un compromiso.

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 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 - es 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.

Para autoalojar un worker en otra región, el panel de admin tiene un generador de bundle WireGuard - crea un tar.gz con la configuración para un nuevo nodo worker y lo añade a worker_urls.

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.