デバイスとターゲットを作成する方法

HTTP/S 監視では、単一の URL で可用性、パフォーマンス、適切なコンテンツ、およびエラーがチェックされます。 一般的な種類の要求、Cookie、フォーム送信、カスタムヘッダー、パスワードで保護されたサイト(基本的なHTTP / S認証およびCookie/スクリプト承認メカニズム)、およびタイムアウトしきい値をすべてサポートしています。

HTTP/S 監視では、セキュリティ証明書の検証、認証局のチェック、および証明書の有効期限チェックの実行が行われます。 証明書の有効期限が近づいたときにリマインダーを送信するように構成できます。

HTTP(S) 要求パラメーターをコンテキスト パラメーター に変換して、たとえば、監視デバイス内の別の要求の応答から取得した値を渡すことができます。 URL、ヘッダー、要求本文、および準備/投稿スクリプトのコンテキスト パラメーターを設定できます。 詳細については、「 HTTP(S) 要求でコンテキスト パラメータを使用する方法」を参照してください。

一括インポート

ワンクリックで多数のデバイスの監視を作成するには、[監視の種類の選択] ページで HTTP/S 監視の種類に提供されている [一括インポート] オプションを選択します。 詳細については、 一括インポート |ウェブページの監視、HTTP/S、およびPING/ICMPデバイスの 記事 ウィキの記事。

要求の構成

URL

タスクを実行するページの URL を入力します。 www.example.com 形式にする必要があります。 セクションの上部にある 詳細 スイッチャーをクリックすると、視覚的にわかりやすい入力モードをオンにすることができます。

SSL/証明書チェック

セキュア ソケット レイヤ SSL 証明書チェックは、HTTP(S) テストの標準的な側面です。

次の追加オプションを使用できます。

  • [証明機関]: 証明書チェーンに、信頼されているルート証明書が含まれているか、信頼されていないかを確認します。
  • 共通名 (CN): 移動先のアドレスが、そのアドレスが署名されたアドレス証明書と一致していることを検証します。
  • [日付]: 証明書の有効期限を確認します。
  • 失効: 証明書の信頼チェーンに失効した証明書が含まれていないことを検証します。
  • 使用法: 中間証明書の不適切な使用について証明書チェーンを検証します。
  • 有効期限アラーム日数: 証明書の有効期限を通知する通知 (エラー)。
  • クライアント証明書: クライアント証明書名。

「ターゲット ホスト名または IP アドレス」も参照してください。

時間検証のしきい値 (秒)

システムが Web ページからの応答を待機してからタスクを終了してエラーを返すまでの最大秒数を入力します。

最大タイムアウト値は 70 秒に制限されています。 しきい値が設定されていない場合は、既定の 70 秒のタイムアウトがタスクに適用されます。

要求の種類

GET または POST 要求を Web ページに送信できます。 GET 要求を選択すると、Web サーバーからデータを取得するだけです。 POST 要求を選択すると、サーバーが処理するデータのセットが含まれているということが示されます。

要求の種類を POST に設定し、以下の追加パラメーター セクションで POST パラメーターを指定しない場合、POST 値は、タスクを保存するときに GET に戻って既定の値になります。

URL リダイレクト

[ リダイレクトに従う ] オプションが [はい]に設定されている場合、システムは 301 応答で送信される URL のパスに従い、各リダイレクトを個別の HTTP 要求と見なします。 これにより、最初の URL と後続の応答の両方の応答時間を含む、テスト結果で完全なリダイレクト チェーン (要求がリダイレクトされるすべてのリンク) を実行できます。

初期 URL だけでなく、チェーン内のすべての URL をテストする必要がある場合は、[ リダイレクトに従 う] オプションを有効にすることをお勧めします。 たとえば、リダイレクト チェーン内の URL ごとに SSL 証明書チェックを実行すると便利です。

初期 URL のみをテストする場合は、[ リダイレクトに従う ] オプションを無効にします。

既定のリダイレクト制限は 10 リダイレクトに設定されています。 システムで特定の回数のリダイレクト (10 未満) を実行する場合は、[ スクリプトの準備] フィールドで、リダイレクト チェーンでテストする URL の数を指定できます。

