メトリックを使用してキューに入れられたインジェストを監視する

キューに入った取り込みプロセスでは、Azure Data Explorer は、構成可能なインジェスト バッチ処理ポリシーに基づいて、受信した小さなデータ チャンクをバッチにバッチ処理することでデータ インジェストを最適化し、高スループットを実現します。 バッチ処理ポリシーにより、バッチを封印するためのトリガー条件 (データ サイズ、BLOB の数、経過時間) を設定できます。 すると、これらのバッチは、高速なクエリ結果のために最適に取り込まれます。

この記事では、メトリックを使用して、Azure portal で Azure Data Explorer へのキューに入ったインジェストを監視する方法について説明します。

バッチ処理のステージ

このセクションで説明するステージは、すべてのバッチインジェストに適用されます。 Azure Event Grid、Azure Event Hubs、Azure IoT Hub、Cosmos DB のインジェストの場合、データが data 接続の取り込みキューに登録される前に 外部ソースからデータを取得し、初期データ再配置を実行します。

キューに入れ込まれるインジェストは、次の段階で発生します。

1. Batching Manager は、インジェスト メッセージのキューをリッスンし、要求を処理します。
2. Batching Manager は、受信する小さなイングレス データ チャンクを取得し、インジェスト バッチ処理ポリシーに基づいて URL をバッチ処理することで、インジェストスループットを最適化します。
3. "インジェスト マネージャー" によってインジェスト コマンドが "Azure Data Explorer ストレージ エンジン" に送信されます。
4. "Azure Data Explorer ストレージ エンジン" によって、取り込まれたデータが格納され、クエリに使用できるようになります。

Azure Data Explorer には Azure Monitor ingestion メトリックのセットが用意されています キューに置かれたインジェスト プロセスのすべてのステージとコンポーネントでデータ インジェストを監視できます。

Azure Data Explorer のインジェスト メトリックにより、次の詳細情報が得られます。

• キューに入ったインジェストの結果。
• 取り込まれたデータの量。
• キューに登録されたインジェストの待機時間とその発生場所。
• バッチ処理プロセス自体。
• Event Hubs、Event Grid、IoT Hub のインジェストの場合: 受信したイベントの数。

この記事では、Azure portal でインジェスト メトリックを使用して、Azure Data Explorer へのキューに入ったインジェストを監視する方法について説明します。

前提条件

• Azure サブスクリプション。 無料の Azure アカウントを作成します。
• Azure Data Explorer クラスターとデータベース。 クラスターとデータベースを作成します。
• Event Hubs、IoT Hub、Event Grid など、アクティブなキューに入ったインジェスト。

Azure Monitor メトリックス エクスプローラーを使用してメトリック グラフを作成する

以下で Azure Monitor メトリックの一般的な使用方法を説明し、後続のセクションで実装します。 Azure portal で Azure Monitor メトリックス エクスプローラーを使用してメトリック グラフを作成するには、次の手順に従います。

1. Azure portal にサインインし、Azure Data Explorer クラスターの概要ページに移動します。

2. 左側のナビゲーション バーから [メトリックス] を選択して、メトリック ペインを開きます。

3. メトリック ペインの右上にある [時刻の選択] パネルを開き、[時間の範囲] を分析対象の時間に変更します。 この記事では、過去 48 時間の Azure Data Explorer へのデータ インジェストを分析します。

4. [スコープ] と [メトリック名前空間] を選択します。

   • [スコープ] は Azure Data Explorer クラスターの名前です。 以下の例では、demo11 という名前のクラスターを使用します。
   • [メトリック名前空間] は [Kusto Cluster standard metrics]\(Kusto クラスター標準メトリック\) に設定する必要があります。 これは、Azure Data Explorer メトリックを含む名前空間です。

   

5. [メトリック] の名前および関連する [集計] の値を選択します。

この記事のいくつかの例では、ディメンションを持つメトリックに [フィルターの追加] と [Apply splitting]\(分割の適用\) を選択します。 また、同じグラフにその他のメトリックをプロットするには [メトリックの追加] を、1 つのビューに複数のグラフを表示するには [+ New chart]\(+ 新しいグラフ\) を使用します。

新しいメトリックを追加するたびに、手順 4 と 5 を繰り返します。

Note

メトリックを使用した Azure Data Explorer の一般的な監視方法と、メトリック ペインでの操作方法の詳細については、「メトリックを使用した Azure Data Explorer のパフォーマンス、正常性、および使用状況の監視」を参照してください。

この記事では、キューに登録されたインジェストを追跡するために使用できるメトリックと、これらのメトリックの使用方法について説明します。

インジェスト結果を表示する

