Application Insights 可用性テスト

[アーティクル]
10/15/2024

Application Insights を使うと、世界中のさまざまな場所から Web サイトまたはアプリケーションの可用性と応答性を監視する定期的な Web テストを設定できます。これらの可用性テストは、一定の間隔で Web 要求をアプリケーションに送信し、アプリケーションが応答していない場合や応答時間が遅すぎる場合はユーザーに警告します。

可用性テストのために、テスト対象の Web サイトまたはアプリケーションを変更する必要はありません。パブリックインターネットからアクセスできる任意の HTTP または HTTPS エンドポイント (サービスが依存する REST API を含む) に対して機能します。つまり、独自のアプリケーションだけでなく、アプリケーションの機能に不可欠な外部サービスも監視できます。 Application Insights リソースごとに最大 100 個の可用性テストを作成できます。

注意

可用性テストは、保存時の Azure データ暗号化ポリシーに従って暗号化されて格納されます。

可用性テストの種類

可用性テストには、次の 4 種類があります。

標準テスト: 非推奨の URL ping テストと同様に、1 つの要求を送信して Web サイトの可用性をチェックする可用性テストの種類。標準テストには、エンドポイントが応答し、パフォーマンスを測定しているかどうかの検証に加え、TLS/SSL 証明書の有効性、プロアクティブな有効期間チェック、HTTP 要求動詞 (GET、HEAD、POST など)、カスタムヘッダー、HTTP 要求に関連付けられたカスタムデータなども含まれます。

標準テストを作成する方法を学習する。
カスタム TrackAvailability テスト: 可用性テストを実行するカスタムアプリケーションを作成することにした場合、TrackAvailability() メソッドを使用して、結果を Application Insights に送信できます。

カスタム TrackAvailability テストを作成する方法を学習する。
(非推奨) 複数ステップの Web テスト: この一連の Web 要求の記録を再生して、より複雑なシナリオをテストできます。複数ステップ Web テストは Visual Studio Enterprise で作成され、ポータルにアップロードされ、ここでそれらを実行できます。
(非推奨) URL ping テスト: Azure portal を使用してこのテストを作成して、エンドポイントが応答しているかどうかを検証し、その応答に関連するパフォーマンスを測定できます。また、依存する要求の解析などの高度な機能と結合されたカスタム成功基準を設定し、再試行が可能になります。

重要

今後、可用性テストが 2 つ提供終了になる予定です。

マルチステップ Web テスト: 2024 年 8 月 31 日、Application Insights のマルチステップ Web テストは廃止されます。これらのテストをご利用の場合、提供終了日より前に、代替可用性テストに移行することをお勧めします。この日付が過ぎると、基礎インフラストラクチャが撤去され、残りのマルチステップテストが中断されます。
URL ping テスト: 2026 年 9 月 30 日、Application Insights の URL ping テストは廃止されます。既存の URL ping テストはリソースから削除されます。標準テストの価格と、その利用への切り替えを 2026 年 9 月 30 日より前に確認して、Application Insights リソースでシングルステップの可用性テストを引き続き実行できるようにします。

前提条件

ワークスペースベースの Application Insights リソース

作業の開始

Application Insights リソースに移動して、[可用性] エクスペリエンスを開きます。
上部のナビゲーションバーで [標準テストの追加] を選びます。

テスト名、URL、次の表で説明されているその他の設定を入力して、[作成] を選びます。

セクション	設定	説明
基本情報
	URL	[URL] は、テストする任意の Web ページにすることができますが、パブリックインターネットから表示できる必要があります。 URL にはクエリ文字列を含めることができます。したがって、たとえば限られた範囲でデータベースを実行できます。 URL が解決されてリダイレクトする場合、それに続いて最大で 10 個リダイレクトを使用できます。
	依存する要求の解析	テストでは、テスト対象の Web ページの一部である画像、スクリプト、スタイルファイル、およびその他のファイルが要求されます。記録される応答時間には、これらのファイルの取得にかかる時間が含まれます。テスト全体のタイムアウト時間内にこれらすべてのリソースを正常にダウンロードできない場合、テストは失敗します。このオプションが選択されていない場合、テストでは指定した URL にあるファイルのみが要求されます。このオプションを有効にすると、より厳密なチェックが行われます。サイトを手動で参照しているときは気付かない場合があることが原因でテストが失敗する可能性があります。解析される従属要求は最大 15 個だけです。
	可用性テストが失敗した場合の再試行を有効にする	テストが失敗したときは、少し間を置いて再試行します。エラーは試行が 3 回連続で失敗した場合にのみ報告されます。その後、後続のテストが通常のテスト間隔で実行されます。再試行は、次の成功まで一時的に中断されます。このルールがテスト場所ごとに独立して適用されます。このオプションはオンにすることをお勧めします。再試行の際に平均でエラーの約 80% がなくなります。
	SSL 証明書の有効性を有効にする	SSL 証明書が正しくインストールされていること、有効であること、信頼できること、ユーザーにエラーが発生しないことを確認するために、ご自身の Web サイト上で、その SSL 証明書を検証できます。
	プロアクティブな有効期間チェック	この設定により、ご自身の SSL 証明書の有効期限が切れる前に設定期間を定義できます。有効期限が切れた後、テストは失敗します。
	テスト間隔	各テストの場所からテストを実行する頻度を設定します。既定の間隔が 5 分で、テストの場所が 5 か所の場合、サイトは平均して毎分テストされます。
	テストの場所	サーバーはこれらの場所から指定の URL に Web 要求を送信します。 Web サイトの問題とネットワークの問題とを確実に区別するために、テストの場所は 5 か所以上にすることをお勧めします。最大 16 個の場所を選択できます。
