設計和建立監視系統的建議

  • 發行項

適用於此 Azure Well-Architected Framework Operational Excellence 檢查列表建議：

OE：07 設計和實作監視系統來驗證設計選擇，並通知未來的設計和商務決策。 此系統會擷取並公開作業遙測、計量和記錄，這些記錄會從工作負載的基礎結構和程式代碼發出。

相關指南： 檢測應用程序的建議

本指南說明設計和建立監視系統的建議。 若要有效地監視工作負載的安全性、效能和可靠性，您需要一個包含其本身堆疊的完整系統，以提供所有監視、偵測和警示功能的基礎。

定義

詞彙 定義
記錄 錄製的系統事件。 記錄可以包含結構化或自由格式文字格式的不同數據類型。 它們包含時間戳。
計量 定期收集的數值。 計量會在特定時間描述系統的一些層面。

主要設計策略

若要為您的工作負載實作完整的監視系統設計，請遵循下列核心原則：

  • 只要可行，請利用平臺提供的監視工具，這通常需要非常少的設定，而且可以提供您工作負載的深入解析，否則可能難以完成。

  • 從整個工作負載堆疊收集記錄和計量。 所有基礎結構資源和應用程式函式都應該設定為產生標準化、有意義的數據，以及需要收集數據。

  • 將收集的數據儲存在標準化、可靠且安全的儲存解決方案中。

  • 處理已儲存的數據，以便透過分析和視覺效果解決方案來處理。

  • 分析已處理的數據，以精確地判斷工作負載的狀態。

  • 將工作負載的狀態可視化，以有意義的儀錶板或報表呈現工作負載小組和其他項目關係人。

  • 設定可採取動作的警示和其他自動回應，以智慧方式定義的閾值，以在問題發生時通知工作負載小組。

  • 在您的整體工作負載測試實務中包含監視和警示系統。

  • 請確定監視和警示系統在持續改善的範圍內。 生產環境中的應用程式和基礎結構行為提供持續學習機會。 將這些課程納入監視和警示設計。

  • 將您收集和分析的監視數據系結回 系統與使用者流程 ，以將流程的健康情況與工作負載的整體健康情況相互關聯。 根據流程分析該數據有助於將可觀察性策略與您的 健康情況模型保持一致。

您應該盡可能自動執行監視系統的所有功能，而且它們應該一直持續、每天執行。

此工作流程管線說明監視系統：

顯示完整監視系統作為管線階段的圖表。

集合

注意

您必須檢測您的應用程式，才能啟用記錄。 如需詳細資訊，請參閱 檢測指南。

您應該將所有工作負載元件設定為基礎結構資源或應用程式功能，以擷取遙測和/或記錄和計量等事件。

記錄主要用於偵測和調查異常。 一般而言，記錄是由工作負載元件產生，然後透過自動化傳送至監視平臺或由監視平臺提取。

計量主要用於 建置健康情況模型 ，並識別工作負載效能和可靠性的趨勢。 計量也可用於識別客戶使用行為的趨勢。 這些趨勢可協助從客戶的觀點引導有關改善的決策。 一般而言，計量是在監視平台中定義，而監視平臺和其他工具會輪詢工作負載以擷取計量。

應用程式資料

對於應用程式，收集服務可以是應用程式效能管理 (APM) 工具，可從產生檢測數據的應用程式自發執行。 啟用 APM 之後，您可以即時和歷史地清楚查看重要的計量。 使用適當的記錄層級。 詳細資訊記錄可能產生巨額成本。 根據環境設定記錄層級。 較低的環境不需要與生產環境相同的詳細資訊層級。例如。

「應用程式記錄檔」支援端對端應用程式生命週期。 記錄是瞭解應用程式在各種環境中運作方式、發生哪些事件，以及其發生狀況的必要條件。

我們建議您收集所有主要環境的應用程式記錄和事件。 如果這樣做很實用，請儘可能針對每個環境使用不同的數據存放區來分隔環境之間的數據。 使用篩選來確保非關鍵環境不會使生產記錄的解譯複雜。 最後，應用程式之間的對應記錄項目應該擷取其個別交易的相互關聯標識碼。

