Azure Monitor でのログデータインジェスト時間

[アーティクル]
11/21/2024

Azure Monitor とは、毎月増加するテラバイト単位のデータを送信する何千もの顧客にサービスを提供する高スケールのデータサービスです。ログデータが収集されてから、そのデータが使用可能になるまでにかかる時間について、よく質問されることがあります。この記事では、この待機時間に影響するさまざまな要因について説明します。

平均待機時間

待機時間は、データが監視対象のシステムで作成される時間と Azure Monitor で分析に使用できるようになる時間を指します。ログデータを取り込むための平均待機時間は "20 秒から 3 分" です。特定のデータに対する具体的な待機時間は、この記事で説明するいくつかの要因によって異なります。

待機時間に影響する要因

特定のデータセットの合計インジェスト時間は、次の高度な領域に分割することができます。

エージェント時間: イベントを検出し、それを収集して、ログレコードとしてデータ収集エンドポイントに送信する時間。ほとんどの場合、このプロセスは、エージェントによって処理されます。ネットワークによって、追加の待機時間が生じる場合があります。
パイプライン時間: ログレコードを処理するインジェストパイプラインの時間。これには、イベントのプロパティを解析し、場合によっては計算済みの情報を追加する時間が含まれます。
インデックス作成時間: ログレコードを Azure Monitor のビッグデータストアに取り込むために費やされた時間。

このプロセスによるさまざまな待機時間の詳細を以下のセクションに示します。

エージェントコレクションの待機時間

時間は変動

エージェントと管理ソリューションは、さまざまな方法を使用して仮想マシンからデータを収集します。これが待機時間に影響する場合があります。いくつかの具体例を次の表に示します。

データの種類	収集の頻度	メモ
Windows イベント、Syslog イベント、パフォーマンスメトリック	すぐに収集される
Linux パフォーマンスカウンター	30 秒間隔でポーリングされる
IIS ログとテキストログ	タイムスタンプが変更された後に収集される	IIS ログの場合、このスケジュールは IIS で構成されているロールオーバースケジュールの影響を受けます。
Active Directory Replication ソリューション	5 日おきに評価される	エージェントは評価が完了したときにのみ、このログを収集します。
Active Directory Assessment ソリューション	Active Directory インフラストラクチャが週 1 回評価される	エージェントは評価が完了したときにのみ、このログを収集します。

エージェントのアップロードの頻度

1 分未満

Log Analytics エージェントを軽量にするため、エージェントではログがバッファーに格納されて、定期的に Azure Monitor にアップロードされます。アップロードの頻度は、データの型に応じて 30 秒から 2 分間の範囲で異なります。ほとんどのデータは、1 分未満でアップロードされます。

ネットワーク

場合により異なる

ネットワーク条件は、このデータがデータ収集エンドポイントに到達するまでの待機時間に悪影響を及ぼす可能性があります。

Azure メトリック、リソースログ、アクティビティログ

30 秒から 20 分

Azure データがデータ収集エンドポイントで処理のために使用可能になるまでには追加の時間がかかります。

Azure プラットフォームのメトリックは、1 分未満でメトリックデータベースで使用可能になりますが、データ収集エンドポイントにエクスポートできるようになるまでには、さらに 3 分かかります。
通常、リソースログには、Azure サービスに応じて、さらに 30 秒から 90 秒かかります。一部の Azure サービス (具体的には、Azure SQL Database と Azure Virtual Network) では、現在 5 分間隔でそのログが報告されます。この時間をさらに向上させるための取り組みが進行中です。ご利用の環境におけるこの待機時間を調べる方法については、次のクエリを参照してください。
アクティビティログは、3 分から 20 分で分析とアラートに使用できるようになります。

管理ソリューションのコレクション

場合により異なる

一部のソリューションでは、エージェントからデータを収集せず、さらに待機時間がかかるコレクションメソッドを使用する場合があります。一部のソリューションでは、ほぼリアルタイムでの収集を試みることなく、一定の間隔でデータを収集します。具体的な例を次に示します。

Microsoft 365 ソリューションを使用すると、Management Activity API (現在はほぼリアルタイムの待機時間を保証していません) を使用して、アクティビティログがポーリングされます。
Windows Analytics ソリューション (Update Compliance など) のデータは、毎日の頻度でソリューションによって収集されます。

