Règles de mise en sourdine : supprimer la notification

Alertes envoie une notification en temps opportun lorsque votre système rencontre des problèmes. Parfois, vous ne souhaitez pas voir certaines notifications connues. Vous pouvez utiliser muting rules pour arrêter d'être bombardé de messages qui ne nécessitent pas votre attention.

Une fois que vous avez identifié les éléments communs dans vos notifications indésirables, vous pouvez définir des règles de mise en sourdine qui ciblent spécifiquement ces éléments, tout en laissant passer les autres notifications. Même lorsqu'une notification est en sourdine, alertescollecte toujours des données sur ces événements d'alerte. Les règles de mise en sourdine n'interfèrent pas avec le processus d'alerte et sont appliquées juste avant l'envoi d'une notification.

Créer une règle de mise en sourdine

Pour créer une règle de mise en sourdine, procédez comme suit :

1. Accédez à one.newrelic.com > All capabilities > Alerts et cliquez sur Muting rules dans le volet de navigation de gauche.

2. Cliquez sur + Add a rule.

3. Saisissez un nom et une description (facultatif) pour la règle de mise en sourdine, puis sélectionnez le compte auquel la règle s'appliquera.

4. Construisez le filtre des événements d'alerte. Vous pouvez utiliser un sous-ensemble d'attributs d'événement d'alerte. Choisissez un attribut, un opérateur et une valeur. Voici les attributs : accountId, conditionId, conditionName, conditionType, entity.guid, nrqlEventType, nrqlQuery, policyId, policyName, product,runbookUrl (en tant que conditionRunbookUrl), tags.<NAME> et targetName). Les valeurs sont comparées à l'un de vos attributs d'événement d'alerte, tel qu'un ID de politique d'alertes ou un nom de condition.

5. Cliquez sur Add another condition si vous souhaitez inclure plus de filtres.

/* <img title="Écran de modification de la règle de mise en sourdine" alt="Écran de modification de la règle de mise en sourdine" src="/images/alerts_screenshot-crop_violation-filter.webp" /> <figcaption> Allez sur <DNT>**[one.newrelic.com > All capabilities](https\://one.newrelic.com/all-capabilities) > Alerts**</DNT> et cliquez sur <DNT>**Muting rules**</DNT> dans le volet de navigation de gauche. Vous pouvez créer des règles de mise en sourdine complexes pour cibler un ensemble restreint ou vaste de notifications indésirables. </figcaption> */

Gérer les règles de mise en sourdine

Une condition de règle de mise en sourdine est l'ensemble d'expressions individuelles composées d'attributs, d'opérateurs et de valeurs qui définissent les événements d'alerte à cibler pour la mise en sourdine.

Pour créer, activer, désactiver et gérer les règles de mise en sourdine, procédez comme suit :

1. Accédez à one.newrelic.com > All capabilities > Alerts et cliquez sur Muting rules dans le volet de navigation de gauche.

2. Activez ou désactivez les règles de mise en sourdine à tout moment à partir de la colonne Enabled . Vous pouvez également modifier chaque règle en cliquant sur le bouton icône sur la ligne de chaque règle.

Les règles peuvent avoir l'un des statuts suivants :

• Active:La mise en sourdine est activée et active.
• Scheduled:La mise en sourdine est activée mais pas encore active (il y a une planification future).
• Ended:La mise en sourdine est activée, mais n'est plus active (il n'y a pas de planification future).
• Inactive: La mise en sourdine est désactivée.

/* <img title="Gérer les règles de silence" alt="Gérer les règles de silence" src="/images/alerts_screenshot-full_muting-rules.webp" /> <figcaption> Allez sur <DNT>**[one.newrelic.com > All capabilities](https\://one.newrelic.com/all-capabilities) > Alerts > Muting rules**</DNT>: Vous pouvez créer des règles de silence complexes pour cibler un ensemble restreint ou vaste de notifications indésirables. </figcaption> */

Options de notification pour les règles de désactivation

Lorsqu'une règle de mise en sourdine est active et qu'un événement d'alerte est ouvert, l'utilisateur ne reçoit pas de notification. Vous pouvez configurer le comportement des notifications lorsqu'une règle de mise en sourdine est inactive à l'aide des deux paramètres ci-dessous :

• Notify: Si un événement d'alerte est en cours après la fin de la fenêtre de la règle de mise en sourdine, vous serez notifié. Cela fonctionne en fermant l'événement d'alerte existant mis en sourdine ; si le seuil est toujours dépassé, un nouvel événement d'alerte s'ouvre dans un état non mis en sourdine, déclenchant une notification. Nous recommandons de conserver ce paramètre par défaut.

• Suppress notification: Si un événement d'alerte est en cours après la fin de la fenêtre de la règle de silence, vous ne serez pas notifié. Cela fonctionne en laissant l'événement d'alerte existant mis en sourdine ouvert au-delà de l'horodatage de fin de la fenêtre de la règle de mise en sourdine.

Planifier une règle de mise en sourdine

Si nécessaire, vous pouvez planifier vos règles de mise en sourdine.

