Visual Studio を使用した Azure App Service のアプリのトラブルシューティング

[アーティクル]
06/01/2023

概要

このチュートリアルでは、Visual Studio Tools を活用し、App Service のアプリをデバッグモードでリモートから実行するか、アプリケーションのログと Web サーバーのログを参照することによってデバッグする方法を説明します。

学習内容:

Visual Studio から利用できるアプリ管理機能。
Visual Studio のリモートビューを使用して、リモートアプリをすばやく変更する方法。
Azure でプロジェクトが実行されているときに、アプリと Web ジョブの両方をリモートからデバッグモードで実行する方法。
アプリケーションのトレースログを作成する方法と、ログが作成されている最中にそれらを確認する方法。
Web サーバーのログ (詳細なエラーメッセージ、失敗した要求トレースを含む) を確認する方法。
Azure のストレージアカウントに診断ログを送り、そこでログを確認する方法。

Visual Studio Ultimate がある場合は、デバッグに IntelliTrace を使用することもできます。 IntelliTrace については、このチュートリアルでは説明しません。

前提条件

このチュートリアルでは、Azure App Service での ASP.NET アプリの作成に関するページで設定した開発環境、Web プロジェクト、および App Service アプリを使用します。 Web ジョブのセクションでは、Azure Web ジョブ SDK の使用に関するページで作成したアプリケーションが必要です。

このチュートリアルで示すコードサンプルは、C# MVC Web アプリケーションに対応していますが、トラブルシューティング手順は Visual Basic および Web フォームの各アプリケーションでも同じです。

このチュートリアルは、Visual Studio 2019 の使用を前提としています。

ストリーミングログ機能は、.NET Framework 4 以降を対象とするアプリケーションでのみ動作します。

アプリの構成と管理

Visual Studio は、Azure portal で利用できるアプリ管理機能や構成設定に一部アクセスできるようになっています。このセクションでは、サーバーエクスプローラーを使用することで、その対象となる機能や設定について取り上げます。最新の Azure の統合機能を確認するために、 Cloud Explorer もお試しください。どちらのウィンドウも [表示] メニューから開くことができます。

まだ Visual Studio で Azure にサインインしていない場合は、サーバーエクスプローラーで、 [Azure] を右クリックし、Microsoft Azure サブスクリプションへの接続を選択します。

または、アカウントへのアクセスを可能にする管理証明書をインストールします。証明書をインストールする方針を選択した場合は、サーバーエクスプローラーで、 [Azure] ノードを右クリックし、コンテキストメニューの [サブスクリプションの管理およびフィルター] を選択します。 [Microsoft Azure サブスクリプションの管理] ダイアログボックスで、 [証明書] タブをクリックし、 [インポート] をクリックします。操作手順に従い、Azure アカウント用のサブスクリプションファイル ( .publishsettings ファイル) をダウンロードしてインポートします。

Note

サブスクリプションファイルをダウンロードする場合は、ソースコードディレクトリの外にあるフォルダー (Downloads フォルダーなど) に保存し、インポートが完了したらそのファイルを削除します。悪意のあるユーザーがサブスクリプションファイルへのアクセス許可を取得すると、Azure サービスを編集、作成、削除できるためです。

Visual Studio から Azure リソースへの接続の詳細については、「Azure portal を使用して Azure ロールを割り当てる」を参照してください。
サーバーエクスプローラーで [Azure] を展開し、 [App Service] を展開します。
Azure App Service での ASP.NET Web アプリの作成に関するページで作成したアプリを含むリソースグループを展開し、アプリノードを右クリックして、 [設定の表示] をクリックします。

[Azure Web アプリ] タブが表示され、Visual Studio から利用できるアプリ管理タスクや構成タスクが確認できます。

このチュートリアルでは、ログとトレースのドロップダウンを使用します。また、リモートデバッグも使用し、さまざまな方法でこの機能を有効にします。

このウィンドウの [アプリ設定] ボックスの一覧と [接続文字列] ボックスの一覧については、「Azure App Service:How Application Strings and Connection Strings Work (アプリケーション文字列と接続文字列の動作)」をご覧ください。

このウィンドウでは実行できないアプリ管理タスクを行う場合は、 [管理ポータルで開く] をクリックし、ブラウザーウィンドウを開いて Azure portal にアクセスします。

サーバーエクスプローラーでのアプリファイルへのアクセス

通常は、Web.config ファイルで customErrors フラグを On または RemoteOnly に設定して Web プロジェクトをデプロイします。これは、何か問題が発生したときに、役に立つエラーメッセージを表示しないことを意味します。表示されるエラーの多くは、次のいずれかのようなページになります。

