Los test de API multipaso te permiten encadenar varias solicitudes HTTP o solicitudes gRPC a la vez para monitorizar de forma proactiva y asegurar que los recorridos más complejos de 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
Si uno de tus servicios comienza a responder más lentamente o de una manera inesperada (por ejemplo, un cuerpo de respuesta o código de estado inesperado), tu test puede alertar a tu equipo, bloquear tu pipeline de IC o incluso hacer retroceder el despliegue defectuoso.
Los tests de API multipaso pueden ejecutarse desde Datadog localizaciones gestionadas y localizaciones privadas, permitiendo 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 de API multipaso. Puedes utilizar estas etiquetas para filtrar tus tests Synthetic en la página Monitorización y tests continuos Synthetic.
Selecciona las localizaciones
Selecciona las localizaciones para tu test de API multipaso. Los tests de API multipaso pueden ejecutarse tanto desde localizaciones gestionadas como desde localizaciones privadas en función de si prefieres ejecutar el test desde fuera o desde 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.
| Americas | APAC | EMEA |
|---|
| Canada Central (AWS) | Hong Kong (AWS) | Cape Town (AWS) |
| Northern California (AWS) | Mumbai (AWS) | Frankfurt (AWS) |
| Northern Virginia (AWS) | Seoul (AWS) | Ireland (AWS) |
| Ohio (AWS) | Singapore (AWS) | London (AWS) |
| Oregon (AWS) | Sydney (AWS) | Paris (AWS) |
| São Paulo (AWS) | Tokyo (AWS) | Stockholm (AWS) |
| Virginia (Azure) | Osaka (AWS) | Milan (AWS) |
| Jakarta (AWS) | Bahrain (AWS) |
The Datadog for Government site (US1-FED) uses the following managed location:
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: HTTP o gRPC.
Consulta la documentación de Tests HTTP para crear una solicitud HTTP y añadir aserciones. Las aserciones son opcionales en los tests de API multipaso.
Consulta la documentación de Tests 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 multipaso.
Añade parámetros de ejecución
Haz clic en Continuar con el test si este paso falla para permitir que tu test continúe con los pasos siguientes tras el fallo de un paso. Esto asegura que tus tests son capaces de limpiarse a sí mismos. Por ejemplo, un test puede crear un recurso, realizar una serie de acciones en ese recurso y terminar con la eliminación de ese recurso.
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.
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):
Introduce un Variable Name (Nombre de variable). El nombre de tu variable debe tener al menos tres caracteres y sólo puede contener mayúsculas, números y guiones bajos.
Decide si prefieres extraer la variable de los encabezados o del cuerpo de la respuesta.
- Extraer el valor del encabezado de respuesta: utiliza el encabezado de respuesta completa de tu solicitud de API como valor de la variable, o analízalo con una
regex. - Extraer 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 una
regex, una JSONPath o una 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.
Indica 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.
- En tus pipelines de CI/CD para empezar a realizar envíos sin temer que un código defectuoso pueda afectar a la experiencia de tus clientes.
- 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.
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. 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). |
Specify how often you want your test to re-send the notification message in case of test failure. To prevent renotification on failing tests, leave the option as Never renotify if the monitor has not been resolved.
Click Create to save your test configuration and monitor.
For more information, see Using Synthetic Test Monitors.
Variables
Create local variables
To create a local variable, click Create a Local Variable. 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.
Además de crear variables locales, puedes extraer variables de cualquier paso de tu test de API multipaso y reinyectar los valores en pasos posteriores.
Usar variables
Puedes utilizar las variables globales definidas en la Settings y las variables definidas localmente en la URL, las opciones avanzadas y las aserciones de tus tests de API.
Para visualizar tu lista de variables, escribe {{ en el campo que desees.
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 porque 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).
SSL- no se ha podido realizar la conexión SSL. Consulta la página de errores dedicada para obtener más información.
TIMEOUT- La solicitud no se ha podido completar en un plazo razonable. Pueden ocurrir dos tipos de
TIMEOUT (tiempo de espera):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 establece en 60 segundos).
Para cada solicitud, solo se muestran en la cascada de la red las etapas completadas de la solicitud. Por ejemplo, en el caso de que solo se muestre Total response time, el límite de tiempo 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).
Para pasos de HTTP, consulta fallos comunes en pasos de HTTP. Para pasos de gRPC, consulta fallos comunes de pasos de gRPC.
Permisos
Por defecto, solo los usuarios con los roles Datadog Admin y Datadog Standard pueden crear, editar y borrar los tests de API multipaso Synthetic. Para obtener acceso a la creación, edición y eliminación de tests de API multipaso Synthetic, actualiza tu usuario a uno de esos dos roles predeterminados.
Si estás utilizando la función de rol personalizado, añade tu usuario a cualquier rol personalizado que incluya permisos para synthetics_read y synthetics_write para la monitorización Synthetic.
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.
Referencias adicionales
Más enlaces, artículos y documentación útiles:
