Qué es el Synthetic Monitoring (monitorización sintética): definición, tipos y RUM

¿Qué es la monitorización sintética?

La monitorización sintética (synthetic monitoring) ejecuta comprobaciones con guion contra un sitio web, una API o una aplicación según un calendario, desde las ubicaciones que elija, y le avisa cuando una comprobación falla o se vuelve lenta. El tráfico es artificial, así que funciona a las 3 de la madrugada y antes del lanzamiento, sin necesidad de visitantes. Responde continuamente a una pregunta: ¿sigue funcionando esto como lo diseñamos?

Esta página explica el concepto. Para configurar comprobaciones, consulte la monitorización sintética de LoadFocus, que incluye comprobaciones de API y de navegador con Playwright.

Cómo funciona la monitorización sintética

1. Definir una comprobación. Una URL, una petición a una API o un recorrido de navegador con guion, más aserciones: código de estado, texto en el cuerpo, tiempo de respuesta por debajo de un límite.
2. Programarla. Cada minuto en servicios críticos, cada pocos minutos en la mayoría, cada hora o cada día en páginas de poca prioridad.
3. Ejecutarla desde varias ubicaciones. Un fallo visto desde una región y no desde otra apunta a problemas de enrutamiento, de CDN o de DNS. Exigir que dos ubicaciones coincidan también reduce las falsas alarmas.
4. Registrar el resultado. Tiempos, estado y, en las comprobaciones de navegador, capturas de pantalla y cascadas de red.
5. Avisar. Por correo, Slack, webhook o buscapersonas, y si se desea solo tras varios fallos seguidos.

Tipos de comprobaciones sintéticas

• Comprobaciones de disponibilidad. Solicitan una URL y confirman que responde con el estado esperado.
• Comprobaciones de API. Llaman a un endpoint con cabeceras y cuerpo y verifican estado, cabeceras, contenido y tiempo. Las comprobaciones de varios pasos encadenan llamadas, por ejemplo iniciar sesión, tomar el token y llamar a un endpoint protegido. Véase monitorización de APIs.
• Comprobaciones de navegador. Manejan un navegador real por una página o un recorrido como inicio de sesión, búsqueda y pago, e indican qué paso falló o se ralentizó.
• Comprobaciones de velocidad de página. Cargan una página en condiciones de laboratorio de forma periódica y siguen métricas como Largest Contentful Paint y Total Blocking Time. Véase Core Web Vitals.
• Comprobaciones de SSL y DNS. Vigilan la caducidad de los certificados y que un nombre de host resuelva a la dirección correcta.

Monitorización sintética frente a monitorización de usuarios reales

Miden cosas distintas y los equipos maduros usan ambas.

La comparación completa está en monitorización sintética frente a monitorización de usuarios reales.

Métricas que conviene seguir

• Disponibilidad. Proporción de comprobaciones correctas en un periodo. Los objetivos como el 99,9 % suelen informarse a partir de esta cifra.
• Tiempo de respuesta. De extremo a extremo, idealmente desglosado en DNS, conexión, TLS, espera y descarga.
• Tasa de errores. Aserciones fallidas y códigos de estado inesperados.
• Time to First Byte. Una señal rápida de la salud del servidor.
• Métricas de navegador. LCP, CLS y TBT en comprobaciones de navegador o de velocidad de página. El Interaction to Next Paint requiere usuarios reales, por lo que en laboratorio el TBT hace de indicador de capacidad de respuesta.

Un ejemplo sencillo

Una tienda en línea añade una comprobación de API para GET /products?limit=1 que debe devolver 200 con un cuerpo JSON que contenga items en menos de 500 ms, y una comprobación de navegador que recorre inicio de sesión, búsqueda y añadir al carrito. Ambas se ejecutan cada pocos minutos desde dos regiones. Cuando el paso del carrito empieza a fallar tras un despliegue, la alerta indica el paso y adjunta la captura, antes de que la mayoría de los clientes lo noten.

Errores habituales

• Comprobar solo la página de inicio. La portada puede estar activa mientras el inicio de sesión o el pago están rotos.
• Verificar solo el estado. Un 200 con un mensaje de error o una lista vacía también pasa. Verifique también el cuerpo.
• Una sola ubicación. Un corte de red local le despierta de madrugada.
• Avisar en cada fallo. Exija dos fallos seguidos o que dos ubicaciones coincidan.
• Cuentas de prueba compartidas que caducan. La comprobación falla por motivos ajenos al producto.
• Considerarla cobertura total. No sustituye a la observabilidad ni a la monitorización del rendimiento de aplicaciones, que explican por qué algo falló.

Monitorización sintética y pruebas de carga

Las comprobaciones sintéticas envían un hilo de tráfico para confirmar que un usuario puede hacer su tarea. Una prueba de carga envía muchos usuarios a la vez para encontrar dónde se rompe el sistema. Se complementan: la prueba de carga halla el límite antes del lanzamiento y la monitorización sintética avisa cuando producción se acerca a él. Las comprobaciones de API gratuitas de LoadFocus se ejecutan cada 5 minutos; los intervalos de pago figuran en monitorización de APIs, y las auditorías Lighthouse programadas, en monitorización de velocidad de página. Empiece con comprobaciones de API gratuitas. Para consejos prácticos, lea cómo mejorar la experiencia de usuario con monitorización sintética.

Preguntas frecuentes: monitorización sintética

¿En qué se diferencia la monitorización sintética de la monitorización de disponibilidad?

La monitorización de disponibilidad es la comprobación sintética más simple: pregunta si una URL responde. La monitorización sintética incluye además aserciones de API, recorridos de varios pasos, comprobaciones de navegador y mediciones de rendimiento.

¿Con qué frecuencia deben ejecutarse las comprobaciones sintéticas?

Cada minuto o dos en endpoints críticos para el negocio, cada cinco minutos en la mayoría de los servicios y cada hora o cada día en páginas que cambian poco. Los intervalos cortos detectan los problemas antes pero consumen más ejecuciones.

¿La monitorización sintética sustituye a la de usuarios reales?

No. La sintética le dice que algo está roto, incluso sin visitantes. El RUM le dice cómo vive el sitio la gente real en dispositivos reales. Use ambas.

¿Puedo usar monitorización sintética antes del lanzamiento?

Sí. Como no necesita visitantes, puede apuntar las comprobaciones a un entorno de pruebas y ejecutarlas tras cada despliegue.

¿Por qué ejecutar comprobaciones desde varias ubicaciones?

Para distinguir una caída real de un problema de red local y detectar incidencias regionales de DNS, CDN o enrutamiento que una sola ubicación pasaría por alto.