'/' アプリケーションのサーバーエラー:

Screenshot showing a Server Error in '/' Application error in a web browser.

エラーが発生しました:

Screenshot showing an example of a generic error occurring in a web browser.

Web サイト側でページを表示できません

Screenshot showing a message that reads **The website cannot display the page error in a web browser**.

多くの場合、エラーの原因を最も簡単に見つける方法は、詳細なエラーメッセージを有効にすることです。その結果、既に示した最初のスクリーンショットのように、対応方法が表示されます。ここでは、デプロイした Web.config ファイルの変更が必要です。プロジェクト内の Web.config ファイルを編集し、プロジェクトを再デプロイすること、または Web.config の変換を作成し、デバッグビルドをデプロイすることもできますが、より簡単な方法があります。ソリューションエクスプローラーで、リモートビュー機能を使用して、リモートアプリからファイルを直接表示し、編集することができます。

サーバーエクスプローラーで、 [Azure] 、 [App Service] 、アプリがあるリソースグループ、アプリのノードの順に展開します。

アプリのコンテンツファイルとログファイルへのアクセス許可を付与するノードが表示されます。
[ファイル] ノードを展開し、 [Web.config] ファイルをダブルクリックします。

Visual Studio は、リモートアプリから Web.config ファイルを開き、タイトルバーのファイル名の横に [リモート] を表示します。
次の行を system.web 要素に追加します。

<customErrors mode="Off"></customErrors>
あまり役に立たないエラーメッセージを示しているブラウザーを最新の情報に更新すると、次の例のような詳細なエラーメッセージが表示されます。

(ここで示されているエラーは、赤く表示されている行を Views\Home\Index.cshtml に追加することによって作成したものです。)

Web.config ファイルの編集は、App Service アプリにあるファイルの読み取りと編集を可能にしてトラブルシューティングを容易にするシナリオの一例にすぎません。

アプリのリモートデバッグ

詳細なエラーメッセージで十分な情報が表示されておらず、エラーをローカルで再現できない場合は、トラブルシューティングの別の方法として、リモートでデバッグモードを実行することができます。ブレークポイントの設定、メモリの直接操作、コードのステップ実行、さらにコードパスの変更を実行できます。

リモートデバッグは、Visual Studio の各 Express Edition では機能しません。

ここでは、Azure App Service での ASP.NET アプリの作成に関するページで作成したプロジェクトを使用して、リモートでデバッグする方法について説明します。

Azure App Service での ASP.NET アプリの作成に関するページで作成した Web プロジェクトを開きます。
Controllers\HomeController.cs を開きます。

About() メソッドを削除し、その位置に次のコードを挿入します。

public ActionResult About()
{
    string currentTime = DateTime.Now.ToLongTimeString();
    ViewBag.Message = "The current time is " + currentTime;
    return View();
}

ViewBag.Message の行にブレークポイントを設定します。
ソリューションエクスプローラーで目的のプロジェクトを右クリックし、 [発行] をクリックします。
[プロファイル] ドロップダウンリストで、Azure App Service での ASP.NET アプリの作成に関するページで使用した同じプロファイルを選択します。次に、[設定] をクリックします。
[発行] ダイアログボックスで、 [設定] タブをクリックし、 [構成] を [デバッグ] に変更し、 [保存] をクリックします。
[発行] をクリックします。デプロイが完了し、ブラウザーが起動してアプリの Azure URL が表示されたら、ブラウザーを閉じます。
サーバーエクスプローラーで、アプリを右クリックしてから [デバッガーの接続] をクリックします。

ブラウザーが自動的に起動し、Azure で実行されているホームページが表示されます。デバッグに必要な設定を Azure がサーバーに対して行う間、20 秒ほどの待ち時間が生じることがあります。この待ち時間が生じるのは、48 時間以内にアプリでのデバッグモードを実行する初回に限られます。同じ期間に再度デバッグを開始しても、遅延はありません。

Note

デバッガーの起動時に問題がある場合、サーバーエクスプローラーではなくCloud Explorerを使用して起動してみてください。
メニューの [About] をクリックします。

Visual Studio がブレークポイントで停止します。コードが実行されている場所は、ローカルコンピューターではなく Azure 上です。
currentTime 変数にマウスを合わせて、時刻値を表示します。

表示される時刻は、Azure サーバーの時刻です。ローカルコンピューターとはタイムゾーンが異なります。
currentTime 変数に新しい値 ("Now running in Azure" など) を入力します。
F5 キーを押して実行を継続します。

Azure で実行中の [About] ページに、先ほど currentTime 変数に対して入力した新しい値が表示されます。

