Azure AI 検索でクエリ要求を監視する

この記事では、組み込みのメトリックと診断ログを使用してクエリのパフォーマンスとボリュームを測定する方法について説明します。 また、アプリケーション ユーザーが入力したクエリ文字列を取得する方法についても説明します。

Azure ポータルには、クエリの待機時間、クエリ負荷 (QPS)、調整に関する基本的なメトリックが表示されます。 これらのメトリックにフィードされる履歴データには、Azure ポータルで 30 日間アクセスできます。 保持期間を長くしたり、操作データとクエリ文字列をレポートしたりするには、 診断ログを有効に して、ログに記録された操作とメトリックを保持するためのストレージ オプションを選択する必要があります。 ログに記録される操作の保存先として、Log Analytics ワークスペースをお勧めします。 Kusto クエリとデータ探索は、Log Analytics ワークスペースを対象とします。

データ測定の整合性を最大化する条件は次のとおりです。

• 課金対象サービス (Basic レベルまたは Standard レベルで作成されたサービス) を使用します。 無料サービスは複数のサブスクライバーによって共有され、負荷のシフトに伴って一定のボラティリティが発生します。

• 可能であれば、単一のレプリカとパーティションを使用して、包含および分離された環境を作成します。 複数のレプリカを使用する場合、クエリ メトリックは複数のノード間で平均化されるため、結果の精度が低下する可能性があります。 同様に、複数のパーティションはデータが分割されることを意味します。インデックス作成も進行中の場合は、一部のパーティションのデータが異なる可能性があります。 クエリのパフォーマンスを調整すると、単一のノードとパーティションにより、テスト用のより安定した環境が提供されます。

クエリ ボリューム (QPS)

ボリュームは、1 分間に実行されるクエリの平均、カウント、最小値、または最大値として報告できる組み込みのメトリックである 、1 秒あたりの検索クエリ 数 (QPS) として測定されます。 メトリックの 1 分間隔 (TimeGrain = "PT1M") は、システム内で固定されます。

Azure AI 検索では、既定で 30 日間のメトリック データが保持されます。 ログ記録を有効にして、保持期間を長くすることができます。 QPS は、Azure ポータルの検索サービスの Monitoring タブで使用できます。

SearchQueriesPerSecond メトリックの詳細については、「 1 秒あたりの検索クエリ数」を参照してください。

クエリのパフォーマンス

サービス全体のクエリ パフォーマンスは、 検索の待機時間 と 調整されたクエリとして測定されます。 これらのメトリックは、[ 監視 ] タブでも使用できます。

検索の待機時間

検索の待機時間は、クエリの完了にかかる時間を示します。 SearchLatency メトリックの詳細については、「 検索の待機時間」を参照してください。

次の検索待機時間メトリックの例を考えてみましょう。86 個のクエリがサンプリングされ、平均所要時間は 23.26 ミリ秒です。 少なくとも 0 は、一部のクエリが削除されたことを示します。 実行時間が最も長いクエリの完了には 1000 ミリ秒かかりました。 合計実行時間は 2 秒でした。

制限されたクエリ

制限されたクエリは、処理されずに破棄されるクエリを指します。 ほとんどの場合、スロットリングはサービス運用の通常の一部です。 必ずしも何か問題があることを示しているわけではありません。 ThrottledSearchQueriesPercentage メトリックの詳細については、「 スロットルされた検索クエリの割合」を参照してください。

次のスクリーンショットでは、最初の数はカウント (またはログに送信されたメトリックの数) です。 上部またはメトリックの上にマウス ポインターを置いたときに表示されるその他の集計には、平均、最大値、合計が含まれます。 このサンプルでは、要求は削除されませんでした。

Azure ポータルでメトリックを調べる

現在の数値を簡単に確認するには、[サービスの概要] ページの [監視 ] タブに、時間、日、週単位で測定された固定間隔に対する 3 つのメトリック (検索待機時間、 1 秒あたりの検索クエリ数 (検索単位あたり)、 スロットルされた検索クエリの割合) が表示され、集計の種類を変更できます。

詳細な探索を行うには、[ 監視 ] メニューからメトリック ス エクスプローラーを開き、データをレイヤー化、拡大、視覚化して傾向や異常を調査できるようにします。 メトリック チャートの作成に関するこのチュートリアルを完了して、メトリック エクスプローラーの詳細を知ることができます。

1. [監視] セクションで、[ メトリック] を選択して、検索サービスにスコープが設定されたメトリックス エクスプローラーを開きます。

2. [メトリック] で、ドロップダウン リストから 1 つを選択し、優先する種類の使用可能な集計の一覧を確認します。 集計では、収集された値を時間間隔ごとにサンプリングする方法を定義します。

   