您應該使用計算機可讀取的數據點，而不是非結構化字串類型，擷取結構化數據類型中的應用程式事件。 使用已知架構的結構化格式，可讓您更輕鬆地剖析和分析記錄。 此外，結構化資料易於編製索引和搜尋，產生報告非常簡單。

數據的格式應該與計算機、操作系統或網路通訊協議無關。 例如，以 JSON、MessagePack 或 Protobuf 等自我描述格式發出資訊，而不是 ETL/ETW。 標準格式可讓系統建構處理管線。 以標準格式讀取、轉換和傳送數據的元件可以輕鬆地整合。

基礎結構資料

針對工作負載中的基礎結構資源，請確定您同時收集記錄和計量。 對於基礎結構即服務 (IaaS) 系統、擷取 OS、應用層和診斷記錄，以及與工作負載健康情況相關的計量。 對於平臺即服務 (PaaS) 資源，您可能會受限於擷取與基礎結構相關的記錄，但除了工作負載健康情況相關的計量之外，您也可以擷取診斷記錄。

盡可能從您的雲端平臺收集記錄。 您可以收集訂用帳戶的活動記錄，以及管理平面的診斷記錄。

收集策略

避免手動從每個元件擷取遙測資料。 將數據移至中央位置並加以合併。 針對多區域解決方案，建議您先依區域收集、合併及儲存數據，然後將區域數據匯總成單一中央系統。

取捨：請注意，具有區域和集中式數據存放區的成本含意。

為了使頻寬使用量最佳化，請根據資料的重要性排列優先順序。 您可以分批傳輸較不緊急的資料。 不過，此數據不得無限期延遲，特別是在包含時間敏感性資訊時。

收集服務可以使用兩個主要模型來收集檢測數據：

  • 提取模型：主動從應用程式的每個實例的各種記錄和其他來源擷取數據。

  • 推送模型：被動等候數據從構成應用程式每個實例的元件傳送。

監視代理程式

您可以在提取模型中使用監視代理程式。 代理程式會在每個應用程式實例的個別進程中執行，定期提取數據，並將資訊直接寫入應用程式的所有實例共用的通用記憶體。

此圖顯示監視代理程式用來提取資訊，並將其寫入共用記憶體。

注意

使用監視代理程式非常適合擷取從資料來源自然提取的檢測資料。 它適用於在單一位置的有限節點上執行的小型應用程式。 範例包括 SQL Server 動態管理檢視或 Azure 服務匯流排 佇列長度的資訊。

效能考量

複雜且高度可調整的應用程式可能會產生大量數據。 數據量可以輕鬆地讓單一中央位置的 I/O 頻寬負荷過大。 遙測解決方案不可成為瓶頸，必須可隨著系統擴充而調整。 在理想情況下，解決方案應該納入一個程度的備援，以降低遺失重要監視信息的風險 (，例如稽核或計費數據) 系統失敗時。

緩衝檢測數據的其中一種方式是使用佇列：

此圖顯示如何使用佇列來緩衝檢測數據。

在此架構中，資料收集服務將資料排入佇列。 訊息佇列適合，因為它提供「至少一次」語意，有助於確保張貼佇列數據之後不會遺失。 您可以使用個別的背景工作角色來實作記憶體寫入服務。 您可以使用 優先順序佇列模式 來實作此架構。

針對延展性，您可以執行記憶體寫入服務的多個實例。 如果正在監視大量的事件或大量的數據點，您可以使用 Azure 事件中樞 將數據分派至不同的計算實例來處理和儲存。

合併策略

從應用程式單一實例收集的數據會提供該實例健康情況和效能的當地語系化檢視。 若要評估系統的整體健康情況，您需要從本機檢視合併數據的某些層面。 您可以在儲存資料之後執行此動作，但在某些情況下，您可以在收集數據時執行此動作。

此圖顯示使用服務合併檢測數據的範例。

