Design and deploy Application Insights Alert Rules with Azure Bicep, by Tobias Zimmergren

Create Azure Monitor Alert Rules with Azure Bicep

Tobias Zimmergren
Tobias Zimmergren
ScriptRunner Webinar

Previously, I wrote a well-received popular blog post about Getting started with Azure Bicep. In that post, I also explained how you could automatically convert your JSON ARM templates into Bicep using the Bicep CLI.

Regularly, I see new Bicep templates and other code being shared - but seldom the process of how they got there. I sometimes end up in discussions with businesses about how they can configure alerting, deploy their own alert rules, and perform other relevant tasks on their infrastructure - usually as IaC (Infrastructure as Code). ย 

In this post, we'll explore two things:

  • A Bicep Alert Rule (the results)
  • Design a new alert rule, then export it (getting to the results)

We will look at what a simple rule can look like, but also, and perhaps more importantly, how we got there.

Get the Bicep code:

Design an Azure Alert Rule in the Azure Portal

There is no better way to understand the impact of your alert rules than to use the Azure Portal when designing new rules. You can immediately see the rule's effect and whether it would've triggered as expected with the historical data you have.

To me, this is a killer feature of Azure Monitor.

For the sake of this post, I assume you already know how to create the alert rule. If you don't, the link above will guide you.

When defining the signal logic for the alert rule, the UI is tremendously helpful. From here you can immediately see that in the last few hours, there's been several points where the alert would have triggered - so you can verify that the logic works.

To discover 4xx anomalies, we can define a new Alert Rule in Azure Monitor.

When the rule has been defined, you can go to "Alert Rules" in Azure Monitor, and click on your new rule, then "Properties":

View the properties of an Alert Rule in Azure Monitor.

From there, you can easily export your Alert Rule as an ARM template. The content is JSON, and will be the base for our new Bicep alert rule template.

ARM JSON content exported from an Azure Alert Rule

Convert the ARM alert rule to Bicep

You can convert the newly exported JSON template into Bicep. When the conversion is done, we can make any modifications as we see fit in the code and commit them to our code repository.

I previously wrote about how to accomplish that in the post Getting started with Azure Bicep.

Here's the quick recap of how to convert a JSON file to Bicep with the Bicep CLI:

az bicep decompile -f theARMfile.json

A Bicep Alert Rule

When you have converted the ARM template into a Bicep file, you should make any necessary modifications for your specific situation - then you're ready to deploy it.

I have modified the names of parameters and other values to make it work for this blog post, and at the same time work to deploy to any of my Azure subscriptions.

This example is a fairly simple Bicep file that defines an Alert Rule for my Azure resources. It does assume that there is already a Web App to monitor, and an existing Action Group. You can, of course, create those using Bicep as well. However, that's outside of the scope of this post.

param alertRuleName string = 'Web App has 4xx anomalies'
param webAppResourceId string = 'THE WEB APP RESOURCE ID'
param actionGroupResourceId string = 'AN EXISTING ACTION GROUP RESOURCE ID'

resource metricalerts_PROD_WEU_4xx_Anomalies 'microsoft.insights/metricalerts@2018-03-01' = {
  name: alertRuleName
  location: 'global'
  properties: {
    severity: 1
    enabled: true
    scopes: [
      webAppResourceId
    ]
    evaluationFrequency: 'PT5M'
    windowSize: 'PT5M'
    criteria: {
      allOf: [
        {
          threshold: 1
          name: 'Metric1'
          metricNamespace: 'Microsoft.Web/sites'
          metricName: 'Http4xx'
          operator: 'GreaterThan'
          timeAggregation: 'Total'
          criterionType: 'StaticThresholdCriterion'
        }
      ]
      'odata.type': 'Microsoft.Azure.Monitor.MultipleResourceMultipleMetricCriteria'
    }
    autoMitigate: true
    targetResourceType: 'Microsoft.Web/sites'
    actions: [
      {
        actionGroupId: actionGroupResourceId
        webHookProperties: {}
      }
    ]
  }
}

Clean, simple, and using Bicep.

Usually, most code examples end here - but that leaves many wondering how to get to that point, and that's really what I want to explore next.

AzureBicepAzure MonitorApplication Insights

Tobias Zimmergren Twitter

Hey, I'm Tobias! I write about my experiences in designing, architecting, securing, and operating distributed cloud services. Nice to meet you ๐Ÿ‘‹

Reactions and mentions