在 Azure AI 搜尋中監視查詢要求

  • 發行項

本文說明如何使用內建計量和資源記錄來測量查詢效能和磁碟區。 它也會說明如何取得應用程式使用者輸入的查詢字串。

Azure 入口網站 顯示有關查詢延遲、查詢負載 （QPS） 和節流的基本計量。 可在入口網站中存取饋送至這些計量的歷程記錄數據 30 天。 若要延長保留時間，或報告作業數據和查詢字串，您必須 新增診斷設定 ，以指定保存記錄作業和計量的記憶體選項。 我們建議 將Log Analytics工作區 作為記錄作業的目的地。 Kusto 查詢和數據探索的目標是 Log Analytics 工作區。

最大化資料測量完整性的條件包括：

  • 使用計費服務（在基本層或標準層建立的服務）。 免費服務由多個訂閱者共用，這會在負載轉移時引入一定數量的波動性。

  • 可能的話，請使用單一複本和分割區來建立包含和隔離的環境。 如果您使用多個復本，查詢計量會在多個節點之間平均，這可能會降低結果的精確度。 同樣地，多個分割區表示數據已分割，如果索引編製也正在進行中，某些分割區可能會有不同的數據。 當您微調查詢效能時，單一節點和分割區可提供更穩定的測試環境。

提示

使用額外的用戶端程序代碼和 Application Insights，您也可以擷取點擊鏈接數據，以深入瞭解吸引應用程式用戶的興趣。 如需詳細資訊，請參閱 搜尋使用分析。

查詢量 （QPS）

磁碟區會測量為 「每秒搜尋查詢 」（QPS），這是內建計量，可報告為一分鐘範圍內執行之查詢的平均、計數、最小值或最大值。 計量的一分鐘間隔 （TimeGrain = “PT1M”） 在系統中已修正。

查詢通常會以毫秒為單位執行，因此只有以秒為單位測量的查詢才會出現在計量中。

彙總類型 描述
平均 查詢執行期間的平均秒數。
計數 在一分鐘間隔內發出至記錄的計量數目。
最大值 在一分鐘內註冊的每秒搜尋查詢數目最高。
最小值 在一分鐘內註冊的每秒搜尋查詢數目最低。
Sum 在分鐘內執行的所有查詢總和。

例如，在一分鐘內，您可能會有類似這樣的模式：SearchQueriesPerSecond 最大負載的一秒，後面接著 58 秒的平均負載，最後一秒只有一個查詢，這是最小值。

另一個範例：如果節點發出 100 個計量，其中每個計量的值是 40，則 “Count” 為 100，“Sum” 為 4000，“Average” 為 40，而 “Max” 為 40。

查詢效能

整個服務的查詢效能會測量為搜尋延遲（查詢完成所花費的時間）和因資源爭用而捨棄的節流查詢。

搜尋延遲

彙總類型 Latency
平均 平均查詢持續時間以毫秒為單位。
計數 在一分鐘間隔內發出至記錄的計量數目。
最大值 範例中執行時間最長的查詢。
最小值 範例中的最短執行查詢。
總數 範例中所有查詢的總運行時間，在間隔內執行 （一分鐘）。

請考慮下列搜尋延遲計量範例：已取樣 86 個查詢，平均持續時間為 23.26 毫秒。 至少 0 表示已卸除一些查詢。 執行時間最長的查詢需要 1000 毫秒才能完成。 總運行時間為2秒。

Latency aggregations

節流查詢

節流查詢是指捨棄而不是處理的查詢。 在大部分情況下，節流是執行服務的正常部分。 這不一定表示發生問題。

當執行中的要求數目超過容量時，就會發生節流。 當復本從輪替或編製索引期間取出時，您可能會看到節流要求增加。 查詢和索引要求都是由同一組資源處理。

服務會根據資源耗用量來判斷是否要卸除要求。 跨記憶體、CPU 和磁碟 IO 耗用的資源百分比平均一段時間。 如果這個百分比超過臨界值，則所有對索引的要求都會進行節流處理，直到要求量減少為止。

視您的用戶端而定，下列方式會指出節流要求：

  • 服務傳回錯誤 "You are sending too many requests. Please try again later."
  • 服務會傳回 503 錯誤碼，指出服務目前無法使用。
  • 如果您使用入口網站 （例如搜尋總管），查詢會以無訊息方式卸除，而您需要再次選取 [搜尋 ]。

若要確認節流查詢，請使用 節流搜尋查詢 計量。 您可以在入口網站中探索計量，或建立警示計量，如本文所述。 針對在取樣間隔內捨棄的查詢，請使用 Total 來取得未執行的查詢百分比。

彙總類型 節流
平均 在間隔內捨棄的查詢百分比。
計數 在一分鐘間隔內發出至記錄的計量數目。
最大值 在間隔內捨棄的查詢百分比。
最小值 在間隔內捨棄的查詢百分比。
總數 在間隔內捨棄的查詢百分比。

針對 [節流搜尋查詢百分比]、[最小值]、[最大值]、[平均值] 和 [總計]，所有值都相同：已節流處理的搜尋查詢百分比，從一分鐘的搜尋查詢總數。

