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
Si uno de tus servicios empieza a responder más lentamente o de forma inesperada (por ejemplo, cuerpo de respuesta o código de estado inesperados), tu test puede alertar a tu equipo, bloquear tu pipeline de CI o incluso revertir el despliegue defectuoso.
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.
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.
- Dentro de tus pipelines de Continuous Integration Continuous Delivery para empezar a enviar 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.
Create local variables
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.
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 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 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).
SSL- La connection (conexión) de SSL no se pudo realizar. Consulta la page (página) de error dedicado para obtener más información.
TIMEOUT- 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).
Para los pasos HTTP, consulta errores comunes de step (UI) / paso (generic) de HTTP. Para los pasos de gRPC, consulta errores comunes de step (UI) / paso (generic) de gRPC.
Permisos
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.
Referencias adicionales
Más enlaces, artículos y documentación útiles:
