Supervisión sintética: medición automatizada de los tiempos de carga en varias regiones

Lo que muestra el «Synthetic Monitoring»

Synthetic Monitoring realiza de forma automática y periódica una serie de comprobaciones predefinidas en un sitio web. Un Consulte En este contexto, describe, entre otras cosas, el objetivo, el calendario, los puntos de medición y los criterios de éxito. Cada ejecución en un punto de medición genera un resultado propio: por lo tanto, la configuración no debe equipararse a una única medición.

Por el contrario, una prueba de rendimiento global única solo ofrece una instantánea de las condiciones de esa carrera. Repetida Supervisión del sitio web permite detectar si una desviación vuelve a producirse y cómo evolucionan los resultados a lo largo del tiempo. Para que estas comparaciones sean significativas, deben poder identificarse el objetivo, el entorno de medición y la ubicación.

Un punto de medición público en un centro de datos en la nube comprueba el sitio web desde una región e infraestructura concretas. Sin embargo, su conexión no se corresponde automáticamente con una conexión a Internet privada in situ. El enrutamiento, la latencia de la red y la distancia a la infraestructura de entrega pueden influir en el resultado; por lo tanto, una ejecución lenta describe, en primer lugar, esta ruta de medición concreta.

A clase particular responde a otra pregunta: permite comprobar si se puede acceder a una aplicación desde una red privada. Esto es relevante, por ejemplo, para los servicios internos, pero no demuestra que se pueda acceder a ellos desde la Internet pública. Por el contrario, una comprobación pública satisfactoria no indica si el acceso funciona desde cualquier red empresarial.

Por lo tanto, a la hora de planificar, conviene formular cada comprobación como una pregunta concreta: ¿se puede acceder a la página del producto desde una región objetivo importante y aparece allí el contenido esperado? La respuesta es válida para los puntos de medición y las condiciones de prueba seleccionados. Se trata de una indicación reproducible, pero no de una imagen completa de todos los visitantes y sus dispositivos.

HTTP, navegadores y recorridos

A Comprobación HTTP consulta un punto final y evalúa, por ejemplo, el código de estado o la respuesta. En el caso de una página de producto, puede indicar rápidamente que el servidor no responde como se esperaba. Sin embargo, si devuelve un código HTTP 200, solo se cumple el criterio de respuesta comprobado: queda por ver si la interfaz es visible y se puede utilizar.

Una comprobación del navegador carga la misma página de producto en un navegador automatizado. Permite comprobar si aparece un título esperado y registrar los valores de medición relacionados con el navegador. Si esta comprobación falla, aunque el estado HTTP sea correcto, conviene analizar la representación y el contenido de la página. Sin embargo, esta diferencia por sí sola no prueba aún una causa concreta del error.

A Comprobación del viaje va más allá de la simple carga y ejecuta una serie de pasos definidos. Por ejemplo, al iniciar sesión, abre la página de inicio de sesión, inicia sesión con una cuenta de prueba adecuada y, a continuación, comprueba un elemento esperado. Solo este último criterio demuestra, para el proceso sometido a prueba, que no solo se pudo acceder a la página de inicio de sesión.

Incluso un recorrido satisfactorio solo confirma los pasos y las condiciones que realmente se han llevado a cabo. Un restablecimiento de contraseña no probado o un navegador diferente pueden seguir planteando problemas. Por eso, elige unos pocos procesos importantes para la empresa y formula un resultado verificable para cada paso, en lugar de deducir el buen funcionamiento de todo el servicio a partir de una carga satisfactoria de la página.

Una revisión visual complementaria permite detectar cambios en la presentación que no se detectan con una comprobación de elementos individual. Para ello, se pueden comparar, por ejemplo, capturas de pantalla; posteriormente, hay que clasificar las discrepancias, ya que no todos los cambios visibles son errores. En el artículo sobre Verificación visual y comprobaciones automatizadas del sitio.

Distinguir correctamente los tiempos de carga

„Sin más especificaciones, el término “tiempo de carga» no se refiere a una magnitud claramente comparable. Al abrir una página, lo primero que interesa es el tiempo que transcurre hasta la primera respuesta del servidor: esto ayuda a evaluar los retrasos antes de que llegue la respuesta. Sin embargo, esto no indica cuándo el navegador ha mostrado algo visible o cuándo ha procesado la página por completo.

