• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

Cette traduction automatique est fournie pour votre commodité.

En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.

Créer un problème

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, collecte 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

Important

Avant de créer des règles de mise en sourdine, vous devez créer des politiques et des conditions qui génèrent des notifications.

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.

Muting rule edit screen

Accédez à one.newrelic.com > All capabilities > Alerts et cliquez sur Muting rules dans le volet de navigation de gauche. Vous pouvez créer des règles de désactivation complexes pour cibler un petit ou un grand ensemble de notifications indésirables.

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.
Manage muting rules

Accédez à one.newrelic.com > All capabilities > Alerts > Muting rules: vous pouvez créer des règles de désactivation complexes pour cibler un petit ou un grand ensemble de notifications indésirables.

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.

How to suppress notifications

Allez à one.newrelic.com > All capabilities > Alerts et cliquez sur + Add a rule.

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.

Schedule your muting window

Accédez à one.newrelic.com > All capabilities > Alerts et cliquez sur Muting rules dans le volet de navigation de gauche. Vérifiez les options flexibles et puissantes dont vous disposez pour planifier vos règles de mise en sourdine.

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.

Important

Les cases à cocher du jour de la semaine Repeat remplacent les champs de date Starts et Ends . Si vous définissez une date de début et choisissez également un jour de la semaine, vos règles de mise en sourdine seront appliquées le premier de ces jours après votre date de début.

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.

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.

Conseil

Toutes les valeurs de l'opérateur de sous-condition sont sensibles à la casse. Par exemple, si vous utilisez policyName STARTS_WITH 'PROD' un nom de politique commençant par « Prod » ne sera pas récupéré.

  • 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é :

SI

ALORS

Event: Le problème est activé

Un problème est activé en raison d'un incident qui n'est pas désactivé

une notification concernant ce problème sera envoyée.

Un problème est activé en raison d'un incident qui est mis en sourdine

la notification pour ce problème ne sera pas envoyée (en sourdine).

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 :

Règle de mise en sourdine

Champs et composants

accountId

L'ID de compte de la règle de mise en sourdine. Une règle de mise en sourdine n'affectera que les incidents qui se produisent dans un seul compte. Pour désactiver un incident sur plusieurs comptes, vous devez créer une règle de désactivation pour chaque compte séparément.

actionOnMutingRuleWindowEnded

Le comportement attendu à la fin de la fenêtre de règle de mise en sourdine. Valeurs valides de CLOSE_ISSUES_ON_INACTIVE ou DO_NOTHING. Si CLOSE_ISSUES_ON_INACTIVE est sélectionné, tous les problèmes en cours seront fermés et seront rouverts (avec notification) si l'incident se poursuit.

condition

L'ensemble des expressions individuelles qui définissent l'incident à cibler. Une condition de règle de mise en sourdine comprend :

  • operator: L'opérateur booléen AND ou OR qui définit comment combiner l'ensemble des conditions.

  • conditions: L'ensemble des expressions individuelles (sous-conditions) que la cible attribue au sein d'un incident. Ceux-ci sont évalués ensemble sur la base du operator. Vous pouvez avoir un maximum de 20 sous-conditions pour une seule règle de mise en sourdine.

    Une sous-condition comprend :

    • attribute:Un attribut unique dans un incident. Cliquez ici pour une liste d'attributs d'événement incident.

    • operator: La fonction de comparaison utilisée pour comparer l'attribut d'incident sélectionné aux valeurs de la condition. Cliquez ici pour obtenir une liste des opérateurs de sous-condition.

    • values:Un éventail de valeurs de chaîne à comparer à l'attribut incident sélectionné. Lorsque les règles de mise en sourdine évaluent une condition, si nécessaire, les valeurs seront extraites des chaînes. Vous pouvez utiliser un maximum de 500 valeurs lorsque vous utilisez un opérateur qui prend en charge la comparaison de plusieurs valeurs, telles que IN.

createdAt

L'horodatage de la création de la règle de mise en sourdine (UTC).

createdBy

L'ID utilisateur de la personne qui a créé la règle de mise en sourdine.

description

Il s'agit d'un champ de texte facultatif décrivant la règle de mise en sourdine. C'est un moyen utile de fournir plus de contexte à votre règle de mise en sourdine. Ces données sont uniquement utilisées à des fins d'affichage de gestion.

enabled

Activer ou désactiver la règle de mise en sourdine (booléen). Activez et désactivez vos règles de mise en sourdine manuellement.

id

L'identifiant unique de la règle de mise en sourdine.

mutingRuleLifecycleEventPublishedAt

Un horodatage représentant la dernière fois que le comportement de fin de fenêtre de règle de mise en sourdine a été appliqué.

name (Requis)

Un champ de texte pour le nom convivial de la règle de mise en sourdine. Ceci est utilisé lors de l'énumération ou du référencement d'une règle. Nous n'exigeons pas que le nom soit unique, mais c'est recommandé.

schedule

La fenêtre temporelle pendant laquelle le MutingRule coupe activement le son de l'incident.

  • startTime: L'horodatage qui représente le moment où la règle de mise en sourdine démarre. Il s'agit d'un format local ISO 8601 sans décalage. Exemple: 2020-07-08T14:30:00
  • endTime: L'horodatage qui représente le moment où la règle de mise en sourdine se termine. Il s'agit d'un format local ISO 8601 sans décalage. Exemple: 2020-07-15T14:30:00
  • timeZone: Le fuseau horaire qui s'applique à la planification de la règle de mise en sourdine. Exemple : America/Los_Angeles. Voir la liste des fuseaux horaires de la base de données tz de Wikipédia.
  • repeat: La fréquence à laquelle la règle de mise en sourdine est répétée. Si cela ne se répète pas, utilisez null. Les options sont DAILY, WEEKLY, MONTHLY.
  • endRepeat: L'horodatage lorsque la planification de la règle de mise en sourdine cesse de se répéter. Il s'agit d'un format local ISO 8601 sans décalage. Exemple : 2020-07-10T15:00:00. Remarque : endRepeat ou repeatCount doit être utilisé pour mettre fin à une planification de règle de mise en sourdine. Les deux champs ne doivent pas être fournis ensemble.
  • repeatCount: Le nombre de fois que la planification de la règle de mise en sourdine se répète. Ceci inclut le calendrier original. Par exemple, un repeatCount sur 2 se reproduira une fois. Un repeatCount sur 3 se reproduira deux fois. Remarque : repeatCount ou endRepeat peuvent être utilisés pour mettre fin à une planification de règle de mise en sourdine. Ne fournissez pas les deux champs ensemble.
  • weeklyRepeatDays: Le(s) jour(s) de la semaine pendant lesquels une règle de mise en sourdine doit se répéter lorsque le champ de répétition est défini sur WEEKLY. Exemple : ['MONDAY', 'WEDNESDAY'].

updatedAt

L'horodatage de la dernière modification de la règle de mise en sourdine (UTC).

updatedBy

L'ID utilisateur de la personne qui a modifié en dernier la règle de mise en sourdine.

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 .

Droits d'auteur © 2025 New Relic Inc.

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