共用方式為

Log Analytics 上的 Azure Well-Architected Framework 檢視方塊

  • 發行項

Well-Architected 架構工作負載功能和效能必須以各種方式監視，並基於各種原因。 Azure 監視器 Log Analytics 工作區是監視數據中大部分的主要記錄和計量接收。 工作區支援 Azure 監視器中的多項功能，包括臨機操作查詢、視覺效果和警示。 如需一般監視原則，請參閱 監視和診斷指引。 本指南提供一般監視原則。 它會識別不同類型的數據。 它會識別 Azure 監視器支援的必要分析，也會識別儲存在工作區中的數據，以啟用分析。

本文假設您了解系統設計原則。 您也需要 Azure 監視器中 Log Analytics 工作區和功能的工作知識，以填入作業工作負載數據。 如需詳細資訊，請參閱 Log Analytics工作區概觀。

重要

如何使用本指南

每個區段都有一個 設計檢查清單 ，其中顯示相關的架構區域，以及當地語系化為技術範圍的設計策略。

此外，也包含技術功能或部署拓撲 的建議 ，可協助具體化這些策略。 這些建議並不代表Log Analytics工作區及其相關 Azure 監視器資源可用之所有設定的完整清單。 相反地，他們會列出對應至設計觀點的主要建議。 使用建議來建置概念證明、設計工作負載監視環境，或優化您現有的工作負載監視解決方案。

技術範圍

本指南著重於下列 Azure 資源的相互關聯決策。

  • Log Analytics 工作區
  • 工作負載作業記錄數據
  • 工作負載中 Azure 資源的診斷設定

可靠性

可靠性要素的目的是要 藉由建置足夠的復原能力，以及從失敗快速復原的能力，來提供持續的功能。

可靠性設計原則提供針對個別元件、系統流程和整個系統套用的高階設計策略。

Log Analytics 工作區要考慮的可靠性情況如下：

  • 工作區的可用性。
  • 在 Azure 資料中心或區域失敗的罕見案例中，保護收集的數據。

不同區域中的工作區之間目前沒有故障轉移的標準功能，但如果您有可用性或合規性的特定需求，請使用策略。

可靠性的設計檢查清單

根據 可靠性的設計檢閱檢查清單 開始您的設計策略，並判斷其與業務需求的相關性，同時請記住虛擬機的 SKU 和功能， (VM) 及其相依性。 擴充策略，視需要包含更多方法。

  • 檢閱 Log Analytics工作區的服務限制。 服務限制區段可協助您了解數據收集和保留的限制，以及服務的其他層面。 這些限制可協助您判斷如何正確設計工作負載可觀察性策略。 請務必檢閱 Azure 監視器服務限制 ，因為其中討論的許多函式，例如查詢，可與 Log Analytics 工作區共同作業。
  • 規劃工作區復原和復原。 Log Analytics 工作區是區域性的，沒有跨區域備援或複寫的內建支援。 此外，可用性區域備援選項有限。 因此，您應該判斷工作區的可靠性需求，並制定策略以符合這些目標。 您的需求可能會規定您的工作區必須具備數據中心失敗或區域失敗的復原能力，或者可能會規定您必須能夠將數據復原到故障轉移區域中的新工作區。 每個案例都需要額外的資源和程式才能成功，因此應謹慎考慮平衡可靠性目標與成本和複雜性。
  • 選擇正確的部署區域，以符合您的可靠性需求。 (DCE 部署 Log Analytics 工作區和數據收集端點，) 與發出作業數據的工作負載元件共置。 您可以選擇部署工作區的適當區域，而您的 DCE 應依照您 部署工作負載的位置來通知。 您可能需要根據工作負載可靠性、成本和效能需求更集中的其他因素，來衡量特定 Log Analytics 功能的區域可用性，例如專用叢集。
  • 確定您的可觀察性系統狀況良好。 就像工作負載的任何其他元件一樣，請確定您的監視和記錄系統正常運作。 若要達成此目的，請啟用將健康情況數據訊號傳送給作業小組的功能。 設定 Log Analytics 工作區和相關聯資源特有的健康情況數據訊號。

可靠性的組態建議

