雲端監視指南:可檢視性

本文旨在協助組織透過確保 可檢視性 是在 Azure 登陸區域中建立的,以協助組織更快速地執行一致的監視策略, (也就是每個監視解決方案的最小可行產品) 。

作為規劃工具,您可以為服務制訂監視計畫,並包含一些監視目標。 您所想要的一個目標,就是讓監視取用者 (的) 能夠儘快使用您所規劃的解決方案,達到更自信或自信的程度。 然後,您可以繼續進行其他目標,例如建立報表和自訂儀表板。

我們稱之為 採用

本文的目標是要採取 監視策略 建議,並建立監視計畫,以支援現代化和發展組織 IT 營運策略的目標。 第二個目標是要藉由敏銳並不斷地逐一查看來改善您監視這些服務的方式,來推動營運成熟度。

注意

在本文中, 監視解決方案 是在雲端中監視服務的實際執行單位,而 監視目標 是受監視的服務。 解決方案包含監視的所有層面:工具、監視資料、警示、回應類型、修復動作、視覺效果類型、角色型存取等等。

為何可檢視性很重要

簡單地說,它的可檢視性會 驅動監視取用者,以瞭解服務的 正常 運作所需的視為或認知。 換句話說,您可以儘快搜尋 總可見度(主要監視準則)。 完成初始可檢視性之後,您就可以建立可採取動作的警示、建立有用的儀表板,以及評估 AIOps 解決方案,以初始的可見度層級為基礎。 這讓您有時間熟悉基礎度量和記錄監視資料。

注意

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

無論方案 (是,目標) 都會以 Azure 資源類型(例如 Key Vault、整個資源群組,甚至 Microsoft 365 Exchange Online)為目標,因此第一個步驟是 建立可檢視性

這種方法也簡化了您的計畫。 在所有情況下,整體可見度表示在三個維度或各方面有足夠的可見度:

  • 深入監視
  • 廣泛監視
  • 跨健康狀態模型監視

三側 cube 範例

敏銳不只是 IT 焦點,請記住,目標是要確保使用者可以取用並符合商務期望。 您無法監視不了解或知道的內容,因此您將無法提供承諾給商務的服務可用性層級。 在雲端運算的問世之前,Microsoft 強調了在應用程式設計和開發期間的失敗模式分析。 失敗模式分析協助開發人員在程式碼中,考慮邏輯或其他重大錯誤的發生方式和時機。 當它執行時,會以有意義的方式公開條件,讓監視工具不只會偵測到它並對其採取動作,同時為開發人員、操作員或系統工程師提供有用的資訊,以協助進一步瞭解應用程式的行為,並做出資料驅動的決策。 目前,「 雲端採用架構 」會建議您遵循此程式,作為架構和設計階段的一部分,以在您的設計中建立 Azure 服務的復原。

這就是您想要的可檢視性,以及您的最小可行產品。

監視系統和可檢視性

基礎結構和應用程式監視很複雜,即使是在引進雲端運算的情況下,它一律會保持不變。 企業轉型會套用技術,以達成最新和協助圖形,也就是未來的策略。 雲端對監視的複雜本質有進一步的影響。

這會以下列方式示範:

  • 企業 (數位) 轉換工作轉移至雲端技術的超惡意探索。

  • 監視會變成內嵌在 Azure 資源和資源群組中,與您在內部部署中管理的個別工具不同。

  • 雲端原生監視架構是類似 SIEM 的,例如 Azure 監視器。 因此它的範圍廣泛、記錄驅動,以及量級的順序更有彈性。

針對架構設計人員,診斷形成了利用更符合成本效益的雲端原生監視結構的核心,可讓 IT 管理跨不同雲端模型的服務全面性地型。

架構設計人員必須像操作員一樣瞭解 IT 基礎結構元件或應用程式所發出的診斷資訊。 將多變數、dynamical、時間序列、eventful、具狀態和遙測記錄資料流程合併為有價值的情報,取決於下列各項:

  • 開發人員或系統工程師的知識和經驗,深入瞭解監視目標。

  • 使用資料的實際支援和疑難排解體驗,以找出問題或找出問題的原因。

  • 查看過去的事件以找出非技術的原因,之後可以自動 (自動補救) 。

  • 軟體或硬體廠商提供的檔、軟體、訓練或諮詢的指引。

