Azure 監視器記錄的最佳做法

本文提供 Azure 監視器記錄的架構最佳做法。 此指引是以 Azure 良好架構架構中所述的五大架構卓越要素為基礎。

可靠性

可靠性 是指系統從失敗中復原並繼續運作的能力。 與其嘗試完全防止雲端中的失敗，目標是將單一失敗元件的影響降到最低。 使用下列資訊將Log Analytics工作區的失敗降到最低，並保護他們收集的數據。

Log Analytics 工作區提供高度的可靠性。 暫時遺失工作區存取權可能會導致資料遺失的情況，通常會透過內建在擷取管線中的 Azure 監視器代理程式和保護機制等功能來緩和數據遺失。

本節所述的復原功能可以提供數據遺失和商務持續性的額外保護。 有些是區域內的解決方案，有些則提供跨區域備援;有些會自動套用，而其他則需要手動觸發。 下表摘要說明並比較這些功能。

某些可用性功能需要專用的叢集，此叢集目前需要連結至此叢集的所有工作區每天至少 100 GB 的承諾（匯總）。

設計檢查清單

• 如果您為專用叢集收集足夠的數據，請在可用性區域中建立專用叢集。
• 如果您需要在區域失敗時提供工作區，或您未為專用叢集收集足夠的數據，請設定數據收集，以將重要數據傳送至不同區域中的多個工作區。
• 如果您需要在資料中心或區域失敗的情況下保護數據，請設定從工作區匯出數據以將資料儲存在替代位置。
• 對於需要高可用性的任務關鍵性工作負載，請考慮實作同盟工作區模型。
• 監視Log Analytics工作區的健康情況。

組態建議

建議	優點
如果您收集足夠的數據，請在支援可用性區域的區域中建立專用叢集。	連結至 專用叢集 的工作區位於支援 可用性區域的 區域中，如果數據中心失敗，仍可供使用。 專用叢集需要相同區域中所有工作區每天至少 100 GB 的承諾。 如果您未收集太多數據，則需要以它所提供的可靠性功能來加權此承諾的成本。
如果您需要在發生區域失敗時，工作區中的數據可供使用，請將重要數據傳送至不同區域中的多個工作區。	將數據傳送至不同區域中的多個工作區。 例如，設定 DCR 將數據從虛擬機上執行的 Azure 監視器代理程式傳送至多個工作區，並設定多個診斷設定，以從 Azure 資源收集資源記錄到多個工作區。 即使數據會在失敗時於替代工作區中提供，但依賴數據的資源，例如警示和活頁簿，也不知道使用替代工作區。 請考慮使用 Azure DevOps 中替代工作區的設定來儲存適用於重要資源的 ARM 範本，或儲存為可在故障轉移案例中快速啟用的已停用原則。 取捨：此設定會產生重複的擷取和保留費用，因此只將其用於重要數據。
對於需要高可用性的任務關鍵性工作負載，請考慮實作使用多個工作區的同盟工作區模型，以在發生區域失敗時提供高可用性。	任務關鍵 性提供在 Azure 上建構高度可靠應用程式的規範性最佳做法指引。 設計方法包含具有多個 Log Analytics 工作區的同盟工作區模型，可在多個失敗的情況下提供 高可用性 ，包括 Azure 區域的失敗。 此策略可消除跨區域的輸出成本，並在區域失敗時維持運作，但您必須使用 Azure 上任務關鍵性工作負載的健康情況模型化和可檢視性中所述的組態和程式來管理的額外複雜度。
如果您需要在資料中心或區域失敗的情況下保護數據，請設定從工作區匯出數據以將資料儲存在替代位置。	Azure 監視器的數據匯出功能可讓您將傳送至特定數據表的數據持續匯出至 Azure 記憶體，以便保留一段時間。 使用 Azure 儲存體 備援選項，包括 GRS 和 GZRS，將此數據復寫至其他區域。 如果您需要匯出數據不支援的 數據表導出，您可以使用其他匯出數據的方法，包括 Logic Apps 來保護您的數據。 這主要是符合數據保留合規性的解決方案，因為數據可能難以分析和還原至工作區。 此選項類似於將數據多播至不同工作區的先前選項，但成本較低，因為額外的數據會寫入記憶體。 數據匯出容易受到區域事件的影響，因為它依賴您區域中 Azure 監視器擷取管線的穩定性。 它不會針對影響區域擷取管線的事件提供復原能力。
監視Log Analytics工作區的健康情況。	使用 Log Analytics 工作區深入解析 來追蹤失敗的查詢，並建立 健全狀態警示 ，以在因數據中心或區域性失敗而無法使用工作區時主動通知您。

