透過摘要規則在 Log Analytics 工作區中彙整資料

摘要規則讓你能以固定頻率彙整日誌資料,並將彙整結果傳送到你的 Log Analytics 工作區中的自訂日誌表。 使用摘要規則來最佳化您的資料:

  • 分析與報告,特別是針對大型資料集與時間範圍的報告,例如安全與事件分析,或月度與年度業務報告。 大型資料集上的複雜查詢通常會逾時。分析及報告已清理和已彙總摘要資料更為簡單且更有效率。

  • 在詳細記錄上節省成本:您可以依需求將記錄保留在低成本的 Basic 記錄資料表中,時間可長可短,並將摘要資料傳送至 Analytics 資料表,用於分析和報表。

  • 藉由移除或模糊化摘要共用資料中的隱私權詳細資料,以及限制對具有未經處理資料的資料表存取,來獲得安全性和資料隱私權。

本文說明摘要規則的運作方式,以及如何定義和檢視摘要規則,並提供摘要規則使用方式和優點的一些範例。

以下影片概述了摘要規則的一些優點:

摘要規則的運作方式

摘要規則直接在您的 Log Analytics 工作空間中執行批次處理。 摘要規則根據 KQL 查詢,依據 bin 大小來彙整資料塊,並將這些彙總的結果重新匯入包含 分析日誌計劃 的自訂表格內,並在你的 Log Analytics 工作空間中使用。

圖示,展示資料如何被導入Log Analytics工作區,並透過摘要規則被聚合後重新匯入工作區。

摘要規則會從任何資料表彙整資料,無論該資料表是有 分析計畫還是基本資料計畫。 Azure 監視器 會根據你定義的查詢建立目的地資料表架構。 如果目標資料表已經存在,Azure 監視器 會附加任何支援查詢結果所需的欄位。 所有目的地資料表也包含一組具有摘要規則資訊的標準欄位,包括:

  • _RuleName:產生彙總記錄項目的摘要規則。
  • _RuleLastModifiedTime:上次修改規則的時間。
  • _BinSize:彙總間隔。
  • _BinStartTime:匯總開始時間。

可設定最多 100 條主動規則,將多個資料表的資料彙整,並將彙整後的資料傳送至不同的目的資料表或同一資料表。

若要將自訂日誌表的摘要資料匯出到儲存帳號或事件中心進行進一步整合,請定義 資料匯出規則。

範例:摘要 ContainerLogV2 資料

如果您要監視容器,需要將大量冗長的日誌導入至 ContainerLogV2 資料表。

你可以在摘要規則中使用此查詢,在 60 分鐘內彙整獨特紀錄,僅將有用的資料推廣至目標資料表:

ContainerLogV2
| summarize Count = count()
  by
  Computer,
  ContainerName,
  PodName,
  PodNamespace,
  LogSource,
  LogLevel,
  Message = tostring(LogMessage.Message)

以下是 ContainerLogV2 資料表中的未經處理資料:

截圖顯示 ContainerLogV2 表格中的原始日誌資料。

以下是摘要規則傳送至目的地資料表的彙總資料:

截圖顯示摘要規則傳送到目標資料表的彙整資料。

目的地資料表會顯示每個唯一項目的計數,而不是在一小時內記錄數百個類似的項目,如 KQL 查詢中所定義。 在表格中設定基本資料計畫ContainerLogV2,以降低原始資料的保留成本,並利用目標資料表中的彙整資料來滿足您的分析需求。

需要的權限

