Un monitor que da la voz de alarma sin motivo es peor que ninguno. Tras unas cuantas falsas alarmas, la gente deja de leer las alertas, y la verdadera recibe el mismo encogimiento de hombros. Esta guía explica de dónde vienen las falsas alertas y qué puedes hacer al respecto.

Primero, una definición. Una falsa alerta es una alerta sobre un problema que tus visitantes no tuvieron. No es lo mismo que una caída real y breve: un sitio que estuvo inalcanzable durante dos minutos estuvo realmente caído, y la alerta era correcta.

De dónde vienen las falsas alertas

Un corte entre el monitor y el sitio

La comprobación viaja por internet público. Un paquete perdido por el camino, un enlace congestionado o un breve problema de enrutamiento pueden hacer que falle una comprobación mientras el sitio está perfectamente sano para sus visitantes. Es la causa más común, y se pasa sola.

Se bloquea al monitor

Los cortafuegos, la protección contra bots y los límites de frecuencia están hechos para frenar las solicitudes automatizadas, y un monitor envía solicitudes automatizadas. Si tu protección responde a una comprobación con una página de desafío o con un 403 Forbidden, el monitor ve un fallo mientras las personas reales pasan.

UptimeWire trata como comprobación fallida cualquier respuesta final fuera del rango de 200 a 399. Eso incluye 401 y 403. Si tu sitio muestra esa respuesta a los visitantes automatizados, permite el acceso al monitor. En el momento de escribir esto, las solicitudes de UptimeWire se identifican como UptimeWireBot/1.0.

Una página lenta

Una comprobación espera una respuesta durante un tiempo limitado. En UptimeWire, una comprobación se rinde a los 15 segundos. Una página que a veces tarda más, por ejemplo mientras se calienta una caché, hará fallar esas comprobaciones aunque un visitante paciente sí obtendría una página.

Monitoriza una dirección que responda rápido, como una página sencilla o una página de estado, en lugar de una página pesada de búsqueda o de informes.

Demasiadas redirecciones

UptimeWire sigue hasta cinco redirecciones. Una cadena más larga, o un bucle entre dos direcciones, cuenta como un fallo, con el motivo «más de 5 redirecciones». Los navegadores también tienen un límite, así que una cadena tan larga es un fallo real, pero puede que solo se note en un monitor.

Una regla de texto de página demasiado estricta

Una regla de texto de página hace fallar la comprobación cuando falta el texto esperado o cuando aparece texto prohibido. UptimeWire lee el HTML sin procesar de la página, hasta 1 MB, y busca el texto sin distinguir mayúsculas de minúsculas. No ejecuta scripts. El texto que el navegador añade con JavaScript no está en ese HTML, así que una regla basada en él fallará en una página sana.

Trabajo planificado

Un despliegue, una migración de base de datos o un reinicio del servidor hacen que el sitio falle a propósito. Si el monitor no lo sabe, informa de una caída real que has causado tú. No es falsa en el sentido de que sea mentira, pero es ruido, y las ventanas de mantenimiento planificadas existen para eliminarlo.

Cómo reducen el ruido las comprobaciones repetidas

La defensa más sencilla es no creerse un fallo aislado. Cuando una comprobación falla, UptimeWire vuelve a comprobar. Un incidente se abre solo tras tres comprobaciones fallidas seguidas, separadas unos 20 segundos. Se cierra tras dos comprobaciones correctas.

Cuando hay más de una ubicación de comprobación disponible, un fallo debe ser visto además por más de la mitad de las ubicaciones que respondieron. Cuando solo hay una ubicación disponible, se puede pedir una segunda opinión a otro servidor antes de abrir el incidente, si hay uno configurado. Sin segunda opinión, un incidente puede abrirse con los tres fallos de un único lugar.

La contrapartida es clara. Repetir una comprobación cuesta algo de tiempo, aproximadamente 40 segundos sumados al intervalo de comprobación. A cambio, las falsas alertas bajan mucho. No ofrece una detección instantánea, y ningún ajuste la ofrece.

Ventanas de mantenimiento planificadas

Para el trabajo que puedes prever, avisa al monitor con antelación. En UptimeWire programas una ventana de mantenimiento planificada para un sitio web. Las comprobaciones siguen ejecutándose y el historial muestra los fallos, pero:

  • Las alertas de incidentes que empiezan dentro de la ventana se retienen. Si la caída termina dentro de la ventana, las alertas se cancelan. Si se prolonga más allá del final, se envían cuando termina la ventana.
  • El tiempo dentro de la ventana se deja fuera del cálculo de disponibilidad.
  • Los avisos sobre el certificado, el dominio y el DNS no se retienen por la ventana.

Una ventana debe configurarse con antelación, y se aplican límites a su duración y a su número. Es una herramienta para el trabajo que anuncias, no una forma de esconder una caída.

Qué ajustar, en orden

  1. Lee los motivos de los fallos. El historial de incidentes muestra por qué falló cada comprobación: tiempo de espera agotado, conexión rechazada, nombre sin resolver, error de certificado o un código de estado. Un patrón en los motivos suele señalar la causa.
  2. Permite el paso del monitor por tu protección si el motivo es 403 o un desafío.
  3. Elige una dirección más ligera si el motivo es un tiempo de espera agotado.
  4. Revisa las reglas de texto de página. Asegúrate de que el texto está en el HTML sin procesar.
  5. Usa ventanas de mantenimiento para el trabajo planificado.
  6. Elige adónde van las alertas. Envía la primera alerta a un lugar donde una persona la vea, y reserva los canales ruidosos para lo que importa.
  7. Envía una notificación de prueba para confirmar que la ruta funciona. También te muestra qué aspecto tiene la alerta a las 3 de la madrugada.

Qué no hacer

  • No alargues el intervalo de comprobación para reducir las alertas. Solo retrasa la detección de las caídas reales.
  • No ignores un patrón repetido. Si un monitor falla a la misma hora cada noche, algo ocurre a esa hora. Podría ser una copia de seguridad que ralentiza el servidor.
  • No apagues un monitor para acabar con el ruido. Arregla la causa.

Cuando la alerta es real pero breve

Una caída breve puede ser real y aun así parecer ruido, por ejemplo un reinicio que tarda un minuto. Si se repite, es un problema real con una huella pequeña. Cuéntalo. El historial de incidentes registra las horas de inicio y de fin, así que puedes ver con qué frecuencia ocurre y cuánto dura.

Una comprobación HTTP tampoco puede ver todos los tipos de fallo. Una respuesta 200 no demuestra que el pago funcione, y el silencio de un monitor no es prueba de que no pase nada. Monitorización de la disponibilidad de sitios web explica qué mide una comprobación y qué se le escapa.

Lista de comprobación

  • ¿Las alertas llevan un motivo? Léelo.
  • ¿Se permite el paso del monitor por la protección contra bots y los límites de frecuencia?
  • ¿La dirección monitorizada responde con holgura en menos de 15 segundos?
  • ¿Las reglas de texto de página se basan en el HTML sin procesar?
  • ¿Los cambios planificados están cubiertos por una ventana de mantenimiento?
  • ¿La primera alerta llega a alguien que actuará?