¿Qué es Synthetic Monitoring? Definición, Tipos, Comparación RUM

Synthetic monitoring corre tests scripted desde ubicaciones globales 24/7 — detecta issues de uptime y latencia antes que usuarios reales.

¿Qué es synthetic monitoring?

Synthetic monitoring es una técnica proactiva de testing de performance y disponibilidad donde scripts pre-definidos simulan interacciones de usuario con un website, API o aplicación desde ubicaciones cloud o agent controladas. A diferencia de Real User Monitoring (RUM), que mide usuarios reales en la naturaleza, synthetic monitoring corre en una cadencia programada (cada minuto, hora o día) independientemente de si hay tráfico real golpeando el sistema. El objetivo es detectar regresiones de availability y performance antes que los usuarios.

Un monitor synthetic típico envía un HTTP request, navega un browser por un flow multi-step (login, browse, checkout) o valida una respuesta API, luego registra timing, status code y resultados de assertions. Cuando algo falla — endpoint down, response demasiado lento, contenido faltante — el monitor dispara una alerta vía Slack, PagerDuty, email o webhook.

Cómo funciona synthetic monitoring

  1. Define un check. Una URL para hittar, un endpoint API para validar, o un browser flow para recorrer. El check usualmente incluye assertions: status code 200, response body contiene cierto texto, response time bajo N ms.
  2. Programa el check. Corrre cada minuto (high-criticality), cada 5 minutos (típico), o cada hora (menor prioridad).
  3. Corre desde múltiples ubicaciones. Synthetic monitors cloud-based ejecutan checks desde agents en múltiples regiones geográficas — típicamente al menos una en Norteamérica, Europa y Asia.
  4. Registra resultados. Cada run produce métricas (latencia, status, body size), screenshots (para browser checks) y waterfall traces.
  5. Alerta sobre fallas. Umbrales configurables disparan notificaciones.

Tipos de synthetic monitoring

  • Uptime monitoring. Lo más simple — repetidamente hittar una URL, confirmar status 200.
  • API monitoring. Envía un request a un endpoint HTTP/REST/GraphQL con headers auth opcionales y request body, asserta sobre status, contenido del body y timing.
  • Browser-based monitoring. Corre un Chromium browser real para cargar una página, mide Core Web Vitals (LCP, CLS, TBT) y captura filmstrip + datos waterfall.
  • Transaction (multi-step) monitoring. Un browser flow scripted recorre un user journey crítico — login, search, add to cart, checkout.
  • Monitoring de certificado SSL/TLS. Chequea expiración de certificado, validez de chain y grade SSL Labs.
  • DNS monitoring. Resuelve un hostname desde múltiples resolvers.

Synthetic monitoring vs Real User Monitoring (RUM)

Los dos approaches miden cosas diferentes y se complementan:

AspectoSynthetic MonitoringReal User Monitoring (RUM)
Fuente de datosTests scripted desde agents controladosUsuarios reales via beacon JavaScript
CoberturaLo que scriptes — predecibleLo que los usuarios realmente hacen — variable
Cuándo correProgramado (24/7)Cuando un usuario real visita
Detecta issues antes que usuariosNo (después del hecho)
Captura varianza real-worldNo (entorno controlado)Sí (devices, redes, geografías)
Funciona sin tráficoNo (necesita usuarios)
Testing pre-launchNo (sin usuarios aún)
Diagnóstico per-userNo

La mayoría de estrategias de monitoring maduras combinan ambos: synthetic para "¿el sistema funciona como diseñado?", RUM para "¿qué experimentan los usuarios realmente?".

Métricas comunes rastreadas

  • Availability / Uptime %. Porcentaje de checks exitosos. SLAs típicamente expresados como targets de availability (99,9%, 99,95%, 99,99%).
  • Response time. Latencia end-to-end, a menudo desglosada por fase.
  • Core Web Vitals. Para browser checks: LCP, CLS, TBT. Factores de ranking de Google.
  • Error rate. Porcentaje de checks devolviendo status codes inesperados.
  • Time-to-first-byte (TTFB). Señal de responsiveness server-side.
  • Apdex score. Métrica estándar de la industria.