如果您熟悉 System Center Operations Manager,Microsoft 及其合作夥伴會提供 管理元件。 管理元件為技術特定;例如,您匯入 SQL 管理元件 Operations Manager 會自動探索並以裝載 SQL Server 的伺服器為目標,然後開始進行監視。 在此,可檢視性是由 Microsoft 及數十個產業的產品工程師預先定義。 有了 Operations Manager,您就不需要擔心北和東西部的相依性,因此觀察 SQL 的健康狀態是包含網路功能、虛擬化和應用程式之大型 IT 服務的一部分。 根據熟悉的四部分 健康情況模型 原因至一般架構,Operations Manager 是專為內部部署基礎結構所設計。 相較于雲端服務,基礎結構服務架構通常會在元件和架構模式中 修正

在雲端中,您可以選擇的服務類型有很大的彈性。 監視包含它們隨著時間的變更,而且可以是動態、全域和彈性。 作為雲端架構設計人員,您不受限於固定的內部部署思考。 Operations Manager 可以參與,但同樣地,其強度是傳統的內部部署基礎結構和應用程式。 相較之下,Azure 監視器的架構在支援所有三種雲端模型方面更有彈性。 若要在 Azure 監視器達到您的可檢視性目標,您可以更自由地決定資源、將它們放在不同的位置,以及如何將元件視覺化。

使用 Azure 監視器,您可以利用 深入解析中包含的現有活頁簿,其提供與 Operations Manager 管理元件類似的功能。 否則,您必須檢查每個 Azure 服務的 Azure 檔,以瞭解如何監視和偵測指出可能發生失敗的已知失敗或徵兆。

監視專業領域

下圖顯示左邊的觀察專業領域,稍後在本節中,我們將討論 Microsoft Azure 在此如何扮演重要的角色。

監視專業領域

可檢視性和回應

可檢視性 是一個明顯 的指標,監視解決方案可協助監視消費者達成所定義服務的令人滿意的控制層級。 其中的監視可提供服務取用者適當範圍的監視 功能觀點

回應 是組織能夠快速確定觀察到的監視資料的 重要性 (偵測到的事件、遙測模式、相互關聯的資訊等等) ,因此可快速還原或補救的負面事件。 對於正面事件或資訊事件,它有助於維護服務合約、改善可靠性,並降低支援成本。 事件會在系統或服務中動態發生,其中監視解決方案可提供警示、控制迴圈自動化,以及在外部 IT 服務管理 (ITSM) 系統中引發事件、問題或變更。 請注意,許多事件不能或不應該自動補救。

公用程式: 就這方面來說,可檢視性 (和回應) 是有關監視解決方案的操作使用或公用程式。 Azure 監視器提供 Microsoft 對服務資源的觀點,並提供與內部部署監視系統類似的功能。 監視解決方案需要具有以角色為基礎之存取權的視覺效果,例如儀表板和活頁簿。

責任: 服務取用者和服務提供者兩者共用都需要根據硬式資料來學習和改進。 因此,您必須瞭解雲端提供者的責任,與客戶/取用者的責任。 針對每個 Azure 資源,您可以根據記錄或計量來取得觀點,此資料可以在資源專屬儀表板中表示,或根據您的需求自訂視覺效果,並與組織中的必要角色共用。

注意

可檢視性 是系統的屬性,會從系統控制理論中詞幹。 它會測量系統的內部狀態如何從其系統 外部 輸出推斷,以及 Controllability,也就是系統的另一個屬性。 此外, dynamical 系統 也會在一段時間內測量或評估系統的健全狀況狀態。 但在新式服務管理條款中,請參閱 Microsoft Operations Framework (MOF) 服務監視和控制」,以及資訊技術基礎結構程式庫 (ITIL) v3 監視和控制迴圈