建議 優點
請勿在 工作負載的重要路徑中包含Log Analytics工作區。 您的工作區對於正常運作的可觀察性系統很重要，但工作負載的功能不應相依於它們。 將工作區和相關聯的函式保留在工作負載的重要路徑外，可將影響您可觀察性系統的問題風險降到最低，而不會影響工作負載的運行時間執行。
若要支援工作區數據的高持久性，請將Log Analytics工作區部署到支援資料復原 的區域 。 數據復原功能只能透過將工作區連結至相同區域中 的專用叢集 來達成。 當您使用專用叢集時，它可讓您將相關聯的工作區分散到可用性區域，以提供數據中心中斷的保護。 如果您現在未收集足夠的數據來證明專用叢集，此先佔區域選擇可支援未來的成長。
根據您的工作負載鄰近性選擇您的工作區部署。

在與 Log Analytics 工作區相同的區域中使用數據收集端點 (DCE) 。		 將工作區部署在與工作負載實例相同的區域中。 讓工作區和 DCE 位於與工作負載相同的區域中，可降低其他區域中中斷的影響風險。

Azure 監視器代理程式和記錄擷取 API 會使用 DCE，將工作負載作業數據傳送至 Log Analytics 工作區。 即使您的部署只有單一工作區，您仍可能需要多個 DCE。 如需如何針對特定環境設定 DCE 的詳細資訊，請參閱 如何根據您的部署設定數據收集端點。<Br
如果您的工作負載部署在主動-主動設計中，請考慮使用分散在工作負載部署所在區域的多個工作區和 DCE。

在多個區域中部署工作區會增加環境的複雜性。 平衡 設計Log Analytics工作區架構 與可用性需求中所述的準則。
如果您需要在區域失敗中 提供工作區 ，或您未收集足夠的數據供專用叢集使用，請設定數據收集，以將重要數據傳送至不同區域中的多個工作區。 此做法也稱為記錄多播。

例如，針對在 VM 上執行的 Azure 監視器代理程式設定多個工作區的 DCR。 設定多個診斷設定，以從 Azure 資源收集資源記錄，並將記錄傳送至多個工作區。
如此一來，如果發生區域失敗，工作負載作業數據就會在替代工作區中使用。 但知道依賴警示和活頁簿等數據的資源不會自動復寫到其他區域。 請考慮將 Azure Resource Manager (ARM) 範本儲存為具有替代工作區設定的重要警示資源，或將它們部署在所有區域中，但停用它們以防止備援警示。 這兩個選項都支援區域失敗中的快速啟用。

取捨：此設定會產生重複的擷取和保留費用，因此只將它用於重要數據。
如果您需要在資料中心或區域失敗中 保護數據 ，請設定從工作區 匯出數據 以將資料儲存在替代位置。

此選項類似於將數據多播至不同工作區的上一個選項。 但此選項的成本較低，因為額外數據會寫入記憶體。

使用 Azure 記憶體備援選項，包括異地備援記憶體 (GRS) 和異地區域備援記憶體 (GZRS) ，以進一步將此數據復寫至其他區域。

數據匯出不會針對影響區域擷取管線的事件提供復原能力。		 雖然歷史作業記錄數據可能無法在匯出狀態下立即查詢，但可確保數據在長時間發生區域性中斷時仍可存留，並可存取並保留一段時間。

如果您需要匯出 數據不支援的數據表導出，您可以使用其他匯出數據的方法，包括 Logic Apps 來保護您的數據。

若要讓此策略以可行的復原方案運作，您必須具備程式，才能針對 Azure 中的資源，以及提供數據的所有代理程式，重新設定診斷設定。 您也必須計劃手動將匯出的數據重新凍結到新的工作區。 如同先前所述的選項，您也需要為依賴警示和活頁簿等數據的資源定義處理程式。
對於需要高可用性的任務關鍵性工作負載，請考慮實作使用多個工作區的同盟工作區模型，以在發生區域失敗時提供高可用性。 任務關鍵 性提供在 Azure 上設計高度可靠應用程式的規範性最佳做法指引。 設計方法包含具有多個 Log Analytics 工作區的同盟工作區模型，可在有多個失敗時提供 高可用性 ，包括 Azure 區域的失敗。

此策略可消除跨區域的輸出成本，並持續運作，併發生區域失敗。 但您必須使用 Azure 上任務關鍵性工作負載的健康情況模型化和可觀察性中所述的組態和程式來管理更複雜的情況。
使用基礎結構即程式代碼 (IaC) 來部署和管理工作區和相關聯的函式。 當您自動化大部分的部署，以及復原和復原的機制時，它可確保這些作業可靠。 您可以在作業流程中節省重要時間，並將人為錯誤的風險降到最低。

