次の方法で共有

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

  • [アーティクル]

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

Azure portal には、クエリの待ち時間、クエリ負荷 (QPS)、スロットリングに関する基本的なメトリックが表示されます。 これらのメトリックにフィードされる履歴データには、ポータルで 30 日間アクセスできます。 データ保持期間を延長したり、オペレーショナル データとクエリ文字列についてレポートしたりする場合は、ログされた操作とメトリックの保持に関するストレージ オプションを指定する診断設定を追加する必要があります。 ログされる操作の格納先としては Log Analytics ワークスペースをお勧めします。 Kusto クエリとデータ探索のターゲットは Log Analytics ワークスペースです。

データ測定の整合性を最大化する条件には、次のようなものがあります。

  • 課金対象のサービス (Basic または Standard レベルで作成されたサービス) を使用します。 無料のサービスは、複数のサブスクライバーによって共有されます。そのため、負荷の変化に応じて一定量の変動性が生じます。

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

ヒント

追加のクライアント側コードと Application Insights を使用すると、何がアプリケーション ユーザーの関心を引くかについてより深い分析情報を得るために、クリックスルー データをキャプチャすることもできます。 詳しくは、「検索トラフィックの分析」をご覧ください。

クエリ量 (QPS)

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

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

クエリ パフォーマンス

サービス全体のクエリ パフォーマンスは、検索の待ち時間とスロットルされたクエリとして測定されます。

検索の待ち時間

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

次の検索の待機時間メトリックの例を考えてみます。86 件のクエリがサンプリングされ、平均時間は 23.26 ミリ秒であるとします。 最小値 0 は、一部のクエリが削除されたことを示します。 実行時間の最も長いクエリは、完了までに 1,000 ミリ秒かかりました。 合計実行時間は 2 秒でした。

待ち時間の集計

スロットルされたクエリ

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

次のスクリーンショットでは、最初の数はカウント (つまり、ログに送信されるメトリックの数) です。 上部に、またはメトリックにカーソルを合わせたときに表示されるその他の集計には、平均、最大、合計などがあります。 このサンプルでは、​​要求は削除されませんでした。

スロットルの集計

ポータルでメトリックについて調べる

現在の数値を簡単に確認できるように、サービスの [概要] ページの [監視] タブには、3 つのメトリック (検索の待ち時間、秒あたりの検索クエリ数 (検索ユニットごと)、スロットルされた検索クエリの割合) が表示されます。これらは、一定の間隔で時間、日、および週単位で測定されるほか、集計の種類を変更するオプションが用意されています。

さらに詳しく調べるには、[監視] メニューからメトリックス エクスプローラーを開き、データを階層化、拡大、および視覚化して、傾向や異常を確認します。 メトリックス エクスプローラーの詳細を確認するには、このメトリックのグラフの作成に関するチュートリアルを完了してください。

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

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

    QPS メトリックのメトリックス エクスプローラー

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

  4. 視覚化方法を選択します。 既定では折れ線グラフになっています。

  5. 階層化する集計を増やすには、[メトリックの追加] を選んで、異なる集計を選びます。

  6. 折れ線グラフ上で、関心領域を拡大します。 領域の先頭にマウス ポインターを置き、マウスの左ボタンを押したまま領域のもう一方の側にドラッグしてボタンを離します。 その時間範囲のグラフが拡大されます。

ユーザーによって入力されたクエリ文字列を返す

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

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

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

       AzureDiagnostics
| project OperationName, Query_s, IndexName_s, Documents_d
| where OperationName == "Query.Search"
| where Query_s != "?api-version=2023-11-01&search=*"
| where IndexName_s != "realestate-us-sample-index"

  3. 必要に応じて、Query_s に列フィルターを設定して、特定の構文または文字列を検索します。 たとえば、?api-version=2023-11-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. 最後に、アラートの詳細を指定します。 アラートに名前と説明を指定し、重要度の値を割り当てて、ルールを有効な状態と無効の状態のどちらで作成するかを指定します。

メール通知を指定した場合、"Microsoft Azure" から "Azure: Activated Severity: 3 <your rule name>" という件名のメールを受け取ります。

次のステップ

まだ行っていない場合は、検索サービスの監視の基礎を確認し、すべての監視機能について理解してください。

Azure AI Searchでの操作とアクティビティの監視