Estrategias de reintento: confirmar un estado antes de avisar
Un reintento es la segunda opinión que pide un sistema de monitorización antes de creerse un cambio de estado, repitiendo la comprobación fallida o recién correcta desde otras ubicaciones para que un solo punto de vista malo no pueda abrir una incidencia por su cuenta. HostTracker comprueba un sitio con el calendario fijado en su configuración de monitorización, y un nuevo estado UP o DOWN detectado se trata como candidato hasta que el reintento lo confirma.
Por qué una comprobación fallida no es una caída
Un resultado de comprobación describe una petición, desde un sitio, en un momento. Cualquiera de esas tres cosas puede estar equivocada sobre el sitio en su conjunto. La red entre un único punto de control y tu servidor puede estar rota mientras todas las demás rutas van bien. Un registro DNS puede seguir propagándose en una región y ya estar correcto en la siguiente. El propio entorno de un punto de control puede ser incompatible con algo que hace tu servidor.
Si un sistema de monitorización actuara ante cada primer resultado, te avisaría por todo eso y además corrompería tus estadísticas de uptime, ya que la caída que registró nunca ocurrió para tus usuarios. Así que el estado detectado, UP o DOWN, se mantiene sin verificar hasta que se confirma, y solo entonces pasa algo aguas abajo: sale una alerta, se abre un episodio, se mueve la cifra de uptime.
Qué detecta un reintento
Reintentar desde otras ubicaciones es lo que separa un cambio real y a escala de todo el sitio de un artefacto local. Los casos que filtra más a menudo son:
- Una caída corta durante un despliegue nuevo, donde el sitio vuelve antes de que se ejecute una segunda comprobación
- Indisponibilidad de DNS mientras se propaga un cambio de configuración, así que algunos resolutores responden y otros no
- Una inclusión en lista negra local del sitio o de la dirección del punto de control, visible solo desde una red
- Un agente de comprobación cuyo entorno es incompatible con las tecnologías que usa el servidor
- Problemas de enrutamiento o de peering en la ruta entre un único punto de control y el servidor
Las comprobaciones de confirmación se sacan de la región geográfica configurada para la tarea de monitorización, así que la segunda opinión viene de la misma parte del mundo en la que están tus usuarios y no de donde sea que esté libre.
Las tres estrategias de reintento
HostTracker admite tres formas de decidir si un estado nuevo es real.
1. Voto por mayoría. Cuando una comprobación devuelve un estado nuevo, el sistema asigna hasta 7 ubicaciones nuevas de la región geográfica de la tarea de monitorización para confirmarlo. Los resultados devueltos se agrupan por estado, y gana el grupo más grande. Supongamos que una comprobación desde Miami reporta DOWN, y los reintentos desde Nueva York, Boston y Chicago vuelven UP, DOWN, UP. El DOWN queda sin confirmar y se descarta, y Miami queda penalizado: no se usará para las comprobaciones de ese sitio. Ejecuta el mismo ejemplo al revés, con Miami reportando UP después de un DOWN y Nueva York y Chicago confirmando UP, y la transición DOWN-UP se registra.
2. Un número fijo de ubicaciones que confirmen DOWN. Aquí configuras el número mínimo de reintentos necesarios para confirmar un DOWN, mientras que un UP sigue exigiendo el voto por mayoría. Con ese número fijado en 1, en el mismo ejemplo, que solo Boston devuelva DOWN basta para confirmar el DOWN de Miami, aunque Nueva York y Chicago no estuvieran de acuerdo.
3. Sin reintento. El estado nuevo siempre se confirma en cuanto se detecta. Esto supone una confianza total en el servidor y en los entornos de las ubicaciones de monitorización. Encaja con unas pocas necesidades de monitorización concretas, y hay que elegirlo con cuidado, porque cualquier problema de red pasajero en un único punto de control se convierte en una falsa alerta y en un bache en la cifra de uptime.
Elegir una estrategia
- Empieza por el voto por mayoría. Es el valor por defecto equilibrado: cuesta unos segundos extra de confirmación y elimina casi todo el ruido de un único punto de control.
- Baja el umbral de confirmación de DOWN cuando una alerta rápida vale más que una bandeja tranquila. Una caída regional que solo dos ubicaciones pueden ver te sigue llegando, al coste de más falsos positivos.
- Mantén el voto por mayoría para las transiciones UP sea cual sea cómo fijes DOWN. Un UP prematuro cierra una incidencia que todavía está en marcha y esconde la cola de la caída de tus estadísticas.
- Reserva la opción sin reintento para objetivos que controlas de principio a fin, donde prefieres investigar una alerta falsa antes que esperar la confirmación.
Elijas la estrategia que elijas, puedes reproducir un desacuerdo tú mismo desde dos redes distintas y comparar lo que ve cada una:
curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/Un 503 desde una red y un 200 desde otra es exactamente el patrón que el reintento está pensado para resolver. Si el estado que falla es un 5xx en lugar de un tiempo de espera agotado, el servidor respondió, que es un problema distinto: consulta 503 Service Unavailable.
Qué te da la confirmación
Los reintentos son lo que deja a un sistema de monitorización ejecutar comprobaciones frecuentes desde muchos sitios sin convertir esa sensibilidad en ruido. HostTracker comprueba desde más de 300 puntos de control en 158 ciudades, así que siempre hay ubicaciones independientes disponibles para la segunda opinión, y solo una transición confirmada dispara una alerta por correo, SMS, llamada de voz, Slack, Telegram y más. Las estrategias de arriba no son todo el conjunto posible, y el soporte puede plantearse una nueva para una futura versión si tu monitorización tiene una necesidad que ninguna de ellas cubre. Consulta monitorización de disponibilidad distribuida para ver cómo se usa la red de puntos de control, y el resto de la sección de conceptos de monitorización para los términos que hay detrás.