Monitorización sintética frente a de usuarios reales
La monitorización sintética ejecuta comprobaciones programadas con un calendario desde ubicaciones que eliges tú; la monitorización de usuarios reales registra tiempos de los navegadores de las personas que visitan tu sitio. Lo sintético te dice si el sitio funciona, la monitorización de usuarios reales te dice cómo se sintió para las personas que estuvieron ahí.
Qué hace cada una
La monitorización sintética, a veces llamada activa o proactiva, envía una petición que tú definiste desde una máquina que controlas, con un intervalo que fijas. Esa petición puede ser tan pequeña como un GET HTTP o tan grande como una sesión de navegador guionizada que inicia sesión, añade un artículo al carrito y paga. Cada ejecución produce un resultado haya o no visitado alguien el sitio.
La monitorización de usuarios reales, normalmente abreviada como RUM, es pasiva. Un pequeño script en tus páginas reporta lo que midió el navegador para esa visita: tiempos de navegación, cargas de recursos, errores, y los Core Web Vitals tal como los vivió el visitante. Produce datos solo en proporción a tu tráfico, y no produce nada cuando no hay nadie.
Qué detecta lo sintético que a RUM se le escapa
- Caídas a las 4 de la madrugada, o en cualquier página con poco tráfico. Si nadie carga la página, RUM no tiene nada que reportar, y una caída total es precisamente el caso en que no se puede enviar la señal
- Disponibilidad desde sitios donde todavía no tienes usuarios, que es como descubres que un mercado nuevo no puede llegar hasta ti
- Una línea base limpia. El mismo script, desde la misma ubicación, con el mismo intervalo, así que un cambio en el número es un cambio en el sitio y no en quién visitó por casualidad
- Flujos de varios pasos que no querrías que ejerciten usuarios reales, como un pago que crearía un pedido real, o un inicio de sesión que puedes ejecutar contra una cuenta de prueba
- Fallos de caducidad y configuración que nunca llegan a un navegador en absoluto: certificados, registros DNS, inclusiones en listas negras, puertos abiertos
- El primer fallo tras un despliegue, antes de que llegue el tráfico que lo habría revelado
Qué detecta RUM que a lo sintético se le escapa
- La distribución real de dispositivos, redes y ubicaciones. Una comprobación sintética desde una conexión de centro de datos nunca va a reproducir un móvil de gama media con datos móviles
- Scripts de terceros, banners de consentimiento y personalización que solo cargan para sesiones reales con cookies reales
- Problemas que afectan a un subconjunto de usuarios: una versión de navegador, una región, una variante de prueba A/B
- Qué páginas lentas importan, ponderadas por cuánta gente las ve
- Los Core Web Vitals de campo, que es lo que usan los buscadores, a diferencia de los valores de laboratorio que produce una ejecución sintética
Cuándo necesitas las dos
Las dos responden a preguntas distintas, así que la división suele ser clara. Usa lo sintético para todo lo que avisarías a alguien: disponibilidad, tiempo de respuesta contra un umbral, caducidad de certificado y dominio, y los flujos críticos que te dan dinero. Eso tiene que ser cierto a las 4 de la madrugada con cero tráfico, y necesita una línea base estable contra la que avisar.
Usa RUM para decidir qué arreglar. Cuando una página va lenta para algunas personas, RUM te dice para quiénes y cuántas, que es la información que necesita un argumento de priorización y que una comprobación sintética no puede darte.
Una configuración práctica es comprobaciones sintéticas que impulsan las alertas y el registro de uptime, RUM que impulsa el backlog de rendimiento. Si solo puedes ejecutar una, ejecuta la sintética: una caída sin monitorizar sale más cara que una página lenta sin medir, y RUM no puede informar de una página que no llegó a cargar.
Dónde encaja la monitorización de transacciones
Una comprobación de transacción es la monitorización sintética en su forma más detallada: un script de navegador grabado que recorre paso a paso un recorrido de usuario real y falla en el paso que se rompió, en lugar de en el sitio como un todo. Detecta la clase de fallo que una simple comprobación de disponibilidad reporta como sana, donde la página de inicio devuelve 200 mientras el formulario de inicio de sesión detrás de ella está roto.
Como es sintética, se ejecuta con un calendario sin necesitar tráfico, y como usa un navegador real ejerce el JavaScript, las dependencias de terceros y las redirecciones que se salta una simple comprobación HTTP. La monitorización de transacciones de HostTracker funciona así, y la guía de la comprobación de transacción cubre cómo se graba un script y qué reporta cada paso.
Convertir una medición en una alerta
Ninguno de los dos enfoques sirve de nada hasta que algo actúa sobre el resultado. Una comprobación sintética merece la pena tenerla porque se ejecuta estés vigilando o no, y porque un fallo puede llegarte de inmediato: HostTracker ejecuta sus comprobaciones desde más de 300 puntos de control en 158 ciudades con 13 tipos de monitor, y envía alertas por correo, SMS, llamada de voz, Slack, Telegram y más cuando un resultado cambia. Combínalo con la RUM que ya recojas y tienes las dos mitades: una alerta cuando el sitio se rompe, y pruebas de para quién fue lento. El resto de la sección de conceptos de monitorización cubre los términos sobre los que se apoyan estas dos.