請確定已儲存的記錄查詢等函式也會透過您的 IaC 定義，以在需要復原時將它們復原到新的區域。
以單一責任原則設計 DCR，讓 DCR 規則保持簡單。

雖然一個 DCR 可以載入來源系統的所有輸入、規則和目的地，但最好設計依賴較少數據源的縮小焦點規則。 使用規則指派的組合，以到達邏輯目標所需的可觀察性範圍。

此外，將 DCR 中的轉換降至最低		 當您使用縮小焦點的 DCR 時，它會將規則設定錯誤的風險降到最低，併產生更廣泛的效果。 它只會將效果限制為僅建置 DCR 的範圍。 如需詳細資訊，請參閱 在 Azure 監視器中建立和管理數據收集規則的最佳做法。

雖然轉換在某些情況下可能強大且必要，但測試及疑難解答關鍵詞查詢語言 (KQL) 工作可能很困難。 可能的話，藉由擷取數據原始和處理查詢時間下游的轉換，將數據遺失的風險降到最低。
設定 每日上限 或保留原則時，請務必藉由擷取並保留所需的記錄來維護可靠性需求。 一旦達到指定的數量，每日上限就會停止工作區的數據收集，這可協助您維持對擷取磁碟區的控制權。 但在仔細規劃之後，才使用這項功能。 請確定您的每日上限不會定期達到。 如果發生這種情況，您的上限會太嚴格地設定。 您需要重新設定每日上限，因此您不會錯過來自工作負載的重要訊號。

同樣地，請務必謹慎且謹慎地處理數據保留原則的降低，以確保您不小心遺失重要數據。
使用 Log Analytics 工作區深入解析 來追蹤擷取磁碟區、擷取的數據與您的數據上限、沒有回應的記錄來源，以及其他數據之間的失敗查詢。 建立 健康狀態警示 ，以在因數據中心或區域失敗而無法使用工作區時主動通知您。 此策略可確保您可以成功監視工作區的健康情況，並在健康情況處於降級風險時主動採取行動。 就像工作負載的任何其他元件一樣，請務必瞭解健康情況計量，並識別一段時間後改善可靠性的趨勢。

Azure 原則

Azure 不提供與 Log Analytics 工作區可靠性相關的原則。 您可以建立 自定義原則 ，以在工作區部署周圍建置合規性防護措施，例如確保工作區與專用叢集相關聯。

雖然與 Log Analytics 工作區的可靠性不直接相關，但幾乎每個可用的服務都有 Azure 原則。 原則可確保該服務已啟用診斷設定，並驗證服務的記錄數據是否流向Log Analytics工作區。 工作負載架構中的所有服務都應該將其記錄數據傳送至Log Analytics工作區，以符合自己的可靠性需求，而原則可協助強制執行。 同樣地，原則也存在以確保代理程式型平臺，例如 VM 和 Kubernetes，已安裝代理程式。

Azure Advisor

Azure 不提供與 Log Analytics 工作區可靠性相關的 Azure Advisor 建議。

安全性

安全性要素的目的是要為工作負載提供 機密性、完整性和可用性 保證。

安全性設計原則提供高階設計策略，可藉由將方法套用至監視和記錄解決方案的技術設計，以達成這些目標。

安全性的設計檢查清單