string url;
url = "http://wtatour.com/";
(current.Task).TaskMaxRedirectAttempts = N;

ここで 、N は、リダイレクト先の数を指定します。 リダイレクトを実行しない場合は、リダイレクト場所の数を 0 に設定するだけです。

コンテンツの検証

コンテンツ検証キーワードは、期待されるコンテンツが Web ページに読み込まれたことを確認するために使用されます。 [キーワード]フィールドでは、Web ページのコンテンツで検索する 1 つ以上の単語または語句を指定できます。 予期されるキーワードが見つからない場合、タスクはエラーを返します。

キーワード フィールドには複数の文字列を入力できます。 入力する値は、次のように論理式で区切ることができます。

{[("keyword1"&"keyword2")|!"keyword3"]}

どこ:
{[ – キーワード式の開始。
[}- キーワード式の終了。
() – 括弧をグループ化します。
& – 論理 AND;
|– 論理 OR;
!– 論理ではない;
“文字列” – キーワード。

正常なキーワード式には、次のように開始および終了の角かっこを含める必要があります。

{["keyword"]}

基本認証

基本認証スキームは、ユーザーが一部の Web サイトのコンテンツにアクセスできるようにするために使用されます。 指定されたログイン資格情報が、要求ヘッダーとともに Web サーバーに渡されます。

  • ユーザー名: HTTP/S の基本認証またはダイジェスト アクセス認証のユーザー名が含まれています。
  • ユーザーパスワード: HTTP/S基本認証またはダイジェストアクセス認証のパスワードが含まれています。

基本認証は、ベアラー トークンを含むベアラー認証やアクセス トークンを使用する OAuth 2.0 などの他の認証スキームと混同しないでください。

詳細については、基本認証ユーザー名とパスワードおよびモニタリング OAuth 2.0 ベースの API に関する記事を参照してください。

ヘッダー

このオプションを使用すると、カスタム ヘッダーを追加できます。 たとえば、コンテンツタイプヘッダーで、送信されるデータの MIME タイプと要求を定義できます。

Content-Type: text/html

要求に Content-Type ヘッダーが指定されていない場合、要求は既定のコンテンツ タイプ アプリケーション/x-www-form-urlencodedで送信されます。

The default User-Agent header is set to:

User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; .NET CLR 1.1.4322; .NET CLR 1.0.3705; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) DMBrowser/2.1 (SV)

However, the user-agent string can be replaced with any other string. To do this, add a custom header with the name “user-agent” and the specific value needed.

要求本文

POST、PUT、または PATCH のいずれかの方法を選択した場合は、ここでペイロードを指定できます。 HTTP 要求本文内のコンテンツは、”生” データ (JSON、XML など) または静的な名前値コレクション (フォームデータ) として送信できます。

名前と値のコレクションを操作するには、セクションの上部にある 詳細 スイッチャーを使用して詳細入力モードをオンにし、対応するフィールドに要求パラメーターの名前と値を指定します。

JSON オブジェクトなどのリクエストと共に「生」データを送信するには、入力フィールドに JSON ペイロードを入力します。 要求本文を動的に変更することもできます。 たとえば、現在の日時を POST 要求の一部として送信したり、JSON ペイロードの現在のセッション ID をリモート サーバーに渡したりする必要がある場合などです。 ドットコムモニターは、Razor 構文とデータ マスクを使用して、HTTP 要求のペイロードを動的に変更できます。

  • 例。HTTP ポスト要求の動的 JSON 本文

    HTTP 要求での動的 JSON 本文のしくみを理解するために、次の例を見てみましょう。 Web サイトで注文を送信する必要があり、送信トランザクションには次の 3 つの基本的な手順が順次実行されるとします。

    1. ログイン
    2. チェックイン
    3. 注文の提出

    これらのステップを順次実行してテストを設定するには 、1つの監視デバイス内に3つのHTTPタスクを作成 する必要があります(ロードテストが行われている場合はロードテスト)。

    アプリケーションにチェックインするには、HTTP 要求を使用して、現在の時刻と一意の GUID を JSON に送信する必要があると仮定します。 また、注文を送信するには、ログイン時に生成されたユーザー・セッション ID と注文時間がアプリケーションによって必要になります。

    このテストを実装するには、まず、Web アプリケーション Web サーバーへの基本認証パラメーターを使用してログイン要求を構成する必要があります。 次に、実際のチェックイン時刻と一意の GUID を JSON 本文と共に渡す HTTP 要求を構成する必要があります。 この例では、JSON 本文に Razor 構文を使用して次の文字列を入力します。

    { "CheckInTime": "@Model["CurrentTime"]", "GenGuid": "@Model["Guid"]" }

    ここで @Model[” < パラメータ名 > “は 、Razor 式で必要なコンテキスト パラメーター名を参照します。

    コンテキスト パラメーターを宣言し、[スクリプトの準備] フィールドで Post Data の処理方法を指定する必要があります。

    context.Guid = Guid.NewGuid().ToString(); // uniq random string
    context.CurrentTime = DateTime.Now.ToUniversalTime().ToString("yyyy-MM-dd\Thh:mm:ss") + ".0Z"; // get current time in UTC
    ProcessPostDataByRazor(currentTask); // the call to process the Post Data content with the Razor engine

    結果の HTTP 要求は次のようになります。

    03:15:23
    POST http://www.dotcom-monitor.com/CheckIn
    { "CheckInTime": "2021-03-30T08:15:22.0Z", "GenGuid": "5c5e3d23-66fd-49d0-bd57-62c516aea7e7" }

    次のステップでは、注文を送信するように HTTP 要求を構成する必要があります。 これを行うために、JSON 本文の現在の時刻とセッション ID と、アイテムのモデル識別番号をターゲット エンドポイントに渡します。 このリクエストについては、JSON の本文を参照してください。

    { "OrderTime": "@Model["OrderTime"]",   "VIEWSTATE": "@Model["Session"]",  "ModelID": "2128506" }

    現在のセッション ID 変数の値を渡すためには、View State メソッドを使用して、最初のログイン ステップで呼び出されたログイン ページから取得する必要があります。 準備スクリプトでコーディングできます。 さらに、実際のユーザーの思考時間をシミュレートするために、3分のオフセットで注文時間変数を設定します。 したがって、[スクリプトの準備] フィールドには、次の文字列が含まれます。

    context.OrderTime = DateTime.Now.AddMinutes(3).ToUniversalTime().ToString("yyyy-MM-dd\Thh:mm:ss") + ".0Z"; // order time + 3 min
    context.Session = (Tasks["Login"] as Http).body["//INPUT[@ID='__VIEWSTATE']", "VALUE"]; // track state value from Login page 
    ProcessPostDataByRazor(currentTask);

    結果の HTTP 要求は次のようになります。

    03:15:45
    POST http://www.dotcom-monitor.com/Order
    { "OrderTime": "2021-03-30T08:18:45.0Z", "VIEWSTATE": "<Server Generated ViewState>", "ModelID": "2128506" }
                        

動的に変更されるペイロードを使用して HTTP 要求を構成する方法については 、「HTTP 要求でペイロードを動的に変更する方法」を参照してください。

DNS オプション

DNS オプション機能を使用すると、監視タスク中にドメイン ネーム サーバー (DNS) 要求を実行する方法をユーザーが選択できます。

ホスト名の解決モードを指定するには 、[DNS 解決モード] セクションで、使用可能なモードのいずれかを選択します。 機能の構成の詳細については 、「DNS モード オプション」を参照してください。

[カスタム DNS ホスト]セクションには、IP アドレスとホスト名のマッピングが含まれています。

マッピングを指定するには、対応するフィールドに IP アドレスとホスト名を入力します。

例:

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

参照 : DNS モード オプション

スクリプトとポスト スクリプトの準備

フィールドには、特定の POST、GET、URL データ、またはカスタム ヘッダーの検証または発行に使用できる C# コードを含めることができます。 使用法の詳細については、「 スクリプトの準備と Post Script の使用」の記事を参照するか、テクニカル サポートに問い合わせてください。