La primera representación visible describe una fase posterior: el navegador muestra contenido por primera vez. Puede tratarse ya de un pequeño texto u otro elemento inicial, mientras que el contenido principal de la página aún no aparece. Por lo tanto, que la página se vea pronto no significa automáticamente que sea una página de producto que se pueda utilizar rápidamente.

El El mayor contenido de pintura (LCP) tiene en cuenta el momento en que el elemento de contenido más relevante aparece en el área visible. En la página de un producto, por ejemplo, puede ser la imagen grande del producto. Compara el LCP únicamente con valores de LCP designados como tales y toma nota de las condiciones del navegador y de la red; el tiempo de respuesta del servidor se mide en otra fase.

El Duración del guion A su vez, esto no equivale automáticamente al tiempo de carga de una sola página. Un script puede abrir varias páginas, esperar a que se carguen determinados elementos y realizar un inicio de sesión. En el caso de las comprobaciones de navegador de Grafana-k6, la duración del script que se muestra no suele incluir la fase de inicio de k6; estos límites de la herramienta también deben tenerse en cuenta a la hora de interpretar los resultados.

El «Interaction to Next Paint» (INP, por sus siglas en inglés) se refiere a la respuesta ante las interacciones. En este contexto, un proceso sintético solo puede analizar las interacciones que realmente lleva a cabo. Por lo tanto, un clic automatizado en condiciones predeterminadas no ofrece una distribución de las experiencias de todos los visitantes reales que utilizan otros dispositivos, conexiones y formas de navegación.

Plan de medición para las regiones objetivo

Empieza el plan de medición con las páginas y los procesos cuyo fallo podría afectar a tu negocio. Pueden ser, por ejemplo, una página de producto, el registro o una interfaz. A continuación, selecciona las regiones de medición en función de tus mercados objetivo: una ubicación adicional resulta especialmente útil si cubre una región importante de usuarios o complementa una observación regional ya existente.

Para un comprobación similar Anota el navegador y la versión, la configuración de visualización del dispositivo, las condiciones de red y el estado de la caché. Documenta además el intervalo y el tiempo de espera, así como la respuesta esperada o el elemento visible. De este modo, más adelante se podrá determinar si una desviación podría coincidir con un cambio en el entorno de medición.

La siguiente tabla es un ejemplo conceptual, no un plan operativo medido ni recomendado de forma general. Debes adaptar los intervalos y las condiciones de alarma a la importancia de tu sitio web y a las posibilidades del servicio elegido.

La tabla es solo el punto de partida: completa en la configuración de comprobación el límite de tiempo concreto y el resto de condiciones de medición. Una alarma regional sigue teniendo sentido por sí misma, incluso si otras ubicaciones informan de que todo va bien. Ten en cuenta que un punto de medición en la nube no representa automáticamente una conexión a Internet privada en la misma región.

Configurar comprobaciones y procedimientos de prueba

Para crear tu propia página de prueba, puedes empezar por configurar una comprobación HTTP que verifique el código de estado esperado. Añade una comprobación de navegador que acceda a esa misma página y espere a que aparezca el encabezado esperado. La primera comprobación analiza la respuesta del punto final; la segunda proporciona, además, una indicación de si el contenido esperado aparece en el navegador.

Anota para cada ejecución el lugar de la medición, la hora, el resultado y la duración correspondiente. Si la comprobación del navegador falla a pesar de que la comprobación HTTP se haya realizado con éxito, analiza el contenido y la visualización, en lugar de dar por sentado inmediatamente que se trata de un error concreto. Comprueba también si el título ha cambiado de forma intencionada o si el tiempo de espera se ha fijado en un valor demasiado corto.

Para registrarse, hay que hacer clic en un Viaje la llamada al navegador para introducir datos y realizar una comprobación tras iniciar sesión. Utiliza una cuenta de prueba independiente con el menor número posible de permisos y comprueba un elemento estable y no personal en el área de acceso. El mero hecho de que se abra correctamente la página de inicio de sesión no confirma por sí solo que el inicio de sesión funcione.

Elija selectores estables y espera específicamente los contenidos previstos, en lugar de basarte únicamente en una pausa fija. Guarda los datos de acceso en la gestión de claves secretas del servicio utilizado y no en el script ni en los registros. Tras realizar cambios en la interfaz, comprueba si los selectores y los criterios de éxito siguen ajustándose al flujo previsto.

