アプリケーション マップ: 分散アプリケーションをトリアージする

開発者は、分散アプリケーションの論理構造を表すためにアプリケーション マップを使用します。 マップは、記録されたテレメトリの roleName または name プロパティを使用して個々のアプリケーション コンポーネントを識別することによって生成されます。 マップ上の円 (または "ノード") はコンポーネントを表し、方向線 ("コネクタ" または "エッジ") は "ソース" ノードから "ターゲット" ノードへの HTTP 呼び出しを示します。

Azure Monitor には、マップをすばやく実装し、すべてのコンポーネントでパフォーマンスのボトルネックや障害のホットスポットを特定するのに役立つアプリケーション マップ機能が用意されています。 各マップ ノードは、アプリケーション コンポーネントまたはその依存関係であり、正常性 KPI とアラートの状態が提供されます。 任意のノードを選択して、Application Insights イベントなどのコンポーネントの詳細な診断を表示できます。 アプリで Azure サービスを使用している場合は、Azure Diagnostics (SQL Database アドバイザーのアドバイス情報など) を選ぶこともできます。

アプリケーション マップには、サービスの正常性に関する迅速な調査を支援するインテリジェント ビューも用意されています。

コンポーネントについて理解する

コンポーネントは、分散型またはマイクロサービス アプリケーションの個別にデプロイできる部分です。 開発者と運用チームには、これらのアプリケーション コンポーネントによって生成されたテレメトリに対して、コード レベルの可視性またはアクセスがあります。

コンポーネントに関するいくつかの考慮事項:

• コンポーネントは、チームや組織がアクセスできない可能性がある Azure SQL、Azure Event Hubs などの "監視された" 外部依存関係 (コードまたはテレメトリ) とは異なります。
• コンポーネントは、任意の数のサーバー、ロール、またはコンテナー インスタンス上で実行されます。
• サブスクリプションが異なる場合でも、コンポーネントは別個の Application Insights リソースにすることができます。 また、1 つの Application Insights リソースにレポートする異なるロールにすることもできます。 プレビュー マップのエクスペリエンスには、各コンポーネントがその設定方法に関係なく表示されます。

アプリケーション マップについて調べる

アプリケーション マップを使用すると、複数のレベルの関連アプリケーション コンポーネントにわたる完全なアプリケーション トポロジを確認できます。 前述のとおり、コンポーネントは、さまざまな Application Insights リソース、依存コンポーネント、または単一のリソース内のさまざまなロールにすることができます。 アプリケーション マップでは、Application Insights SDK がインストールされているサーバー間での HTTP 依存関係呼び出しに従ってコンポーネントが検索されます。

マッピング エクスペリエンスではまず、アプリケーション内のコンポーネントとその依存関係が順次検出されます。 アプリケーション マップを最初に読み込むときに、クエリ セットがトリガーされ、メイン コンポーネントに関連するコンポーネントが検出されます。 コンポーネントが検出されると、ステータス バーに検出されたコンポーネントの現在の数が表示されます。

次のセクションでは、Azure portal でアプリケーション マップを操作するために使用できるいくつかのアクションについて説明します。

マップ コンポーネントの更新

[マップ コンポーネントの更新] オプションでは、コンポーネントの検出がトリガーされ、現在のすべてのノードを表示するためにマップが更新されます。 アプリケーションの複雑さによっては、更新の読み込みに数分かかることがあります。

すべてのアプリケーション コンポーネントが単一の Application Insights リソース内のロールである場合、この検出ステップは不要です。 このアプリケーション シナリオの初期読み込みでは、すべてのコンポーネントが検出されます。

コンポーネントの詳細を表示する

アプリケーション マップ エクスペリエンスの主な目的は、何百ものコンポーネントがある複雑なトポロジを視覚化できるようにすることです。 このシナリオでは、[詳細の表示] オプションを使用して、個々のノードの詳細でマップ ビューを拡張すると便利です。 ノードの詳細ペインには、選択されたコンポーネントの関連する分析情報、パフォーマンス、エラー トリアージ エクスペリエンスが表示されます。

各ペイン セクションには、エラー、パフォーマンス、失敗した要求と依存関係に関する詳細など、展開ビューで詳細情報を表示するオプションが含まれています。