比較復原功能和功能

功能	服務復原能力	數據備份	高可用性	保護範圍	設定	成本
可用性區域	✅ 在支援的區域內	✅	✅	區域內	在支援區域中的專用叢集上自動啟用。	無成本
連續資料匯出		✅		防止區域失敗 1	啟用每個數據表。	數據導出的成本 + 儲存體 Blob 或事件中樞
雙重擷取	✅	✅	✅	防止區域失敗	啟用每個受監視的資源。	最多保留成本的兩倍 （視您雙重內嵌的數據量而定） + 輸出費用。

¹ 如果您將記錄匯出至不同的區域，數據匯出會提供跨區域保護。 發生事件時，會備份先前匯出的數據並隨時可用;不過，視事件的性質而定，進一步導出可能會失敗。

安全性

安全性 是任何架構中最重要的層面之一。 Azure 監視器提供功能來同時採用最低許可權和深度防禦原則。 使用下列資訊，將Log Analytics工作區的安全性最大化，並確保只有授權的用戶能夠存取收集的數據。

設計檢查清單

• 判斷是否要在相同的 Log Analytics 工作區中結合操作資料和安全性資料。
• 設定組織中不同角色所需工作區中不同類型的數據的存取權。
• 請考慮使用 Azure 私人連結，從公用網路移除工作區的存取權。
• 如果您需要自己的加密金鑰來保護工作區中的數據和已儲存的查詢，請使用客戶管理的金鑰。
• 匯出長期保留或不變性的稽核數據。
• 設定記錄查詢稽核，以追蹤哪些使用者正在執行查詢。
• 決定在工作區中篩選或模糊化敏感數據的策略。
• 清除意外收集的敏感數據。
• 啟用 Microsoft Azure 的客戶加密箱，以核准或拒絕 Microsoft 數據存取要求。

組態建議

