• EnglishEspañol日本語한국어Português
  • EntrarComeçar agora

Muting rules: Suppress notifications

Alerts sends out timely notifications when your system is having problems. Sometimes there're notifications you know you don't need to see. You can use muting rules to stop being bombarded by messages that don't need your attention.

Once you've spotted the common elements in your unwanted notifications, you can define muting rules that specifically target those elements, while letting other notifications through. Even when a notification is muted, still gathers data on those incidents. Muting rules don't interfere with the alerts process and are applied at the point right before a notification is sent.

Manage muting rules

A muting rule condition is the set of individual expressions made up of attributes, operators, and values that define which incidents to target for muting.

You can create, enable, disable, and manage muting rules. Go to one.newrelic.com > All capabilities > Alerts > Muting rules. Enable or disable muting rules at any time. Click the icon on the row of each rule to edit and remove rules.

Rules can have one of the following statuses:

  • Active: Muting is enabled and active.
  • Scheduled: Muting is enabled but not active yet (there's a future schedule).
  • Ended: Muting is enabled, but no longer active (there's no future schedule).
  • Inactive: Muting is disabled.

one.newrelic.com > All capabilities > Alerts > Muting rules: You can create complex muting rules to target a small or large set of unwanted notifications.

Create a muting rule

Dica

Before creating muting rules, you'll need to create policies and conditions that generate notifications.

To create a muting rule, go to one.newrelic.com > All capabilities > Alerts > Muting rules and click + Add a rule. Enter a name and a description (optional) for the muting rule, and select the account to which the rule will apply.

Next, build the incidents filter. You can use a subset of incident event attributes. Choose an attribute, an operator, and a value. These are the attributes: accountId, conditionId, conditionName, conditionType, entity.guid, nrqlEventType, nrqlQuery, policyId, policyName, product,runbookUrl (as conditionRunbookUrl), tags.<NAME>, and targetName). Values are compared against one of your incident attributes, such as an alerts policy ID or a condition name. Click Add another condition if you want to include more filters.

one.newrelic.com > All capabilities > Alerts > Muting rules: You can create complex muting rules to target a small or large set of unwanted notifications.

Schedule a muting rule

If needed, you can schedule your muting rules.

To do this, select a start time and/or end time. Optionally, you can set the muting rule to last an entire day.

You can also choose to select a time zone for the muting rule schedule. The default is the time zone selected in your user preferences.

one.newrelic.com > All capabilities > Alerts > Muting rules: Flexible and powerful options for scheduling your muting rules.

You can schedule your muting rules to recur daily, weekly, or monthly. A muting rule that's scheduled to repeat weekly includes the option to select the days of the week to recur. If no days are selected, the weekly recurrence will default to repeating on the day of the week that the muting rule is scheduled to start.

Importante

The Repeat day of the week checkboxes override the Starts and Ends date fields. If you set a start date and also choose a day of the week, your muting rules will be applied on the first of those days after your start date.

You can also specify when you would like recurrence to end by selecting either a specific date or a certain number of occurrences.

Manage muting rules with NerdGraph

In NerdGraph, you can use the following queries and mutations with your muting rules. You can see the schema in more detail in the API Explorer.

  • actor.account.alerts.mutingRule: Fetch a muting rule by id.
  • actor.account.alerts.mutingRules: Fetch a list of muting rules for an account.
  • alertsMutingRuleCreate: Create a muting rule for an account.
  • alertsMutingRuleUpdate: Update a muting rule by id and account id.
  • alertsMutingRuleDelete: Delete a muting rule by id and account id.

You can find some sample queries and mutations examples in this page.

A muting rule has the following fields and components:

Muting rule

Fields and components

id

The unique identifier for the muting rule.

name (Required)

A text field for the user-friendly name of the muting rule. This is used when listing or referencing a rule. We don't require that the name be unique, but it's recommended.

description

This is an optional text field describing the muting rule. It's a useful way to provide more context for your muting rule. This data is only used for management display purposes.

accountId

The muting rule's account ID. A muting rule will only affect incidents that occur in a single account. To mute incidents across multiple accounts, you'll need to create a muting rule for each account separately.

createdAt

The timestamp when the muting rule was created (UTC).

createdBy

The user ID of the person who created the muting rule.

updatedAt

The timestamp when the muting rule was last modified (UTC).

updatedBy

The user ID of the person who last modified the muting rule.

enabled

Enable or disable the muting rule (Boolean). Enable and disable your muting rules manually.

condition

The set of individual expressions that define which incidents to target. A muting rule condition includes:

  • operator: The boolean operator AND or OR that defines how to combine the set of conditions.

  • conditions: The set of individual expressions (sub-conditions) that target attributes within an incident. These are evaluated together based on the operator. You can have a maximum of 20 sub-conditions for a single muting rule.

    A sub-condition includes:

    • attribute: A single attribute within an incident. Go here for a list of Incident event attributes.

    • operator: The comparison function used to compare the selected incident attribute against values in the condition. Go here for a list of sub-condition operators.

    • values: An array of string values to compare against selected incident attributes. When the muting rules evaluate a condition, if necessary, values will be coerced from strings. You can use a maximum of 500 values when using an operator that supports comparison against multiple values, such as IN.

schedule

The time window when the MutingRule actively mutes incidents.

  • startTime: The datetime stamp that represents when the muting rule starts. This is in local ISO 8601 format without an offset. Example: 2020-07-08T14:30:00
  • endTime: The datetime stamp that represents when the muting rule ends. This is in local ISO 8601 format without an offset. Example: 2020-07-15T14:30:00
  • timeZone: The time zone that applies to the muting rule schedule. Example: America/Los_Angeles. See Wikipedia's list of tz database time zones.
  • repeat: The frequency the muting rule schedule repeats. If it does not repeat, use null. Options are DAILY, WEEKLY, MONTHLY.
  • endRepeat: The datetime stamp when the muting rule schedule stops repeating. This is in local ISO 8601 format without an offset. Example: 2020-07-10T15:00:00. Note: Either endRepeat or repeatCount should be used to end a muting rule schedule. Both fields should not be provided together.
  • repeatCount: The number of times the muting rule schedule repeats. This includes the original schedule. For example, a repeatCount of 2 will recur one time. A repeatCount of 3 will recur two times. Note: Either repeatCount or endRepeat can be used to end a muting rule schedule. Don't provide both fields together.
  • weeklyRepeatDays: The day(s) of the week that a muting rule should repeat when the repeat field is set to WEEKLY. Example: ['MONDAY', 'WEDNESDAY'].

How muting rules work

Muting rules are applied at the end of the default alert lifecycle in order to suppress or mute notifications. They don't disable existing policies or conditions. For example, you can mute notifications during known system disruptions, such as maintenance windows and deployments. System disruption incidents will still be identified, even though the notifications for those incidents are muted.

A muting rule uses a set of conditions that match against attributes in a incident event. The muting rules tell us how to:

  1. Identify individual incidents after they're created, but before an issue is opened.
  2. Override their default condition to indicate that they should be "muted."

Currently, muting an incident means that the normal alerts incident lifecycle will be maintained, except that an issue that only contains muted incidents will not send out any notifications.

Muting rules are determined by the first event which triggered a notification within an issue. Meaning, if the first notification event was muted because of a muting state, the rest of the issue will be muted as well.

Muting rules override specific incidents. They don't disable existing policies or conditions. This allows you to mute incidents from specific entities that may be covered by a policy or condition that covers a large number of entities. This also keeps you from having to over-mute your monitoring when you are performing maintenance on a subset of your system.

Muting behavior

The following table describes how the alerts incident lifecycle is affected by muted incidents:

IF

THEN

Event: Issue is activated

An issue is activated because of an incident that is not muted

Notifications for this issue will be sent.

An issue is activated due to an incident that is muted

Notifications for this issue will not be sent (muted).

Muting behavior with workflows

A triggered incident has a 1:1 ratio with an issue so if an incident is muted then the matching issue will be muted as well. Workflows are triggered by issues that can have one or more incidents, therefore there could be a scenario of muted and not muted incidents combined.

Each issue has one of the following muting states:

  • Fully muted (FULLY_MUTED): an issue has all of its open incidents muted (Default value).
  • Partially muted (PARTIALLY_MUTED): an issue that has at least one open incident that is muted and one open incident that is not muted.
  • Not muted (NOT_MUTED): an issue that has no open muted incidents.

For a step-by-step guide on how to set up your workflows, check out an example demo below (approx. 2:17 minutes):

View muted incidents and issues

When viewing an open or closed issue, incidents and issues are marked as Muted. The following sections show some of these muted incidents and issues, and where you can find them.

Mute faceted results using tags.

To mute results of faceted queries, use the tags.FACETED_ATTRIBUTE attribute, where FACETED_ATTRIBUTE represents the attributed you've run a NRQL FACET query on. For example: if your NRQL alert condition includes FACET host in its query, you can target that FACET attribute using tags.host.

NRQL condition queries can accept multiple facet attributes. If you want to be able to filter from attributes in your events or metric time series that have been aggregated, you must add those attributes to your NRQL query FACET clause; for example: FACET host, region, cluster.

For an example of using tags., see Create muting rule.

Sub-condition operators

These are the logical operators you can use to compare attributes when you're adding muting rules. If you're new to muting rules, see these examples.

Dica

All sub-condition operator values are case-sensitive. For example, if you use policyName STARTS_WITH 'PROD' a policy name that starts with 'Prod' won't get picked up.

  • EQUALS: Where the supplied value equals the incident attribute value.
  • DOES_NOT_EQUALS: Where the supplied value doesn't equal the incident attribute value.
  • IN: Where the incident attribute value is present in a list of supplied values (up to 500).
  • NOT_IN: Where the incident attribute value isn't present in a list of supplied values (up to 500).
  • CONTAINS: Where the supplied value string is present in the incident attribute value.
  • DOES_NOT_CONTAINS: Where the supplied value string isn't present in the incident attribute value.
  • ENDS_WITH: Where the incident attribute value ends with the supplied value string.
  • NOT_ENDS_WITH: Where the incident attribute value doesn't end with the supplied value string.
  • STARTS_WITH: Where the incident attribute value begins with the supplied value string.
  • DOES_NOT_STARTS_WITH: Where the incident attribute value doesn't begin with the supplied value string.
  • IS_BLANK: Where the incident attribute value is blank. Null, empty string, etc.
  • IS_NOT_BLANK: Where the incident attribute value is not blank. Null, empty string, etc.
  • IS_ANY: Caution: A condition with this operator will mute all incidents on the account.

Muting examples

For more information about making requests to NerdGraph, see the NerdGraph documentation, including GraphQL tutorials.

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.