エラーを調査する

ノードの詳細ペインで、[エラーの調査] オプションを使用して、コンポーネントのすべてのエラーを表示できます。

[エラー] ビューでは、選択されたコンポーネントに関連する操作、依存関係、例外、ロールのエラー データを調べることができます。

パフォーマンスを調査する

ノードの詳細ペインで、[パフォーマンスの調査] オプションを選択して、コンポーネントのパフォーマンスの問題をトラブルシューティングできます。

[パフォーマンス] ビューでは、選択されたコンポーネントに関連付けられている操作、依存関係、ロールのテレメトリ データを調べることができます。

詳細に移動とスタック トレース

ノードの詳細ペインの [詳細に移動] オプションでは、コンポーネントのエンドツーエンド トランザクション エクスペリエンスが表示されます。 このペインでは、呼び出し履歴レベルで詳細を表示できます。

ページが開き、詳細の [タイムライン] ビューが表示されます。

[すべて表示] オプションを使用すると、コンポーネントのトレースとイベント情報を含むスタックの詳細を表示できます。

ログに表示 (Analytics)

ノードの詳細ペインでは、[ログに表示 (Analytics)] オプションを使用して、アプリケーション データのクエリを実行し、さらに調査することができます。

[ログ (Analytics) ページには、組み込みまたはカスタムのクエリと関数を使用して、アプリケーション テレメトリ テーブル レコードを調べるためのオプションが用意されています。 形式を調整し、分析を保存してエクスポートすることで、データを操作できます。

アラートとルールを表示する

ノードの詳細ペインの [アラートの表示] オプションを使用すると、アクティブなアラートを表示できます。

[アラート] ページには重大なアラートと発生したアラートが表示されます。

[アラート] ページの [アラート ルール] オプションでは、アラートがトリガーされる原因となっている基になるルールが表示されます。

クラウド ロールの名前とノードについて理解する

アプリケーション マップではクラウド ロール名プロパティを使用して、マップ上のアプリケーション コンポーネントが識別されます。 コンポーネント ノードでクラウド ロール名がどのように使用されるかを調べるには、複数のクラウド ロール名が存在するアプリケーション マップを確認します。

次の例は、5 つのコンポーネント ノードと 9 つの依存ノードへのコネクタを含む階層ビューのマップを示しています。 各ノードにはクラウド ロール名があります。

アプリケーション マップでは、アプリケーション コンポーネントのデータとリレーションシップを示すために、ノードにさまざまな色、強調表示、サイズが使用されます。

• クラウド ロール名は、分散アプリケーションのさまざまな側面を表します。 この例では、一部のアプリケーション ロールに Contoso Retail Check、Fabrikam-App、fabrikam-loadfunc、retailfabrikam-37ha6、retailapp が含まれます。

• ノードの周りの点線の青い円は、最後に選択されたコンポーネントを示しています。 この例では、最後に選択されたコンポーネントは Web ノードです。

• ノードを選択して詳細を表示すると、実線の青い円でノードが強調表示されます。 この例では、現在選択されているノードは Contoso Retail Reports です。

• 離れているか関連のないコンポーネント ノードは、他のノードと比べて小さく表示されています。 これらの項目はビューで淡色表示され、現在選択されているコンポーネントのパフォーマンスが強調表示されます。

• この例では、各クラウド ロール名は、独自のインストルメンテーション キーを持つ異なる一意の Application Insights リソースも表します。 このアプリケーションの所有者は、これら 4 つの異なる各 Application Insights リソースにアクセスできるため、アプリケーション マップによって基になるリレーションシップを 1 つのマップにまとめることができます。

クラウド ロール インスタンスを調査する

クラウド ロール名によって Web フロントエンド内のどこかに問題があることが明らかになり、Web フロントエンド全体で複数の負荷分散サーバーを実行している場合は、"クラウド ロール インスタンス"を使用すると役立ちます。 アプリケーション マップでは、Kusto クエリを使用して、コンポーネント ノードに関するより詳細な情報を表示できます。 ノードを調査して、特定のクラウド ロール インスタンスに関する詳細を表示できます。 この方法は、問題がすべての Web フロントエンド サーバーに影響するか、特定のインスタンスにのみ影響するかを判断するのに役立ちます。

クラウド ロール インスタンスの値のオーバーライドが必要になる可能性があるシナリオは、アプリがコンテナー化された環境で実行されている場合です。 この場合、個々のサーバーに関する情報が、特定の問題を見つけるのに十分でない可能性があります。

クラウド ロール名プロパティをテレメトリ初期化子でオーバーライドする方法の詳細については、ITelemetryInitializer プロパティの追加に関するページを参照してください。

クラウド ロール名を設定する

アプリケーション マップではクラウド ロール名プロパティを使用して、マップ上のコンポーネントを識別します。 このセクションでは、クラウド ロール名を手動で設定またはオーバーライドし、アプリケーション マップに表示される内容を変更する例を示します。

次のスニペットは、クラウド ロールとクラウド ロール インスタンスのスキーマ定義を示しています。

[Description("Name of the role the application is a part of. Maps directly to the role name in Azure.")]
[MaxStringLength("256")]
705: string      CloudRole = "ai.cloud.role";

[Description("Name of the instance where the application is running. Computer name for on-premises, instance name for Azure.")]
[MaxStringLength("256")]
715: string      CloudRoleInstance = "ai.cloud.roleInstance";

公式な定義:

using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.Extensibility;

namespace CustomInitializer.Telemetry
{
    public class MyTelemetryInitializer : ITelemetryInitializer
    {
        public void Initialize(ITelemetry telemetry)
        {
            if (string.IsNullOrEmpty(telemetry.Context.Cloud.RoleName))
            {
                //set custom role name here
                telemetry.Context.Cloud.RoleName = "Custom RoleName";
                telemetry.Context.Cloud.RoleInstance = "Custom RoleInstance";
            }
        }
    }
}

    <ApplicationInsights>
      <TelemetryInitializers>
        <!-- Fully qualified type name, assembly name: -->
        <Add Type="CustomInitializer.Telemetry.MyTelemetryInitializer, CustomInitializer"/>
        ...
      </TelemetryInitializers>
    </ApplicationInsights>

 using Microsoft.ApplicationInsights.Extensibility;
 using CustomInitializer.Telemetry;

    protected void Application_Start()
    {
        // ...
        TelemetryConfiguration.Active.TelemetryInitializers.Add(new MyTelemetryInitializer());
    }

 using Microsoft.ApplicationInsights.Extensibility;
 using CustomInitializer.Telemetry;
 public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<ITelemetryInitializer, MyTelemetryInitializer>();
}