標準テストの情報
	HTTP 要求動詞	要求に対して実行するアクションを示します。
	要求本文	ご自身の HTTP 要求に関連付けられているカスタムデータ。独自のファイルをアップロードしたり、コンテンツを入力したり、この機能を無効にしたりできます。
	カスタムヘッダーの追加	操作パラメーターを定義するキーと値のペア。
成功の基準
	テストのタイムアウト	この値を引き下げると、応答が遅い場合に警告されます。この期間内にサイトから応答が返されない場合、テストはエラーとしてカウントされます。 [従属要求の解析] をオンにした場合は、すべての画像、スタイルファイル、スクリプト、その他の従属リソースを、この期間内に受信する必要があります。
	HTTP 応答	成功としてカウントされる、返される状態コード。番号 200 は通常の Web ページが返されたことを示すコードです。
	コンテンツの一致	"Welcome!" などの文字列。それぞれの応答内に、大文字と小文字を区別した完全一致があるかどうかをテストします。文字列は、(ワイルドカードを含まない) プレーン文字列である必要があります。ページコンテンツが変更された場合は、この文字列の更新が必要になる可能性があることに注意してください。コンテンツの一致では、英字のみがサポートされています。

重要

TrackAvailability() では、複雑なカスタムコードの作成とメンテナンスに開発者の投資を行う必要があります。

標準テストは、必要な投資がほとんどなく、メンテナンス不要で前提条件も少ないため、可能な場合は常に使用する必要があります。

この例は、Azure Functions アプリ内で TrackAvailability() API 呼び出しが機能する仕組みを示すためだけに設計されています。この例を完全に機能する可用性テストにするために必要な、基になる HTTP テストコードまたはビジネスロジックを記述する方法は示されていません。

前提条件

ワークスペースベースの Application Insights リソース
Azure Functions アプリのソースコードへのアクセス
特定のビジネスニーズに合わせて調整された TrackAvailability() 用のカスタムコードを作成するための開発者の専門知識

作業の開始

Note

これらの手順に従って行うには、App Service プランまたは Functions Premium プランを使い、App Service Editor でのコードの編集を許可する必要があります。

仮想ネットワークの内側でテストする場合、またはパブリックではないエンドポイントをテストする場合は、Functions Premium プランを使う必要があります。

タイマートリガー関数を作成する

次のことを考慮して、Azure Functions リソースを作成します。
- タイマーによってトリガーされる関数用の Application Insights リソースがまだない場合は、Azure Functions アプリの作成時に "既定で" 作成されます。
- Application Insights リソースが既にある場合は、Azure Functions アプリの作成時に [監視] タブに移動し、Application Insights のドロップダウンで既存のリソースの名前を選択または入力します。
手順に従って、タイマーによってトリガーされる関数を作成します。

App Service Editor でコードを追加して編集する

デプロイされた Azure Functions アプリに移動し、[開発ツール] で [App Service Editor] タブを選びます。

新しいファイルを作成するには、タイマートリガー関数の下 (たとえば TimerTrigger1) を右クリックし、[新しいファイル] を選択します。次に、ファイルの名前を入力し、Enter を押します。

function.proj という新しいファイルを作成し、次のコードを貼り付けます。

<Project Sdk="Microsoft.NET.Sdk"> 
    <PropertyGroup> 
        <TargetFramework>netstandard2.0</TargetFramework> 
    </PropertyGroup> 
    <ItemGroup> 
        <PackageReference Include="Microsoft.ApplicationInsights" Version="2.15.0" /> <!-- Ensure you’re using the latest version --> 
    </ItemGroup> 
</Project>

runAvailabilityTest.csx という新しいファイルを作成し、次のコードを貼り付けます。

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 
    } 
}

run.csx の既存のコードを、次のように置き換えます。

#load "runAvailabilityTest.csx" 

using System; 

using System.Diagnostics; 

using Microsoft.ApplicationInsights; 

using Microsoft.ApplicationInsights.Channel; 

using Microsoft.ApplicationInsights.DataContracts; 

using Microsoft.ApplicationInsights.Extensibility; 

private static TelemetryClient telemetryClient; 

// ============================================================= 

// ****************** DO NOT MODIFY THIS FILE ****************** 

// Business logic must be implemented in RunAvailabilityTestAsync function in runAvailabilityTest.csx 