根據 安全性的設計檢閱檢查清單 開始您的設計策略，並識別弱點和控件以改善安全性狀態。 擴充策略，視需要包含更多方法。

  • 檢閱 Azure 監視器 安全性基準 和管理 Log Analytics 工作區的存取 權主題。 這些主題提供安全性最佳做法的指引。
  • 使用分割作為基底準則來部署您的工作區。 在網路、數據和存取層級實作分割。 分割有助於確保您的工作區隔離到適當的程度，並更妥善地防止未經授權的存取，同時仍符合可靠性、成本優化、營運卓越和效能效率的商務需求。
  • 請確定您可以稽核工作區讀取和寫入活動和相關聯的身分識別。 攻擊者可以受益於檢視作業記錄。 遭入侵的身分識別可能會導致記錄插入式攻擊。 啟用從 Azure 入口網站執行的作業稽核，或透過 API 互動和相關聯的用戶執行。 如果您未設定為稽核工作區，您可能會讓組織有違反合規性需求的風險。
  • 實作強固的網路控制。 透過網路隔離和防火牆功能，協助保護您的對工作區和記錄的網路存取。 設定不足的網路控制可能會讓您面臨未經授權的或惡意執行者存取的風險。
  • 判斷數據類型需要固定性或長期保留。 您的記錄數據應該與生產系統內的工作負載數據相同。 在數據分類實務中包含記錄數據，以確保您已成功根據其合規性需求儲存機密記錄數據。
  • 透過加密保護待用記錄數據。 單獨分割不會完全保護記錄數據的機密性。 如果發生未經授權的原始存取，讓待用記錄數據加密有助於防止不良的動作專案在工作區外部使用該數據。
  • 透過模糊處理保護機密記錄數據。 就像位於生產系統中的工作負載數據一樣，您必須採取額外的措施，以確保機密性會保留給可能刻意或意外出現在作業記錄中的敏感性資訊。 當您使用混淆方法時，它可協助您隱藏機密記錄數據，使其免於未經授權的眼睛。

安全性的組態建議

建議 優點
如果您需要自己的加密金鑰來保護工作區中的數據和已儲存的查詢，請使用客戶管理的金鑰。

Azure 監視器可確保所有資料和已儲存的查詢都會使用 Microsoft 管理的金鑰 (MMK) 進行待用加密。 如果您需要自己的加密金鑰，併為 專用叢集收集足夠的數據，請使用 客戶管理的金鑰。 您可以在 Azure 金鑰保存庫 中使用自己的金鑰來加密數據，以控制密鑰生命週期，以及撤銷數據的存取權。

如果您使用 Microsoft Sentinel，請確定您已熟悉 設定 Microsoft Sentinel 客戶管理的密鑰中的考慮。		 此策略可讓您在 Azure 金鑰保存庫 中使用自己的金鑰來加密數據，以控制密鑰生命週期，以及撤銷資料的存取權。
設定 記錄查詢稽核 ，以追蹤哪些使用者正在執行查詢。

設定每個工作區的稽核記錄，以傳送至本機工作區，或如果您分隔作業和安全性數據，請在專用的安全性工作區中合併。 使用 Log Analytics工作區深入解析 定期檢閱此數據。 請考慮建立記錄查詢警示規則，以在未經授權的使用者嘗試執行查詢時主動通知您。		 記錄查詢稽核會記錄工作區中每個查詢執行的詳細數據。 將此稽核數據視為安全性數據，並適當地保護 LAQueryLogs 數據表。 此策略可協助確保未經授權的存取在發生時立即攔截到您的安全性狀態。
透過專用網和分割量值協助保護您的工作區。

使用 私人連結 功能，將記錄來源與工作區之間的通訊限制為專用網。		 當您使用私人連結時，它也可讓您控制哪些虛擬網路可以存取指定的工作區，透過分割進一步強化您的安全性。
使用 Microsoft Entra ID，而不是 API 金鑰，以供工作區 API 存取使用。 以 API 金鑰為基礎的 查詢 API 存取不會留下個別用戶端稽核線索。 使用足夠的範圍 專案標識碼型存取 ，以便正確稽核程式設計存取。
設定組織中不同角色所需工作區中不同數據類型數據的存取權。

將工作區的 訪問控制模式 設定為 [使用資源或工作區許可權]。 此訪問控制可讓資源擁有者使用 資源內容 來存取其數據，而不會獲得工作區的明確存取權。

針對需要跨多個資源存取一組數據表的使用者，請使用 數據表層級 RBAC 。		 此設定可簡化您的工作區設定，並協助確保使用者無法存取他們不應存取的操作數據。

指派適當的 內建角色 ，根據其責任範圍，將工作區許可權授與訂用帳戶、資源群組或工作區層級的系統管理員。

具有數據表許可權的使用者可以存取數據表中的所有數據，而不論其資源許可權為何。

如需授與工作區中數據存取權之不同選項的詳細資訊，請參閱 管理 Log Analytics 工作區的存取 權。
匯出需要長期保留或固定性的記錄。

使用 數據匯出 將數據傳送至具有 不變性原則 的 Azure 記憶體帳戶，以協助防止數據竄改。 並非所有類型的記錄都與合規性、稽核或安全性具有相同的相關性，因此請判斷應該導出的特定數據類型。		 您可能會在工作區中收集稽核數據，該數據受限於需要長期保留的法規。 Log Analytics 工作區中的數據無法改變，但可以 清除。 匯出作業數據的複本以供保留之用，可讓您建置符合合規性需求的解決方案。
決定在工作區中篩選或模糊敏感數據的策略。

您可能會收集數據，其中包含 敏感性資訊。 使用特定數據源的組態來篩選不應收集的記錄。 如果只應移除或模糊處理數據中的特定數據行，請使用 轉換 。

如果您有需要未經修改原始數據的標準，您可以使用 KQL 查詢中的 'h' 常值 來混淆活頁簿中顯示的查詢結果。		 混淆或篩選工作區中的敏感數據可協助您確保機密性對敏感性資訊保持機密性。 在許多情況下，合規性需求會規定您可以處理敏感性資訊的方式。 此策略可協助您主動遵守需求。

Azure 原則

Azure 提供與 Log Analytics 工作區安全性相關的原則，以協助強制執行您想要的安全性狀態。 這類原則的範例包括：

Azure 也提供許多原則來協助強制執行私人連結設定，例如 Log Analytics 工作區應該封鎖來自公用網路的記錄擷取和查詢，或甚至透過一些要求原則來設定解決方案，例如設定 Azure 監視器 Private Link 範圍以使用私人 DNS 區域。

Azure Advisor

Azure 不提供與 Log Analytics 工作區安全性相關的 Azure Advisor 建議。

成本最佳化

成本優化著重於 偵測支出模式、優先處理重要領域的投資，以及優化其他人 以符合組織的預算，同時符合商務需求。

成本優化設計原則提供達成這些商務目標的高階設計策略。 它們也可協助您在與監視和記錄解決方案相關的技術設計中視需要做出取捨。

如需如何計算Log Analytics工作區數據費用的詳細資訊，請參閱 Azure 監視器記錄成本計算和選項。

成本優化的設計檢查清單

根據投資 成本優化的設計檢閱檢查清單 開始設計策略，並微調設計，讓工作負載符合為工作負載配置的預算。 您的設計應該使用正確的 Azure 功能、監視投資，以及尋找經過一段時間優化的機會。

  • 執行成本模型化練習。 這些會協助您瞭解目前的工作區成本，並預測相對於工作區成長的成本。 分析工作負載中的成長趨勢，並確定您瞭解工作負載擴充的計劃，以正確預測未來的作業記錄成本。
  • 選擇正確的計費模型。 使用成本模型來判斷案例的最佳 計費模型 。 您目前如何使用您的工作區，以及您打算在工作負載演進時使用這些工作區的方式，會決定隨用隨付或承諾用量層模型最適合您的案例。

    請記住，您可以為每個工作區選擇不同的計費模型，而且在特定情況下可以合併工作區成本，因此您可以在分析和決策制定時更細微。
  • 只收集正確的記錄數據量。 對資源、數據收集規則組態和自定義應用程式程式代碼記錄執行診斷設定的定期排程分析，以確保您不會收集不必要的記錄數據。
  • 以不同於生產環境的方式處理非生產環境。 檢閱您的非生產環境，以確保您已適當地設定診斷設定和保留原則。 這些通常比生產環境低很多，特別是針對開發/測試或沙盒環境。

成本優化的設定建議

建議 優點
針對每個Log Analytics工作區通常會收集的數據量設定定價層。 根據預設，Log Analytics 工作區會使用隨用隨付定價，而不需要最低數據量。 如果您收集足夠的數據，您可以使用 承諾層大幅降低成本，這可讓您承諾每天收集的最小數據，以降低費率。 如果您在單一區域中的工作區之間收集足夠的數據，您可以將這些數據連結到 專用叢集 ，並使用 叢集定價來合併其收集的磁碟區。

