MSOMS Archives - Page 2 of 6

Azure monitoring, connecting the dots

04/01/201807/01/2025
by Martin Ehrnst

Azure Monitoring

Welcome to the continuing saga on how to monitor your customers Azure tenants being a service provider. Previously we have covered how to authenticate against Microsoft CSP, using Azure Resource Health API with Powershell and more.

This post is all about connecting the dots. We are far away from finished, but things are moving in this project and at the time of writing, we have two separate projects going.
The first one is focused on creating a single pane of glass for all our customers’ workflows. This involves custom coding and management pack development for SCOM. The second one, which this post will cover, is how we have designed each customer tenant and how we plan to use built-in Azure monitoring functionality.

Customer tenant setup

Working for a service provider we need to construct Azure tenants by taking in to account that we are going to manage cloud resources, so using many cloud features makes a lot of sense. The challenge ist that we always have to think about how we can integrate with an existing deployment and work with monitoring solutions on premises.

When we first started out this project we looked in-to what have been done before, and most of the examples we found wouldn’t scale to our requirements or used OMS/Log Analytics only. We wanted to use our SCOM environment for alert handling, dashboard and platform health as SCOM is already integrated with customer portals, CMDBs and more. We will discuss more on that later in this blog post.

Things are moving very fast in Azure, we have changed our inital customer tenant setup twice before we found a structure we believe is future friendly.
When a customer sign up for an Azure Subscription, we populate their tenant with a default monitoring resource group and a OMS/Log Analytics workspace (LA). Along with the default LA workspace we add the Azure Activity Log, Web Apps and Office 365 solutions as standard.
For “bread and butter” type of Azure Resources, such as compute and web apps we setup the same type of monitoring regime we provide for on-premise resources, but we use alerts in Azure Monitor. This approach works well for Azure Resources which do not have existing, custom Log Analytics solutions and searches to provide health state. This means that VMs deployed using our custom ARM template will also include Monitor Alerts such as “CPU Usage % above 95” and “Web app response time above x”. In conjunction with Azure Monitor we use Azure Resource Health wich will provide health state data regardless of resource type, and custom alerts in monitor or Log Analytics.

Below is a (not so detailed) illustration on our default tenant.

SCOM and Azure Integration

We use System Center Operations Manager (SCOM) as our main monitoring platform for operating systems and applications. As SCOM is already integrated with our ticketing system, CMDB and other internal tools it seems reasonable to provide insight to application and workloads running in Azure on the same monitoring platform. That way we optimally can provide a single pane of glass in to the on premise, hybrid and cloud only workloads.

Azure Management Packs

To get monitoring data in to our on prem SCOM we looked in to two major options.

Option #1:
The official Azure Management pack from Microsoft. he official MP discovery process/adding new tenants cannot be automated. It relies on a GUI where you sign it to the tenant etc. neither does it provide any “umbrella” functionality for companies enrolled in the CSP program.

Option #2:
Daniele Grandini’s Azure/OMS management pack. Daniele’s management packs provide insight to Log Analytics, Azure Backup and Automation, but relies on the official Microsoft MP for initial discovery. Daniele’s management packs focuses on the solutions within the “Monitoring + management” (formerly known as OMS) space in Azure. Since much of the alerting features from OMS/Log Analytics are moving to Azure Monitor, I reached out to Daniele and asked if he had looked in to creating a management pack for that. He had looked a little in to it, but was also concerned about the rapid changes. Unfortunately this MP is bound to the initial discovery from the official Azure MP. A service provider managing several hundred tenants (and growing) cannot have that limitation. I hope to be able to help Daniele with the upcoming Azure Monitor MP.

Here’s where our problems started. I wanted to discover all our manged tenants automatically. Take advantage of being a CSP we set out to create our own management pack(s). I have create one management pack for the CSP platform that integrate with the Partner Center API (see example in this blog post) to do the initial discovery. Tenants and subscriptions are populated as objects in SCOM. Further, using a Partner Center Managed Application we can pre-consent access to all managed tenants. That means we can use this applications credentials to authenticate against each of our managed tenants, by-passing the limitation within the official management pack. All resources are the created as object with a hosting relationship to resourcegroup, subscription and tenant. Basic monitoring is done through Azure Resource Health API.

Below is a diagram showing the structure of our CSP management pack

Credentials used to authenticate against partner center and the Azure tenants is provided through SCOM RunAs accounts.

Our next step in SCOM and Azure integration is to create an Azure Monitor Management pack that reference the CSP management pack. This will provide the more enriched monitoring provided by Azure Monitor. Due to many recent changes to the monitor platform I have decided to wait and see where we end up. At the time of writing Azure Monitor have two new alert features in preview and none of their API’s are officially documented – i will come back with examples when I have something tangible.

Summary

To provide effective monitoring as a service provider for customers which span on-prem and cloud environments, we recommend the following:

