從 System Center Operations Manager (SCOM) 遷移至 Azure 監視器

本文為目前使用 System Center Operations Manager (SCOM) 並規劃轉換至 Azure 監視器以使用雲端型監視的客戶提供指導,因為他們要將商務應用程式和其他資源移轉至 Azure。

從 SCOM 遷移沒有標準流程,您也可以依賴 SCOM 管理組件來延長期限,而不是執行快速移轉。 本文說明可用來為特定環境判斷最佳策略的不同可用選項和決策準則。

混合式雲端監視

大部分的客戶都會使用混合式雲端監視策略來逐步轉換至雲端。 此方法可讓您在更熟悉新平台的同時,維護現有的商務程序。 僅脫離 SCOM 功能,因為您可以將其取代為 Azure 監視器。 雖然多個監視工具會增加複雜性,但這可讓您利用 Azure 監視器來監視新一代雲端工作負載,同時保留 SCOM 監視伺服器軟體和工作負載的能力。

將任何元件移至 Azure 之前的環境是以位於內部部署或具有受控服務提供者的虛擬和實體機器為基礎。 其依賴 SCOM 來監視環境中的商務應用程式、伺服器軟體和其他基礎結構元件,例如實體伺服器和網路。 您可以針對伺服器軟體使用標準管理組件,例如 IIS、SQL Server 和各種廠商軟體,並針對特定需求調整這些管理組件。 您可以為商務應用程式和無法使用現有管理組件監視的其他元件建立自訂管理組件,也可以設定 SCOM 以支援商務程序。

當您將服務移至雲端時,Azure 監視器會開始收集每個資源的平台計量活動記錄。 您可以建立診斷設定來收集資源記錄,以便使用記錄查詢深入解析,透過互動方式分析所有可用的遙測資料。

在此轉換期間,您會有兩個獨立的監視工具。 您可以使用深入解析和活頁簿在 Azure 入口網站中分析雲端遙測,同時仍使用 Operations 控制台來分析 SCOM 收集的資料。 由於每個系統都有自己的警示,因此您必須在 Azure 監視器中建立與 SCOM 通知群組相等的動作群組。

下表說明使用 SCOM 和 Azure 監視器的混合式監視環境可用的不同功能和策略。

方法 描述
雙宿主代理程式 SCOM 使用 Microsoft 管理代理程式 (MMA),其與 Azure 監視器所使用的 Log Analytics 代理程式相同。 您可以將此代理程式設定為讓單一機器同時連線到 SCOM 和 Azure 監視器。 此設定需要您的 Azure VM 連線到內部部署管理伺服器。

Log Analytics 代理程式已由 Azure 監視器代理程式取代,其可提供顯著優勢,包括更簡單的管理方式,以及更妥善地控制資料收集。 這兩個代理程式可以共存於同一部機器上,讓您能夠同時連線到 Azure 監視器和 SCOM。 此設定比舊版代理程式的雙宿主設定更好,因為 Azure 監視器代理程式的優點相當顯著。
已連線的管理群組 將 SCOM 管理群組連線至 Azure 監視器,即可將從 SCOM 代理程式收集的資料轉送至 Azure 監視器。 這類似於使用雙宿主代理程式,但不需要將每個代理程式設定為連線到 Azure 監視器。 此策略需要舊版代理程式,因此您無法搭配資料收集規則來指定監視功能。 除非您將每個 VM 直接連線到 Azure 監視器,否則您也無法使用 VM 深入解析。
SCOM 受控執行個體 (預覽) SCOM 受控執行個體 (預覽) 是 SCOM 在 Azure 中的完整實作,可讓您繼續執行在內部部署 SCOM 環境中執行的相同管理組件。 SCOM 和 Azure 監視器的資料和警示之間目前沒有整合,您可以繼續使用相同的 Operations 控制台來分析健康情況和警示。