3. 右上隅で、時間間隔を設定します。

4. 視覚化を選択します。 既定値は折れ線グラフです。

5. [ メトリックの追加] を選択し、別の集計を選択して、より多くの集計をレイヤー化します。

6. 折れ線グラフの対象領域を拡大します。 領域の先頭にマウス ポインターを置き、マウスの左ボタンを選択して長押しし、領域の反対側にドラッグして、ボタンを離します。 グラフは、その時間範囲を拡大表示します。

ユーザーが入力したクエリ文字列を返す

リソース ログを有効にすると、 システムは AzureDiagnostics テーブル内のクエリ要求をキャプチャします。 前提条件として、 ログに記録される操作の宛先 (Log Analytics ワークスペースまたは別のストレージ オプション) を既に指定しておく必要があります。

1. [監視] セクションで、Logs を選択して、Log Analyticsで空のクエリ ウィンドウを開きます。

2. 次の式を実行して Query.Search 操作を検索し、操作名、クエリ文字列、クエリ対象のインデックス、検出されたドキュメントの数で構成される表形式の結果セットを返します。 最後の 2 つのステートメントでは、空または未指定の検索で構成されるクエリ文字列をサンプル インデックスで除外し、結果のノイズを削減します。

      AzureDiagnostics
   | project OperationName, Query_s, IndexName_s, Documents_d
   | where OperationName == "Query.Search"
   | where Query_s != "?api-version=2026-04-01&search=*"
   | where IndexName_s != "hotels-sample"
   

3. 必要に応じて、特定の構文または文字列を検索する列フィルターを Query_s に設定します。 たとえば、は?api-version=2026-04-01&search=*&%24filter=HotelNameに等しいというフィルターを設定できます。

   

この手法はアドホック調査に適していますが、レポートを作成すると、クエリ文字列を統合して、分析に役立つレイアウトで表示できます。

実行時間の長いクエリを特定する

期間列を追加して、メトリックとして取得されたクエリだけでなく、すべてのクエリの数値を取得します。 このデータを並べ替えた場合、完了に最も時間がかかるクエリが表示されます。

1. [監視] セクションで、[ ログ ] を選択してログ情報を照会します。

2. 次の基本的なクエリを実行して、ミリ秒単位の期間で並べ替えられたクエリを返します。 実行時間が最も長いクエリが一番上にあります。

   AzureDiagnostics
   | project OperationName, resultSignature_d, DurationMs, Query_s, Documents_d, IndexName_s
   | where OperationName == "Query.Search"
   | sort by DurationMs
   

   

メトリック アラートを作成する

メトリック アラートは、通知を送信したり、事前に定義した修正アクションをトリガーしたりするためのしきい値を確立します。 クエリの実行に関連するアラートを作成できますが、リソースの正常性、検索サービスの構成の変更、スキルの実行、ドキュメント処理 (インデックス作成) 用にアラートを作成することもできます。

すべてのしきい値はユーザー定義であるため、アラートをトリガーするアクティビティ レベルを把握しておく必要があります。

クエリの監視では、検索の待機時間と調整されたクエリのメトリック アラートを作成するのが一般的です。 クエリ が削除されるタイミング がわかっている場合は、負荷を軽減したり容量を増やしたりする救済策を探すことができます。 たとえば、インデックス作成中に制限されたクエリが増加した場合、クエリアクティビティが落ち着くまで延期することができます。

特定のレプリカ パーティション構成の制限をプッシュする場合は、クエリ ボリュームのしきい値 (QPS) のアラートの設定も役立ちます。

1. [ 監視] で [ アラート ] を選択し、[ アラート ルールの作成] を選択します。

2. [条件] で [追加] を選択 します。

3. シグナル ロジックを構成します。 シグナルの種類の場合は、 メトリック を選択し、シグナルを選択します。

4. シグナルを選択した後、グラフを使用して履歴データを視覚化し、条件の設定を進める方法に関する情報に基づいた決定を行うことができます。

5. 次に、アラート ロジックまで下にスクロールします。 概念実証では、テスト目的で人為的に低い値を指定できます。

6. 次に、アクション グループを指定または作成します。 これは、しきい値が達成されたときに呼び出す応答です。 プッシュ通知または自動応答である可能性があります。

7. 最後に、アラートの詳細を指定します。 アラートに名前を付けて説明し、重大度の値を割り当て、ルールを有効または無効の状態で作成するかどうかを指定します。

電子メール通知を指定した場合は、件名が "Azure: アクティブな重大度: 3 <your rule name>" のメールが "Microsoft Azure" から届きます。

次の手順

検索サービスの監視の基礎をまだ確認していない場合は、監視機能の全範囲について確認してください。