For “bread and butter” monitoring use a combination of SCOM and Azure Monitor
If in the CSP program. Create a management pack using CSP rest API’s (hopefully I can share our MP later) combined with a custom Azure Monitor MP
Not a CSP? Look in to a combination of the official MP and Daniele’s management packs.
Deploy Log Analytics as default to all tenants. This will give you an advantage when customers require custom solutions and log sources.

Wrapping up

All service providers do their monitoring differently, but hopefully you have gotten some ideas on how you can do yours. Our solution is far from being finished, but I feel we have a structure that are future proof (the modern type of future). Hopefully we can share the SCOM management packs later, but feel free to contact me on specifics. Just remember I cannot share the MP itself at this point in time.

Until further notice, this will be the closing post on how you can do Azure Monitoring as a service provider.

Big thanks to Kevin Green and Cameron Fuller for providing feedback and to reach out to other community friends on my behalf.

Uncategorised

Merry Christmas 2017

21/12/201707/01/2025
by Martin Ehrnst

Christmas and new year is just around the corner. I am wishing all my readers and followers a merry christmas, and a happy new year.

highlights from 2017:

14000 blog visitors, around 40 a day
22 published blog posts
Top Post: Web API for System Center Operations Manager with 1300 views
- SCOM web api have almost 200 downloads and confirmed 4 installations in production.
2 Conferences attended
- Presenting at one. Definitely one of the coolest things from 2017

Thanks to all colleagues, community members, friends and others who have helped out during the year.

You should expect the blog to go a bit dead the next weeks, but who knows, maybe I will finish some of the drafts lying around.

Automation

Activate Webasto diesel heater using OMS and Azure functions

03/10/201707/01/2025
by Martin Ehrnst

Looking at the above picture snow and winter is pretty awesome, but when you have to fire up your car outside your cabin in -15c (5f) you wish for summer. Not only is it extremely hard for your engine, but it’s also ridiculously cold to get inside the car! That’s why many cars in Norway are equipped with preheaters. A unit you can activate before starting or entering the car, heating up the engine (and in many cases the interior as well).
Just to put some numbers down, average temperature in Oslo January 2017 was -4.3, and coldest -12.6.

My child carrier, a Range Rover Sport, (one of Britains fines engineering that never fails) is equipped with a Webasto pre heater and controlled remotely by SMS command or an app. Communication is using WBUS, Webasto’s own language.

My goal in this post is to use data from the OMS Weather Data solution and Azure functions to automatically start my Webasto heater based on the observed temperature. I have to say, using the app directly way easier, but this is a very good opportunity to explore and play with cars, azure and automation.

Starting the heater

Many of these heaters and apps only communicate using SMS commands, but my heater controller can use internet connection as well, meaning there is an API of some sort it’s communicating with.

Using fiddler I found out how the app was communicating, replicating it using Powershell I ended up with this as a simple function to send commands to my heater. Typical commands are “cmd_heater_status” which asks for current status, and “cmd_time1:30,start” that starts the heater for 30 minutes.

To be honest, I wasn’t very pleased with the security here, but that’s something I will notify the company who make these controllers about.

Below is a typical output after requesting heater status.

heater : 1 gsm : 7 voltage : 12.0 h_temp : 25 flame : 0 date : 2017-10-1 19:13:9 valid : 1 status_date : 01/10 status_fdate : 01.10.2017 status_time : 21:13:09

Creating the Azure Function

After we have the basic functionality in place, we can add some logic to our script and create an Azure Function out of it. I have created a basic Powershell function below that accepts two input parameters. TempLow the temperature you have to be below to fire the heater, and heatingMinutes which is the number of minutes the heater will run.

The rest of the script is using our function above to request statuses and act upon our input and the heater response. I had to add sleep time within the script so that the Webasto controller had time process my commands.
Parameters like email-address and heaterId are defined as function environment variables

OMS / Log Analytics setup – query and alert.

Using data from the weather solution I created together with Cameron Fuller i created the following query to alert when observed temperature in Oslo is below a certain degree. This search is based on the new query language, Kusto. I reccommend everyone (including my self) to take a look at this Kusto cheet sheet.
YRno_CL | where LocationName_s == "Oslo" and TimeGenerated > ago(2h) | summarize AggregatedValue = avg(ObservedTemp_d) by bin(TimeGenerated, 15m), LocationName_s

Create an metric based alert based on the above query.

To kick off our Azure Function we set the alert to send a webhook with a custom json payload looking like this: (yes testing values)
{ "tempLow": "59", "heatingMinutes": "40" }

The test says webhook is sent successfully, and our function log confirms 🙂

Calm down John Snow, let winter come.

Azure monitoring, connecting the dots

Azure Monitoring

Customer tenant setup

SCOM and Azure Integration

Azure Management Packs

Summary

Wrapping up

Share this:

Merry Christmas 2017

highlights from 2017:

Share this:

Activate Webasto diesel heater using OMS and Azure functions

Starting the heater

Creating the Azure Function

OMS / Log Analytics setup – query and alert.

Share this: