Application Insights での高いデータ インジェストのトラブルシューティング

Application Insights または Log Analytics の課金料金の増加は、多くの場合、データインジェストが多いために発生します。 この記事は、この問題のトラブルシューティングに役立ち、データ インジェスト コストを削減する方法を提供します。

一般的なトラブルシューティングの手順

手順 1: 高いデータ インジェストを示すリソースを特定する

Azure portal でサブスクリプションに移動し、 コスト管理>コスト分析を選択します。 このブレードには、リソースあたりのコストを次のようにグラフに示すコスト分析ビューが用意されています。

手順 2: データ インジェストが多いコストの高いテーブルを特定する

Application Insights リソースまたは Log Analytics ワークスペースを特定したら、データを分析し、最も高いインジェストが発生する場所を特定します。 シナリオに最も適したアプローチを検討します。

• 原始レコード数に基づく

  次のクエリを使用して、テーブル間のレコード数を比較します。

  search *
  | where timestamp > ago(7d)
  | summarize count() by $table
  | sort by count_ desc
  

  このクエリは、最も騒がしいテーブルを識別するのに役立ちます。 そこから、クエリを絞り込んで調査を絞り込むことができます。

• 使用されたバイト数に基づく

  format_bytes() スカラー関数を使用して、バイト インジェストが最も高いテーブルを決定します。

  systemEvents
  | where timestamp > ago(7d)
  | where type == "Billing"
  | extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
  | extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
  | summarize TotalBillingTelemetrySize = sum(BillingTelemetrySizeInBytes) by BillingTelemetryType
  | extend BillingTelemetrySizeGB = format_bytes(TotalBillingTelemetrySize, 1 ,"GB")
  | sort by BillingTelemetrySizeInBytes desc
  | project-away BillingTelemetrySizeInBytes
  

  レコード数クエリと同様に、上記のクエリは最もアクティブなテーブルを識別するのに役立ちます。これにより、詳細な調査のために特定のテーブルを特定できます。

• Log Analytics ワークスペースブックの使用

  Azure portal で Log Analytics ワークスペースに移動し、監視>Workbooks を選択し、Log Analytics ワークスペースの分析情報の下にある [使用状況] を選択します。

  

  このブックは、各テーブルのデータ インジェストの割合や、同じワークスペースにレポートする各リソースの詳細なインジェスト統計など、貴重な分析情報を提供します。

手順 3: データ インジェストの高い要因を特定する

データ インジェストが多いテーブルを特定したら、アクティビティが最も高いテーブルに注目し、データ インジェストの高い要因を特定します。 これは、他のアプリケーションよりも多くのデータを生成する特定のアプリケーション、ログに記録される頻度が高すぎる例外メッセージ、または多すぎる情報を出力する新しいロガー カテゴリなどです。

この識別に使用できるサンプル クエリを次に示します。

requests
| where timestamp > ago(7d)
| summarize count() by cloud_RoleInstance
| sort by count_ desc

requests
| where timestamp > ago(7d)
| summarize count() by operation_Name
| sort by count_ desc

dependencies
| where timestamp > ago(7d)
| summarize count() by cloud_RoleName
| sort by count_ desc

dependencies
| where timestamp > ago(7d)
| summarize count() by type
| sort by count_ desc

traces
| where timestamp > ago(7d)
| summarize count() by message
| sort by count_ desc

exceptions
| where timestamp > ago(7d)
| summarize count() by message
| sort by count_ desc

さまざまなテレメトリ フィールドを試すことができます。 たとえば、最初に次のクエリを実行し、過剰なテレメトリの明らかな原因がないことを確認します。

dependencies
| where timestamp > ago(7d)
| summarize count() by target
| sort by count_ desc

ただし、typeなど、targetではなく別のテレメトリ フィールドを試すことができます。

dependencies
| where timestamp > ago(7d)
| summarize count() by type
| sort by count_ desc

シナリオによっては、特定のアプリケーションまたはインスタンスをさらに調査することが必要になる場合があります。 次のクエリを使用して、ノイズの多いメッセージまたは例外の種類を特定します。

