ウェブソケット要求の設定
URL
WebSocket 接続を開くには、エンドポイントの WebSocket URL または確認する WebSocket URL の IP アドレスを入力する必要があります (ws:// および暗号化された wss:// プロトコルがサポートされています)。 たとえば、wss://echo.websocket.org/
より視覚的にわかりやすい入力モードをオンにするには、セクションの上部にある 詳細 スイッチをクリックします。
ここで、URL を動的な値またはコンテキスト パラメーターに変換できます。 たとえば、ターゲット URL を動的に変更します。
データの送信
ターゲット エンドポイントにデータを転送する必要がある場合は、[ データの送信 ] フィールドで、文字列形式またはバイナリ形式でメッセージを指定します。 ドットコムモニターは、WebSocket プロトコルを使用してターゲット エンドポイントにメッセージを送信し、応答を待機します。
ドットコムモニターは、WebSocket メッセージで Razor 式をサポートしています。 Razor 式を含む文字列を送信するには、[ データの送信 ] フィールドに文字列を入力し、 準備スクリプト を使用してメッセージの種類を Razor 式に設定します。 それ以外の場合、メッセージは解析され、テキストとして送信されます。 [ スクリプトの準備 ] フィールドで次のスニペットを使用して、メッセージを Razor エンジンで解析する必要があることをシステムに通知します。
ProcessPostDataByRazor(currentTask);
Razor エンジンに加えて、ドットコムモニターを使用すると、データ マスクを使用して要求本文データを動的に変更できます。 送信データで Razor 構文とデータ マスクを使用する方法、および動的に変化するペイロードを構成する方法については、「 HTTP 要求でペイロードを動的に変更する方法」を参照してください。
応答の検証 (コンテンツの検証)
WebSocket から受信したメッセージ文字列を検証するには、呼び出し実行シナリオでキーワードをアサートします。 システムはターゲット エンドポイントからの応答を待機し、受信したメッセージで文字列内に指定されたキーワードが存在するかどうかを確認します。 ソケットからの応答でキーワードが検出されなかった場合は、エラーが生成されます。
[キーワード] フィールドには、応答メッセージで検索する単語または語句を 1 つ指定できます。 プレーンテキストを使用してキーワードを指定します。
スクリプトとポスト スクリプトの準備
フィールドには、特定の要求や URL データ、またはカスタム ヘッダーの検証や公開に使用できる C# コードを含めることができます。 使用方法の詳細については、「スクリプト の準備とポスト スクリプトの使用 」の記事を参照するか、テクニカル サポートにお問い合わせください。
WebSocket 呼び出し実行の動的シナリオは、[ スクリプトの準備 ] フィールドで指定できます。 動的シナリオには、バイナリ データまたは文字列データを使用した多数の操作を含めることができます。
バイナリ形式の操作 (Base64 エンコードとしてのメッセージ):
- ValidateBinary(文字列メッセージ) – WebSocket 応答が指定されたバイナリ データと等しいかどうかを確認します。
- ValidateBinaryContains(文字列メッセージ) – WebSocket 応答に指定されたバイナリ データが含まれているかどうかを確認します。
- SendBinary(文字列メッセージ) – バイナリメッセージをWebSocketに送信します。
テキスト形式の操作:
- SendText(文字列メッセージ) – テキスト文字列をウェブソケットに送信します。
- ValidateText(文字列メッセージ) – WebSocket からの応答が指定された文字列と等しいかどうかを確認します。
- ValidateTextContains (文字列 msg) – WebSocket 応答に指定された文字列が含まれているかどうかを確認します。
ドットコムモニターを使用すると、準備スクリプトに必要な数の操作を含めることができます。 ただし、タスク完了タイムアウトに達すると、スクリプトの実行は終了します。 タスクの完了時間は、スクリプトの実行開始からカウントされます。
-
例: 応答検証 OK
-
例: 応答の検証に失敗しました
SSL/証明書チェック
セキュアソケットレイヤーSSL証明書チェックには、次の検証オプションが含まれています。
- [証明機関]: 証明書チェーンに、信頼されているルート証明書が含まれているか、信頼されていないかを確認します。
- 共通名 (CN): 移動先のアドレスが、そのアドレスが署名されたアドレス証明書と一致していることを検証します。
- [日付]: 証明書の有効期限を確認します。
- 失効: 証明書の信頼チェーンに失効した証明書が含まれていないことを検証します。
- 使用法: 中間証明書の不適切な使用について証明書チェーンを検証します。
- 有効期限アラーム日数: 証明書の有効期限を通知する通知 (エラー)。
- クライアント証明書: クライアント証明書名。
時間検証のしきい値 (秒)
サービスが Web ページからの応答を待機してから、要求の実行を終了してエラーを返す秒数を入力します。 これを空白のままにすると、要求の既定のタイムアウトは 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 オプション機能を使用すると、監視タスク中にドメイン ネーム サーバー (DNS) 要求を実行する方法をユーザーが選択できます。
ホスト名の解決モードを指定するには 、[DNS 解決モード] セクションで、使用可能なモードのいずれかを選択します。 機能の構成の詳細については 、「DNS モード オプション」を参照してください。
[Custom DNS Hosts] セクションでは、IP アドレスとホスト名のマッピングを設定できます。 IPv6 および IPv4 DNS 解決がサポートされています。
マッピングを指定するには、対応するフィールドに 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.