Resumen

Las pruebas HTTP le permiten enviar solicitudes HTTP a los puntos finales de la API de sus aplicaciones para verificar respuestas y condiciones definidas, como el tiempo de respuesta general, el código de estado esperado, el encabezado o el contenido del cuerpo.

Las pruebas HTTP pueden ejecutarse desde ubicaciones gestionadas y ubicaciones privadas dependiendo de su preferencia por ejecutar la prueba desde fuera o dentro de su red. Las pruebas HTTP pueden ejecutarse según un horario, a demanda o directamente dentro de sus canalizaciones de CI/CD.

Configuración

Puede crear una prueba utilizando una de las siguientes opciones:

• Crear una prueba a partir de una plantilla:

  1. Pase el cursor sobre una de las plantillas predefinidas y haga clic en Ver Plantilla. Esto abre un panel lateral que muestra información de configuración predefinida, incluyendo: Detalles de la Prueba, Detalles de la Solicitud, Afirmaciones, Condiciones de Alerta y Configuraciones de Monitoreo.

  2. Haga clic en +Crear prueba para abrir la página Definir solicitud, donde puede revisar y editar las opciones de configuración predefinidas. Los campos presentados son idénticos a los disponibles al crear una prueba desde cero.

  3. Haga clic en Guardar detalles para enviar su prueba de API.
     
     

• Construya una prueba desde cero:

  1. Para construir una prueba desde cero, haga clic en la plantilla + Comenzar desde cero, luego seleccione el tipo de HTTPsolicitud y especifique la URL a consultar. Los métodos disponibles son: GET, POST, PATCH, PUT, HEAD, DELETE y OPTIONS. Se admiten tanto http como https URLs.

     Vea Opciones avanzadas para más opciones.

  2. Name your HTTP test.

  3. Add Environment Tags as well as any other tag to your HTTP test. You can then use these tags to filter through your Synthetic tests on the Synthetic Monitoring & Continuous Testing page.

  4. Click Send to try out the request configuration. A response preview is displayed on the right side of your screen.
     
     

  5. Click Create Test to submit your API test.

Fragmentos

When setting up a new Synthetic Monitoring API test, use snippets to automatically fill in basic auth, performance, and regions, rather than selecting these options manually. The following snippets are available:

• Basic Auth: Automatically test your APIs using pre-populated basic auth headers, JavaScript, bearer token, and API/app key auth variables.

• Performance: Automatically configure a test with the shortest frequency (one minute), perform a gRPC health check, and test for overall response time latency with a breakdown of network timing.

• Regions: Automatically test your API endpoint against a location in each of the three primary geographic regions (AMER, APAC and EMEA).
  
  

  

Opciones avanzadas

• Versión HTTP: Seleccione HTTP/1.1 only, HTTP/2 only o HTTP/2 fallback to HTTP/1.1.
• Seguir redirecciones: Seleccione para que su prueba HTTP siga hasta diez redirecciones al realizar la solicitud.
• Ignorar error de certificado del servidor: Seleccione para que su prueba HTTP continúe con la conexión incluso si hay errores al validar el certificado SSL.
• Tiempo de espera: Especifique la cantidad de tiempo en segundos antes de que la prueba exceda el tiempo límite.
• Encabezados de solicitud: Define encabezados para agregar a tu solicitud HTTP. También puedes anular los encabezados predeterminados (por ejemplo, el encabezado user-agent).
• Cookies: Define cookies para agregar a tu solicitud HTTP. Establece múltiples cookies utilizando el formato <COOKIE_NAME1>=<COOKIE_VALUE1>; <COOKIE_NAME2>=<COOKIE_VALUE2>.

• Certificado de cliente: Autentica a través de mTLS subiendo tu certificado de cliente (.crt) y la clave privada asociada (.key) en formato PEM. Puedes usar la biblioteca openssl para convertir tus certificados. Por ejemplo, convierte un certificado PKCS12 a claves privadas y certificados 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: Agrega credenciales de autenticación básica HTTP.

