次の方法で共有

失敗した要求トレース規則を使用したアプリケーション要求ルーティングのトラブルシューティング

  • [アーティクル]

適用対象:Windows Server 2016 以降のオペレーティング システム バージョンの インターネット インフォメーション サービス

失敗した要求トレースは、Windows Server 2016 以降のバージョンに付属する インターネット インフォメーション サービス (IIS) Web サーバーでの要求処理エラーをトラブルシューティングするための強力なツールです。 この記事では、失敗した要求トレース ルールを有効にして、アプリケーション要求ルーティングのエラーとトレース手順をデバッグする手順について説明します。 失敗した要求トレース ルールの詳細については、「 IIS でトレースを使用して失敗した要求をトラブルシューティングするを参照してください。

目標

失敗した要求トレースルールを構成し、アプリケーション要求ルーティングのトラブルシューティング時に何を検索するかを理解するため。

前提条件

このチュートリアルでは、次の前提条件が必要です。

  • Windows Sever 2016 (任意の SKU) 以降の IIS (トレースロール サービスが IIS 用にインストールされています)。
  • Microsoft アプリケーション要求ルーティングと依存モジュール。
  • サイトとアプリケーションが正常に実行されているアプリケーション サーバー (2 台以上)。

アプリケーション要求ルーティングがインストールされていない場合は、ダウンロード センターからダウンロードし、「アプリケーション要求ルーティングのインストールで説明されている手順に従ってインストールします。

もう 1 つの前提条件は、 アプリケーション要求ルーティング モジュールの使用 アプリケーション要求ルーティングを構成していることです。 次のセクションに進む前に、アプリケーション要求ルーティングが正常に動作している必要があります。

手順 1: 失敗した要求トレース規則を構成する

UI またはコマンド ラインを使用して、アプリケーション要求ルーティングの失敗した要求トレース規則を構成します。