{
  "role": {
    "name": "my cloud role name"
  }
}

var appInsights = require("applicationinsights");
appInsights.setup('INSTRUMENTATION_KEY').start();
appInsights.defaultClient.context.tags["ai.cloud.role"] = "your role name";
appInsights.defaultClient.context.tags["ai.cloud.roleInstance"] = "your role instance";

var appInsights = require("applicationinsights");
appInsights.setup('INSTRUMENTATION_KEY').start();

appInsights.defaultClient.addTelemetryProcessor(envelope => {
    envelope.tags["ai.cloud.role"] = "your role name";
    envelope.tags["ai.cloud.roleInstance"] = "your role instance"
});

appInsights.queue.push(() => {
appInsights.addTelemetryInitializer((envelope) => {
  envelope.tags["ai.cloud.role"] = "your role name";
  envelope.tags["ai.cloud.roleInstance"] = "your role instance";
});
});

def callback_function(envelope):
   envelope.tags['ai.cloud.role'] = 'new_role_name'

# AzureLogHandler
handler.add_telemetry_processor(callback_function)

# AzureExporter
exporter.add_telemetry_processor(callback_function)

アプリケーション マップ フィルターを使用する

アプリケーション マップ フィルターは、マップ上の表示ノードとエッジの数を減らすのに役立ちます。 これらのフィルターを使用すると、マップの範囲を縮小し、より小さく、より対象を絞ったマップを表示できます。

フィルター処理を行う簡単な方法は、マップ上の任意のノードのコンテキスト メニューの [このノードのフィルター] オプションを使用することです。

[フィルターの追加] オプションを使用してフィルターを作成することもできます。

フィルターの種類 (ノードまたはコネクタ) と必要な設定を選択し、選択内容を確認して現在のマップに適用します。