建議	優點
判斷是否要在相同的 Log Analytics 工作區中結合操作資料和安全性資料。	您決定是否要結合此數據，取決於您的特定安全性需求。 在單一工作區中結合它們可讓您更清楚地看到所有數據，不過您的安全性小組可能需要專用的工作區。 請參閱設計 Log Analytics 工作區策略，了解為環境制定此決策並與其他要素中準則達到平衡的詳細資料。 取捨：在您的工作區中啟用 Sentinel 的潛在成本影響。 請參閱設計Log Analytics工作區架構中的詳細數據。
設定組織中不同角色所需工作區中不同類型的數據的存取權。	將工作區的訪問控制模式設定為 [使用資源或工作區許可權]，以允許資源擁有者使用資源內容來存取其數據，而不獲授與工作區的明確存取權。 這可簡化您的工作區設定，並協助確保使用者無法存取他們不應該存取的數據。 指派適當的 內建角色 ，根據其責任範圍，將工作區許可權授與訂用帳戶、資源群組或工作區層級的系統管理員。 針對需要跨多個資源存取一組數據表的使用者，利用 數據表層級 RBAC 。 具有數據表許可權的使用者無論其資源許可權為何，都可以存取數據表中的所有數據。 如需授與工作區中數據存取權的不同選項詳細資訊，請參閱 管理 Log Analytics 工作區 的存取權。
請考慮使用 Azure 私人連結，從公用網路移除工作區的存取權。	公用端點的 連線 會使用端對端加密來保護。 如果您需要私人端點，您可以使用 Azure 私人鏈接 ，允許資源透過授權的專用網連線到 Log Analytics 工作區。 私人連結也可以用來強制透過 ExpressRoute 或 VPN 擷取工作區數據。 請參閱 設計您的 Azure Private Link 設定 ，以判斷您環境的最佳網路和 DNS 拓撲。
如果您需要自己的加密金鑰來保護工作區中的數據和已儲存的查詢，請使用客戶管理的金鑰。	Azure 監視器可確保所有資料和已儲存的查詢都會使用 Microsoft 管理的金鑰 (MMK) 在待用時加密。 如果您需要自己的加密金鑰，併為專用叢集收集足夠的數據，請使用客戶管理的密鑰，以取得更大的彈性和密鑰生命週期控制。 如果您使用 Microsoft Sentinel，請確定您已熟悉設定 Microsoft Sentinel 客戶自控密鑰中的考慮事項。
匯出長期保留或不變性的稽核數據。	您可能已在工作區中收集稽核數據，該數據受限於需要其長期保留的法規。 Log Analytics 工作區中的數據無法變更，但可以 清除。 使用 數據匯出 將數據傳送至具有 不變性原則 的 Azure 記憶體帳戶，以防止數據竄改。 並非所有類型的記錄都與合規性、稽核或安全性具有相同的相關性，因此請判斷應該導出的特定數據類型。
設定記錄查詢稽核，以追蹤哪些使用者正在執行查詢。	記錄查詢稽核 會記錄工作區中執行之每個查詢的詳細數據。 將此稽核數據視為安全性數據，並適當地保護 LAQueryLogs 數據表。 將每個工作區的稽核記錄設定為要傳送至本機工作區，或如果您分隔作業和安全性數據，請在專用的安全性工作區中合併。 使用 Log Analytics 工作區深入解析 定期檢閱此數據，並考慮建立記錄搜尋警示規則，以在未經授權的使用者嘗試執行查詢時主動通知您。
決定在工作區中篩選或模糊化敏感數據的策略。	您可能會收集數據，其中包含 敏感性資訊。 使用特定數據源的組態來篩選不應該收集的記錄。 如果只應移除或模糊處理數據中的特定數據行，請使用轉換。 如果您有要求未經修改原始數據的標準，您可以使用 KQL 查詢中的 『h』 常值 來模糊化活頁簿中顯示的查詢結果。
清除意外收集的敏感數據。	定期檢查工作區中可能未意外收集的私人數據，並使用 數據清除 將其移除。
啟用 Microsoft Azure 的客戶加密箱，以核准或拒絕 Microsoft 數據存取要求。	Microsoft Azure 的客戶加密箱提供您檢閱和核准或拒絕客戶資料存取要求的介面。 它用於 Microsoft 工程師需要需要存取客戶資料的情況，無論是回應客戶發起的支援憑證還是 Microsoft 所識別的問題。 若要啟用客戶加密箱，您需要專用 的叢集。

成本最佳化

成本優化 是指減少不必要的費用並提升營運效率的方法。 您可以了解不同設定選項和機會來減少 Azure 監視器收集的資料量，藉此大幅降低其成本。 請參閱 Azure 監視器成本和使用量 ，以瞭解 Azure 監視器費用的不同方式，以及如何檢視每月帳單。

注意

請參閱 將 Azure 監視器中的成本優化，以取得 Azure 監視器 所有功能的成本優化建議。

設計檢查清單

• 判斷是否要在相同的 Log Analytics 工作區中結合操作資料和安全性資料。
• 針對每個 Log Analytics 工作區通常收集的資料量設定定價層。
• 設定資料保留和封存。
• 將用於偵錯、疑難排解和稽核的資料表設定為基本記錄。
• 限制工作區從資料來源收集的資料。
• 定期分析收集的資料，以識別趨勢和異常狀況。
• 建立資料收集過高的警示。
• 考慮使用每日上限作為預防性措施，以確保您不會超過特定預算。
• 針對 Log Analytics 工作區設定 Azure Advisor 成本建議的警示。

組態建議

