For a clearer picture

Part 5 – Azure MP – Lessons learned

Part 5 – Azure MP – Lessons learned

I have to admit I’m not a fan.

The organisations I have worked with need version and source code control. They insist on authoring SCOM management packs via Visual Studio. They require the authoring to be peer reviewed and source code to be stored appropriately and deployed via a robust release management framework. Basically, SCOM management pack development is treated the same as any other development

1. Azure monitoring is template based. This means that a lot of these requirements are not met:
– I can’t code once in Visual Studio and deploy the same code to multiple environments. The best I can do is run a wizard in one environment and then export the MP and store it. I guess this could all be automated but it isn’t straight forward.

2. When you run the template wizard under authoring you can only run the wizard once for each subscription. This means that all your monitoring for a subscription has to be saved to the same management pack. And if someone makes a mistake or worse, accidentally deletes it, it impacts my whole Azure Monitoring.

3. The classes get created on the fly by the authoring template wizard; this makes it much more difficult to code against as you don’t know the class name until it has already been discovered.

4. The instances of the Azure Resources that are discovered don’t get user friendly names or descriptions and are difficult to decipher what they actually relate to; especially for non-specialists.

5. The resultant alerts are not user friendly and are difficult to integrate into ticketing systems.

SCOM isn’t a Cloud monitoring solution. The cloud is all about scaling on demand, elasticity, consuming resources as and when you need them and not a second longer.

SCOM doesn’t work that way. Discoveries run every few hours or even just once per day. That isn’t just a lifetime in Cloud terms; it is multiple generations. Monitoring virtual machines (IaaS) doesn’t require the Azure MP as they can be monitored as any other virtual machine given the usual requirements on connectivity and authentication. PaaS and SaaS monitoring requires something altogether more dynamic than SCOM.

So when moving to the Cloud; think about how you are going to monitor all of this transient, ephemeral resources whose lifecycles are beyond the scope of SCOM monitoring.

For Cloud monitoring from a Microsoft perspective; Log Analytics is the way forward and that is what I’ll concentrate on in a future series of articles.


Leave a Reply

Your email address will not be published. Required fields are marked *