SCOM MI 類似於維護現有的 SCOM 環境和雙宿主代理程式,不過您可以在 Azure 中合併監視設定,淘汰資料庫和管理伺服器等內部部署元件。 來自 Azure VM 的代理程式可以連線到 Azure 中的 SCOM 受控執行個體,而不是連線到您自己資料中心的管理伺服器。
Azure 管理組件 Azure 管理組件可讓 Operations Manager 根據一組特定的監視情節來探索 Azure 資源並監視其健康情況。 此管理組件會要求您針對 Azure 中的每個資源執行額外的設定。 不過,在您將商務程序發展為專注於 Azure 監視器之前,Operations 主控台有助於為 Azure 資源提供一些可見度。

監視商務應用程式

您通常需要自訂管理組件,才能使用 SCOM 監視商務應用程式,並使用每個虛擬機器上安裝的代理程式。 Azure 監視器中的 Application Insights 會監視 Web 應用程式,且無論其位於 Azure、其他雲端或內部部署。 其可用於您的所有應用程式,且不論應用程式是否已遷移至 Azure。

如果您的商務應用程式監視僅限於 SCOM 中 .NET 應用程式效能範本所提供的功能,則您最有可能移轉至 Application Insights,才不會遺失功能。 事實上,Application Insights 包含大量其他功能,包括下列各項:

  • 自動探索及監視應用程式元件。
  • 收集詳細的應用程式使用量和效能資料,例如回應時間、失敗率和要求率。
  • 收集瀏覽器資料,例如頁面檢視和載入效能。
  • 偵測例外狀況並鑽研堆疊追蹤和相關要求。
  • 使用分散式追蹤智慧偵測等功能來執行進階分析。
  • 使用計量總管以互動方式分析效能資料。
  • 使用記錄查詢,以互動方式分析收集的遙測,以及針對 Azure 服務和 VM 深入解析收集的資料。

不過,在某些情節下,除了 Application Insights 之外,您可能需要繼續使用 SCOM,直到您能夠達到必要的功能為止。 您可能需要繼續使用 SCOM 的範例如下:

  • 可讓您監視和警示應用程式的可用性和回應性的可用性測試,需要來自 Web 測試代理程式的 IP 位址傳入要求。 如果原則不允許這類存取,您可能需要繼續使用 SCOM 中的 Web 應用程式可用性監視器
  • 在 SCOM 中,您可以設定可用性測試的任何輪詢間隔,許多客戶每隔 60-120 秒檢查一次。 Application Insights 的輪詢間隔下限為五分鐘,對某些客戶來說這個間隔可能太長。
  • SCOM 中的大量監視是藉由收集應用程式所產生的事件,以及在本地代理程式上執行指令碼來執行。 這些不是 Application Insights 中的標準選項,因此您可能需要自訂工作才能達到商務需求。 這可能包括使用在 Log Analytics 工作區儲存的事件資料,以及使用混合式 Runbook 背景工作角色,在虛擬機器客體中啟動的指令碼中自訂警示規則。
  • 視應用程式撰寫的語言而定,您可能會受限於您可以與 Application Insights 搭配使用的檢測

遵循本指南其他章節中的基本策略,繼續在商務應用程式上使用 SCOM,但利用 Application Insights 所提供的其他功能。 當您能夠以 Azure 監視器取代重要功能時,您可以開始淘汰自訂管理組件。

監視虛擬機器

在混合式環境中監視虛擬機上的軟體時,通常會使用 Azure 監視器和 SCOM 的組合 (視 VM 上執行的工作負載需求而定)。 一旦在 Azure 中建立虛擬機器後,VM 主機的平台計量活動記錄就會自動開始收集。 啟用建議的警示,通知您 VM 主機的常見錯誤,例如伺服器關閉和高 CPU 使用率。

啟用 VM 深入解析以安裝 Azure 監視器代理程式,並開始從用戶端作業系統收集一般效能資料。 這可能會與您在 SCOM 中收集的某些資料重疊,但可讓您開始檢視一段時間的趨勢,並監視您的 Azure VM 和其他雲端資源。 您也可以選擇啟用對應功能,讓您深入了解虛擬機上執行的程序,以及其與其他服務的相依性。