Cuándo usar synthetic monitoring

  • Necesitas visibilidad 24/7.
  • Estás testeando pre-launch o servicios low-traffic. RUM necesita tráfico. Synthetic funciona desde el día uno.
  • Necesitas reporting de SLA.
  • Quieres detectar regresiones temprano. Corre synthetic checks contra staging después de cada deploy.
  • Necesitas visibilidad geográfica.
  • Necesitas mediciones consistentes.

Limitaciones

  • No captura varianza real-world. Synthetic checks corren desde data centers en redes rápidas; usuarios reales hitten desde WiFi de café, 4G congestionada y browsers viejos.
  • Limitado a lo que scriptes.
  • Costo escala con frecuencia de check × ubicaciones.
  • Puede ser ruidoso sin buenos thresholds.
  • Browser checks consumen más recursos.

Synthetic monitoring con LoadFocus

LoadFocus ofrece synthetic monitoring a través de los tres tipos principales de check:

  • Page speed monitoring. Checks browser Chromium real con audits Lighthouse completos, tracking Core Web Vitals y alertas de regresión budget-based. Corre desde 25+ regiones cloud en schedules desde cada minuto.
  • API monitoring. Checks de endpoints HTTP/REST con validación assertion-based. Multi-step request chaining via scripts k6.
  • Load testing. Más allá del synthetic monitoring, LoadFocus corre tráfico simulado en concurrency elegida para testear capacidad.

La plataforma integra con Slack, PagerDuty, email y webhooks, y provee CLI + GitHub Action para CI/CD. Análisis waterfall generado por AI explica por qué un check es lento.

FAQ: Synthetic monitoring

¿En qué se diferencia synthetic monitoring de APM?

APM es típicamente agent-based y observa el interior de tu aplicación — ejecución de código, queries de base de datos, timing de funciones. Synthetic monitoring observa desde afuera — lo que un usuario ve. APM y synthetic se complementan.

¿Con qué frecuencia deberían correr synthetic checks?

Servicios críticos user-facing: cada 1 minuto. APIs internas y paths de menor prioridad: cada 5-15 minutos. Background jobs: cada 30 minutos a 1 hora.

¿Desde cuántas ubicaciones debería monitorear?

Mínimo 3 (una por región — Américas, EMEA, APAC). Para servicios globales, 5-10 ubicaciones cubren la mayoría de issues regionales.

¿Synthetic monitoring debería reemplazar RUM?

No — se complementan. Usa synthetic para monitoring proactivo 24/7 SLA; usa RUM para entender experiencia real de usuario.

¿Cuál es la diferencia entre synthetic monitoring y load testing?

Synthetic monitoring corre checks single-user en intervalos. Load testing simula muchos usuarios concurrentes.

¿Puede synthetic monitoring detectar issues de seguridad?

Limitado. Para security monitoring, herramientas dedicadas (Sucuri, Cloudflare Security, SIEM enfocado a seguridad) son mejor fit.

Prueba LoadFocus synthetic monitoring gratis

Si estás evaluando herramientas de synthetic monitoring, LoadFocus ofrece page speed monitoring, API monitoring y load testing en una plataforma con plan gratis sin tarjeta de crédito. Regístrate en loadfocus.com/signup para configurar tu primer synthetic check en menos de 5 minutos — multi-región, con assertions, alertas y análisis generado por AI incluidos en todos los planes.

¿Qué tan rápido es tu sitio web?

Mejora su velocidad y SEO sin problemas con nuestra Prueba de Velocidad gratuita.

Prueba de velocidad de sitio web gratis

Analice la velocidad de carga de su sitio web y mejore su rendimiento con nuestro comprobador de velocidad de página gratuito.

×