數據收集規則 （DCR） 決定如何收集和處理傳送至 Azure 的遙測。 某些資料收集規則是由 Azure Monitor 建立和管理，而您也可以自行建立其他規則，以便根據特定需求量身訂製資料收集。 本文討論建立您自己的 DCR 時應套用的一些最佳做法。
當您建立 DCR 時，需要考慮一些層面，例如：
- 收集的數據類型，也稱為數據來源類型（效能、事件）
- 與 DCR 相關聯的目標虛擬機
- 收集的數據目的地
考慮所有這些因素對於良好的 DCR 組織而言都很重要。 上述所有點都會對 DCR 管理工作以及設定傳輸和處理的資源耗用量造成影響。
假設原生數據粒度可讓指定的 DCR 與多個目標虛擬機和最多 30 個 DCR 相關聯的指定虛擬機相關聯，請務必盡可能使用較少的數據源讓 DCR 保持簡單。 務必保持每個數據源中收集的項目清單精簡，且符合可觀察性的範圍。
若要釐清 可觀察性範圍 為何，請將它視為收集數據的慣用邏輯界限。 例如，可能的範圍可以是一組執行軟體的虛擬機（例如，特定應用程式所需的 SQL Servers），或 IT 系統管理員所使用的基本作業系統計數器或事件集。 您也可以建立專用於不同環境（開發、 測試、 生產）的類似範圍，以更專門化。
事實上，建立包含所有數據源、集合專案和目的地的單一 DCR 來實現可觀察性並不理想，甚至不被推薦。 在下表中，有數個建議有助於更妥善規劃 DCR 建立和維護：
| 類別 | 最佳做法 | 說明 | 影響區域 |
|---|---|---|---|
| 資料收集 | 定義可觀察性範圍。 | 定義可觀察性範圍是較簡單且成功的 DCR 管理和組織可觀察性範圍的關鍵。 它有助於釐清集合需求，以及應該從哪個目標虛擬機執行。 如先前所述，可觀察性範圍可能是一組執行特定應用程式通用軟體的虛擬機、IT 部門的一組常見資訊等等。例如，收集基本的作系統性能計數器，例如CPU使用率、可用的記憶體和可用磁碟空間，可視為中央IT管理的範圍。 | 沒有明確定義的範圍不會帶來清晰且不允許適當的管理。 |
| 建立可檢視性範圍專屬的 DCR。 | 根據可觀察性範圍建立個別 DCR 是輕鬆維護的關鍵。 它可讓您輕鬆地將 DCR 與相關的目標虛擬機產生關聯。 | 為什麼要建立一個單一的 DCR 來同時收集操作系統性能計數器、Web 伺服器計數器和資料庫計數器？ 這種方法不僅會強制每個相關聯的虛擬機傳輸、處理和執行超出範圍的組態。 當 DCR 組態需要更新時，也需要付出更多努力。 請考慮管理包含不必要條目的範本，這種情況不太理想，並可能導致錯誤。 | |
| 在定義的可觀察性範圍內，建立數據源類型專屬的 DCR。 | 針對效能和事件建立個別 DCR 有助於根據目標機器和細微性管理設定與關聯。 例如，建立 DCR 來收集事件和效能計數器可能會導致不理想的做法。 在某些情況下，指定的計算機（或一組計算機）未在 DCR 中設定事件記錄檔或性能計數器。 在此情況下，虛擬機被迫處理和執行不必要的組態，這些組態不符合其上安裝的軟體需求。 | 未使用不同 DCR 會強制每個相關聯的虛擬機器根據安裝軟體傳輸、處理和執行可能不適用的設定。 處理組態中過多的計算資源耗用量和錯誤可能會導致 Azure 監視器代理程式 （AMA） 變得沒有回應。 此外，收集不必要的數據會增加數據擷取成本。 | |
| 數據目的地 | 根據目的地建立不同的 DCR。 | DCR 能夠同時將數據傳送至多個不同的目的地，例如 Azure 監視器計量和 Azure 監視器記錄。 擁有目的地專屬的 DCR 有助於管理數據主權或法律需求。 因為符合規範的要求可能需將資料僅傳送到允許區域中建立的允許存放庫，不同的 DCR 可以實現更細緻的目的地定位。 | 如果您未根據數據目的地分隔 DCR，可能會導致數據處理、隱私權和存取需求不符合規範。 這也可能會導致不必要的數據收集，造成非預期的成本。 |
上述原則提供建立您自己的 DCR 管理方法的基礎，以平衡可維護性、重複使用、粒度和服務限制。 DCR 也需要共享治理，以盡量減少形成孤島和不必要的工作重複。