diff --git a/src/content/docs/alerts/get-notified/muting-rules-suppress-notifications.mdx b/src/content/docs/alerts/get-notified/muting-rules-suppress-notifications.mdx index e04a6cf230e..44967d4b512 100644 --- a/src/content/docs/alerts/get-notified/muting-rules-suppress-notifications.mdx +++ b/src/content/docs/alerts/get-notified/muting-rules-suppress-notifications.mdx @@ -17,11 +17,44 @@ Alerts sends out timely notifications when your system is having problems. Somet 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. +## Create a muting rule [#create] + + + Before creating muting rules, you'll need to [create policies](/docs/alerts/new-relic-alerts/configuring-alert-policies/create-edit-or-find-alert-policy) and [conditions](/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/create-alert-conditions/) that generate [notifications](/docs/alerts-applied-intelligence/notifications/intro-notifications/). + + +To create a muting rule, follow these steps: + +1. Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **Muting rules** on the left navigation pane. + +2. Click **+ Add a rule**. + +3. Enter a name and a description (optional) for the muting rule, and select the account to which the rule will apply. + +4. Build the incidents filter. You can use a subset of [incident event attributes](/docs/alerts/create-alert/condition-details/incident-event-attributes/). Choose an attribute, an [operator](#sub-conditions), and a value. These are the attributes: `accountId`, `conditionId`, `conditionName`, `conditionType`, `entity.guid`, `nrqlEventType`, `nrqlQuery`, `policyId`, `policyName`, `product`,`runbookUrl` (as `conditionRunbookUrl`), `tags.`, and `targetName`). Values are compared against one of your incident attributes, such as an alerts policy ID or a condition name. + +5. Click **Add another condition** if you want to include more filters. + +Muting rule edit screen + +
+ Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **Muting rules** on the left navigation pane. You can create complex muting rules to target a small or large set of unwanted notifications. +
+ + ## Manage muting rules [#manage] 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](https://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. +To create, enable, disable, and manage muting rules, follow these steps: + +1. Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **Muting rules** on the left navigation pane. + +2. Enable or disable muting rules at any time from the **Enabled** column. You also can edit each rule by clicking the icon on the row of each rule. Rules can have one of the following statuses: @@ -33,39 +66,39 @@ Rules can have one of the following statuses: Manage muting rules
- **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts > Muting rules**: You can create complex muting rules to target a small or large set of unwanted notifications. + Go to **[one.newrelic.com > All capabilities](https://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 [#create] +## How to suppress notifications [#notify] - - Before creating muting rules, you'll need to [create policies](/docs/alerts/new-relic-alerts/configuring-alert-policies/create-edit-or-find-alert-policy) and [conditions](/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/create-alert-conditions/) that generate [notifications](/docs/alerts-applied-intelligence/notifications/intro-notifications/). - +If a mute rule is active, for example, planned maintenance, you won't receive notifications when an incident is triggered. + +When the mute rule is no longer active, you've these options: -To create a muting rule, go to **[one.newrelic.com > All capabilities](https://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. +* **Close ongoing incidents**: This means that if an incident is triggered right after the mute rule is inactive, you'll receive a notification. We recommend that you keep this default setting. -Next, build the incidents filter. You can use a subset of [incident event attributes](/docs/alerts-applied-intelligence/new-relic-alerts/advanced-alerts/understand-technical-concepts/incident-event-attributes). Choose an attribute, an [operator](#sub-conditions), and a value. These are the attributes: `accountId`, `conditionId`, `conditionName`, `conditionType`, `entity.guid`, `nrqlEventType`, `nrqlQuery`, `policyId`, `policyName`, `product`,`runbookUrl` (as `conditionRunbookUrl`), `tags.`, 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. +* **Continue ongoing incidents**: This means that if an incident that started during a muting window continues after the muting rule becomes inactive, you will not be notified. Muting rule edit screen
- **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts > Muting rules**: You can create complex muting rules to target a small or large set of unwanted notifications. + Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **+ Add a rule**.
+ ## Schedule a muting rule [#schedule-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. +To do this, select a start time and 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. @@ -73,11 +106,11 @@ You can also choose to select a time zone for the muting rule schedule. The defa width="50%;" title="Schedule your muting window" alt="Schedule your muting window" - src="/images/accounts_screenshot-full_rules-recurring.webp" + src="/images/alerts_screenshot-crop_schedule-muting window.webp" />
- **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts > Muting rules**: Flexible and powerful options for scheduling your muting rules. + Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **Muting rules** on the left navigation pane. Check the flexible and powerful options you have 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. @@ -88,15 +121,163 @@ You can schedule your muting rules to recur daily, weekly, or monthly. A muting 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 [#manage-with-nerdgraph] +## View muted incidents and issues [#ui] + +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. + + + + Alert incident lifecycle: Muting rule incidents + +
+ Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **Issues & Activity** on the left navigation pane. Click on a muted issue. +
+ + + + Incidents and issues are marked with the icon in the **Muted** column: + + Alert incident lifecycle: Muting rule incidents + +
+ Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Alerts** and click **Issues & Activity** on the left navigation pane. Then select the **Incidents tab**. +
+ + + +### Mute faceted results using `tags.` [#facet-muting] + +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](/docs/query-data/nrql-new-relic-query-language/getting-started/nrql-syntax-clauses-functions#sel-facet) 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](#create). + +## Sub-condition operators [#sub-conditions] + +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](/docs/alerts-applied-intelligence/new-relic-alerts/alert-notifications/muting-rules-suppress-notifications/#examples). + + + 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`: A condition with this operator will mute all incidents on the account. + +## How muting rules work [#overview] + +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 an [incident event](/docs/alerts-applied-intelligence/new-relic-alerts/advanced-alerts/understand-technical-concepts/incident-event-attributes). The muting rules tell us how to: + +* Identify individual incidents after they're created, but before an issue is opened. +* Override their default condition to indicate that they should be muted. + +Currently, muting an incident means that the normal alerting incident lifecycle is maintained, except that an issue containing only muted incidents will not send any notifications. + +Muting rules are determined by the first event that triggered a notification within an issue. This means that if the first notification event was muted due to a muted 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. + +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 [#workflow-behavior] + +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): + +