Monitorización multirregión: cómo eliminar las caídas falsas positivas
· 6 min de lectura
Las falsas alarmas enseñan al equipo a ignorar las alertas. Un cross-check multirregión solo marca una caída cuando la confirman varias sondas independientes.
Por qué miente la monitorización de una sola región
La monitorización clásica tiene una única posición de observación (un servidor o una región cloud). Cuando esa sonda no recibe respuesta, reporta una caída. La causa, sin embargo, puede ser cualquiera de las siguientes:
- Un problema en la propia red de la sonda (route flap, un problema de peering de su proveedor)
- Un glitch de DNS de corta duración del lado de la sonda
- Una caída geográficamente limitada (un edge de CDN cayó en un país)
- Rate limiting o un bloqueo de IP del lado de tu infraestructura
Desde la perspectiva de los usuarios reales, el sitio puede estar perfectamente bien - solo inaccesible para un host de monitorización concreto.
La consecuencia: alert fatigue
Un equipo que recibe 3 notificaciones de "caída" a la semana, de las cuales 2 son falsas alarmas (falsos positivos), poco a poco deja de reaccionar. Cuando luego llega una caída real, la reacción se retrasa o nadie la nota. Este fenómeno se llama alert fatigue (fatiga por alertas) y está bien documentado en la literatura devops.
El objetivo es la mejor relación señal-ruido (signal-to-noise ratio) posible. Es mejor recibir 1 notificación al mes que siempre es real que 10 notificaciones de las cuales 7 son ruido.
El patrón multirregión: consenso de N sondas
El principio:
- Tienes 3 nodos worker en 3 ciudades (primary en Liptovský Hrádok, eu2 en Liptovský Mikuláš, eu1 en Bratislava). El umbral por defecto = 2 de 3, lo que da un consenso real (no unánime). La arquitectura admite cualquier número de nodos; al ampliar, se añaden al mecanismo de consenso existente.
- En cada intervalo todas las sondas prueban el endpoint en paralelo.
- Fusionas el resultado: una caída se confirma si M de N sondas la reportan (típicamente M = 2 o más).
- El fallo de una sola sonda no dispara una alarma - si una sonda reporta "down" pero las demás reportan "up", el sistema permanece en estado UP.
Se trata del llamado consensus algorithm (algoritmo de consenso), similar a Raft o Paxos - la decisión se toma por mayoría de votos.
Configuración práctica
En el panel de administración de ePulz.io, el multirregión se activa con un solo interruptor y se configura mediante:
- Regiones activas - la lista de workers, típicamente 3-5
- Umbral de consenso - cuántas regiones deben decir DOWN (por defecto: 2)
- Worker token - un secreto compartido (shared secret) entre el servidor principal y los workers para la verificación
En cada comprobación, el servidor principal contacta a todos los workers en paralelo a través de la API HTTP. Un worker ejecuta un test HTTP, TCP o ping local y devuelve el resultado. El servidor principal evalúa el consenso y solo escala la alerta cuando se supera el umbral.
Trade-offs
Ventajas:
- Muchas menos falsas alarmas
- Visualización geográfica - ves desde qué regiones el sitio no funciona
- Detección de caídas regionales (problema con un PoP de Cloudflare, enrutamiento defectuoso en un ISP)
Desventajas:
- Latencia algo mayor entre la caída real y la alerta (se espera el consenso de varias fuentes)
- Mayores exigencias de infraestructura y un plan de precios superior
- Disponibilidad de los workers - si la mitad de los workers están a su vez inaccesibles, el umbral puede no ser alcanzable (la solución es un umbral dinámico = M de las sondas actualmente vivas)
Ejemplo de cálculo de consenso
Configuración de 3 nodos worker realmente desplegados: primary en Liptovský Hrádok (SK), eu2 en Liptovský Mikuláš (SK), eu1 en Bratislava (SK), umbral = 2.
| Escenario | primary (Liptov) | eu1 (Bratislava) | eu2 (Liptov) | ¿Alerta? |
|---|---|---|---|---|
| Todo OK | UP | UP | UP | No |
| BGP flap entre Liptov y tu hosting | DOWN | UP | UP | No (1 de 3) |
| Fallo HW de la máquina primary | DOWN | UP | DOWN | Sí (2 de 3) |
| Caída real de tu servidor | DOWN | DOWN | DOWN | Sí |
Cómo desplegar tus propios workers
Un worker es un servicio sencillo que recibe tareas de comprobación por HTTPS, ejecuta el test y devuelve el resultado. ePulz.io admite workers propios a través de un túnel WireGuard, de modo que pueden ejecutarse en cualquier VPS sin IP pública y comunicarse con el servidor principal por un túnel cifrado.
Configurar un solo worker lleva en la práctica unos 10 minutos (apt install wireguard, copiar la config del peer, systemctl enable). Así obtienes posiciones de observación realmente independientes, que combinan diversidad geográfica (ciudades distintas) con redundancia de hardware (máquinas distintas en la misma ciudad).
Conclusión
La monitorización multirregión no es solo un eslogan de marketing. Es un patrón de ingeniería concreto (quórum, o consenso) que lleva la monitorización del nivel "veo lo que ve una posición de red" al nivel "veo lo que ve internet". Para aplicaciones de negocio críticas, hoy es el estándar.
Elimina las alertas falsas positivas
Cross-check multirregión en los planes base (gestionado de forma centralizada). 7 días gratis.
Relacionado
Prueba ePulz.io gratis - 7 días sin tarjeta de crédito.
Crear cuenta