// If this file does not exist, add it first 

// ============================================================= 

public async static Task Run(TimerInfo myTimer, ILogger log, ExecutionContext executionContext) 

{ 
    if (telemetryClient == null) 
    { 
        // Initializing a telemetry configuration for Application Insights based on connection string 

        var telemetryConfiguration = new TelemetryConfiguration(); 
        telemetryConfiguration.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING"); 
        telemetryConfiguration.TelemetryChannel = new InMemoryChannel(); 
        telemetryClient = new TelemetryClient(telemetryConfiguration); 
    } 

    string testName = executionContext.FunctionName; 
    string location = Environment.GetEnvironmentVariable("REGION_NAME"); 
    var availability = new AvailabilityTelemetry 
    { 
        Name = testName, 

        RunLocation = location, 

        Success = false, 
    }; 

    availability.Context.Operation.ParentId = Activity.Current.SpanId.ToString(); 
    availability.Context.Operation.Id = Activity.Current.RootId; 
    var stopwatch = new Stopwatch(); 
    stopwatch.Start(); 

    try 
    { 
        using (var activity = new Activity("AvailabilityContext")) 
        { 
            activity.Start(); 
            availability.Id = Activity.Current.SpanId.ToString(); 
            // Run business logic 
            await RunAvailabilityTestAsync(log); 
        } 
        availability.Success = true; 
    } 

    catch (Exception ex) 
    { 
        availability.Message = ex.Message; 
        throw; 
    } 

    finally 
    { 
        stopwatch.Stop(); 
        availability.Duration = stopwatch.Elapsed; 
        availability.Timestamp = DateTimeOffset.UtcNow; 
        telemetryClient.TrackAvailability(availability); 
        telemetryClient.Flush(); 
    } 
}

Note

TrackAvailability() で作成されたテスト名の横には、 [CUSTOM] と表示されます。

2 つの異なるテストが一覧表示された可用性エクスペリエンスを示すスクリーンショット。

可用性のアラート

アラートは既定で自動的に有効になりますが、アラートを完全に構成するには、最初に可用性テストを作成する必要があります。

設定	説明
ほぼリアルタイム	準リアルタイムのアラートを使用することが推奨されます。この種類のアラートの構成は、可用性テストの作成後に実行されます。
アラートの場所のしきい値	少なくとも 3/5 の場所にすることをお勧めします。アラートの場所のしきい値とテストの場所の数の最適な関係は、アラートの場所のしきい値 = テストの場所の数 - 2 です。テストの場所は、少なくとも 5 か所にします。

位置情報の作成タグ

Azure Resource Manager を使って標準テストまたは URL ping テストをデプロイするときに、次の作成タグを地理的位置属性に使用できます。

プロバイダー	[表示名]	作成名
Azure
	オーストラリア東部	emea-au-syd-edge
	ブラジル南部	latam-br-gru-edge
	米国中部	us-fl-mia-edge
	東アジア	apac-hk-hkn-azr
	米国東部	us-va-ash-azr
	フランス南部 (旧名フランス中部)	emea-ch-zrh-edge
	フランス中部	emea-fr-pra-edge
	東日本	apac-jp-kaw-edge
	北ヨーロッパ	emea-gb-db3-azr
	米国中北部	us-il-ch1-azr
	米国中南部	us-tx-sn1-azr
	東南アジア	apac-sg-sin-azr
	英国西部	emea-se-sto-edge
	西ヨーロッパ	emea-nl-ams-azr
	米国西部	us-ca-sjc-azr
	英国南部	emea-ru-msa-edge
Azure Government
	USGov バージニア州	usgov-va-azr
	USGov アリゾナ	usgov-phx-azr
	USGov テキサス	usgov-tx-azr
	USDoD 東部	usgov-ddeast-azr
	USDoD 中部	usgov-ddcentral-azr
21Vianet によって運営される Microsoft Azure
	中国東部	mc-cne-azr
	中国東部 2	mc-cne2-azr
	中国北部	mc-cnn-azr
	中国北部 2	mc-cnn2-azr

アラートを有効にする

Note

新しい統合アラートの場合、アラートルールの重大度と通知の基本設定をアクショングループと一緒に、アラートエクスペリエンスで構成する必要があります。次の手順を行わないと、ポータル内通知を受け取るだけとなります。

可用性テストを保存した後、作成したテストのコンテキストメニューを開いて、[規則 (アラート) ページを開く] を選びます。
[アラートルール] ページでアラートを開き、上部のナビゲーションバーで [編集] を選びます。ここでは、重大度レベル、ルールの説明、このアラートルールに使用する通知の基本設定が含まれるアクショングループを設定できます。

アラートの条件

自動的に有効になる可用性アラートでは、エンドポイントが使用できなくなると 1 つのメールがトリガーされ、再び使用可能になると別のメールがトリガーされます。このエクスペリエンスで作成される可用性アラートは、"状態に基づきます"。アラートの条件が満たされると、Web サイトが使用不可として検出された場合に 1 つのアラートが生成されます。次にアラートの条件が評価されたときに Web サイトがまだダウンしている場合、新しいアラートは生成されません。