traces
| where timestamp > ago(7d)
| where cloud_RoleName == 'Specify a role name'
| summarize count() by type
| sort by count_ desc

exceptions
| where timestamp > ago(7d)
| where cloud_RoleInstance == 'Specify a role instance'
| summarize count() by type
| sort by count_ desc

手順 4: 時間の経過に伴うインジェストの進化を調査する

以前に特定された要因に基づいて、時間の経過に伴うインジェストの進化を調べます。 この方法では、この動作が一貫しているかどうか、または特定の時点で変更が発生したかどうかを判断できます。 この方法でデータを分析することで、変更が発生したタイミングを特定し、高いデータ インジェストの背後にある原因をより明確に把握できます。 この分析情報は、問題に対処し、効果的なソリューションを実装するために重要です。

次のクエリでは、 bin() Kusto クエリ言語 (KQL) スカラー関数を使用して、データを 1 日間隔に分割します。 この方法を使用すると、時間の経過と同時にデータがどのように変化したか、変更されていないかを確認できるため、傾向分析が容易になります。

dependencies
| where timestamp > ago(30d)
| summarize count() by bin(timestamp, 1d), operation_Name
| sort by timestamp desc

min()集計関数を使用して、特定の要因の最も早く記録されたタイムスタンプを識別します。 このアプローチは、ベースラインを確立し、イベントまたは変更が最初に発生したタイミングに関する分析情報を提供するのに役立ちます。

dependencies
| where timestamp > ago(30d)
| where type == 'Specify dependency type being investigated'
| summarize min(timestamp) by type
| sort by min_timestamp desc

特定のシナリオのトラブルシューティング手順

シナリオ 1: Log Analytics での高いデータ インジェスト

1. Log Analytics ワークスペース内のすべてのテーブルに対してクエリを実行します。

   search *
   | where TimeGenerated > ago(7d)
   | where _IsBillable == true
   | summarize TotalBilledSize = sum(_BilledSize) by $table
   | extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
   | sort by TotalBilledSize desc
   | project-away TotalBilledSize
   

   どのテーブルがコストの最大の要因であるかを把握できます。 こちらに AppTraces の例を示します。

   

2. トレースのコストを駆動する特定のアプリケーションに対してクエリを実行します。

   AppTraces
   | where TimeGenerated > ago(7d)
   | where _IsBillable == true
   | summarize TotalBilledSize = sum(_BilledSize) by  AppRoleName
   | extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
   | sort by TotalBilledSize desc
   | project-away TotalBilledSize
   

   

3. そのアプリケーションに固有の次のクエリを実行し、テレメトリを AppTraces テーブルに送信する特定のロガー カテゴリをさらに調べます。

   AppTraces
   | where TimeGenerated > ago(7d)
   | where _IsBillable == true
   | where AppRoleName contains 'transformation'
   | extend LoggerCategory = Properties['Category']
   | summarize TotalBilledSize = sum(_BilledSize) by tostring(LoggerCategory)
   | extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
   | sort by TotalBilledSize desc
   | project-away TotalBilledSize
   

   結果には、コストを担当する 2 つの主要なカテゴリが表示されます。

   

シナリオ 2: Application Insight での高いデータ インジェスト

コストの要因を特定するには、次の手順に従います。

1. すべてのテーブルのテレメトリに対してクエリを実行し、テーブルと SDK のバージョンごとのレコード数を取得します。

   search *
   | where TimeGenerated > ago(7d)
   | summarize count() by $table, SDKVersion
   | sort by count_ desc
   

   次の例では、Azure Functions で大量のトレースと例外テレメトリが生成されていることを示します。

   

2. 次のクエリを実行して、他のアプリよりも多くのトレースを生成する特定のアプリを取得します。

   AppTraces
   | where TimeGenerated > ago(7d)
   | where SDKVersion == 'azurefunctions: 4.34.2.22820'
   | summarize count() by AppRoleName
   | sort by count_ desc
   

   