ノード フィルターを作成する

ノード フィルターを使用すると、アプリケーション マップ内の特定のノードのみを表示し、他のすべてのノードを非表示にすることができます。 マップ内のノードのプロパティで条件に一致する値を検索するようにパラメーターを構成します。 ノード フィルターでノードが削除されると、そのノードのすべてのコネクタとエッジも削除されます。

ノード フィルターには、構成する 3 つのパラメーターがあります。

• 含まれるノード: 一致するプロパティについてアプリケーション マップで確認するノードの種類。 次の 4 つのオプション用意されています:

  • ノード、ソース、ターゲット: 検索条件に一致するすべてのノードが結果マップに含まれます。 ソースまたはターゲットが検索条件を満たしていない場合でも、一致するノードのすべてのソースおよびターゲット ノードも自動的に結果マップに含まれます。 ソースおよびターゲット ノードは、まとめて "接続された" ノードと呼ばれます。

  • ノードとソース: ノード、ソース、ターゲットと同じ動作ですが、ターゲット ノードは結果マップに自動的に含まれません。

  • ノードとターゲット: ノード、ソース、ターゲットと同じ動作ですが、ソース ノードは結果マップに自動的に含まれません。

  • ノードのみ: 結果マップ内のすべてのノードには、検索条件に一致するプロパティ値が必要です。

• 演算子: 各ノードのプロパティ値に対して実行する条件付きテストの種類。 次の 4 つのオプション用意されています:

  • contains: ノード プロパティ値には、検索値パラメーターで指定された値が含まれます。
  • !contains ノード プロパティ値には、検索値パラメーターで指定された値が含まれません。
  • ==: ノード プロパティ値は、検索値パラメーターで指定された値と同じです。
  • !=: ノード プロパティ値は、検索値パラメーターで指定された値と等しくありません。

• 検索値: プロパティ値の条件付きテストに使用するテキスト文字列。 パラメーターのドロップダウン リストには、アプリケーション マップ内の既存のノードの値が表示されます。 リストから値を選択することも、独自の値を作成することもできます。 パラメーター フィールドにカスタム値を入力し、リストで [オプションの作成 ...] を選択します。 たとえば、「test」と入力し、リストで[オプションの作成 "test"] を選択します。

次の図は、30 日間のデータを示すアプリケーション マップに適用されるフィルターの例を示しています。 このフィルターでは、"retailapp" というテキストを含むプロパティを持つノードと接続されたターゲットを検索するようにアプリケーション マップに指示します。

一致するノードとその接続されたターゲット ノードは、結果マップに含まれます。

コネクタ (エッジ) フィルターを作成する

コネクタ フィルターを使用すると、特定のコネクタを持つ特定のノードのみをアプリケーション マップに表示し、他のすべてのノードとコネクタを非表示にすることができます。 マップ内のコネクタのプロパティで条件に一致する値を検索するようにパラメーターを構成します。 ノードに一致するコネクタがない場合、フィルターによってマップからノードが削除されます。

コネクタ フィルターには、構成する 3 つのパラメーターがあります。

• コネクタのフィルター方法: 一致するプロパティについてアプリケーション マップで確認するコネクタの種類。 4 つの選択肢があります。 選択すると、他の 2 つのパラメーターで使用できるオプションが制御されます。

• 演算子: 各コネクタの値に対して実行する条件付きテストの種類。

• 値: プロパティ値の条件付きテストに使用する比較値。 パラメーターのドロップダウン リストには、現在のアプリケーション マップに関連する値が含まれています。 リストから値を選択することも、独自の値を作成することもできます。 たとえば、「16」と入力し、リストで [オプションの作成 "16"] を選択します。

次の表は、[コネクタのフィルター方法] パラメーターでの選択に基づいて構成オプションをまとめたものです。

値のパーセンタイル インジケーター

エラー率、平均呼び出し時間、または呼び出し数でコネクタをフィルター処理する場合、[値] パラメーターの一部のオプションには (Pxx) 指定が含まれます。 このインジケーターではパーセンタイル レベルが示されます。 平均呼び出し時間フィルターの場合、値 200 (P90) が表示されることがあります。 このオプションは、(それらが表す呼び出しの数に関係なく) すべてのコネクタの 90% の呼び出し時間が 200 ms 未満であることを意味します。