如需有關承諾層的詳細資訊，以及判斷最適合使用量層級的指引，請參閱 Azure 監視器記錄成本計算和選項。 若要檢視不同定價層使用量的估計成本，請參閱 使用量和估計成本。
設定數據保留和封存。 在 Log Analytics 工作區中保留資料超過預設值 31 天的費用。 如果工作區上已啟用 Microsoft Sentinel，且 Application Insights 數據為 90 天，則為 90 天。 請考慮您的特定需求，讓數據隨時可供記錄查詢使用。 您可以藉由設定 封存的記錄來大幅降低成本。 封存的記錄可讓您將數據保留最多七年，而且偶爾仍會存取它。 您可以使用 搜尋作業 或 將一組數據還原 至工作區來存取數據。
如果您使用 Microsoft Sentinel 分析安全性記錄，請考慮採用個別工作區來儲存這些記錄。 當您針對 SIEM 使用的記錄數據使用專用工作區時，可協助您控制成本。 Microsoft Sentinel 使用的工作區受限於 Microsoft Sentinel 定價。 您的安全性需求會指定 SIEM 解決方案中必須包含的記錄類型。 您可以排除作業記錄，如果它們位於個別工作區，則會以標準Log Analytics定價收費。
將用於偵錯、疑難解答和稽核的數據表設定為基本記錄。 針對 基本記錄 設定的 Log Analytics 工作區中的數據表，會以較低的擷取成本來交換有限的功能，以及記錄查詢的費用。 如果您不常查詢這些數據表，而且不要將它們用於警示，此查詢成本可能會比減少的擷取成本來位移。
限制工作區數據源的數據收集。 Azure 監視器成本的主要因素是您在 Log Analytics 工作區中收集的數據量。 請確定您收集的數據不超過評估服務與應用程式的健康情況和效能所需的數據。 針對每個資源，針對您設定的診斷設定選取正確的類別，以提供您需要的作業數據量。 它可協助您成功管理工作負載，而不會管理忽略的數據。

成本與監視需求之間可能會有取捨。 例如，您可以更快速地偵測高取樣率的效能問題，但您可能想要較低的取樣率來節省成本。 大部分的環境都有多個具有不同集合類型的數據源，因此您必須將特定需求與每個專案的成本目標進行平衡。 如需為不同數據源設定收集的建議，請參閱 Azure 監視器中的成本優化 。
定期分析工作區使用量數據，以識別趨勢和異常狀況。

使用 Log Analytics工作區深入解析 定期檢閱工作區中所收集的數據量。 使用在 Log Analytics 工作區中分析使用量 的方法進一步分析數據收集，以判斷是否有其他設定可進一步減少使用量。		 藉由協助您瞭解不同來源所收集的數據量，它會識別數據收集中的異常狀況和向上趨勢，這可能會導致成本過高。 當您將一組新的數據源新增至工作負載時，此考慮很重要。 例如，如果您新增一組新的 VM，請在服務上啟用新的 Azure 診斷設定，或變更應用程式中的記錄層級。
在數據收集很高時建立警示。 若要避免非預期的帳單，您應該在 遇到過多使用量時主動收到通知。 通知可讓您在計費期間結束時解決任何潛在的異常狀況。
請考慮每日上限作為預防措施，以確保您不會超過特定預算。 每日上限會在達到您設定的限制之後，停用 Log Analytics 工作區中的資料收集。 請勿使用這個做法作為降低成本的方法，如 何時使用每日上限中所述，而是避免因設定錯誤或濫用而造成失控擷取。

如果您設定每日上限， 請在達到上限時建立警示。 當 達到某些百分比時，請務必建立警示規則。 例如，您可以設定達到 90% 容量時的警示規則。 此警示可讓您在上限從工作負載關閉重要數據收集之前，調查並解決增加數據的原因。

Azure 原則

Azure 不提供與 Log Analytics 工作區成本優化相關的原則。 您可以建立 自定義原則 來建置工作區部署的合規性防護措施，例如確保工作區包含正確的保留設定。

Azure Advisor

Azure Advisor 會針對接收相對高擷取磁碟區的數據表，建議將工作區中的特定數據表移至低成本的基本記錄數據計劃。 在切換之前，先使用基本記錄來瞭解限制。 如需詳細資訊，請參閱 何時應該使用基本記錄？。 Azure Advisor 也可能建議根據整體使用量量，變更整個工作區的 定價承諾層 。

卓越營運

卓越營運主要著重於 開發實務、可觀察性和發行管理的程式。

營運卓越設計原則提供高階設計策略，以達成這些目標，以達到工作負載的操作需求。

營運卓越設計檢查清單

