Your data. Anywhere you go.

New Relic for iOS or Android


Download on the App Store    Android App on Google play


New Relic Insights App for iOS


Download on the App Store


Learn more

Close icon

Relic Solution: Muting Rules Pro-Tips

alerts
rfb
muting-rules

#1

Muting Rules is a great feature in Alerts which allows users to silence notifications based on several different criteria. This documentation goes into detail on how to use this feature.

In this article, I’m going to focus on two different object attributes which can be used to target entities to be silenced.


tag.*

The tag.* object attribute is used to target tags. Tags can be attached in many ways, but a good way to think about them is as entity metadata. They are also used to facet NRQL alert conditions. In order for it to be considered a tag.*, it needs to be a key:value pair. To use tag.*, you would first name a key, then specify a value of that key to be silenced.

        attribute: "tag.hostname",
        operator: EQUALS,
        values: ["host-1"]

This would silence any entity with a tag of hostname:host-1. If you used this in an actual Muting Rule, any violation coming from a NRQL alert condition using FACET hostname would be silenced, assuming host-1 was the target of the violation. Keep in mind that Infrastructure alert conditions do not see hostname as a tag, and so this will not silence any violations coming from Infrastructure alert conditions targeting host-1.

You could, alternatively, use a label or custom attribute for your Muting Rule.

        attribute: "tag.environment",
        operator: EQUALS,
        values: ["prod"]

This would silence any violation coming from a NRQL alert condition using FACET environment in the query and with a target that had the environment:prod custom attribute or label. It would also silence any violations coming from Infrastructure alert conditions targeting a host with the environment:prod custom attribute or label on it.


targetName

The targetName object attribute is used to specify the target of violations coming from non-NRQL alert conditions. Any entity that can be targeted by an alert condition (an APM-monitored application, for instance, or an Infrastructure-monitored host) can be specified here. You could directly target a hostname:

          attribute: "targetName",
          operator: EQUALS,
          values: ["host-1"]

This will silence any violations coming from Infrastructure alert conditions targeting the host-1 server.

          attribute: "targetName",
          operator: EQUALS,
          values: ["app-1"]

This will silence any violations coming from APM alert conditions targeting the app-1 application.



Now here’s where you get to put these two together.

How do I silence a server during maintenance when I have both Infrastructure and NRQL alert conditions scoped to that server?

This is an interesting case, since the NRQL condition is probably using FACET hostname while the Infrastructure condition is simply targeting that host (along with, probably, other hosts as well). In this case, you would use a combined clause in your API call.

    condition: {
      operator: OR,
      conditions: [
        {
          attribute: "targetName",
          operator: EQUALS,
          values: ["host-1"]
        },
        {
          attribute: "tag.hostname",
          operator: EQUALS,
          values: ["host-1"]
        }
      ]
    }

At first glance, this might seem redundant. However, now that you know the nuance of these two object attributes, you can see that this Muting Rule will silence violations from the host-1 server whether they are coming from Infrastructure conditions directly targeting that server or NRQL conditions using FACET host.


#2

Here’s another pro-tip for muting rules users. This idea came from a customer ticket, where they were trying to disable all of their alert conditions using the REST API. We suggested that they use Muting Rules, instead.

Before we suggested this, though, we figured we ought to find out how involved it would be to do this. Would they need to use the API to list out all of their alert policies, then make separate muting rules for each policy?

As it turns out, wildcards work in Muting Rules! So we tried creating a Muting Rule with the following details:

              "conditions": [
                {
                  "attribute": "policyName",
                  "operator": "ANY",
                  "values": [
                    "*"
                  ]
                }
              ],

This will quickly and elegantly silence all policies on your account. Since alert conditions must be contained within policies, while this rule is enabled no notifications will be sent out.


Feature Idea: Is there an API for "Monitor Downtime"?
split this topic #3

4 posts were split to a new topic: Auto-Scheduling Muting Rules


Learn some stuff, Earn some stuff!