Note
Azure AI 搜尋服務 可透過 Azure 入口網站、REST API 及 Azure SDK 取得。 它同時也是 Foundry IQ 的基礎，這是一個管理式知識層，能將企業內容轉化為可重複使用、權限感知的知識庫，供 Microsoft Foundry 入口網站中的代理使用。
本文說明如何利用內建指標與診斷記錄來衡量查詢效能與查詢量。 它也說明了如何讓應用程式使用者輸入查詢字串。
Azure 入口網站顯示了關於查詢延遲、查詢負載（QPS）和限速的基本指標。 這些指標的歷史資料可在 Azure 入口網站存取 30 天。 若要延長保留時間，或要報告操作資料與查詢字串，必須 啟用診斷記錄 ，並選擇儲存選項以持續保存記錄的操作與指標。 我們建議將 Log Analytics workspace 作為記錄操作的目的地。 Kusto 查詢和資料探索都以 Log Analytics 工作區為目標。
最大化資料測量完整性的條件包括：
使用可計費服務（在基本層級或標準層級建立的服務）。 免費服務由多個用戶共享，隨著負載變動，會帶來一定的波動性。
如果可能，使用單一複本和分割區來建立一個封裝且隔離的環境。 如果你使用多個副本，查詢指標會在多個節點間平均，這可能會降低結果的精確度。 同樣地，多分割區意味著資料會被分割，若同時進行索引，某些分割區可能會有不同的資料。 當你調校查詢效能時，單一節點和分割區能提供更穩定的測試環境。
查詢量（QPS）
磁碟區會測量為每秒搜尋查詢數 (QPS)，這是內建指標，可回報為在一分鐘時段內執行之查詢的平均值、計數、最小值或最大值。 系統內將指標的時間間隔設定為一分鐘（TimeGrain = “PT1M”）。
Azure AI 搜尋服務 預設保留 30 天的指標資料。 你可以啟用日誌以延長資料保留時間。 QPS 可在 Azure 入口網站的搜尋服務 Monitoring 標籤中取得。
欲了解更多 SearchQueriesPerS 指標，請參閱 Search Queries per second。
查詢效能
在整個服務範圍內，查詢效能以 搜尋延遲 與 節流查詢來衡量。 這些指標也可在 監控 標籤中取得。
搜尋延遲
搜尋延遲表示查詢完成所需的時間。 欲了解更多搜尋延遲指標，請參閱 搜尋延遲。
請考慮以下搜尋 延遲 指標的範例：抽樣了86次查詢，平均持續時間為23.26毫秒。 最低 0 表示部分查詢被遺漏。 最長持續的查詢花了 1000 毫秒完成。 總執行時間為2秒。
延遲聚合
已節流查詢
已節流查詢是指遭捨棄而非處理的查詢。 在大多數情況下，流量限制是服務運作的正常部分。 這不一定代表有什麼問題。 欲了解更多關於 ThrottledSearchQueriesPercentage 指標，請參閱 Throttled 搜尋查詢百分比。
以下截圖中，第一個數字是計數（或傳送到日誌的指標數量）。 其他彙總則會出現在指標頂端或滑鼠懸停時，包括平均值、最大值和總值。 在此範例中，沒有捨棄任何要求。
探索 Azure 入口網站中的指標
欲快速查看目前數據，服務概覽頁面的監控標籤顯示三個指標（搜尋延遲、每秒搜尋查詢數（每搜尋單位）、限速搜尋查詢百分比），以小時、天、週為單位計算，並可選擇更改聚合類型。
若想深入探索，請從 監控 選單開啟指標總覽，方便分層、放大及視覺化資料，探索趨勢或異常。 透過完成 此教學，了解如何建立指標圖表，了解更多關於指標探索器的資訊。
在監控區塊中，選擇 「指標 」以開啟指標總覽，範圍設為您的搜尋服務。
在「指標」下拉選單中選擇一個，並查看可用的聚合清單以尋找偏好類型。 聚合定義了在每個時間區間中如何抽樣所收集的數值。
在右上角設定時間間隔。
選擇一個視覺化圖像。 預設是折線圖。
要分層更多聚合，請選擇新增指標，並選擇不同的彙總方式。
縮放至折線圖中感興趣的區域。 將滑鼠指標放在區域開頭，選取並長按左鍵，拖到區域另一側，放開按鈕。 圖表會聚焦於那個時間範圍。
回傳使用者輸入的查詢字串
啟用資源記錄時，系統會將查詢請求記錄在 AzureDiagnostics 表格中。 作為前提，你必須已經指定 一個記錄作業的目的地，可能是日誌分析工作空間或其他儲存選項。
在監控區塊中，選擇 Logs，Log Analytics 中開啟一個空白查詢視窗。
執行以下運算式來搜尋
Query.Search操作，回傳一個表格形式，包含操作名稱、查詢字串、查詢的索引及找到的文件數量。 最後兩句話排除了由空搜尋或未指定搜尋組成的查詢字串，並搭配範例索引，這能減少結果中的雜訊。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"可選擇在 Query_s 設置欄位過濾器，搜尋特定語法或字串。 例如，您可以篩選 等於
?api-version=2026-04-01&search=*&%24filter=HotelName的項目。
雖然此方法適合臨時調查，但建置報告能讓你整合並呈現查詢字串，呈現更有利於分析的版面。
識別長期執行的查詢
新增持續時間欄位，即可取得所有查詢的數字，而不僅限於作為指標的查詢。 整理這些資料後，你會知道哪些查詢最花時間完成。
在監控區塊中，選擇 日誌 以查詢日誌資訊。
執行以下基本查詢，即可回傳查詢，並依毫秒為單位的持續時間排序。 最長的查詢會排在最上面。
AzureDiagnostics | project OperationName, resultSignature_d, DurationMs, Query_s, Documents_d, IndexName_s | where OperationName == "Query.Search" | sort by DurationMs
排序
建立指標警示
指標警示會設定一個門檻，讓你事先定義，才能發送通知或觸發糾正措施。 你可以建立與查詢執行相關的警示，也可以為資源健康、搜尋服務設定變更、技能執行以及文件處理（索引）建立警示。
所有門檻都是使用者自訂的，所以你應該知道什麼活動等級會觸發警報。
對於查詢監視，通常會為搜尋延遲和已節流查詢建立指標警示。 如果你知道 查詢何時 會被丟棄，就可以尋找減輕負載或增加容量的解決方法。 例如，如果已節流查詢在編製索引期間增加，您可以延後索引，直到查詢活動減少。
如果您正在推動特定複本分割組態的限制，為查詢量閾值 (QPS) 設定警示也很有用。
在 監控中，選擇 警報 ，然後選擇 建立警報規則。
在條件下，選擇 新增。
設定訊號邏輯。 對於訊號類型，選擇 指標 ，再選擇訊號。
選擇號誌後，您可以使用圖表視覺化歷史資料，幫助您做出明智的條件設置決策。
接著往下滑到 Alert Logic。 為了概念證明，你可以指定一個人工設定的低值來測試目的。
接著，指定或建立一個行動群組。 這是在符合閾值時要調用的回應。 可能是推送通知或自動回應。
最後，請指定警示詳情。 命名並描述警示，指派嚴重度值，並指定在啟用或停用狀態下建立規則。
如果您指定電子郵件通知，您將收到來自「Microsoft Azure」的電子郵件，主旨為「Azure：啟動嚴重度：3 <your rule name>」。
下一步
如果你還沒這麼做過，請複習搜尋服務監控的基本原理，了解所有監督能力的範圍。