For a clearer picture

Category: Azure

Part 2 – Azure Service Health

Part 2 – Azure Service Health

Key information
  • History is retained for 90 days at no additional cost.

Azure Service Health gives the following information:

  • Service issues – Problems in the Azure services that affect you right now.
  • Planned maintenance – Upcoming maintenance that can affect the availability of your services in the future.
  • Health advisories – Changes in Azure services that require your attention. Examples include when Azure features are deprecated or if you exceed a usage quota.
Service Issues

In the screenshot below you can see that Azure Application Insights has an issue with additional details on possible impact and the ability to track using a CR bar code straight to the Azure App on my iPhone.

I can also print out more information about the issue to pdf and there is a link that I can share with appropriate support teams and insert into my incident management solution.

Planned Maintenance

Upcoming maintenance that will impact your Azure resources.

Health Advisories

Upcoming changes to Azure which will impact your Azure deployments such as a service been deprecated. Usage quotas being breached will also show here.

Health History

And here we can see the history which goes back 3 months.

Resource Health

Resource Health allows you to select resources to view their current health state – here my IOT hub is healthy. Possible options are:

  • Healthy (with any events of the last 24 hours available to view)
  • Unavailable
    • Platform events triggered by Azure infrastructure
    • Non-Platform events triggered by end users e.g. shutting down a virtual machine.
  • Degraded if there are performance issues but the resource is available

Health Alerts

These are off limits for my mini-series as they will incur charges. But I’ll cover alerting in a future article and it obviously makes sense to make use of this functionality.

Part 1 – Azure Monitoring for free

Part 1 – Azure Monitoring for free

Yes; free. No gimmicks. No dodgy sales calls. No cracked license keys. Totally free Azure monitoring from Microsoft themselves.

OK. Let us start off by agreeing what we mean by free. When you buy a car you expect to get the wheels, the steering wheel and the brakes as well as many other components as part of the overall cost of the car. Imagine going to drive away from the forecourt just as the dealer takes the wheels off and tells you they cost extra. That wouldn’t be cricket. And it wouldn’t be much of a car either.

Same idea with Azure. When you “buy” a resource; you get some monitoring functionality as part of the cost of the resource. That is what I mean by free. Although the grammar guardians mightwell prefer me to say “at no additional cost” it doesn’t sound so catchy as a title.

At Ignite 2018 Microsoft announced a re-imagining of the Azure Portal and they did a great job of it. What had become a slightly confusing collection of monitoring options suddenly had a much more intuitive layout.

But what might not be entirely clear from the portal is what is free and what you really do need to pay for.

That is where this series of articles comes in. To ensure that you don’t accidentally enable functionality that incur costs that neither you, nor your bosses, expect.

Hopefully it is good news that as soon as you start using Azure, Azure Monitor starts recording what activities are taking place against the resource and providing a base level of performance metrics for that resource. Note – this is the Cloud. Everything is subject to change at very little notice and, when it involves increasing prices, in incredibly small print on obscure pages. This series is correct of October 5th, 2018. Please let me know if you spot something is out of date and I’ll amend it. Thanks.

So we’ll be looking at:

  • Service Health – which highlights problems with Azure Services that impact you now
  • Activity Logs – which record when resources are created or modified
  • Metrics – which tell you how the resource is performing and the resources that it’s consuming.
  • Lessons Learned.

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.

Part 4 – Deploying the SCOM Azure Management Pack

Part 4 – Deploying the SCOM Azure Management Pack

Download details

The latest version of the Azure Management Pack is available here.

I’ll run through installing the Azure Management Pack and carrying out the configuration which will involve:

  • Configuring the connection to Azure
  • Running the Authoring Template wizard to configure the monitoring

So having downloaded the MP, read the management pack guidelines and ensured that I have the following complete:

  • Created a Resource Pool for Azure Monitoring
  • Ensured the Management Servers (or Gateway Servers) that are in the Resource Pool are added to the resource pool, have internet connectivity and .Net Framework 4.5.2 installed
Extract Management Pack

I’m ready to go. Lets extract the Management Pack by running the .msi

Accept the license agreement.

Location to extract to:

And go ….

And finish …

And we’ll see 2 Management Pack bundles that we need to import to SCOM.

Let’s import them:

Configure Management Pack Administration details

And then start the Azure configuration process. You’ll notice that on the Administration blade; there is now an Azure icon.

And then choose to add an Azure subscription. The first question you will get is how to authenticate to Azure.

A User Principal Name (UPN) is simpler to configure, but it does not work when multi-factor authentication is enforced.

A Service Principal Name (SPN) works in any environment and allows assigning permissions in a more flexible way. Using a service principal allows the management pack to be used in environments with multi-factor authentication. Ideally you should create the Service Principal Name ahead of deployment but I’m going to take the lazy route for this demonstration and let the configuration wizard create it on the fly.

More on SPNs here

I don’t of any reason why you would need to change the Azure endpoints so leave these on the defaults.

And then select auto-created SPN and enter the details requested.

Then click Add Subscription to start the configuration of the subscription:

Confirm that it has worked:

And then select the SCOM Resource Pool that will be responsible for the Azure monitoring. Note that the Management Servers or Gateway Servers in the resource pool do not need direct internet connectivity; there is the option here to configure communication via a proxy.

You’ll be shown a list of subscriptions to choose to monitor. I’ve only got the one so will just select that.

And that is the Administration configuration complete. At this moment we have no monitoring in place. We still need to run the authoring template wizard. But we have the framework in place to start monitoring.

Azure Monitoring Template Wizard

Sadly you can only run the wizard once per subscription which means that you can’t slice and dice your Azure monitoring into more granular logical management packs.

Lets’ run the wizard:

Enter a Name and Management Pack to save the configuration into:

Select the subscription and do a full Azure scan. Take note of the comments at the bottom of the window; a full scan can take 1 to 2 hours for 1000 Azure resources. After the initial full scan you can just do refreshes but I am concerned about enterprise scalability.

You then get a list of all the discovered Azure resources and can select the items that you want to monitor. I’ve just selected my Microsoft.insights resources.

  • Alert Rules – I’ll look at in the next article in this series
  • Components – this is the Azure Resource Name (top level – ping-SCOM_Prod1)
  • Web Tests – the actual URL tests themselves
    • If you want to exclude specific Azure Resources you can do so here:

      Select the data you want SCOM to collect. Be aware that the URL tests just collect the top line item “Test Duration” (which equates to response time) so even though you might select all the performance counters; you won’t be able to actually collect them.

      You can also select to alert on conditions; such as Test Duration > 1200 milliseconds.

      Once you click Finish; you’ll see a Microsoft Azure folder on the Monitoring blade and you’ll be able to see the performance metrics and the Resource State:

      Performance View

      State View

      There naming convention which includes Azure subscription id and Azure Resource Type makes it very difficult for users to easily understand what is being monitored.

      Alert View

      As you can see; we do get alerts when thresholds are exceeded but the alerts are somewhat cryptic. They are not user friendly and integrating with ticketing systems will be challenging.