Azure/azure-monitor-baseline-alerts

[Question/Feedback]: Using Custom tags to enable/disable monitoring

Opened this issue · 3 comments

Check for previous/existing GitHub issues

  • I have checked for previous/existing GitHub issues

Description

In the documentation for Disabling Policies there is a part about MonitorDisable parameter that says the following:

This is easily adjusted to use existing tags, for example you could configure the parameter with the tag name “Environment” and tell it to deploy only if the tag value equals “prod”, or when the tag isnt equal to “dev”.

However, looking at the source code in the repo it is not clear to me how to change this, as the MonitorDisable is hardcoded in each Deploy file and 282 times in the policies.json file. It might be easy to customize, but as someone who's just starting with using AMBA it's not clear to me by just reading the documentation.

Hello @MarcoJanse,
thanks for your feedback. At the moment the parameter is not exposed in the Param file and so it must be changed in the code. As a quick workaround you can create that tag on the resource you want to disable the monitoring for. In the meantime we will work on your feedback to either make the parameter name a choice or to align the documentation.

Thanks,
Bruno.

It would be really useful if we could specify multiple tags - Azure Databricks compute clusters spin up their own resources, and with a Deny policy so we can't change the tags on them. But it does add its own tags such as ClusterID, ClusterName, databricks-instance-name, DatabricksEnvironment etc. As these clusters can have short lifetimes, we get a heap of Resource Unhealthy alerts when they are down or deleted. Being able to check for MonitorDisable or (custom tag) would solve this problem, we could simply add databricks-instance-name to the list of tags to exclude alerting on.

edit: in databricks, we can specify tags to deploy the clusters with, this is just an example for things where perhaps it's more onerous

Hello @lansalot ,
sorry for replying late. We added this feature request to our backlog. However, we cannot an ETA for the release at the moment.

Thanks!