建議	優點
判斷是否要在相同的 Log Analytics 工作區中結合操作資料和安全性資料。	因為如果已啟用 Sentinel，則 Log Analytics 工作區中的所有資料都會受限於 Microsoft Sentinel 定價，因此合併此資料可能會對成本造成影響。 請參閱設計 Log Analytics 工作區策略，了解為環境制定此決策並與其他要素中準則達到平衡的詳細資料。
針對每個 Log Analytics 工作區通常收集的資料量設定定價層。	根據預設，Log Analytics 工作區會使用隨用隨付定價，沒有最低資料量。 如果您收集的資料量夠多，則可以使用定額層來大幅降低成本，這可讓您藉由承諾每日最低的資料收集量來換取較低費率。 如果您在單一區域中的各個工作區上收集的資料夠多，您可以將這些工作區連結至專用叢集，並使用叢集定價來合併其收集的資料量。 請參閱 Azure 監視器記錄成本計算和選項，以取得關於定額層的詳細資料，以及最適合您使用量層級的階層判斷指引。 請參閱使用量和估計成本，以檢視不同定價層的使用量估計成本。
設定資料保留和封存。	在 Log Analytics 工作區中保留數據的費用超過預設值 31 天（如果工作區已啟用 Sentinel，則為 90 天，而 Application insights 數據則為 90 天）。 請考量您的特定需求，讓資料可方便記錄查詢使用。 您可以藉由設定封存記錄來大幅降低成本，這可讓您將資料保留最多七年，而且仍可使用搜尋作業或將一組資料還原至工作區來偶爾存取資料。
將用於偵錯、疑難排解和稽核的資料表設定為基本記錄。	Log Analytics 工作區中專為基本記錄設定的資料表可降低擷取成本，但功能有限，查詢記錄也會收費。 如果您不常查詢這些資料表，而且不會將其用於警示，此查詢成本可能會高於降低擷取成本抵銷的費用。
限制工作區從資料來源收集的資料。	Azure 監視器成本的主要因素是 Log Analytics 工作區中收集的資料量，因此您應確保收集的資料量不超過評估服務和應用程式健康情況和效能所需的資料。 請參閱設計 Log Analytics 工作區結構，了解為環境制定此決策並與其他要素中準則達到平衡的詳細資料。 取捨：成本與監視需求之間可能會有所取捨。 例如，您可能能夠透過高採樣速率更快地偵測效能問題，但您可能也想要較低的採樣速率來節省成本。 大部分的環境都有多個不同集合類型的數據源，因此您必須將特定需求與每個專案的成本目標進行平衡。 如需針對不同資料來源設定收集方式的建議，請參閱 Azure 監視器中的成本最佳化。
定期分析收集的資料，以識別趨勢和異常狀況。	使用 Log Analytics工作區深入解析來定期檢閱工作區中收集的資料量。 此功能除了可協助您了解不同來源所收集的資料量之外，還會識別資料收集中可能導致成本過高的異常和上升趨勢。 使用分析 Log Analytics 工作區中的使用量中所述的方法，進一步分析資料收集，以判斷是否有其他設定可以進一步減少使用量。 當您新增一組新的資料來源 (例如一組新的虛擬機器或將新的服務上線) 時，這會特別重要。
建立資料收集過高的警示。	為了避免非預期的帳單，您應該在遇到過多使用量時主動收到通知。 通知可讓您在計費週期結束時，解決任何潛在的異常。
考慮使用每日上限作為預防性措施，以確保您不會超過特定預算。	每日上限會在達到您設定的限制之後，停用 Log Analytics 工作區中的資料收集。 這不應該當做降低成本的方法，如使用每日上限的時機中所述。 如果您設定每日上限，除了在達到上限時建立警示之外，請確定您也會建立警示規則，以在達到某個百分比時收到通知 (例如 90%)。 這可讓您在因為上限而停止資料收集之前，調查並解決資料增加的原因。
針對 Log Analytics 工作區設定 Azure Advisor 成本建議的警示。	當有機會將成本優化時，Log Analytics 工作區的 Azure Advisor 建議會主動提醒您。 針對下列成本建議建立 Azure Advisor 警示 ： 請考慮在所選數據表上設定符合成本效益的基本記錄計劃 - 我們已識別出每月擷取超過 1 GB 的數據表，這些數據表符合低成本基本記錄數據計劃資格。 基本記錄計劃可讓您以較低的成本搜尋偵錯和疑難解答功能。 請考慮變更定價層- 根據您的目前使用量量，調查變更您的定價 （承諾用量） 層以接收折扣並降低成本。 請考慮移除未使用的還原數據表 - 您在工作區中有一或多個具有已還原數據的數據表。 如果您不再使用還原的數據，請刪除數據表以避免不必要的費用。 偵測到數據擷取異常 - 我們已根據您在前三周的擷取，找出過去一周的擷取率要高得多。 請記下這項變更，以及成本的預期變更。 您也可以從 Log Analytics 工作區資源功能表中選取 [概>觀 建議 或 Advisor 建議]，以檢視自動產生的建議。

