監視 Azure AI 搜尋服務中的查詢要求
本文說明如何使用內建計量和資源記錄來測量查詢效能和磁碟區。 它也會說明如何取得應用程式使用者輸入的查詢字串。
Azure 入口網站顯示有關查詢延遲、查詢負載 (QPS) 和節流的基本計量。 這些計量的歷程記錄數據可以在 Azure 入口網站 中存取 30 天。 若要延長保留期，或報告操作資料和查詢字串，您必須新增診斷設定，以指定保存記錄作業和計量的儲存體選項。 我們建議使用 Log Analytics工作區作為記錄作業的目的地。 Kusto 查詢和資料探索會以 Log Analytics 工作區為目標。
最大化資料量值完整性的條件包括：
使用可計費的服務 (在基本或標準層建立的服務)。 免費服務是由多個訂閱者共用，這會在負載移位時引進一定數量的變動性。
盡可能使用單一複本和分割區來建立包含且隔離的環境。 如果您使用多個複本，查詢計量會跨多個節點平均，這可能會降低結果的精確度。 同樣地，多個分割區表示資料已分割，如果索引編製也正在進行中，某些資料分割可能會有不同的資料。 調整查詢效能時，單一節點和資料分割可提供更穩定的環境進行測試。
提示
使用額外的用戶端程式碼和 Application Insights，您也可以擷取點選連結資料，以深入了解吸引應用程式使用者興趣的項目。 如需詳細資訊，請參閱搜尋流量分析。
查詢磁碟區 (QPS)
磁碟區會測量每秒搜尋查詢 (QPS)，這是一個內建計量，可報告一分鐘視窗內所執行查詢的平均、計數、最小值或最大值。 系統內一分鐘間隔的計量 (TimeGrain = "PT1M") 是固定的。
若要深入了解 SearchQueriesPerSecond 計量，請參閱 每秒搜尋查詢。
查詢效能
整個服務的查詢效能會測量為搜尋延遲和 節流查詢。
搜尋延遲
搜尋延遲表示查詢需要多久的時間才能完成。 若要深入了解 SearchLatency 計量，請參閱 搜尋延遲。
請考慮下列搜尋延遲計量的範例：已取樣 86 個查詢，平均持續時間為 23.26 毫秒。 最小值 0 表示已卸除一些查詢。 執行時間最長的查詢需要 1000 毫秒才能完成。 總執行時間為 2 秒。
節流查詢
節流查詢是指已卸除但未處理的查詢。 在大部分情況下，節流是執行服務正常的一部分。 這不一定表示發生錯誤。 若要深入了解 ThrottledSearchQueriesPercentage 計量，請參閱 節流搜尋查詢百分比。
在下列螢幕擷取畫面中，第一個數字是計數 (或傳送至記錄的計量數字)。 顯示在頂端或停留在計量上方的其他彙總包括平均值、最大值和總計。 在此範例中，不會卸除任何要求。
探索 Azure 入口網站 中的計量
如需快速查看目前的數字，[服務概觀] 頁面上的 [監視] 索引標籤會顯示三個計量 (搜尋延遲、每秒搜尋查詢 (每個搜尋單位)、節流搜尋查詢百分比) 以小時、天和周為單位的固定間隔，以及變更匯總類型的選項。
若要進行更深入的探索，請從 [監視] 功能表開啟計量總管，讓您可以分層、放大及視覺化資料，以探索趨勢或異常狀況。 完成建立計量圖表教學課程，以深入了解計量瀏覽器。
在 [監視] 區段底下，選取 [計量] 以開啟計量總管，並將範圍設定為搜尋服務。
在 [計量] 底下，從下拉式清單中選擇一個，並檢閱偏好型別的可用匯總清單。 該彙總會定義收集的值將如何在每個時間間隔內取樣。
在右上角設定時間間隔。
選擇視覺效果。 預設值為折線圖。
選擇 [新增計量] 並選取不同的彙總，以分層更多彙總。
放大折線圖上感興趣的區域。 將滑鼠指標放在區域的開頭，選取並按住滑鼠左鍵，拖曳至區域的另一端，再放開按鈕。 圖表將會放大該時間範圍。
傳回使用者輸入的查詢字串
當您啟用資源記錄時，系統會擷取 AzureDiagnostics 資料表中的查詢要求。 作為必要條件，您必須已指定記錄作業的目的地 (Log Analytics 工作區或其他儲存體選項)。
在 [監視] 區段底下，選取 [記錄] 以在 Log Analytics 中開啟空白查詢視窗。
執行下列運算式來搜尋
Query.Search作業，傳回表格式結果集，其中包含作業名稱、查詢字串、查詢索引，以及找到的文件數目。 最後兩個陳述式會排除包含空白或未指定搜尋的查詢字串，而樣本索引會減少結果中的雜訊。AzureDiagnostics | project OperationName, Query_s, IndexName_s, Documents_d | where OperationName == "Query.Search" | where Query_s != "?api-version=2024-07-01&search=*" | where IndexName_s != "realestate-us-sample-index"選擇性在 Query_s 上設定資料行篩選，以搜尋特定語法或字串。 例如，您可以將 [等於]
?api-version=2024-07-01&search=*&%24filter=HotelName作為篩選條件。
雖然這項技術適用於臨機操作調查，但建置報表可讓您將查詢字串合併並呈現在配置中更方便分析。
識別執行時間長的查詢
新增持續時間資料行可取得所有查詢的數量，而不僅僅是選取為計量的查詢。 透過排序此資料，可以顯示哪些查詢需要最長的時間才能完成。
在 [監視] 區段底下，選取 [記錄] 以查詢記錄資訊。
執行下列基本查詢以傳回查詢，並以毫秒為單位依持續時間排序。 執行時間最長的查詢在頂端。
AzureDiagnostics | project OperationName, resultSignature_d, DurationMs, Query_s, Documents_d, IndexName_s | where OperationName == "Query.Search" | sort by DurationMs
建立計量警示
計量警示會針對傳送通知或觸發您事先定義的矯正措施建立閾值。 您可以建立與查詢執行相關的警示，但您也可以針對資源健康情況、搜尋服務組態變更、技能執行和文件處理 (編製索引) 建立警示。
所有閾值都是使用者定義的，因此您應該了解什麼活動層級應該觸發警示。
針對查詢監視，系統通常會為搜尋延遲和節流查詢建立計量警示。 如果您知道查詢是何時卸除的，您可以尋找可減少負載或增加容量的解決方式。 例如，如果在編製索引期間增加節流查詢，您可以將它延後，直到查詢活動趨緩為止。
如果您超出特定復本分割區設定的限制時，設定查詢磁碟區閾值 (QPS) 的警示也很有用。
在 [監視] 下，選取 [警示]，然後選取 [建立警示規則]。
在 [條件] 底下，選取 [新增]。
設定訊號邏輯。 針對訊號型別，選擇 [計量]，並選取訊號。
選取訊號之後，您可以使用圖表將歷程記錄資料視覺化，以取得如何繼續設定條件的明智決策。
接下來，向下捲動至 [警示邏輯]。 您可以針對測試目的指定人工性低值，作為概念證明。
接下來，指定或建立動作群組。 這是符合閾值時要叫用的回應。 這可能是推播通知或自動化回應。
最後，指定 [警示詳細資料]。 命名並描述警示、指派嚴重性值，並指定是否要在啟用或停用狀態中建立規則。
如果您指定電子郵件通知，您會收到來自「Microsoft Azure」的電子郵件，主旨行為 「Azure 啟動嚴重性：3 <your rule name>」。
下一步
如果您尚未這麼做，請檢閱搜尋服務監視的基本概念，以了解完整的監督功能範圍。