Ingestion result (インジェスト結果) メトリックでは、取り込みに成功した、および取り込みに失敗したソースの合計数に関する情報が示されます。

この例では、このメトリックを使用してインジェストの試行結果を確認し、状態情報を使用して、失敗した試行のトラブルシューティングに役立てます。

1. Azure Monitor の [メトリックス] ペインで [メトリックの追加] を選択します。
2. [メトリック] の値として [Ingestion result]\(インジェスト結果\) を、[集計] の値として [合計] を選択します。 このように選択すると、経時的なインジェスト結果が 1 つのグラフ線で示されます。
3. グラフの上にある [Apply splitting]\(分割の適用\) ボタンを選択し、[状態] を選択してインジェスト結果の状態別にグラフを分割します。 分割の値を選択したら、分割セレクターの外側をクリックして閉じます。

これで、メトリック情報が状態別に分割され、3 つの線に分割されたインジェスト結果の状態に関する情報を確認できます。

1. 成功したインジェスト操作の場合は青色。
2. "エンティティが見つからない" ために失敗したインジェスト操作の場合はオレンジ色。
3. "無効な要求" が原因で失敗したインジェスト操作の場合は紫色。

インジェスト結果のグラフを見るときには、次の点を考慮してください。

• イベント ハブまたは IoT Hub のインジェストを使用する場合は、"データ接続コンポーネント" でイベントの事前集計があります。 インジェストのこのステージでは、イベントは取り込まれる単一ソースとして扱われます。 このため、事前集計後にいくつかのイベントが単一のインジェスト結果として表示されます。
• 一時的な障害は、限られた試行回数で内部的に再試行されます。 それぞれの一時的な障害は、一時的なインジェスト結果として報告されます。 そのため、1 回のインジェストで複数のインジェスト結果が生じる可能性があります。
• インジェスト エラーは、グラフ内にエラー コードのカテゴリ別に一覧表示されます。 カテゴリ別のインジェスト エラー コードの完全な一覧を確認し、考えられるエラーの原因をより深く理解するには、「Azure Data Explorer のインジェスト エラー コード」を参照してください。
• インジェスト エラーの詳細情報を取得するために、失敗したインジェストの診断ログを設定できます。 ただし、ログ結果の生成によって追加のリソースが作成され、COGS (売却済商品の原価) が増加することを考慮することが重要です。

取り込まれたデータの量を表示する

Blobs Processed、Blobs Received、および Blobs Dropped メトリックは、キューに登録されたインジェストの段階でingestion コンポーネントによって処理、受信、および削除される BLOB の数に関する情報を提供します。

この例では、これらのメトリックを使用して、インジェスト パイプラインで渡されたデータの量、インジェスト コンポーネントによって受信されたデータの量、破棄されたデータの量を確認します。

処理された BLOB

1. Azure Monitor の [メトリックス] ペインで [メトリックの追加] を選択します。
2. [メトリック] の値として [Blobs Processed] (処理された BLOB) を、[集計] の値として [合計] を選択します。
3. [Apply splitting]\(分割の適用\) ボタンを選択し、[Component Type]\(コンポーネントの種類\) を選択して、異なるインジェスト コンポーネント別にグラフを分割します。
4. クラスター内の特定のデータベースに焦点を当てるには、グラフの上にある [フィルターの追加] ボタンを選択し、グラフをプロットするときに含めるデータベース値を選択します。 この例では、[プロパティ] として [データベース] を、[演算子] として = を、[値] ドロップダウンで [GitHub] を選択して、GitHub データベースに送信された BLOB をフィルター処理します。 フィルターの値を選択したら、フィルター セレクターの外側をクリックして閉じます。

これで、GitHub データベースに送信され、各インジェスト コンポーネントで処理された BLOB の数が経時的にグラフに示されます。

• 経時的に GitHub データベースに取り込まれた BLOB の数が 2 月 13 日に減少していることに注目してください。 また、各コンポーネントで処理された BLOB の数が同様であることにも注目してください。これは、"データ接続" コンポーネントで処理されたほぼすべてのデータが、"バッチ処理マネージャー"、"インジェスト マネージャー"、および "Azure Data Explorer ストレージ エンジン" コンポーネントでも正常に処理されたことを意味します。 このデータは、クエリ用に準備できています。

受信した BLOB

各コンポーネントで受信した BLOB の数と各コンポーネントで正常に処理された BLOB の数との関係をよく理解するために、新しいグラフを追加します。