在我們深入瞭解可檢視性之前,我們必須先強調幾個我們將使用的監視相關詞彙:

  • 資產: 數位資產,例如檔案共用、硬體和軟體資產中也稱為 目標 的內容。

  • 焦點: 您在追求目標的範圍:窄、廣泛、單一元件、元件類別、元件群組、服務。

  • 層面: 觀點,例如從使用者的觀點來看,商務、服務擁有者等。

  • 涵蓋範圍: 可見度和目標的指標;以確保所有相關資產都包含在監視範圍內。

  • 管理能力: 可以控制數字資產的範圍,也就是與變更風險和動作群組(可診斷或自動補救)相關的自我修復。

  • 資料來源 主要位置監視資料的來源,例如 Azure 儲存體帳戶、Azure Active Directory、自訂來源等等。

  • 頻率 連續與偶爾的監視。

敏銳的藝術

可檢視性依賴受監視的內容和作法。 在 Azure 中,有多個來源,而且每個來源都提供不同的行為方式。 不提及,Azure 包含多個工具,可協助您分析這項資料的不同層面。 觀察 Azure 服務和非 Azure 資源的健康情況和效能,是您使用 Azure 監視器和其功能的主要方式。 在 Azure 中,Microsoft 具有廣泛的服務目錄,而虛擬機器並非主要焦點。 在 Azure 中,我們會透過不同的平臺記錄來提供 服務提供者 的觀點:

  • Azure 回報服務事件和預定維修的服務健康狀態。
  • Azure 活動記錄會在訂用帳戶中部署的所有資源上報告訂用帳戶層級事件。
  • Azure 資源健康狀態報告您的資源目前和過去的健康情況。
  • Azure Advisor 接收以最佳作法為基礎的建議解決方案,以優化您的 Azure 部署。

所有其他以計量和記錄為基礎的觀點,都是透過 Azure 監視器的各種功能來傳遞。 或者,根據 Azure 資源而定,您可以直接從入口網站中的該資源查看其平臺計量。

可檢視性適用于設定預期,Azure 監視器可讓您深入瞭解 Azure 服務的健全狀況、效能和其他方面,以及深度和廣度。 但是,還有其他活動或焦點是服務和元件監視。 敏銳不應被視為只有特定的角色會根據其角色或函式的要求,或在支援進程的情況下執行的某些部分。 它類似于「同」。 觀察並不是一次,而是想要在設定的時間間隔內或連續的情況下,偶爾在空間中監視物件。 某些物件(例如黑色洞)很難觀察。 所需的監視類型取決於取用者。 例如,總是業餘天文學家會偶爾觀察,而 astrophysicists 則是將無線電排放的長期測量和持續監視的價值。

有了適當的規劃,您就可以在幾個小時內,在 Azure 中建立中型至複雜的服務,而不需要數小時或更久的內部部署。 如果您這樣做,您會將多個 Azure 資源的組合安排在不同區域 (服務元件) 。 您將使用 Azure Resource Manager 管理這些資源,並在 Azure 中使用資源群組監視來管理這些資源,您將會看到該服務的圖片。 在生產環境中,服務會 dynamical 且有彈性。 耗用量開始向上和向外延展。容量會回應需求。 將會發生事件,服務取用者可以觀察監視資料、查看趨勢,以及建立其重要性。

這項服務可能會隨著時間而改變,但無法預期的不同。 因此,我們將這種行為稱為 dynamical。 在一段時間內觀察服務的雲端服務管理員必須考慮下列事項:

  • 跨位置或地理位置移動資源
  • 新增、刪除或修改資源
  • 耗用量變化

作為監視服務提供者,您的工作是加速監視解決方案,以依照下列優先順序提供下列各項的值: 1) 至服務、2) 給專案關係人,以及 3) 至主要取用者。

您的價值串流需要以較早的方式和下列方式來考慮服務可檢視性:

  • 它會監視足夠的深度和廣度。
  • 它可在健康狀態模型中提供涵蓋範圍 (可用性、容量/效能、安全性、一致性) 。
  • 它也會監視公用程式,也就是服務的功能,包括終端使用者體驗。