パラメーター フィールドに「P」と入力すると、パーセンタイル レベルを含む [値] オプションを確認できます。

フィルターを確認する

選択した後、[フィルターの追加] ポップアップの [レビュー] セクションには、フィルターに関するテキストと視覚的な説明が表示されます。 概要表示は、フィルターがアプリケーション マップにどのように適用されるかを理解するのに役立ちます。

次の例は、"-west" というテキストを含むプロパティを持つノードとターゲットを検索するノード フィルターのレビューの概要を示しています。

この例は、平均呼び出し時間が 42 ms 以上のコネクタ (およびそれらに接続されているノード) を検索するコネクタ フィルターの概要を示しています。

マップにフィルターを適用する

フィルター設定を構成して確認した後、[適用] を選択してフィルターを作成します。 同じアプリケーション マップに複数のフィルターを適用できます。 アプリケーション マップでは、適用されたフィルターはマップの上に "ピル" として表示されます。

フィルター ピルの削除アクション を使用すると、フィルターを削除できます。 適用されたフィルターを削除すると、マップ ビューが更新され、フィルター ロジックが減ります。

アプリケーション マップでは、リストの左端のフィルターから順にフィルター ロジックがマップに適用されます。 フィルターが適用されると、ノードとコネクタがマップ ビューから削除されます。 ノードまたはコネクタがビューから削除された後、後続のフィルターで項目を復元することはできません。

フィルター ピルを選択することで、適用されたフィルターの構成を変更できます。 フィルター設定を変更すると、アプリケーション マップに新しいフィルター ロジックを含むマップ ビューのプレビューが表示されます。 変更を適用しないことにした場合、現在のマップ ビューとフィルターに [キャンセル] オプションを使用できます。

フィルターを調べて保存する

興味深いフィルターが見つかったら、そのフィルターを保存し、後で [リンクのコピー] または [ダッシュボードにピン留めする] オプションで再利用できます。

• [リンクのコピー] オプションでは、コピーした URL 内のすべての現在のフィルター設定がエンコードされます。 このリンクはブラウザーのブックマークに保存することも、他のユーザーと共有することもできます。 この機能では、フィルター設定の時間値は保持されますが、絶対時間は保持されません。 後でリンクを使用するときに、生成されたアプリケーション マップが、リンクが取り込まれた時に存在していたマップと異なる場合があります。

• [ダッシュボードにピン留めする] オプションでは、現在のアプリケーション マップが現在のフィルターと共にダッシュボードに追加されます。 一般的な診断方法は、エラーのコネクタ フィルターを適用してマップをピン留めすることです。 HTTP 呼び出しでエラーが発生したノードをアプリケーションで監視できます。

次のセクションでは、ほとんどのマップに適用され、ダッシュボードにピン留めすると役立つ一般的ないくつかのフィルターについて説明します。

重要なエラーを確認する

過去 24 時間にエラー (赤で強調表示) が発生したコネクタのみのマップ ビューを生成します。 フィルターには、インテリジェント ビューと組み合わされたエラーのコネクタ パラメーターが含まれます。

インテリジェント ビュー機能については、この記事で後ほど説明します。

トラフィックの少ないコネクタを非表示にする

エラーがなく、トラフィックの少ないコネクタをマップ ビューで非表示にして、より重要な問題にすばやく集中できるようにします。 フィルターには、呼び出し数が 2872 (P20) を超える、過去 24 時間のコネクタが含まれます。

トラフィックの多いコネクタを表示する

平均呼び出し時間が長いトラフィックの多いコネクタを表示します。 このフィルターは、潜在的なパフォーマンスの問題を特定するのに役立ちます。 この例のフィルターには、呼び出し数が10854 (P50) を超え、平均呼び出し時間が 578 (P80) を超えている過去 24 時間のコネクタが含まれています。

名前でコンポーネントを見つける

コンポーネントの roleName プロパティの名前付け規則の実装に従って、アプリケーション内のコンポーネント (ノードとコネクタ) を名前で見つけます。 この方法を使用して、分散アプリケーションの特定の部分を確認できます。 フィルターでは、指定された値を含む、過去 24 時間のノード、ソース、ターゲットが検索されます。 この例では、検索値は "west" です。

ノイズの多いコンポーネントを削除する

ノイズの多いコンポーネントをマップから削除して非表示にするフィルターを定義します。 アプリケーション コンポーネントには、マップ ビューに不可欠ではないデータを生成するアクティブな依存ノードが存在する場合があります。 この例のフィルターでは、指定された値 "retail" を含まない、過去 24 時間のノード、ソース、ターゲットが検索されます。

エラーが発生しやすいコネクタを探す

特定の値よりもエラー率が高いコネクタのみを表示します。 この例のフィルターでは、エラー率が 3% を超える過去 24 時間のコネクタが検索されます。

インテリジェント ビューについて調べる

アプリケーション マップのインテリジェント ビュー機能は、サービス正常性の調査に役立つよう設計されています。 機械学習を適用して、ノイズを除外することで、問題の潜在的な根本原因をすばやく特定します。 機械学習モデルは、アプリケーション マップの履歴動作から学習し、インシデントの潜在的な原因を示す主要なパターンと異常を特定します。

大規模な分散型アプリケーションでは、常に "良性" のエラーからある程度のノイズが発生します。これにより、多くの赤いエッジが表示され、アプリケーション マップにノイズが多くなる可能性があります。 インテリジェント ビューには、最も可能性の高いサービス エラーの原因のみが表示され、正常なサービスではノード間の赤いエッジ (サービス間通信) が削除されます。 インテリジェント ビューでは、調査する必要があるエッジが赤で強調表示されます。 また、強調表示されたエッジに対するアクションにつながる分析情報も提供されます。

インテリジェント ビューを使用する利点は多数あります。

• 調査する必要があるエラーのみを強調表示することで、解決までの時間を短縮する
• 特定の赤いエッジが強調表示された理由に関する実用的な分析情報を提供する
• 大規模な分散型アプリケーションでアプリケーション マップを (赤でマークされたエッジのみに焦点を合わせて) シームレスに使用できるようにする

インテリジェント ビューにはいくつかの制限があります。

• 大規模な分散型アプリケーションでは、読み込みに時間がかかる場合があります。
• 最大 7 日間の概算時間がサポートされています。

インテリジェント ビューを操作する

アプリケーション マップの上のトグルを使用すると、インテリジェント ビューを有効にして、問題検出の感度を制御できます。

インテリジェント ビューでは、特許を取得した AIOps 機械学習モデルを使用して、アプリケーション マップ内の重要なデータが (赤で) 強調表示されます。 エラー率、要求数、時間、異常、依存関係の型など、マップ上で強調表示するデータを決定するためにさまざまなアプリケーション データが使用されます。 比較のために、標準マップ ビューでは "生" のエラー率のみが使用されます。

アプリケーション マップでは、感度設定に従ってエッジが赤で強調表示されます。 感度を調整し、強調表示されたエッジで目的の信頼度レベルを実現できます。

実用的な分析情報を確認する

インテリジェント ビューを有効にした後、マップ上で強調表示されているエッジ (赤) を選択して、コンポーネントの "実用的な分析情報" を表示します。 右側のペインに分析情報が表示され、エッジが強調表示されている理由が説明されます。

問題のトラブルシューティングを開始するには、[エラーの調査] を選択します。 [エラー] ペインでコンポーネントに関する情報を確認し、検出された問題が根本原因であるかどうかを判断できます。

インテリジェント ビューでアプリケーション マップ上のエッジが強調表示されない場合、機械学習モデルによって、アプリケーションの依存関係で潜在的なインシデントが検出されていません。

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

アプリケーション マップを期待どおりに動作させる際に問題が発生している場合は、次のセクションの推奨事項を確認してください。

一般的な推奨事項をいくつか以下に示します。

• 公式にサポートされている SDK を使用します。 未サポートまたはコミュニティ SDK は、相関関係をサポートしていない場合があります。 サポートされている SDK の一覧については、Application Insights: 言語、プラットフォーム、および統合に関する記事を参照してください。

• すべてのコンポーネントを最新の SDK バージョンにアップグレードします。

• Azure Functions V2 にアップグレードすることで、C# で Azure Functions をサポートします。

• クラウド ロール名が正しく構成されていることを確かめます。

• 欠落している依存関係が、自動収集される依存関係として一覧表示されていることを確認します。 依存関係が一覧表示されていない場合は、依存関係の追跡呼び出しを使用して手動で追跡できます。

マップ上のノードが多すぎる

アプリケーション マップでは、要求テレメトリ内の一意のクラウド ロール名ごとにコンポーネント ノードが追加されます。 また、このプロセスでは、型、ターゲット、クラウド ロール名の一意の組み合わせごとに依存関係ノードも追加されます。

• テレメトリに 10,000 を超えるノードがある場合、アプリケーション マップではすべてのノードとリンクをフェッチできません。 このシナリオでは、マップ構造が不完全です。 このシナリオが発生すると、マップを表示したときに警告メッセージが表示されます。

• アプリケーション マップでは、一度に最大 1,000 個の個別のグループ化されていないノードをレンダリングできます。 アプリケーション マップでは、視覚化の複雑さを低減するために、型と呼び出し元が同じである場合に依存関係がグループ化されます。

• テレメトリの一意のクラウド ロール名が多すぎる場合や、依存関係の型が多すぎる場合は、そのグループ化が不十分となり、マップはレンダリングされません。

この問題を解決するには、クラウド ロール名、依存関係の型、依存関係のターゲットのフィールドが正しく設定されるように、インストルメンテーションを変更する必要があります。 アプリケーションが次の条件に準拠していることを確認します。

• 各依存関係ターゲットは、依存関係の論理名を表します。 多くの場合、この値は依存関係のサーバーまたはリソース名と等しくなります。 たとえば、HTTP 依存関係がある場合、値はホスト名です。 値には、一意の ID やパラメーター (要求によって変わる) を含めることはできません。

• 各依存関係の型は、依存関係の論理型を表します。 たとえば、一般的な依存関係の種類には、HTTP、SQL、Azure BLOB などがあります。 この値には、一意の ID を含めることはできません。

• 各クラウド ロール名の目的は、「クラウド ロール名を設定またはオーバーライドする」セクションの説明に適用されます。

インテリジェント ビュー: エッジが強調表示されていない

インテリジェント ビューでは、感度が低い設定であっても、エッジが期待どおりに強調表示されない場合があります。 依存関係が失敗しているようであるものの、モデルでは問題が潜在的なインシデントとして示されていません。 考えられるシナリオを次にいくつか示します。

• 一般的に依存関係が失敗する場合、モデルではエラーがコンポーネントの標準状態と見なされ、エッジが強調表示されない可能性があります。 インテリジェント ビューでは、リアルタイムでの問題解決に重点が置かれています。

• 依存関係がアプリケーションの全体的なパフォーマンスに最小限の影響しか与えない場合、インテリジェント ビューでは機械学習モデリング中にコンポーネントが無視される可能性があります。

シナリオが一意である場合は、フィードバック オプションを使用してエクスペリエンスを説明し、今後のモデル バージョンの改善に役立てることができます。

インテリジェント ビュー: エッジが強調表示されている

インテリジェント ビューでエッジが強調表示されている場合、機械学習モデルからの実用的な分析情報で、高い確率スコアに影響する重大な問題が特定されているはずです。 推奨事項は、エラーだけでなく、主要なフローでの予期しない待ち時間などの他のインジケーターにも基づいていることに留意してください。

インテリジェント ビュー: 読み込まれない

インテリジェント ビューが読み込まれない場合は、構成された時間枠を 6 日以下に設定します。

インテリジェント ビュー: 長い読み込み時間

インテリジェント ビューの読み込みに予想以上に時間がかかる場合は、[マップ コンポーネントの更新] オプションを選択しないようにしてください。 1 つの Application Insights リソースに対してのみ[Intelligent view] (インテリジェント ビュー) を有効にします。

関連するコンテンツ

• テレメトリの関連付けを使用した Application Insights での関連付けのしくみについて学習します。

• Application Insights に監視されるすべてのコンポーネントからのサーバー側テレメトリを単一ビューに関連付けるエンドツーエンドのトランザクション診断エクスペリエンスについて調べます。

• カスタム操作の追跡を使用して、ASP.NET Core と ASP.NET の高度な相関シナリオをサポートします。