Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"azurerm_monitor_scheduled_query_rules_alert_v2" - "skip_query_validation" Not Working as Expected #28293

Open
1 task done
efettero opened this issue Dec 16, 2024 · 1 comment
Labels
service/monitor upstream/microsoft/blocking-api-issue This label is applicable when there is a bug on the Azure API that is blocking. v/4.x waiting-response

Comments

@efettero
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Terraform Version

1.10.2

AzureRM Provider Version

4.14.0

Affected Resource(s)/Data Source(s)

azurerm_monitor_scheduled_query_rules_alert_v2

Terraform Configuration Files

data "azurerm_subscription" "current" {}

resource "azurerm_resource_group" "example" {
  name     = "rg-example"
  location = "eastus"
}

resource "azurerm_monitor_action_group" "example" {
  name                = "ag-example"
  resource_group_name = azurerm_resource_group.example.name
  location            = "global"
  short_name          = "example"

  email_receiver {
    name                    = "example"
    email_address           = "[email protected]"
    use_common_alert_schema = true
  }
}

resource "azurerm_monitor_scheduled_query_rules_alert_v2" "disk_space_low" {
  resource_group_name = azurerm_resource_group.example.name
  location            = "eastus"
  name                = "Virtual Machine - Disk Space Low"
  display_name        = "Virtual Machine - Disk Space Low"
  description         = "Monitors the percentage of disk space available, per disk, on Virtual Machines."

  scopes                = [data.azurerm_subscription.current.id]
  evaluation_frequency  = "PT1H"
  window_duration       = "PT1H"
  severity              = 2
  skip_query_validation = true 

  action {
    action_groups = [azurerm_monitor_action_group.example.id]
  }

  criteria {
    metric_measure_column   = "min_CounterValue"
    operator                = "LessThanOrEqual"
    threshold               = 6
    time_aggregation_method = "Minimum"
    resource_id_column      = "_ResourceId"

    query = <<QUERY
      Perf
      | where ObjectName == "LogicalDisk" or ObjectName == "Logical Disk"
      | where CounterName == "% Free Space"
      | where InstanceName != "_Total" and InstanceName != "total"
      | summarize min(CounterValue) by Computer, InstanceName, _ResourceId
    QUERY

    dimension {
      name     = "Computer"
      operator = "Include"
      values   = ["*"]
    }

    dimension {
      name     = "InstanceName"
      operator = "Include"
      values   = ["*"]
    }

    failing_periods {
      minimum_failing_periods_to_trigger_alert = 1
      number_of_evaluation_periods             = 1
    }
  }
}

Debug Output/Panic Output

│ Error: creating Scheduled Query Rule (Subscription: "<subscripition-id>"
│ Resource Group Name: "rg-example"
│ Scheduled Query Rule Name: "Virtual Machine - Disk Space Low"): unexpected status 400 (400 Bad Request) with error: BadRequest: 'where' operator: Failed to resolve table or column expression named 'Perf'. A semantic error occurred.. The request had some invalid properties Activity ID: <activity-id>.
│ 
│   with azurerm_monitor_scheduled_query_rules_alert_v2.disk_space_low,
│   on azr.tf line 19, in resource "azurerm_monitor_scheduled_query_rules_alert_v2" "disk_space_low":
│   19: resource "azurerm_monitor_scheduled_query_rules_alert_v2" "disk_space_low" {
│ 
│ creating Scheduled Query Rule (Subscription: "<subscription-id>"
│ Resource Group Name: "rg-example"
│ Scheduled Query Rule Name: "Virtual Machine - Disk Space Low"): unexpected status 400 (400 Bad Request) with error: BadRequest: 'where' operator: Failed to resolve table or column expression
│ named 'Perf'. A semantic error occurred.. The request had some invalid properties Activity ID: <activity-id>.

Expected Behaviour

Setting skip_query_validation to true should deploy the alert rule regardless of if the query returns any results or errors.

Actual Behaviour

This subscription does not have the Perf table yet. Upon apply the configuration with skip_query_validation = true, it errors with Failed to resolve table or column expression named 'Perf'.

Steps to Reproduce

  1. Target a subscription that does not have the Perf table
  2. terraform apply

Important Factoids

No response

References

No response

@teowa
Copy link
Contributor

teowa commented Dec 17, 2024

Hi @efettero , thanks for submitting this.

This seems to be an Azure API issue. There is a Q&A that mentions skip_query_validation might conflict with evaluation_frequency=PT1M. Additionally, the Azure documentation highlights some limitations for one-minute frequency.

From my local tests, the provided configuration with evaluation_frequency set to PT1H can be created successfully. Could you check if your configuration works with this adjustment?

@rcskosir rcskosir added waiting-response upstream/microsoft/blocking-api-issue This label is applicable when there is a bug on the Azure API that is blocking. labels Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
service/monitor upstream/microsoft/blocking-api-issue This label is applicable when there is a bug on the Azure API that is blocking. v/4.x waiting-response
Projects
None yet
Development

No branches or pull requests

3 participants