雲端監視中的可檢視性

  • 發行項

本文是雲端監視指南系列文章的一部分。

下列各節旨在藉由觀察並不斷反覆運算來推動作業成熟度，以改善您監視服務的方式。 了解組織如何藉由建立 每個監視解決方案的可檢視性 ，更快速地實作一致的監視策略。

定義可觀察性

雖然可觀察性和監視彼此互補，但有顯著的區別：

  • 監視：收集資訊並通知您，它會根據您設定問題來監視這些條件而偵測到的問題。 您正在監視已知或可預測的失敗。
  • 可檢視性：藉由查看輸出數據，了解系統中發生的情況。 可檢視性解決方案可協助您分析此數據，以評估系統的健康情況，並找出修正IT基礎結構中問題的方法。

可檢視性會先推動監視取用者了解什麼是服務的 正常 作業。 換句話說，您會儘快搜尋 完全可見度 。

一旦您達到初始可觀察性，即可建立該初始可見度層級，以開發可採取動作的警示、建立實用的儀錶板，以及評估 AIOps 解決方案。 這些深入解析可讓您熟悉基礎計量和記錄監視數據。

注意

這與過去當小組在建置、測試和部署之前先在紙張上定義所有監視需求時所使用的方法相反。

無論您的監視計劃是以應用程式、雲端基礎結構或 Azure 平台為目標，第一個步驟是 建立可檢視性。

此方法也會簡化您的計劃。 在所有情況下，總可見度表示在三個維度或層面達成並維持足夠的可見度：

  1. 深入監視：收集有意義的相關訊號。
  2. 監視端對端或廣度：從堆疊的最低層到應用程式。
  3. 監視整個健康情況模型：專注於健康情況層面，例如可用性、效能、安全性和持續性。

Three-sided cube example

可觀察性不僅僅是 IT 小組的焦點。 基本目標是確保終端使用者可以使用系統，並符合您的 服務等級目標 （SLO）。

監視解決方案和可檢視性

基礎結構和應用程式監視可能很複雜。 業務轉型應用技術來達成並協助塑造其策略。 雲端進一步影響了監視的複雜本質。

這會以下列方式示範：

  • 數字轉型轉變：企業的數字轉型工作轉向雲端技術的超開發。
  • 內建監視：監視會內嵌在 Azure 資源和資源群組中，而不是您管理內部部署的不同工具。
  • 廣泛的監視 雲端原生架構，例如 Azure 監視器，類似於安全性事件和事件管理 （SIEM） 工具。 Azure 監視器具有比傳統內部部署工具更具彈性、記錄驅動和數量級順序的廣泛性。

架構設計人員必須像操作員一樣瞭解基礎結構元件或應用程式發出的診斷資訊。

將多重變數、動態、時間序列、事件性、具狀態和遙測記錄數據流結合成有價值的智慧，取決於下列各項：

  • 小組知識：深入瞭解監視目標的開發人員或系統工程師的知識和經驗。
  • 疑難解答體驗：使用數據尋找或找出問題原因的支援和疑難解答體驗。
  • 從歷程記錄中學習：檢閱過去的事件，以找出稍後可自動補救的非技術原因。
  • 檔：軟體、軟體、訓練或軟體或硬體廠商諮詢檔中的指引。

Microsoft 及其合作夥伴提供 System Center Operations Manager 的管理元件。 管理元件是技術特定的;例如，如果您匯入 SQL 管理元件，Operations Manager 會自動探索並鎖定裝載 SQL Server 的伺服器，並開始監視它們。 在這裡， 可觀察性是預先定義的或多或少。 Operations Manager 主要是針對內部部署基礎結構所設計，這些基礎結構通常會固定在相對於雲端服務的元件和架構設計模式中。

在雲端中，您可以彈性地選擇服務類型。 監視包括服務隨著時間變化的方式，而且可以是動態、全域和復原性。 透過 Azure 監視器，您可以利用 Azure 監視器深入解析中包含的現有活頁簿，提供與 Operations Manager 中管理元件類似的功能。

觀察的藝術

可檢視性依賴監視的專案和方式。

在 Azure 中，有多個監視數據源，每個數據源都提供不同的觀點來瞭解某些行為的方式。 Azure 包含許多工具來協助分析此數據的各個層面。

觀察平臺

在 Azure 中，Microsoft 透過不同的平台記錄提供服務提供者的觀點。

