Azure 監視器 中的轉換會在資料送入 Log Analytics 工作空間前過濾或修改。 轉換會在資料來源送達資料後、傳送到目的地之前執行。 它們是在 資料收集規則（DCR）中定義的。
標準轉換會使用一個 Kusto 查詢語言（KQL）陳述式 ，分別套用到每個輸入資料中的項目。 多階段轉換 透過宣告式處理器的管線擴展此模型，其中 KQL 查詢是轉換鏈中眾多可用處理器類型之一。
下圖說明傳入資料的轉換程序，並顯示可能使用的範例查詢。 在此範例中，僅收集message欄中包含error一詞的記錄。
支援的資料表
Log Analytics 工作區中的下表支援轉換。
- 任何在 Logs 資料表功能支援中列出，且帶有
指示的 Azure 資料表。 - 為 Azure 監視器代理程式建立的任何自訂資料表
- 附有輔助方案的自訂表格。
建立轉換
部分資料收集情境支援透過 Azure 入口網站新增轉換，但大多數情境需要使用其 JSON 定義建立新的 DCR，或在現有 DCR 中新增轉換。 請參閱 在 Azure 監視器 中建立轉換 以了解不同選項，並參閱 Azure 監視器 中轉換的最佳做法與範例 以查看常見情境的轉換查詢範例。
多階段轉換（預覽）
這很重要
多階段轉型目前正處於公開預覽階段。 請參閱Microsoft Azure 預覽的補充使用條款，以了解適用於 Azure 測試版、預覽版或其他尚未正式發布的功能的法律條款。
標準轉換會在擷取期間對傳入資料套用單一 KQL 查詢。 多階段轉換擴展了此模型，讓你能定義由多個有序處理階段組成的處理管線，隨著資料流經系統而應用。
在多階段轉換中，DCR 定義的是資料處理流程，而非單一轉換步驟。 資料會經過以下階段：
- 數據採集。 Azure 監視器 代理程式（AMA）根據 DCR 中的資料來源設定，從資源中收集資料。
- 用戶端處理。 轉換會在資料傳送至網路前，先在代理程式上本地執行。 轉換應用於原始資料，可能與標準表格表示不同。
- 攝取時處理。 資料抵達 Azure 監視器 後，會在擷取過程中進行轉換，然後資料才寫入 Log Analytics 的目標資料表。 此轉換在資料完整架構化與豐富後才適用。
- 資料傳遞。 已處理的日誌會被傳送到其最終目的地。
Processors
多階段 DCR 中的轉換是透過 處理器 定義的——處理器是小型、宣告式的建構單元，每個單元執行特定類型的操作。 處理器具備以下特性：
- 可組合。 多個處理器可以在單一轉換中串連在一起。
- 已訂購。 處理器依照轉換中定義的順序依序執行。
- 不受階段限制。 相同類型的處理器可在不同資料來源、階段或情境間使用，但在預覽時會有一些限制。
每次轉換都從標 頭處理器 開始，將原始資料轉換成已知的結構化表格格式。 標頭之後，你可以串接額外的處理器來過濾、映射、解析、聚合、豐富或套用 KQL 表達式。
以下處理器家族可供選擇：
| 家族 | Processors | Description |
|---|---|---|
| Header |
header.Syslog、 header.WindowsEvents、 header.TextLog、 header.StandardStream、 header.CustomStream、 及其他 |
將原始資料圖式化成表格格式。 必須是第一個處理器。 |
| 篩選 | filter.Basic |
根據條件評估結果刪除記錄。 |
| Map |
map.Rename、map.Drop |
重新命名、定型或刪除專欄。 |
| Parse |
parse.JsonPath、parse.XmlPath、parse.CEFAttribute |
從 JSON、XML 或 CEF 格式字串中擷取欄位。 |
| Aggregation | aggregate.Basic |
使用具有分組維度的聚合運算子來總結紀錄。 |
| 擴充 | enrich.DNSLookup |
查詢 IP 位址並新增 DNS 名稱欄位。 |
| 自訂轉換 | transform.KQL |
套用任意的 KQL 表達式。 僅適用於擷取端。 |
完整處理器參考資料，包括組態結構與輸出結構，請參見 DCR 結構 - 轉換。
用戶端與擷取端轉換
每個轉換都會被分配到特定的處理階段。 這種區別決定了運算發生的地點、網路上傳送哪些資料，以及哪些成本可以及早優化。
| 層面 | Client-side | 攝取時間 |
|---|---|---|
| 指派 | 資料來源（dataSources） |
資料流程（dataFlows） |
| 在其中執行 | Azure 監視器 Agent （VM） | Azure 監視器 服務 |
| 標頭處理器 | 特定於資料來源（例如：header.Syslog） |
header.StandardStream 或 header.CustomStream |
| 成本效益 | 透過過濾/彙整資料離開資源前，降低網路與資料擷取成本 | 在資料結構化並加入額外表格欄位後，適用 |
單一 DCR 可同時結合用戶端轉換與資料擷取時轉換。 用戶端階段的輸出會自動成為資料擷取時階段的輸入。
多階段 DCR 考量因素
- 多階段轉換需要 API 版本
2025-05-11或更新版本。 較早期的 API 版本無法辨識資料來源與資料流程上的transformations區段和transform屬性。 -
transform屬性在每個資料流中都與transformKql互斥。 DCR 可以在不同資料流之間混合新舊資料流。 - 在預覽階段，您必須手動將下游轉換的標頭與上游轉換的結果協調。 例如，如果您對 Windows 事件的原始資料流進行彙總，結果可能與對應的 Event 資料表不相容，而擷取時轉換應從自訂資料流標頭開始。
多階段處理的設計方法
設計多階段DCR時請遵循以下步驟：
- 評估資料來源與目的地。 辨識你的資料來源類型，並決定各自落在哪裡：預設標準資料表還是自訂資料表。
- 識別聚合需求。 聚合後的日誌應該放到另一個資料表中，因為其結構與原始形式不同。
- 為差異化處理做好規劃。 如果您需要以不同方式處理同一組日誌的不同部分，請建立多個相同類型但收集設定不同的資料來源，並對每個資料來源套用不同的用戶端轉換。
- 撰寫用戶端轉換。 如果輸出保留標頭結構，請使用標準串流（
Microsoft-*），若不保留則使用自訂串流（Custom-*）。 在streamDeclarations中定義自訂串流。 - 定義資料流程。 為每個串流建立一個資料流。 使用資料擷取時資料流程，透過在每個資料流程中套用不同的篩選條件，將單一串流拆分至多個目的地資料表。
工作區轉換 DCR
轉換是在數據收集規則中定義，但 Azure 監視器中仍有尚未使用 DCR 的數據集合。 例如由 診斷設定 收集的資源日誌，以及 由 Application Insights 收集的應用程式資料。
工作區轉換資料收集規則 (DCR) 是一個直接套用至 Log Analytics 工作區的特殊 DCR。 此 DCR 的目的是針對尚未對其數據收集使用 DCR 的數據執行 轉換 ，因此沒有任何方法可定義轉換。
每個工作區只能有一個工作區 DCR，但它可以包含針對任何數量支援資料表的轉換。 除非該資料來自另一個 DCR，否則這些轉換會套用至傳送至這些資料表的任何資料。
例如， 事件 數據表可用來儲存來自 Windows 虛擬機的事件。 如果您在事件數據表的工作區轉換 DCR 中建立轉換，它會套用至執行 Log Analytics 代理程式1 的虛擬機所收集的事件，因為此代理程式不會使用 DCR。 不過，從 Azure 監視器代理程式 （AMA） 傳送的任何數據都會忽略轉換，因為它會使用 DCR 來定義其數據收集。 您仍然可以使用 Azure 監視器代理程式搭配轉換，不過該轉換應包含在與代理程式相關聯的 DCR 中，而非工作區轉換 DCR 中。
1 Log Analytics代理已被棄用，但部分環境可能仍在使用。 這隻是未使用 DCR 之數據來源的其中一個範例。
Azure 監視器管線轉換
Azure 監視器 管線資料轉換提供與 Azure 監視器 中用戶端轉換類似的功能。 兩者都允許你對輸入資料套用 KQL 查詢，在資料傳送到下一步資料前過濾或修改資料。
Azure 監視器擷取時轉換會在 Azure 監視器接收到資料後、資料擷取至記錄分析工作區前執行。 Azure 監視器 的管線轉換會在資料流程的較早階段套用，允許在資料傳送至 Azure 監視器 前進行資料整形與篩選。 這使得管線轉換在從邊緣或多雲環境傳送資料時，能降低資料量與網路頻寬。
下表總結 Azure 監視器管線轉換與 Azure 監視器擷取時轉換的主要差異：
| 特徵 / 功能 | Azure 監視器管線轉換 | Azure 監視器擷取時轉換 |
|---|---|---|
| 應用時 | 在資料傳送到 Azure 監視器 之前 | Azure 監視器 收到資料後， 在它被儲存在 Log Analytics 工作區之前 |
| Definition | 定義於 Azure 監視器管線中的資料流程 | Azure 監視器 資料收集規則 (Data Collection Rules，DCRs) 中定義 |
| 語言 | Kusto 查詢語言 (KQL) | Kusto 查詢語言 (KQL) |
| 支援聚合嗎？ | Yes | 否 |
| 支援範本嗎？ | Yes | 否 |
擷取至 Azure 監視器的資料是由管線轉換以及所有後續 Azure 監視器擷取時轉換所組成的組合。 唯一的要求是管線轉換的輸出結構必須與 Azure 監視器 採集時間轉換所預期的輸入結構相符。 雖然兩種轉換都可以過濾資料，但通常在管線轉換中過濾資料更有效率，因為這樣可以減少網路上傳送的資料量。 Azure 監視器 資料擷取時間轉換所輸出的資料結構必須與 Log Analytics 工作空間中目標資料表的結構相符。
轉換成本
在 Azure 監視器雲端管線中處理記錄 (轉換和篩選) 時，依據資料被擷取到 Log Analytics 工作區的資料表類型，其計費方式會有所不同。
輔助日誌
Auxiliary Logs 會為資料處理及資料匯入 Log Analytics 工作空間設定成本。 如果 Log Analytics 工作空間中的目的地是輔助日誌資料表，則資料處理費用會適用於 Azure 監視器 接收的所有進來資料。 這包括任何 Azure 監視器擷取時轉換所處理的資料量。 資料擷取費用僅適用於傳送至輔助記錄資料表且經過擷取時轉換後的資料。 轉換可以增加或減少資料大小。
下表展示了一些例子：
| 傳入資料大小 | 透過轉換捨棄或新增的資料 | 內嵌至 Log Analytics 工作區作為輔助記錄資料表的資料 | 資料處理計費 GB | 資料擷取計費 GB |
|---|---|---|---|---|
| 20 GB | 12 GB 遺失 | 8 GB | 20 GB | 8 GB |
| 20 GB | 8 GB 丟失 | 12 GB | 20 GB | 12 GB |
| 20 GB | 新增 4 GB | 24 GB | 20 GB | 24 GB |
如需記錄處理和記錄資料擷取的價格，請參閱 Azure 監視器定價 。
分析或基本記錄
對於 Analytics 或基本記錄，轉換本身通常不會產生任何成本，但下列案例可能會導致額外費用：
- 如果轉換增加傳入資料的大小 (例如透過新增計算結果欄)，您將需要支付額外資料的標準擷取費率。
- 如果轉換將擷取的資料減少了一半以上，您將需要支付超過 50% 之已篩選資料的費用。
若要計算轉換所產生的資料處理費用，請使用下列公式:
[轉換捨棄的 GB 資料] - （[GB 傳入資料大小] / 2）。
下表顯示範例。
| 傳入資料大小 | 透過轉換捨棄或新增的資料 | 內嵌至 Log Analytics 工作區作為分析或基本記錄資料表的資料 | 資料處理計費 GB | 資料擷取計費 GB |
|---|---|---|---|---|
| 20 GB | 12 GB 遺失 | 8 GB | 2 GB | 8 GB |
| 20 GB | 8 GB 丟失 | 12 GB | 0 GB | 12 GB |
| 20 GB | 新增 4 GB | 24 GB | 0 GB | 24 GB |
若要避免這項費用，您應該先使用替代方法篩選匯入資料，再在應用轉換之前進行篩選。 如此一來，您就可以減少轉換所處理的資料量，從而將任何額外的成本降到最低。
如需記錄處理和記錄資料擷取的定價，請參閱 Azure 監視器定價 。
這很重要
如果在 Log Analytics 工作區中啟用了 Microsoft Sentinel，則無論轉換篩選多少資料，轉換為 Analytics 資料表都不會產生任何成本。
相關內容
- 深入了解資料收集規則 (DCR)。
- 在 Azure 監視器 中建立轉換，包含多階段轉換。
- 完整 JSON 架構的資料收集規則（DCR）結構，包括多階段
transformations部分。 - 為未使用 DCR 收集的資料建立工作區轉換 DCR。
- 如需了解公開預覽的背景資訊，請參閱 Azure Observability Blog 上的多階段轉換公告。