Los tests HTTP te permiten enviar solicitudes HTTP a los endpoints de API de tus aplicaciones para verificar las respuestas y las condiciones definidas, como el tiempo de respuesta global, el código de estado esperado, la cabecera o el contenido del cuerpo.
Los tests HTTP pueden ejecutarse tanto desde localizaciones gestionadas como de localizaciones privadas dependiendo de tu preferencia de ejecución de tests desde fuera o dentro de tu red. Los tests HTTP pueden ejecutarse de forma programada, bajo demanda o directamente dentro de tus pipelines CI/CD.
Configuración
Cuando decidas crear un test HTTP
, define la solicitud de tu test.
Definición de la solicitud
Elige el Método HTTP y especifica la URL a consultar. Los métodos disponibles son: GET
, POST
, PATCH
, PUT
, HEAD
, DELETE
y OPTIONS
. Tanto las URL http
como https
son compatibles.
Pon un nombre a tu test HTTP.
Añade Etiquetas (tags) env
así como cualquier otra etiqueta a tu test HTTP. Luego, puedes utilizar estas etiquetas para filtrar tus tests Synthetic en la página de monitorización y tests continuos Synthetic.
Haz clic en Test de URL para probar la configuración de la solicitud. Aparecerá una vista previa de la respuesta en la parte derecha de la pantalla.
Opciones avanzadas
- Versión HTTP: Selecciona
HTTP/1.1 only
, HTTP/2 only
o HTTP/2 fallback to HTTP/1.1
. - Seguir redirecciones: Selecciona esta opción para que tu test HTTP pueda acceder a un máximo de diez redirecciones al realizar la solicitud.
- Ignorar error de certificado del servidor: Selecciona esta opción para que tu test HTTP continúe con la conexión, aunque se produzcan errores al validar el certificado SSL.
- Tiempo de espera: Especifica la cantidad de tiempo en segundos antes de que se inicie un tiempo de espera en el test.
- Cabeceras de solicitud: Define las cabeceras a añadir a tu solicitud HTTP. También puedes anular las cabeceras predeterminadas (por ejemplo, la cabecera
user-agent
). - Cookies: Define cookies para añadir a tu solicitud HTTP. Define varias cookies utilizando el formato
<COOKIE_NAME1>=<COOKIE_VALUE1>; <COOKIE_NAME2>=<COOKIE_VALUE2>
Certificado de cliente: Autentícate a través de mTLS cargando tu certificado de cliente (.crt
) y la clave privada asociada (.key
) en formato PEM
. Puedes utilizar la biblioteca openssl
para convertir tus certificados. Por ejemplo, puedes convertir un certificado PKCS12
en certificados y claves privadas en formato PEM
.
openssl pkcs12 -in <CERT>.p12 -out <CERT_KEY>.key -nodes -nocerts
openssl pkcs12 -in <CERT>.p12 -out <CERT>.cert -nokeys
Autenticación básica HTTP: Añade credenciales de autenticación básica HTTP.
Autenticación Digest: Añade credenciales de autenticación Digest.
NTLM: Añade credenciales de autenticación NTLM. Esto es compatible con NTLMv2 y con NTLMv1.
AWS Signature v4: Introduce tu ID de clave de acceso y tu clave de acceso secreta. Datadog genera la firma para tu solicitud. Esta opción utiliza la implementación básica de SigV4. Las firmas específicas, como Amazon S3, no son compatibles de forma predefinida.
Para las solicitudes de transferencia “Single Chunk” a buckets de Amazon S3, añade x-amz-content-sha256
con el cuerpo de la solicitud codificado con sha256 como cabecera (para un cuerpo vacío: x-amz-content-sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
).
OAuth 2.0: Elige entre conceder credenciales de cliente o una contraseña de propietario de recurso e introduce una URL de token de acceso. Dependiendo de tu selección, introduce un ID de cliente y un secreto o un nombre de usuario y una contraseña. En el menú desplegable, selecciona una opción para enviar el token de API como cabecera de autenticación básica o envía las credenciales de cliente en el cuerpo. También puedes proporcionar información adicional como el público, el recurso y el contexto (así como el ID de cliente y el secreto, si has seleccionado Contraseña del propietario del recurso).
- Codificar parámetros: Añade el nombre y el valor de los parámetros de consulta que requieren codificación.
- Tipo de cuerpo: Selecciona el tipo de cuerpo de la solicitud (
application/json
, application/octet-stream
, application/x-www-form-urlencoded
, multipart/form-data
, text/html
, text/plain
, text/xml
, GraphQL
o None
) que quieres añadir a tu solicitud HTTP. - Cuerpo de la solicitud: Añade el contenido del cuerpo de tu solicitud HTTP.
- El cuerpo de la solicitud está limitado a un tamaño máximo de 50 kilobytes para
application/json
, application/x-www-form-urlencoded
, text/html
, text/plain
, text/xml
, GraphQL
. - El cuerpo de la solicitud está limitado a un archivo de 3 megabytes para
application/octet-stream
. - El cuerpo de la solicitud está limitado a tres archivos de 3 megabytes cada uno para
multipart/form-data
.
- URL de proxy: Especifica la URL del proxy por el que debe pasar la solicitud HTTP (
http://<YOUR_USER>:<YOUR_PWD>@<YOUR_IP>:<YOUR_PORT>
). - Cabecera de proxy: Añade cabeceras para incluir en la solicitud HTTP al proxy.
- No guardar el cuerpo de la respuesta: Selecciona esta opción para evitar que se guarde el cuerpo de la respuesta en tiempo de ejecución. Esta opción es útil para garantizar que no se muestren datos confidenciales en los resultados del test, pero debes utilizarla con prudencia ya que puede dificultar la resolución de problemas. Para obtener recomendaciones de seguridad, consulta Seguridad en la monitorización Synthetic.
Define variables para tus tests API HTTP con JavaScript:
<div class="shortcode-wrapper shortcode-img expand"><figure class="text-center"><a href="https://datadog-docs.imgix.net/images/synthetics/api_tests/http_javascript.66fe410698cb2c156ee0634db040393e.png?fit=max&auto=format" class="pop" data-bs-toggle="modal" data-bs-target="#popupImageModal"><picture class="" style="width:90%;" >
<img
class="img-fluid"
srcset="https://datadog-docs.imgix.net/images/synthetics/api_tests/http_javascript.66fe410698cb2c156ee0634db040393e.png?auto=format"
style="width:90%;" alt="Definir tests API HTTP con JavaScript" />
</picture></a></figure>
</div>
Definir aserciones
Las aserciones definen cuál es el resultado esperado de un test. Después de hacer clic en URL del test, se añaden aserciones básicas de response time
, status code
y header
content-type
basadas en la respuesta obtenida. Debes definir al menos una aserción para que sea monitorizada por tu test.
Tipo | Operador | Tipo de valor |
---|
cuerpo | contains , does not contain , is , is not ,
matches , does not match ,
jsonpath , xpath | String Regex |
cabecera | contains , does not contain , is , is not ,
matches , does not match | String Regex |
tiempo de respuesta | is less than | Integer (ms) |
código de estado | is , is not ,
matches , does not match | Integer Regex |
Los tests HTTP pueden descomprimir cuerpos con las siguientes cabeceras content-encoding
: br
, deflate
, gzip
y identity
.
Puedes crear hasta 20 aserciones por test API haciendo clic en Nueva aserción o haciendo clic directamente en la vista previa de la respuesta:
Para aplicar una lógica OR
en una aserción, utiliza el comparador matches regex
para definir una expresión regular con varios valores esperados, como (200|302)
. Por ejemplo, te podría interesar que tu test HTTP tenga éxito cuando el servidor responde con un código de estado 200
o 302
. La aserción status code
tiene éxito si el código de estado es 200 o 302. También puedes añadir la lógica OR
en una aserción de body
o header
.
Si un test no contiene una aserción en el cuerpo de la respuesta, la carga útil del cuerpo cae y devuelve un tiempo de respuesta asociado para la solicitud, dentro del límite de tiempo de espera establecido por el worker de Synthetics.
Si un test contiene una aserción en el cuerpo de la respuesta y se alcanza el límite de tiempo de espera, aparece un error Assertions on the body/response cannot be run beyond this limit
.
Seleccionar localizaciones
Selecciona las Localizaciones desde donde ejecutar tu test HTTP. Los tests HTTP pueden ejecutarse desde localizaciones gestionadas y también 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:
Indicar la frecuencia del test
Los tests HTTP se pueden ejecutar:
- De forma programada para garantizar que los endpoints más importantes siempre resulten accesibles para tus usuarios. Selecciona la frecuencia con la que quieres que Datadog ejecute tu test HTTP.
- En tus pipelines CI/CD para empezar a realizar envíos sin temer que un código defectuoso pueda afectar a la experiencia de tus clientes.
- Bajo demanda para ejecutar tus tests cuando sea más conveniente para tu equipo.
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.
Uso de variables
Puedes utilizar las variables globales definidas en la página Parámetros en la URL, las opciones avanzadas y las aserciones de tus tests HTTP.
Para visualizar tu lista de variables, escribe {{
en el campo de tu elección.
Fallo del test
Un test se considera FAILED
si no satisface una o más aserciones o si la solicitud ha fallado prematuramente. En algunos casos, el test puede fallar sin comprobar las aserciones respecto al endpoint.
Los errores más comunes incluyen los siguientes:
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 falla al responder, o que se haya perdido la conectividad del servidor web.
DNS
:
No se ha encontrado la entrada DNS para la URL del test. Entre las posibles causas se incluyen una URL de test mal configurada o una configuración incorrecta de las entradas DNS.
Error performing HTTP/2 request
- No se ha podido realizar la solicitud. Para obtener más información, consulta la página de errores específicos.
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. Para obtener más información, consulta la página de errores específica.
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 del test (solicitud + aserciones) alcanza la duración máxima (60,5 segundos).
MALFORMED_RESPONSE
- El servidor remoto ha respondido con una carga útil que no cumple con las especificaciones HTTP.
Permisos
De manera predeterminada, sólo los usuarios con los roles de administrador de Datadog y estándar de Datadog pueden crear, editar y eliminar tests HTTP Synthetic. Para crear, editar y eliminar tests HTTP 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 que incluya permisos synthetics_read
y synthetics_write
.
Restringir el acceso
La restricción del acceso está disponible para clientes que utilizan roles personalizados en sus cuentas.
Puedes restringir el acceso a un test HTTP en función de los roles de tu organización. Al crear un test HTTP, elige qué roles (además de tu usuario) pueden leer y escribir tu test.
Referencias adicionales
Additional helpful documentation, links, and articles: