Application Insights は、Web アプリケーションから Azure portal にテレメトリを送信して、アプリケーションとインフラストラクチャのパフォーマンスと使用状況に関する分析情報を提供します。 テレメトリ データの理解と整理を深めるために、テレメトリ データは個別の種類に分類されます。
テレメトリ データ モデルは標準化されており、プラットフォームと言語に依存しない監視を作成できます。 私たちは、基本的なシナリオをサポートするモデルをシンプルかつスリムに維持しながら、高度な用途に対してスキーマを拡張できるよう努めています。
Application Insights によって収集されたデータは、次の一般的なアプリケーション実行パターンをモデル化します。
1availabilityResults は既定では使用できないため、可用性テストを設定する必要があります。
2customEvents と customMetrics はカスタムインストルメンテーションでのみ使用できます。
注意
Application Insights では、従来の理由から、 traces テーブルにログが格納されます。 分散トレースのスパンは、requestsテーブルとdependencies テーブルに格納されます。 混乱を避けるために、今後のリリースでこの問題を解決する予定です。
テレメトリの種類
アプリケーションの実行を監視するには、次の種類のテレメトリが使用されます。 Azure Monitor OpenTelemetry Distro と Application Insights JavaScript SDK は次を収集します。
| テレメトリの種類 | テーブル名 (アプリケーション・インサイツ) |
テーブル名 (ログ分析) |
説明 |
|---|---|---|---|
| 可用性 | availabilityResults |
AppAvailabilityResults |
Web 要求を一定の間隔で送信し、アプリケーションが応答していない場合や応答時間が遅すぎる場合に警告することで、アプリケーションの可用性と応答性を監視します。 |
| ブラウザーのタイミング | browserTimings |
AppBrowserTimings |
ページの読み込み時間やネットワーク期間など、Web ページのパフォーマンスを測定します。 |
| 依存関係 | dependencies |
AppDependencies |
REST API や SQL データベースなどの外部サービスまたはストレージへのアプリケーションからの呼び出しを追跡し、これらの呼び出しの期間と成功を測定します。 |
| イベント | customEvents |
AppEvents |
通常、使用パターンを分析するために、ユーザーの操作やその他の重要な発生 (ボタンのクリックや注文のチェックアウトなど) をキャプチャするために使用されます。 |
| 例外 | exceptions |
AppExceptions |
エラーのトラブルシューティングと理解に不可欠なエラー情報をキャプチャします。 |
| メトリック | performanceCounterscustomMetrics |
AppPerformanceCountersAppMetrics |
パフォーマンス カウンターは、CPU 使用率やメモリ消費量など、アプリケーションとシステムのパフォーマンスのさまざまな側面に関する数値データを提供します。 さらに、カスタム メトリックを使用すると、アプリケーションに固有の特定の測定値を定義および追跡できるため、カスタム パフォーマンス インジケーターを柔軟に監視できます。 |
| ページ ビュー | pageViews |
AppPageViews |
ユーザーが表示したページを追跡し、アプリケーション内のユーザー ナビゲーションとエンゲージメントに関する分析情報を提供します。 |
| 依頼 | requests |
AppRequests |
アプリケーションが受信した要求をログに記録し、操作 ID、期間、成功または失敗の状態などの詳細を提供します。 |
| トレース | traces |
AppTraces |
アプリケーション固有のイベント (カスタム診断メッセージやトレース ステートメントなど) をログに記録します。これは、時間の経過に伴うアプリケーションの動作のデバッグと監視に役立ちます。 |
重要
Application Insights と Log Analytics (推奨) の両方からアプリケーション テレメトリにクエリを実行できますが、テーブル名とフィールド名は異なります。 この区別により、旧バージョンとの互換性が維持されます。たとえば、Log Analytics の名前付け規則の前に作成されたカスタム クエリを含む顧客ダッシュボードが引き続き正しく機能するようにします。
Azure portal でフィールド名を比較するには、 Application Insights>Logs を開き、クエリを実行し、テレメトリ項目の Id ( 1234a5b6c7de8f90 など) をコピーします。 次に、ブラウザーで新しいタブを開き、 Log Analytics>Logs に移動し、 KQL モードに切り替えて、クエリを実行します。
AppDependencies // Notice that table names are also different.
| where Id == "1234a5b6c7de8f90"
各行の左側にあるシェブロンを選択して両方のテレメトリ項目を展開し、すべてのプロパティを表示します。
各テレメトリ項目には、アプリケーションのバージョンやユーザー セッション ID などの コンテキスト情報 を含めることができます。 コンテキストは、さまざまな分析シナリオを可能にする厳密に型指定されたフィールドのセットで構成されます。
たとえば、アプリケーションのバージョンが適切に初期化されると、Application Insights は再デプロイと関連付けられたアプリケーション動作の新しいパターンを検出できます。 同様に、セッション ID を使用して、障害や問題がユーザーに与える影響を評価できます。 失敗した依存関係、エラー トレース、または重大な例外に関連付けられている一意のセッション ID の数を計算することで、ユーザーへの影響をより明確に把握できます。
Application Insights テレメトリ モデルでは、所属する操作に 対するテレメトリ項目の関連付 けもサポートされています。 たとえば、要求によって SQL Database 呼び出しがトリガーされた場合、要求と依存関係の呼び出しの両方に診断データを含め、共有の関連付けコンテキストを介してリンクできるため、操作の完全なフローをトレースできます。
この記事では、各テレメトリの種類に固有のフィールドについて説明します。 テレメトリの種類に関して使用可能なフィールド (コンテキスト フィールドを含む) の完全な一覧を表示するには、各関連テーブルの下にあるリンクに従います。
可用性テレメトリ
可用性テレメトリには合成監視が含まれます。テストでは、アプリケーションが使用可能で応答性が高いかどうかを確認するために、ユーザーの操作をシミュレートします。 世界中のさまざまなポイントからアプリケーションの可用性を監視し、独自のテスト情報を Application Insights に送信するように 、標準の可用性 テストを設定することをお勧めします。
可用性固有のフィールド:
| フィールド名 (アプリケーション・インサイツ) |
フィールド名 (ログ分析) |
説明 |
|---|---|---|
id |
Id |
可用性テスト結果の一意の識別子。個々のテスト実行間の相関関係に使用されます。これは、時間の経過に伴う特定のエラーまたはパターンのトレースに役立ちます。 詳細については、「 Application Insights のテレメトリの相関関係」を参照してください。 |
name |
Name |
可用性テストの名前。 テストの作成時に定義されます (例: "Homepage ping test")。 |
___location |
Location |
可用性テストの実行元の地理的な場所またはデータ センター リージョン (米国西部、北ヨーロッパなど)。 これは、リージョンの停止や待機時間の問題を特定するのに役立ちます。 |
success |
Success |
このフィールドは、可用性テストが成功したかどうかを示します。 これはブール値であり、 true はテストが成功したことを意味し、 false は失敗したことを意味します。 |
message |
Message |
テストの結果に関する詳細を含む説明メッセージ。 多くの場合、例外の詳細またはエラー応答が含まれています。 |
duration |
Duration |
可用性テストの実行にかかった時間。 パフォーマンスの測定と応答時間の問題の特定に役立ちます。 通常、期間はミリ秒単位で測定されます。 |
使用可能なすべてのフィールドの一覧については、「 AppAvailabilityResults」を参照してください。
ウェブブラウザのタイミングテレメトリ
ブラウザーは 、パフォーマンス API を使用してページ読み込みアクションの測定値を公開します。 Application Insights は、関連するタイミングを 標準のブラウザー メトリックに統合することで、これらの測定を簡略化します。
ブラウザータイミング固有のフィールド:
| フィールド名 (アプリケーション・インサイツ) |
フィールド名 (ログ分析) |
説明 |
|---|---|---|
networkDuration |
NetworkDurationMs |
クライアントは DNS にアクセスして Web サイトのホスト名を解決し、DNS は IP アドレスで応答します。 クライアントは TCP を作成してから、Web サーバーとの TLS ハンドシェイクを作成します。 |
sendDuration |
SendDurationMs |
クライアントは要求ペイロードを送信し、サーバーが要求を実行するのを待機し、最初の応答パケットを受信します。 |
receiveDuration |
ReceiveDurationMs |
クライアントは、残りの応答ペイロード バイトを Web サーバーから受信します。 |
processingDuration |
ProcessingDurationMs |
クライアントは完全な応答ペイロードを持つようになり、コンテンツをブラウザーにレンダリングして DOM を読み込む必要があります。 |
totalDuration |
TotalDurationMs |
すべてのブラウザーのタイミングの合計。 |
使用可能なすべてのフィールドの一覧については、 AppBrowserTimings を参照してください。
依存関係テレメトリ
依存関係テレメトリ項目は、監視対象コンポーネントと SQL や HTTP エンドポイントなどのリモート コンポーネントの相互作用を表します。
依存関係固有のフィールド:
| フィールド名 (アプリケーション・インサイツ) |
フィールド名 (ログ分析) |
説明 |
|---|---|---|
id |
Id |
依存関係呼び出しインスタンスの一意識別子。この依存関係呼び出しに対応する要求テレメトリ項目との関連付けに使用されます。 詳細については、「 Application Insights のテレメトリの相関関係」を参照してください。 |
target |
Target |
依存関係呼び出しのターゲット サイト。 例: サーバー名およびホスト アドレス。 詳細については、「 Application Insights のテレメトリの相関関係」を参照してください。 |
type |
DependencyType |
依存関係の種類の名前。 これには、依存関係を論理的にグループ化するための小さなカーディナリティの値と、commandName や resultCode のようなフィールドの変換が含まれます。 例: SQL、Azure テーブル、HTTP。 |
name |
Name |
この依存関係呼び出しで開始されたコマンドの名前。 小さなカーディナリティの値です。 例として、ストアド プロシージャ名と URL パス テンプレートがあります。 |
data |
Data |
この依存関係呼び出しによって開始されるコマンド。 例: すべてのクエリ パラメーターを使用する SQL ステートメントと HTTP URL。 |
success |
Success |
このフィールドは、呼び出しが成功したかどうかを示します。 これはブール値であり、 true は呼び出しが成功したことを意味し、 false は失敗したことを意味します。 |
resultCode |
ResultCode |
依存関係呼び出しの結果コード。 例: SQL エラー コードと HTTP 状態コード。 |
duration |
DurationMs |
要求の期間は DD.HH:MM:SS.MMMMMM という形式です。 1000 日未満である必要があります。 |
使用可能なすべてのフィールドの一覧については、「 AppDependencies」を参照してください。
イベント テレメトリ
アプリケーションで発生したイベントを表すイベント テレメトリ項目を作成できます。 通常は、ボタンのクリックや注文のチェックアウトなどのユーザーの操作です。 初期化や構成の更新などのアプリケーション ライフ サイクル イベントの場合もあります。
カスタム イベント テレメトリの作成の詳細については、「 .NET、Java、Node.js、Python アプリケーション用の Azure Monitor OpenTelemetry の追加と変更」を参照してください。
イベント固有のフィールド:
| フィールド名 (アプリケーション・インサイツ) |
フィールド名 (ログ分析) |
説明 |
|---|---|---|
name |
Name |
適切なグループ化と有用なメトリックを許可するには、アプリケーションを制限して、いくつかの個別のイベント名が生成されるようにします。 たとえば、1 つのイベントで生成されるインスタンスごとに別の名前を使用しないでください。 |
使用可能なすべてのフィールドの一覧については、「 AppEvents」を参照してください。
例外テレメトリ
例外テレメトリ項目は、監視対象アプリケーションの実行中に発生した処理済みまたはハンドルされない例外を表します。
例外固有のフィールド:
| フィールド名 (アプリケーション・インサイツ) |
フィールド名 (ログ分析) |
説明 |
|---|---|---|
problemId |
ProblemId |
コード内で例外が発生した箇所を特定します。 例外をグループ化するために使用されます。 通常は、例外の種類と呼び出し履歴の関数との組み合わせです。 |
type |
ExceptionType |
発生した特定の種類の例外。 これには通常、 System.NullReferenceException や System.InvalidOperationExceptionなどの名前空間とクラス名が含まれます。 |
assembly |
Assembly |
例外がスローされたアセンブリ。 これは、例外を担当するアプリケーションのコンポーネントを特定するのに役立ちます。 |
method |
Method |
例外がスローされたアセンブリ内のメソッド名。 これにより、エラーが発生したコード内の場所に関するコンテキスト情報が提供されます。 |
outerType |
OuterType |
現在の例外が別の例外内に入れ子になっている場合、外側の (ラップしている) 例外の型。 これは、内部例外が発生したコンテキストを理解するのに役立ち、一連のエラーのトレースに役立ちます。 |
outerMessage |
OuterMessage |
このメッセージは、外部例外の人間が判読できる説明を提供し、より広範な問題を理解するのに役立ちます。 |
outerAssembly |
OuterAssembly |
外部例外が発生したアセンブリ。 |
outerMethod |
OuterMethod |
外部例外のメソッド。 これにより、外部例外内の障害点に関する詳細情報が提供されます。 |
severityLevel |
SeverityLevel |
トレースの重大度レベルには、 Verbose、 Information、 Warning、 Error、または Criticalのいずれかの値を指定できます。 |
details |
Details |
例外メッセージや呼び出し履歴などの例外情報が含まれます。 |
使用可能なすべてのフィールドの一覧については、「 AppExceptions」を参照してください。
メトリック テレメトリ
Application Insights では、次の 2 種類のメトリック テレメトリがサポートされています。
- 1 つの測定値には名前と値があります。
- 事前集計メトリックは、1 分間の集計期間に複数の測定値を受け取ります。
性能カウンター
パフォーマンス カウンターは、常に name と valueを持つ単一の測定メトリックですが、 category、 counter、および Windows アプリケーション用の追加のフィールドも instance。
パフォーマンス カウンター固有のフィールド:
| フィールド名 (アプリケーション・インサイツ) |
フィールド名 (ログ分析) |
説明 |
|---|---|---|
name |
Name |
Application Insights ポータルに表示するメトリックの名前。 |
value |
Value |
測定の単一値。 これは、集計での個別の測定値の合計です。 |
category |
Category |
関連するパフォーマンス カウンターのグループ (たとえば、 Process) を表します。 |
counter |
Counter |
カテゴリ内で測定される特定のパフォーマンス メトリック (たとえば、 IO Data Bytes/sec) を指定します。 |
instance |
Instance |
カテゴリ (たとえば、 ??APP_WIN32_PROC??) 内のカウンターの特定の発生を識別します。 |
使用可能なすべてのフィールドの一覧については、「 AppPerformanceCounters」を参照してください。
メトリックの詳細については、「 Application Insights のメトリック」を参照してください。 メトリック REST API の詳細については、「 メトリック - 取得」を参照してください。
システムカウンターとプロセスカウンターのメトリック
| .NET の名前 | 説明 |
|---|---|
\Processor(_Total)\% Processor Time |
コンピューターの CPU の合計。 |
\Memory\Available Bytes |
コンピューターで実行されているプロセスが利用できる物理メモリの量をバイト単位で表示します。 これは、ゼロ メモリ、空きメモリ、スタンバイ メモリの一覧の領域を合計することで計算されます。 空きメモリはメモリを使用する準備が整っているメモリです。 ゼロ メモリはゼロで満たされたメモリのページで構成されており、後続のプロセスが、前のプロセスによって使用されたデータを見ることができないようにします。 スタンバイ メモリは、ディスクへのルート上でプロセスのワーキング セット (物理メモリ) から削除されたメモリですが、引き続き再度呼び出すことができます。 メモリ オブジェクトを参照してください。 |
\Process(??APP_WIN32_PROC??)\% Processor Time |
アプリケーションをホストするプロセスの CPU。 |
\Process(??APP_WIN32_PROC??)\Private Bytes |
アプリケーションをホストするプロセスで使用されるメモリ。 |
\Process(??APP_WIN32_PROC??)\IO Data Bytes/sec |
アプリケーションをホストしているプロセスで実行される I/O 操作の速度。 |
\ASP.NET Applications(??APP_W3SVC_PROC??)\Requests/Sec |
アプリケーションによって処理された要求の割合。 |
\.NET CLR Exceptions(??APP_CLR_PROC??)\# of Exceps Thrown / sec |
アプリケーションによってスローされた例外の割合。 |
\ASP.NET Applications(??APP_W3SVC_PROC??)\Request Execution Time |
平均要求実行時間。 |
\ASP.NET Applications(??APP_W3SVC_PROC??)\Requests In Application Queue |
キューで処理を待っている要求の数。 |
カスタム プロパティ
カスタム プロパティ CustomPerfCounter が true に設定されたメトリックは、メトリックが Windows パフォーマンス カウンターを表すことを示します。 これらのメトリックは、customMetrics ではなく performanceCounters テーブルに配置されます。 また、このメトリックの名前は、カテゴリ、カウンター、インスタンスの名前を抽出するために解析されます。
カスタム メトリック
カスタム メトリックは、標準メトリックでカバーされていない分析情報を得るために定義して収集するパフォーマンス インジケーターまたはビジネス固有のメトリックです。 カスタム メトリックの詳細については、 Azure Monitor のカスタム メトリック (プレビュー) を参照してください。
カスタム メトリック固有のフィールド:
| フィールド名 (アプリケーション・インサイツ) |
フィールド名 (ログ分析) |
単一測定 | 事前集計メトリック |
|---|---|---|---|
name |
Name |
このフィールドは、Application Insights ポータルと UI に表示するメトリックの名前です。 | |
value |
Value |
このフィールドは、測定の単一の値です。 これは、集計での個別の測定値の合計です。 | 事前集計メトリックの場合、 値 は Sum と等しくなります。 |
Max |
Max |
1 つの測定メトリックの場合、 最大値 は Value と等しくなります。 | このフィールドは、集計メトリックの最大値です。 測定には設定しないでください。 |
Min |
Min |
1 つの測定メトリックの場合、 最小値 は 値と等しくなります。 | このフィールドは、集計メトリックの最小値です。 測定には設定しないでください。 |
Sum |
Sum |
1 つの測定メトリックの場合、 Sum は Value と等しくなります。 | 集計されたメトリックのすべての値の合計。 測定には設定しないでください。 |
Count |
Count |
1 つの測定メトリックの場合、 Count は 1。 |
1 分間の集計期間の測定値の数。 測定には設定しないでください。 |
使用可能なすべてのフィールドの一覧については、「 AppMetrics」を参照してください。
注意
平均を計算するには、 Sum を Count で除算します。
ページ ビュー テレメトリ
アプリケーション ユーザーが監視対象アプリケーションの新しいページを開くと、ページ ビューテレメトリがログに記録されます。 ここでいう Page とは、開発者がアプリケーションのタブや画面として定義した論理単位であり、必ずしもブラウザーの Web ページの読み込みや更新の動作とは関連性がありません。
この違いは、ページ間の切り替えがブラウザーのページ操作に縛られないシングルページ アプリケーション (SPA) のコンテキストでさらに理解することができます。 pageViews.duration は、アプリケーションがユーザーにページを表示するのにかかる時間です。
ページビュー固有のフィールド:
| フィールド名 (アプリケーション・インサイツ) |
フィールド名 (ログ分析) |
説明 |
|---|---|---|
name |
Name |
ユーザーが表示したページの名前 ( "Home" や "Shopping Cart"など)。 |
url |
Url |
表示されたページの完全な URL。 このフィールドは、アプリケーション全体のトラフィックとユーザーの動作を分析するために重要です。 |
duration |
DurationMs |
PageView の期間は、ブラウザーのパフォーマンス タイミング インターフェイスである PerformanceNavigationTiming.duration から取得されます。PerformanceNavigationTiming がある場合は、その期間が使用されます。 そうでない場合は、 非推奨PerformanceTiming インターフェイスが使用され、 NavigationStart と LoadEventEnd 間の差分が計算されます。開発者は、 PageViewを使用してカスタム イベントをログに記録するときの期間値を指定します。 |
使用可能なすべてのフィールドの一覧については、「 AppPageViews」を参照してください。
注意
既定では、Application Insights JavaScript SDK では、ブラウザーの各 Web ページの読み込みアクションで単一の
PageViewイベントがログに記録され、pageViews.durationブラウザーのタイミングによって設定されます。 開発者は、PageViewを使用して、 イベントの追加の追跡を拡張できます。ログは既定で 30 日間保持されます。 長期間の
PageViewの統計情報を表示する場合は、設定を調整する必要があります。
テレメトリを要求する
要求テレメトリは、アプリケーションへの受信 HTTP 要求に関連する情報を表します。 この種類のテレメトリは、アプリケーションの Web ベースサービスのパフォーマンスと成功を監視するのに役立ちます。 要求テレメトリ項目は、アプリケーションへの外部要求によってトリガーされる実行の論理シーケンスを表します。 すべての要求の実行は、一意の id と、すべての実行パラメーターが含まれる url によって識別されます。
要求は、論理的な name によってグループ化でき、要求の source が定義されます。 コードの実行は、success または failという結果になる可能性があり、特定の duration を持っています。 resultCode を使用して、成功と失敗の実行をさらにグループ化することができます。 要求テレメトリの開始時刻は、エンベロープ レベルで定義されます。 要求テレメトリでは、 カスタム properties と measurementsを使用して、標準の機能拡張モデルがサポートされます。
要求固有のフィールド:
| フィールド名 (アプリケーション・インサイツ) |
フィールド名 (ログ分析) |
説明 |
|---|---|---|
id |
Id |
要求と他のテレメトリ項目を関連付けるために使用される、要求コールインスタンスのユニークな識別子。 ID はグローバルに一意である必要があります。 詳細については、「 Application Insights のテレメトリの相関関係」を参照してください。 |
source |
Source |
ソースは要求のソースです。 たとえば、呼び出し元のインストルメンテーション キーや呼び出し元の IP アドレスです。 詳細については、「 Application Insights のテレメトリの相関関係」を参照してください。 |
name |
Name |
このフィールドは、要求の名前であり、要求を処理するために使われたコード パスを表します。 小さなカーディナリティの値を使うと、要求をより適切にグループ化できます。 HTTP 要求では、これは、実際の id 値ではなく、GET /values/{id}のような HTTP メソッドと URL パス テンプレートを表します。Application Insights Web SDK は、文字の大文字と小文字は "そのまま" で要求名を送信します。 UI では大文字と小文字を区別してグループ化されるため、 GET /Home/Index と GET /home/INDEX は別々にカウントされます (多くの場合、これらは同じコントローラーとアクションの実行に至ります)。 その理由は、一般的に URL では大文字と 小文字が区別されるためです。 すべての 404 エラーが、大文字で入力された URL に対して発生したのかどうかを確認することをお勧めします。 ASP.NET Web SDK による要求名の収集の詳細については、 ブログ記事を参照してください。 |
url |
Url |
URL はすべてのクエリ文字列パラメーター付きの要求 URL です。 |
success |
Success |
成功は、呼び出しが成功したか失敗したかを示します。 このフィールドは必須です。 要求が明示的に false に設定されない場合は、成功したとみなされます。 例外または返されたエラー結果コードによって操作が中断された場合は、この値を false に設定します。Web アプリケーションでは、応答コードが 400 未満または 401 に相当する場合は、Application Insights によって要求は成功と定義されます。 ただし、この既定のマッピングが、アプリケーションのセマンティックと一致しない場合があります。応答コード 404 は、通常のフローの一部になることができる "レコードなし" を示していることがあります。 それは、リンクが壊れていることを示していることもあります。 リンクが壊れている場合は、さらに高度なロジックを実装することもできます。 URL の参照元を分析してリンクが同じサイトに配置されている場合のみ、壊れたリンクをエラーとマークすることができます。 または、会社のモバイル アプリケーションからアクセスされた場合にエラーとマークできます。 同様に、301 と 302 は、リダイレクトをサポートしていないクライアントからアクセスされた場合のエラーを示します。コンテンツを一部受け入れる 206 が、要求全体のエラーを示していることがあります。 たとえば、Application Insights のエンドポイントがテレメトリ項目のバッチを 1 つの要求として受信している場合です。 バッチ内の一部の項目が正常に処理されなかった場合、206 が返されます。 206 の割合の上昇は、調査する必要がある問題の存在を示唆しています。 同様のロジックが 207 マルチステータスにも適用され、複数の応答コードの中で、最も悪いステータスが "成功" である場合があります。 |
resultCode |
ResultCode |
応答コードは要求実行の結果です。 HTTP 要求の HTTP 状態コードです。 他の要求の種類では、HRESULT 値や例外の種類になることがあります。 |
duration |
DurationMs |
要求の期間は DD.HH:MM:SS.MMMMMM という書式です。 正の 1000 日未満の値にする必要があります。 要求テレメトリは開始と終了によって操作を表すため、このフィールドは必須です。 |
使用可能なすべてのフィールドの一覧については、 AppRequests を参照してください。
トレース テレメトリ
トレーステレメトリは、printfスタイルのテキスト検索用トレースステートメントを示します。 Log4Net、NLog、およびその他のテキスト ベースのログ ファイルのエントリは、この型のインスタンスに変換されます。 トレースには、機能拡張としての測定はありません。
トレース固有のフィールド:
| フィールド名 (アプリケーション・インサイツ) |
フィールド名 (ログ分析) |
説明 |
|---|---|---|
message |
Message |
トレース メッセージ。 |
severityLevel |
SeverityLevel |
トレース重大度レベル。 |
使用可能なすべてのフィールドの一覧については、「 AppTraces」を参照してください。
注意
severityLevelの値は列挙され、プラットフォーム固有です。
カスタム プロパティと測定値
カスタム プロパティ
カスタム プロパティの名前と値のコレクション: このコレクションは、カスタム ディメンションを使用して標準テレメトリを拡張するために使用されます。 例として、注文番号など、テレメトリまたはテレメトリ項目に固有のプロパティを生成したデプロイ スロットがあります。
- 最大キー長: 150
- 最大値の長さ: 8,192
カスタム測定値
カスタム測定のコレクション: このコレクションを使用して、テレメトリ項目に関連付けられている名前付き測定値を報告します。 一般的なユース ケースは次のとおりです。
- 依存関係テレメトリのペイロードのサイズ。
- 要求テレメトリによって処理されるキュー項目の数。
- 顧客がイベント テレメトリの完了ウィザードの手順を完了するのにかかった時間。
Application Analytics でカスタム測定値のクエリを実行できます。
customEvents
| where customMeasurements != ""
| summarize avg(todouble(customMeasurements["Completion Time"]) * itemCount)
注意
- カスタム測定値は、属するテレメトリ項目に関連付けられています。 それらは、測定値が含まれるテレメトリ項目のサンプリング対象になります。 他のテレメトリの種類から独立した値を持つ測定値を追跡するには、 メトリック テレメトリを使用します。
- カスタム測定値には文字列値を使用しないでください。 数値のみがサポートされています。
最大キー長: 150
コンテキスト
すべてのテレメトリ項目は、厳密に型指定されたコンテキストのフィールドを持つことができます。 すべてのフィールドで特定の監視シナリオが可能です。 カスタム プロパティのコレクションを使用して、カスタムまたはアプリケーション固有のコンテキスト情報を格納します。
| フィールド名 (アプリケーション・インサイツ) |
フィールド名 (ログ分析) |
説明 |
|---|---|---|
account_ID |
user_AccountId |
マルチテナント アプリケーションのアカウント ID は、ユーザーが操作しているテナント アカウントの ID または名前です。 これは、ユーザー ID と認証されたユーザー ID では十分でないときに、さらにユーザーをセグメント化するために使用されます。 たとえば、Azure portal のサブスクリプション ID やブログ プラットフォームのブログ名などがあります。 |
application_Version |
AppVersion |
アプリケーション コンテキスト フィールドの情報は必ず、テレメトリを送信しているアプリケーションに関するものです。 アプリケーションのバージョンは、アプリケーションの動作の傾向変化、およびデプロイとのその相関関係を分析するために使用されます。 |
appId |
ResourceGUID |
さまざまなアプリケーションからテレメトリを区別するための Application Insights リソースの一意の識別子。 |
appName |
なし | Application Insights では、 appName は _ResourceIdと同じです。 |
client_Browser |
ClientBrowser |
クライアントによって使用される Web ブラウザーの名前。 |
client_City |
ClientCity |
テレメトリの収集時にクライアントが配置された市区町村 (IP 位置情報に基づく)。 |
client_CountryOrRegion |
ClientCountryOrRegion |
テレメトリの収集時にクライアントが配置された国またはリージョン (IP 位置情報に基づく)。 |
client_IP |
ClientIP |
クライアント デバイスの IP アドレス。 IPv4 と IPv6 がサポートされています。 サービスからテレメトリが送信されるときのロケーション コンテキストは、サービスで操作を開始したユーザーに関するものです。 Application Insights は、クライアント IP から地理的な場所の情報を抽出し、それを切り捨てます。 クライアント IP は、単独ではユーザーを特定できる情報として使用できません。 |
client_OS |
ClientOS |
テレメトリを生成したクライアントのオペレーティング システムを示します。 |
client_StateorProvince |
ClientStateOrProvince |
テレメトリが収集されたときにクライアントが存在した州または都道府県 (IP 位置情報に基づく)。 |
client_Type |
ClientType |
テレメトリを送信したクライアント デバイスの種類 ( Browser や PCなど) について説明します。 |
cloud_RoleInstance |
AppRoleInstance |
アプリケーションが実行されているインスタンスの名前。 たとえば、オンプレミスのコンピューター名や、Azure のインスタンス名です。 |
cloud_RoleName |
AppRoleName |
アプリケーションが一部であるロールの名前。 これは、Azure 内のロール名に直接マップされます。 単一のアプリケーションの一部であるマイクロ サービスを区別するために使用することもできます。 |
iKey |
IKey |
テレメトリ データと特定の Application Insights リソースを関連付けるために使われるレガシ一意識別子。 |
itemId |
なし | 特定のテレメトリ項目を表す一意識別子。 |
itemCount |
ItemCount |
1 つのテレメトリ イベントに関連付けられた発生回数またはカウント数。 |
operation_Id |
OperationId |
ルート操作を表す一意識別子。 この識別子を使用すると、複数のコンポーネントでテレメトリをグループ化できます。 詳細については、「 テレメトリの相関関係」を参照してください。 要求またはページ ビューのいずれかによって、操作 ID が作成されます。 その他のすべてのテレメトリは、含まれている要求またはページ ビューの値でこのフィールドを設定します。 |
operation_Name |
OperationName |
操作の名前 (グループ)。 要求またはページ ビューのいずれかによって、操作名が作成されます。 その他のすべてのテレメトリ項目は、含まれている要求またはページ ビューの値でこのフィールドを設定します。 操作の名前は、操作のグループ (たとえば、GET Home/Index) のすべてのテレメトリ項目を検索するために使用されます。 このコンテキスト プロパティは、このページでスローされる典型的な例外は何か、といった質問に答えるために使用されます。 |
operation_ParentId |
ParentId |
テレメトリ項目の直接の親を表す一意識別子。 詳細については、「 テレメトリの相関関係」を参照してください。 |
operation_SyntheticSource |
SyntheticSource |
合成ソースの名前。 アプリケーションからのテレメトリの一部は、合成トラフィックを表すことがあります。 これは、Web サイトにインデックスを付ける Web クローラー、サイトの可用性のテスト、Application Insights SDK 自体のような診断ライブラリからのトレースである可能性があります。 |
sdkVersion |
SDKVersion |
テレメトリ データを送信している Application Insights SDK のバージョン。 詳細については、 SDK のバージョンを参照してください。 |
session_Id |
SessionId |
セッション ID は、ユーザーとアプリのやり取りのインスタンスです。 セッション コンテキスト フィールドの情報は、必ずユーザーに関するものです。 サービスからテレメトリが送信されるときのセッション コンテキストは、サービスで操作を開始したユーザーに関するものです。 |
user_AuthenticatedId |
UserAuthenticatedId |
認証されたユーザー ID は、匿名ユーザー ID とは正反対です。 このフィールドは、フレンドリ名を持つユーザーを表します。 この ID が既定で収集されるのは、ASP.NET Framework SDK の AuthenticatedUserIdTelemetryInitializer のみです。Application Insights SDK を使用して、ブラウザーとデバイスにまたがってユーザーを永続的に識別する値で、認証されたユーザー ID を初期化します。 このようにすることで、すべてのテレメトリ項目が、その一意の ID に帰属します。 この ID を使用すると、特定のユーザーに対して収集されたすべてのテレメトリに対してクエリを実行できます ( サンプリング構成 と テレメトリ フィルター処理の対象)。 ユーザー ID をセッション ID と相互参照して、一意のテレメトリ ディメンションを提供し、セッション期間中のユーザー アクティビティを確立できます。 |
user_Id |
UserId |
匿名ユーザー ID は、アプリケーションのユーザーを表します。 サービスからテレメトリが送信されるときのユーザー コンテキストは、サービスで操作を開始したユーザーに関するものです。 サンプリング は、収集されたテレメトリの量を最小限に抑える手法の 1 つです。 サンプリング アルゴリズムは、相関関係を持つテレメトリをすべて対象として、またはすべてを対象外としてサンプリングを試行します。 匿名ユーザー ID はサンプリング スコアの生成に使用されるため、匿名ユーザー ID は十分にランダムな値である必要があります。 匿名ユーザー ID の数は、一意のアプリケーション ユーザーの数と同じではありません。 ユーザーが別のデバイスやブラウザーでアプリを開いたり、ブラウザーの Cookie を消去したりするたびに、新しい一意の匿名ユーザー ID が割り当てられるため、匿名ユーザー ID の数は、より多くなるのが一般的です。 この計算では、同じ物理ユーザーが複数回カウントされる可能性があります。 ユーザー ID をセッション ID と相互参照して、一意のテレメトリ ディメンションを提供し、セッション期間中のユーザー アクティビティを確立できます。 匿名ユーザー ID を使用してユーザー名を格納することは、フィールドの不正使用になります。 認証されたユーザー ID を使用してください。 |
_ResourceId |
_ResourceId |
サブスクリプション、リソース グループ、リソース名を含む、Application Insights コンポーネントの完全な Azure リソース ID。 |
次のステップ
- よく寄せられる質問 (FAQ) を確認する: テレメトリ データ モデルに関する FAQ
- Application Insights でサポートされている プラットフォーム を確認してください。
- Azure Monitor OpenTelemetry Distro を使用してカスタム テレメトリを収集する方法について説明します。
- カスタム イベントとメトリックに Application Insights API を使用する方法について説明します。
- テレメトリを拡張およびフィルター処理する方法について説明します。
- サンプリングを使用して、データ モデルに基づいてテレメトリの量を最小限に抑える方法について説明します。