在監視策略中,我們建議您建立一個以最基本的可行或最重要的監視和觀察來開始的監視計畫。 這可以根據資源或系統,根據 Microsoft、其他可靠的來源,以及您的內部開發人員或系統工程師提供建議。 在您的 Azure 資源群組和您的 Azure Active Directory 租使用者中,建立資源 耗用量效能安全性可用性 的初始可見度。 透過觀察,您將瞭解如何解讀資料,並瞭解如何進行調整,以微調和優化服務的監視方式。 值是在遞增時達成,而在這裡有共同的價值,那就是取用者與監視團隊 (,或在某些情況下,服務提供者) 在共同建立值時使用。

可檢視性逐漸發展,從最基本的可行監視計畫開始,以及整合工具和程式的工作正在進行中。 當您熟悉資料 (也就是、計量、記錄和交易) ,您就能瞭解這些資源或應用程式的徵兆或問題的行為和徵兆。 藉由熟悉資料,您就可以建立與 Azure 監視器和資料搭配使用的信任。 透過可檢視性,您可以獲得信心,並且可以瞭解原因並尋找可協助的解答:

  • 藉由確保所有所需監視元件的涵蓋範圍,來減少監視失明點。
  • 改進資源和服務的監視,以協助您在未來找出問題。 專注于可預測且可靠的問題或徵兆。
  • 評估是否未預期這一點,您可以做什麼來改善基礎結構、應用程式等。
  • 將基礎結構或應用程式排除為來源,並判斷特定的瀏覽器、瀏覽器版本或用戶端作業系統是否為潛在問題。
  • 識別、記錄或實行因應措施,以將應用程式、基礎結構等的任何效能或可用性問題降至最低。
  • 適應應用程式的 dynamical 和複雜本質。 繼續學習其正常行為模式,以縮小不尋常的行為模式。
  • 調整收集、匯總及警示的資料類型,以將永遠不會分析、警示或視覺化的資料儲存成本降至最低。

一開始,您不再需要擔心基礎結構或應用程式在內部部署世界中的情況;您現在可以自由監視或取得監視資料,以支援負責管理和操作工作負載的人員需求。

就像任何應用程式或基礎結構服務一樣,專案關係人和角色的各種清單需要存取監視功能、資料和報表。 從負責支援工作負載的核心系統工程師、作業或服務提供者開始,再將存取權延伸至其他專案關係人。

Fixed 與 dynamical 方法的比較

在資料中心內進行內部部署服務的監視,通常是與產品(例如 System Center Operations Manager)搭配使用。 Operations Manager 的方法是以代理程式和作業系統為基礎,在基礎結構和伺服器上具有穩固的基礎。 應用程式監視(不論是否為容器化)都是最新狀態,而且相依于伺服器的基礎結構監視。 您可以垂直看到解決方案涵蓋範圍,從上到下,從網路和頂端的使用者體驗監視開始。

IaaS 監視的完整歷程記錄會顯示 可檢視性可以預先定義,或您想要 預先設計 的。 以 IaaS 為基礎的服務是產品工程師可以撰寫 Operations Manager 管理元件的服務,基本上是針對大部分支援的使用案例自訂監視解決方案。

因此,若要透過監視解決方案來控制基礎結構服務,客戶會在大部分情況下尋求更多固定的方法。

在雲端中,有一種固定的方法不會發生在空間中,並以空間和時間的方式組合資源。 每個服務都可以是唯一的。 Azure 中的服務可檢視性必須根據 (服務的彈性本質(也就是 dynamical、全域、彈性、) 以使用者為中心)來建立,或根據某些可能尚未存在的架構樣板集來建立。

然後,可檢視性會優先全面性地型查看所有元件如何一起運作, 建立事件重要性 (警示、摘要、活頁簿等 ) 。

同樣地,雲端服務監視的彈性更高,且 dynamical 加快變更速度。

監視計畫

您可以建立監視計畫,以描述目標和目標、需求和其他重要的詳細資料。 然後,在組織中的所有相關專案關係人之間,請求合約。 監視計畫應說明如何開發及操作一或多個監視解決方案。 在專案的策略和規劃階段,及早開始開發您的監視方案。

在建立方案時,請務必記住新式監視的五個專業領域-觀察、測量、回應及學習和改善。

以下提供建議的大綱,並將其視為服務個別方案的主要考慮,或將雲端服務功能(例如 Azure 資源類型或 Microsoft 365 服務)標準化時。 計畫的本質是在服務提供者之間定義可見度的行, (誰將會) 和取用者 (負責操作或衍生值) 。