たとえば、Web サイトが 1 時間ダウンし、評価頻度が 15 分のメールアラートを設定してあるとします。 Web サイトがダウンしたときのメールと、その Web サイトがオンラインに戻ったときの別のメールのみを受け取ります。 Web サイトがまだ使用できないことを通知するアラートを 15 分ごとに継続的に受け取ることはありません。

アラートの条件を変更する

メンテナンス中など、Web サイトが短時間だけダウンした場合には通知を受け取りたくない場合があります。評価頻度を、予想されるダウンタイムよりも長い値 (最大 15 分) に変更できます。また、アラートの場所のしきい値を大きくすることもできます。そうすると、Web サイトが特定の数のリージョンでダウンしている場合にのみアラートがトリガーされます。

ヒント

スケジュールされたダウンタイムが長い場合は、アラートルールを一時的に非アクティブ化するか、カスタムルールを作成します。そうすれば、ダウンタイムを考慮に入れるためのより多くのオプションが提供されます。

場所のしきい値、集計期間、テストの頻度を変更するには、[アラートルールの編集] ページ (「アラートを有効にする」のステップ 2 を参照) に移動し、条件を選んで [シグナルロジックの構成] ウィンドウを開きます。

カスタムアラートルールを作成する

高度な機能が必要な場合は、[アラート] タブでカスタムのアラートルールを作成できます。[アラートルールの作成(>A)] を選択します。使用可能なシグナルをすべて表示するには、[シグナルの種類] で [メトリック] を選択し、[可用性] を選択します。

カスタムのアラートルールでは、より大きい値を使用できます。集計期間については 6 時間ではなく最大 24 時間、テストの頻度については 15 分ではなく最大 1 時間です。さまざまな演算子、集計の種類、しきい値を選択することで、ロジックを詳細に定義するためのオプションも追加されます。

Y 箇所中 X 箇所で障害が報告された場合にアラートを生成する: 新しい可用性テストを作成するとき、新しい統合アラートエクスペリエンスでは Y 箇所中 X 箇所のアラートルールが既定で有効になります。オプトアウトするには、"クラシック" オプションを選択するか、またはアラートルールを無効にすることを選択します。前述の手順に従って、アラートがトリガーされたときに通知を受信するようにアクショングループを構成します。このステップを行わないと、ルールがトリガーされたときにポータル内通知のみを受け取ります。
可用性メトリックに関するアラート: 新しい統合アラートを使用すると、セグメント化された可用性の集計メトリックおよびテスト継続期間メトリックに関してもアラートを生成できます。
1. [メトリック] エクスペリエンス内で Application Insights リソースを選択し、[可用性] メトリックを選択します。
2. メニューから [アラートを構成する] オプションを選択すると、新しいエクスペリエンスが表示され、アラートルールの設定対象とする特定のテストまたは場所を選択できます。ここでは、このアラートルールに対してアクショングループを構成することもできます。
カスタム分析クエリに関するアラート: 新しい統合アラートを使用すると、カスタムログクエリに関するアラートを生成できます。カスタムクエリを使用すると、可用性の問題を示す最も確かなシグナルを取得するのに役立つ任意の条件に基づいてアラートを生成することができます。また、これは TrackAvailability SDK を使用してカスタムの可用性の結果を送信する場合にも当てはまります。

可用性データに関するメトリックにはカスタムの可用性の結果が含まれます。これは、TrackAvailability SDK を呼び出すことによって送信できます。メトリックに関するアラートのサポートを使用することにより、カスタムの可用性の結果に関するアラートを生成することができます。

アラートを自動化する

Azure Resource Manager テンプレートを使用してこのプロセスを自動化する方法については、Azure Resource Manager テンプレートを使用したメトリックアラートの作成に関するページを参照してください。

可用性テストの結果を表示する

このセクションでは、Azure portal で可用性テストの結果を確認し、Log Analytics を使用してデータにクエリを実行する方法について説明します。可用性テストの結果は、折れ線グラフと散布図の両方で視覚化できます。

可用性を確認する

最初に、Azure portal の [可用性] エクスペリエンスでグラフを確認します。

既定では、[可用性] エクスペリエンスには折れ線グラフが表示されます。診断テストのステップの詳細が含まれるテスト結果のサンプルを表示するには、ビューを [散布図] (グラフの上の切り替え) に変更します。テストエンジンは、失敗したテストの診断の詳細を格納します。成功したテストの場合、診断の詳細は実行のサブセットに対して格納されます。テスト、テスト名、場所を表示するには、緑色の点または赤い十字をマウスでポイントします。

特定のテストまたは場所を選択します。または期間を短くして、目的の期間に関するより詳細な結果を表示できます。検索エクスプローラーを使用して、すべての実行の結果を表示します。または Log Analytics クエリを使用して、このデータに対してカスタムレポートを実行できます。

