Monitorización sintética
La monitorización sintética de HostTracker pone a prueba tu sitio según un calendario, desde más de 300 ubicaciones, con la verificación que mejor se ajuste al trabajo: un recorrido de navegador guionado, una llamada a la API evaluada por reglas, o una simple solicitud HTTP. Elige una abajo y recibe una alerta en el momento en que deje de cumplir lo que esperas.
La misma lógica detrás de las tres: ejecutar, evaluar, reverificar, alertar
La monitorización sintética significa que el tráfico se genera a propósito. En lugar de esperar a que un visitante real se tope con un problema, un servicio de monitoreo pone a prueba tu propio sitio web, según un calendario fijo, desde fuera de tu red, y compara lo que recibe con las reglas que definas. Las herramientas de monitorización sintética de HostTracker cubren tres formas de verificación - monitoreo de navegador para un recorrido guionado, una llamada a la API evaluada por reglas, y una simple solicitud HTTP -, cubriendo desde un proceso de compra completo hasta una única comprobación de código de estado, todo desde más de 300 ubicaciones en todo el mundo.
No es monitorización de usuarios reales. HostTracker genera cada verificación por sí mismo; no recopila datos de tiempo ni de errores de los navegadores de tus visitantes reales. Si necesitas saber qué experimentaron tus visitantes reales, esa es una disciplina distinta con un nombre distinto - consulta monitorización sintética frente a monitorización de usuarios reales para la comparación completa. La ventaja de la monitorización sintética va en el sentido contrario: funciona antes de que tengas un solo visitante, y sigue funcionando a las tres de la madrugada cuando nadie está mirando.
Los tres tipos de verificación responden preguntas distintas, y elegir la incorrecta es la forma más habitual en que un problema real pasa desapercibido. Esta tabla relaciona cinco necesidades comunes con la verificación que realmente las cubre.
La mayoría de las cuentas terminan ejecutando más de una fila de esta tabla a la vez - una verificación HTTP como base de todo, más una verificación de transacción o de API en el uno o dos flujos que más importan.
Un escenario de transacción es una secuencia de acciones con nombre; un conjunto de reglas de API es un grupo de aserciones sobre una sola respuesta. Ambos se configuran, nunca se programan.
Transacción: un escenario de cinco pasos
0 navigate https://shop.example.com/ 1.4 s 1 type #email "[email protected]" 0.2 s 2 click #add-to-cart 0.9 s 3 waitForNavigation /checkout 1.1 s 4 checkContent "Order summary" present 0.1 s
API: un conjunto de cuatro reglas
status isOk header("Content-Type") contains "json" body.json.path("$.count") gt 0 time lt 5s
Cada una responde una pregunta distinta. La mayoría de las cuentas que usan HostTracker terminan ejecutando más de una.
Abre un navegador Chromium real y recorre hasta diez pasos - iniciar sesión, buscar, añadir al carrito, pagar - y luego verifica lo que hay en la página. Detecta lo que un código de estado no puede: un botón eliminado, un envío de formulario roto, un error de JavaScript a mitad de camino. Monitoreo de transacciones
Envía una llamada HTTP y evalúa la respuesta con hasta 20 reglas de aserción sobre su estado, encabezados, tiempo y cuerpo en JSON, XML o texto plano. Pensado para el endpoint del que depende otro sistema. Monitoreo de API
Solicita una URL desde más de 300 checkpoints en 158 ciudades y verifica el estado, las palabras clave del cuerpo, el tiempo de respuesta y el TLS. La base permanente sobre la que se apoyan las otras dos. Monitoreo HTTP
La forma de la verificación cambia; los checkpoints, la lógica de confirmación y los canales de alerta detrás no.
Todos los tipos de verificación se ejecutan desde la misma flota pública de checkpoints. Elige las ubicaciones que coincidan con dónde están realmente tus visitantes, o los consumidores de tu API.
Un único checkpoint que falla nunca abre un incidente por sí solo. La verificación se vuelve a ejecutar desde otros checkpoints independientes, y solo un resultado coincidente la convierte en una alerta.
Una verificación de transacción guarda una captura de pantalla del último paso, y otra en el momento en que falla un paso, así que la depuración empieza con el aspecto real que tenía la página.
Verifica texto renderizado, un valor JSON seleccionado por JSONPath o XPath, o una simple palabra clave - hasta 20 reglas de aserción o 10 coincidencias de palabras clave por monitor, según el tipo de verificación.
Correo electrónico, SMS, llamada de voz, Slack, Telegram y webhooks, configurados una sola vez por contacto, se comparten entre las verificaciones de transacción, API y HTTP de tu cuenta.
Añade cualquier monitor - recorrido de navegador, llamada a la API o verificación HTTP - a la misma página de estado pública, para que tus clientes vean una sola página en lugar de tres separadas.
Sitios web, servidores, APIs, certificados. Un tipo de comprobación por página, con las mismas ubicaciones, alertas e informes detrás.
Con la confianza de equipos en
Cada capítulo se abre en su lugar, para que la página siga siendo corta.
Los dos enfoques responden preguntas distintas. La monitorización sintética de sitios web genera su propio tráfico, desde sus propios checkpoints, según un calendario que tú controlas - un recorrido de navegador guionado, una llamada a la API, o una simple solicitud HTTP. La monitorización de usuarios reales, en cambio, observa los navegadores de tus visitantes reales, lo que significa que necesita tráfico real para decir algo, y no puede decirte qué pasará mañana, solo lo que ya pasó hoy.
HostTracker es un servicio de monitorización sintética - no ofrece monitorización de usuarios reales, y esta página no va a fingir lo contrario. Lo que ofrece la monitorización sintética a cambio: un sitio de pruebas sin visitantes sigue verificándose; una avería a las tres de la madrugada se detecta igual que una en hora punta; y como el escenario es determinista, el resultado nombra el paso o la regla exacta que falló en lugar de un síntoma vago. Para la comparación completa lado a lado, consulta monitorización sintética frente a monitorización de usuarios reales; la página de monitoreo de transacciones también incluye una tabla detallada si quieres la mecánica.
Cada tipo de verificación tiene su propio mínimo de intervalo, porque cada una cuesta una cantidad de trabajo distinta de ejecutar. Una solicitud HTTP es barata y puede ejecutarse hasta cada minuto en un plan de pago. Una llamada a la API añade análisis y evaluación de reglas, pero sigue yendo de un minuto hasta 24 horas. Una verificación de transacción abre un navegador real y recorre un escenario de principio a fin, por eso tiene un mínimo de 10 minutos - las verificaciones de navegador son costosas de ejecutar y de recibir, y combinar una con una verificación HTTP rápida en el mismo sitio cubre a la vez las preguntas de "¿está accesible ahora mismo?" y "¿el flujo sigue funcionando?" sin ejecutar un navegador cada sesenta segundos.
Las tres te permiten elegir desde cuál de los más de 300 checkpoints en 158 ciudades se ejecuta un monitor concreto - la geografía importa más de lo que parece, ya que una CDN o un balanceador de carga con enrutamiento geográfico puede estar sano en una región y fallando en otra.
La tentación con cualquier tipo de verificación nuevo es conectarlo directamente a una alerta que despierte a alguien. Resiste esa tentación la primera semana: deja que un monitor nuevo se ejecute en silencio, revisa un puñado de resultados reales, y solo entonces decide a quién se avisa de inmediato frente a quién recibe un resumen diario. Una verificación de transacción que falla porque cambió el selector de un banner de marketing no tiene la misma gravedad que una que falla porque el proceso de compra dejó de completarse - escribe tus aserciones de contenido sobre texto estable y significativo, para que la alerta que sí recibas merezca la pena atenderla.
Las alertas salen por los canales que configures por contacto - correo electrónico, SMS, llamada de voz, Slack, Telegram, webhook y más -, el mismo conjunto para los tres tipos de verificación, así que un fallo de transacción y un fallo HTTP llegan a la misma persona de la misma forma. Un cambio de estado solo se confirma cuando otros checkpoints coinciden, así que la alerta que recibes ya es una alerta razonada y no una única observación inestable; sigue un aviso de recuperación en cuanto la verificación vuelve a pasar, cerrando el ciclo sin que tengas que ir a comprobarlo tú mismo.
La monitorización sintética es aquella en la que el tráfico se genera a propósito, según un calendario, desde un servicio externo a tus propios sistemas, en lugar de esperar a que un visitante real se tope con un problema y confiar en que te avise. La monitorización sintética de HostTracker viene en tres formas: un recorrido de navegador guionado que sigue un flujo de varios pasos, una llamada a la API evaluada contra reglas que tú escribes, y una simple solicitud HTTP verificada por su estado, cuerpo y tiempo de respuesta. Las tres se ejecutan desde más de 300 ubicaciones, usan los mismos canales de alerta, y retienen una alerta hasta que otros checkpoints confirman el fallo.
No. HostTracker genera el propio tráfico, desde sus propios checkpoints, según el calendario que definas - no recopila datos de tiempo ni de errores de los navegadores de tus visitantes reales. Si necesitas saber qué experimentaron tus visitantes reales, eso es monitorización de usuarios reales, una disciplina distinta con un nombre distinto; consulta monitorización sintética frente a monitorización de usuarios reales para la comparación completa. La ventaja de la monitorización sintética es la contraria: funciona antes de que tengas un solo visitante, y sigue verificando a las tres de la madrugada cuando nadie está navegando.
El monitoreo de disponibilidad, en el sentido estricto y cotidiano, suele referirse a una sola de estas tres formas: la verificación HTTP simple que solicita una URL y observa el código de estado y el tiempo de respuesta. La monitorización sintética es el término más amplio que también cubre el monitoreo de navegador - el recorrido guionado - y la monitorización sintética de API, la llamada evaluada por reglas. Una verificación HTTP responde “¿está ahí el servidor?”; una verificación de transacción responde “¿realmente se completa el flujo de varios pasos?”; la monitorización sintética de API responde “¿la respuesta cumple realmente su contrato?”. Un sitio puede pasar todas las verificaciones HTTP mientras su proceso de compra está roto, que es exactamente el vacío que cierran las otras dos.
No. Los tres tipos de verificación se crean en el editor web. Un escenario de transacción es una lista de acciones - navegar, hacer clic, escribir y demás - elegidas de un menú, con un selector CSS escrito en un campo. Las reglas de aserción de un monitor de API son cada una una línea de sintaxis clara y legible, no un script. Las palabras clave y opciones de un monitor HTTP son campos de un formulario. Nada de esto es un lenguaje de programación, aunque toda la superficie de acciones y reglas también es accesible a través de la API si quieres automatizar la propia configuración.
Hasta diez pasos definidos por ti, dentro de un presupuesto de 40 segundos para toda la ejecución. Una navegación inicial a la propia URL del monitor se añade automáticamente como paso cero, así que los diez pasos que escribes son diez pasos de trabajo real - clics, texto escrito, aserciones de contenido - no nueve más una carga de página. Un flujo que de verdad necesita más de diez pasos suele ser mejor dividirlo en dos monitores; eso además te dice qué mitad se rompió.
Empieza con una verificación HTTP sobre el propio sitio - es la señal más económica y la base permanente que toda cuenta debería tener. Luego añade la de las otras dos que corresponda a tu riesgo de mayor valor: una verificación de transacción si un proceso de compra o inicio de sesión roto te cuesta dinero directamente, una verificación de API si otro sistema - tu propia app, la integración de un socio - depende de que un endpoint responda correctamente. La mayoría de las cuentas que usan las tres ejecutan la verificación HTTP con más frecuencia, la de API a continuación, y la de transacción en el intervalo más largo, ya que es la que más trabajo cuesta ejecutar.
Depende del tipo de verificación, porque cada una cuesta una cantidad de trabajo distinta de ejecutar. Las verificaciones HTTP pueden ejecutarse hasta cada minuto en un plan de pago. Las verificaciones de API van de un minuto hasta 24 horas. Las verificaciones de transacción - porque cada ejecución abre un navegador real y recorre un escenario de principio a fin - tienen un mínimo de 10 minutos. Un patrón habitual combina una verificación HTTP de un minuto para detectar caídas rápido con una verificación de transacción o de API cada 10 a 15 minutos para la pregunta más profunda.
El fallo no se da por bueno en la primera observación. HostTracker vuelve a ejecutar la verificación desde otros checkpoints independientes, y solo confirma el cambio de estado cuando suficientes de ellos coinciden, así que una ruta de red inestable o un nodo lento por sí solos no se convierten en una alerta. Una vez confirmado, HostTracker avisa a los contactos que configuraste por los canales que elegiste - correo electrónico, SMS, llamada de voz, Slack, Telegram, webhook y más - después del retraso que cada contacto tenga asignado, y sigue un aviso de recuperación en cuanto la verificación vuelve a pasar.
Inicia una prueba gratuita y añade una verificación de transacción, de API o HTTP a la misma cuenta - las mismas más de 300 ubicaciones y las mismas alertas detrás de las tres.
Forma parte del software de monitorización web de HostTracker.
