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 repéré les éléments communs dans votre notification indésirable, vous pouvez définir des règles de désactivation qui ciblent spécifiquement ces éléments, tout en laissant passer les autres notifications. Même lorsqu'une notification est désactivée, alertescollecte toujours des données sur ces incidents. Les règles de désactivation n'interfèrent pas avec le processus d'alertes 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 d’incident. Vous pouvez utiliser un sous-ensemble de l'attributincident événement. Choisissez un attribut, un opérateur et une valeur. Voici les attributs : accountId, conditionId, conditionName, conditionType, entity.guid, nrqlEventType, nrqlQuery, policyId, policyName, product,runbookUrl (comme conditionRunbookUrl), tags.<NAME> et targetName). Les valeurs sont comparées à l'un de vos attributs incident , comme un ID de règle d'alerte ou un nom de condition.

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

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 l'incident à 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.

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

Lorsqu'une règle de mise en sourdine est active et qu'un incident est ouvert, l'utilisateur ne recevra pas de notification. Vous pouvez configurer le comportement de notification lorsqu'une règle de désactivation est inactive avec les deux paramètres ci-dessous :

• Notify:Si un incident se produit après la fin de la fenêtre de règle de mise en sourdine, vous en serez averti. Cela fonctionne en fermant l'incident existant et en mode silencieux, et si le seuil est toujours violé, un nouvel incident s'ouvrira dans un état non silencieux, déclenchant une notification. Nous vous recommandons de conserver ce paramètre par défaut.

• Suppress notification:Si un incident se produit après la fin de la fenêtre de règle de mise en sourdine, vous ne serez pas averti. Cela fonctionne en laissant l'incident existant et désactivé ouvert au-delà de l'horodatage de fin de la fenêtre de règle de désactivation.

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.

Afficher les incidents et problèmes en mode silencieux

Lors de la visualisation d'un problème ouvert ou fermé, les incidents et les problèmes sont marqués comme Muted. Les sections suivantes présentent certains de ces incidents et problèmes mis en sourdine, et où vous pouvez les trouver.

Un problème avec un incident critique qui a été mis en sourdine

Une liste d'incidents, dont certains sont en sourdine

les incidents et les problèmes sont marqués avec le 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 incident.
• DOES_NOT_EQUALS:Lorsque la valeur fournie n'est pas égale à la valeur de l'attribut incident.
• IN:Lorsque la valeur de l'attribut incident est présente dans une liste de valeurs fournies (jusqu'à 500).
• NOT_IN:Lorsque la valeur de l'attribut incident n'est pas présente dans une liste de valeurs fournies (jusqu'à 500).
• CONTAINS:Lorsque la chaîne de valeur fournie est présente dans la valeur de l'attribut incident.
• DOES_NOT_CONTAINS:Lorsque la chaîne de valeur fournie n'est pas présente dans la valeur de l'attribut d'incident.
• ENDS_WITH:Là où la valeur de l'attribut incident se termine par la chaîne de valeur fournie.
• NOT_ENDS_WITH:Lorsque la valeur de l'attribut incident ne se termine pas par la chaîne de valeur fournie.
• STARTS_WITH:Là où la valeur de l'attribut incident commence par la chaîne de valeur fournie.
• DOES_NOT_STARTS_WITH:Lorsque la valeur de l'attribut incident ne commence pas par la chaîne de valeur fournie.
• IS_BLANK:Lorsque la valeur de l'attribut incident est vide. Nul, chaîne vide, etc.
• IS_NOT_BLANK:Lorsque la valeur de l'attribut incident n'est pas vide. Nul, chaîne vide, etc.
• IS_ANY:Une condition avec cet opérateur désactivera tous les incidents sur le compte.

Comment fonctionnent les règles de mise en sourdine

Les règles de désactivation sont appliquées à la fin du cycle de vie de l'alerte par défaut afin de supprimer ou de désactiver la notification. Ils ne désactivent pas les politiques ou conditions existantes. Par exemple, vous pouvez désactiver les notifications lors de perturbations système connues, telles que les fenêtres de maintenance et de déploiement. Les incidents de perturbation du système seront toujours identifiés, même si les notifications pour ces incidents sont désactivées.

Une règle de mise en sourdine utilise un ensemble de conditions qui correspondent à l'attribut d'un événementincident . Les règles de mise en sourdine nous indiquent comment :

• Identifiez les incidents individuels après leur création, mais avant qu'un problème ne soit ouvert.
• Remplacez leur condition par défaut pour indiquer qu'ils doivent être désactivés.

Actuellement, la mise en sourdine d'un incident signifie que le cycle de vie normal incident d'alerte est maintenu, sauf qu'un problème contenant uniquement un incident 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 remplacent un incident spécifique. Ils ne désactivent pas les politiques ou conditions existantes. Cela vous permet de désactiver un incident provenant d'une entité spécifique qui peut être couverte par une politique ou une condition couvrant un grand nombre d'entités. Cela vous évite également de devoir désactiver excessivement votre monitoring lorsque vous effectuez une maintenance sur un sous-ensemble de votre système.

Le tableau suivant décrit comment le cycle de vie de incident d'alerte est affecté par un incident désactivé :

Comportement de mise en sourdine avec le flux de travail

Un incident déclenché a un rapport de 1:1 avec un problème, donc si un incident est désactivé, le problème correspondant sera également désactivé. les flux de travail sont déclenchés par des problèmes qui peuvent avoir un ou plusieurs incidents, il pourrait donc y avoir un scénario d'incident en sourdine et non en sourdine combiné.

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

• Fully muted (FULLY_MUTED):un problème a tous ses incidents ouverts mis en sourdine (valeur par défaut).
• Partially muted (PARTIALLY_MUTED):un problème qui comporte au moins un incident ouvert qui est désactivé et un incident ouvert qui n'est pas désactivé.
• Not muted (NOT_MUTED):un problème qui n'a pas d'incident ouvert en sourdine.

Pour un guide étape par étape sur la façon de configurer votre flux de travail, 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
  }
}