Azure-docs: Deploying Log Analytics Alerts within and ARM Template does not work as documented

Created on 23 Jan 2019  Â·  8Comments  Â·  Source: MicrosoftDocs/azure-docs

Creating alerts in Log Analytics using an ARM template does not work as documented.

Page Link: https://docs.microsoft.com/en-gb/azure/azure-monitor/insights/solutions-resources-searches-alerts?toc=%2Fazure%2Fazure-monitor%2Ftoc.json#alerts

The problem here is that the documented sample in the above page does not work.

The sample states that the following is needed to get an alert deployed from an ARM template:

{
            "name": "[concat(parameters('workspaceName'), '/', variables('MySearch').Name, '/', variables('MyAlert').Schedule.Name, '/', variables('MyAlert').Name)]",
            "type": "Microsoft.OperationalInsights/workspaces/savedSearches/schedules/actions",
            "apiVersion": "[variables('LogAnalyticsApiVersion-Search')]",
            "dependsOn": [
                "[concat('Microsoft.OperationalInsights/workspaces/', parameters('workspaceName'), '/savedSearches/', variables('MySearch').Name, '/schedules/', variables('MyAlert').Schedule.Name)]"
            ],
            "properties": {
                "etag": "*",
                "Type": "Alert",
                "Name": "[variables('MyAlert').DisplayName]",
                "Description": "[variables('MyAlert').Description]",
                "Severity": "[variables('MyAlert').Severity]",
                "Threshold": {
                    "Operator": "[variables('MyAlert').ThresholdOperator]",
                    "Value": "[variables('MyAlert').ThresholdValue]",
                    "MetricsTrigger": {
                        "TriggerCondition": "[variables('MyAlert').MetricsTrigger.TriggerCondition]",
                        "Operator": "[variables('MyAlert').MetricsTrigger.Operator]",
                        "Value": "[variables('MyAlert').MetricsTrigger.Value]"
                    }
                },
                "Throttling": {
                    "DurationInMinutes": "[variables('MyAlert').ThrottleMinutes]"
                },
                "AzNsNotification": {
                    "GroupIds": "[variables('MyAlert').AzNsNotification.GroupIds]",
                    "CustomEmailSubject": "[variables('MyAlert').AzNsNotification.CustomEmailSubject]"
                }
            }
        }

The first issue on this page is that the section that talks about Alerts shows the properties attributes beginning with a lower case character. However if that is done, Azure returns a TypeNotFound error. This is the first resource that I have come across that has attributes that need this casing.

However the real issue is that when deploying a similar snippet a BadJson error is received. How is the template meant to be defined to get this deploy properly?

This can be averted by changing the AzNsNotification attribute to a EmailNotification. The template will now attempt to deploy, however an error is raised later on stating that the workspace has been extended and that ActionGroups should be used instead.

I am using the API version 2017-03-15-preview.

An issue similar to this has been raised before in #13602. In this issue someone say the same problem which was fixed by MS, but it seems that it still does not work.

I appreciate that this is not a direct documentation issue, but I am not sure where to log this issue otherwise. Happy to move this to the correct repo if it needs to be.


Document details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

assigned-to-author monitorinsvc product-issue triaged

Most helpful comment

@russellseymour I have tried to reproduce the issue by using the sample template from the provided page and couldn't see any errors (as TypeNotFound, BadJson) while the deployment of the ARM template.

But looks like there are real issues with the sample template so makes sense @bwren to make necessary revisions.

Few of my observations are:

  1. To successfully deploy the ARM template, we must remove the parameters "accountName", "regionId", "pricingTier" from the template parameters file as they are not present in the template file.
  2. The parameter "workspaceName" is used in various blocks of template files as "workspacename" and in few others blocks as "workspaceName". But as per ARM template best practices (https://docs.microsoft.com/en-us/azure/azure-resource-manager/template-best-practices) it's recommended to use camel case for parameters names i.e., in this case its recommended to use "workspaceName".
  3. Same observation applies for the parameter "workspaceRegionId" as well.
  4. Redeployed the ARM template after correcting the parameters "workspaceName" and "workspaceRegionId". And then as part of post validation, couldn't see any differences in the resources that got created.
  5. After the deployment of ARM template, I couldn't post validate saved search schedule and saved search schedule action because AFAIK I couldn't find any current way (i.e., using Azure Portal / Azure PowerShell / CLI / REST API) to check saved search schedule and saved search schedule action as these features are applicable for legacy setup.

For reference, please find attached document that has few screenshots.

GitHub_Issue_23140.docx

All 8 comments

@russellseymour Thank you very much for your interest in Azure cloud services. We are currently investigating this and will take the appropriate action once the issue is well understood.

Assigning @KrishnaG-MSFT to reproduce the issue. If we are able to repro then we need to work with @bwren to revise the document.

@russellseymour I have tried to reproduce the issue by using the sample template from the provided page and couldn't see any errors (as TypeNotFound, BadJson) while the deployment of the ARM template.

But looks like there are real issues with the sample template so makes sense @bwren to make necessary revisions.

Few of my observations are:

  1. To successfully deploy the ARM template, we must remove the parameters "accountName", "regionId", "pricingTier" from the template parameters file as they are not present in the template file.
  2. The parameter "workspaceName" is used in various blocks of template files as "workspacename" and in few others blocks as "workspaceName". But as per ARM template best practices (https://docs.microsoft.com/en-us/azure/azure-resource-manager/template-best-practices) it's recommended to use camel case for parameters names i.e., in this case its recommended to use "workspaceName".
  3. Same observation applies for the parameter "workspaceRegionId" as well.
  4. Redeployed the ARM template after correcting the parameters "workspaceName" and "workspaceRegionId". And then as part of post validation, couldn't see any differences in the resources that got created.
  5. After the deployment of ARM template, I couldn't post validate saved search schedule and saved search schedule action because AFAIK I couldn't find any current way (i.e., using Azure Portal / Azure PowerShell / CLI / REST API) to check saved search schedule and saved search schedule action as these features are applicable for legacy setup.

For reference, please find attached document that has few screenshots.

GitHub_Issue_23140.docx

This content is out of date with alerts moving into Azure Monitor. I'm following up with the engineering team to see if it's going to be updated or retired.

@bwren Thanks for the quick response. Please provide the update once you hear from engineering team.

@bwren We are having a lot of issues with this similar to what @russellseymour is experiencing. We really cant move forward on this using ARM automation until the issues are sorted out.

This is out of date now that Log Analytics alerts have been moved to Azure Monitor. ARM for a log alert is available in the following article - https://docs.microsoft.com/azure/azure-monitor/platform/alerts-log#managing-log-alerts-using-azure-resource-template. We've had some confusion in what we're going to do with that solution content, but we'll most likely end up retiring the article altogether. For the moment, I'm going to put a note at the top of that article directing to the ARM that I'm referencing here.

@bwren Thanks for the update!
@russellseymour We will be closing this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

DeepPuddles picture DeepPuddles  Â·  3Comments

ianpowell2017 picture ianpowell2017  Â·  3Comments

JeffLoo-ong picture JeffLoo-ong  Â·  3Comments

bdcoder2 picture bdcoder2  Â·  3Comments

varma31 picture varma31  Â·  3Comments