動作 需要的權限
建立或更新摘要規則 Log Analytics 工作區的 Microsoft.Operationalinsights/workspaces/summaryLogs/write 權限,此權限由 Log Analytics 參與者內建角色提供,例如
建立或更新目的地資料表 Log Analytics 工作區的 Microsoft.OperationalInsights/workspaces/tables/write 權限,此權限由 Log Analytics 參與者內建角色提供,例如
在工作區中啟用查詢作業 Log Analytics 工作區的 Microsoft.OperationalInsights/workspaces/query/read 權限,此權限由 Log Analytics 讀者內建角色提供,例如
查詢工作區中的所有數據表 Log Analytics 工作區的 Microsoft.OperationalInsights/workspaces/query/*/read 權限,此權限由 Log Analytics 讀者內建角色提供,例如
查詢資料表中的記錄 Log Analytics 工作區的 Microsoft.OperationalInsights/workspaces/query/<table>/read 權限,此權限由 Log Analytics 讀者內建角色提供,例如
資料表中的查詢記錄 (資料表動作) Log Analytics 工作區的 Microsoft.OperationalInsights/workspaces/tables/query/read 權限,此權限由 Log Analytics 讀者內建角色提供,例如
使用在客戶自控儲存體帳戶中加密的查詢 儲存體帳戶的 Microsoft.Storage/storageAccounts/* 權限,例如儲存體帳戶參與者內建角色所提供的權限

實作考量

  • 工作區中的使用中規則數目上限為 100。
  • 摘要規則目前僅適用於公用雲端。
  • 摘要規則處理的是輸入資料,不允許歷史時間範圍。 資料只能從最近過去到最多 24 小時的期間進行處理。 當binSize設定為完整的24小時時段,這相當於最大binStartTime1440分鐘。
  • 不支援在 Lighthouse 下使用跨另一個租用戶的查詢建立摘要規則。
  • 不支援在摘要規則的目標資料表中加入 工作區轉換 。
  • 不支援使用 union * 和 isfuzzy=true 摘要規則查詢。

摘要規則定價模型

摘要規則不會產生額外費用。 您只需根據執行查詢的來源資料表的資料表方案,支付查詢費用以及將結果提取到目標資料表的費用:

來源資料表方案 查詢成本 摘要結果擷取成本
Analytics 無成本 擷取分析記錄
基本和輔助 數據掃描 擷取分析記錄

例如,每個間隔所傳回 100 筆記錄的每小時規則成本計算為:

來源資料表方案 每月價格計算
Analytics 擷取價格 x 記錄量 x 記錄數 x 24 小時 x 30 天。
基本和輔助 數據掃描價格 x 掃描的磁碟區 + 擷取價格 x 記錄磁碟區 x 記錄數目 x 24 小時 x 30 天。 對於連續執行的規則,會掃描所有傳入來源資料表的資料。

更多資訊請參閱 Azure 監視器 價格。

建立或更新摘要規則

摘要規則查詢中可用的運算子取決於查詢中來源資料表的規劃。

  • 分析:支援所有 KQL 運算子和函式,除了:
  • 基本:支援單一數據表上的所有 KQL 運算子。 使用 查詢 操作工具,最多可連接五個 Analytics 資料表。
  • 函式:不支援使用者定義函式。 支援 Microsoft 所提供的系統功能。

當規則查詢包含 summarize 運算子,且結果數量或資料量大幅減少時,摘要規則可在成本和查詢方面帶來最大效益。 例如,目標是讓結果的體積為原始體積的 0.01% 或更低。 在建立規則前,請先在 Log Analytics 測試查詢並驗證以下事項:

  1. 查詢會產生預期的結果與結構。
  2. 查詢未達或接近 查詢 API 的限制。 如果查詢接近查詢限制,請考慮使用較小的 binSize,讓每個 bin 處理較少的資料。 相反地,可以修改查詢以回傳較少的記錄或較少的高容量欄位。
  3. 結果中的記錄大小小於 1 MB。

備註

在摘要規則查詢中,請勿使用時間過濾器,因為查詢已在由箱大小定義的時間範圍內運作。 如果您新增時間篩選,它會與 Bin 大小結合,導致系統只使用重疊的時間週期。

當你更新查詢且摘要結果欄位變少時,Azure 監視器 不會自動移除目標資料表中的欄位。 如果需要,請手動刪除表格中的欄位。

建立、更新、啟動或停止規則後,取回該設定並等待 properties.provisioningState IS Succeeded ,再進行下一次變更。 當規則仍 Updating為 時,成功請求可返回。

若要建立或更新摘要規則:

  1. 從 Azure 入口網站,前往你的 Log Analytics 工作區。

  2. 在左側選單的 設定中,選擇 規則。

  3. 選擇「 摘要規則 」標籤。

    截圖顯示了 Azure 入口網站中摘要規則體驗的總覽。

  4. 選擇 + 建立 以建立新的摘要規則。

  5. 填寫 規則名稱、 描述和 目的地表格,然後選擇 「下一頁:設定規則邏輯」。

    這張截圖顯示了 Azure 入口網站中建立摘要規則的體驗。

  6. 規則邏輯步驟始於 Log Analytics 的查詢體驗。 在這裡設計並測試你的查詢,當結果達到預期時,選擇 「套用 」。

    這張截圖顯示了 Azure 入口網站中建立摘要規則邏輯的體驗。

  7. 選取與 對應的 binSize 值,並視需要調整其他排程選項。 然後選擇 「下一頁:評論+創建」。

  8. 檢視摘要規則設定,然後選擇 建立。

摘要規則特性

本表描述可用於摘要規則建立與管理的參數。

參數 有效值 描述
ruleType User 或 System 指定規則的類型。
- User:您定義的規則。
- System:由Azure服務管理的預先定義規則。
description 字串 描述規則及其功能。 當您有數個規則且可協助管理規則時,此參數會很有幫助。
binSize 20、30、60、120、180、360、720 或 1440 (分鐘) 定義彙總間隔和回顧時間範圍。 例如,如果您設定 "binSize": 120,則可能會取得 02:00 to 04:00 和 04:00 to 06:00 的項目。
query Kusto 查詢語言 (KQL) 查詢 定義在規則中執行的查詢。 你不需要指定時間範圍,因為參數 binSize 決定了聚合區間,例如 02:00 to 03:00 ,如果 "binSize": 60。 如果你在查詢中加入時間過濾器,查詢中使用的時間範圍就是過濾器與箱大小的交點。
destinationTable tablename_CL 指定目的地自訂記錄資料表的名稱。 名稱值必須具有尾碼 _CL。 Azure 監視器 會根據你在規則中設定的查詢,在工作區建立這個表格(如果還不存在的話)。 如果該資料表已經存在於工作區中,Azure 監視器 會新增查詢中新增的欄位。

若摘要結果包含保留欄位名稱,例如 TimeGenerated、_IsBillable、_ResourceId、TenantId 或 Type,Azure 監視器 會在原始欄位後加上 _Original 前綴以保留原始值。
binDelay (選用) 整數 (分鐘) 設定在執行間隔之前等待的時間,通常在延遲到達的資料上執行時很有用 (也稱為擷取延遲),且允許大部分的資料到達。 預設延遲是從 3 分半到 10% binSize 的值。

如果您知道您查詢的數據通常是以延遲擷取,請使用已知延遲值或更大值來設定 binDelay 參數,最多 1440 分鐘。 如需詳細資訊,請參閱設定彙總時間。
在某些情況下,Azure 監視器 可能會稍微晚於設定的 bin 延遲開始執行,以確保服務的可靠性與查詢成功。
retryBinStartTime 日期時間內
%Y-%n-%eT%H:%M %Z 格式
依提供的 retryBinStartTime 重新執行貯體。 規則的其他定義依最新更新保留。 所選 retryBinStartTime 值必須在 之後 RuleLastModifiedTime 且符合 的 binSize除法範圍內。 例如,如果規則 binSize 是 20 分鐘,你可以設定 retryBinStartTime 為「2026-02-16T10:00:00Z」、「2026-02-16T10:20:00Z」或「2026-02-16T10:40:00Z」。
binStartTime (選用) 日期時間內
%Y-%n-%eT%H:%M %Z 格式
指定初始間隔執行的日期和時間。 值可以從規則建立日期時間減去 binSize 值,或稍後以及整數小時內開始。 例如,如果日期時間是 2023-12-03T12:13Z 且 binSize 為 1,440,則最早的有效 binStartTime 值為 2023-12-02T13:00Z,而彙總會包含在 02T13:00 和 03T13:00 之間記錄的資料。 在此案例中,規則會開始彙總 03T13:00 加上預設或指定的延遲。

binStartTime 參數在每日摘要案例中很有用。 假設您位於 UTC-8 時區,並在 2023-12-03T12:13Z 建立每日規則。 您希望規則在 8:00 (00:00 UTC) 開始一天工作之前完成。 將 binStartTime 參數設定為 2023-12-02T22:00Z。 第一個聚合包含在本機時間 02T:06:00 和 03T:06:00 之間記錄的所有資料,且該規則每天在相同時間執行。 如需詳細資訊,請參閱設定彙總時間。

更新規則時,請選擇以下選項之一:
- 使用現有的 binStartTime 值或移除 binStartTime 參數,在此情況下,會根據初始定義繼續執行。
- 以新的 binStartTime 值更新規則,以設定新的日期時間值。
name 字串 指定規則名稱。 名稱必須在工作區中唯一,且可包含字母、數字、底線、連字號及句點(不得有空格)。 name 值會用於目的地資料表中的 _RuleName 欄位。
displayName (選用) 字串 指定 Azure 入口網站體驗中的規則顯示名稱。
timeSelector (選用) TimeGenerated 定義 Azure 監視器 用來彙整資料的時間戳欄位。 例如,如果您設定 "binSize": 120,則可能會取得介於 TimeGenerated 和 02:00 之間 04:00 值的項目。

設定彙總時間

根據預設,摘要規則會在下一個整數小時後不久建立第一個彙總。

Azure 監視器 所加入的短暫延遲,會將資料擷取延遲納入考量;資料擷取延遲是指從資料在受監視系統中建立,到資料可在 Azure 監視器 中供分析使用之間的時間。 預設情況下,在彙總每個分箱之前,這個延遲值介於三分半鐘與分箱大小值的 10% 之間。 在大多數情況下,這種延遲確保 Azure 監視器 會彙整每個時間區段內記錄的所有資料。

例如:

  • 您會在 14:44 建立間隔大小為 30 分鐘的摘要規則。 第一個彙總在 15:04 產生,即接下來整整一小時加上 4 分鐘延遲。
  • 您在 14:44 建立了間隔大小為 720 分鐘的摘要規則。 第一個彙總在 16:12 產生,即接下來整整一小時加上 72 分鐘 (720 間隔大小的 10%) 延遲。

使用 binStartTime 和 binDelay 參數來改變首次聚合的時間,以及 Azure 監視器 在每次聚合前增加的延遲時間。

下一節提供預設彙總時間和更進階的彙總時間選項範例。

使用預設彙總時間

在這個例子中,摘要規則是在 2023-06-07 14:44 建立的,Azure 監視器 預設延遲為四分鐘。

binSize (分鐘) 初始規則執行 第一次彙總 第二次彙總
1440 2023-06-07 15:04 2023-06-06 15:00 - 2023-06-07 15:00 2023-06-07 15:00 - 2023-06-08 15:00
720 2023-06-07 15:04 2023-06-07 03:00 - 2023-06-07 15:00 2023-06-07 15:00 - 2023-06-08 03:00
360 2023-06-07 15:04 2023-06-07 09:00 - 2023-06-07 15:00 2023-06-07 15:00 - 2023-06-07 21:00
180 2023-06-07 15:04 2023-06-07 12:00 - 2023-06-07 15:00 2023-06-07 15:00 - 2023-06-07 18:00
120 2023-06-07 15:04 2023-06-07 13:00 - 2023-06-07 15:00 2023-06-07 15:00 - 2023-06-07 17:00
六十 2023-06-07 15:04 2023-06-07 14:00 - 2023-06-07 15:00 2023-06-07 15:00 - 2023-06-07 16:00
30 2023-06-07 15:04 2023-06-07 14:30 - 2023-06-07 15:00 2023-06-07 15:00 - 2023-06-07 15:30
20 2023-06-07 15:04 2023-06-07 14:40 - 2023-06-07 15:00 2023-06-07 15:00 - 2023-06-07 15:20

設定選擇性彙總時間參數

在此範例中,摘要規則於 2023-06-07 14:44 建立,規則包含以下進階設定:

  • binStartTime:2023-06-08 07:00
  • binDelay:8 分鐘
binSize (分鐘) 初始規則執行 第一次彙總 第二次彙總
1440 2023-06-09 07:08 2023-06-08 07:00 - 2023-06-09 07:00 2023-06-09 07:00 - 2023-06-10 07:00
720 2023-06-08 19:08 2023-06-08 07:00 - 2023-06-08 19:00 2023-06-08 19:00 - 2023-06-09 07:00
360 2023-06-08 13:08 2023-06-08 07:00 - 2023-06-08 13:00 2023-06-08 13:00 - 2023-06-08 19:00
180 2023-06-08 10:08 2023-06-08 07:00 - 2023-06-08 10:00 2023-06-08 10:00 - 2023-06-08 13:00
120 2023-06-08 09:08 2023-06-08 07:00 - 2023-06-08 09:00 2023-06-08 09:00 - 2023-06-08 11:00
六十 2023-06-08 08:08 2023 年 6 月 8 日早上 7 點至 2023 年 6 月 8 日早上 8 點 2023 年 6 月 8 日早上 8 點至 2023 年 6 月 8 日早上 9 點
30 2023-06-08 07:38 2023 年 6 月 8 日早上 7 點至 2023 年 6 月 8 日早上 7 點 30 分 2023-06-08 07:30 - 2023-06-08 08:00
20 2023-06-08 07:28 2023-06-08 07:00 - 2023-06-08 07:20 2023-06-08 07:20 - 2023-06-08 07:40

查看所有摘要規則

檢視或列出工作區中的所有摘要規則。

displayName Azure 入口網站中可見的摘要規則屬性與 API 呼叫中使用的屬性不同name,尤其是當你是透過入口網站建立規則時。 屬性 name 是規則的唯一識別碼,用於 API 呼叫來管理規則。 displayName這是一個使用者友善的名稱,會在 Azure 入口網站顯示,方便辨識。

  1. 從 Azure 入口網站,前往你的 Log Analytics 工作區。
  2. 在左側選單的 設定中,選擇 規則。
  3. 選擇「 摘要規則 」標籤。

顯示 Azure 入口網站中包含所有摘要規則的摘要規則窗格的螢幕擷取畫面。

查看摘要規則

查看或更新特定摘要規則的設定。

  1. 從 Azure 入口網站,前往你的 Log Analytics 工作區。

  2. 在左側選單的 設定中,選擇 規則。

  3. 選擇「 摘要規則 」標籤。

  4. 從清單中選取您要檢視之摘要規則旁的省略符號 (...)。

  5. 選擇 編輯 以查看摘要規則設定。

    截圖顯示 Azure 入口網站中已選定的摘要規則,並有編輯選項。

  6. 選擇 下一步:設定規則邏輯 以查看摘要規則中使用的查詢。

停止摘要規則

暫停一條規則一段時間。 其中一個使用情境是,當你想驗證資料已匯入資料表,且不影響彙總資料表和報表時。

若要停止規則:

  1. 從 Azure 入口網站,前往你的 Log Analytics 工作區。
  2. 在左側選單的 設定中,選擇 規則。
  3. 選擇「 摘要規則 」標籤。
  4. 選擇 「活躍狀態 切換」按鈕,確認狀態變更為 「不活躍」。

截圖顯示 Azure 入口網站中已選取的摘要規則,狀態切換按鈕設為非活躍。

開始制定摘要規則

當你重新啟動規則時,Azure 監視器會根據定義的 binStartTime(可選)參數開始處理下一整小時的資料。

若要開始建立規則:

  1. 從 Azure 入口網站,前往你的 Log Analytics 工作區。
  2. 在左側選單的 設定中,選擇 規則。
  3. 選擇「 摘要規則 」標籤。
  4. 選擇 「非活躍狀態 切換」按鈕,確認狀態變更為 「活躍」。

截圖顯示 Azure 入口網站中已選取的摘要規則,狀態切換按鈕設為啟用。

刪除摘要規則

Log Analytics 工作區支援最多 100 條活躍摘要規則。 如果你已經有 100 條有效規則,想建立新的規則,必須先停止或刪除一個有效的摘要規則。

若要刪除規則:

  1. 從 Azure 入口網站,前往你的 Log Analytics 工作區。
  2. 在左側選單的 設定中,選擇 規則。
  3. 選擇「 摘要規則 」標籤。
  4. 從清單中選取您要檢視之摘要規則旁的省略符號 (...)。
  5. 選擇 刪除。

監視摘要規則

要監控摘要規則,請在Log Analytics工作區的 diagnostic settings 中啟用 Summary Logs 類別。 Azure 監視器 會將摘要規則的執行詳細資料(包括 Started、Succeeded 和 Failed 執行狀態)傳送至您工作區中的 LASummaryLogs 資料表。

設置日誌警示規則 ,以接收分箱失敗通知或分箱執行接近逾時的通知,如下範例所示。 根據失敗原因,請縮小分箱大小,讓每次執行處理較少的資料量;或者修改查詢,使其回傳較少的記錄或較少的高資料量欄位。

此查詢會傳回失敗的執行:

LASummaryLogs | where Status == "Failed"

此查詢會傳回 QueryDurationMs 值大於查詢執行時間上限 90% 的 Bin 執行:

LASummaryLogs | where QueryDurationMs > 0.9 * 600000

確認資料完整性

摘要規則設計為可擴展性,並包含重試機制以克服與 查詢限制相關的暫態服務或查詢失敗。 重試機制會在八小時內嘗試 10 次對聚合失敗的分箱進行聚合;如果 10 次嘗試皆失敗,則會略過該分箱。 規則會設定為 isActive: false,並在連續八次間隔重試後保留。

如果您啟用診斷設定以監視摘要規則,Azure 監視器 會在您工作區的 LASummaryLogs資料表中記錄事件,讓您可以查看執行記錄,並重試失敗的執行作業。 使用下列查詢或透過入口網站檢視執行。

let startTime = datetime("2024-02-16");
let endTime = datetime("2024-03-03");
let ruleName = "myRuleName";
let stepSize = 20m; // The stepSize value is equal to the bin size defined in the rule
LASummaryLogs
| where RuleName == ruleName
| where Status == 'Succeeded'
| make-series dcount(BinStartTime) default=0 on BinStartTime from startTime to endTime step stepSize
| render timechart

此查詢會將結果轉譯為時間圖:

螢幕擷取畫面顯示圖表,圖表顯示摘要規則中失敗間隔的查詢結果。

如需規則補救選項和主動式警示,請參閱監視摘要規則一節。

重試摘要規則 Bin

摘要規則設計為可擴展性,並包含重試機制以克服暫態服務問題或查詢限制失敗。 當服務的重試次數已用盡時,請手動重試失敗的執行作業(或 bin)。

重試是對現有規則的動作,而非資源部署。 找出失敗的 bin 的 BinStartTime,並將其用作 retryBinStartTime。 例如,對於涵蓋 2026-02-16T10:00:00Z 到 2026-02-16T11:00:00Z 的 60 分鐘時間區段,請使用 2026-02-16T10:00:00Z。

  1. 在您要重試的摘要規則最右側選取省略符號 (...)。
  2. 從功能表中選取檢視執行。
  3. 將篩選器設為顯示 失敗 的執行結果。
  4. 找到你想重試的執行時間,然後選擇該列末尾的省略號(...)。
  5. 從選單中選擇 「重新執行此儲存桶」。

顯示 Azure 入口網站中已選取失敗的摘要規則執行,並有重新執行資源回收桶選單選項的螢幕截圖。

使用客戶自控金鑰加密摘要規則查詢

KQL 查詢可以在註解或查詢語法中包含敏感性資訊。 要加密摘要規則查詢,請將儲存帳號連結到你的Log Analytics工作空間,並使用客戶管理的金鑰。

使用加密查詢時的考量事項:

  • 鏈接記憶體帳戶來加密查詢並不會中斷現有的規則。
  • 預設情況下,Azure 監視器 會將摘要規則查詢儲存在 Log Analytics 儲存中。 如果你在連結儲存帳號到Log Analytics工作區之前已有摘要規則,請更新這些規則,讓查詢能儲存在儲存帳號中。
  • 您在儲存體帳戶中儲存的查詢位於 CustomerConfigurationStoreTable 資料表中。 這些查詢會被視為服務成品,且其格式可能會變更。
  • 同一儲存帳號支援摘要規則查詢、Log Analytics 中儲存的查詢,以及日誌警示。

針對摘要規則進行疑難排解

本節提供疑難排解摘要規則的提示。

摘要規則的目的地資料表被意外刪除

如果你在摘要規則仍在運作時刪除目標資料表,規則會被暫停,Azure 監視器 會向 LASummaryLogs 資料表發送事件,並顯示規則已被暫停。

如果您不需要目的地資料表中的摘要結果,請刪除規則和資料表。 如果您需要摘要結果,請依照建立或更新摘要規則一節中的步驟重新建立目的地資料表並還原所有資料,包括刪除前內嵌的資料,視資料表中的保留原則而定。

查詢使用的運算子會在目的地資料表中建立新的資料行。

當您建立或更新摘要規則時,會定義目的地資料表結構描述。 如果查詢包含允許根據輸入資料擴充輸出結構的運算子(例如函式),arg_max(expression, *)Azure 監視器 在建立或更新規則後不會新增欄位到目標資料表,且需要這些欄位的輸出資料會被捨棄。 若要將新欄位新增至目的地資料表,請更新摘要規則,或手動將資料行新增至資料表。

根據資料表的保留設定,已刪除資料行中的資料會保留在工作區中

當你從查詢中移除欄位時,目標資料表中的資料行和資料仍會依據在資料表或工作區上定義的 保留期限 保留。 如果你不需要目標資料表中移除的欄位,請 從資料表結構中刪除這些欄位。 如果你再加入同名欄位,任何不超過保留期限的資料就會重新出現。