Working with Azure Monitor Rest API

Before delving in to Azure monitor Rest API and powershell, let’s take a little step back. Azure monitor released in public preview a little over a year ago (September 2016). Introduced as “The built-in solution to make monitoring available for all Azure users”.
At that time I was personally all over the Operations Management Suite or OMS which is now a deprecated brand. All features from OMS is now available under “Monitoring + Management” in the Azure Marketplace.

Therefore, Azure Monitor went a bit under my radar, but when OMS shifted we started to see more and more about Azure Monitor being the one stop shop for Azure monitoring. Especially the alerting feature seems to be richer in Monitor than in Log Analytics and it is my (and others) anticipation that we will see Monitor as the default alert tool, for both metrics and activity logs.

So as part of my never-ending story, Monitoring Azure as a CSP provider. Let’s take a look at Azure Monitor and it’s REST API

We want to retrieve alert rules and incidents (alerts) programmatically, but first we create an alert rule to work with through the GUI. In th Azure portal:

At this time of writing the alert rule is bound to a specific resource. I hope we will see the ability to create rules based on resource type. ie: you want all web apps to have the same standard alert rules for response time.

Locate Azure monitor

Find your resource and metric (or you can jump straight in to alerts)

Verify your alert rule exist

Retrieve Azure Monitor alerts and incidents

From Powershell I am connecting to AAD and generating authentication header, reusing code from earlier blog post about Azure Resource health. For the purpose of this post I will focus on these two Azure Monitor API endpoints: Alert Rules РList By Resource Group and Alert Rule Incidents РList By Alert Rule.

After you have authenticated against Azure AD, and if using my previous sample you should have the following header available.

Using this header we call the alert rules endpoint to get our alert rules. Pay attention to the URL, as it requires you to specify a subscription id and the resource group name.


The output from the above should look something like this. I only have one alert configured for the resource group

id : /subscriptions/a2782f8e/resourceGroups/2017/providers/microsoft.insights/alertrules/name
name : name
type : Microsoft.Insights/alertRules
location : westeurope
tags : @{$type=Microsoft.WindowsAzure.Management.Common.Storage.CasePreservedDictionary,}
properties : @{name=No runs; description=; isEnabled=True; condition=; action=; lastUpdatedTime=2017-11-02T12:52:26.9091865Z; provisioningState=Succeeded; actions=System.Object[]}


Next we use the ID from our previus result as part of the URL to get our alert incidents

I am jumping straight in to the ‘value’ node at this point. If youre alert rule have triggered an incident it will return a result. We see the time it was activated (and resolved if it’s old), a boolean value of its status, and some information on the resource it self.

id : L3N1YnNjcmlwdGlvbnMvZTUxNGRhY2EtYTA3Ny00NGYwLTljZmEtNjBlMzRjOTk1Zjk3L3Jlc291cmNlR3JvdXBzL1NlbWluYXIyMDE3L3Byb3ZpZGVycy9taWNyb3NvZnQuaW5zaWdodHMvYWxlcnRydWxlcy9ObyUyMHJ1bnMwNjM2NDUyMjM3NjcyODMwODI2
ruleName : /subscriptions/a2782f8e/resourceGroups/2017/providers/microsoft.insights/alertrules/name
isActive : True
activatedTime : 2017-11-02T12:49:27.2830826+00:00
resolvedTime :
targetResourceId :
targetResourceLocation :
legacyResourceId :



Below I have tied everything together, using my Azure App authentication function we generate the auth header and retrieves alert rules based on user input.



Wrapping up

We now know the basic consepts on how we authenticate and retrieve alert rules and incidents from Azure Monitor through it’s rest API using Powershell. From here we can easially expand our work to create new alert rules or retrieve metrics from our resources¬†wich lets us build custom solutions on prem or any where else.

If you want to continue exploring Azure Monitoring capabilities i suggest you follow Adin Ermies series describing all the different solutions.

Hopefully I can soon provide some insights on how we are building our CSP monitoring solution in a single blog post, using the different tools mentioned in my latest posts.

Martin Ehrnst
Systems Engineer working with SCOM, OMS and Azure
IT Pro with a passion for monitoring. Working with System Center, OMS, Azure and related software and cloud services.

Direct customer experience from previously being a Technical Account Manager.

Community supporter where I try to contribute via blogging and social media.

Engage by commenting