檢測資料可以通過另一個資料合併服務，此服務合併資料，並充當篩選和清除程序。 例如，您可以將包含相同相互關聯資訊的檢測數據合併，例如活動標識碼。 (使用者可能會在一個節點上啟動商務作業，然後在第一個節點失敗時傳輸至另一個節點，或因為設定負載平衡的方式。) 此程式也可以偵測並移除任何重複的數據。 如果遙測服務使用消息佇列將檢測數據推送至 storage.) ，可能會發生重複 (

儲存體

當您選擇記憶體解決方案時，請考慮數據類型、其使用方式，以及需要多久緊急。

注意

針對非生產環境與生產環境使用不同的記憶體解決方案，以確保來自每個環境的數據很容易識別和管理。

儲存體技術

請考慮Polyglot持續性方法，其中不同類型的資訊會儲存在最適合每個類型使用方式的技術中。

例如，以類似的方式存取 Azure Blob 儲存體 和 Azure 資料表記憶體。 但是，您可以對其執行的作業會有所不同，因為它們所保存的數據粒度也不同。 如果您需要執行更多的分析作業或需要資料上的全文檢索搜尋功能，可能更適合使用資料儲存體，因為它提供的功能已針對特定類型的查詢和資料存取最佳化。 例如：

  • 效能計數器資料可以儲存在 SQL Database 中，以啟用特定分析。

  • 最好將追蹤記錄儲存在 Azure 監視器記錄或 Azure Data Explorer。

  • 您可以將安全性資訊儲存在 HDFS 解決方案中。

基於多個用途，可能需要相同的檢測資料。 例如，您可以使用性能計數器來提供一段時間內系統效能的歷史檢視。 此資訊可能會與其他使用情況資料結合，來產生客戶帳單資訊。 在這些情況下，相同的數據可能會傳送至多個目的地，例如檔資料庫，該資料庫可以是長期存放區來保存帳單資訊，以及處理複雜效能分析的多維度存放區。

請務必啟用功能以保護資料免於意外刪除，例如資源鎖定和虛刪除。

此外，請務必使用角色型訪問控制來保護記憶體的存取，以確保只有需要存取數據的個人才能這麼做。

合併服務

您可以實作另一個服務，以定期從共用記憶體擷取數據、分割並根據其用途進行篩選，然後將它寫入適當的數據集。

此圖顯示數據分割服務，此服務會根據數據的類型將數據移至適當的數據存放區。

替代方法是在彙總及清除程序中包含此功能，並直接將資料寫入這些存放區，因為會擷取它，而不是將它儲存在中間共用的儲存體區域中。

每一種方法有其優點和缺點。 實作個別的數據分割服務可減少合併和清除服務上的負載，而且視共用記憶體) 保留多少數據而定，至少可重新產生部分分割 (的數據。 不過，此方法會耗用額外的資源。 此外，在從每個應用程式執行個體接收的檢測資料，以及將資料轉換成可採取動作的資訊之間，可能會出現延遲。

查詢考量

請考慮資料的急需程度。 如需快速存取產生警示資訊的資料，則資料應該保留在快速資料儲存體中，並編製索引或結構化，使警示系統執行的查詢最佳化。 在某些情況下，收集服務可能需要在本機格式化和儲存資料，讓警示系統的本機執行個體可以快速傳送通知。 相同的資料可以發送至先前圖表中顯示的儲存體寫入服務，而且如果基於其他用途而需要它，則集中儲存。

資料保留考量

在某些情況下，在處理和傳輸數據之後，您可以移除儲存在本機的原始源數據。 在其他情況下，儲存原始資訊可能有必要或有用。 例如，您可能想要保留產生的數據，以供原始格式使用偵錯，但在解決任何 Bug 之後快速捨棄。

效能數據通常具有較長的存留期，因此您可以使用它來找出效能趨勢和容量規劃。 此資料的合併檢視通常會在一段有限期間內，保留線上狀態以啟用快速存取。 在這段期間之後，即會將其封存或捨棄。

儲存歷程記錄資料非常有用，讓您能夠找出長期趨勢。 您可以減少數據的取樣，以降低其解析度並節省記憶體成本，而不是完全儲存舊數據。 例如，您可以合併超過一個月的數據，而不是儲存每分鐘效能指標，以形成每小時檢視。

針對計量和計費收集的資料，客戶可能需要無限期地儲存。 此外，法規需求可能會規定針對稽核和安全性收集的信息必須封存並儲存。 此資料也是機密資料，因此可能需要加密或保護以防止竄改。 您絕對不應該記錄用戶密碼或其他可能用來認可身分識別詐騙的資訊。 您應該先從數據清除這些詳細數據，再儲存數據。

為了確保您遵守法律和法規，請將任何可識別資訊的儲存降到最低。 如果您需要儲存可識別的資訊，請務必在設計解決方案時考慮允許個人要求刪除其資訊的需求。

分析

從各種數據源收集數據之後，請分析它以評估系統的整體健全狀況。 針對此分析，請清楚瞭解：

  • 如何根據您已定義的 KPI 和效能計量來建構數據。

  • 如何將不同計量和記錄檔中擷取的資料相互關聯。 當您追蹤一連串事件時，此相互關聯很重要，可協助您診斷問題。

在大部分情況下，架構的每個元件數據都會在本機擷取，然後精確地結合其他元件所產生的數據。

例如，三層式應用程式可能具有：

  • 可讓用戶連線至網站的呈現層。

  • 裝載一組可處理商業規則的微服務的中介層。

  • 儲存與作業相關聯之數據的資料庫層。

單一商務作業的使用方式數據可能會跨越這三層。 此資訊必須相互關聯，才能整體了解作業的資源和處理使用量。 相互關聯可能需要稍微預先處理和篩選資料庫層的資料。 在中介層上，匯總和格式化是常見的工作。

建議

  • 將應用層級和資源層級記錄相互關聯。 評估兩個層級的數據，以優化問題偵測和這些問題的疑難解答。 您可以在單一數據接收中匯總數據，或利用跨兩個層級查詢事件的方法。 我們建議整合的解決方案，例如 Azure Log Analytics，以匯總及查詢應用層級和資源層級的記錄。

  • 定義記憶體上的清除保留時間以進行冷分析。 我們建議此做法在特定期間內啟用歷史分析。 它也可協助您控制記憶體成本。 實作確保數據封存到較便宜的記憶體和匯總數據的程式，以進行長期趨勢分析。

  • 分析長期趨勢以預測作業問題。 評估長期數據以形成操作策略，並預測可能發生哪些作業問題，以及何時發生。 例如，您可能會注意到平均響應時間會隨著時間緩慢增加，並接近目標上限。

如需這些建議的詳細指引，請參閱 分析雲端應用程式的監視數據。

視覺效果

儀表板

將數據可視化最常見的方式是使用儀錶板，可將信息顯示為一系列圖表或圖形，或以其他視覺形式顯示資訊。 這些專案可以參數化，而分析師可以針對任何特定情況選取重要的參數，例如時間週期。

將您的儀錶板與您的 健康情況模型 對齊，使其指出工作負載的工作負載或元件狀況良好、降級或狀況不良。

若要讓儀錶板系統有效運作，對工作負載小組而言必須有意義。 可視化與工作負載健康情況相關的資訊，以及也可以採取動作的資訊。 當工作負載或元件降級或狀況不良時，工作負載小組的成員應該能夠輕鬆地識別問題的來源，並開始其更正動作或調查。 相反地，包括無法採取動作或與工作負載健康情況無關的資訊，可能會讓儀錶板變得不必要複雜，而且對嘗試辨識背景雜訊與可採取動作數據的小組成員感到困難。

您可能有項目關係人或開發人員的儀錶板，這些儀錶板會自定義為只顯示其找到相關工作負載的相關數據。 請確定工作負載小組瞭解其他小組想要查看和預覽儀錶板的數據點類型，然後再共用儀錶板以檢查是否清楚。 為項目關係人提供工作負載的相關儀錶板，是讓他們知道工作負載健康情況的好方法，但如果利害關係人未清楚了解他們看到的數據，就會有反生產的風險。

良好的儀錶板不只是顯示資訊。 它也可讓分析師提出該資訊的相關臨時問題。 某些系統會提供管理工具，操作員可以用來執行這些工作，並瀏覽基礎資料。 相反地，視用來保存資訊的存放庫而定，您可以直接查詢數據，或將數據匯入 Excel 之類的工具，以便進一步分析和報告。

注意

限制儀表板存取權給已授權的人員。 儀錶板的相關信息可能會有商業敏感性。 您也應該保護基礎數據，以防止用戶變更它。

報告

報告可用來產生系統的整體檢視。 它可能包含歷程記錄數據和目前的資訊。 報告的需求落在兩大類：作業報告和安全性報告。

工作報告通常包含下列各項：

  • 彙總統計資料，您可以用來了解整體系統或指定子系統在指定時間範圍內的資源使用率。

  • 識別整體系統或指定子系統在指定時段內資源使用狀況的趨勢。

  • 監視整個系統或指定子系統在指定時段內發生的例外狀況。

  • 判斷已部署資源的應用程式效率，以及了解資源量及其相關成本是否可以降低，而不會影響不必要的效能。

安全性報告會追蹤客戶使用系統。 其中包含︰

  • 稽核使用者作業。 此工作需要記錄每個使用者完成的個別要求，以及日期和時間。 數據應該經過結構化，讓系統管理員能夠快速重新建構使用者在指定期間內完成的作業順序。

  • 依使用者追蹤資源使用。 此工作需要記錄使用者每個要求如何存取組成系統的各種資源，以及多久時間。 系統管理員可以使用此數據來依用戶產生可能計費的指定期間使用量報告。

在許多情況下，批次程序可以根據定義的排程產生報告 延遲通常不是問題。 您也應該有批次程式，可以視需要定期產生報告。 例如，如果您將數據儲存在關係資料庫中，例如 Azure SQL Database，您可以使用 SQL Server Reporting Services 之類的工具來擷取和格式化數據，並將其呈現為一組報表。

警示

為了協助確保系統保持狀況良好、回應且安全，請設定警示，讓操作員可以及時回應警示。 警示可以包含足夠的內容資訊，以協助他們快速開始使用診斷活動。 警示可用來叫用補救功能，例如 自動調整或其他自我修復機制。 警示也可以藉由提供預算和限制的可見度來啟用成本感知。

建議

  • 定義警示回應的流程，以識別負責的擁有者和所需動作。

  • 為警示設定妥善的定義範圍 (資源類型和資源群組)，並調整詳細資訊以將雜訊降至最低。

  • 使用自動化警示解決方案，例如Splunk或 Azure 監視器，而不是要求人員主動尋找問題。

  • 使用警示將補救程序運作。 例如，自動建立票證來追蹤問題和解決方式。

  • 追蹤區域中雲端平台服務的健康情況、中斷的通訊、計劃性維護活動和其他健康情況諮詢。

臨界值

當您的監視系統偵測到閾值時，就會產生警示。 請確定您設定的閾值通常有足夠的時間來實作工作負載的必要變更，以避免降低或中斷。 例如，設定您的自動調整臨界值，在任何執行中的系統變得無法負荷到用戶體驗降低的點之前起始調整。 根據您過去管理基礎結構體驗指派的閾值，並透過您在測試實務中執行的測試加以驗證。

如需警示使用案例和其他考慮的詳細指引，請參閱 設計可靠的監視和警示策略。

Azure 指導

  • Azure 監視器 是一套完整的監視解決方案，可用來收集、分析及回應來自雲端和內部部署環境的監視數據。

  • Log Analytics 是 Azure 入口網站 工具，可用來編輯和執行 Log Analytics 工作區中的數據記錄查詢。

    如果您使用多個工作區，請參閱Log Analytics工作區 架構指南 以取得最佳做法。

  • Application Insights 是 Azure 監視器的延伸模組。 它提供 APM 功能。

  • Azure 監視器深入解析 是特定 Azure 技術的進階分析工具， (例如 VM、應用程式服務和容器) 。 這些工具是 Azure 監視器和 Log Analytics 的一部分。

  • 適用於 SAP 解決方案的 Azure 監視器 是 Azure 上執行的 SAP 環境 Azure 監視工具。

  • Azure 原則 可協助您強制執行組織標準，並大規模評估合規性。

營運卓越檢查清單

請參閱一組完整的建議。

營運卓越檢查清單