ソリューションのコレクションの頻度を判断するには、各ソリューションのドキュメントを参照してください。

パイプライン処理時間

30 秒から 60 秒

データ収集エンドポイントで使用可能になったデータがクエリに使用できるようになるまでには、さらに 30 から 60 秒かかります。

(_TimeReceived プロパティに指定されているように) ログレコードは Azure Monitor パイプラインに取り込まれた後、テナントが分離され、データが失われないように、一時的なストレージに書き込まれます。通常、このプロセスにより、さらに 5 から 15 秒が加算されます。

一部のソリューションでは、データのストリーミング時に、データを集計し、分析情報を派生させるため、より重いアルゴリズムが実装されます。たとえば、Application Insights でアプリケーションマップデータが計算され、Azure のネットワークパフォーマンス監視では受信データを 3 分間隔で集計するため、事実上 3 分間の待機時間が加算されます。

データ収集にインジェスト時間変換が含まれている場合は、パイプラインに待機時間が追加されます。変換クエリの効率を監視するには、Logs Transformation Duration per Min メトリックを使用します。

待機時間を増やす別のプロセスは、カスタムログを処理するプロセスです。場合によっては、このプロセスによって、エージェントがファイルから収集するログの待機時間が数分増えることがあります。

新しいカスタムデータ型のプロビジョニング

新しいカスタムデータの型をカスタムログまたはデータコレクター API から作成すると、システムにより専用のストレージコンテナーが作成されます。この 1 回限りのオーバーヘッドは、このデータ型が最初に出現したときにのみ発生します。

急激な増加の保護

通常は 1 分未満 (ただし、それ以上かかる場合もあります)

Azure Monitor の最優先事項は、顧客データが失われることがないようにすることです。そのため、システムにはデータの急激な増加に対する保護が組み込まれています。この保護には、膨大な負荷でもシステムが機能し続けられるようにするバッファーが含まれます。通常の負荷では、これらのコントロールにより追加されるのは 1 分未満です。極端な状態で障害が発生した場合、データの安全を確保する一方で、膨大な時間が追加される場合があります。

インデックス作成時間

5 分以下

すべてのビッグデータプラットフォームには、分析および高度な検索機能の提供と、データへの即時アクセスの提供の間のバランスを取る機能が組み込まれています。 Azure Monitor を使用すると、何十億ものレコードに対して強力なクエリを実行し、数秒以内で結果を取得できます。このパフォーマンスを可能にしているのは、インフラストラクチャがデータインジェスト中にデータを動的に変換して、それを一意のコンパクトな構造に格納しているからです。システムは、これらの構造を作成するのに十分なデータ量になるまで、データをバッファーします。このプロセスは、ログレコードが検索結果に表示される前に完了する必要があります。

このプロセスは現在、データ量が少ない場合は約 5 分かかりますが、データレートが高いほど時間を短縮できます。この動作は直感に反しているように思えますが、このプロセスにより、大量の運用環境のワークロードの待機時間の最適化が可能になります。

インジェスト時間のチェック

インジェスト時間は、さまざまな状況とリソースの種類によって変わる場合があります。ログクエリを使用すると、ご利用の環境の具体的な動作を把握することができます。次の表は、レコードが作成され、Azure Monitor に送信されるときにそのレコードのさまざまな時間を判断する方法を示しています。

手順	プロパティまたは関数	説明
データソースで作成されるレコード	TimeGenerated	TimeGenerated の値は、受信時刻の 2 日前より前、または 1 日以上先にはできません。そうしないと、Azure Monitor ログが TimeGenerated 値を実際の受信時刻に置き換えます。データソースがこの値を設定しない場合は、Azure Monitor ログが値を _TimeReceived と同じ時刻に設定します。
データ収集エンドポイントによって受信されたレコード	_TimeReceived	このフィールドは、大量の処理向けに最適化されていないため、大きなデータセットをフィルター処理するためには使用しないでください。
ワークスペースに保存され、クエリに使用できるレコード	ingestion_time()	特定の時間枠で取り込まれたレコードのみをフィルター処理する必要がある場合は、`ingestion_time()` を使用することをお勧めします。このような場合は、より広い範囲を使用する `TimeGenerated` フィルターを追加することもお勧めします。

