Skip to main content

Resource Monitor

You can provide configuration to Snowflake Object Lifecycle Engine for the following operations with resource monitors:

  • Manage the lifecycle of new and existing resource monitors
  • Manage the lifecycle of cloned resource monitor
  • Manage grants of resource monitor

Usage​

resource_monitors:
  <resource-monitor-name>:
    <configuration-key>: <value>
    grants:
      <privilege>:
        - <role-name>
        - <role-name>

Supported parameters​

The engine supports the parameters listed below.

Configuration KeyRequired/OptionalData Types and ValuesDescription
credit_quotaOptionalIntegerThe number of credits allocated to the resource monitor per frequency interval. When total usage for all warehouses assigned to the monitor reaches this number for the current frequency interval, the resource monitor is considered to be at 100% of the quota.
Note: Avoid setting credit quota to 0 because it will be treated as null in Snowflake, and this will result in an infinite credit quota.
deletedOptionalBoolean: True enables deletion prevention, False does nothingSpecifies what objects are allowed to be deleted
end_timestampOptionalString: Must be a valid date or timestampThe date and time when the resource monitor starts monitoring credit usage for the assigned warehouses. See End Timestamp Usage for resource monitor.
environmentOptionalStringSpecifies the environment in which the resource monitor is managed. Regex can be provided as well.
frequencyOptionalString: DAILy, WEEKLY, MONTHLY, YEARLY, NEVERThe frequency interval at which the credit usage resets to 0
grantsOptionalMap: See Supported Resource Monitor Grants to RolesList of Privileges and Roles to which privileges are granted to on the current Resource Monitor
manage_modeOptionalEnumeration: all (default), none, grantsConfigures what properties to manage for the resource monitor.
See Changing Manage Mode before changing the value.
namespacingOptionalString: both (default), prefix, suffix, noneSpecifies whether Prefix or Suffix or both are to be added to resource monitor name
notify_triggersOptionalArray/List of IntegersA list of percentage thresholds at which to send an alert to subscribed users
notify_usersOptionalArray/List of StringsSpecifies the list of users to receive email notifications on resource monitors.
Note: When configuring users using notify_users, only users with verified email addresses can be included.
set_for_accountOptionalBooleanSpecifies whether the resource monitor should be applied globally to your Snowflake account.
Caution: resource_monitors set for account cannot have any warehouses referencing it.
start_timestampOptionalString: Must be a valid Date or timestampThe date and time when the resource monitor starts monitoring credit usage for the assigned warehouses. See Start Timestamp Usage for resource monitor.
suspend_immediate_triggersOptionalArray/List of IntegersA list of percentage thresholds at which to immediately suspend all warehouses
suspend_triggersOptionalArray/List of IntegersA list of percentage thresholds at which to suspend all warehouses

Timestamp​

As per Snowflake Docs, the start_timestamp and end_timestamp parameters support valid timestamps as values — they only support DATE (YYYY-MM-DD) and cannot be created with a complete timestamp (YYYY-MM-DDTHH:MM:SS). When setting the parameter to any valid timestamp that has time mentioned in it, this leads to an SQL compilation error with the message Invalid date/time format string. This error occurs while creating as well as updating a Resource Monitor.

To bypass this error, a valid Date must be provided when creating or updating the Resource Monitor. This Date is converted to its timestamp equivalent after creation or update.

This leads to another issue when managing the resource with the Snowflake Object Lifecycle Engine engine. Each time a pipeline is run, the engine would compare the two values. The configuration defines a Date while the local state has a timestamp present in it. As the values are not similar(Date is not equal to timestamp although their values are equivalent), the engine determines that the resource monitor has to be updated. This leads to a replacement of the resource monitor (start_timestamp and end_timestamp lead to the replacement of the object), each-time a pipeline is run.

This replacement could be avoided if, after the creation or update of the resource monitor, the values of start_timestamp and end_timestamp are set to timestamp.

Example​

Initial Configuration:

resource_monitors:
  RESOURCE_MONITOR_1:
    frequency: "YEARLY"
    start_timestamp: "2021-04-15"
    end_timestamp: "2022-04-15"
    notify_triggers:
      - 40
    suspend_triggers:
      - 50
    suspend_immediate_triggers:
      - 90

Configuration Update after Creation/Update:

resource_monitors:
  RESOURCE_MONITOR_1:
    frequency: "YEARLY"
    start_timestamp: "2021-04-15T00:00:00Z"
    end_timestamp: "2022-04-15T00:00:00Z"
    notify_triggers:
      - 40
    suspend_triggers:
      - 50
    suspend_immediate_triggers:
      - 90
info

If a new branch is created from this, start_timestamp and end_timestamp have to be set back to dates.

Supported resource monitor grants to roles​

Following is the list of the access privileges you can grant to roles in the resource monitor definition:

  • ALL PRIVILEGES
  • MODIFY
  • MONITOR
ALL PRIVILEGES handling

When you define ALL PRIVILEGES in the SOLE configuration file, you grant all the privileges listed above to roles on this object. However, the management of ALL PRIVILEGES in SOLE differs from its handling in Snowflake. See Handling ALL PRIVILEGES in SOLE for more information.

Examples​

resource_monitors:
  RESOURCE_MONITOR_1:
    credit_quota: 1000
    frequency: "YEARLY"
    start_timestamp: "2021-04-15"
    end_timestamp: "2022-04-15"
    notify_users:
      - USER_1
      - USER_2
    notify_triggers:
      - 40
    suspend_triggers:
      - 50
    suspend_immediate_triggers:
      - 90
    grants:
      MONITOR:
        - DEV_ROLE
Last updated on