UI を使用して失敗した要求トレース規則を構成する方法

  1. インターネット インフォメーション サービス (IIS) マネージャー (inetmgr) を起動します。

  2. [Default Web Site] を選択します。

    [サイト] リストが展開されていることを示すスクリーンショット。既定の Web サイトが強調表示されています。

  3. [操作]ウィンドウの [構成] で、[失敗した要求のトレース] を選択します。

    [操作] ウィンドウの [失敗した要求トレース] に焦点を当てたスクリーンショット。

  4. [ Edit Web Site Failed Request Tracing Settings ] ダイアログ ボックスで、[ Enable ] チェック ボックスをオンにします。

    [Web サイトの失敗した要求トレース設定の編集] ダイアログのスクリーンショット。

  5. [OK] を選択して変更を保存します。

  6. [Default Web Site] を選択します。

  7. [失敗した要求トレースの規則] をダブルクリックします。

  8. Actions ペインで Add... を選択します。

    [失敗した要求トレースルールの追加] ウィンドウのスクリーンショット。すべてのコンテンツが選択されています。

    すべてのコンテンツ (*) を選択し、 次へを選択します。

  9. [ Status code(s): を選択し、「 200-399」と入力します。

    失敗した要求トレース ルールの追加のスクリーンショット。状態コードがチェックされます。

    [次へ] を選択します。 上記の構成では、状態コードが 200 から 399 の間にある場合にトレースを書き込む失敗した要求トレースルールが作成されています。

  10. [ASP]、[ASPNET]、[ISAPI Extension](ISAPI 拡張機能) をオフにします。 [WWW Server](WWW サーバー) を選択した後、[領域] に表示される項目のうち、[Rewrite](再書き込み) と [RequestRouting](要求ルーティング処理) を除くすべての項目の選択を解除します。 アプリケーション要求ルーティングは受信要求を検査するために URL 書き換えモジュールに依存するため、アプリケーション要求ルーティング (RequestRouting) と URL 書き換えモジュール (Rewrite) の両方に対してトレースを有効にすることをお勧めします。

    [失敗した要求トレースルールの編集] ウィンドウのスクリーンショット。[プロバイダー] セクションで W サーバーが選択されています。

    URL 書き換えモジュールトレースの詳細については、「 失敗した要求トレースをトレース書き換えルールに使用するを参照してください。

  11. [完了] を選びます。

コマンド ラインを使用して失敗した要求トレース規則を構成する方法

  1. 管理者特権でコマンド プロンプトを開きます。

  2. %windir%\system32\inetsrv に移動します。

  3. 既定の Web サイトで失敗した要求トレースを有効にするには、次のコマンドを実行します。

    appcmd set site "Default Web Site" -traceFailedRequestsLogging.enabled:"true" /commit:apphost

  4. 上記の UI に示すように失敗した要求トレース規則を構成するには、次のコマンドを実行します。

    appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /+"[path='*']"

    appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /+"[path='*'].traceAreas.[provider='WWW Server',areas='Rewrite,RequestRouting',verbosity='Verbose']"

    appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /[path='*'].failureDefinitions.statusCodes:"200-399"

手順 2: 失敗した要求トレース ログを分析する

この手順では、アプリケーション要求ルーティングに要求を送信し、失敗した要求トレース ログを分析します。

失敗した要求のトレース ログを確認するには

  1. 失敗した要求のトレース ログが書き込まれるディレクトリに移動します。 既定では、場所は %SystemDrive%\inetpub\Logs\FailedReqLogFiles\ です。

  2. Default Web サイトに一致するフォルダーにディレクトリを変更。 既定では、 W3SVC1 です。 不明な場合は、IIS マネージャーで Default Web Site を選択し、Actions ウィンドウで Advanced Settings... を選択します。 ID の値は、対応するフォルダーを表します。 (たとえば、ID 1 は W3SVC1 に対応します)。

  3. XML ファイルがある場合は、次のように入力して削除します。

    del *.xml

  4. アプリケーション要求ルーティング処理に要求を送信します。 アプリケーション要求ルーティングが正常に機能している場合は、200 応答が返されます。応答は、 Step 1 で指定されている 200 ~ 399 の範囲内になります。 そのため、上記の場所にログが書き込まれます。

  5. ディレクトリ内のファイルを一覧表示して、新しい XML ファイルが書き込まれたことを確認します。

  6. XML ファイルを開きます。 Request Details を選択します。 Complete 要求トレースを選択し、Expand All を選択します。 次の図は、アプリケーション要求ルーティングの失敗した要求トレース ログの例です。

    タブの Web サイト例の要求診断を示すブラウザー ウィンドウのスクリーンショット。

  7. 次のセクションに注目してください。

    • GENERAL_REQUEST_HEADERS:

      • [Headers](ヘッダー): アプリケーション要求ルーティング処理が受信した HTTP ヘッダーを示します。

    • ARR_REQUEST_ROUTED:

      • WebFarm: 要求がルーティングされるサーバー グループの名前を示します。
      • サーバー: 要求がルーティングされる宛先サーバーを示します。
      • [Algorithm](アルゴリズム): 使用されている負荷分散アルゴリズムを示します。
      • [RoutingReason]: サーバーが選択された理由の背景にある決定を示します。

    • [ARR_SERVER_STATS]:

      • [State](状態): 宛先サーバーの稼働状況。
      • [TotalRequests]: このサーバーに送信された要求の数に関するランタイム統計。
      • [CurrentRequests]: このサーバーに対する HTTP 要求の同時実行数に関するランタイム統計。
      • [BytesSent]: このサーバーに送信されたデータの量についてのランタイム統計 (KB 単位)。
      • [BytesReceived]: このサーバーから受信したデータの量についてのランタイム統計 (KB 単位)。
      • ResponseTime: このサーバーの応答性に関するランタイム統計 (ミリ秒単位)。

    • GENERAL_RESPONSE_HEADERS

      • [Headers](ヘッダー): 宛先サーバーからの応答 HTTP ヘッダーを示します。

    • GENERAL_RESPONSE_ENTITY_BUFFER

      • [Buffer](バッファー): 宛先サーバーからの応答エンティティを示します。

    • アプリケーション要求ルーティング処理のパフォーマンスをプロファイリングするために、以下の項目が、対応するイベントの開始時刻と終了時刻を示すタイムスタンプと共に追加されています。

      • ARR_REQUEST_HEADERS_START
      • ARR_REQUEST_HEADERS_END
      • ARR_RESPONSE_HEADERS_START
      • ARR_RESPONSE_HEADERS_END
      • ARR_RESPONSE_ENTITY_START
      • ARR_RESPONSE_ENTITY_END
      • ARR_RESPONSE_ENTITY_START
      • ARR_RESPONSE_ENTITY_END

サーバー コアで失敗した要求トレース ログを収集する場合は、ブラウザーが使用可能なコンピューターに freb.xsl スタイルシートを含むログをコピーします。

まとめ

これで、アプリケーション要求ルーティングの失敗した要求トレース規則が正常に構成されました。 失敗した要求トレース 規則を使用して、アプリケーション要求ルーティングのトラブルシューティングとデバッグを行うだけでなく、特定の要求の宛先サーバーを選択する際に行った負荷分散アルゴリズムなどのルーティングの決定を理解できます。