Configuración de una solicitud WebSocket

Url

Para abrir una conexión WebSocket, debe introducir la dirección URL de WebSocket del punto de conexión o dirección IP de la dirección URL de WebSocket que desea comprobar (se admiten los protocolos ws:// y cifrados wss://). Por ejemplo, wss://echo.websocket.org/

Para activar un modo de entrada más amigable visualmente, haga clic en el interruptor Detallado en la parte superior de la sección.

Puede convertir la dirección URL en un valor dinámico o un parámetro de contexto aquí. Por ejemplo, para cambiar dinámicamente la URL de destino.

Enviar datos

Si necesita transferir datos al punto de conexión de destino, en el campo Enviar datos, especifique un mensaje en una cadena o formato binario. Dotcom-Monitor enviará el mensaje al punto de conexión de destino mediante el protocolo WebSocket y esperará la respuesta.

Dotcom-Monitor admite expresiones razor en los mensajes WebSocket. Para enviar una cadena que contenga una expresión razor, introdúzcala en el campo Enviar datos y use el programa Preparar script para establecer el tipo de mensaje en expresión Razor. De lo contrario, el mensaje se analizará y se enviará como texto. Utilice el siguiente fragmento de código en el campo Preparar script para notificar al sistema que el mensaje debe analizarse con razor engine:

ProcessPostDataByRazor(currentTask);

Además del motor Razor, Dotcom-Monitor permite cambiar dinámicamente los datos del cuerpo de la solicitud mediante máscaras de datos. Para obtener información sobre cómo usar la sintaxis de Razor y las máscaras de datos en los datos enviados y configurar la carga útil que cambia dinámicamente, consulte Cómo cambiar dinámicamente la carga útil en solicitud HTTP.

Validación de respuesta (validación de contenido)

Para validar una cadena de mensaje recibida de WebSocket, puede afirmar palabras clave en el escenario de ejecución de llamadas. El sistema esperará la respuesta del punto final de destino y comprobará la presencia de la palabra clave especificada en la cadena en el mensaje recibido. Si la palabra clave no se detectó en las respuestas del socket, se generará un error.

En los campos Palabra clave , puede especificar una palabra o frase que desee buscar en el mensaje de respuesta. Utilice el texto sin formato para especificar una palabra clave:

Tenga en cuenta que una palabra clave distingue entre mayúsculas y minúsculas.

Preparar guión y secuencia de comandos de publicación

Los campos pueden contener código de C#, que se puede usar para solicitudes específicas y datos de dirección URL o para validar o publicar encabezados personalizados. Consulte el artículo Uso del script y el script de publicación o póngase en contacto con el soporte técnico para obtener más detalles sobre el uso.

El escenario dinámico de la ejecución de la llamada WebSocket se puede especificar en el campo Preparar script. El escenario dinámico puede incluir una serie de operaciones con datos binarios o de cadena.

Operaciones con formato binario (msg como Base64 codificado):

  • ValidateBinary(string msg): comprueba si una respuesta WebSocket es igual a los datos binarios especificados.
  • ValidateBinaryContains(string msg): comprueba si una respuesta WebSocket contiene datos binarios especificados.
  • SendBinary(string msg): envía un mensaje binario a un WebSocket.

Operaciones con formato de texto:

  • SendText(string msg): envía una cadena de texto a un WebSocket.
  • ValidateText(string msg): comprueba si una respuesta de un WebSocket es igual a una cadena especificada.
  • ValidateTextContains(string msg): comprueba si una respuesta de WebSocket contiene una cadena especificada.

En los casos en que se especificó cualquier aserción en el campo Preparar script, el sistema esperará la aserción especificada en la respuesta y continuará con la ejecución del script una vez que la validación se realice correctamente. Si no se recibe un mensaje con la aserción especificada y se alcanza el tiempo de espera de finalización de la tarea, generaremos el error de validación.

Dotcom-Monitor le permite incluir tantas operaciones como sea necesario en el script Preparar. Sin embargo, si se alcanza el tiempo de espera de finalización de la tarea, se finalizará la ejecución del script. El tiempo de finalización de la tarea se cuenta desde el inicio de la ejecución del script.

  • Ejemplo: Validación de respuesta OK

  • Ejemplo: Error en la validación de la respuesta

Tenga en cuenta que los campos Enviar datos y validación de contenido se omiten si el campo Preparar script contiene los pasos correspondientes en el escenario dinámico. Por ejemplo, si se incluyen los pasos siguientes en el script, se omitirá el campo Enviar datos y validación de contenido:

currentTask.SendText("This is a test");
currentTask.ValidateText("This is a test");

Donde el parámetro currentTask no depende de un nombre de tarea y tiene el tipo de la tarea que se procesa actualmente.

Comprobación de certificado/SSL

Secure Socket Layer SSL Certificate Check incluye las siguientes opciones de validación:

  • Autoridad: comprueba si una cadena de certificados contiene un certificado raíz de confianza o no de confianza.
  • Nombre común (CN): valida que una dirección a la que navegue coincida con el certificado de dirección al que se firmó la dirección.
  • Fecha: comprueba la fecha de caducidad del certificado.
  • Revocación: valida que la cadena de confianza del certificado no contiene un certificado revocado.
  • Uso: comprueba una cadena de certificados para el uso incorrecto de un certificado intermedio.
  • Recordatorio de expiración en días: un recordatorio que notifica (como un error) sobre la expiración del certificado.
  • Certificado de cliente: nombre del certificado de cliente.

Umbral de validación de tiempo (en segundos)

Escriba el número de segundos que el servicio debe esperar una respuesta de la página web antes de finalizar la ejecución de la solicitud y devolver un error. Si se deja en blanco, el tiempo de espera predeterminado para una solicitud es de 60 segundos.

Autenticación básica

The Basic Authentication scheme is used to allow users to access content on some websites. Once provided, login credentials will be passed along with the request header to the web server.

  • Username: contains a username for HTTP/S basic or digest access authentication.
  • User Password: contains a password for HTTP/S basic or digest access authentication.

Do not confuse Basic Authentication with other authentication schemes such as Bearer Authentication that involves bearer tokens and OAuth 2.0 that uses access tokens.

Read the articles on Basic Authentication Username and Password and Monitoring OAuth 2.0-based APIs for more information.

Encabezados

La opción permite agregar encabezados personalizados adicionales si es necesario.

  • Nombre del encabezado: especifique el nombre del parámetro tal como aparecerá en la solicitud.
  • Valor: escriba el valor asociado al nombre del parámetro.

Opciones de DNS

La característica Opciones de DNS permite a los usuarios elegir cómo se llevan a cabo las solicitudes de servidor de nombres de dominio (DNS) durante una tarea de supervisión.

Para especificar el modo de resolución de nombres de host, en la sección Modo de resolución de DNS, seleccione uno de los modos disponibles. Para obtener más información sobre la configuración de características, consulte Opciones de modo DNS.

La sección Hosts DNS personalizados permite configurar la asignación de direcciones IP a nombres de host. Se admite la resolución DNS IPv6 e IPv4.

Para especificar la asignación, introduzca la dirección IP y el nombre de host en los campos correspondientes.

Ejemplos:

192.168.107.246 example.com user.example.com userauth.example.com tools.example.com
192.168.107.246 example.com
192.168.107.246 user.example.com
192.168.107.246 userauth.example.com

Véase también: Opciones de modo DNS.

Filtro de errores

You can create filters that will ignore specific errors that you know may occur and are not relevant to the goal of a specific device. The system will not generate alerts on responses with error codes that match the filters. For example, DNS errors could be filtered out based on who is responsible for DNS server operations. In addition, you can configure the system to ignore a range of error codes using a dash, or multiple error codes using semicolons as a separator.

You can find a comprehensive list of Error Codes in the HTTP Status Codes List | HTTP Error Codes Explained article of this wiki.

For example, if you do not care about 404 errors on one particular device, you can filter them out so that you do not receive alerts when they the errors are detected. The error details will be available for review in the device reports.

If you want to ignore an error with a specific code and type while monitoring, you can configure the Ignore Error Codes option in the device settings. If the system detects a response with the specified error type and code, the response will be considered as successful and its status will be changed to OK. Note that ignored errors will not be reflected on the reports and can’t be tracked down.