Limita los procesos de prueba a acciones seguras: un recorrido que se ejecute periódicamente no debe generar pedidos ni pagos reales. Si un paso de escritura es inevitable, debe realizarse en un entorno de prueba expresamente destinado a ello o mediante un proceso de prueba controlado. Además, determina quién investigará una ejecución fallida y quién se encargará de los datos de prueba.

Comparar herramientas y modelos operativos

A la hora de elegir una herramienta, debes distinguir entre un servicio de monitorización gestionado y una herramienta que, en un primer momento, solo realiza una prueba. Lo decisivo no es únicamente que sea compatible con un navegador: también necesitas ubicaciones adecuadas, una ejecución periódica, el almacenamiento de los resultados y un sistema de alertas que se adapte a tu negocio.

Grafana Cloud Supervisión sintética Conecta configuraciones de comprobación con puntos de prueba públicos y privados, y es compatible con comprobaciones de navegadores basadas en k6. Los puntos de prueba públicos y privados responden a diferentes cuestiones relacionadas con la accesibilidad. Comprueba también de antemano las frecuencias de comprobación disponibles: las comprobaciones de navegadores y de scripts están sujetas a otros límites que algunas comprobaciones sencillas de terminales.

El realizado a nivel local Módulo de navegador k6 Hay que distinguirlo de esto. Para ello, necesitas k6 y un navegador basado en Chromium; la ejecución de un script local no configura automáticamente puntos de medición regionales ni un calendario permanente. Para una monitorización distribuida, tendrías que organizar además la ejecución, la infraestructura y la gestión de resultados, o bien utilizar un servicio adecuado.

AWS CloudWatch Synthetics ejecuta los «canaries» programados. Los Función multisitio Replica un Canary en las regiones de AWS seleccionadas y agrupa los resultados en una región principal. Antes de la implementación, comprueba las versiones mínimas documentadas para los entornos de ejecución de Node.js, Puppeteer o Playwright compatibles, así como la disponibilidad regional específica de esta función.

Las estaciones de medición gestionadas por ti mismo te ofrecen un mayor control sobre la ubicación y el entorno, pero también requieren mantenimiento, actualizaciones y supervisión de la infraestructura de medición. Compara, en todos los modelos de funcionamiento, las ubicaciones que se ofrecen realmente, los costes en función del uso y las condiciones de almacenamiento de datos. Aclara, en particular, dónde se guardan las capturas de pantalla y los registros, y si esto se ajusta a tus requisitos de protección de datos.

Evaluar adecuadamente los resultados regionales

Compara los resultados regionales para la misma página y el mismo periodo. El navegador, la versión, las condiciones de red y el estado de la caché deben coincidir; de lo contrario, cualquier diferencia podría deberse al entorno de medición y no a la entrega. Además, un punto de medición en la nube representa una ubicación y una ruta de red concretas, no todas las conexiones de una región.

Para mediciones repetidas con resultados satisfactorios, el Mediana el valor medio de los resultados ordenados. Un percentil superior, por ejemplo, el percentil 95, pone de manifiesto las carreras más lentas: el 95 % de los valores analizados no superan este valor. Anota el periodo y el número de mediciones para que quede claro cuál es el alcance del análisis.

Cuando el número de ejecuciones es reducido, una sola ejecución lenta puede influir considerablemente en el percentil superior. Por ello, comprueba la evolución temporal y compara varias ventanas de medición antes de dar por hecho que se trata de un empeoramiento regional persistente. Un cambio en el punto de medición o en la versión del navegador también debe tenerse en cuenta como posible factor que influya en el análisis.

Espera intentos fallidos se muestran por separado, por ejemplo, como número de errores y porcentaje del total de ejecuciones. De lo contrario, unas estadísticas de tiempo de carga que solo incluyan las peticiones completadas con éxito podrían dar una imagen erróneamente positiva de una región en la que se producen frecuentes tiempos de espera agotados. En caso de fallo sin un valor válido de tiempo de carga, no es posible utilizar simplemente un tiempo de carga normal.

