Azure Monitor for service providers – The basics

Last year at Microsoft Ignite in Orlando, I talked about Azure Monitor, and how we replaced our System Center Operations Manager (SCOM) with it. We are in some ways a Managed Service Provider, and I keep getting questions from these type of companies, about how to move from SCOM to Azure Monitor. This post is focusing on those service providers.
Since my presentation at Ignite, I’ve deployed this at other service providers, and developed more features. Through those project, I’ve learned quite a lot, and I want to share all of that. I don’t know how many posts this will take, but I’ll try to write 1-2 posts a week about it, and maybe do some demo videos, let’s see what time brings..

First of all: SCOM and Azure Monitor are two completely different products, and very different ways of monitoring. There is some similarities though, for example they use the same agent for servers: Microsoft Monitoring Agent.
While SCOM has a ton of management packs offered from Microsoft and other vendors. Azure Monitor is quite different. You can’t just download a management pack to monitor Exchange Servers or Veeam Backup, they’re simply not there. Actually, we don’t really have the concept of management packs in Azure Monitor. Previously when it was named Operations Management Suite (OMS), we had “Solutions”. While they’re not quite like management packs, the concept was somewhat the same: collect data, and alert if something pre-defined happens.

Another difference is that Azure Monitor is paid for, by how many GBs of data you ingest, and how long retention you want. On top of that, you pay for each alert you define, and the notifications that alert triggers. As you can see this can get a little complicated, but I’ll go into more details in another post.
One great thing about the payment method is that you can finally split the cost of each customer. That would be quite impossible when using a multi-tenant SCOM. With Azure Monitor you simply create a subscription for each customer. That was something we really missed in our SCOM environment.
Oh, and.. We actually saved quite a lot of money by moving to Azure Monitor… And, bonus! We don’t have to maintain servers, update SQL, keep track of SCOM updates etc. That’s a lot of time saved, and I bet your boss would like that too, so you can spend the time developing your monitoring offer instead.

As part of this transition, we changed the name of our offering from “solvo it monitoring” to “solvo it management” – not because we don’t monitor anymore, but because we gained so many new great features, to help customers manage their environment. A popular approach, at least among our customers, to patching servers, is to use System Center Configuration Manager (SCCM). When we’ve enrolled our customers in Azure Monitor, a free and very well functioning Patch Management solution is clicks away. So that is now part of our monitoring management offer.

Here you got the basics, in my next post I’ll dive into the architecture and building blocks we used to create a super quick deployment of new features and to new customers.

3 comments

  1. Really looking forward to upcoming blog posts. We’re a MSP and are looking into Azure Monitor for our customers. In general for your customers, do you create a separate Subscriptions for each Customer and a Log Analytics workspace for each Customer in your or customer’s tenant?

    Like

    1. One subscription and workspace per customer, in their own tenant with access through lighthouse. We’re CSP and create the subscription for them.

      The next post we be about that 🙂

      Like

Leave a Reply