インジェストの待ち時間

特定のレコードの待ち時間は、ingestion_time() 関数の結果を TimeGenerated プロパティと比較することによって測定することができます。このデータを、さまざまな集計と組み合わせて使用すれば、取り込みの待ち時間の動作を突き止めることができます。インジェスト時間のパーセンタイルを観察すれば、大量のデータの分析情報が得られます。

たとえば、次のクエリを実行すると、過去 8 時間でインジェスト時間が最も長かったコンピューターを表示できます。

Heartbeat
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer 
| top 20 by percentile_E2EIngestionLatency_95 desc

前出のパーセンタイルチェックは、待ち時間の一般的な傾向を見つけるのに適しています。待ち時間の短期間のスパイクを識別するのであれば、最大値 (max()) を使用した方が効果的である場合があります。

一定の期間にわたる特定のコンピューターのインジェスト時間をドリルダウンする場合は、次のクエリを使用すると、昨日のデータもグラフに視覚化されます。

Heartbeat 
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"  
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60 
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60 
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by bin(TimeGenerated,30m) 
| render timechart

コンピューターのインジェスト時間を、それが置かれている (対応する IP アドレスに基づく) 国や地域ごとに表示するには、次のクエリを使用します。

Heartbeat 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry

エージェントから送信されるデータの種類が異なれば、インジェストの待ち時間も異なる可能性があるので、前出のクエリを他の種類のデータにも使用してみましょう。各種 Azure サービスのインジェスト時間を観察するには、次のクエリを使用します。

AzureDiagnostics 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider

同じクエリロジックを使用して、Application Insights データの待機時間の状態を診断します。

// Classic Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
requests
| where timestamp  > start and timestamp < end
| extend TimeEventOccurred = timestamp
| extend TimeRequiredtoGettoAzure = _TimeReceived - timestamp
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - timestamp
| project timestamp, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

// Workspace-based Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
AppRequests
| where TimeGenerated  > start and TimeGenerated < end
| extend TimeEventOccurred = TimeGenerated
| extend TimeRequiredtoGettoAzure = _TimeReceived - TimeGenerated
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - TimeGenerated
| project TimeGenerated, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

上記の 2 つのクエリは、"requests" 以外の他の Application Insights テーブルとペアにすることができます。

応答していないリソース

ときには、リソースからのデータ送信が停止することもあります。リソースからデータが送信されているかどうかを把握するには、標準の TimeGenerated フィールドで識別できる最新のレコードに着目します。

エージェントからは、1 分間に 1 回ハートビートが送信されます。そこで、Heartbeat テーブルを使用して VM の状態をチェックします。アクティブなコンピューターのうち、ハートビートを最近レポートしていないコンピューターを一覧表示するには、次のクエリを使用します。

Heartbeat  
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day 
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer  
| top 20 by NoHeartbeatPeriod desc

次のステップ

Azure Monitor のサービスレベルアグリーメントをお読みください。

次の方法で共有

Azure Monitor でのログデータインジェスト時間

平均待機時間

待機時間に影響する要因

エージェントコレクションの待機時間

エージェントのアップロードの頻度

ネットワーク

Azure メトリック、リソースログ、アクティビティログ

管理ソリューションのコレクション

パイプライン処理時間

新しいカスタムデータ型のプロビジョニング

急激な増加の保護

インデックス作成時間

インジェスト時間のチェック

インジェストの待ち時間

応答していないリソース

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure Monitor でのログ データ インジェスト時間

平均待機時間

待機時間に影響する要因

エージェント コレクションの待機時間

エージェントのアップロードの頻度

ネットワーク

Azure メトリック、リソース ログ、アクティビティ ログ

管理ソリューションのコレクション

パイプライン処理時間

新しいカスタム データ型のプロビジョニング

急激な増加の保護

インデックス作成時間

インジェスト時間のチェック

インジェストの待ち時間

応答していないリソース

次のステップ

フィードバック

その他のリソース

Azure Monitor でのログデータインジェスト時間

エージェントコレクションの待機時間

Azure メトリック、リソースログ、アクティビティログ

新しいカスタムデータ型のプロビジョニング