Настройка запроса WebSocket
Url
Чтобы открыть соединение WebSocket, необходимо ввести URL-адрес WebSocket конечной точки или IP-адрес URL WebSocket, который вы хотите проверить (поддерживается ws:// и зашифрованные протоколы wss://). Например, wss://echo.websocket.org/
Чтобы включить более визуально чистый режим ввода, нажмите подробный переключатель в верхней части раздела.
Вы можете преобразовать URL в динамическое значение или параметр контекста здесь. Например, динамическое изменение целевого URL-адреса.
Отправка данных
Если вам необходимо передать данные в целевую конечную точку, в поле Отправка данных, укажите сообщение в строке или двоичном формате. Dotcom-Monitor отправит сообщение в конечную точку цели с помощью протокола WebSocket и будет ждать ответа.
Dotcom-Monitor поддерживает выражения Razor в сообщениях WebSocket. Чтобы отправить строку, которая содержит выражение Razor, введите его в поле отправки данных и используйте сценарий подготовки, чтобы настроить тип сообщения на выражение Razor. В противном случае сообщение будет проанализировано и отправлено в виде текста. Используйте следующий фрагмент в поле Prepare Script, чтобы уведомить систему о том, что сообщение должно быть разобранно с помощью движка Razor:
ProcessPostDataByRazor(currentTask);
В дополнение к двигателю Razor, Dotcom-Monitor позволяет динамически изменять данные тела запроса с помощью масок данных. Чтобы узнать, как использовать синтаксис Razor и маски данных в отправленных данных, и настроить динамически меняющейся полезной нагрузки, см. Как динамически изменить полезную нагрузку в http Request.
Проверка ответа (Проверка содержимого)
Для проверки строки сообщений, полученной из WebSocket, можно утвердить ключевые слова в сценарии выполнения вызова. Система будет ждать ответа от целевой конечной точки, и проверять полученное сообщение на наличие указанного ключевого слова в строке. Если ключевое слово не было обнаружено в ответах из гнезда, ошибка будет сгенерирована.
В полях Ключевое слово можно указать одно слово или фразу, которую требуется найти в ответном сообщении. Используйте обычный текст, чтобы указать ключевое слово:
Подготовка сценария и почтового сценария
Поля могут содержать код СЗ, который может использоваться для конкретных запросов и данных URL или для проверки или публикации пользовательских заголовников. Для получения более подробной информации об использовании обратитесь в техническую поддержку в статье Using Prepare Script and Post Script.
Динамический сценарий выполнения вызова WebSocket можно указано в поле «Подготовьй сценарий». Динамический сценарий может включать в себя ряд операций с двоичными или струнными данными.
Бинарные отформатированные операции (msg как Base64 закодированы):
- ValidateBinary(string msg) – проверяет, равен ли ответ WebSocket указанным двоичным данным.
- ValidateBinaryContains (string msg) – проверяет, содержит ли ответ WebSocket указанные двоичные данные.
- SendBinary (строка msg) – отправляет двоичное сообщение на WebSocket.
Текстовые отформатированные операции:
- SendText (строка msg) – отправляет текстовую строку на WebSocket.
- ValidateText(string msg) – проверяет, равен ли ответ от WebSocket указанной строке.
- ValidateTextContains(string msg) — проверяет, содержит ли ответ WebSocket указанную строку.
В тех случаях, когда какое-либо утверждение было указано в поле Prepare Script, система будет ждать указанного утверждения в ответе и приступить к исполнению сценария после успешной проверки. Если сообщение с указанным утверждением не получено, и достигнуто время ожидания завершения задачи, мы создадим ошибку проверки.
Dotcom-Monitor позволяет включить в сценарий Prepare столько операций, сколько необходимо. Однако, если истечет время ожидания выполнения задачи, выполнение скрипта будет прекращено. Время выполнения задачи отсчитывается от начала выполнения скрипта.
-
Пример: проверка ответа OK
-
Пример: сбой проверки ответа
Проверка SSL/сертификата
Проверка SSL-сертификата уровня защищенных сокетов включает следующие параметры проверки:
- Власть: проверяет, содержит ли цепочка сертификатов корневой сертификат, которому доверяют или не доверяют.
- Общее имя (CN): подтверждает, что адрес, по который вы переходите, соответствует сертификату адреса, на который был подписан адрес.
- Дата: проверяет срок действия сертификата.
- Отзыв: подтверждает, что цепочка доверия сертификата не содержит отозванного сертификата.
- Использование: проверяет цепочку сертификатов на ненадлежащее использование промежуточного сертификата.
- Напоминание об истечении срока действия в днях: напоминание, уведомляемое (как ошибка) об истечении срока действия сертификата.
- Сертификат клиента: имя сертификата клиента.
Порог проверки времени (в секундах)
Введите количество секунд, в течение которых служба должна ожидать ответа с веб-страницы, прежде чем завершить выполнение запроса и вернуть ошибку. Если оставить поле пустым, время ожидания запроса по умолчанию составляет 60 секунд.
Базовая аутентификация
The HTTP authentication protocol is used to allow users to access content on some websites.
The following authentication schemes are available:
- Basic Authentication: This method encodes the username and password in base64 and sends them in the request header. It’s simple but not secure unless used with HTTPS.
- Digest Authentication: This scheme hashes credentials using a nonce (a random value) before sending them over the network, providing better security than Basic Authentication by preventing replay attacks.
- NTLM Authentication: A challenge-response mechanism developed by Microsoft, NTLM is used for securing credentials in Windows environments. It provides strong security by using multiple hashing and challenge-response protocols.
Once provided, login credentials will be passed along with the request header to the web server.
- Username: contains a username for HTTP/S authentication.
- User Password: contains a password for HTTP/S authentication.
Do not confuse HTTP 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.
Заголовки
Опция позволяет добавлять любые дополнительные пользовательские заготовки, если это необходимо.
- Название заголовка: укажите имя параметра, как оно появится в запросе.
- Значение: введите значение, связанное с именем параметра.
Параметры DNS
Функция DNS Options позволяет пользователям выбирать, как запросы сервера доменных имен (DNS) проводятся во время выполнения задачи мониторинга.
Чтобы указать режим разрешения имен хостов в разделе Режим решения DNS, выберите один из доступных режимов. Для получения более подробной информации о конфигурации функции см.
Раздел Custom DNS Hosts позволяет настроить сопоставление IP-адресов с именами хостов. Поддерживается разрешение DNS IPv6 и IPv4.
Чтобы указать сопоставление, введите IP-адрес и имя хоста в соответствующие поля.
Смотрите также: Параметры режима DNS.
Фильтр ошибок
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.