azure-cli: Cannot create custom metric alert via azure cli.

Note: this pertains to https://docs.microsoft.com/en-us/cli/azure/monitor/metrics?view=azure-cli-latest#az-monitor-metrics-list-definitions and https://docs.microsoft.com/en-us/cli/azure/monitor/metrics/alert?view=azure-cli-latest#az-monitor-metrics-alert-create

Describe the bug I ran

$aiid = "/subscriptions/CENSORED/resourceGroups/CENSORED/providers/microsoft.insights/components/CENSORED"
az monitor metrics list-definitions --resource $aiid

and expected to see my custom metric definitions (in custom namespaces), but didn’t found any custom metrics.

To Reproduce Log a custom metric from the source code using ApplicationIsnights. Observe you can create an alert using it it via azure portal, or view it in metrics view in AI. However, it is not listed via list-definitions, nor you can create an alert via Azure CLI using it, as it is not found.

Expected behavior The custom metric (and its namespace) to be listed, and accepted when creating an alert with az monitor metrics alert create.

Environment summary

az --version
azure-cli                         2.0.66

Additional context Confirmed the custom metrics also cannot be found via

Get-AzMetricDefinition -ResourceId $aiid

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 17 (13 by maintainers)

Most upvoted comments

If you pass an empty string to -DynamicThreshold it lets you create the criteria unfortunatelly when you create the alert rule it comes with static “default” threshold.

protected override void ProcessRecordInternal() |  
-- | --
  | {
  | if(String.IsNullOrWhiteSpace(this.DynamicThreshold))
  | {
  | List<MetricDimension> metricDimensions = new List<MetricDimension>();
  |  
  | if (this.DimensionSelection!= null && this.DimensionSelection.Length > 0)
  | {
  | foreach (var dimension in this.DimensionSelection)
  | {
  | if (dimension.IncludeValues != null && dimension.IncludeValues.Count() > 0)
  | {
  | metricDimensions.Add(new MetricDimension(dimension.Dimension, "Include", dimension.IncludeValues));
  | }
  | if (dimension.ExcludeValues != null && dimension.ExcludeValues.Count() > 0)
  | {
  | metricDimensions.Add(new MetricDimension(dimension.Dimension, "Exclude", dimension.ExcludeValues));
  | }
  | }
  | }
  | else
  | {
  | metricDimensions = null;
  | }
  | MetricCriteria metricCriteria = new MetricCriteria(name: "metric1", metricName: this.MetricName, operatorProperty: this.Operator, timeAggregation: this.TimeAggregation, threshold: this.Threshold, metricNamespace: this.MetricNamespace, dimensions: metricDimensions);
  | PSMetricCriteria result = new PSMetricCriteria(metricCriteria);
  | WriteObject(sendToPipeline: result);
  | }
  | else
  | {
  | WriteExceptionError(new Exception("Creating   criteria for Dynamic Threshold is not yet supported"));
  | }

Hi @konrad-jamrozik , @pajzo, thanks for reporting this. We are looking into this.

I’m having the same issue right now (custom application insights metric), and I think it’s sad to have a custom REST call to create this alert when all my other alerts can be created with native methods 😦

@konrad-jamrozik happy you are unblocked! I will keep this issue open to track the feature request.

@konrad-jamrozik resource create/update have been around longer than az rest, so you might try giving that a shot.

@tjprescott I managed to create a dynamic threshold alert based on my custom metric using the raw REST API. Thus, I have a workaround, but it is not ideal, as using the REST API directly requires creating, securing and managing a service principal. The az rest seems to have a broken logic for parsing body json. I have filed an issue for that: #9742. Hope that helps!

@snehithm for comment.

@konrad-jamrozik if you know the API structure, you could also use the generic resource create/update commands as an alternative to ARM templates or direct REST (also there’s a new az rest command to help with direct REST calls)

The command returns whatever the service does. Will pass along to the service for comment on whether this is the expected behavior or not.