卓越營運

卓越營運是指需要讓服務在生產環境中可靠地執行作業程式。 使用下列資訊將支援Log Analytics工作區的操作需求降到最低。

設計檢查清單

• 使用最少數量的工作區來設計工作區架構，以符合您的商務需求。
• 管理多個工作區時，請使用基礎結構即程式代碼 （IaC）。
• 使用 Log Analytics 工作區深入解析來追蹤 Log Analytics 工作區的健康情況和效能。
• 建立警示規則，以主動通知工作區中的作業問題。
• 請確定您有妥善定義的數據隔離作業程式。

組態建議

建議	優點
設計工作區策略以符合您的商務需求。	如需設計 Log Analytics 工作區策略的指引，請參閱 設計 Log Analytics 工作區架構 ，包括建立多少個和放置位置。 單一或至少最少的工作區數目會最大化您的作業效率，因為它會限制作業和安全性數據的分佈、增加潛在問題的可見度、讓模式更容易識別，以及將維護需求降至最低。 您可能有多個工作區的需求，例如多個租使用者，或者您可能需要多個區域中的工作區來支援可用性需求。 在這些情況下，請確定您有適當的程式可管理此增加的複雜度。
管理多個工作區時，請使用基礎結構即程式代碼 （IaC）。	使用基礎結構即程式代碼 （IaC） 在 ARM、BICEP 或 Terraform 中定義工作區的詳細數據。 這可讓您利用現有的 DevOps 程式來部署新的工作區，並 Azure 原則 強制執行其設定。
使用 Log Analytics 工作區深入解析來追蹤 Log Analytics 工作區的健康情況和效能。	Log Analytics 工作區深入解析 提供所有工作區的使用量、效能、健康情況、代理程序、查詢和變更記錄的統一檢視。 定期檢閱這項資訊，以追蹤每個工作區的健康情況和作業。
建立警示規則，以主動通知工作區中的作業問題。	每個工作區都有一個 作業數據表 ，可記錄影響工作區的重要活動。 根據此數據表建立警示規則，以在發生作業問題時主動收到通知。 您可以使用 工作區 的建議警示來簡化最重大警示規則的建立。
請確定您有妥善定義的數據隔離作業程式。	針對儲存在工作區中的不同類型的數據，您可能有不同的需求。 在設計工作區策略和設定許可權和封存等設定時，請務必清楚了解數據保留和安全性等需求。 您也應該有一個明確定義的程式，以便偶爾清除不小心收集個人信息的數據。

效能效益

效能效率 是工作負載調整的能力，以符合使用者以有效率的方式滿足其需求。 使用下列資訊來確保Log Analytics工作區和記錄查詢已設定為最高效能。

設計檢查清單

• 設定記錄查詢稽核，並使用Log Analytics工作區深入解析來識別緩慢且效率不佳的查詢。

組態建議

建議	優點
設定記錄查詢稽核，並使用Log Analytics工作區深入解析來識別緩慢且效率不佳的查詢。	記錄查詢稽核 會儲存執行每個查詢所需的計算時間，以及傳回結果的時間。 Log Analytics 工作區深入解析 會使用此數據來列出工作區中可能沒有效率的查詢。 請考慮重寫這些查詢以改善其效能。 如需 優化記錄查詢的指引，請參閱在 Azure 監視器 中優化記錄查詢。

後續步驟

• 取得 Azure 監視器完整部署的最佳做法。