在下列螢幕快照中，第一個數位是計數（或傳送至記錄的計量數目）。 其他匯總會顯示在頂端，或停留在計量上方時，包括平均值、最大值和總計。 在此範例中，不會捨棄任何要求。

Throttled aggregations

在入口網站中探索計量

如需快速查看目前的數位，[服務概觀] 頁面上的 [監視] 索引標籤會顯示三個計量（搜尋延遲、每秒搜尋單位的搜尋查詢數、節流搜尋查詢百分比），以及以小時、天和周為單位的固定間隔，以及變更匯總類型的選項。

若要深入探索，請從 [ 監視 ] 功能表開啟計量總管，以便您可以分層、放大和可視化數據，以探索趨勢或異常狀況。 完成建立計量圖表的本教學課程，以深入瞭解計量瀏覽器。

  1. 在 [監視] 區段下，選取 [計量 ] 以開啟計量總管，並將範圍設定為搜尋服務。

  2. 在 [計量] 下，從下拉式清單中選擇一個，並檢閱慣用類型的可用匯總清單。 匯總會定義收集的值在每次時間間隔內取樣的方式。

    Metrics explorer for QPS metric

  3. 在右上角，設定時間間隔。

  4. 選擇視覺效果。 預設值為折線圖。

  5. 選擇 [ 新增計量 ] 並選取不同的匯總，以分層更多匯總。

  6. 放大折線圖上感興趣的區域。 將滑鼠指標放在區域開頭，選取並按住滑鼠左鍵、拖曳至區域的另一側，然後放開按鈕。 圖表會放大該時間範圍。

傳回使用者輸入的查詢字串

當您啟用資源記錄時，系統會擷取 AzureDiagnostics 資料表中的查詢要求。 作為必要條件，您必須已經指定 記錄作業的目的地，記錄分析工作區或其他記憶體選項。

  1. 在 [監視] 區段底下，選取 [ 記錄 ] 以在Log Analytics 中開啟空白查詢視窗。

  2. 執行下列表達式來搜尋 Query.Search 作業，傳回表格式結果集，其中包含作業名稱、查詢字串、查詢索引，以及找到的檔數目。 最後兩個語句會排除查詢字串，其中包含空白或未指定的搜尋，而範例索引會減少結果中的雜訊。

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

  3. 或者，在 Query_s 上設定數據行篩選條件，以搜尋特定語法或字串。 例如，您可以篩選 over 等於?api-version=2023-11-01&search=*&%24filter=HotelName 。

    Logged query strings

雖然這項技術適用於臨機操作調查，但建置報表可讓您合併並呈現配置中更有利於分析的查詢字串。

識別長時間執行的查詢

新增持續時間數據行以取得所有查詢的數位，而不只是挑選為計量的查詢。 排序此數據會顯示哪些查詢需要最長的時間才能完成。

  1. 在 [監視] 區段底下，選取 [ 記錄 ] 以查詢記錄資訊。

  2. 執行下列基本查詢以傳回以毫秒為單位的持續時間排序的查詢。 執行時間最長的查詢位於最上方。

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

    Sort queries by duration

建立計量警示

計量警示會建立傳送通知或觸發您事先定義的更正動作的閾值。 您可以建立與查詢執行相關的警示，但您也可以針對資源健康情況、搜尋服務組態變更、技能執行和文件處理建立警示（編製索引）。

所有閾值都是用戶定義的，因此您應該知道活動層級應該觸發警示。

針對查詢監視，通常會建立搜尋延遲和節流查詢的計量警示。 如果您知道何時卸除查詢，您可以尋找降低負載或增加容量的補救措施。 例如，如果節流查詢在編製索引期間增加，您可以將它延後，直到查詢活動消退為止。

如果您要推送特定複本分割區組態的限制，則設定查詢磁碟區臨界值 （QPS） 的警示也很有説明。

  1. 在 [監視] 底下，選取 [警示]，然後選取 [建立警示規則]。

  2. 在 [條件] 底下，選取 [ 新增]。

  3. 設定訊號邏輯。 針對訊號類型，選擇 計量 ，然後選取訊號。

  4. 選取訊號之後，您可以使用圖表將歷程記錄數據可視化，以取得有關如何繼續設定條件的明智決策。

  5. 接下來，向下捲動至 [警示邏輯]。 針對概念證明，您可以針對測試目的指定人為的低值。

  6. 接下來，指定或建立動作群組。 這是符合閾值時要叫用的回應。 這可能是推播通知或自動化回應。

  7. 最後，指定 [警示詳細數據]。 命名並描述警示、指派嚴重性值，並指定是否要在啟用或停用狀態中建立規則。

如果您指定電子郵件通知，您會收到來自 「Microsoft Azure」 的電子郵件，主旨行為 “Azure： Activated Severity： 3 <your rule name>”。

下一步

如果您尚未這麼做，請檢閱搜尋服務監視的基本概念，以瞭解完整的監督功能。

監視 Azure AI 搜尋中的作業和活動