エンドツーエンドのトランザクションの詳細を表示するには、[詳細の表示] で [成功] または [失敗] を選択します。次に、サンプルを選択します。グラフでデータポイントを選択することにより、エンドツーエンドのトランザクションの詳細も取得できます。

サンプルの可用性テストの選択を示すスクリーンショット。

テストを調べて編集する

テストの編集、一時的な無効化、または削除を行うには、テストのコンテキストメニュー (省略記号) を開いて、[編集] を選びます。変更を行った後、すべてのテストエージェントに構成の変更が反映されるまで、最大 20 分かかる場合があります。

ヒント

サービスに対するメンテナンスを実行している間、関連付けられた可用性テストまたはアラートルールを無効にすることもできます。

エラーが発生した場合

散布図上の赤い十字を選んで、[エンドツーエンドトランザクションの詳細] ビューを開きます。

ここで、次のことを行うことができます。

[トラブルシューティングレポート] を調べて、テストが失敗する原因になっている可能性があるものを明らかにします。
サーバーから受信した応答を調べる。
失敗した可用性テストの処理中に収集された、サーバー側の相関関係を持つテレメトリを使用してエラーを診断する。
Git または Azure Boards でイシューまたは作業項目をログして、問題を追跡します。このバグには、Azure portal のイベントへのリンクが含まれます。
Visual Studio で Web テスト結果を開く。

エンドツーエンドのトランザクションの診断エクスペリエンスの詳細については、トランザクション診断のドキュメントを参照してください。

例外の行を選択すると、代理可用性テストが失敗した原因であるサーバー側の例外の詳細が表示されます。コードレベルの豊富な診断のデバッグスナップショットを取得することもできます。

生の結果に加えて、メトリックスエクスプローラーに 2 つの重要な可用性メトリックを表示することもできます。

可用性: すべてのテスト実行にわたる、成功したテストの割合 (%)。
テスト期間: すべてのテスト実行にわたる平均のテスト期間。

Log Analytics のサンプルクエリ

Log Analytics を使って、可用性の結果 (availabilityResults)、依存関係 (dependencies)、その他を見ることができます。 Log Analytics の詳細については、ログクエリの概要に関するページを参照してください。

従来の URL ping テストを標準テストに移行する

次の手順では、URL ping テストの機能をレプリケートする標準テストの作成プロセスについて説明します。これにより、以前作成した URL ping テストを使用して、標準テストの高度な機能をより簡単に利用し始めることができます。

重要

コストは、標準テストの実行に関連付けられます。標準テストを作成すると、テストの実行に対して課金されます。このプロセスを開始する前に、Azure Monitor の価格に関するページを参照してください。

必須コンポーネント

Application Insights での URL ping テスト
Azure PowerShell のアクセス

作業の開始

Azure PowerShell (Connect-AzAccount + Set-AzContext) を使って、サブスクリプションに接続します。

現在のサブスクリプションのすべての URL ping テストを一覧表示してください。

Get-AzApplicationInsightsWebTest | `
Where-Object { $_.WebTestKind -eq "ping" } | `
Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;

移行したい URL ping テストを見つけて、そのリソースグループと名前を記録します。

次のコマンドを使って、URL ping テストと同じロジックで標準テストを作成します。これは、HTTP と HTTPS 両方のエンドポイントで機能します。

$resourceGroup = "pingTestResourceGroup";
$appInsightsComponent = "componentName";
$pingTestName = "pingTestName";
$newStandardTestName = "newStandardTestName";

$componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
$pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
$pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
$pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;

$dynamicParameters = @{};

if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
$dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
}

if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
-and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
-and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
$dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
$dynamicParameters["ContentPassIfTextFound"] = $true;
}

New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
-Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
-RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
-Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
-RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString);

新しい標準テストには既定でアラートルールがないため、わずらわしいアラートは作成されません。 URL ping テストは変更されないため、これについては引き続きアラートを利用できます。

新しい標準テストの機能を検証してから、URL ping テストを参照するアラートルールを更新して、代わりに標準テストを参照するようにします。
URL ping テストを無効化または削除します。 Azure PowerShell でこれを行うには、次のコマンドを使用できます。
```
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
```

ファイアウォールの内側でのテスト

ファイアウォールの内側でエンドポイントの可用性を確保するには、パブリック可用性テストを有効にするか、切断された、またはイングレスのシナリオで可用性テストを実行します。

パブリック可用性テストの有効化

内部 Web サイトにパブリックドメインネームシステム (DNS) レコードがあることを確認します。 DNS を解決できない場合、可用性テストは失敗します。詳細については、内部アプリケーションのカスタムドメイン名の作成に関するページを参照してください。

警告

可用性テストサービスによって使用される IP アドレスは共有され、ファイアウォールで保護されたサービスエンドポイントを他のテストに公開できます。 IP アドレスのフィルター処理だけではサービスのトラフィックのセキュリティは確保されないため、Web 要求の配信元を確認するために追加のカスタムヘッダーを追加することをお勧めします。詳細については、「仮想ネットワークサービスタグ」を参照してください。