(的排程以及) 的運作方式也很重要,例如,DevOps 與瀑布式) 的工作管理 (方法。

商務觀點

全方位的監視計畫必須考慮企業在監視方面的需求,而且必須包含以使用者為中心的焦點。 在定義方案時,請務必記錄和共用商務需求,以下建議這部分方案的範圍。

  • 專案關係人和取用者
  • 商業價值串流和流程
  • 終端使用者的觀點和公用程式
  • 度量和報告需求
  • 已識別的風險與合規性控制架構
  • 存取和控制需求
  • 企業風險

服務觀點

全面的監視計畫必須考慮服務擁有者在監視方面的需求。 在定義方案時,請務必記錄並共用其需求,以下建議這部分方案的範圍。

  • 專案關係人和取用者
  • 角色與責任
  • 服務的定義
  • 存取和控制需求
  • 架構考慮?
  • 供應商和合作夥伴底層合約
  • 服務協定 (Sla、Ola)
  • 識別服務擔保涵蓋範圍
  • 度量和報告需求
  • 風險

技術觀點

此計畫的這一節代表使用商務和服務觀點資訊的監視解決方案。

  • 使用者案例和案例
  • 技術目標 (例如網路)
  • 元件相依性對應
  • 類型 (例如,雲端原生、混合式、內部部署)
  • 觀測
  • 回應式
  • 測量
  • 微調和優化

主要考量

摘要說明如何進行溝通,並通知所有相關的取用者、專案關係人和管理層級。

  • 生產階段: 當服務上線時,監視解決方案應可提供價值,因此規劃可包含實驗室或預先生產環境的設定 (也就是在支援此) 的另一個訂用帳戶中進行實驗,並測試您的假設。 在雲端中,生產租使用者通常是以整體治理為安全的。

  • 策略: 方案也可以對應回監視和 IT 策略,讓監視目標追蹤回到任務或業務。 這取決於工作負載是否為原生雲端

  • 目標: 在此計畫中,您應該根據考慮來描述及分析目標資產 (s) 或服務 () 如有需要,請對應要監視的所有元件,以包含服務相依性。 找出涵蓋範圍缺口,並判斷誰擁有服務的各部分。

  • 解決方案: 針對監視解決方案,識別取用者、專案關係人、供應商、合作夥伴、存取和檢測。 此外,監視層面、焦點、回應和報表與儀表板 (可用性、安全性、使用者體驗等) 。

精簡和敏捷式考慮

  • 最小可行產品: 讓此方案定義最小可行產品,這是一開始上線所需的產品,然後繼續發展監視解決方案以將價值最大化。 例如,您可以稍後定義未來的工作,以建立其他以記錄為基礎的活頁簿、釘選到 Azure 儀表板,以及將專案關係人存取擴充至 Azure 入口網站。

  • 您可以從這裡開始,快速取得價值: 快速且徹底的實驗,利用現成的 SaaS,因為它既簡單又實用。

  • 知道護欄: 雲端是新的且不確定,因此,請讓專家引導您找出風險 (例如,將敏感的監視資料公開) 。

  • Microsoft 365 取決於 Azure: 任何良好的方案都會將您的 Azure 租使用者視為主要玩家的 Microsoft 365。 Microsoft 365 取決於 Azure AD,而且 Azure 監視器會提供與端點管理 Microsoft 365 的整合。

  • 可檢視性獲勝: 將焦點放在警示之前的總可見度,因為警示現在是成本。

  • 記錄架構: 發射器、遙測、信號、AI 和預先封裝的解決方案(例如 Intelligent Security Graph)。 更專注于 SIEM 方法,如何 amass 不同的記錄到記錄解決方案,例如 Azure 監視器記錄。

  • 移動資料: 更多監視功能著重于發射器對儀表板,以及資料會透過網際網路和跨雲端區域、ExpressRoute 連線和 Vpn。

  • 活動監視: 您現在可以輕鬆地對服務擁有者和安全性進行「審核」、「登入」和「活動記錄」的配量和骰子。

下一步