根據 營運卓越設計檢查清單 開始設計策略，以定義與 Log Analytics 工作區相關的可檢視性、測試和部署程式。

  • 針對與工作負載Log Analytics工作區相關的所有函式，使用基礎結構即程式代碼 (IaC) 。 藉由透過程式代碼自動化這些函式，將手動管理和操作記錄收集、擷取、儲存、儲存和查詢函式，包括已儲存的查詢和查詢套件，可能會發生人為錯誤的風險降到最低。 此外，也包括報告健康情況狀態變更的警示，以及將記錄傳送至 IaC 程式代碼中工作區之資源的診斷設定。 將程式代碼與其他工作負載相關的程式代碼包含在內，以確保您的安全部署作法會針對工作區的管理進行維護。
  • 請確定您的工作區狀況良好，並在發生問題時收到通知。 就像工作負載的任何其他元件一樣，您的工作區可能會遇到問題。 這些問題可能需要寶貴的時間和資源來進行疑難解答及解決，而且可能會讓您的小組不知道生產工作負載狀態。 能夠主動監視工作區並減輕潛在問題，可協助作業小組將花費在疑難解答和修正問題的時間降到最低。
  • 將您的生產環境與非生產工作負載分開。 請避免不必要的複雜度，因為作業小組會針對生產環境使用與非生產環境所使用的工作區不同， 傳入的數據也可能會導致混淆，因為測試活動可能會顯示為生產環境中的事件。
  • 偏好使用非 Microsoft 解決方案的內建工具和函 式使用內建工具來擴充監視和記錄系統的功能。 您可能需要就地設定其他設定，以支援Log Analytics工作區現用的復原性或數據主權等需求。 在這些情況下，只要可行，請使用原生 Azure 或 Microsoft 工具來保留組織至少必須支援的工具數目。
  • 將工作區視為靜態而非暫時元件 如同其他類型的數據存放區，工作區不應視為工作負載的暫時元件。 Well-Architected 架構通常會偏好不可變的基礎結構，以及快速且輕鬆地取代工作負載內的資源作為部署的一部分的能力。 但工作區數據遺失可能是重大且無法復原的。 因此，將工作區保留在部署套件中，以取代更新期間的基礎結構，而且只會在工作區上執行就地升級。
  • 請確定作業人員已訓練 Kusto 查詢語言 訓練員工，以在需要時建立或修改查詢。 如果操作員無法寫入或修改查詢，它可能會使重大疑難解答或其他功能變慢，因為操作員必須依賴其他小組來執行該工作。

營運卓越設定建議

建議 優點
設計工作區策略以符合您的商務需求。

如需設計 Log Analytics 工作區策略的指引，請參閱 設計 Log Analytics 工作區架構 。 包含要建立多少個和放置位置。

如果您需要工作負載使用集中式平臺小組供應專案，請確定您已設定所有必要的作業存取權。 此外，建構警示以確保符合工作負載可檢視性需求。		 單一或至少最少的工作區數目會將工作負載的作業效率最大化。 它會限制作業和安全性數據的分佈、增加潛在問題的可見度、讓模式更容易識別，並將維護需求降至最低。

您可能有多個工作區的需求，例如多個租使用者，或者您可能需要多個區域中的工作區來支援可用性需求。 因此，請確定您已備妥適當的程式來管理此增加的複雜度。
使用基礎結構即程式代碼 (IaC) 來部署和管理工作區和相關聯的函式。 使用基礎結構即程式代碼 (IaC) ，在 ARM 範本、 Azure BICEP 或 Terraform 中定義工作區的詳細數據。 它可讓您使用現有的 DevOps 程式來部署新的工作區，並 Azure 原則 強制執行其設定。

將所有 IaC 程式代碼與應用程式程式碼共置，有助於確保所有部署都維持安全部署做法。
使用 Log Analytics 工作區深入解析來追蹤 Log Analytics 工作區的健康情況和效能，並建立有意義且可採取動作的警示，以主動通知操作問題。

Log Analytics 工作區深入解析 提供所有工作區使用量、效能、健康情況、代理程式、查詢和變更記錄的統一檢視。

每個工作區都有 一個作業數據表 ，可記錄影響工作區的重要活動。		 檢閱Log Analytics深入解析定期提供的資訊，以追蹤每個工作區的健康情況和作業。 當您使用這項資訊時，它可讓您輕鬆地建立儀錶板或報表等視覺效果，讓作業和項目關係人可用來追蹤工作區的健康情況。