繼續使用管理組件來獲得 Azure 監視器中其他功能無法提供的功能。 這包括 IIS、SQL Server 或 Exchange 等重要伺服器軟體的管理組件。 您可能也有針對無法透過 Azure 監視器連線的內部部署基礎結構所開發的自訂管理組件。 如果 SCOM 已緊密整合至作業程序,請繼續使用 SCOM,直到您可以轉換至將 Azure 監視器和其他 Azure 服務擴充或取代的服務作業現代化為止。

注意

如果您使用 Log Analytics 代理程式來啟用 VM Insights,而不是使用 Azure 監視器代理程式,則不需要在 VM 上安裝其他代理程式。 不過,建議使用 Azure 監視器代理程式,因為其在雲端中監視 VM 方面有顯著的改善。 維護多個代理程式的複雜性會因可在資料收集規則中定義監視功能而抵銷,因為這可讓您為不同的 VM 集合設定不同的資料收集,類似於設計管理組件的策略。

遷移 VM 工作負載的管理組件邏輯

沒有任何移轉工具可將 SCOM 管理組件轉換至 Azure 監視器,因為其邏輯基本上與 Azure 監視器資料收集不同。 遷移管理組件邏輯通常會著重於分析 SCOM 收集的資料,並識別 Azure 監視器可複寫的監視案例。 當您自訂 Azure 監視器以符合不同應用程式和元件的需求時,您就可以開始淘汰 SCOM 中的不同管理組件和舊版代理程式。

SCOM 中的管理元件包含規則和監視器,可將資料收集和產生的警示合併成單一端對端工作流程。 SCOM 已經收集的資料很少用於警示。 Azure 監視器會將資料收集和警示分成不同的流程。 警示規則會從已從代理程式收集的 Azure 監視器記錄和 Azure 監視器計量存取資料。 此外,規則和監視器通常以特定的資料為焦點,例如特定事件或效能計數器。 Azure 監視器中的資料收集規則通常會更廣泛地收集單一 DCR 中的多組事件和效能計數器。

如需為常見監視案例建立資料收集和警示的指引,請參閱下列內容:

與其嘗試複寫管理組件的完整功能,不如分析每個管理組件所提供的重要監視功能。 決定您是否可以使用替代方法來復寫這些監視需求。 在多數情況下,您可以在 Azure 監視器中設定資料收集和警示規則,藉此複寫足以淘汰特定管理組件的功能。 管理組件通常包含數百個甚至數千個規則和監視器。

其中一項策略便是著重於觸發您環境中警示的監視和規則。 請參閱 Operations Manager 中可用的現有報告,例如警示最常見的警示,可協助您在一段時間內識別警示。 您也可以在作業資料庫執行下列查詢,以評估最常見的警示。

select AlertName, COUNT(AlertName) as 'Total Alerts' from
Alert.vAlertResolutionState ars
inner join Alert.vAlertDetail adt on ars.AlertGuid = adt.AlertGuid
inner join Alert.vAlert alt on ars.AlertGuid = alt.AlertGuid
group by AlertName
order by 'Total Alerts' DESC

評估輸出以識別移轉的特定警示。 忽略任何已微調或已知有問題的警示。 檢閱管理組件,以識別從未觸發任何重要的重大警示。

綜合交易

管理組件通常會使用綜合交易會連線至機器上執行的應用程式或服務,以模擬使用者連線或實際使用者流量。 若能使用應用程式,您可以假設機器正常執行。 Azure 監視器中的 Application Insights 可用性測試可提供這項功能。 這項功能僅適用於可從網際網路存取的應用程式。 針對內部應用程式,您必須開啟防火牆,以允許從執行測試的特定 Microsoft URL 進行存取。 或者,您可以繼續使用現有的管理組件。

下一步