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

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

平均待機時間

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

待機時間に影響する要因

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

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

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

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

時間は変動

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

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

1 分未満

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

ネットワーク

場合により異なる

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

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

30 秒から 15 分

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

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

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

場合により異なる

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

• 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 に送信されるときにそのレコードのさまざまな時間を判断する方法を示しています。

インジェストの待ち時間

特定のレコードの待ち時間は、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 のサービス レベル アグリーメントをお読みください。