Azure Monitoring Tools Explained – Part 13: System Center Operations Manager (SCOM)

In the first part of this series, we introduced the confusion and complexity that tends to occur when looking at the long list of monitoring tools available for Azure.

We then provided a list of currently available tools that we will explore further.

• Part 2: Activity Logs
• Part 3: Application Insights
• Part 4: Azure Advisor
• Part 5: Azure Alerts
• Part 6: Azure Diagnostics
• Part 7: Azure Metrics
• Part 8: Azure Monitor
• Part 9: Azure Security Center (ASC)
• Part 10: Network Watcher
• Part 11: Operations Management Suite (OMS)
• Part 12: Service Health
• Part 13: System Center Operation Manager (SCOM)

We’ve already discussed Azure Activity Logs, Application Insights, Azure Advisor,  Azure Alerts, Azure Diagnostics, Azure Metrics, Azure Monitor, Azure Security Center (ASC), Network Watcher, Operations Management Suite (OMS), and Service Health. The final tool on the list is System Center Operations Manager (SCOM). 

System Center Operations Manager (SCOM)

You may wonder why we included SCOM, an on-premises product, in an article about monitoring Azure.

Put simply, although SCOM is designed to monitoring your datacenter environment, it can also be extended to monitor your Azure resources too. For example, SCOM has a Management Pack (MP) that enables you to monitor the availability and performance of your resources that are running in Azure.

So what does this enable you to monitor in Azure? Firstly, it uses the Azure REST APIs to remotely discover and collect performance information about the specified Microsoft Azure resources. Of note, the Management Pack is specifically configured to collect data from Azure Resource Manager (ARM) based resources, and not the classic Azure Service Management (ASM) type.

Here is the link to the most recent Azure Management Pack for SCOM.

Real Word Example

Unfortunately, I don’t have a SCOM environment setup to run through this (sorry). But, in reading through the Management Pack documentation, I will call out a few things that you should be aware of before deploying this solution.

• This Management Pack is not supported on SCOM 2012 RTM, so you need at least 2012 SP1 to use it
• Microsoft recommends a dedicated Management Server for this Management Pack, due to performance issues!
• To collect Event and Performance data from Azure resources, you need to enable Azure Diagnostics for them first, and those diagnostic logs need to be forwarded to an Azure Storage account.
• Azure Active Directory is used for authenticating Azure REST API calls, so you need Azure AD setup, and with that either an Azure Active Directory User Principal Name (UPN) or Service Principal Name (SPN).
• If you use a Service Principal Name (SPN), you need to grant Contributor permissions, as the default Reader permissions on insufficient.
• You will use the Authoring pane to explicitly discovery and add monitoring for specific Azure resources.

Also recently announced, is the integration of System Center Operations Manager (SCOM) with the Operations Management Suite (OMS)’s Service Map feature. If you’ve worked with SCOM in the past, think of it as a dynamically building Distributed Application model!

Conclusion

Although System Center Operations Manager (SCOM) is traditionally an on-premises solution, Microsoft continues to enhance this toolset with additional cloud-empowering features. Not only is there a Management Pack for monitoring Azure resources, but SCOM can also integrate with the Operations Management Suite (OMS).

So even if you haven’t embraced the new cloud-based monitoring toolsets discussed in this series, you can still utilize the tools you are already familiar with.

That finishes our tool-by-tool coverage part of this series, let’s summarize.

We’ve discussed each of these tools individually, providing a short overview of what it is, and tried to make the information more real and meaningful by providing a real-world type of example of the tool in use.

Key Takeaways

If I can leave you with some key takeaways from this series it would be this:

• Start getting into the habit of using Azure Monitor as your first point for all monitoring toolsets.
• Even if you are familiar and comfortable with the “classic” Operations Management Suite (OMS) portal, start shifting to the new Azure portal experiences.
• Deep-dive into the new Log Analytics query language, and the additional power and insights we gain from it.
• Although the Operations Management Suite (OMS) has several security solutions, start using Azure Security Center (ASC) as your first point for all security toolsets.
• Keep a close eye on Network Watcher, as just like OMS-to-Azure Monitor and OMS-to-Azure Security Center, it will become another important starting point for all network-related toolsets.

I hope you have found this series interesting and valuable. I had fun writing it, and digging into all the different monitoring toolsets of Azure, understanding how they work, and when you would use them.

Feel free to share, bookmark, tweet, etc. any of the articles in this series. And, if you have any suggestions or asks for another series (or just a one-off article), feel free to reach out to me via my contact information on the About Me page.