Are there any nested loop workarounds?

[alexwhitmore]

I am in the process of writing 2 alerts for various app services (4 function apps, and one web app). Originally I have it set up as one file, metric-alerts.bicep where I have the parameterized resource:

resource dealsMetricAlerts 'Microsoft.Insights/metricAlerts@2018-03-01' = {
  name: metricAlertsName
  location: 'global'
  tags: {}
  properties: {
    description: description
    severity: severity
    enabled: enabled
    scopes: scopes
    evaluationFrequency: evaluationFrequency
    windowSize: windowSize
    targetResourceRegion: targetResourceRegion
    criteria: {
      'odata.type': 'Microsoft.Azure.Monitor.SingleResourceMultipleMetricCriteria'
      allOf: allOf
    }
    actions: [
      {
        actionGroupId: actionGroupId
      }
    ]
  }
}

Shown below, in my main bicep file I consume the resource as modules, and for each alert I have (in my case I have a simple 403 & 500 implementation) I need to create a new module:

// App Service Names
var appServices = [
  'dda-webApp'
  'dealservice-fnapp'
  'itemdata-fnapp'
  'refdata-fnapp'
  'userprofile-fnapp'
]

module appServicePlan403Errors '../modules/management/metric-alert.bicep' = [for appService in appServices : {
  name: 'asp_${appService}-403Error'
  params: {
    metricAlertsName: 'AppService_${appService}_403Error' 
    actionGroupName: actionGroupName
    description: 'Alert fires whenever the App Service throws a 403 error'
    evaluationFrequency: 'PT5M'
    severity: 2
    windowSize: 'PT15M'
    scopes: [
      resourceId(resourceGroup().name,'Microsoft.Web/sites', 'gbt-${env1}-${env}-${location}-${appService}')
    ]
    allOf: [
      {
        name: 'AppService_${appService}_403error'
        metricName: 'Http403'
        dimensions: []
        operator: 'GreaterThan'
        threshold: 0
        timeAggregation: 'Count'
      }
    ] 
  }
}]

module appServicePlan500Errors '../modules/management/metric-alert.bicep' = [for appService in appServices : {
    // Logic for the 500 errors
}]

The above implementation works and will generate my two alerts for all 5 app services however, I've been looking into trying to create a less verbose implementation. I keep my parameterized resource in metric-alerts.bicep, but added a parameter file:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "alertConfig": {
      "value": {
        "metricAlerts": [
          {
            "name": "403ErrorTest",
            "params": {
              "metricAlertsName": "AppService403ErrorTest",
              "actionGroupName": "actionGroupName",
              "description": "Alert fires whenever the App Service throws a 403 error",
              "evaluationFrequency": "PT5M",
              "severity": 2,
              "windowSize": "PT15M",
              "allOf": [
                {
                  "name": "403errorTest",
                  "metricName": "Http403",
                  "dimensions": [],
                  "operator": "GreaterThan",
                  "threshold": 0,
                  "timeAggregation": "Count"
                }
              ]
            }
          },
          {
            "name": "5XXErrorTest",
            "params": {
             // 500 Error parameters
            }
          }
        ]
      }
    }
  }
}

I then re-write the module in main.bicep to loop through my parameter values, and if I hard-code the name of the app service it will create the two alerts for that service:

module dealsMetricAlerts '../modules/management/metric-alert.bicep' = [for (alert, index) in alertConfig.metricAlerts: {
  name: alert.name
  params: {
    metricAlertsName: alert.params.metricAlertsName
    actionGroupName: actionGroupName
    description: alert.params.description
    evaluationFrequency: alert.params.evaluationFrequency
    severity: alert.params.severity
    windowSize: alert.params.windowSize
    allOf: alert.params.allOf
    scopes: resourceId(resourceGroup().name,'Microsoft.Web/sites', 'gbt-${env1}-${env}-${location}-dda-webApp')
  }
}]