1. [+ 新しいグラフ] を選択します。
2. [スコープ]、[メトリック名前空間]、[集計] に先ほどと同じ値を選択し、[Blobs Received]\(受信した BLOB\) メトリックを選択します。
3. [Apply splitting]\(分割の適用\) ボタンを選択し、[Component Type]\(コンポーネントの種類\) を選択して、"Blobs Received (受信した BLOB)" メトリックをコンポーネントの種類別に分割します。
4. [フィルターの追加] ボタンを選択して、先ほどと同じ値を設定して GitHub データベースに送信された BLOB のみをフィルター処理します。

• グラフを比較し、各コンポーネントによって受信された BLOB の数が、各コンポーネントによって処理された BLOB の数とほぼ一致していることに注目してください。 この比較により、インジェスト中に破棄された BLOB がないことがわかります。

破棄された BLOB

インジェスト中に破棄された BLOB があるかどうかを判断するには、Blobs Dropped (破棄された BLOB) メトリックを分析する必要があります。 このメトリックにより、インジェスト中に破棄された BLOB の数が示され、特定のインジェスト コンポーネントでの処理に問題があるかどうかを検出するのに役立ちます。 破棄された各 BLOB について、エラーの原因に関する詳細情報を含む Ingestion result (インジェスト結果) メトリックも取得します。

インジェストの待機時間を表示する

Stage latency (ステージの待機時間) および Discovery Latency (検出の待機時間) メトリックによりインジェスト プロセスの待機時間が監視され、Azure Data Explorer で、またはインジェストのために Azure Data Explorer にデータが到達する前に長い待機時間が発生していないかを確認できます。

• Stage latency (ステージの待機時間) では、Azure Data Explorer によるメッセージの検出時から、そのコンテンツが処理用にインジェスト コンポーネントによって受信されるまでの期間が示されます。
• 探索の待機時間 は、データ接続 (イベント ハブ、IoT ハブ、Event Grid など) を使用するインジェスト パイプラインに使用されます。 このメトリックにより、データのエンキューから、Azure Data Explorer データ接続による検出までの期間に関する情報が得られます。 この期間は Azure Data Explorer の上流にあるので、Azure Data Explorer の待機時間のみを測定する Stage latency (ステージの待機時間) メトリックには含まれません。

Note

既定のバッチ処理ポリシーでは、既定のバッチ処理時間は 5 分です。 そのため、バッチが他のトリガーによって封印されていない場合、バッチは 5 分後に封印されます。

データがクエリ用に準備できるまでに長い待機時間がある場合は、Stage latency (ステージの待機時間) および Discovery Latency (検出の待機時間) を分析すると、長い待機時間の原因が、Azure Data Explorer の長い待機時間にあるのか、Azure Data Explorer の上流にあるのかを把握できます。 待機時間が Azure Data Explorer 自体にある場合、長い待機時間の原因である特定のコンポーネントを検出することもできます。

ステージの待機時間 (プレビュー)

まず、キューに登録されたインジェストのステージ待機時間を見てみましょう。 各ステージの説明については、「バッチ処理のステージ」を参照してください。

1. Azure Monitor の [メトリックス] ペインで [メトリックの追加] を選択します。
2. [メトリック] の値として [Stage latency]\(ステージの待機時間\) を、[集計] の値として [平均] を選択します。
3. [Apply splitting]\(分割の適用\) ボタンを選択し、[Component Type]\(コンポーネントの種類\) を選択して、異なるインジェスト コンポーネント別にグラフを分割します。
4. [フィルターの追加] ボタンを選択し、GitHub データベースに送信されたデータをフィルター処理します。 フィルターの値を選択したら、フィルター セレクターの外側をクリックして閉じます。 これで、インジェストを通じて各コンポーネントで GitHub データベースに送信されるインジェスト操作の待機時間がグラフに経時的に示されます。

このグラフから、次の情報がわかります。

• Event Hubs データ接続 コンポーネントの待機時間は約 0 秒です。 Stage latency (ステージの待機時間) では、Azure Data Explorer によってメッセージが検出された場合のみ待機時間が測定されるため、これは理にかなっています。
• インジェスト プロセスで最も長い時間 (約 5 分) がかかるのは、"バッチ処理マネージャー" コンポーネントによってデータが受信されてから、"インジェスト マネージャー" コンポーネントによってデータが受信されるまでです。 この例では、GitHub データベースに対して既定のバッチ処理ポリシーを使用しています。 前に説明したように、既定のバッチ処理ポリシーの待機時間の制限は 5 分であるため、ほとんどの場合、ほぼすべてのデータが時間単位でバッチ処理され、キューに登録されたインジェストの待機時間の大部分がバッチ処理自体によるものであることが示されます。
• グラフのストレージ エンジンの待機時間は、"Azure Data Explorer ストレージ エンジン" にデータが格納されて、クエリ用に準備ができるまでです。 Azure Data Explorer によるデータの検出時刻から、クエリ用に準備できるまでの待機時間の合計平均は、5.2 分であることがわかります。