根據此數據表建立警示規則，以在發生操作問題時主動收到通知。 您可以使用 工作區的建議警示 ，以簡化您建立最重要警示規則的方式。
經常重新流覽資源、數據收集規則和應用程式記錄詳細資訊的 Azure 診斷設定，以練習持續改善。

請確定您透過經常檢閱資源設定來優化記錄收集策略。 從操作觀點來看，請專注於提供資源健康狀態實用信息的記錄，藉此減少記錄中的雜訊。		 藉由以這種方式優化，您可以讓操作員在發生問題時調查和疑難解答問題，或執行其他例行性、隨插即用或緊急工作。

當新的診斷類別可供資源類型使用時，請檢閱使用此類別發出的記錄類型，以瞭解啟用這些記錄是否有助於您將收集策略優化。 例如，新的類別可能是正在擷取之一組較大活動的子集。 新的子集可讓您將焦點放在作業要追蹤的重要活動，藉此減少所傳入的記錄數量。

Azure 原則 和 Azure Advisor

Azure 不提供任何原則，也不提供與 Log Analytics 工作區營運卓越相關的 Azure Advisor 建議。

效能效率

效能效率是關於 維護用戶體驗，即使 藉由管理容量增加。 此策略包括調整資源、識別和優化潛在的瓶頸，以及優化尖峰效能。

效能效率設計原則提供針對預期使用量達成這些容量目標的高階設計策略。

效能效率的設計檢查清單

根據 效能效率的設計檢閱檢查清單 開始設計策略，以定義Log Analytics工作區和相關聯函式的基準。

  • 熟悉 Azure 監視器中記錄數據擷取延遲的基本概念。 將記錄擷取到工作區時，有數個因素會造成延遲。 許多這些因素都是 Azure 監視器平臺固有的。 瞭解因素和一般延遲行為，可協助您在工作負載作業小組內設定適當的預期。
  • 將非生產與生產工作負載分開。 生產特定工作區可減輕非生產系統可能引進的任何額外負荷。 其可減少工作區的整體使用量，需要較少的資源來處理記錄數據處理。
  • 選擇正確的部署區域，以符合您的效能需求。 部署Log Analytics工作區和資料收集端點， (DCE) 接近您的工作負載。 選擇部署工作區的適當區域，以及您的 DCE 應該會通知您部署工作負載的位置。 如果您已將工作負載部署到無法支援記錄數據之需求的區域，您可能需要根據可靠性需求，在與工作負載相同的區域中部署工作區和 DCE 的效能優勢。

效能效率的設定建議

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

記錄查詢稽核 會儲存執行每個查詢所需的計算時間，以及傳回結果之前的時間。 Log Analytics 工作區深入解析會 使用此數據來列出工作區中可能沒有效率的查詢。 請考慮重寫這些查詢以改善其效能。 如需優化 記錄查詢的指引，請參閱優化 Azure 監視器中的記錄查詢 。		 優化查詢會更快傳回結果，並在後端使用較少的資源，讓依賴這些查詢的進程也更有效率。
瞭解 Log Analytics 工作區的服務限制。

在某些高流量實作中，您可能會遇到會影響效能的服務限制，以及您的工作區或工作負載設計。 例如，查詢 API 會限制查詢所傳回的記錄和數據磁碟區數目。 記錄擷取 API 會限制每個 API 呼叫的大小。

如需 Azure 監視器和 Log Analytics 工作區 限制和工作區本身專屬限制的完整清單，請參閱 Azure 監視器服務限制。		 瞭解可能會影響工作區效能的限制，可協助您適當地設計以減輕這些限制。 您可能會決定使用多個工作區，以避免達到與單一工作區相關聯的限制。

針對其他要素的需求和目標，衡量設計決策以減輕服務限制。
建立一或多個已定義可檢視範圍內數據源類型特有的 DCR。 為效能和事件建立個別的 DCR，以優化後端處理計算使用率。 當您針對效能和事件使用不同的 DCR 時，有助於減輕後端資源耗盡。 藉由結合效能事件的 DCR，它會強制每個相關聯的虛擬機傳輸、處理和執行可能不符合已安裝軟體的組態。 處理設定時可能會發生過多的計算資源耗用量和錯誤，並導致 Azure 監視器代理程式 (AMA) 變得沒有回應。

Azure 原則 和 Azure Advisor

Azure 不提供任何原則，也不會提供與 Log Analytics 工作區效能相關的 Azure Advisor 建議。

後續步驟