トラフィックを認証する

トラフィックを検証するために、標準テストにカスタムヘッダーを設定します。

この可用性テストを識別するために、スペースを含まない英数字文字列を作成します (例: MyAppAvailabilityTest)。これ以降、この文字列を "可用性テスト文字列識別子" と呼びます。
可用性テストを作成または更新するときに、[標準テストの情報] セクションで、カスタムヘッダー X-Customer-InstanceId と値 ApplicationInsightsAvailability:<your availability test string identifier> を追加します。
これまでの手順で定義したヘッダーと値が受信トラフィックに含まれていることをサービスで必ず確認します。

または、クエリパラメーターとして "可用性テスト文字列識別子" を設定します。

例: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

可用性テストからの受信要求を許可するようにファイアウォールを構成する

Note

この例は、ネットワークセキュリティグループのサービスタグの使用に固有です。多くの Azure サービスはサービスタグを受け入れますが、それぞれに異なる構成手順が必要です。

個々の IP を承認したり、最新の IP リストを維持したりせずに Azure サービスを簡単に有効にするには、サービスタグを使用します。これらのタグを Azure Firewall とネットワークセキュリティグループの全体に適用して、可用性テストサービスがエンドポイントにアクセスできるようにします。サービスタグ ApplicationInsightsAvailability は、すべての可用性テストに適用されます。

Azure ネットワークセキュリティグループを使っている場合は、ネットワークセキュリティグループリソースに移動し、[設定] で [受信セキュリティ規則] エクスペリエンスを開いてから、[追加] を選びます。
次に、[ソース] として [サービスタグ] を選び、[ソースサービスタグ] として ApplicationInsightsAvailability を選びます。サービスタグからの着信トラフィック用にオープンポート 80 (http) と 443 (https) を使用します。

エンドポイントが Azure の外部にある場合、またはサービスタグがオプションではない場合にアクセスを管理するには、Web テストエージェントの IP アドレスを許可リストに登録します。 PowerShell、Azure CLI、または Service Tag API を使用した REST 呼び出しを使用して、IP 範囲のクエリを実行できます。現在のサービスタグとその IP の詳細の包括的な一覧については、JSON ファイルをダウンロードしてください。

ネットワークセキュリティグループリソースの [設定] で [受信セキュリティ規則] エクスペリエンスを開き、[追加] を選びます。
次に、[ソース] として [IP アドレス] を選びます。次に、[ソース IP アドレス/CIDR 範囲] のコンマ区切りの一覧に IP アドレスを追加します。

切断またはイングレスなしシナリオ

Azure Private Link を使用して、Application Insights リソースを内部サービスエンドポイントに接続します。
内部サーバーまたはエンドポイントを定期的にテストするカスタムコードを作成します。コア SDK パッケージ内の TrackAvailability() API を使用して、結果を Application Insights に送信します。

サポートされる TLS 構成

クラス最高の暗号化を提供するために、すべての可用性テストでは、選択した暗号化メカニズムとしてトランスポート層セキュリティ (TLS) 1.2 および 1.3 が使用されます。さらに、各バージョンでは、以下の暗号スイートと楕円曲線もサポートされます。

TLS 1.3 は現在、可用性テストリージョン NorthCentralUS、CentralUS、EastUS、SouthCentralUS、WestUS でのみ使用できます。

バージョン	暗号スイート	楕円曲線
TLS 1.2	• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	• NistP384 • NistP256
TLS 1.3	• TLS_AES_256_GCM_SHA384 • TLS_AES_128_GCM_SHA256	• NistP384 • NistP256

TLS 構成の非推奨化

重要

2025 年 3 月 1 日、Azure 全体でのレガシ TLS 提供終了に合わせて、TLS 1.0/1.1 プロトコルバージョン、および一覧の TLS 1.2/1.3 レガシ暗号スイートと楕円曲線が Application Insights 可用性テストで廃止されます。

TLS 1.0 と TLS 1.1

TLS 1.0 と TLS 1.1 は廃止されます。

TLS 1.2 と TLS 1.3

バージョン	暗号スイート	楕円曲線
TLS 1.2	• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA • TLS_RSA_WITH_AES_256_GCM_SHA384 • TLS_RSA_WITH_AES_128_GCM_SHA256 • TLS_RSA_WITH_AES_256_CBC_SHA256 • TLS_RSA_WITH_AES_128_CBC_SHA256 • TLS_RSA_WITH_AES_256_CBC_SHA • TLS_RSA_WITH_AES_128_CBC_SHA	• curve25519
TLS 1.3		• curve25519

トラブルシューティング

警告

可用性テストでは最近 TLS 1.3 が有効にされました。結果として新しいエラーメッセージが表示される場合、TLS 1.3 を有効にしている Windows Server 2022 で実行されているクライアントがエンドポイントに接続できることを確認してください。これができない場合、可用性テストを古い TLS バージョンにフォールバックさせるために、エンドポイントで TLS 1.3 を一時的に無効にすることを検討してください。