La monitorización de usuarios reales complementa las pruebas controladas con las experiencias de los visitantes reales. El Informe de experiencia de usuario de Chrome proporciona datos de campo disponibles en una ventana móvil de 28 días; no todas las páginas ni todos los grupos de usuarios están incluidos en él. Por lo tanto, esta perspectiva a más largo plazo no sustituye a una alerta sintética actual ni puede equipararse directamente a una única prueba.

Alarmas y resolución de problemas a nivel regional

A alarma global Puede agrupar los errores recurrentes de varias ubicaciones. Esto ayuda a distinguir entre un incidente de mayor alcance y una avería aislada en un punto de medición. Al mismo tiempo, establece una condición de alarma regional: si falla un mercado objetivo importante, el éxito de otras regiones no debe ocultar el problema.

Elige el número de repeticiones y el intervalo de tiempo en función de la importancia del proceso. Varias pruebas fallidas consecutivas pueden compensar valores atípicos a corto plazo, pero retrasan la notificación. Supervisa también los propios puntos de medición y comprueba si se ha producido un fallo en una muestra o si otras pruebas de la misma ubicación también se han visto afectadas.

Si una página de producto solo funciona con lentitud en una ubicación, empieza por comparar ejecuciones similares y el momento en que se produjo la desviación. A continuación, analiza la resolución de DNS, la distribución a través de la CDN, los tiempos de carga de los recursos y la respuesta del servidor. Las diferentes rutas de red y la proximidad a la infraestructura pueden influir en los niveles iniciales regionales; el valor medido por sí solo no identifica aún la causa.

En el caso de recursos de otros Origins, es posible que los detalles de la medición del navegador estén limitados. Sin el correspondiente Timing-Allow-Origin-En los encabezados, algunos valores de la API Resource Timing pueden ser nulos. Esto no significa automáticamente que la conexión fuera extremadamente rápida; comprueba primero qué datos facilita el servidor externo para la medición.

Para pasar al siguiente nivel de análisis, debes relacionar la hora, la región y el proceso afectado con los registros y rastros disponibles. De este modo, por ejemplo, se puede buscar una consulta lenta sin dar por sentada que una correlación sea ya una prueba de la causa. En el artículo sobre Observabilidad en el alojamiento web.

Llevar a cabo un seguimiento de forma permanente

Empieza con comprobaciones sencillas de puntos finales para objetivos importantes accesibles públicamente y compleméntalas con recorridos específicos en el navegador para páginas o inicios de sesión críticos para el negocio. Una comprobación HTTP puede ejecutarse con mayor frecuencia, mientras que la prueba de navegador, más compleja, comprueba funciones seleccionadas. Los intervalos deben ajustarse en función del tiempo de detección deseado, los límites del servicio y los costes, y no según un valor fijo por minuto.

Determina para cada comprobación una Competencia: ¿Quién recibe la alarma, quién comprueba el servicio afectado y quién se encarga del punto de medición? Anota también cuándo se transmite una alarma y dónde se pueden encontrar los resultados correspondientes. Una comprobación sin reacción ante errores repetidos proporciona datos, pero no resuelve el incidente.

Tras realizar cambios en la interfaz, comprueba si los selectores y los contenidos esperados siguen ajustándose al flujo del script. En el script, espera a que aparezca el elemento necesario, en lugar de basarte únicamente en un retraso fijo. Documenta los cambios en el navegador, el perfil de red o la configuración de la caché, para que las comparaciones posteriores no mezclen sin darse cuenta condiciones de medición diferentes.

Trata las capturas de pantalla y los registros como datos potencialmente sensibles: pueden contener el contenido de una sesión o información de la aplicación. Limita el acceso y el almacenamiento en función de la finalidad y comprueba qué es lo que realmente registra la prueba. Para los inicios de sesión, utiliza una cuenta de prueba con acceso restringido y gestiona los datos de acceso como «secrets» en lugar de incluirlos en el script.

Comprueba periódicamente si Lugares de medición si se ajustan a tus mercados objetivo y si las tarifas, la gestión de datos y los requisitos de protección de datos siguen permitiendo su funcionamiento. En el caso de los entornos de prueba gestionados por ti mismo, hay que añadir la actualización y la supervisión del entorno. Un script del navegador k6 ejecutado localmente no constituye por sí solo una infraestructura de supervisión distribuida de forma permanente.