You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-monitor/azure-monitor-operations-manager.md
+29-77Lines changed: 29 additions & 77 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,21 +10,39 @@ ms.reviewer: bwren
10
10
---
11
11
12
12
# Migrate from SCOM to Azure Monitor
13
-
This article provides guidance for customers who currently use [System Center Operations Manager (SCOM)](/system-center/scom/welcome) and are planning a transition to cloud based monitoring with [Azure Monitor](overview.md) as they migrate business applications and other resources into Azure.
13
+
This article provides guidance for customers who currently use [System Center Operations Manager (SCOM)](/system-center/scom/welcome) and are planning a transition to cloud based monitoring with [Azure Monitor](overview.md) as they migrate business applications and other resources into Azure.
14
+
15
+
There's no standard process for migrating from SCOM, and depending on your business and technical requirements, you may rely on SCOM management packs for an extending period of time as opposed to performing a quick migration. This article describes the different options available and decision criteria you can use to determine the best strategy for your particular environment.
16
+
17
+
## Components to monitor
18
+
It helps to categorize the different types of workloads that you need to monitor in order to determine a distinct monitoring strategy for each. [Cloud monitoring guide: Formulate a monitoring strategy](/azure/cloud-adoption-framework/strategy/monitoring-strategy#high-level-modeling) provides a detailed breakdown of the different layers in your environment that need monitoring as you progress from legacy enterprise applications to modern applications in the cloud.
19
+
20
+
Before the cloud, you used Operations Manager to monitor all layers. As you start your transition with Infrastructure as a Service (IaaS), you continue to use Operations Manager for your virtual machines but start to use Azure Monitor for your cloud resources. As you further transition to modern applications using Platform as a Service (PaaS), you can focus more on Azure Monitor and start to retire Operations Manager functionality.
21
+
22
+
:::image type="content" source="media/azure-monitor-operations-manager/cloud-models.png" alt-text="Diagram showing different cloud models: on-premises, infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).":::
23
+
24
+
These layers can be simplified into the following categories. While every monitoring workload in your environment may not fit neatly into one of these categories, each should be close enough to a particular category for the general recommendations to apply.
25
+
26
+
**Business applications.** Applications that provide functionality specific to your business. They may be internal or external and are often developed internally using custom code. Your legacy applications will typically be hosted on virtual or physical machines running either Windows or Linux, while your newer applications will be based on application services in Azure such as Azure Web Apps and Azure Functions.
27
+
28
+
**Azure services.** Resources in Azure that support your business applications that have migrated to the cloud. This includes services such as Azure Storage, Azure SQL, and Azure IoT. This also includes Azure virtual machines since they are monitored like other Azure services, but the applications and software running on the guest operating system of those virtual machines require more monitoring beyond the host.
29
+
30
+
**Server software.** Software running on virtual and physical machines that support your business applications or packaged applications that provide general functionality to your business. Examples include Internet Information Server (IIS), SQL Server, Exchange, and SharePoint. This also includes the Windows or Linux operating system on your virtual and physical machines.
31
+
32
+
**Local infrastructure.** Components specific to your on-premises environment that require monitoring. This includes such resources as physical servers, storage, and network components. These are the components that are virtualized when you move to the cloud.
14
33
15
-
> [!IMPORTANT]
16
-
> There is a cost to implementing several Azure Monitor features described here, so you should evaluate their value before deploying across your entire environment. See [Cost optimization and Azure Monitor](best-practices-cost.md) for strategies for reducing your cost for Azure Monitor.
17
34
18
35
36
+
## Hybrid cloud monitoring
37
+
Most customers will use a [hybrid cloud monitoring](/azure/cloud-adoption-framework/manage/monitor/cloud-models-monitor-overview#hybrid-cloud-monitoring) strategy that allows you to make a gradual transition to the cloud. Even though some features may overlap, this strategy will allow you to maintain your existing business processes as you become more familiar with the new platform. Only move away from Operations Manager functionality as you can replace it with Azure Monitor. Using multiple monitoring tools does add complexity, but it allows you to take advantage of Azure Monitor's ability to monitor next generation cloud workloads while retaining Operations Manager's ability to monitor server software and infrastructure components that may be on-premises or in other clouds.
19
38
20
-
## On-premises SCOM
21
39
Your environment prior to moving any components into Azure is based on virtual and physical machines located on-premises or with a managed service provider. It relies on Operations Manager to monitor business applications, server software, and other infrastructure components in your environment such as physical servers and networks. You use standard management packs for server software such as IIS, SQL Server, and various vendor software, and you tune those management packs for your specific requirements. You create custom management packs for your business applications and other components that can't be monitored with existing management packs and configure Operations Manager to support your business processes.
22
40
23
-
Your migration to Azure typically starts with IaaS, moving virtual machines supporting business applications into Azure. The monitoring requirements for these applications and the server software they depend on don't change, so you can continue using Operations Manager on these servers with your existing management packs. This does require that you allow your agents in the cloud to access your on-premises management servers.
41
+
As you move services into the cloud, Azure Monitor starts collecting [platform metrics]()and the [activity log]() for each, and you create [diagnostic settings]() to collect [resource logs]() to be collected so you can interactively analyze all available telemetry using [log queries]() and [insights]().
24
42
43
+
During this period of transition, you will have two independent monitoring tools. You'll use insights and workbooks to analyze your cloud telemetry in the Azure portal while still using the Operations console to analyze your data collected by SCOM. Each system also has its own alerts, so each would need to be managed independently.
25
44
26
-
## Existing integration with SCOM
27
-
There are multiple ways to combine your SCOM and Azure Monitor environments.
45
+
The following table describes the different features and strategies that are available for a hybrid monitoring environment using Operations Manager and Azure Monitor.
28
46
29
47
| Method | Description |
30
48
|:---|:---|
@@ -34,8 +52,9 @@ There are multiple ways to combine your SCOM and Azure Monitor environments.
34
52
| Azure management packs | The [Azure management pack](https://www.microsoft.com/download/details.aspx?id=50013) allows Operations Manager to discover Azure resources and monitor their health based on a particular set of monitoring scenarios. This management pack does require you to perform additional configuration for each resource in Azure, but it may be helpful to provide some visibility of your Azure resources in the Operations Console until you evolve your business processes to focus on Azure Monitor. |
35
53
36
54
37
-
38
55
## Enable VM monitoring
56
+
As you move virtual machines supporting business applications into Azure. The monitoring requirements for these applications and the server software they depend on don't change, so you can continue using Operations Manager on these servers with your existing management packs. This does require that you allow your agents in the cloud to access your on-premises management servers.
57
+
39
58
As soon as a virtual machine is created in Azure, [platform metrics]() and [activity logs]() for the VM host automatically start being collected, but you need to enable VM insights to install the Azure Monitor agent and start collecting data from the client. Even though SCOM is collecting similar data, this will allow you to start migrating your monitoring logic to Azure Monitor. VM insights will collect common performance counters for the client operating system and allow to start viewing trends over time. You may also choose to enable the [map feature]() which will give you insight into the processes running on your virtual machines and their dependencies on other services.
40
59
41
60
This allows you to continue with the same SCOM monitoring that you've been relying on while gaining additional insights provided by Azure Monitor.
@@ -50,62 +69,12 @@ This allows you to continue with the same SCOM monitoring that you've been relyi
50
69
See [Migrate from Operations Manager on-premises to Azure Monitor SCOM Managed Instance (preview)](https://learn.microsoft.com/en-us/system-center/scom/migrate-to-operations-manager-managed-instance?view=sc-om-2022&tabs=mp-overrides) for the detailed steps on migration to SCOM Managed Instance.
51
70
52
71
53
-
## Migrate workloads
54
-
55
-
56
-
57
-
58
-
59
-
60
-
## Azure Monitor for cloud components
61
-
When you first start your migration into the cloud, use Azure Monitor to monitor your cloud components. This includes creating diagnostic settings to collect resource logs from your Azure components and enabling features such as Container insights for your Kubernetes clusters and XXX.
62
-
63
-
Use Azure Arc for hybrid resources either on-premises or in other clouds.
64
-
65
-
During this phase, continue to use your existing SCOM environment to monitor the workloads running on your virtual machines. Even as you migrate your machines into Azure, the MMA running on them can connect to your existing SCOM environment and continue running the same management packs.
66
-
67
-
68
-
## Azure Monitor for virtual machine host
69
-
70
-
Continue using your on-premises SCOM environment to monitor the workloads on your virtual machines, but enable Azure Monitor to monitor your virtual machine hosts. Platform metrics and activity log will start collecting as soon as the virtual machines are collected.
71
-
72
-
Enable VM insights to install the
73
-
74
-
75
-
76
-
77
-
## Components to monitor
78
-
It helps to categorize the different types of workloads that you need to monitor in order to determine a distinct monitoring strategy for each. [Cloud monitoring guide: Formulate a monitoring strategy](/azure/cloud-adoption-framework/strategy/monitoring-strategy#high-level-modeling) provides a detailed breakdown of the different layers in your environment that need monitoring as you progress from legacy enterprise applications to modern applications in the cloud.
79
-
80
-
Before the cloud, you used Operations Manager to monitor all layers. As you start your transition with Infrastructure as a Service (IaaS), you continue to use Operations Manager for your virtual machines but start to use Azure Monitor for your cloud resources. As you further transition to modern applications using Platform as a Service (PaaS), you can focus more on Azure Monitor and start to retire Operations Manager functionality.
81
-
82
-
:::image type="content" source="media/azure-monitor-operations-manager/cloud-models.png" alt-text="Diagram showing different cloud models: on-premises, infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).":::
83
-
84
-
These layers can be simplified into the following categories. While every monitoring workload in your environment may not fit neatly into one of these categories, each should be close enough to a particular category for the general recommendations to apply.
85
-
86
-
**Business applications.** Applications that provide functionality specific to your business. They may be internal or external and are often developed internally using custom code. Your legacy applications will typically be hosted on virtual or physical machines running either Windows or Linux, while your newer applications will be based on application services in Azure such as Azure Web Apps and Azure Functions.
87
-
88
-
**Azure services.** Resources in Azure that support your business applications that have migrated to the cloud. This includes services such as Azure Storage, Azure SQL, and Azure IoT. This also includes Azure virtual machines since they are monitored like other Azure services, but the applications and software running on the guest operating system of those virtual machines require more monitoring beyond the host.
89
-
90
-
**Server software.** Software running on virtual and physical machines that support your business applications or packaged applications that provide general functionality to your business. Examples include Internet Information Server (IIS), SQL Server, Exchange, and SharePoint. This also includes the Windows or Linux operating system on your virtual and physical machines.
91
-
92
-
**Local infrastructure.** Components specific to your on-premises environment that require monitoring. This includes such resources as physical servers, storage, and network components. These are the components that are virtualized when you move to the cloud.
93
-
94
-
95
-
96
-
97
72
98
73
## Monitor server software and local infrastructure
99
-
When you move machines to the cloud, the monitoring requirements for their software don't change. You no longer need to monitor their physical components since they're virtualized, but the guest operating system and its workloads have the same requirements regardless of their environment.
74
+
When you move machines to the cloud, the monitoring requirements for their software don't change. You no longer need to monitor any physical components since they're virtualized, but the guest operating system and its workloads have the same requirements regardless of their environment.
100
75
101
76
The [Azure Monitor agent](agents/agents-overview.md) uses [data collection rules](essentials/data-collection-rule-overview.md) to collect data from the guest operating system of virtual machines. This is the same performance and event data typically used by management packs for analysis and alerting. [VM insights](vm/vminsights-overview.md) allows you to easily deploy and manage the agent and gets you started with preexisting data collection rules and performance views.
102
77
103
-
> [!NOTE]
104
-
> Azure Monitor previously used the same Microsoft Management Agent (referred to as the Log Analytics agent in Azure Monitor) as Operations Manager. The Azure Monitor agent can coexist with this agent on the same machine during migration.
Examples of features unique to Azure Monitor include the following:
111
80
@@ -116,13 +85,10 @@ Examples of features unique to Azure Monitor include the following:
116
85
117
86
In addition to Azure virtual machines, Azure Monitor can monitor machines on-premises and in other clouds using [Azure Arc-enabled servers](../azure-arc/servers/overview.md). Azure Arc-enabled servers allow you to manage your Windows and Linux machines hosted outside of Azure, on your corporate network, or other cloud provider consistent with how you manage native Azure virtual machines.
Azure Monitor though doesn't have preexisting rules to identify and alert on issues for the business applications and server software running in your virtual machines. You must create your own alert rules to be proactively notified of any detected issues.
124
91
125
-
126
92
Azure Monitor also doesn't measure the health of different applications and services running on a virtual machine. Metric alerts can automatically resolve when a value drops below a threshold, but Azure Monitor doesn't currently have the ability to define health criteria for applications and services running on the machine, nor does it provide health rollup to group the health of related components.
127
93
128
94
Monitoring the software on your machines in a hybrid environment will often use a combination of Azure Monitor and Operations Manager, depending on the requirements of each machine and on your maturity developing operational processes around Azure Monitor.
@@ -191,17 +157,3 @@ Management packs often make use of synthetic transactions that connect to an app
191
157
- Read more about [VM insights](vm/vminsights-overview.md).
192
158
- Read more about [Application Insights](app/app-insights-overview.md).
193
159
194
-
195
-
196
-
## Sample walkthrough
197
-
The following is a hypothetical walkthrough of a migration from Operations Manager to Azure Monitor. This is not intended to represent the full complexity of an actual migration, but it does at least provide the basic steps and sequence. The sections below describe each of these steps in more detail.
198
-
199
-
Your environment prior to moving any components into Azure is based on virtual and physical machines located on-premises or with a managed service provider. It relies on Operations Manager to monitor business applications, server software, and other infrastructure components in your environment such as physical servers and networks. You use standard management packs for server software such as IIS, SQL Server, and various vendor software, and you tune those management packs for your specific requirements. You create custom management packs for your business applications and other components that can't be monitored with existing management packs and configure Operations Manager to support your business processes.
200
-
201
-
Your migration to Azure starts with IaaS, moving virtual machines supporting business applications into Azure. The monitoring requirements for these applications and the server software they depend on don't change, and you continue using Operations Manager on these servers with your existing management packs.
202
-
203
-
Azure Monitor is enabled for your Azure services as soon as you create an Azure subscription. It automatically collects platform metrics and the Activity log, and you configure resource logs to be collected so you can interactively analyze all available telemetry using log queries. You enable VM insights on your virtual machines to analyze monitoring data across your entire environment together and to discover relationships between machines and processes. You extend your use of Azure Monitor to your on-premises physical and virtual machines by enabling Azure Arc-enabled servers on them.
204
-
205
-
You enable Application Insights for each of your business applications. It identifies the different components of each application, begins to collect usage and performance data, and identifies any errors that occur in the code. You create availability tests to proactively test your external applications and alert you to any performance or availability problems. While Application Insights gives you powerful features that you don't have in Operations Manager, you continue to rely on custom management packs that you developed for your business applications since they include monitoring scenarios not yet covered by Azure Monitor.
206
-
207
-
As you gain familiarity with Azure Monitor, you start to create alert rules that are able to replace some management pack functionality and start to evolve your business processes to use the new monitoring platform. This allows you to start removing machines and management packs from the Operations Manager management group. You continue to use management packs for critical server software and on-premises infrastructure but continue to watch for new features in Azure Monitor that will allow you to retire additional functionality.
0 commit comments