詳しくは、トラブルシューティングに関する記事をご覧ください。

ダウンタイムと停止のブック

このセクションでは、複数の Application Insights リソースと Azure サブスクリプションを対象とする 1 つのペインで、Web テストのサービスレベルアグリーメント (SLA) を簡単に計算してレポートする方法を説明します。ダウンタイムと停止レポートには、顧客の接続、一般的なアプリケーションの応答時間、および発生したダウンタイムについて理解を深められるように、強力な構築済みのクエリとデータ視覚化が用意されています。

SLA ブックテンプレートには、次の 2 つの方法で Application Insights リソースからアクセスできます。

[可用性] エクスペリエンスを開き、上部のナビゲーションバーで [SLA レポート] を選びます。
[Workbooks] エクスペリエンスを開いて、[ダウンタイムと停止] テンプレートを選びます。

パラメーターの柔軟性

ブックに設定されているパラメーターは、レポートの残りの部分に影響します。

Subscriptions、App Insights Resources、Web Test: これらのパラメーターによって、大まかなリソースのオプションが決まります。これらは Log Analytics クエリに基づいており、すべてのレポートクエリで使われます。
Failure Threshold と Outage Window: これらのパラメーターを使って、サービス停止の独自の条件を決定できます。たとえば、選択した期間にエラーが発生した場所のカウンターに基づいた、Application Insights の可用性アラートの条件です。一般的なしきい値は、5 分間に 3 つの場所となります。
Maintenance Period: このパラメーターを使って、通常のメンテナンス頻度を選択できます。 Maintenance Window は、メンテナンス期間例の日時セレクターです。指定した期間に発生したすべてのデータは、結果では無視されます。
Availability Target %: このパラメーターを使ってターゲット目標を指定し、カスタム値を受け取ります。

[概要] ページ

概要ページには、お客様の以下に関する概要情報が含まれています。

SLA の合計 (定義されている場合はメンテナンス期間を除く)
エンドツーエンドの停止インスタンス
アプリケーションダウンタイム

停止パラメーターに従い、テストが失敗し始めた時点から正常に再び合格するまでの間で停止インスタンスが決定されます。テストが午前 8:00 に失敗するようになり、午前 10:00 に再び成功した場合は、データのその期間全体が同じ停止と見なされます。また、報告期間中に発生した最長の停止を調査することもできます。

一部のテストは、さらに調査するために Application Insights リソースにリンクすることができます。ただし、これを利用できるのはワークスペースベースの Application Insights リソースのみです。

ダウンタイム、障害、および失敗

[概要] ページの横には、さらに 2 つのタブがあります。

[停止とダウンタイム] タブには、停止インスタンスの合計と、テスト別に分類されたダウンタイムの合計に関する情報があります。
[Failures by Location] (場所別の失敗) タブには、問題がある可能性のある接続領域を特定するのに役立つ、テストに失敗した場所の geo マップがあります。

その他の機能

カスタマイズ: 他の Azure Monitor ブックと同様にレポートを編集でき、チームのニーズに基づいてクエリや視覚化をカスタマイズできます。
Log Analytics: すべてのクエリを Log Analytics で実行して、他のレポートまたはダッシュボードで使用できます。パラメーターの制限を解除して、コアクエリを再利用してください。
アクセスと共有: レポートは、チームやリーダーと共有したり、ダッシュボードにピン留めしてさらに使用したりできます。ユーザーには、実際のブックが格納されている Application Insights リソースに対する読み取りアクセス許可とアクセス権が必要です。

よく寄せられる質問

このセクションでは、一般的な質問への回答を示します。

全般

イントラネットサーバー上で可用性テストを実行することはできますか?

可用性テストは、世界中に分布するプレゼンスのポイントで実行されます。以下に示す 2 つのソリューションがあります。

ファイアウォールドア: 頻繁に変更される多数の Web テストエージェントからサーバーへの要求を許可します。
カスタムコード: イントラネット内部からサーバーに定期的な要求を送信する独自のコードを記述します。 Visual Studio Web テストを実行して、このコードをテストすることができます。テストの結果は TrackAvailability() API を使用して Application Insights に送信できます。

可用性テストのユーザーエージェント文字列は何ですか?

ユーザーエージェント文字列は、Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights) です

TLS サポート

この非推奨化はどのように Web テストの動作に影響しますか?

可用性テストは、サポートされている Web テストの場所それぞれにおける分散クライアントとして機能します。 Web テストが実行されるたびに、可用性テストサービスは、Web テスト構成内で定義されているリモートエンドポイントへのアクセスを試みます。現在サポートされている TLS 構成すべてを含む TLS クライアント Hello メッセージが送信されます。リモートエンドポイントが可用性テストクライアントと共通の TLS 構成を共有している場合、TLS ハンドシェイクが成功します。それ以外の場合、Web テストは TLS ハンドシェイクの失敗によって失敗します。

Web テストが影響を受けないようにするにはどうすればよいですか?