3. 特定のアプリを含むようにクエリを調整し、個々のメッセージごとにレコードの数を生成します。

   AppTraces
   | where TimeGenerated > ago(7d)
   | where SDKVersion == 'azurefunctions: 4.34.2.22820'
   | where AppRoleName contains 'inbound'
   | summarize count() by Message
   | sort by count_ desc
   

   その結果、インジェスト コストが増加する特定のメッセージが表示されます。

   

シナリオ 3: 予期せず日次上限に達する

9 月 4 日に予期せず日次上限に達したとします。 カスタム イベントの数を取得し、各イベントに関連付けられている最新のタイムスタンプを識別するには、次のクエリを使用します。

customEvents
| where timestamp between(datetime(8/25/2024) .. 15d)
| summarize count(), min(timestamp) by name

この分析は、特定のイベントが 9 月 4 日に取り込まれ始め、その後すぐにノイズが発生したことを示しています。

データ インジェスト コストを削減する

予期しないデータ インジェストを担当する Azure Monitor テーブルの要因を特定したら、シナリオごとに次の方法を使用してデータ インジェスト コストを削減します。

方法 1: 日次上限構成を更新する

過剰なテレメトリ インジェストを防ぐために、日次上限を調整します。

方法 2: テーブル プランを切り替える

Application Insights でサポートされている別のテーブル プランに切り替えます。 データ インジェストの課金は、テーブル プランと Log Analytics ワークスペースのリージョンによって異なります。 テーブル プランとAzure Monitor ログの Basic テーブル プランをサポートするテーブルを参照してください。

方法 3: Java エージェントにテレメトリ SDK 機能を使用する

既定で推奨されるソリューションは、 サンプリング オーバーライドを使用することです。 Application Insights Java エージェントには、 2 種類のサンプリングが用意されています。 一般的なユース ケースは、 正常性チェックのテレメトリの収集を抑制する場合です。

サンプリング オーバーライドには、いくつかの補足的な方法があります。

• traces テーブルからコストを削減します。

  • テレメトリ ログ レベルを下げます。

  • MDC 属性とサンプリング オーバーライドを使用して、(フレームワーク/libs ではなく) アプリケーション ログを削除します。

  • applicationinsights.json ファイルを更新して、ログ インストルメンテーションを無効にします。

    {
      "instrumentation": {
        "logging": {
          "enabled": false
        }
      }
    }
    

• dependencies テーブルからコストを削減します。

  • 依存関係テレメトリを生成する Java メソッドのテレメトリの収集を抑制します。

  • 依存関係テレメトリ データを生成するインストルメンテーションを無効にします。

    依存関係がデータベース呼び出しの場合、アプリケーション マップにデータベースは表示されません。 HTTP 呼び出しまたはメッセージ (Kafka メッセージなど) の依存関係インストルメンテーションを削除すると、すべてのダウンストリーム テレメトリ データが削除されます。

• customMetrics テーブルからコストを削減します。

  • メトリック間隔を増やします。
  • テレメトリ プロセッサを使用してメトリックを除外します。
  • ハートビート間隔を長くします。

• OpenTelemetry 属性のコストを削減します。

  OpenTelemetry 属性が customDimensions 列に追加されます。 これらは Application Insights のプロパティとして表されます。 属性テレメトリ プロセッサを使用して 属性を削除できます。 詳細については、「 テレメトリ プロセッサの例 - 削除」を参照してください。

方法 4: アプリケーション コード (ログ レベルまたは例外) を更新する

一部のシナリオでは、アプリケーション コードを直接更新すると、Application Insights バックエンド サービスによって生成および使用されるテレメトリの量を減らすことができます。 一般的な例として、アプリケーションによって発生するノイズの多い例外が考えられます。

リファレンス

• Azure Monitor の価格
• Log Analytics ワークスペースの価格レベルを変更する
• Azure Monitor のテーブル 設定
• Azure Monitor のコストと使用量
• Log Analytics ワークスペースでの使用量を分析する
• Azure Monitor でのコストの最適化

サードパーティのお問い合わせ窓口に関する免責事項

マイクロソフトは、このトピックについての追加情報を見つけるのに役立つよう、サードパーティの連絡先情報を提供しています。 この連絡先情報は予告なしに変更されることがあります。 マイクロソフトは、第三者の連絡先情報の正確性を保証しません。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。