設計和建立監視系統的建議
適用於此 Azure 架構完善的架構營運卓越檢查清單建議：
| OE：07 | 設計和實作監視系統，以驗證設計選擇，並通知未來的設計和商務決策。 此系統會擷取並公開從工作負載基礎結構和程式代碼發出的作業遙測、計量和記錄。 |
|---|
相關指南： 檢測應用程序的建議
本指南說明設計和建立監視系統的建議。 若要有效地監視工作負載的安全性、效能和可靠性，您需要一個完整的系統及其本身的堆疊，以提供所有監視、偵測和警示功能的基礎。
定義
| 詞彙 | 定義 |
|---|---|
| 記錄 | 記錄的系統事件。 記錄可以包含結構化或自由格式文字格式的不同數據類型。 它們包含時間戳。 |
| 計量 | 定期收集的數值。 計量會描述系統在特定時間的某些層面。 |
關鍵設計策略
若要為您的工作負載實作完整的監視系統設計，請遵循下列核心原則：
只要可行，請利用平臺提供的監視工具，這通常需要很少的組態，而且可以提供您工作負載的深入解析，否則可能難以完成。
從整個工作負載堆疊收集記錄和計量。 所有基礎結構資源和應用程式函式都應該設定為產生標準化、有意義的數據，以及需要收集數據。
將收集的數據儲存在標準化、可靠且安全的記憶體解決方案中。
處理預存數據，以便透過分析和視覺效果解決方案來處理。
分析已處理的數據，以正確判斷工作負載的狀態。
針對工作負載小組和其他項目關係人，以有意義的儀錶板或報表，將工作負載的狀態可視化。
設定可採取動作的警示和其他自動回應，以智慧定義閾值，以在發生問題時通知工作負載小組。
在您的整體工作負載測試實務中包含監視和警示系統。
請確定監視和警示系統在持續改善的範圍內。 生產環境中的應用程式和基礎結構行為提供持續學習機會。 將這些課程納入監視和警示設計。
將您收集和分析的監視數據系結回 系統與使用者流程 ，以將流程的健康情況與工作負載的整體健康情況相互關聯。 分析流程中的數據，將有助於將您的可檢視性策略與您的 健康情況模型保持一致。
您應該盡可能自動執行監視系統的所有功能，而且它們應該每天都會持續執行。
此工作流程管線說明監視系統：
收集檢測數據
注意
您必須檢測應用程式以啟用記錄。 如需詳細資訊，請參閱 檢測指南。
您應該設定所有工作負載元件，無論是基礎結構資源或應用程式函式，以擷取記錄和計量之類的遙測和/或事件。
記錄主要用於偵測和調查異常。 一般而言，記錄是由工作負載元件產生，然後透過自動化傳送至監視平臺或由監視平臺提取。
計量主要用於 建置健康情況模型 ，並識別工作負載效能和可靠性的趨勢。 計量也有助於識別客戶使用行為的趨勢。 這些趨勢可協助從客戶的觀點引導有關改進的決策。 一般而言，計量是在監視平台中定義，而監視平臺和其他工具會輪詢工作負載以擷取計量。
應用程式資料
針對應用程式，收集服務可以是應用程式效能管理 （APM） 工具，可從產生檢測數據的應用程式自主執行。 啟用 APM 之後，您可以即時和歷程記錄地清楚瞭解重要的計量。 使用適當的記錄層級。 詳細信息記錄可能會產生大量成本。 根據環境設定記錄層級。 例如，較低的環境不需要與生產環境相同的詳細資訊層級。
應用程式記錄支援端對端應用程式生命週期。 記錄對於瞭解應用程式在各種環境中的運作方式、發生的事件，以及它們發生的情況至關重要。
建議您在所有主要環境中收集應用程式記錄和事件。 如果這樣做很實用，請盡可能使用每個環境的不同數據存放區來分隔環境之間的數據。 使用篩選來確保非關鍵環境不會使生產記錄的解譯複雜化。 最後，應用程式之間的對應記錄項目應該擷取其個別交易的相互關聯標識碼。
您應該使用電腦可讀取的資料點以結構化資料類型來擷取應用程式事件，而不是非結構化字串類型。 使用已知結構描述的結構化格式可讓剖析和分析記錄變得更容易。 此外，可以輕鬆地對結構化資料進行索引編制和搜尋，而且報表可以大幅簡化。
數據的格式應該與計算機、操作系統或網路通訊協議無關。 例如，以 JSON、MessagePack 或 Protobuf 等自我描述格式發出資訊，而不是 ETL/ETW。 標準格式可讓系統建構處理管線。 以標準格式讀取、轉換和傳送數據的元件可以輕鬆地整合。
基礎結構數據
針對工作負載中的基礎結構資源，請確定您同時收集記錄和計量。 針對基礎結構即服務 （IaaS） 系統，除了與工作負載健康情況相關的計量之外，還擷取 OS、應用層和診斷記錄。 針對平臺即服務 （PaaS） 資源，您可能會受限於擷取與基礎結構相關的記錄，但除了與工作負載健康情況相關的計量之外，您還可以確定您可以擷取診斷記錄。
盡可能從您的雲端平台收集記錄。 您可以收集訂用帳戶的活動記錄，以及管理平面的診斷記錄。
收集策略
避免從每個元件手動擷取遙測數據。 將數據移至中央位置，並將其合併到該處。 針對多區域解決方案，建議您先依區域收集、合併及儲存數據，然後將區域數據匯總成單一中央系統。
取捨：請注意，具有區域和集中式數據存放區的成本影響。
若要優化頻寬的使用，請根據數據的重要性來設定優先順序。 您可以分批傳輸較不緊急的數據。 不過，此數據不得無限期延遲，特別是包含時間敏感性資訊時。
收集服務可以使用兩個主要模型來收集檢測數據：
提取模型：主動從應用程式每個實例的各種記錄和其他來源擷取數據。
推送模型：被動地等候從構成應用程式每個實例的元件傳送數據。
監視代理程式
您可以在提取模型中使用監視代理程式。 代理程式會在個別進程中與應用程式的每個實例一起在本機執行，定期提取數據，並將資訊直接寫入應用程式的所有實例所共用的通用記憶體。
注意
使用監視代理程式很適合擷取自然從數據源提取的檢測數據。 適合在單一位置的有限節點上執行的小規模應用程式。 範例包括來自 SQL Server 動態管理檢視或 Azure 服務匯流排 佇列長度的資訊。
效能考量
複雜且高度可調整的應用程式可能會產生大量數據。 數據量很容易壓倒單一中央位置可用的 I/O 頻寬。 遙測解決方案不得作為瓶頸，而且必須隨著系統擴充而調整。 在理想情況下，如果系統的一部分失敗，解決方案應納入一定程度的備援，以減少失去重要監視資訊（例如稽核或計費數據）的風險。
緩衝檢測數據的其中一種方式是使用佇列：
在此架構中，數據收集服務會將數據張貼至佇列。 消息佇列適合使用，因為它提供「至少一次」語意，有助於確保佇列數據在張貼後不會遺失。 您可以使用個別的背景工作角色來實作記憶體寫入服務。 您可以使用 優先順序佇列模式 來實作此架構。
針對延展性，您可以執行記憶體寫入服務的多個實例。 如果正在監視大量的事件或大量的數據點，您可以使用 Azure 事件中樞 將數據分派至不同的計算實例進行處理和儲存。
匯總策略
從應用程式單一實例收集的數據會提供該實例健康情況和效能的當地語系化檢視。 若要評估系統的整體健康情況，您需要從本機檢視合併數據的某些層面。 您可以在儲存資料之後執行此動作，但在某些情況下，您可以在收集數據時執行此動作。
檢測數據可以傳遞個別的數據匯總服務，以結合數據並做為篩選和清除程式。 例如，您可以合併包含相同相互關聯資訊的檢測數據，例如活動識別碼。 （使用者可能會在一個節點上啟動商務作業，然後在第一個節點失敗時，或因為設定負載平衡的方式而轉移到另一個節點。此程式也可以偵測並移除任何重複的數據。 （如果遙測服務使用消息佇列將檢測數據推送至記憶體，就可能發生重複的情況。
儲存用於查詢和分析的數據
當您選擇記憶體解決方案時，請考慮數據類型、其使用方式，以及其必要程度。
注意
針對非生產環境與生產環境使用不同的記憶體解決方案，以確保來自每個環境的數據很容易識別和管理。
儲存體技術
請考慮Polyglot持續性方法，其中不同類型的資訊會儲存在最適合每種類型使用方式的技術中。
例如，Azure Blob 儲存體 和 Azure 資料表記憶體會以類似的方式存取。 但是，您可以對其執行的作業會有所不同，因為它們保存的數據粒度也不同。 如果您需要對數據執行更多分析作業或需要全文搜索功能，可能更適合使用針對特定查詢和數據存取類型優化的功能的數據記憶體。 例如：
性能計數器數據可以儲存在 SQL 資料庫中，以啟用臨機操作分析。
最好將追蹤記錄儲存在 Azure 監視器記錄或 Azure 數據總管中。
您可以將安全性資訊儲存在 HDFS 解決方案中。
針對多個用途，可能需要相同的檢測數據。 例如，您可以使用性能計數器來提供一段時間的系統效能歷程記錄檢視。 此資訊可能會與其他使用量數據結合，以產生客戶帳單資訊。 在這些情況下，相同的數據可能會傳送到多個目的地，例如檔資料庫，該資料庫可以是長期存放區來保存帳單資訊，以及處理複雜效能分析的多維度存放區。
請務必啟用功能來保護資料免於意外刪除，例如資源鎖定和虛刪除。
此外，請務必使用角色型訪問控制來保護記憶體的存取權，以確保只有需要存取數據的人員才能這麼做。
合併服務
您可以實作另一個服務，定期從共用記憶體、分割區中擷取數據，並根據其用途加以篩選，然後將它寫入適當的數據集。
另一種方法是將這項功能包含在合併和清除程式中，並將數據直接寫入這些存放區，因為擷取數據，而不是將它儲存在中繼共用儲存區域中。
每個方法都有其優點和缺點。 實作個別的數據分割服務可減少合併和清除服務的負載，並在必要時至少重新產生部分分割數據（視共用記憶體中保留的數據量而定）。 不過，此方法會耗用額外的資源。 此外，從每個應用程式實例接收檢測數據，以及將此數據轉換成可操作的信息之間，可能會有延遲。
查詢考慮
請考慮需要數據有多緊急。 產生警示的數據必須快速存取，因此應該保留在快速數據記憶體中，並編製索引或結構化，以優化警示系統執行的查詢。 在某些情況下，收集服務可能需要在本機格式化和儲存數據，讓警示系統的本機實例可以快速傳送通知。 相同的數據可以分派至先前圖表中顯示的記憶體寫入服務，並在其他用途也需要時集中儲存。
數據保留考慮
在某些情況下，在處理和傳輸數據之後，您可以移除儲存在本機的原始源數據。 在其他情況下，儲存原始資訊可能是必要的或有用的。 例如，您可能會想要保留產生的數據，以便以原始形式進行偵錯，但在解決任何 Bug 之後迅速捨棄它。
效能數據通常具有較長的壽命，因此您可以使用它來找出效能趨勢和容量規劃。 此數據的合併檢視通常會在有限時間內保持在線，以便快速存取。 之後，即可進行封存或捨棄。
儲存歷程記錄數據很有用，因此您可以找出長期趨勢。 您不需完全儲存舊數據，而是能夠向下取樣數據，以減少其解析度並節省記憶體成本。 例如，您可以合併一個多月的數據，而不是逐分鐘儲存效能指標，以形成每小時檢視。
針對計量和計費客戶收集的數據可能需要無限期儲存。 此外，法規需求可能會規定收集用於稽核和安全性的信息必須封存並儲存。 此數據也是機密數據，可能需要加密或受到保護，以防止竄改。 您不應該記錄用戶密碼或其他可能用來認可身分識別詐騙的資訊。 您應該先從數據中清除這些詳細數據，再儲存數據。
為了確保您遵守法律和法規，請將任何可識別資訊的儲存降到最低。 如果您需要儲存可識別的資訊，請務必在設計解決方案時考慮允許個人要求刪除其資訊的需求。
分析數據以瞭解工作負載的健康情況
從各種數據源收集數據之後，請分析數據以評估系統的整體福祉。 針對此分析，請清楚瞭解：
如何根據您已定義的 KPI 和效能計量來建構數據。
如何使在不同計量和記錄檔中擷取的數據相互關聯。 當您追蹤一連串事件時，此相互關聯很重要，可協助您診斷問題。
在大部分情況下，架構每個元件的數據都會在本機擷取，然後準確地結合其他元件所產生的數據。
例如，三層式應用程式可能有：
可讓用戶連線到網站的表示層。
一個仲介層，裝載一組可處理商業規則的微服務。
儲存與作業相關聯之數據的資料庫層。
單一商務作業的使用方式數據可能會跨越這三個層級。 此資訊必須相互關聯，才能提供作業資源的整體檢視和處理使用量。 相互關聯可能牽涉到資料庫層上數據的一些前置處理和篩選。 在中介層上，匯總和格式化是常見的工作。
建議
將應用層級和資源層級記錄相互關聯。 評估兩個層級的數據，以優化問題偵測和這些問題的疑難解答。 您可以在單一數據接收中匯總數據，或利用跨兩個層級查詢事件的方法。 我們建議整合的解決方案，例如 Azure Log Analytics，以匯總及查詢應用層級和資源層級的記錄。
定義記憶體上的清除保留時間以進行冷分析。 我們建議這種做法在特定期間啟用歷史分析。 它也可以協助您控制記憶體成本。 實作程式，以確保數據會封存到更便宜的記憶體和匯總數據，以進行長期趨勢分析。
分析長期趨勢以預測作業問題。 評估長期數據以形成作業策略，並預測可能發生哪些作業問題，以及何時發生。 例如，您可能會注意到平均響應時間會隨著時間緩慢增加，並接近目標上限。
如需這些建議的詳細指引，請參閱 分析雲端應用程式的監視數據。
將工作負載健康情況報告可視化
儀表板
將數據可視化的最常見方式是使用儀錶板，可將信息顯示為一系列圖表或圖形，或以其他視覺形式顯示資訊。 這些專案可以參數化，分析師可以針對任何特定情況選取重要的參數，例如時間週期。
將您的儀錶板與您的 健康情況模型 對齊，使其指出工作負載的工作負載或元件狀況良好、降級或狀況不良。
若要讓儀錶板系統有效運作，它必須對工作負載小組有意義。 將與工作負載健康情況相關的資訊可視化，也可以採取動作。 當工作負載或元件降級或狀況不良時，工作負載小組的成員應該能夠輕鬆地識別問題的來源位置，並開始其更正動作或調查。 相反地，包括無法採取動作或與工作負載健康情況無關的資訊，可能會讓儀錶板不必要地複雜且令人沮喪地讓嘗試辨別可採取動作數據的背景雜訊的小組成員。
您可能擁有項目關係人或開發人員的儀錶板，這些儀錶板僅顯示其找到相關工作負載的相關數據。 請確定工作負載小組瞭解其他小組想要查看及預覽儀錶板的數據點類型，然後再共用儀錶板，以檢查清楚明瞭。 為項目關係人提供工作負載的相關儀錶板，是讓他們瞭解工作負載健康情況的好方法，但如果專案關係人無法清楚地了解他們看到的數據，就會有適得其反的風險。
良好的儀錶板不只是顯示資訊。 它還可讓分析師對這些資訊提出即興的問題。 某些系統提供管理工具，操作員可用來完成這些工作並探索基礎數據。 相反地，視用來保存資訊的存放庫而定，可能會直接查詢數據，或將其匯入 Excel 之類的工具，以便進一步分析和報告。
注意
限制儀表板存取權給已授權的人員。 儀錶板上的資訊在商業上可能十分敏感。 您也應該保護基礎數據，以防止用戶變更它。
報表
報告可用來產生系統的整體檢視。 它可能包含歷程記錄數據和目前資訊。 報告需求分為兩大類：作業報告和安全性報告。
工作報告通常包含下列各項：
匯總統計數據，讓您在指定的時間範圍中了解整體系統或指定子系統的資源使用率。
識別指定期間內整體系統或指定子系統的資源使用量趨勢。
監視在指定期間內在整個系統或指定子系統中發生的例外狀況。
判斷已部署資源之應用程式的效率，以及瞭解資源數量及其相關成本是否可以降低，而不會不必要地影響效能。
安全性報告會追蹤客戶使用系統。 它可以包括：
稽核用戶作業。 此工作需要記錄每個使用者完成的個別要求，以及日期和時間。 數據應該結構化，讓系統管理員能夠快速重新建構使用者在指定期間內完成的作業順序。
追蹤使用者使用的資源。 此工作需要記錄使用者每個要求如何存取組成系統的各種資源，以及時間長度。 系統管理員可以使用此數據，依用戶產生可能計費的指定期間使用率報告。
在許多情況下，批處理可以根據定義的排程產生報告。 延遲通常不是問題。 您也應該有批次程式，可以視需要自發產生報告。 例如，如果您將數據儲存在 Azure SQL 資料庫 之類的關係資料庫中，您可以使用 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 監視器基準警示 （AMBA） 是警示定義的中央存放庫， 客戶和合作夥伴可透過採用 Azure 監視器來改善其可檢視性體驗。
卓越營運檢查清單
請參閱一組完整的建議。