Información general

Los tests WebSocket te permiten abrir de forma proactiva conexiones WebSocket en tus endpoints para verificar las respuestas y las condiciones definidas, como los tiempos de respuesta generales o las cabeceras esperadas.

Los tests WebSocket pueden ejecutarse tanto desde localizaciones gestionadas como desde localizaciones privadas dependiendo de si prefieres ejecutar el test desde fuera o desde dentro de tu red. Los tests WebSocket pueden ejecutarse de forma programada, bajo demanda o directamente dentro de tus pipelines CI/CD.

Configuración

Cuando decidas crear un test WebSocket, define la solicitud de tu test.

Definición de la solicitud

1. Especifica la URL donde se ejecutará el test.

2. Introduce la cadena que quieres enviar en tu test.

3. Añade Opciones avanzadas (opcional) a tu test:

   • 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 al iniciar una conexión WebSocket. También puedes anular las cabeceras predeterminadas (por ejemplo, la cabecera user-agent).
   • Cookies: Define cookies para añadir a tu solicitud HTTP al iniciar una conexión WebSocket. Define varias cookies utilizando el formato <COOKIE_NAME1>=<COOKIE_VALUE1>; <COOKIE_NAME2>=<COOKIE_VALUE2>.

   • Autenticación básica HTTP: Añade credenciales de autenticación básica HTTP.

4. Pon un nombre a tu test WebSocket.
5. Añade Etiquetas (tags) env así como cualquier otra etiqueta a tu test WebSocket. 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.

Definición de aserciones

Las aserciones definen cuál es un resultado de test esperado. Al hacer clic en Test de URL (URL de test), se añade una aserción básica sobre el response time. Debes definir al menos una aserción para que sea monitorizada por tu test.

Selecciona la vista previa de la respuesta directamente o haz clic en Nueva aserción para crear una aserción. Puedes crear hasta 20 aserciones por cada test WebSocket.

Para aplicar una lógica OR en una aserción, utiliza los comparadores matches regex o does not match regex para definir una expresión regular con varios valores esperados para el mismo tipo de aserción, como (0|100). Se considera que el resultado del test tiene éxito si el valor de respuesta de la cadena o de la aserción de la cabecera es 0 o 100.

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 WebSocket. Los tests WebSocket 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.

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

Indicar la frecuencia del test

Los tests WebSocket se pueden ejecutar:

• De forma programada para asegurar que tus endpoints más importantes estén siempre disponibles para tus usuarios. Selecciona la frecuencia con la que quieres que Datadog ejecute tu test WebSocket.
• 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 resulte 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.

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

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, leave the option as Never renotify if the monitor has not been resolved.

4. 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 WebSocket.

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.

Entre las razones figuran las siguientes:

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.

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

WEBSOCKET

La conexión WebSocket se ha cerrado o no se puede abrir. Puede ocurrir un tipo de error WEBSOCKET:

• WEBSOCKET: Received message longer than the maximum supported length. indica que la longitud del mensaje de respuesta alcanza la longitud máxima (50kb).

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 WebSocket Synthetic. Para crear, editar y eliminar tests WebSocket 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 WebSocket en función de los roles de tu organización. Al crear un test WebSocket, elige qué roles (además de tu usuario) pueden leer y escribir tu test.

Referencias adicionales

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

Presentación de la monitorización Synthetic de DatadogBLOG Ejecutar tests UDP y WebSocket para monitorizar aplicaciones críticas para la latenciaBLOG Introducción a los tests SyntheticCENTRO DE APRENDIZAJE Más información sobre los monitores de test SyntheticDOCUMENTACIÓN