ログベースのメトリックを検出する

Application Insights のログ ベースのメトリックを使用すると、監視対象のアプリの正常性の分析、強力なダッシュボードの作成、アラートの構成が行えます。 メトリックには次の 2 種類があります。

• ログベースのメトリックはバックグラウンドで、保存されたイベントから Kusto クエリに変換されます。
• 標準メトリック は、事前集計された時系列として格納されます。

標準メトリックは収集中に事前に集計されるため、クエリ時のパフォーマンスが向上します。 ダッシュボードやリアルタイム アラートには標準のメトリクスが推奨されます。 ログ ベースのメトリックのディメンションが多いため、データ分析とアドホック診断に優れたオプションになります。 名前空間セレクターを使用して、メトリックス エクスプローラーでログ ベースのメトリックと標準メトリックを切り替えます。

ログ ベースのメトリック

開発者は SDK を使用し、(SDK を明示的に呼び出すコードを記述することで) イベントを手動で送信することも、自動インストルメンテーションからのイベントの自動収集を利用することもできます。 どちらの場合も、Application Insights バックエンドは収集されたすべてのイベントをログとして格納し、Azure portal の Application Insights ブレードは、ログからイベントベースのデータを視覚化するための分析および診断ツールとして機能します。

ログを使用してイベントの完全なセットを保持すると、優れた分析と診断の値が得られます。 たとえば、特定の URL への要求の正確な数と、これらの呼び出しを行った個別のユーザーの数を取得できます。 また、任意のユーザー セッションの例外や依存関係の呼び出しを含む詳細な診断トレースを取得することもできます。 この種の情報を使用すると、アプリケーションの正常性と使用状況の可視性が大幅に向上し、アプリの問題を診断するために必要な時間を短縮できます。

同時に、大量のテレメトリを生成するアプリケーションでは、イベントの完全なセットを収集することが非現実的 (または不可能) な場合もあります。 イベントの量が多くなりすぎたら、Application Insights では、収集されて格納されたイベントの数を減らすためのサンプリングやフィルター処理など、テレメトリ量の削減手法がいくつか適用されます。 しかし残念ながら、格納されるイベントの数を減らすと、ログに格納されたイベントに対してクエリ時にバックグラウンドで集計を行う必要があるメトリックの精度も低下してしまいます。

事前集計されたメトリック

事前に集計されたメトリックは、たくさんのプロパティを持つ個々のイベントとしては保存されません。 代わりに、これらは事前集計された時系列として格納され、キー ディメンションでのみ格納されます。 この機能により、新しいメトリックはクエリ時に優れています。データの取得が高速化され、必要なコンピューティング能力が低下します。 また、メトリックのディメンションに関するほぼリアルタイムのアラート、応答性の高いダッシュボードなど、新しいシナリオも可能になります。

新しい SDK (.NET 用 Application Insights 2.7 SDK 以降) は、収集中にメトリックを事前に収集します。 これは、既定で送信される標準メトリック に適用されるため、精度はサンプリングやフィルター処理の影響を受けないようにします。 また、 GetMetric を使用して送信されるカスタム メトリックにも適用されるため、データ インジェストが少なくなり、コストが削減されます。

事前に集計しない SDK の場合、Application Insights バックエンドでは引き続き、Application Insights イベント収集エンドポイントによって受信されるイベントを集計することで新しいメトリックが設定されます。 ネットワーク経由で送信されるデータの量を減らせる利点はありませんが、引き続き事前に集計されたメトリックを使用できて、収集時にメトリックを事前に集計しない SDK でのほぼリアルタイムのディメンション アラートのパフォーマンスとサポートが向上します。

コレクション エンドポイントは、インジェスト サンプリングの前にイベントを事前に収集することに言及する価値があります。つまり、 インジェスト サンプリング は、アプリケーションで使用する SDK のバージョンに関係なく、事前集計メトリックの精度に影響を与えることはありません。