Cuando un equipo SRE despliega monitorización sintética junto a RUM (Real User Monitoring), la tentación habitual es tratarlos como sistemas independientes: los sintéticos verifican disponibilidad desde puntos controlados, el RUM captura experiencia real del usuario. Ambos generan alertas, ambos alimentan dashboards, y en teoría todo funciona. El problema aparece cuando un sintético reporta degradación pero el RUM muestra métricas normales, o viceversa: un usuario real experimenta latencias inaceptables mientras los sintéticos desde tu infraestructura reportan tiempos perfectos. Sin correlación efectiva entre ambas señales, el equipo termina investigando dos realidades paralelas que nunca convergen en un diagnóstico coherente.
La correlación entre sintéticos y RUM no es un problema de dashboards compartidos ni de alinear métricas en la misma pantalla. Es un problema de arquitectura de observabilidad: cómo estructurar la telemetría para que ambas fuentes de datos se enriquezcan mutuamente, cómo identificar cuándo una señal sintética predice degradación real antes de que impacte usuarios, y cómo evitar que las diferencias entre tráfico sintético y real generen ruido operativo en lugar de claridad diagnóstica. En entornos complejos con múltiples regiones, CDNs, balanceadores y capas de caché, esta correlación se convierte en la diferencia entre detectar problemas antes del impacto y reaccionar cuando ya hay usuarios afectados.
Este artículo aborda la correlación sintéticos-RUM desde una perspectiva arquitectónica: qué señales correlacionar, cómo estructurar la telemetría para que la correlación sea operativamente útil, y cuándo esta estrategia aporta valor real frente a cuándo añade complejidad sin beneficio claro. El enfoque se centra en Dynatrace por su capacidad de correlación entre sintéticos, RUM y topología de infraestructura, pero los principios aplican a cualquier stack de observabilidad que combine estas señales.
El problema fundamental: sintéticos y RUM miden realidades diferentes
La primera fuente de confusión operativa es asumir que sintéticos y RUM deberían reportar métricas similares. Un sintético ejecuta transacciones predefinidas desde ubicaciones controladas, con condiciones de red estables y sin variabilidad de comportamiento de usuario. El RUM captura sesiones reales con toda su complejidad: usuarios en redes móviles inestables, navegadores con extensiones que alteran rendimiento, cachés locales impredecibles, y patrones de navegación que nunca seguirían un script sintético.
Esta diferencia no es un defecto, es la naturaleza de cada señal. Los sintéticos proporcionan una línea base consistente: si un sintético desde Frankfurt reporta latencia creciente en tu API de checkout, sabes que el problema está en tu infraestructura, no en la red del usuario. El RUM te dice si esa degradación realmente impacta a usuarios reales, cuántos están afectados, y si el problema es generalizado o específico de ciertos segmentos. La correlación efectiva no busca que ambas señales coincidan, busca que se complementen para construir un diagnóstico completo.
El error común es configurar alertas independientes para cada señal y esperar que el equipo de guardia las correlacione manualmente durante un incidente. Esto falla en producción porque bajo presión, con múltiples alertas simultáneas, el contexto se pierde. Un SRE ve una alerta de sintéticos reportando timeout en un endpoint crítico, y simultáneamente una alerta de RUM mostrando aumento de errores JavaScript en la misma aplicación. Sin correlación automática, no queda claro si son manifestaciones del mismo problema, problemas independientes, o si uno es consecuencia del otro.
Arquitectura de correlación: topología como contexto compartido
La correlación efectiva entre sintéticos y RUM requiere un modelo de topología compartido que conecte ambas señales con la infraestructura subyacente. En Dynatrace, este modelo se construye automáticamente a través de Smartscape: cada transacción sintética y cada sesión RUM se mapean a los servicios, procesos, hosts y dependencias que participan en la ejecución. Cuando un sintético detecta degradación en un flujo de checkout, la plataforma ya conoce qué servicios backend participan en ese flujo, qué bases de datos consultan, qué APIs externas invocan.
Esta topología es la base sobre la que Davis AI agrupa señales relacionadas. Cuando un sintético falla, el RUM muestra errores y un servicio backend aparece degradado al mismo tiempo, Davis los incluye en el mismo Problem porque comparten infraestructura según el modelo Smartscape — no porque «entienda» la relación semánticamente, sino porque detecta que afectan a los mismos componentes. Esto es lo que Dynatrace llama correlación automática: agrupación contextual basada en topología, no análisis causal independiente.
Esta topología permite correlación bidireccional. Si un sintético reporta latencia creciente, puedes identificar inmediatamente qué porcentaje de usuarios reales están experimentando el mismo comportamiento en esos servicios específicos. Si el RUM muestra errores concentrados en un segmento de usuarios, puedes verificar si los sintéticos desde esas regiones geográficas también detectan problemas, o si el issue es específico de condiciones de usuario real que los sintéticos no replican.
El antipatrón habitual es construir correlación basada únicamente en timestamps y nombres de aplicación. Esto genera falsos positivos: dos señales coinciden en tiempo pero no tienen relación causal. La correlación topológica elimina este ruido porque establece relaciones de dependencia reales. Si un sintético y múltiples sesiones RUM comparten el mismo servicio backend degradado, la correlación es significativa. Si coinciden en tiempo pero no comparten infraestructura, probablemente son problemas independientes que requieren investigación separada.
Granularidad de correlación: transacción vs sesión
La granularidad determina qué tan útil es la correlación en diagnóstico real. Correlacionar a nivel de aplicación completa es demasiado grueso: un sintético reporta problema en la aplicación, el RUM también, pero eso no te dice dónde investigar. Correlacionar a nivel de transacción específica es más útil: el sintético detecta timeout en el paso de validación de tarjeta, y el RUM muestra que usuarios reales también experimentan fallos en ese paso exacto.
Dynatrace permite esta granularidad porque tanto sintéticos como RUM generan trazas distribuidas que se pueden comparar directamente. Un sintético ejecuta un flujo de checkout y genera una traza que atraviesa frontend, API gateway, servicio de pagos, y procesador de tarjetas. Las sesiones RUM reales generan trazas similares. La correlación identifica qué segmentos de esas trazas divergen: si el sintético muestra latencia normal hasta el procesador de tarjetas pero el RUM muestra latencia alta desde el API gateway, el problema probablemente está en la capa de autenticación que los sintéticos omiten por usar credenciales preconfiguradas.
Esta granularidad también expone limitaciones de los sintéticos. Si el RUM reporta errores en un flujo que el sintético ejecuta exitosamente, puede indicar que el sintético no cubre casos edge que usuarios reales encuentran: validaciones de entrada específicas, combinaciones de parámetros no contempladas, o comportamientos dependientes de estado de sesión complejo. La correlación no solo diagnostica problemas, también identifica gaps en la cobertura sintética.
Señales operativas: cuándo la correlación aporta valor diagnóstico
La correlación sintéticos-RUM es más valiosa en escenarios donde ambas señales capturan perspectivas complementarias del mismo sistema.
El primer caso es degradación gradual: los sintéticos detectan aumento de latencia en un servicio antes de que impacte suficientes usuarios reales para generar alerta RUM. Esto proporciona ventana de reacción proactiva. Si la correlación muestra que la degradación sintética aún no se refleja en RUM, tienes tiempo para investigar y mitigar antes del impacto visible.
El segundo caso es problemas geográficos o de red. Un sintético desde una región específica reporta conectividad degradada, pero los sintéticos desde otras regiones funcionan normalmente. La correlación con RUM te dice inmediatamente si usuarios reales en esa región están afectados, cuántos, y si el problema es específico de tu infraestructura en esa región o de la conectividad general.
El tercer caso es validación de mitigación. Después de aplicar un fix, los sintéticos deberían recuperarse primero porque ejecutan flujos controlados. La correlación con RUM confirma que la recuperación se propaga a usuarios reales, y con qué latencia. Si los sintéticos recuperan pero el RUM sigue mostrando problemas, indica que el fix no aborda la causa raíz o que hay un problema de propagación de caché o configuración.
El cuarto caso, menos obvio pero crítico, es detección de falsos positivos. Si un sintético reporta problema pero el RUM no muestra degradación en usuarios reales ejecutando el mismo flujo, puede indicar que el sintético está configurado incorrectamente, ejecuta desde una ubicación no representativa, o que hay un problema específico de la infraestructura sintética. Sin correlación, estos falsos positivos generan investigaciones innecesarias y erosionan confianza en la monitorización sintética.
Antipatrones y errores comunes en implementación
El antipatrón más frecuente es configurar sintéticos que no replican comportamiento real de usuario. Un sintético que ejecuta login, navega directamente a checkout, completa compra y cierra sesión en treinta segundos no representa cómo usuarios reales interactúan con la aplicación. Cuando este sintético reporta métricas diferentes al RUM, la correlación es inútil porque están midiendo flujos fundamentalmente distintos.
El segundo error es correlacionar únicamente métricas agregadas. Comparar percentil 95 de latencia sintética con percentil 95 de latencia RUM a nivel de aplicación no proporciona información accionable. La correlación útil opera a nivel de transacción específica, segmento de usuario, o componente de infraestructura.
El tercer antipatrón es ignorar diferencias legítimas entre sintéticos y RUM. Si tu aplicación usa CDN con caché agresivo, los usuarios reales experimentarán latencias mucho menores que los sintéticos si estos no están configurados para aprovechar caché. Esto no es un problema de correlación, es una diferencia arquitectónica esperada.
El cuarto error es no integrar eventos de cambio. Un sintético reporta degradación después de un despliegue, pero el RUM no muestra impacto porque el despliegue fue gradual y solo afecta a un pequeño porcentaje de usuarios. Sin contexto de cambio, el equipo puede concluir que el sintético es un falso positivo, cuando en realidad está detectando un problema real que se propagará. Dynatrace puede correlacionar sintéticos, RUM y eventos de despliegue en el mismo Problem — pero esto requiere que los eventos de cambio lleguen a la plataforma, ya sea via API, integración CI/CD (Jenkins, GitHub Actions) o anotaciones de OneAgent. Sin esa integración, Davis no tiene contexto de que hubo un cambio.
Cuándo esta estrategia no aporta valor
La correlación sintéticos-RUM añade complejidad operativa y no siempre justifica el esfuerzo. En aplicaciones internas con usuarios controlados y patrones de uso predecibles, los sintéticos pueden ser suficientes. Si todos los usuarios acceden desde la red corporativa y ejecutan flujos similares, el RUM aporta poco contexto adicional que los sintéticos no capturen.
En sistemas con tráfico extremadamente variable o estacional, la correlación puede generar ruido. Si tu aplicación recibe picos de tráfico impredecibles que saturan infraestructura de forma legítima, los sintéticos reportarán degradación que el RUM confirmará, pero la correlación no añade información diagnóstica útil: ya sabes que el problema es capacidad insuficiente.
En arquitecturas con múltiples capas de caché y CDN, la correlación puede ser engañosa si los sintéticos no están configurados para replicar comportamiento de caché real. Y en entornos donde los sintéticos ejecutan desde ubicaciones no representativas de tu base de usuarios, la correlación pierde valor: la prioridad es corregir la cobertura geográfica antes de invertir en correlación sofisticada.
Recomendaciones operativas para equipos SRE
Primera: sintéticos representativos. Establece sintéticos que repliquen flujos críticos de usuario con fidelidad razonable, incluyendo tiempos de espera y manejo de errores. No significa replicar cada variación posible, sino capturar los patrones representativos que generan la mayoría del tráfico real.
Segunda: alertas con contexto cruzado. Configura alertas que incluyan el estado de ambas señales antes de escalar a humanos. Si un sintético reporta degradación pero el RUM no muestra impacto en usuarios reales, la alerta debe incluir ese contexto. En Dynatrace, Davis agrupa automáticamente sintéticos, RUM e infraestructura en Problems unificados cuando comparten los mismos componentes afectados — reduciendo el trabajo de correlación manual durante incidentes.
Tercera: revisión periódica de gaps, como práctica del equipo. Dynatrace no te avisa de que tienes gaps de cobertura sintética — eso lo hace el equipo. Periodicamente conviene entrar a la UI, revisar qué flujos reporta el RUM con errores frecuentes, y verificar si hay un sintético cubriendo ese flujo. Si el RUM reporta errores frecuentes en un flujo que los sintéticos no detectan, es señal de que los sintéticos no cubren ese caso. Si los sintéticos reportan problemas que nunca se reflejan en RUM, puede indicar configuración incorrecta o ubicaciones no representativas.
Cuarta: SLOs híbridos. Usa la correlación para validar SLOs. Si tu SLO se basa únicamente en sintéticos, estás midiendo disponibilidad desde tu perspectiva, no desde la del usuario. Si se basa únicamente en RUM, estás midiendo experiencia real pero sin capacidad de detección proactiva. La correlación permite SLOs híbridos: disponibilidad sintética como indicador leading, experiencia RUM como indicador de impacto real.
La correlación entre sintéticos y RUM no es un problema de herramientas, es un problema de arquitectura de observabilidad. Requiere telemetría estructurada, modelo de topología compartido, y criterio operativo para distinguir cuándo las diferencias entre ambas señales son diagnósticas y cuándo son ruido. Herramientas como Dynatrace reducen el trabajo de correlación manual agrupando señales relacionadas en un mismo contexto — pero la calidad de esa correlación depende directamente de cómo estén configurados los sintéticos, si el RUM cubre los flujos críticos, y si los eventos de cambio llegan a la plataforma. En entornos complejos, esta correlación es la diferencia entre detectar problemas antes del impacto y reaccionar cuando ya hay usuarios afectados. En entornos simples, puede ser complejidad innecesaria. El criterio para decidir es evaluar si tu equipo actualmente diagnostica problemas correlacionando manualmente estas señales: si la respuesta es sí, automatizar esa correlación es inversión que se paga en la primera guardia.