• Autenticación Digest: Agrega credenciales de autenticación Digest.

• NTLM: Agrega credenciales de autenticación NTLM. Admite tanto NTLMv2 como NTLMv1.

• Firma AWS v4: Ingresa tu ID de clave de acceso y clave de acceso secreta. Datadog genera la firma para tu solicitud. Esta opción utiliza la implementación básica de SigV4. Firmas específicas como Amazon S3 no son compatibles de forma predeterminada. Para solicitudes de transferencia “Single Chunk” a los buckets de Amazon S3, agrega x-amz-content-sha256 que contenga el cuerpo de la solicitud codificado en sha256 como un encabezado (para un cuerpo vacío: x-amz-content-sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855).

• OAuth 2.0: Elige entre otorgar credenciales de cliente o una contraseña de propietario de recurso e ingresa una URL de token de acceso. Dependiendo de tu selección, ingresa un ID de cliente y secreto, o un nombre de usuario y contraseña. Desde el menú desplegable, selecciona una opción para enviar el token de API como un encabezado de autenticación básica, o enviar las credenciales del cliente en el cuerpo. Opcionalmente, puedes proporcionar información adicional como la audiencia, el recurso y el contexto (así como el ID y secreto del cliente, si seleccionaste Recurso de Propietario de Contraseña).

• Codificar parámetros: Agrega el nombre y valor de los parámetros de consulta que requieren codificación.