影響を回避するために、Web テストがやり取りを行う各リモートエンドポイント (依存要求を含む) は、可用性テストがサポートするのと同じプロトコルバージョン、暗号スイート、楕円曲線の内の少なくとも 1 つの組み合わせをサポートする必要があります。リモートエンドポイントが必要な TLS 構成をサポートしていない場合は、上記の非推奨化後の TLS 構成のいずれかの組み合わせをサポートするように更新する必要があります。これらのエンドポイントは、(できれば成功した Web テスト実行の) Web テストのトランザクションの詳細を表示することで検出できます。

リモートエンドポイントでどの TLS 構成がサポートされているかを検証するにはどうすればよいですか?

エンドポイントがどの TLS 構成をサポートしているかをテストするために利用できるツールがいくつか存在します。 1 つの方法は、こちらのページで詳しく説明されている例に従うことです。リモートエンドポイントがパブリックインターネット経由で利用できない場合は、エンドポイントを呼び出すアクセス権を持つマシンから、リモートエンドポイントでサポートされている TLS 構成を検証するようにする必要があります。

Note

Web サーバーで必要な TLS 構成を有効にする手順に関して、プロセスが不明な場合は、Web サーバーが実行されているホスティングプラットフォームを所有するチームに連絡することが適切です。

2025 年 3 月 1 日より後は、影響を受けるテストの Web テストの動作はどうなりますか?

この非推奨化の影響を受けるすべての TLS ハンドシェイクの失敗で発生する決まった例外型は存在しません。しかし、Web テストの失敗で発生することになる最も一般的な例外は The request was aborted: Couldn't create SSL/TLS secure channel となるでしょう。また、影響を受ける可能性がある Web テスト結果に関する TLS 転送のトラブルシューティング手順でも、TLS 関連のエラーを確認できるはずです。

自分の Web テストで現在どの TLS 構成が使用されているかを表示できますか?

Web テストの実行中にネゴシエートされた TLS 構成を表示することはできません。リモートエンドポイントが可用性テストで一般的な TLS 構成をサポートしている限り、非推奨化後にどのような影響も発生しないはずです。

非推奨化が影響を与える可用性テストサービス内のコンポーネントはどれですか?

このドキュメントで詳しく説明されている TLS の非推奨化は、2025 年 3 月 1 日より後の可用性テストの Web テストの実行動作にのみ影響を与えるはずです。 CRUD 操作に関する可用性テストサービスとのやり取りの詳細については、「Azure Resource Manager TLS サポート」を参照してください。このリソースは、TLS のサポートと非推奨化のタイムラインの詳細について説明しています。

TLS に関するサポートはどこで受けることができますか?

従来の TLS の問題に関する一般的な質問については、「TLS の問題の解決」を参照してください。

次の方法で共有

Application Insights 可用性テスト

可用性テストの種類

可用性テストを作成する

前提条件

作業の開始

可用性のアラート

位置情報の作成タグ

アラートを有効にする

アラートの条件

アラートの条件を変更する

カスタム アラート ルールを作成する

アラートを自動化する

可用性テストの結果を表示する

可用性を確認する

テストを調べて編集する

エラーが発生した場合

Log Analytics のサンプル クエリ

従来の URL ping テストを標準テストに移行する

必須コンポーネント

作業の開始

ファイアウォールの内側でのテスト

パブリック可用性テストの有効化

トラフィックを認証する

可用性テストからの受信要求を許可するようにファイアウォールを構成する

切断またはイングレスなしシナリオ

サポートされる TLS 構成

TLS 構成の非推奨化

TLS 1.0 と TLS 1.1

TLS 1.2 と TLS 1.3

トラブルシューティング

ダウンタイムと停止のブック

パラメーターの柔軟性

[概要] ページ

ダウンタイム、障害、および失敗

その他の機能

よく寄せられる質問

全般

イントラネット サーバー上で可用性テストを実行することはできますか?

可用性テストのユーザー エージェント文字列は何ですか?

TLS サポート

この非推奨化はどのように Web テストの動作に影響しますか?

Web テストが影響を受けないようにするにはどうすればよいですか?

リモート エンドポイントでどの TLS 構成がサポートされているかを検証するにはどうすればよいですか?

2025 年 3 月 1 日より後は、影響を受けるテストの Web テストの動作はどうなりますか?

自分の Web テストで現在どの TLS 構成が使用されているかを表示できますか?

非推奨化が影響を与える可用性テスト サービス内のコンポーネントはどれですか?

TLS に関するサポートはどこで受けることができますか?

次のステップ

フィードバック

その他のリソース

カスタムアラートルールを作成する

Log Analytics のサンプルクエリ

イントラネットサーバー上で可用性テストを実行することはできますか?

可用性テストのユーザーエージェント文字列は何ですか?

リモートエンドポイントでどの TLS 構成がサポートされているかを検証するにはどうすればよいですか?

非推奨化が影響を与える可用性テストサービス内のコンポーネントはどれですか?