Application Insights のログベースのメトリックと事前に集計されたメトリック
Note
以下のドキュメントは、Application Insights クラシック API に関するものです。 Application Insights の長期的な計画は、OpenTelemetry を使用してデータを収集することです。 詳しくは、「.NET、Node.js、Python、Java アプリケーション用の Azure Monitor OpenTelemetry を有効にする」をご覧ください。
この記事では、ログに基づく "従来の" Application Insights メトリックと、事前に集計されたメトリックとの違いについて説明します。 Application Insights ユーザーは、どちらの種類のメトリックも使用できます。 それぞれ、アプリケーションの正常性の監視、診断、分析において独自の価値があります。 アプリケーションをインストルメント化している開発者の場合は、特定のシナリオに最適なメトリックの種類を判断できます。 判断は、アプリケーションのサイズ、予想されるテレメトリの量、メトリックの精度とアラートに関するビジネス要件に基づいて行います。
ログベースのメトリック
これまで、Application Insights でテレメトリ データ モデルを監視するアプリケーションは、要求、例外、依存関係呼び出し、ページ ビューなど、事前に定義された種類の少数のイベントのみに基づいていました。 開発者は、SDK を明示的に呼び出すコードを記述することで、SDK を使ってこれらのイベントを手動で発行できます。 また、自動インストルメンテーションによるイベントの自動収集を利用することもできます。 いずれの場合も、Application Insights のバックエンドにより、収集したすべてのイベントはログに格納されます。 Azure portal の [Application Insights] ペインは、ログからのイベントベースのデータを視覚化するための分析および診断ツールとして機能します。
ログを使用してイベントの完全なセットを保持することで、優れた分析および診断の値が得られます。 たとえば、特定の URL に対する要求の正確な数と、これらの呼び出しを行った個別のユーザーの数を取得できます。 また、任意のユーザー セッションの例外や依存関係呼び出しを含む、詳細な診断トレースを取得できます。 この種の情報があると、アプリケーションの正常性と使用状況を確認しやすくなります。 また、アプリに関する問題を診断するのに必要な時間を短縮することもできます。
それと同時に、イベントの完全なセットを収集することは、大量のテレメトリを生成するアプリケーションには実用的でない、または不可能である場合があります。 イベントの量が多くなりすぎた場合、Application Insights にはテレメトリ量の削減手法がいくつか実装されており、これを利用して、収集および格納されるイベント数を減らすことができます。 これらの手法にはサンプリングとフィルター処理が含まれています。 残念ながら、格納イベントの数を減らすと、ログに格納されるイベントのクエリ時間集計をバックグラウンドで行う必要があるメトリックの精度も下がります。
Note
Application Insights では、ログに格納されているイベントと測定値のクエリ時間集計に基づくメトリックのことを、ログベースのメトリックといいます。 通常、これらのメトリックには、イベント プロパティによる多数のディメンションがあるため、分析に適しています。 サンプリングとフィルター処理によって、これらのメトリックの精度が低下する可能性があります。
事前に集計されたメトリック
ログベースのメトリックに加え、2018 年後半に、Application Insights チームによってパブリック プレビュー版のメトリックが提供されました。このメトリックは、時系列に最適化された特殊なリポジトリに格納されます。 新しいメトリックは、多くのプロパティを含む個々のイベントとして保持されなくなりました。 代わりに、事前に集計された時系列として格納され、主なディメンションのみが含まれます。 この変更があるため、クエリ時は新しいメトリックの方が優れています。 データの取得が速くなり、必要なコンピューティング能力も少なくて済みます。 その結果、メトリックのディメンションに関するほぼリアルタイムのアラートや応答性の高いダッシュボードなど、新しいシナリオが有効になります。
重要
Application Insights では、ログベースのメトリックと事前に集計されたメトリックの両方が共存します。 この 2 つを区別するために、Application Insights ユーザー エクスペリエンスでは、事前に集計されたメトリックは標準メトリック (プレビュー) という名称になりました。 イベントからの従来のメトリックは、ログベースのメトリックに名称が変更されました。
新しい SDK (.NET 用の Application Insights 2.7 SDK 以降) では、収集時にメトリックが事前に集計されます。 このプロセスは既定で送信される標準メトリックに適用されるため、正確性がサンプリングやフィルター処理の影響を受けることはありません。 また、GetMetric を使用して送信されるカスタム メトリックにも適用されるため、データ インジェストが減り、コストが削減されます。
事前の集計を実装しない SDK の場合 (つまり、以前のバージョンの Application Insights SDK、またはブラウザー インストルメンテーションの場合)、Application Insights バックエンドでは引き続き、Application Insights イベント収集エンドポイントによって受信されるイベントを集計することで、新しいメトリックが設定されます。 ネットワーク経由で送信されるデータ量が減る利点はありませんが、引き続き事前に集計されたメトリックを使用できます。また、収集時にメトリックを事前に集計しない SDK でのほぼリアルタイムのディメンション アラートのパフォーマンスとサポートが向上します。
コレクション エンドポイントにより、インジェスト サンプリングの前にイベントが事前に集計されます。 このため、アプリケーションで使う SDK バージョンに関係なく、インジェスト サンプリングは事前に集計されたメトリックの精度に影響を与えることはありません。
SDK でサポートされている事前集計されたメトリック テーブル
| 現在の運用環境の SDK | 標準メトリック (SDK 事前集計) | カスタム メトリック (SDK 事前集計なし) | カスタム メトリック (SDK 事前集計あり) |
|---|---|---|---|
| .NET Core と .NET Framework | サポート対象 (V2.13.1 以降) | TrackMetric を介してサポート対象 | GetMetric を介してサポート対象 (V 2.7.2 以降) |
| Java | サポートされていません | TrackMetric を介してサポート対象 | サポートされていません |
| Node.js | サポート対象 (V2.0.0 以降) | TrackMetric を介してサポート対象 | サポートされていません |
| Python | サポートされていません | サポートされています | OpenCensus.stats を介して部分的にサポート対象 |
Note
OpenCensus を使用した Python のメトリックの実装は、GetMetric とは異なります。 詳細については、Python のメトリックに関するドキュメントを参照してください。
コード不要でサポートされる事前集計されたメトリック テーブル
| 現在の運用環境の SDK | 標準メトリック (SDK 事前集計) | カスタム メトリック (SDK 事前集計なし) | カスタム メトリック (SDK 事前集計あり) |
|---|---|---|---|
| ASP.NET | サポート対象 1 | サポートされていません | サポートされていません |
| ASP.NET Core | サポート対象 2 | サポートされていません | サポートされていません |
| Java | サポートされていません | サポートされていません | サポートされています |
| Node.js | サポートされていません | サポートされていません | サポートされていません |
- 仮想マシン、仮想マシン スケール セット、オンプレミス上の ASP.NET コードレス アタッチにより、ディメンションなしの標準メトリックが出力されます。 Azure App Service の場合と同じですが、コレクション レベルを推奨に設定する必要があります。 すべてのディメンションに SDK が必要です。
- App Service での ASP.NET Core コード不要アタッチでは、ディメンションのない標準メトリックが出力されます。 すべてのディメンションに SDK が必要です。
Application Insights カスタム メトリックで事前集計を使う
カスタム メトリックで事前集計を使用することができます。 2 つの主な利点は次のとおりです。
- カスタム メトリックのディメンションを構成してアラートを生成する機能
- SDK から Application Insights コレクション エンドポイントに送信されるデータの量を減らす
Application Insights SDK からカスタム メトリックを送信する方法がいくつかあります。 お使いの SDK のバージョンで GetMetric と TrackValue を利用できる場合、カスタム メトリックを送信するときにこれらのメソッドを使うことをお勧めします。 この場合、事前集計は SDK 内で行われます。 このアプローチにより、Azure に格納されるデータ量を減らし、SDK から Application Insights に送信されるデータ量も減らすことができます。 それ以外の場合は、データ インジェスト中にメトリック イベントが事前に集計される trackMetric メソッドを使用します。
カスタム メトリックのディメンションと事前集計
OpenTelemetry、trackMetric、または GetMetric and TrackValue API 呼び出しを使用して送信するメトリックはすべて、ログとメトリック ストアの両方に自動的に格納されます。 これらのメトリックは、Application Insights の customMetrics テーブルと、メトリックス エクスプローラーの "azure.applicationinsights" という名前のカスタム メトリック名前空間にあります。 ログベース バージョンのカスタム メトリックでは常にすべてのディメンションが保持されますが、事前集計バージョンのメトリックは既定でディメンションなしで格納されます。 カスタム メトリックのディメンションの保持はプレビュー機能です。これを有効にするには、[使用量と推定コスト] タブで [カスタム メトリクスを Azure Metric Store に送信する] の下にある [ディメンションあり] を選択します。
Quotas (クォータ)
事前に集計されたメトリックは、Azure Monitor に時系列として格納されます。 [Azure Monitor quotas on custom metrics] (カスタム メトリックに対する Azure Monitor のクォータ) が適用されます。
Note
クォータを超えると、意図しない結果になることがあります。 サブスクリプションまたはリージョンで Azure Monitor の信頼性が低下する可能性があります。 クォータを超えないようにする方法については、「設計の制限と考慮事項」を参照してください。
既定でカスタム メトリック ディメンションの収集が無効になる理由
カスタム メトリック ディメンションの収集は既定でオフです。これは、将来的にディメンションと共にカスタム メトリックを保存したときに Application Insights とは別に課金されるからです。 非ディメンション カスタム メトリックの保存は引き続き無料です (クォータが上限です)。 今後の価格モデル変更の詳細については、Microsoft の公式の価格ページで確認できます。
グラフを作成して、ログベースのメトリックと標準の事前に集計されたメトリックを確認する
Azure Monitor メトリックス エクスプローラーを使用して、事前に集計されたメトリックとログベースのメトリックに基づいてグラフを描画し、そのグラフを使ってダッシュボードを作成します。 必要な Application Insights リソースを選んでから、名前空間ピッカーを使って標準 (プレビュー) メトリックとログベースのメトリックを切り替えます。 また、カスタム メトリックの名前空間を選ぶこともできます。
Application Insights メトリックの価格モデル
メトリックを Application Insights に取り込むと、ログベースか事前に集計されているかにかかわらず、取り込まれたデータのサイズに基づいてコストが発生します。 詳細については、Azure Monitorログの価格の詳細に関するページを参照してください。 カスタム メトリックは、そのすべてのディメンションを含めて、常に Application Insights ログ ストアに格納されます。 また、ディメンションのないカスタム メトリックの事前集計バージョンは、既定でメトリック ストアに転送されます。
[カスタム メトリック ディメンションに関するアラートを有効にします] オプションを選択して、事前に集計されたメトリックのすべてのディメンションをメトリック ストアに格納すると、カスタム メトリックの価格に基づいて追加のコストが生じる可能性があります。