Is there a translation from SCOM to Azure monitor?

Question

Our product is a legacy intranet system. Now it is supporting Azure Cloud, some servers keep on prem, and most of servers need to be run in Azure. A critical problem is how to support the ability and function of Microsoft SCOM (we always use SCOM as the monitoring solution for over ten years). Our some customers also relied on it deeply and did much customizations. The questions are:

• If we want to obtains the ability of scaling by Azure component (such as VM scale set), can we continue to use the legacy SCOM?
• If we can't use SCOM, is there a parallel way to translate all SCOM functions (classes, discovers, monitors, rules, views, reports, etc) from SCOM to Azure monitor quickly?
• We created some discovers/monitors by custom script (vbscript/javascript/powershell) for special customization. By legacy SCOM way, they are executed by SCOM agent on target machines. How to translate them?
• If the translation is not suggested (or effort is too big), whether it is a better option to still use SCOM and implement a self auto-scale engine based on Azure?

Answer 1

Hi there,

SCOM is a great monitoring tool, our community loves it so much and I can't say it's time to say bye to SCOM, no.

• If you plan to scale to Azure and consume virtual machines as a primary compute resource - keep using your investments to SCOM.
• Azure Monitor doesn't relay to objec-oriented model. It's focusing on metrics and logs, and the discovery process takes sometimes to adopt yourself from SCOM to Azure Monitor. But believe me, Azure has so many interesting features and integrated tools, the discovery process will look pretty scalable on every scenario
• In Azure, discovery process looks differently, but by using Azure Functions\LogicApps\Azure Automation accounts you will be able to leverage your powershell scripts (pls, stop using vbs at all, it's time to deprecate the vbs scripts :))
• Continue using SCOM for IaaS components (mostly focusing on virtual machines). It's still a great tool. Azure Monitor is a cloud native tool and its main focus to collect logs\metrics from Azure native services first.

P.S. I highly recommend reading Cloud Adoption Framework and its section https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/manage/monitor/platform-overview
Hopefully it will be useful for your journey

Answer 2

You can monitor Azure VMs with SCOM if preferred.

Azure Monitor is classless and stateless. There is no class framework to build or maintain using discovery rules. There are no remote scripts. You can target/scope monitoring but there is less of a need for managing where monitoring runs. With far fewer rules and no remote scripts, there is little need to limit the monitoring scope. SSRS-style reporting is no longer a thing but AzMOn has Workbooks that are tile-based view/reports.

You may recall the transition from physical server monitoring to virtual server monitoring. There were many aspects of physical servers that no longer needed monitoring. With cloud-based monitoring I feel there is a similar evolution.

The single database is now a workspace which is comparable to EventViewer. Flat, non-relational tables in an easy to query repository. There are no management packs. AzMOn has Insights that are more visual. Monitoring can be managed using ARM templates so it is feasible to create something like MPs. My recommendation is to review your top SCOM alerts from the past 6-12 months. You can create most in AzMOn without the complexity of MPs. We are talking 30-40 custom rules vs. 20-30k MP driven rules/monitors.

The main challenges you might encounter are that Azure Monitor rules are query-based and there are no MPs. Rules are limited to event, logs, and perf counters (no scripts). Also, the alert management experience is not comparable to SCOM. You may need an ITSM to have something close to the SCOM alert management experience.

Answer 3

You can monitor Azure VMs with SCOM if preferred.

Azure Monitor is classless and stateless. There is no class framework to build or maintain using discovery rules. There are no remote scripts. You can target/scope monitoring but there is less of a need for managing where monitoring runs. With far fewer rules and no remote scripts, there is little need to limit the monitoring scope. SSRS-style reporting is no longer a thing but AzMOn has Workbooks that are tile-based view/reports.

You may recall the transition from physical server monitoring to virtual server monitoring. There were many aspects of physical servers that no longer needed monitoring. With cloud-based monitoring I feel there is a similar evolution.

The single database is now a workspace which is comparable to EventViewer. Flat, non-relational tables in an easy to query repository. There are no management packs. AzMOn has Insights that are more visual. Monitoring can be managed using ARM templates so it is feasible to create something like MPs. My recommendation is to review your top SCOM alerts from the past 6-12 months. You can create most in AzMOn without the complexity of MPs. We are talking 30-40 custom rules vs. 20-30k MP driven rules/monitors.

The main challenges you might encounter are that Azure Monitor rules are query-based and there are no MPs. Rules are limited to event, logs, and perf counters (no scripts). Also, the alert management experience is not comparable to SCOM. You may need an ITSM to have something close to the SCOM alert management experience.