Reintentos Antes de Alertar

Reintentos Antes de Alertar

¿Qué son los reintentos?

Los reintentos vuelven a ejecutar una comprobación fallida antes de enviarle una alerta. Una única petición fallida no siempre es una caída real: un corte breve de red, un arranque en frío lento o un tiempo de espera puntual pueden hacer fallar una comprobación aunque su API esté sana. Los reintentos le permiten confirmar que un fallo es real antes de avisar a nadie.

Los reintentos solo se producen cuando una comprobación falla. Una comprobación correcta nunca se reintenta, así que esta opción no le cuesta nada mientras todo esté sano.

¿Por qué usar reintentos?

La razón principal es el ruido de las alertas. Sin reintentos, cada corte pasajero se convierte en una alerta, y las alertas que casi siempre son falsas acaban ignorándose. Con reintentos, solo se entera de los fallos que han sobrevivido a varios intentos.

Ponga Reintentos en 0 para desactivar la función. Está desactivada de forma predeterminada.

Los ajustes

Cómo funciona el backoff

El backoff decide cuánto esperamos antes de cada reintento, partiendo de su Intervalo. Para un intervalo de 10 segundos:

• Fijo espera el mismo intervalo cada vez. Úselo cuando espere que un fallo se resuelva rápido.
• Lineal hace crecer la espera de forma constante. Un término medio razonable.
• Exponencial duplica la espera cada vez. Úselo cuando un servicio con dificultades necesite margen para recuperarse y no quiera que sus reintentos añadan carga.

Tiempo máximo de reintento

El tiempo máximo de reintento es un presupuesto para toda la secuencia, medido desde el inicio del primer intento. Antes de cada espera, comprobamos si esa espera llevaría la secuencia más allá del presupuesto. Si es así, paramos e informamos del último fallo.

Esto significa que el presupuesto puede terminar sus reintentos antes de haberlos usado todos, y es intencionado. Por ejemplo, con un intervalo de 10 segundos, backoff Exponencial, 3 reintentos y un presupuesto de 60 segundos, el tercer reintento necesitaría una espera de 40 segundos además de los aproximadamente 30 segundos ya consumidos. Eso supera el presupuesto, así que la comprobación se detiene tras el segundo reintento.

Si quiere que se ejecuten todos sus reintentos, asegúrese de que el presupuesto sea mayor que la suma de las esperas anteriores.

Qué se registra

Solo se guarda el último intento como resultado de la comprobación. Esto es lo que hace útiles a los reintentos:

• Falla y luego pasa en un reintento: la comprobación se registra como correcta y no se envía ninguna alerta. El corte pasajero nunca le llega.
• Falla en todos los intentos: la comprobación se registra como fallida y sus canales de alerta se activan como siempre.

Como solo se almacena el resultado final, los reintentos no distorsionan sus cifras de disponibilidad con cortes pasajeros.

Región

Misma región reintenta desde la misma ubicación que vio el fallo. Otra región está reservada para confirmar un fallo desde una segunda ubicación. En la versión actual, "Otra región" sigue reintentando en la misma región.

Casos de uso prácticos

• APIs públicas a través de internet: 1 o 2 reintentos con backoff Fijo y un intervalo corto filtran el ruido de red habitual.
• Servicios con arranque en frío: use backoff Lineal o Exponencial para que una primera respuesta lenta tenga tiempo de calentarse.
• Un servicio bajo carga: use backoff Exponencial para que sus reintentos le den margen en lugar de añadir presión.
• Comprobaciones críticas que deben alertar de inmediato: deje Reintentos en 0 para que un solo fallo avise al momento.

Una nota sobre la frecuencia

Mantenga su presupuesto de reintentos por debajo de la frecuencia de su comprobación. Si una comprobación se ejecuta cada minuto y sus reintentos pueden durar hasta 300 segundos, una comprobación fallida seguiría reintentando cuando toque la siguiente ejecución.