Web ジョブのリモートデバッグ

このセクションでは、Azure WebJobs SDK の概要に関するページで作成したプロジェクトとアプリを使用してリモートでデバッグする方法を示します。

このセクションで示す機能は、Visual Studio 2013 Update 4 以降でのみ使用できます。

リモートデバッグは、継続的な Web ジョブでのみ動作します。スケジュールされたオンデマンドの Web ジョブでは、デバッグはサポートされていません。

Azure Web ジョブ SDK の使用に関するページで作成した Web プロジェクトを開きます。
ContosoAdsWebJob プロジェクトで、 Functions.csを開きます。
GenerateThumbnail メソッドの最初のステートメントにブレークポイントを設定します。
ソリューションエクスプローラーで Web プロジェクト (Web ジョブプロジェクトではない) を右クリックし、 [発行] をクリックします。
[プロファイル] ボックスの一覧から、「 Azure Web ジョブ SDK の使用」で使用したものと同じプロファイルを選択します。
[設定] タブをクリックして [構成] を [デバッグ] に変更し、 [発行] をクリックします。

Visual Studio によって Web プロジェクトと Web ジョブプロジェクトがデプロイされ、ブラウザーでアプリの Azure URL が表示されます。
サーバーエクスプローラーで、[Azure] > [App Service] > 使用するリソースグループ > 使用するアプリ > [Web ジョブ] > [継続] の順に展開し、[ContosoAdsWebJob] を右クリックします。
[デバッガーの接続] をクリックします。

ブラウザーが自動的に起動し、Azure で実行されているホームページが表示されます。デバッグに必要な設定を Azure がサーバーに対して行う間、20 秒ほどの待ち時間が生じることがあります。この待ち時間が生じるのは、48 時間以内にアプリでのデバッグモードを実行する初回に限られます。同じ期間に再度デバッグを開始しても、遅延はありません。
Contoso Ads ホームページを表示している Web ブラウザーで、新しい広告を作成します。

広告を作成すると、キューメッセージが作成されます。キューメッセージは Web ジョブによって取得され、処理されます。 Web ジョブ SDK がキューメッセージを処理する関数を呼び出すと、コードがブレークポイントにヒットします。
デバッガーがブレークポイントで停止すると、プログラムがクラウドを実行している間に、変数の値を確認、変更することができます。次の図では、デバッガーは、GenerateThumbnail メソッドに渡された blobInfo オブジェクトの内容を示しています。
F5 キーを押して実行を継続します。

GenerateThumbnail メソッドはサムネイルの作成を完了します。
ブラウザーで、[インデックス] ページを更新して、サムネイルを表示します。
Visual Studio で、Shift キーを押しながら F5 キーを押すと、デバッグは停止します。
サーバーエクスプローラーで、ContosoAdsWebJob ノードを右クリックし、 [ダッシュボードの表示] をクリックします。
Azure の資格情報を使用してサインインし、Web ジョブ名をクリックして、Web ジョブのページに移動します。

GenerateThumbnail 関数が最近実行されたことが、ダッシュボードに示されます。

(次回、 [ダッシュボードの表示] をクリックするときには、サインインする必要はありません。ブラウザーが Web ジョブのページに直接移動します。)
関数名をクリックすると、関数の実行について詳細が表示されます。

関数がログを書き込んだ場合は、 [ToggleOutput] をクリックするとログを表示できます。

リモートデバッグに関する注意

運用環境におけるデバッグモードの実行はお勧めできません。運用環境のアプリが複数のサーバーインスタンスにスケールアウトされていない場合、デバッグを行うと、Web サーバーが他の要求に応答できなくなります。しかし、Web サーバーのインスタンスが複数存在する場合、デバッガーのアタッチ先となるインスタンスは無作為に決定されるため、同じインスタンスに後続のブラウザーの要求を確実に渡すことができません。また、運用環境にデバッグビルドをデプロイすることも一般的ではありません。リリースビルドに対してはコンパイラが最適化を行うため、ソースコードの状況を行レベルで把握することは不可能です。運用環境の問題をトラブルシューティングするのに最も適しているリソースは、アプリケーショントレースと Web サーバーのログです。
リモートデバッグ時、ブレークポイントで長時間停止させることは避けてください。数分以上停止しているプロセスは、応答していないプロセスと見なされ、Azure によりシャットダウンされます。
デバッグ中は、サーバーから Visual Studio にデータが送信されるため、帯域幅の使用料に影響が及ぶ可能性があります。帯域幅使用料については、 Azure 料金計算ツールを参照してください。
Web.config ファイルの compilation 要素の debug 属性が true に設定されていることを確認します。デバッグビルド構成で発行するときは、true が既定値です。
```
<system.web>
  <compilation debug="true" targetFramework="4.5" />
  <httpRuntime targetFramework="4.5" />
</system.web>
```
デバッグ対象となるコードにデバッガーがステップインしない場合、[マイコードのみ] の設定を変更してみてください。詳しくは、「Specify whether to debug only user code using Just My Code in Visual Studio (Visual Studio で [マイコードのみ] を使用してユーザーコードのみをデバッグするかどうかを指定する)」をご覧ください。
リモートデバッグ機能を有効にしたときに、サーバー上でタイマーが開始され、48 時間後にこの機能が自動的に無効になります。この 48 時間の上限はセキュリティとパフォーマンス上の理由で設定されています。必要に応じて、この機能を何回でも簡単に有効に戻すことができます。積極的にデバッグを実行している場合以外は、この機能を無効にしたままにすることをお勧めします。
手動でデバッガーをアプリプロセス (w3wp.exe) だけでなく、任意のプロセスに接続できます。 Visual Studio のデバッグモードの使い方の詳細については、MSDN のトピック「 Visual Studio でのデバッグ」を参照してください。