Azure 中的服務可能會隨著時間以不同且無法預測的方式變更。 我們將此行為稱為動態行為。 一段時間觀察服務的雲端服務管理員也需要考慮下列事項：

  • 資源重新配置：資源可以跨位置或地理位置移轉或移動。
  • 資源變更：新增、刪除或修改資源。
  • 取用：不同服務和實作的耗用量會有所不同。 請留意監視成本、耗用量和預計支出。

以下是一些可讓平臺可觀察性的工具範例：

記錄來源 描述
服務健全狀況 Microsoft 回報的服務事件和計劃性維護。
Azure 資源健康狀態 報告您資源的目前和過去健康情況。
Azure 監視器活動記錄 報告訂用帳戶中部署之所有資源的訂用帳戶層級事件。
Azure 監視器變更分析 報告 Azure 應用程式的變更，並減少修復的平均時間（MTTR）。
Azure 資源記錄 先前稱為 診斷記錄，資源記錄會報告數據平面上 Azure 資源內執行的作業。
Microsoft Entra 報告 （AzureAD） 記錄 報告登入活動的歷程記錄，以及指定租使用者 Microsoft Entra 標識符中變更的稽核記錄。
Azure Advisor 使用 Azure Advisor 根據最佳做法接收建議的解決方案，以優化您的 Azure 部署。
Microsoft Cloud for Sovereignty 透明度記錄 報告何時存取資源，以及哪些 Microsoft 工程師存取資源。 透明度記錄提供客戶資源存取的詳細數據。 記錄也會在沒有存取權時通知您，這是常見的。

可觀察性逐漸發展，從最低限度可行的監視計劃開始，以及整合工具和程式的努力正在進行中。 當您熟悉數據（計量、記錄和交易），您可以從這些資源或應用程式瞭解徵兆的行為和徵兆。 藉由熟悉數據，您可以建立使用 Azure 監視器和數據的信任。

從可觀察性獲得信心

有了適當的可觀察性，您就能獲得信心，而且能夠實現原因並找到可協助的答案。 您越了解數據，您的流程愈演進，小組就會取得深入解析。

若要設定場景，以下是一些從可觀察性中獲得信心的方法：

  • 提高可預測性：改善資源與服務的監視可協助主動識別問題，使其未來可預測且可管理。

  • 早期偵測異常：可觀察性可讓您及時偵測異常或偏離預期行為，以減少潛在問題的影響。

  • 根本原因識別：詳細的可檢視性數據可協助識別問題的根本原因，進而加快解決速度並防止週期性。

  • 增強疑難解答效率：透過可觀察性，小組可以藉由分析相關數據並相互關聯事件，快速診斷和疑難解答複雜的問題。

  • 改善系統可靠性：藉由識別瓶頸、效能問題和潛在失敗點，可觀察性有助於將系統效能優化並增強整體可靠性。

  • 改善客戶體驗：可檢視性可讓您進一步了解系統效能如何影響使用者，讓主動措施提升客戶滿意度。

  • 促進共同作業：可檢視性平臺提供共用可見性和數據存取，促進不同小組之間的合作，例如開發人員、作業和支援。

  • 法規合規性：可檢視性可協助滿足法規需求，方法是提供可追蹤性、稽核記錄，並確保遵守安全性和隱私權標準。

  • 更快解決時間：藉由提供豐富的數據和深入解析，可觀察性可加速診斷和解決問題的時間，將停機時間和服務中斷降到最低。

  • 主動式容量管理：可檢視性數據可協助預測資源需求、識別容量差距，以及主動調整資源以維持最佳效能。

  • 風險降低：透過可觀察性，您可以儘早識別潛在風險，啟用主動式風險降低措施，並減少嚴重影響的可能性。

  • 持續監視和學習：可檢視性允許持續監視和學習，協助小組適應不斷變化的環境、需求和用戶行為。

  • 效能優化：藉由分析可觀察性數據，小組可以識別並優化效能瓶頸，提高系統效率。

  • 工作優先順序：可檢視性深入解析可讓小組根據所識別問題的嚴重性和影響來排定工作優先順序並配置資源。

  • 變更管理的信心：可檢視性可讓您了解變更的影響，確保新的部署或更新不會造成未預期的問題。

  • 改善事件回應：透過可觀察性，事件回應小組可以快速收集相關信息、了解內容，以及起始適當的動作。