Pour ce faire, sélectionnez une heure de début et une heure de fin. En option, vous pouvez définir la règle de mise en sourdine pour qu'elle dure une journée entière.

Vous pouvez également choisir de sélectionner un fuseau horaire pour la planification de la règle de mise en sourdine. La valeur par défaut est le fuseau horaire sélectionné dans vos préférences utilisateur.

Vous pouvez programmer vos règles de désactivation pour qu'elles se répètent quotidiennement, hebdomadairement ou mensuellement. Une règle de mise en sourdine programmée pour se répéter chaque semaine inclut la possibilité de sélectionner les jours de la semaine où elle se répète. Si aucun jour n'est sélectionné, la récurrence hebdomadaire se répétera par défaut le jour de la semaine où la règle de mise en sourdine est programmée pour démarrer.

Vous pouvez également spécifier quand vous souhaitez que la récurrence se termine en sélectionnant soit une date spécifique, soit un certain nombre d'occurrences.

Voir les événements d'alerte et les problèmes mis en sourdine

Lors de la consultation d'un problème ouvert ou fermé, les événements d'alerte et les problèmes sont marqués comme Muted. Vous pouvez consulter les événements d'alerte et les problèmes mis en sourdine aux emplacements suivants :

• Afficher un problème mis en sourdine : Allez à one.newrelic.com > All capabilities > Alerts et cliquez sur Issues & Activity dans le volet de navigation de gauche. Cliquez sur un problème mis en sourdine pour afficher les détails des événements d'alerte critiques qui ont été mis en sourdine.

• Afficher une liste des événements d'alerte mis en sourdine : Accédez à one.newrelic.com > All capabilities > Alerts et cliquez sur Issues & Activity dans le volet de navigation de gauche. Sélectionnez ensuite le alert events tab. Les événements d'alerte et les problèmes mis en sourdine sont signalés par l'icône dans la colonne Muted.

Désactiver les résultats à facettes à l'aide de tags.

Pour désactiver les résultats d'une requête à facettes, utilisez l'attribut tags.FACETED_ATTRIBUTE, où FACETED_ATTRIBUTE représente l'attribut sur lequel vous avez exécuté une requête NRQL FACET . Par exemple : si votre condition d'alerte NRQL inclut FACET host dans sa requête, vous pouvez cibler cet attribut FACET en utilisant tags.host.

La requête de condition NRQL peut accepter plusieurs attributs de facettes. Si vous souhaitez pouvoir filtrer à partir des attributs de votre événement ou de votre série temporelle métrique qui ont été agrégés, vous devez ajouter ces attributs à votre clause de requête NRQL FACET ; par exemple : FACET host, region, cluster.

Pour un exemple d'utilisation de tags., voir Créer une règle de mise en sourdine.

Opérateurs de sous-conditions

Voici les opérateurs logiques que vous pouvez utiliser pour comparer les attributs lorsque vous ajoutez des règles de désactivation. Si vous débutez avec les règles de mise en sourdine, consultez ces exemples.

• EQUALS: où la valeur fournie est égale à la valeur de l'attribut de l'événement d'alerte.
• DOES_NOT_EQUALS: Où la valeur fournie n'est pas égale à la valeur de l'attribut de l'événement d'alerte.
• IN: où la valeur de l'attribut de l'événement d'alerte est présente dans une liste de valeurs fournies (jusqu'à 500).
• NOT_IN: Où la valeur de l'attribut d'événement d'alerte ne figure pas dans une liste de valeurs fournies (jusqu'à 500).
• CONTAINS: où la chaîne de valeur fournie est présente dans la valeur de l'attribut de l'événement d'alerte.
• DOES_NOT_CONTAINS: où la chaîne de valeur fournie n'est pas présente dans la valeur de l'attribut de l'événement d'alerte.
• ENDS_WITH: où la valeur de l'attribut d'événement d'alerte se termine par la chaîne de valeur fournie.
• NOT_ENDS_WITH: Où la valeur de l'attribut de l'événement d'alerte ne se termine pas par la chaîne de valeur fournie.
• STARTS_WITH: où la valeur de l'attribut de l'événement d'alerte commence par la chaîne de valeur fournie.
• DOES_NOT_STARTS_WITH: Où la valeur de l'attribut de l'événement d'alerte ne commence pas par la chaîne de valeur fournie.
• IS_BLANK: Où la valeur de l'attribut d'événement d'alerte est vide. Null, chaîne vide, etc.
• IS_NOT_BLANK: Là où la valeur de l'attribut de l'événement d'alerte n'est pas vide. Null, chaîne vide, etc.
• IS_ANY: Une condition avec cet opérateur mettra en sourdine tous les événements d'alerte du compte.

Comment fonctionnent les règles de mise en sourdine

Les règles de mise en sourdine sont appliquées à la fin du cycle de vie par défaut des alertes afin de supprimer ou de mettre en sourdine les notifications. Ils ne désactivent pas les politiques ou conditions existantes. Par exemple, vous pouvez mettre en sourdine les notifications pendant les interruptions connues du système, telles que les fenêtres de maintenance et les déploiements. Les événements d'alerte de perturbation du système seront toujours identifiés, même si les notifications pour ces événements d'alerte sont mises en sourdine.

