¿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
- 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.
- Programa el check. Corrre cada minuto (high-criticality), cada 5 minutos (típico), o cada hora (menor prioridad).
- 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.
- Registra resultados. Cada run produce métricas (latencia, status, body size), screenshots (para browser checks) y waterfall traces.
- 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:
| Aspecto | Synthetic Monitoring | Real User Monitoring (RUM) |
|---|---|---|
| Fuente de datos | Tests scripted desde agents controlados | Usuarios reales via beacon JavaScript |
| Cobertura | Lo que scriptes — predecible | Lo que los usuarios realmente hacen — variable |
| Cuándo corre | Programado (24/7) | Cuando un usuario real visita |
| Detecta issues antes que usuarios | Sí | No (después del hecho) |
| Captura varianza real-world | No (entorno controlado) | Sí (devices, redes, geografías) |
| Funciona sin tráfico | Sí | No (necesita usuarios) |
| Testing pre-launch | Sí | No (sin usuarios aún) |
| Diagnóstico per-user | No | Sí |
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.
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus — la misma plataforma que potencia todo lo que acabas de leer.