監視計畫

您可以建立監視計劃來描述目標和目標、需求和其他基本詳細數據。 然後，努力在組織中所有相關項目關係人之間徵求合約。

監視計畫應該說明如何開發和操作一或多個監視解決方案。 在專案的策略和規劃階段早期開始建立監視計劃。

建立計劃時，請務必記住新式監視的五個專業領域，如雲端監視策略檔中所述：監視、測量、回應、學習和改進。

下列提供監視計劃的初始建議大綱，並視為個別服務方案的主要考慮，或將 Azure 資源類型或 Microsoft 365 服務等雲端服務功能標準化時。

計劃的本質是定義服務提供者（誰將現場解決方案）和消費者（誰將操作或衍生價值）之間的可見度線。

商務觀點

完整的監視計劃必須考慮商務需求與監視之間的需求，包括以使用者為中心的焦點。 在定義方案時，必須記錄並共用商務需求，下列 建議方案這部分的範圍 。

  • 項目關係人和取用者
  • 商務價值串流和程式
  • 用戶檢視方塊和公用程式
  • 測量和報告需求
  • 識別的風險和合規性控制架構
  • 訪問控制需求
  • 企業風險

服務檢視方塊

全面的監視計劃必須考慮服務擁有者在監視時所需的專案。 在定義計劃時，必須記錄並分享其需求，下列 建議計劃的這部分範圍 。

  • 項目關係人和取用者
  • 角色和責任
  • 服務的定義
  • 訪問控制需求
  • 架構考慮？
  • 供應商和合作夥伴基礎合約
  • 服務合約（SLA、OLA）
  • 識別服務保固涵蓋範圍
  • 測量和報告需求
  • 風險

技術觀點

此計劃的這一節代表使用商務與服務觀點的資訊來監視解決方案。 下列 建議計劃的這個部分範圍 。

  • 用戶劇本和案例
  • 技術目標（例如網路功能）
  • 元件相依性對應
  • 類型（例如雲端原生、混合式、內部部署）
  • 觀測
  • 回應性
  • 測量
  • 微調和優化

考量

摘要說明計劃，以確保其能傳達並通知所有相關取用者、項目關係人和管理層級。 針對成功的監視計劃，請考慮下列幾點：

主要考量

  • 生產階段： 監視解決方案應在服務上線時準備就緒。 規劃可以在另一個專用的訂用帳戶中包含測試或生產前設定，以協助實驗和測試您的假設。

  • 策略： 計劃也可以對應回監視和IT策略，以追蹤監視目標至任務或業務。

  • 目標： 在方案中，描述和分析考慮的目標資產或服務。 如有需要，請對應所有要監視的元件，包括服務相依性。 識別涵蓋範圍差距，並判斷誰擁有服務的每個部分。

  • 解決方案： 針對監視解決方案，識別取用者、項目關係人、供應商、合作夥伴、存取和檢測。 此外，監視層面、範圍、回應、報告和儀錶板（可用性、安全性、用戶體驗等等）。

一般考量

除了重要考慮之外，還尋求進一步了解這些點如何影響貴組織的監視計劃。

  • 最低可行產品 （MVP）： 讓方案定義最低可行產品的成功外觀。 換句話說，最初需要什麼才能上線，我們可以衡量這一點的成功嗎？ 上線之後，您可以繼續發展監視解決方案，以將價值最大化。

  • 保護您的監視數據： 安全性是現今每個組織和小組的重要層面。 請確定您已接受教育並瞭解護欄，或讓專家引導您，讓您不會將風險新增至監視解決方案，例如，藉由在記錄中公開機密監視數據。

  • 請考慮 Microsoft 365： 任何良好的方案都會將您的 Azure 租使用者與 Microsoft 365 視為重要元件。 Microsoft 365 相依於 Microsoft Entra ID，而 Azure 監視器提供 Microsoft 365 與端點管理的整合。

  • 可檢視性獲勝： 專注於警示之前的總可見度，因為警示都是成本，而且可以快速導致警示疲勞。

  • 活動監視： 稽核、登入和活動記錄現在很容易讓服務擁有者和安全性進行配量和切入。 請確定您的監視計劃考慮活動監視，包括您需要為任何相關項目關係人建立的深入解析和儀錶板。

下一步

服務等級目標