Une règle de silence utilise un ensemble de conditions qui correspondent à des attributs dans un événement d'alerte. Les règles de mise en sourdine nous indiquent comment :

• Identifiez les événements d'alerte individuels après leur création, mais avant l'ouverture d'un incident.
• Remplacez leur condition par défaut pour indiquer qu'ils doivent être désactivés.

Actuellement, la mise en sourdine d'un événement d'alerte signifie que le cycle de vie normal de l'événement d'alerte est maintenu, sauf qu'un problème contenant uniquement des événements d'alerte mis en sourdine n'enverra aucune notification.

Les règles de mise en sourdine sont déterminées par le premier événement qui a déclenché une notification dans un problème. Cela signifie que si le premier événement de notification a été désactivé en raison d'un état désactivé, le reste du problème sera également désactivé.

Les règles de mise en sourdine l'emportent sur des événements d'alerte spécifiques. Ils ne désactivent pas les politiques ou conditions existantes. Cela vous permet de mettre en sourdine les événements d'alerte provenant d'entités spécifiques susceptibles d'être couvertes par une politique ou une condition qui couvre un grand nombre d'entités. Cela vous évite également d'avoir à mettre en sourdine votre monitoring de manière excessive lorsque vous effectuez une maintenance sur un sous-ensemble de votre système.

Le tableau suivant décrit comment le cycle de vie des événements d'alerte est affecté par les événements d'alerte mis en sourdine :

Comportement de mise en sourdine avec le workflow

Un événement d'alerte déclenché a un rapport 1:1 avec un problème, donc si un événement d'alerte est mis en sourdine, le problème correspondant le sera également. Les workflows sont déclenchés par des problèmes pouvant comporter un ou plusieurs événements d'alerte ; il est donc possible d'avoir un scénario combinant des événements d'alerte mis en sourdine et non mis en sourdine.

Chaque problème présente l’un des états de mise en sourdine suivants :

• Fully muted (FULLY_MUTED): un problème a tous ses événements d'alerte ouverts mis en sourdine (Valeur par défaut).
• Partially muted (PARTIALLY_MUTED): un problème qui a au moins un événement d'alerte ouvert mis en sourdine et un événement d'alerte ouvert qui n'est pas mis en sourdine.
• Not muted (NOT_MUTED): un problème qui n'a pas d'événements d'alerte ouverts mis en sourdine.

Pour un guide étape par étape sur la façon de configurer votre workflow, consultez un exemple de démonstration ci-dessous (environ 15 minutes). 2:17 minutes) :

Comportement de mise en sourdine avec NerdGraph

Dans NerdGraph, vous pouvez utiliser la requête et les mutations suivantes avec vos règles de mise en sourdine. Vous pouvez voir le schéma plus en détail dans l'API Explorer.

• actor.account.alerts.mutingRule: Récupère une règle de mise en sourdine par ID.
• actor.account.alerts.mutingRules: Récupère une liste de règles de mise en sourdine pour un compte.
• alertsMutingRuleCreate:Créer une règle de mise en sourdine pour un compte.
• alertsMutingRuleUpdate: Mettre à jour une règle de mise en sourdine par ID et ID de compte.

Vous pouvez trouver quelques exemples de requêtes et de mutations sur cette page.

Une règle de mise en sourdine comporte les champs et composants suivants :

Exemples de mise en sourdine

Pour plus d'informations sur la manière de faire requests à NerdGraph, consultez la documentation de NerdGraph, y compris les didacticielsGraphQL .

{
  actor {
    account(id: YOUR_ACCOUNT_ID) {
      alerts {
        mutingRules {
          name
          condition {
            operator
            conditions {
              attribute
              operator
              values
            }
          }
        }
      }
    }
  }
}

mutation {
  alertsMutingRuleCreate(
    accountId: YOUR_ACCOUNT_ID
    rule: {
      name: "host-1 mute rule"
      description: "Mute host-1 incidents"
      enabled: true
      condition: {
        operator: AND
        conditions: [
          { attribute: "tags.host", operator: EQUALS, values: ["host-1"] }
        ]
      }
    }
  ) {
    id
  }
}

mutation {
  alertsMutingRuleCreate(
    accountId: YOUR_ACCOUNT_ID
    rule: {
      name: "host-1 and synthetics/mobile mute rule"
      description: "Mute host-1 and synthetics/mobile incidents"
      enabled: true
      condition: {
        operator: OR
        conditions: [
          { attribute: "targetName", operator: EQUALS, values: ["host-1"] }
          {
            attribute: "product"
            operator: IN
            values: ["SYNTHETICS", "MOBILE"]
          }
        ]
      }
    }
  ) {
    id
  }
}

mutation {
  alertsMutingRuleUpdate(
    accountId: YOUR_ACCOUNT_ID
    id: MUTING_RULE_ID
    rule: { name: "updated name", enabled: false }
  ) {
    name
  }
}

mutation {
  alertsMutingRuleDelete(accountId: YOUR_ACCOUNT_ID, id: MUTING_RULE_ID) {
    id
  }
}