Los tests de API multipaso te permiten encadenar varios tests de API a la vez para monitorizar proactivamente y garantizar que los sofisticados recorridos a tus servicios clave estén disponibles en cualquier momento y desde cualquier lugar. Si deseas realizar solicitudes individuales a tus servicios, utiliza tests de API.
Puedes hacer lo siguiente:
Ejecutar peticiones HTTP en endpoints de la API que requieran autenticación (por ejemplo, a través de un token).
Monitorizar las transacciones empresariales más importantes a nivel de API
Simular el recorrido de una aplicación móvil de principio a fin
Los tests de API multipaso pueden ejecutarse desde Datadog gestionado y ubicaciones privadas, lo que permite una cobertura completa de tus sistemas, tanto externos como internos.
Configuración
Dale un nombre y etiqueta (tag) a tu test
Dale un nombre a tu test de API multipaso.
Añade env y otras etiquetas (tags) a tu test multipaso de API. Puedes utilizar estas etiquetas (tags) para filtrar a través de tus tests de Synthetic Monitoring en la page (página) Synthetic Monitoring & Continuous Testing.
Selecciona las localizaciones
Selecciona las Localizaciones para tu test de la API multipasos. Los tests de la API multipasos pueden ejecutarse tanto desde ubicaciones gestionadas como desde ubicaciones privadas según tu preferencia por ejecutar el test desde fuera o dentro de tu red.
Datadog’s out-of-the-box managed locations allow you to test public-facing websites and endpoints from regions where your customers are located.
AWS:
Americas
Asia Pacific
EMEA
Canada Central
Hong Kong
Bahrain
Northern California
Jakarta
Cape Town
Northern Virginia
Mumbai
Frankfurt
Ohio
Osaka
Ireland
Oregon
Seoul
London
São Paulo
Singapore
Milan
Sydney
Paris
Tokyo
Stockholm
GCP:
Americas
Asia Pacific
EMEA
Dallas
Tokyo
Frankfurt
Los Angeles
Oregon
Virginia
Azure:
Region
Location
Americas
Virginia
The Datadog for Government site (US1-FED) uses the following managed location:
Region
Location
Americas
US-West
Definir pasos
Para crear un paso de solicitud de API, haz clic en Create Your First Step (Crear tu primer paso).
De forma predeterminada, se pueden crear hasta 10 pasos de test. Para aumentar este límite, ponte en contacto con el servicio de asistencia de Datadog.
Define la petición
Dale un nombre a tu paso.
Elige un tipo de solicitud:
Consulta la documentación de Tests de HTTP para crear una solicitud de HTTP y añadir aserciones para un check de comportamiento o un check de estado. Las aserciones son opcionales en los tests de la API de varios pasos.
Consulta la documentación de tests de gRPC para crear una solicitud gRPC y añadir aserciones para un check de comportamiento o un check de estado. Las aserciones son opcionales en los tests de API de varios pasos.
Consulta la Documentación de tests de SSL para crear una solicitud SSL y añadir aserciones para un check de comportamiento o un check de estado. Las aserciones son opcionales en los tests de API de varios pasos.
Consulta la Documentación de tests DNS para crear una solicitud DNS y añadir aserciones para un check de comportamiento o un check de estado. Las aserciones son opcionales en los tests de API de varios pasos.
Consulta la Documentación de tests de WebSocket para crear una solicitud WebSocket y añadir aserciones para un check de comportamiento o un check de estado. Las aserciones son opcionales en los tests de API de varios pasos.
Consulta la documentación de tests de TCP para crear una solicitud TCP y añadir aserciones para un check de comportamiento o un check de estado. Las aserciones son opcionales en los tests de API de varios pasos.
Consulta la Documentación de tests UDP para crear una solicitud UDP y añadir aserciones para un check de comportamiento o un check de estado. Las aserciones son opcionales en los tests de API de varios pasos.
Consulta la Documentación de tests ICMP para crear una solicitud ICMP y añadir aserciones para un check de comportamiento o un check de estado. Las aserciones son opcionales en los tests de API de varios pasos.
Añadir configuración de ejecución
En Execution Settings (Configuración de ejecución), se encuentran disponibles las siguientes opciones:
Éxito del paso:
Haz clic en If step succeeds, continue to next step (Si el paso es exitoso, continuar con el siguiente paso) para que el test continúe con los pasos posteriores después de los pasos exitosos.
Haz clic en If step succeeds, exit test and mark it as passed (Si el paso es exitoso, salir del test y marcarlo como superado) para salir del test una vez que se complete el paso de manera exitosa. De este modo, no se ejecutan pasos innecesarios y se evita marcar el test como fallido.
Fallo del paso
Haz clic en If step fails, continue to next step (Si el paso falla, continuar con el siguiente paso) para continuar con los pasos posteriores después de que se haya producido una falla en el paso. Esto puede resultar útil para tareas de limpieza cuando quieres que continúen los pasos posteriores. Por ejemplo, un test puede crear un recurso, realizar varias acciones en este y finalizar con su eliminación.
En el caso de que uno de los pasos intermedios falle, es conveniente que esta configuración esté activada en todos los pasos intermedios para garantizar que el recurso se elimina al final del test y que no se crean falsos positivos.
El test genera una alerta si un endpoint no responde como se esperaba. Tu test puede activar reintentos X veces después de Y ms en caso de un resultado de test fallido. Personaliza el intervalo de reintentos para adaptarlo a tu criterio de alerta.
Extraer variables de la respuesta
Opcionalmente, extrae variables de la respuesta de tu solicitud de API mediante el parseo de sus encabezados de respuesta o cuerpo. El valor de la variable se actualiza cada vez que se ejecuta el paso de solicitud de API.
Para iniciar el parseo de una variable, haz clic en Extract a variable from response content (Extraer una variable del contenido de la respuesta):
Ingresa un Variable Name (Nombre de variable). El nombre de tu variable debe tener al menos tres caracteres, y solo puede contener mayúsculas, números y guiones bajos.
Decide si prefieres extraer la variable de los encabezados o del cuerpo de la respuesta.
Extrae el valor del encabezado de respuesta: utiliza el encabezado de respuesta completa de tu solicitud de API como valor de la variable o analízala con un regex.
Extrae el valor del cuerpo de respuesta: utiliza el cuerpo de respuesta completo de tu solicitud de API como valor de la variable o analízalo con un regex, un JSONPath o un XPath.
Puedes extraer hasta diez variables por paso de test. Una vez creada, esta variable se puede utilizar en los siguientes pasos de tu test de API multipaso. Para obtener más información, consulta Usar variables.
Indicar la frecuencia del test
Los tests de API multipaso se pueden ejecutar:
En un horario para asegurar que tus endpoints más importantes son siempre accesibles para tus usuarios. Selecciona la frecuencia con la que deseas que Datadog ejecute tu test de API multipaso.
A petición para ejecutar tus tests cuando sea más conveniente para tus equipos.
Define alert conditions
Set alert conditions to determine the circumstances under which you want a test to fail and trigger an alert.
Alerting rule
When you set the alert conditions to: An alert is triggered if any assertion fails for X minutes from any n of N locations, an alert is triggered only if these two conditions are true:
At least one location was in failure (at least one assertion failed) during the last X minutes;
At one moment during the last X minutes, at least n locations were in failure.
Fast retry
Your test can trigger retries X times after Y ms in case of a failed test result. Customize the retry interval to suit your alerting sensibility.
Location uptime is computed on a per-evaluation basis (whether the last test result before evaluation was up or down). The total uptime is computed based on the configured alert conditions. Notifications sent are based on the total uptime.
Configure the test monitor
A notification is sent by your test based on the alerting conditions previously defined. Use this section to define how and what to message your team.
Similar to how you configure monitors, select users and/or services that should receive notifications either by adding an @notification to the message or by searching for team members and connected integrations with the dropdown menu.
Enter the notification message for your test or use pre-filled monitor messages. This field allows standard Markdown formatting and supports the following conditional variables:
Conditional Variable
Description
{{#is_alert}}
Show when the test alerts.
{{^is_alert}}
Show unless the test alerts.
{{#is_recovery}}
Show when the test recovers from alert.
{{^is_recovery}}
Show unless the test recovers from alert.
{{#is_renotify}}
Show when the monitor renotifies.
{{^is_renotify}}
Show unless the monitor renotifies.
{{#is_priority}}
Show when the monitor matches priority (P1 to P5).
{{^is_priority}}
Show unless the monitor matches priority (P1 to P5).
Notification messages include the message defined in this section and information about the failing locations. Pre-filled monitor messages are included in the message body section:
Specify how often you want your test to re-send the notification message in case of test failure. To prevent renotification on failing tests, check the option Stop re-notifying on X occurrences.
Click Save & Start Recording to save your test configuration and monitor.
To create a local variable, click + All steps > Variables. You can select one of the following available builtins to add to your variable string:
{{ numeric(n) }}
Generates a numeric string with n digits.
{{ alphabetic(n) }}
Generates an alphabetic string with n letters.
{{ alphanumeric(n) }}
Generates an alphanumeric string with n characters.
{{ date(n unit, format) }}
Generates a date in one of Datadog’s accepted formats with a value corresponding to the UTC date the test is initiated at + or - n units.
{{ timestamp(n, unit) }}
Generates a timestamp in one of Datadog’s accepted units with a value corresponding to the UTC timestamp the test is initiated at +/- n units.
{{ uuid }}
Generates a version 4 universally unique identifier (UUID).
{{ public-id }}
Injects the Public ID of your test.
{{ result-id }}
Injects the Result ID of your test run.
To obfuscate local variable values in test results, select Hide and obfuscate variable value. Once you have defined the variable string, click Add Variable.
Para visualizar tu lista de variables, escribe {{ en el campo de tu elección.
Subtests
Los tests de API multipaso admiten subtests, lo que te permite reutilizar tests de API existentes o extraer pasos en componentes reutilizables. Puedes anidar subtests hasta dos niveles de profundidad.
Para utilizar un test de API existente como subtest, haz clic en Subtest, ve a la pestaña Desde test existente y selecciona un test de API en el menú desplegable.
Para convertir pasos de tu test de API actual en un subtest, haz clic en la pestaña Extraer de Pasos, selecciona los pasos registrados que deseas extraer y haz clic en Convertir en Subtest.
Para sustituir una variable de subtest en un test de API multipaso, defínela en el test matriz utilizando el mismo nombre. Una variable siempre utiliza el primer valor que se le asigna.
Si no necesitas ejecutar un subtest de forma independiente, puedes pausarlo. Sigue ejecutándose como parte del test de API multipaso, pero no se ejecuta por sí solo.
Fallo del test
Un test se considera FAILED si un paso no satisface una o varias afirmaciones o si la solicitud de un paso falla prematuramente. En algunos casos, el test puede fallar sin poder probar las afirmaciones contra el endpoint, estas razones incluyen:
CONNREFUSED
No se ha podido establecer una conexión, ya que la máquina de destino la ha rechazado continuamente.
CONNRESET
el servidor remoto ha finalizado bruscamente la conexión. Entre las posibles causas se incluyen que el servidor web haya encontrado un error o se haya bloqueado mientras respondía, o la pérdida de conectividad del servidor web.
DNS
Entrada DNS no encontrada para el test URL. Entre las posibles causas se incluyen un test URL mal configurado o una configuración incorrecta en tus entradas DNS.
INVALID_REQUEST
La configuración del test no es válida (por ejemplo, un error tipográfico en la URL).
La solicitud no se ha podido completar en un plazo razonable. Pueden ocurrir dos tipos de TIMEOUT:
TIMEOUT: The request couldn't be completed in a reasonable time. indica que la duración de la solicitud ha alcanzado el tiempo de espera definido en el test (por defecto se define en 60 segundos).
Para cada solicitud, en la cascada de la red sólo se muestran las etapas completadas de la solicitud. Por ejemplo, en el caso de que sólo se muestre Total response time, el tiempo de espera se produjo durante la resolución DNS.
TIMEOUT: Overall test execution couldn't be completed in a reasonable time. indica que la duración de la solicitud y de las aserciones ha alcanzado la duración máxima (30 minutos).
De forma predeterminada, sólo los usuarios con los roles Administrador y Estándar de Datadog pueden crear, editar y eliminar tests de API multipaso Synthetic. Para obtener acceso para crear, editar y eliminar tests de API multipaso Synthetic, actualiza tu usuario a uno de esos dos roles predeterminados.
Si utilizas la función de rol personalizado, añade tu usuario a cualquier rol personalizado que incluya synthetics_read y permisos synthetics_write para Synthetic Monitoring.
Restringir el acceso
La restricción de acceso está disponible para los clientes que utilizan roles personalizados en sus cuentas.
Puedes restringir el acceso a un test de API multipaso en función de los roles de tu organización. Al crear un test de API multipaso, elige qué roles (además de tu usuario) pueden leer y redactar tu test.