検出の待機時間

データ接続のあるインジェストを使用する場合は、Azure Data Explorer の上流での経時的な待機時間を推測する必要があります。これは、Azure Data Explorer でインジェスト用のデータが取得される前に長い待機時間が発生することもあるためです。 そのために、Discovery Latency (検出の待機時間) メトリックを使用できます。

1. [+ 新しいグラフ] を選択します。
2. [メトリック] の値として [Discovery Latency]\(検出の待機時間\) を、[集計] の値として [平均] を選択します。
3. [Apply splitting]\(分割の適用\) ボタンを選択し、[Component Type]\(コンポーネントの種類\) を選択して、異なるデータ接続コンポーネントの種類別にグラフを分割します。 分割の値を選択したら、分割セレクターの外側をクリックして閉じます。

• ほとんどの期間において、検出の待機時間は 0 秒に近く、データのエンキュー直後に Azure Data Explorer でデータが取得されたことがわかります。 最も長いのは 2 月 13 日 14:00 頃の約 300 ミリ秒です。これは、データのエンキュー後、約 300 ミリ秒の時点において Azure Data Explorer クラスターによってデータが受信されたことを示しています。

バッチ処理プロセスについて

キューに登録されたインジェスト フローの第 2 段階では、 Batching Manager コンポーネントは、インジェスト バッチ処理ポリシーに基づいて受信したデータをバッチ処理することで、インジェスト スループットを最適化。

次のメトリックのセットを使用すると、インジェスト中にデータがバッチ処理される方法を把握できます。

• Batches Processed (処理されたバッチ): インジェスト用に完了したバッチの数。
• Batch Size (バッチ サイズ): インジェスト用に集計されたバッチ内の非圧縮データの推定サイズ。
• Batch Duration (バッチ期間): 個別のバッチにおけるバッチが開かれた時点からバッチ封印までの期間。
• Batch Blob Count (バッチ BLOB 数): インジェスト用に完了したバッチ内の BLOB の数。

Batches processed (処理されたバッチ)

まず、バッチ処理プロセスの全体像を把握するために Batches processed (処理されたバッチ) メトリックを見ていきましょう。

1. Azure Monitor の [メトリックス] ペインで [メトリックの追加] を選択します。
2. [メトリック] の値として [Batches Processed]\(処理されたバッチ\) を、[集計] の値として [合計] を選択します。
3. [Apply splitting]\(分割の適用\) ボタンを選択し、[Batching Type]\(バッチ処理の種類\) を選択して、バッチが封印された理由に基づいてグラフを分割します。 バッチ処理の種類の完全な一覧については、バッチ処理の種類に関する記事を参照してください。
4. [フィルターの追加] ボタンを選択し、GitHub データベースに送信されたバッチをフィルター処理します。 フィルターの値を選択したら、フィルター セレクターの外側をクリックして閉じます。

グラフには、GitHub データベースに送信されたデータでの封印されたバッチの数が経時的に示され、"バッチ処理の種類" 別に分割されています。

• 時間の経過に伴って時間単位ごとに 2 から 4 つのバッチがあり、「ステージの待機時間」セクションで推測した時間までにすべてのバッチが封印されています。これにより、既定のバッチ処理ポリシーに基づいてデータをバッチ処理するのに約 5 分かかっていることがわかります。

バッチ期間、サイズ、BLOB 数

ここからは、処理されたバッチの特徴をさらに見ていきます。

1. 各グラフの [+ グラフの追加] ボタンを選択して、[メトリック] の値 [Batch Duration]\(バッチ期間\)、[Batch Size]\(バッチ サイズ\)、および [Batch Blob Count]\(バッチ BLOB 数\) についてさらにグラフを作成します。
2. [集計] の値として [平均] を選択します。
3. 前の例と同様に、[フィルターの追加] ボタンを選択し、GitHub データベースに送信されたデータをフィルター処理します。

Batch Duration (バッチ期間)、Batch Size (バッチ サイズ)、Batch Blob Count (Batch BLOB 数) のグラフから、次の分析情報が導き出されます。

• (既定のバッチ処理ポリシーに従って) 平均バッチ期間は 5 分間です。 インジェストの合計待機時間を見るときには、この点を考慮する必要があります。