診断ログの概要

App Service アプリで実行される ASP.NET アプリケーションは、次の種類のログを作成できます。

アプリケーショントレースログ
アプリケーションが System.Diagnostics.Trace クラスのメソッドを呼び出すことによって作成されます。
Web サーバーログ
Web サーバーは、アプリに届くすべての HTTP 要求について、それぞれログエントリを作成します。
詳細なエラーメッセージログ
失敗した HTTP 要求 (状態コード 400 以上の要求) について、より詳しい情報を記した HTML ページが Web サーバーによって作成されます。
失敗した要求トレースログ
失敗した HTTP 要求についての詳しいトレース情報を記録した XML ファイルが Web サーバーによって作成されます。また、ブラウザーで XML の体裁を設定するための XSL ファイルも作成されます。

ログ出力はアプリのパフォーマンスに影響を及ぼすため、Azure では、必要に応じてログの種類ごとにその有効と無効を切り替えることができるようになっています。アプリケーションログについては、特定の重大度レベルを超えるログだけを記録するように指定できます。新しいアプリを作成した時点ではすべてのログが既定で無効になります。

ログは、アプリのファイルシステムにあり、FTP 経由でアクセス可能な LogFiles フォルダー内のファイルに書き込まれます。 Web サーバーのログとアプリケーションのログは、Azure のストレージアカウントに出力することもできます。ストレージアカウントには、ファイルシステムよりも大量のログを保持することができます。ファイルシステムを使用した場合、保存できるログの上限は 100 MB です。 (ファイルシステムのログは、短期間のみ保持されます。上限に達すると、古いログファイルは削除され、新しいログファイルのための領域が確保されます。)

アプリケーションのトレースログの作成と表示

このセクションでは、次のタスクを実行します。

Azure と ASP.NET の使用に関するページで作成した Web プロジェクトに、トレースステートメントを追加します。
プロジェクトをローカル実行したときのログを確認します。
Azure で実行中のアプリケーションによって生成されたログを確認します。

Web ジョブでアプリケーションログを作成する方法については、「 Web ジョブ SDK を使用して Azure キューストレージを操作する方法 - ログの記述方法」を参照してください。ログの表示とログを Azure に格納する方法の制御に関する次の手順は、Web ジョブによって作成されたアプリケーションログにも適用されます。

アプリケーションへのトレースステートメントの追加

System.Diagnostics の Trace ステートメントと using ステートメントを追加するために、Controllers\HomeController.cs を開き、Index、About、Contact のメソッドを次のコードで置き換えます。

public ActionResult Index()
{
    Trace.WriteLine("Entering Index method");
    ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";
    Trace.TraceInformation("Displaying the Index page at " + DateTime.Now.ToLongTimeString());
    Trace.WriteLine("Leaving Index method");
    return View();
}

public ActionResult About()
{
    Trace.WriteLine("Entering About method");
    ViewBag.Message = "Your app description page.";
    Trace.TraceWarning("Transient error on the About page at " + DateTime.Now.ToShortTimeString());
    Trace.WriteLine("Leaving About method");
    return View();
}

public ActionResult Contact()
{
    Trace.WriteLine("Entering Contact method");
    ViewBag.Message = "Your contact page.";
    Trace.TraceError("Fatal error on the Contact page at " + DateTime.Now.ToLongTimeString());
    Trace.WriteLine("Leaving Contact method");
    return View();
}

using System.Diagnostics; ステートメントをファイルの先頭に追加します。