Of course, the goal is to create 2 alerts for all 5 app services so I switch up my scopes param to:

scopes: [for appService in appServices: [
    resourceId(resourceGroup().name,'Microsoft.Web/sites', 'gbt-${env1}-${env}-${location}-${appService}')
]]

It gives me an error saying: 'Unexpected array in scopes[0]. I know that the nested loops isn't yet supposed so I created a new variable which would hold the looping logic and assigned it to the scopes param:

var appServiceIds = [for appService in appServices: resourceId(resourceGroup().name,'Microsoft.Web/sites', 'gbt-${env1}-${env}-${location}-${appService}')]
...
scopes: appServiceIds 

This gave me an error saying that "Scopes property is invalid. Only single resource is allowed for criteria type SingleResourceMultipleMetricCriteria. If you want to create an alert on multiple resources, use MultipleResourceMultipleMetricCriteria odata.type." And if I change to MultipleResource criteria I get: Alerts are currently not supported with multi resource level for microsoft.web/sites.

I have seen several workarounds in different discussions, like #1280 on here but haven't been able to figure out how to make it work in this situation. Is there something else I should try?

[brwilkinson]

main.bicep

just loop over the app services (only) - Add this extra (outer) layer onto what you have now.

module appService 'appService.bicep' = [for (ws, index) in appServices : {

• just pass in the whole array of metricAlerts from the param file, you will use that at the next layer.

appService.bicep

for a single app service loop over the Metric alerts

module dealsMetricAlerts '../modules/management/metric-alert.bicep' = [for (alert, index) in alertConfig.metricAlerts: {

• don't pass in the scope, just pass in the wsname and then use the existing resource in the final layer

metric-alert.bicep

you just have the name of a single app service and a single alert rule

resource WS 'Microsoft.Web/sites@2021-01-01' existing = {
  name: wsname
}

// for scope just use this
    scopes: [
      WS.id
    ]

[brwilkinson]

Great, you must be pretty close. Let me know if you get stuck.

Do you think because you used the same metric alert name, it likely over wrote it each time,... so try my second last comment sample as well.

[alexwhitmore]

Hmm, so wsname = the name of each app service from main.bicep so 'gbt-${env1}-${env}-${location}-dda-webApp', 'gbt-${env1}-${env}-${location}-dealservice-fnapp, etc. This means that the dealsMetricAlerts name = 'gbt-${env1}-${env}-${location}-dealservice-fnapp-403ErrorTest' and 'gbt-${env1}-${env}-${location}-dealservice-fnapp-5XXErrorTest'.

The only difference in your second to last post be: 'gbt-${env1}-${env}-${location}-dealservice-fnapp-AppService5XXErrorTest'. Wouldn't I run into the same problem?

In an effort to try everything, I tried to make the dealsMetricAlerts name = name: '${wsname}-${uniqueString(alert.name)}'. This appears to deploy everything but I still only have 2 alerts on one of the app services userprofile-fnapp (which is the last item in the appServices array, if it's any consolation).

It makes me wonder if each of the alerts are overwriting each other as each time there's a successful deployment it's usually only one resource with the 2 alerts.

[brwilkinson]

So just to confirm..

resource dealsMetricAlerts 'Microsoft.Insights/metricAlerts@2018-03-01' = {
  name: metricAlertsName

What are your values of metricAlertsName ?

Is it something that is unique for each iteration ?

I was suggesting to ensure they are unique via

resource dealsMetricAlerts 'Microsoft.Insights/metricAlerts@2018-03-01' = {
  name: '${wsname}-${metricAlertsName}'

[alexwhitmore]

Ahh I misunderstood, I changed the name of the module and not the back end resource. It's finally working, you are a life saver. Thank you for taking the time to walk me through this, it was incredibly insightful!!

[brwilkinson]

Nice, glad you were able to work through the layers. This model works well in many different scenarios.