• Batch Size (バッチ サイズ) グラフでは、経時的なバッチの平均サイズが約 200 MB から 500 MB であることがわかります。 取り込まれるデータの最適なサイズは 1 GB の圧縮されていないデータであり、このサイズは既定のバッチ処理ポリシーによって封印条件として定義されています。 経時的にバッチ処理されるデータが 1 GB になっていないため、サイズによって封印されたバッチはありません。

• バッチ内の BLOB の経時的な平均数は 160 BLOB であり、その後 60 から 120 BLOB に減っています。 既定のバッチ処理ポリシーに基づいて、BLOB 数が 1000 BLOB になるとバッチを封印できます。 この数に到達しないため、バッチはカウントによってシールされません。

インジェストのために受信したイベントと送信されたイベントを比較する

イベント ハブ、IoT ハブ、または Event Grid インジェストを適用する場合、Azure Data Explorer で受信したイベントの数と、イベント ソースから Azure Data Explorer に送信されたイベントの数を比較すると便利です。 Events Received (受信したイベント)、Events Processed (処理されたイベント)、Events Dropped (破棄されたイベント) メトリックを使用すると、この比較が可能になります。

受信したイベント

1. Azure Monitor の [メトリックス] ペインで [メトリックの追加] を選択します。
2. [メトリック] の値として [Events Received]\(受信したイベント\) を、[集計] の値として [合計] を選択します。
3. グラフの上にある [フィルターの追加] ボタンを選択し、[プロパティ] 値の "コンポーネント名" を選択して、クラスターで定義されている特定のデータ接続で受信したイベントをフィルター処理します。 この例では、GitHubStreamingEvents データ接続でフィルター処理します。 フィルターの値を選択したら、フィルター セレクターの外側をクリックして閉じます。

これで、選択したデータ接続で経時的に受信したイベントの数がグラフに示されます。

• このグラフでは、GitHubStreamingEvents データ接続で、時間単位あたり約 200 から 500 個のイベントを経時的に受信しています。

処理されたイベントと破棄されたイベント

Azure Data Explorer によって破棄されたイベントがあるか確認するには、Events Processed (処理されたイベント) および Events Dropped (破棄されたイベント) メトリックを使用します。

1. 既に作成済みのグラフで、[メトリックの追加] を選択します。
2. [メトリック] の値として [Events Processed]\(処理されたイベント\) を、[集計] の値として [合計] を選択します。
3. [メトリックの追加] を再度選択し、[メトリック] の値として [Events Dropped]\(破棄されたイベント\) を、[集計] の値として [合計] を選択します。

これで、GitHubStreamingEvents データ接続によって経時的に受信、処理、破棄されたイベントの数がグラフに示されます。

• ほぼすべての受信イベントがデータ接続によって正常に処理されました。 破棄されたイベントが 1 つあります。これは、インジェストの結果を表示したときに確認した、無効な要求が原因で失敗したインジェスト結果と一致します。

Azure Data Explorer で受信したイベントとイベント ハブから送信されたメッセージを比較する

Events Received (受信したイベント) および 送信メッセージメトリックを比較することで、受信したイベントの数とイベント ハブから Azure Data Explorer に送信されたイベントの数を比較することもできます。

1. Events Received (受信したイベント) について作成済みのグラフで、[メトリックの追加] を選択します。

2. [スコープ] を選択し、[スコープの選択] ダイアログで、データ接続に対してデータを送信するイベント ハブの名前空間を検索して選択します。

   

3. [適用] を選択します

4. [メトリック] の値として [送信メッセージ] を、[集計] の値として [合計] を選択します。

設定の外側をクリックして閉じると、Azure Data Explorer データ接続によって処理されたイベントの数とイベント ハブから送信されたイベントの数を比較する完全なグラフが表示されます。

• イベント ハブから送信されたすべてのイベントが Azure Data Explorer データ接続によって正常に処理されたことに注目してください。
• イベント ハブ名前空間に複数のイベント ハブがある場合は、送信メッセージメトリックをエンティティ名ディメンションでフィルター処理して、イベント ハブ名前空間内の目的のイベント ハブからのデータのみを取得する必要があります。

Note

コンシューマー グループごとの送信メッセージを監視するオプションはありません。 送信メッセージ メトリックでは、すべてのコンシューマー グループによって消費されたメッセージの合計数がカウントされます。 このため、イベント ハブにいくつかのコンシューマー グループがある場合、Events Received (受信したイベント) より多くの数の送信メッセージを取得する場合があります。

関連するコンテンツ

• メトリックを使用した Azure Data Explorer のパフォーマンス、正常性、および使用状況の監視
• 診断ログを使用して Azure Data Explorer のインジェスト、コマンド、クエリ、テーブルを監視する
• Azure Monitor の分析情報を使用する