ローカルでのトレース出力の表示

F5 キーを押してデバッグモードでアプリケーションを実行します。

既定のトレースリスナーは、すべてのトレース出力を他のデバッグ出力と一緒に出力ウィンドウに書き込みます。次の図は、 Index メソッドに追加したトレースステートメントからの出力結果を示したものです。

以降の手順では、コンパイルせずにデバッグモードで、トレース出力を Web ページに表示する方法を紹介します。

プロジェクトフォルダーにあるアプリケーションの Web.config ファイルを開き、ファイル末尾の終了 </configuration> 要素の直前に <system.diagnostics> 要素を追加します。

<system.diagnostics>
<trace>
  <listeners>
    <add name="WebPageTraceListener"
        type="System.Web.WebPageTraceListener,
        System.Web,
        Version=4.0.0.0,
        Culture=neutral,
        PublicKeyToken=b03f5f7f11d50a3a" />
  </listeners>
</trace>
</system.diagnostics>

WebPageTraceListener を使用すると、ブラウザーから /trace.axd にアクセスすることでトレース出力を表示できます。

Web.config ファイルの <system.web> に、次のような trace 要素を追加します。

<trace enabled="true" writeToDiagnosticsTrace="true" mostRecent="true" pageOutput="false" />

Ctrl キーを押しながら F5 キーを押してアプリケーションを実行します。
ブラウザーウィンドウのアドレスバーで、URL に続けて「trace.axd」と入力し、Enter キーを押します (例: http://localhost:53370/trace.axd)。
[アプリケーショントレース] ページの最初の行 (BrowserLink の行とは異なる) で、 [詳細の表示] をクリックします。

[要求の詳細] ページが表示され、Index メソッドに追加したトレースステートメントからの出力が [トレース情報] セクションに表示されます。

既定では、trace.axd の使用はローカルに限られます。 Web.config ファイルで trace 要素に localOnly="false" を追加すると、リモートアプリからも利用できるようになります。その例を次に示します。
```
<trace enabled="true" writeToDiagnosticsTrace="true" localOnly="false" mostRecent="true" pageOutput="false" />
```
ただし、運用アプリで trace.axd を有効にすることはセキュリティ上の理由でお勧めできません。次のセクションでは、App Service アプリでトレースログを読み取る簡単な方法を示します。

Azure でのトレース出力の確認

ソリューションエクスプローラーで Web プロジェクトを右クリックし、 [発行] をクリックします。
[Web の発行] ダイアログボックスの [発行] をクリックします。

更新したプロジェクトを発行すると、ブラウザーウィンドウが起動して自分のホームページが表示されます (ただし、 [接続] タブの [宛先 URL] をクリアした場合を除く)。
サーバーエクスプローラーでアプリを右クリックし、 [ストリーミングログの表示] を選択します。

ログストリーミングサービスに接続されたことを示すメッセージが出力ウィンドウに表示されます。ログが出力されないまま 1 分が経過すると、その都度、1 行の通知が追加されます。
アプリケーションのホームページが表示されているブラウザーウィンドウで、 [Contact] をクリックします。

数秒すると、Contact メソッドに追加したエラーレベルのトレースが出力ウィンドウに表示されます。

Visual Studio にエラーレベルのトレースしか表示されていないのは、それが、ログ監視サービスを有効にしたときの既定の設定であるためです。先ほどの設定ページを開いたときに見たように、新しい App Service アプリを作成したときは、すべてのログが既定で無効となります。

ただし、 [ストリーミングログを表示] を選択すると、 [アプリケーションログ記録 (ファイルシステム)] が自動的に [エラー] に変更されます。これは、エラーレベルのログが報告されることを意味します。すべてのトレースログを表示するためには、この設定を [詳細] に変更する必要があります。 "エラー" よりも低い重大度レベルを選択すると、その重大度を超えるログがすべて報告されます。つまり [詳細] を選択した場合は、"情報"、"警告"、"エラー" に該当するログが表示されます。
先ほどと同じように、サーバーエクスプローラーでアプリを右クリックし、 [表示の設定] をクリックします。
[アプリケーションログ記録 (ファイルシステム)] を [詳細] に変更し、 [保存] をクリックします。
[連絡先] ページが表示されているブラウザーウィンドウで、 [ホーム] 、 [バージョン情報] 、 [連絡先] を順にクリックします。

数秒すると、出力ウィンドウにすべてのトレース出力が表示されます。

このセクションでは、ログの有効と無効の切り替えをアプリの設定で行いました。トレースリスナーの有効と無効は、Web.config ファイルで設定することもできます。ただし、Web.config ファイルに変更を加えると、アプリケーションドメインの再利用処理が実行されます。一方、アプリの構成を介してログを有効にした場合は、そのようにはなりません。問題の再現に時間がかかる場合や、発生のタイミングが散発的である場合、アプリケーションドメインの再利用処理で問題が "解消" し、再発までしばらく待たなければならなくなります。 Azure で診断を有効にすると、アプリケーションドメインの再利用処理は行われず、すぐにエラー情報を収集することができます。

出力ウィンドウの機能

出力ウィンドウの [Microsoft Azure ログ] タブには、いくつかのボタンと 1 つのテキストボックスが表示されます。

Screenshot showing the buttons and text box of the Microsoft Azure Logs tab in the Output window.

それぞれの機能を次に示します。

出力ウィンドウをクリアする。
右端での折り返しを有効または無効にする。
ログの監視を開始または停止する。
監視するログを指定する。
ログをダウンロードする。
検索文字列または正規表現によるフィルターをログに適用する。
出力ウィンドウを閉じる。

検索文字列または正規表現を入力した場合、ログ情報は、Visual Studio によってクライアント側でフィルタリングされます。つまり、フィルターの条件は、出力ウィンドウにログが表示された後に入力できます。フィルターの条件を変更するためにログを生成し直す必要はありません。

Web サーバーのログの表示

Web サーバーのログには、アプリの HTTP アクティビティがすべて記録されます。それらの HTTP 要求を出力ウィンドウに表示するには、アプリに対してその機能を有効にしたうえで、HTTP 要求を監視するための指定を Visual Studio に対して行う必要があります。

サーバーエクスプローラーから開いた Azure Web アプリの [構成] タブで [Web サーバーのログ記録] を [オン] に変更し、 [保存] をクリックします。
出力ウィンドウの [監視する Microsoft Azure ログを指定する] をクリックします。
[Microsoft Azure ログオプション] ダイアログボックスの [Web サーバーのログ] を選択し、 [OK] をクリックします。
アプリを表示するブラウザーウィンドウで、 [ホーム] 、 [バージョン情報] 、 [連絡先] の順にクリックします。

通常はアプリケーションのログが先に表示され、続けて Web サーバーのログが表示されます。ログが表示されるまでにしばらく時間がかかる場合があります。

Visual Studio で Web サーバーのログを初めて有効にしたとき、既定では、Azure によってファイルシステムにログが書き込まれます。代わりに、Azure ポータルを使用して、Web サーバーのログの書き込み先として、ストレージアカウントの BLOB コンテナーを指定することもできます。

Azure ポータルを使用して、Azure ストレージアカウントへの Web サーバーのログ記録を有効にした後、Visual Studio でログ記録を無効にした場合、Visual Studio でログ記録を再度有効にすると、ストレージアカウントの設定が復元されます。

詳細なエラーメッセージログの表示

詳細なエラーログでは、エラー応答コード (400 以上) が返された HTTP 要求について、いくつかの詳しい情報が確認できます。それらの HTTP 要求を出力ウィンドウに表示するには、アプリに対してその機能を有効にしたうえで、HTTP 要求を監視するための指定を Visual Studio に対して行う必要があります。

サーバーエクスプローラーから開いた Azure Web アプリの [構成] タブで [詳細なエラーメッセージ] を [オン] に変更し、 [保存] をクリックします。
出力ウィンドウの [監視する Microsoft Azure ログを指定する] をクリックします。
[Microsoft Azure ログオプション] ダイアログボックスの [すべてのログ] を選択し、 [OK] をクリックします。
ブラウザーウィンドウのアドレスバーで、404 エラーの原因となるような余分な文字を URL に追加し (例: http://localhost:53370/Home/Contactx)、Enter キーを押します。

数秒後、Visual Studio の出力ウィンドウに詳細なエラーログが表示されます。

Ctrl キーを押しながらリンクをクリックすると、次のような書式化されたログ出力がブラウザーに表示されます。

ファイルシステムのログのダウンロード

出力ウィンドウで監視できるすべてのログは .zip ファイルとしてダウンロードすることもできます。

出力ウィンドウの [ストリーミングログのダウンロード] をクリックします。

エクスプローラーが起動して [ダウンロード] フォルダーが開き、ダウンロード済みのファイルが選択状態で表示されます。
この .zip ファイルを展開すると、次のフォルダー構造が確認できます。
- アプリケーショントレースログは、LogFiles\Application フォルダーの .txt ファイルに記録されます。
- Web サーバーのログは、LogFiles\http\RawLogs フォルダーの .log ファイルに記録されます。これらのファイルの閲覧と操作は、 Log Parser などのツールを使って行うことができます。
- 詳細なエラーメッセージのログは、LogFiles\DetailedErrors フォルダーの .html ファイルに記録されます。
  
  (deployments フォルダーは、ソース管理の発行によって作成されたファイルに使用されます。Visual Studio の発行に関連したファイルは保存されません。Git フォルダーは、ログファイルストリーミングサービスやソース管理の発行に関連したトレースに使用されます。)

失敗した要求トレースログの表示

失敗した要求トレースログは、URL の書き換えや認証の問題など、IIS による HTTP 要求の処理を詳しく把握する必要がある状況で活用できます。

App Service アプリでは、同じ失敗した要求トレース機能が使用されています。この機能は、IIS 7.0 以降で利用できます。ただし、ログに記録するエラーを指定するための IIS 設定にアクセスする必要はありません。失敗した要求トレースを有効にすると、すべてのエラーがキャプチャされます。

失敗した要求トレースは Visual Studio を使用して有効にできますが、それらを Visual Studio で表示することはできません。これらのログは XML ファイル形式になっています。ストリーミングログサービスで監視されるのは、プレーンテキストモードでの読み取りが可能と判断されたファイル (.txt、.html、.log の各ファイル) だけです。

失敗した要求トレースログは、ブラウザーから FTP で直接表示できるほか、FTP ツールを使ってローカルコンピューターにダウンロードした後、ローカルで表示することもできます。このセクションでは、ブラウザーで直接閲覧する方法を説明します。

サーバーエクスプローラーから開いた [Azure Web アプリ] ウィンドウの [構成] タブで、 [失敗した要求トレース] を [オン] に変更し、 [保存] をクリックします。
アプリが表示されているブラウザーウィンドウのアドレスバーで、余分な文字を URL に追加し、Enter キーを押して 404 エラーを発生させます。

これにより、失敗した要求トレースログが作成されます。そのログを表示またはダウンロードする方法については、以降の手順で説明します。
Visual Studio で、 [Azure Web アプリ] ウィンドウの [構成] タブにある [管理ポータルで開く] をクリックします。
Azure portal のアプリの [設定] ページで [デプロイ資格情報] をクリックし、新しいユーザー名とパスワードを入力します。

Note

ログインするときは、完全なユーザー名とそのアプリ名プレフィックスを使用する必要があります。たとえば、ユーザー名として「myid」と入力し、サイトが "myexample" の場合、"myexample\myid" としてログインします。
新しいブラウザーウィンドウで、アプリの [概要] ページの [FTP ホスト名] または [FTPS ホスト名] に表示されている URL に移動します。
先ほど作成した FTP 資格情報を使用してサインインします (ユーザー名のアプリ名プレフィックスを含めること)。

アプリのルートフォルダーがブラウザーに表示されます。
LogFiles フォルダーを開きます。
W3SVC に数値の付いた名前のフォルダーを開きます。

このフォルダーには、失敗した要求トレースを有効にした後で記録されたすべてのエラーの XML ファイルに加え、ブラウザーで XML の体裁を設定するための XSL ファイルが格納されています。
トレース情報を確認する失敗した要求の XML ファイルをクリックします。

次の図は、サンプルエラーのトレース情報を部分的に示したものです。

次のステップ

App Service アプリで作成されたログは Visual Studio を使って簡単に参照できることが確認できました。次のセクションでは、関連トピックに関する他のリソースへのリンクを紹介します。

App Service のトラブルシューティング
Visual Studio でのデバッグ
Azure でのリモートデバッグ
ASP.NET アプリケーションでのトレース
Web サーバーのログの分析
失敗した要求トレースログの分析
Cloud Services のデバッグ

App Service のトラブルシューティング

Azure App Service のアプリのトラブルシューティングの詳細については、以下のリソースを参照してください。

How to monitor apps (アプリの監視方法)
Investigating Memory Leaks in Azure App Service with Visual Studio 2013 (Visual Studio 2013 を使用した Azure App Service でのメモリリークの調査)。マネージドメモリの問題の分析に役立つ Visual Studio の機能に関する Microsoft ALM のブログ記事
Azure App Service online tools you should know about (知っておくべき Azure App Service のオンラインツール)。 Amit Apple によるブログの投稿です。

具体的なトラブルシューティングについての質問は、次のいずれかのフォーラムで投稿してください。

Visual Studio でのデバッグ

Visual Studio のデバッグモードの使い方については、「Visual Studio でのデバッグ」と Visual Studio 2010 でのデバッグのヒントに関するページを参照してください。

Azure でのリモートデバッグ

App Service アプリと WebJobs のリモートデバッグの詳細については、以下のリソースを参照してください。

アプリで Azure Web API または Mobile Services バックエンドを使用し、デバッグを実行する必要がある場合は、Visual Studio での .NET のデバッグに関するページを参照してください。

ASP.NET アプリケーションでのトレース

ASP.NET トレースに関しては、最新かつ必要な情報をすべて網羅した解説がインターネットには存在しません。そのため、過去に作成された入門者向けの資料を参考にするのが最善の方法となります。MVC がまだ存在していなかったために Web フォームを想定して書かれていますが、具体的な問題については、最新のブログで情報を補うことができます。たとえば、以下のリソースが参考になります。

監視と利用統計情報 (Azure での実際のクラウドアプリケーションのビルド) に関するページ。
Azure クラウドアプリケーションをトレースするためのベストプラクティスを掲載した E-Book の章。
ASP.NET トレース
最新とは言えませんが、基本的な事柄がわかりやすくまとめられています。
トレースリスナー
トレースリスナーについて書かれていますが、WebPageTraceListener には触れていません。
チュートリアル:Integrating ASP.NET Tracing with System.Diagnostics Tracing (ASP.NET トレースと System.Diagnostics トレースの統合)
この記事も古い情報ですが、入門記事では扱っていないような詳しい情報が記載されています。
ASP.NET MVC Razor ビューでのトレース
Razor ビューでのトレースに加え、MVC アプリケーションでハンドルされない例外をすべてログに記録するためのエラーフィルターの作成方法についても説明されています。 Web フォームアプリケーションで、ハンドルされない例外をすべてログに記録する方法については、MSDN の「エラーハンドラーの完全なコード例」で紹介されている Global.asax サンプルを参照してください。 MVC または Web フォームで、特定の例外をログに記録すると共に、既定のフレームワークの処理はそのまま活かしておく必要がある場合、例外を捕捉してから再スローする方法を利用できます。その例を次に示します。
```
try
{
   // Your code that might cause an exception to be thrown.
}
catch (Exception ex)
{
    Trace.TraceError("Exception: " + ex.ToString());
    throw;
}
```
Azure コマンドラインからの診断トレースログのストリーミングと Glimpse に関する情報
このチュートリアルで Visual Studio を使って行ったことをコマンドラインで行う方法が解説されています。 Glimpse は、ASP.NET アプリケーションをデバッグするためのツールです。
Web Apps のログと診断の使用に関するページ - David Ebbo 作成、および Web Apps からのログのストリーミングに関するページ - David Ebbo 作成
Scott Hanselman と David Ebbo によるビデオ。

エラーをログに記録する方法としては、独自のトレースコードを記述する以外にも、 ELMAHのようなオープンソースのログ記録フレームワークを使う方法があります。詳細については、 Scott Hanselman が ELMAH についてまとめたブログ記事を参照してください。

さらに、ASP.NET または System.Diagnostics トレースを使用して、Azure からストリーミングログを取得する必要はありません。 App Service アプリのストリーミングログサービスは、LogFiles フォルダーに見つかったすべての .txt ファイル、 .html ファイル、 .log ファイルをストリーミングします。したがって、アプリのファイルシステムに書き込む独自のログ記録システムを作成することもできます。必要なファイルが自動的にストリーミングされ、ダウンロードされます。必要な作業は、d:\home\logfiles フォルダーにファイルを作成するアプリケーションコードを記述するだけです。

Web サーバーのログの分析

Web サーバーのログの分析の詳細については、次のリソースを参照してください。

LogParser
Web サーバーのログ ( .log ファイル) に記録されているデータを表示するためのツールです。
IIS のパフォーマンスの問題やアプリケーションエラーを LogParser でトラブルシューティングする
Web サーバーのログを分析する際に活用できる Log Parser ツールについて基本的な事柄が説明されています。
LogParser の使用に関して Robert McMurray が執筆したブログ記事
IIS 7.0、IIS 7.5、IIS 8.0 における HTTP 状態コード

失敗した要求トレースログの分析

失敗した要求トレースログの活用方法については、Microsoft TechNet Web サイトの「Using Failed Request Tracing」 (失敗した要求トレースの使用) セクションなどが参考になります。ただし、このドキュメントで扱う内容は、失敗した要求トレースを IIS で構成する作業が主体です。この作業を Azure App Service で行うことはできません。

Visual Studio を使用した Azure App Service のアプリのトラブルシューティング

概要

前提条件

アプリの構成と管理

サーバー エクスプローラーでのアプリ ファイルへのアクセス

アプリのリモート デバッグ

Web ジョブのリモート デバッグ

リモート デバッグに関する注意