• Tipo de cuerpo: Seleccione 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 desea agregar a su solicitud HTTP.
• Cuerpo de la solicitud: Agrega el contenido de tu cuerpo de 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 del proxy: Especifique la URL del proxy por el que debe pasar la solicitud HTTP (http://<YOUR_USER>:<YOUR_PWD>@<YOUR_IP>:<YOUR_PORT>).
• Encabezado del proxy: Agregue encabezados para incluir en la solicitud HTTP al proxy.

• No guardar el cuerpo de la respuesta: Seleccione esta opción para evitar que el cuerpo de la respuesta se guarde en tiempo de ejecución y para truncar el mensaje de error de las afirmaciones de JavaScript fallidas. Esto ayuda a garantizar que no se muestre información sensible en los resultados de su prueba, pero puede dificultar la solución de problemas de fallos. Para recomendaciones de seguridad completas, consulte Seguridad de Datos de Monitoreo Sintético.

Defina variables para sus pruebas de API HTTP con JavaScript:

Las capacidades de JavaScript no son compatibles con las pruebas de API en ubicaciones privadas de Windows.

Define afirmaciones

Las afirmaciones definen cuál es un resultado de prueba esperado. Después de hacer clic en Probar URL, se añaden afirmaciones básicas sobre response time, status code y header content-type basadas en la respuesta que se obtuvo. Debes definir al menos una afirmación para que tu prueba sea objeto de seguimiento.

Tipo	Operador	Tipo de valor
cuerpo	contains, does not contain, is, is not, matches, does not match, jsonpath, xpath	Cadena Regex
encabezado	contains, does not contain, is, is not, matches, does not match	Cadena Regex
tiempo de respuesta	is less than	Entero (ms)
código de estado	is, is not, matches, does not match	Entero Regex

Las pruebas HTTP pueden descomprimir cuerpos con los siguientes content-encoding encabezados: br, deflate, gzip y identity.

Puedes crear hasta 20 afirmaciones por prueba de API haciendo clic en Nueva Afirmación o haciendo clic directamente en la vista previa de la respuesta:

Para realizar OR lógica en una afirmación, usa el matches regex comparador para definir una expresión regular con múltiples valores esperados como (200|302). Por ejemplo, puedes querer que tu prueba HTTP tenga éxito cuando un servidor deba responder con un código de estado 200 o 302. La afirmación status code tiene éxito si el código de estado es 200 o 302. También puedes añadir lógica OR en una afirmación body o header con el comparador matches regex.

Si una prueba no contiene una afirmación sobre el cuerpo de la respuesta, la carga del cuerpo se descarta y se devuelve un tiempo de respuesta asociado para la solicitud dentro del límite de tiempo establecido por el Synthetics Worker.

El cuerpo de la respuesta solo se devuelve si ha agregado afirmaciones sobre su contenido y estas afirmaciones han fallado. Si una prueba contiene una afirmación sobre el cuerpo de la respuesta y tiene éxito, la carga del cuerpo se descarta y solo se muestra un fragmento de los primeros 50 caracteres del cuerpo de la respuesta.

Si una prueba contiene una afirmación sobre el cuerpo de la respuesta y se alcanza el límite de tiempo, aparece un error Assertions on the body/response cannot be run beyond this limit.

Utilice afirmaciones de JavaScript cuando las afirmaciones de respuesta estándar no satisfagan sus necesidades de validación. Synthetic Monitoring utiliza la biblioteca de afirmaciones Chai, que proporciona dd.expect(), dd.should y dd.assert() para estilos de afirmación flexibles.

Al trabajar con respuestas JSON, utilice JSON.parse(dd.response.body) para analizar el cuerpo de la respuesta antes de acceder a sus propiedades. Esto es necesario para todos los métodos de afirmación (dd.assert(), dd.expect() y dd.should) al validar datos JSON.

• Las capacidades de JavaScript no son compatibles con pruebas de API en ubicaciones privadas de Windows.
• Si el mensaje de error de una afirmación de JavaScript fallida puede incluir datos sensibles, bajo Opciones Avanzadas > Privacidad, habilite No guardar el cuerpo de la respuesta. Esto trunca el mensaje de error de la afirmación.

Usando dd.assert()

Utilice dd.assert() para la sintaxis tradicional de afirmaciones:

Por ejemplo, para afirmar que un campo status.code es uno de varios valores permitidos:

Copy

const response = JSON.parse(dd.response.body);
// Assert that the status code is 200, 210, 320, or 330
dd.assert.include([200, 210, 320, 330], response.status.code);

Respuesta de ejemplo:

{
  "status": {
    "code": 200,
    "message": "Success"
  }
}

Esta afirmación:

• Analiza el cuerpo de la respuesta JSON
• Verifica que status.code esté incluido en el arreglo de valores permitidos (200, 210, 320 o 330)

La prueba pasa porque status.code es 200, lo cual está incluido en el arreglo de valores permitidos.

Para más información sobre assert.include(), consulta la documentación de Chai assert.include().

Usando dd.expect()

Utilice dd.expect() para afirmaciones con validación de propiedades anidadas.

Por ejemplo, para afirmar que un campo status.indicator coincida con uno de los varios valores esperados:

Copy

const response = JSON.parse(dd.response.body);
const regex = /^(major|critical|minor|none)$/;

dd.expect(response)
  .to.have.nested.property('status.indicator')
  .that.matches(regex);

Respuesta de ejemplo:

{
  "status": {
    "indicator": "none"
  }
}

Esta afirmación:

• Analiza el cuerpo de la respuesta JSON
• Valida que la propiedad anidada status.indicator exista
• Verifica que el valor coincida con el patrón regex (uno de: major, critical, minor o none)

Con el regex /^(major|critical|minor|none)$/, la prueba pasa porque status.indicator es "none", lo cual coincide con el patrón.

Con el regex /^(major|critical|minor)$/, la prueba falla porque "none" no está incluido en los valores permitidos.

Para más información sobre expect(), consulta la documentación de Chai expect().

Usando dd.should

Usa dd.should para escribir afirmaciones con sintaxis de lenguaje natural:

Por ejemplo, para afirmar que un campo status.indicator existe y es igual a un valor específico:

Copy

const response = JSON.parse(dd.response.body);
response.status.should.exist();
const indicator = response.status.indicator;
indicator.should.equal('none');

Respuesta de ejemplo:

{
  "status": {
    "indicator": "none"
  }
}

Esta afirmación:

• Analiza el cuerpo de la respuesta JSON
• Verifica que la propiedad status exista
• Extrae el valor del indicador en una variable
• Verifica que status.indicator sea igual a "none"

La prueba pasa porque status existe y status.indicator es "none".

Para más información sobre should(), consulta la documentación de Chai should().

Seleccione ubicaciones

Seleccione las Ubicaciones desde las cuales ejecutar su prueba HTTP. Las pruebas HTTP pueden ejecutarse desde ubicaciones gestionadas y privadas dependiendo de su preferencia por ejecutar la prueba desde fuera o dentro de su 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:

GCP:

Azure:

The Datadog for Government site (US1-FED) uses the following managed location:

Especifique la frecuencia de la prueba

Las pruebas HTTP pueden ejecutarse:

• Según un horario para asegurar que sus puntos de conexión más importantes siempre sean accesibles para sus usuarios. Seleccione la frecuencia con la que desea que Datadog ejecute su prueba HTTP.
• Dentro de sus pipelines de CI/CD para comenzar a enviar sin temer que un código defectuoso pueda afectar la experiencia de sus clientes.
• A demanda para ejecutar sus pruebas cuando tenga más sentido para su 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.

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.

1. 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.

2. 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:

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:

3. 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.

4. Click Save & Start Recording to save your test configuration and monitor.

For more information, see Synthetic Monitoring notifications.

Downtimes

To pause test execution during planned maintenance windows, select an existing Scheduled downtime in the Downtimes section. The test automatically pauses during the downtime’s scheduled time slots.

Note: You cannot create a new downtime from the test creation form. To create one, navigate to Settings > Downtimes.

Un clic

La creación de pruebas de API sugiere puntos de conexión del Catálogo y pruebas de API existentes para completar su formulario de prueba con opciones relevantes. Utilice fuentes de datos existentes de Datadog, como trazas de APM, descubrimiento de puntos de conexión del Catálogo y pruebas Synthetic similares existentes creadas por usuarios.

Comience a escribir en la entrada de URL de la prueba de API para obtener sugerencias de puntos de conexión o pruebas similares en Synthetic Monitoring:

Luego, seleccione una sugerencia para completar la configuración de su prueba (opciones de solicitud y encabezados, autenticación y variables):

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.

Utilice variables

Puede usar las variables globales definidas en la página Settings en la URL, opciones avanzadas y afirmaciones de sus pruebas HTTP.

Para mostrar su lista de variables, escriba {{ en el campo deseado:

Fallo de prueba

Una prueba se considera FAILED si no satisface una o más afirmaciones o si la solicitud falló prematuramente. En algunos casos, la prueba puede fallar sin probar las afirmaciones contra el punto de conexión.

Para una lista completa de códigos de error HTTP y SSL, consulta Errores de pruebas de API.

Permisos

Por defecto, solo los usuarios con los Datadog Admin y Datadog Standard roles pueden crear, editar y eliminar pruebas HTTP Synthetic. Para obtener acceso para crear, editar y eliminar pruebas HTTP Synthetic, actualice su rol de usuario a uno de esos dos default roles.

Si está usando la función de rol personalizado, agregue su usuario a cualquiera de los roles personalizados que incluyan los permisos synthetics_read y synthetics_write.

Restringir acceso

Use granular access control to limit who has access to your test based on roles, teams, or individual users:

1. Open the permissions section of the form.
2. Click Edit Access.

3. Click Restrict Access.
4. Select teams, roles, or users.
5. Click Add.
6. Select the level of access you want to associate with each of them.
7. Click Done.

Lectura adicional

Más enlaces, artículos y documentación útiles:

Presentamos el Monitoreo Sintético de DatadogBLOG Introducción a las Pruebas SintéticasCENTRO DE APRENDIZAJE Comience con pruebas HTTPDOCUMENTACIÓN Ejecutar pruebas HTTP en puntos finales internosDOCUMENTACIÓN Ejecutar pruebas HTTP de múltiples pasosDOCUMENTACIÓN Aprenda sobre los monitores de prueba SyntheticDOCUMENTACIÓN