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.
Une condition d’alerte est l’élément central qui définit quand un incident est créé. Il constitue le point de départ essentiel pour créer toute alerte significative. la condition d'alerte contient le paramètre ou le seuil atteint avant que vous en soyez informé. Ils peuvent atténuer les alertes excessives ou informer votre équipe lorsqu'un comportement nouveau ou inhabituel apparaît.
Créer une nouvelle condition d'alerte
Une condition d'alerte est une requête exécutée en continu qui mesure un ensemble donné d'événements par rapport à un seuil défini et ouvre un incident lorsque le seuil est atteint pendant une fenêtre de temps spécifiée.
Cet exemple montre la création manuelle d’une nouvelle condition d’alerte à l’aide de la page Alert condition details . Mais il existe de nombreuses façons de créer une condition d’alerte. Vous pouvez créer une condition d'alerte à partir de :
Vous pouvez également utiliser l'un de nos générateurs d'alertes :
Utilisez Write your own query pour créer des alertes à partir de zéro
Use guided mode
Pour toutes les méthodes à l’exception de notre mode guidé, le processus de création d’une condition d’alerte sera exactement le même que celui décrit dans les étapes ci-dessous.
Définissez le comportement de votre signal
Dans cet exemple, imaginez que votre équipe gère l’application WebPortal pour un site de commerce électronique. Vous souhaitez être alerté de tout problème de latence.
Vous pouvez utiliser une requête NRQL pour définir les signaux que vous souhaitez qu'une condition d'alerte utilise comme base pour votre alerte. Pour cet exemple, vous utiliserez cette requête :
SELECT average(duration)
FROM PageView
WHERE appName ='WebPortal'
L'utilisation de cette requête pour votre condition d'alerte indique New Relic que vous souhaitez connaître la latence moyenne, ou la durée, de chargement des pages dans votre application WebPortal. L'alerte proactive sur la latence, un élément central des signaux dorés, fournit des alertes précoces sur une dégradation potentielle.
Vous pouvez en apprendre plus sur l'utilisation de NRQL, le langage de requête de New Relic, consultez notre documentation NRQL.
Ajuster les paramètres avancés du signal
Après avoir défini votre signal, cliquez sur Run. Un graphique apparaîtra et affichera le paramètre que vous avez défini.
Conseil
Pour configurer des alertes inter-comptes, sélectionnez un compte de données dans la liste déroulante. Et vous ne pouvez interroger les données que d'un seul compte à la fois pour les alertes inter-comptes.
Pour cet exemple, le graphique montrera la durée moyenne d'une transaction. Cliquez sur Next et commencez à configurer votre condition d’alerte.
Pour cet exemple, vous allez personnaliser ces paramètres de signal avancés pour la condition que vous avez créée pour monitorer la latence dans votre application WebPortal.
La durée de la fenêtre définit la manière dont New Relic regroupe vos données pour analyse dans une condition d'alerte. Le choix du bon paramètre dépend de la fréquence de vos données et du niveau de détail souhaité :
High-frequency data (for example, pageviews every minute): Définissez la durée de la fenêtre pour qu'elle corresponde à la fréquence des données (1 minute dans ce cas) pour les informations en temps réel détaillées sur les fluctuations et les tendances.
Low-frequency data (for example, hourly signals):Choisissez une durée de fenêtre qui capture suffisamment de données pour révéler des modèles et des anomalies (par exemple, 60 minutes pour les signaux horaires).
N'oubliez pas que vous pouvez personnaliser la durée de la fenêtre en fonction de vos besoins et de votre expérience. Nous vous recommandons d'utiliser les valeurs par défaut lors du démarrage et d'expérimenter à mesure que vous vous sentez plus à l'aise avec la création de conditions d'alerte.
Les méthodes d’agrégation traditionnelles peuvent s’avérer insuffisantes lorsqu’il s’agit de traiter des données peu peuplées ou présentant des fluctuations importantes entre les intervalles. Voici comment utiliser l'agrégation de fenêtres glissantes pour analyser ces données et déclencher efficacement des alertes opportunes :
Smooth out the noise:Commencez par créer une grande fenêtre d’agrégation. Cette fenêtre (par exemple, 5 minutes) agit comme un tampon, atténuant le « bruit » ou la variabilité inhérente à vos données. Cela permet d’éviter les alertes intempestives déclenchées par des pics ou des creux isolés.
Avoid lag with a sliding window:Bien qu'une grande fenêtre facilite l'analyse des données, si vous attendez que l'intervalle entier soit écoulé avant de vérifier le seuil, vous pouvez rencontrer des retards importants dans la notification des alertes. Nous recommandons des fenêtres coulissantes plus petites (par exemple, une minute). Imaginez cette fenêtre coulissante comme un cadre mobile analysant vos données dans la fenêtre d’agrégation plus grande. Chaque fois que le cadre avance de son intervalle le plus petit, il calcule une valeur globale (par exemple, une moyenne).
Set your threshold duration:Vous pouvez désormais définir votre seuil d’alerte dans le contexte de la fenêtre glissante plus petite. Cela vous permet de déclencher rapidement des alertes lorsque la valeur globale de la trame actuelle s'écarte considérablement de la plage souhaitée sans sacrifier l'effet de lissage de la fenêtre plus grande.
Important
Les clients bénéficiant des plans tarifaires Advanced et Core Compute peuvent encourir des frais CCU supplémentaires lors de l'utilisation de l'agrégation de fenêtres coulissantes. Bien que cette méthode améliore l’analyse des données en atténuant les fluctuations, son utilisation peut entraîner une augmentation des coûts par rapport à d’autres méthodes. Pour plus de détails, consultez la section de tarification des fenêtres coulissantes. Pour déterminer si vous utilisez les plans tarifaires Advanced ou Core Compute, reportez-vous à votre commande.
Vous pouvez en apprendre davantage sur l’agrégation de fenêtres coulissantes dans ce didacticiel NRQL.
En général, nous recommandons d'utiliser la méthode de streaming event flow . Cette option est idéale pour les données qui arrivent fréquemment et régulièrement dans votre système. Il existe des cas spécifiques où event timer pourrait être une meilleure méthode à choisir, mais pour votre première alerte, nous recommandons notre valeur par défaut, event flow. Nous vous recommandons de regarder cette courte vidéo (environ 5:31 minutes) pour mieux comprendre quelle méthode de streaming choisir.
La fonctionnalité de retard dans la condition d'alerte protège contre les problèmes potentiels découlant d'une collecte de données incohérente. Il agit comme un tampon, laissant du temps supplémentaire aux données pour arriver et être traitées avant de déclencher une alerte. Cela permet d’éviter les faux positifs et garantit une création incident plus précise.
Comment ça marche :
Le paramètre de délai approprié est déterminé en évaluant la cohérence de vos données entrantes :
Données cohérentes : un paramètre de délai inférieur est suffisant si les points de données arrivent systématiquement avec un horodatage dans un délai d'une minute.
Données incohérentes : si les points de données arrivent avec un horodatage s'étendant sur plusieurs minutes dans le passé ou le futur, un paramètre de délai plus élevé est nécessaire pour tenir compte de l'incohérence.
Créer un tampon :
Le paramètre de délai sélectionné introduit une période d'attente avant que la condition d'alerte évalue les données par rapport au seuil défini.
Cette mémoire tampon laisse le temps aux divergences de données de se résorber, réduisant ainsi le risque d'alertes trompeuses.
Vous créez une condition d'alerte pour informer votre équipe de tout problème de latence avec l'application WebPortal. Dans cet exemple, votre application envoie systématiquement des données New Relic. Un flux constant de signaux est envoyé depuis votre application vers New Relic, et il n'y a pas d'écart prévu dans le signal, vous n'aurez donc pas besoin de sélectionner une stratégie de comblement des écarts.
Les stratégies de comblement des lacunes s’adressent aux scénarios dans lesquels la collecte de données peut être intermittente ou incomplète. Ils fournissent une méthode permettant de remplacer les points de données manquants par des valeurs estimées, garantissant que la condition d'alerte peut toujours fonctionner efficacement même avec des lacunes dans le flux de données.
Quand ne pas utiliser le remplissage des lacunes :
Consistent data flow:Si votre application envoie systématiquement des données à New Relic sans interruptions attendues, comme dans le cas de l'application WebPortal, le remplissage des interruptions est généralement inutile. Dans de tels cas, laisser la stratégie de comblement des lacunes définie sur « aucune » est souvent l’approche la plus appropriée.
Considérations clés :
Popular use case:Une utilisation courante du remplissage d’espaces vides consiste à insérer une valeur de 0 pour les fenêtres sans données reçues.
Anomaly thresholds:La valeur de remplissage des lacunes est interprétée comme le nombre d'écarts types par rapport à la dernière valeur observée lors de l'utilisation du seuil d'anomalie. Par exemple, combler les lacunes avec une valeur de 0 reproduirait la dernière valeur observée, supposant ainsi qu'il n'y ait aucun changement.
Les alertes inter-comptes dans New Relic vous permettent de configurer une condition d'alerte qui monitore les données d'un compte différent de celui sur lequel l'alerte est configurée. Cette fonctionnalité permet une plus grande flexibilité dans monitoring et la gestion des dépendances sur plusieurs comptes au sein de New Relic.
Si une condition d'alerte est un conteneur, alors les seuils sont les règles que chaque condition d'alerte doit suivre. Au fur et à mesure que les données circulent dans votre système, la condition d'alerte recherche tout incident lié à ces règles. Si la condition d'alerte voit des données de votre système qui ont rempli toutes les conditions que vous avez définies, cela créera un incident. Un incident signale que quelque chose ne va pas dans votre système et que vous devriez y prêter attention.
Les seuils d'anomalie sont idéaux lorsque vous êtes plus préoccupé par l'écart par rapport aux modèles attendus que par des valeurs numériques spécifiques. Ils vous permettent de monitorer les activités inhabituelles sans avoir à définir des limites prédéfinies. La détection d'anomalies de New Relic analyse dynamiquement vos données au fil du temps, en adaptant le seuil pour refléter l'évolution du comportement du système.
Configuration de la détection d'anomalies :
Choisissez supérieur ou inférieur :
Sélectionnez supérieur et inférieur pour être alerté de tout écart supérieur ou inférieur aux prévisions.
Sélectionnez « supérieur uniquement » pour vous concentrer uniquement sur les valeurs inhabituellement élevées.
Attribuer une priorité :
Définissez le niveau de priorité sur critique pour votre alerte initiale afin de garantir une attention prompt aux problèmes potentiels.
Définir les critères de violation :
Commencez avec les paramètres par défaut : ouvrez un incident lorsqu'une requête renvoie une valeur qui s'écarte de la valeur prédite pendant au moins cinq minutes de trois écarts types.
Personnalisez ces paramètres selon vos besoins pour les adapter à votre application spécifique et à vos exigences d'alerte.
Apprenez-en plus sur le seuil d'anomalie et les comportements du modèle dans notre documentation sur les anomalies.
Contrairement au seuil d'anomalie, un seuil statique ne considère pas votre ensemble de données dans son ensemble et détermine quel comportement est inhabituel en fonction de l'historique de votre système. Au lieu de cela, un seuil statique ouvrira un incident chaque fois que votre système se comporte différemment des critères que vous avez définis.
Vous devez définir le niveau de priorité pour l'anomalie et le seuil statique. Voir la section ci-dessus pour plus de détails.
In New Relic, entities are associated with color-coded health statuses. You can view the current state of these entities from their respective indexes and maps. When an alert condition is associated to an entity, the entity's health status is determined by the alert condition. If the alert triggers an incident, the entity's health status changes based on the incident's severity level.
If you want the alert condition to not affect the health status of the associated entity, enable the Do not report system health status toggle. This is useful when you want to monitor an entity without affecting its overall health status.
Important
When you are creating a cross-account alert condition, the Do not report system health status toggle is disabled by default. To prevent the cross-account alert condition from determining the health status of the associated entity, enable it.
Aperçu
Nous travaillons toujours sur cette fonctionnalité, mais nous aimerions que vous l'essayiez !
Cette fonctionnalité est actuellement fournie dans le cadre d'un programme d'aperçu conformément à nos politiques de pré-sortie.
Lorsque la période d'aperçu public des alertes prédictives se termine à tout moment pour une raison quelconque, votre fenêtre d'évaluation de la condition d'alerte sera uniquement évaluée par rapport au seuil statique, ce qui peut entraîner un léger retard dans la détection d'une violation d'alerte.
Predictive Alerts de New Relic analyse les données historiques pour prédire les tendances futures. Si les prévisions montrent que le seuil statique risque d'être bientôt dépassé, vous recevez une notification d'alerte, vous donnant la possibilité d'agir avant que des perturbations ne surviennent.
Pour activer les alertes prédictives pour votre condition d’alerte, procédez comme suit :
Dans la section Set condition thresholds, sélectionnez le type de condition de seuil comme Static.
Pour les alertes prédictives, activez la bascule Predict future behavior .
Définissez le temps d'anticipation. Cela indique jusqu'à quelle distance dans le futur il faut rechercher les violations prévues. Le temps d'anticipation maximal est de 360 fois la durée de la fenêtre.
Définissez le comportement de l'événement d'alerte prévu, lorsque le signal réel dépasse le seuil.
Fermez l’alerte prédite et ouvrez une alerte réelle.
Gardez l’alerte prédite ouverte pour réduire le bruit.
Le seuil de signal perdu détermine combien de temps attendre avant de considérer un signal manquant comme perdu. Si le signal ne revient pas dans ce délai, vous pouvez choisir d'ouvrir un nouvel incident ou de fermer ceux qui y sont liés. Vous pouvez également choisir d’ignorer l’ouverture d’un incident lorsqu’un signal doit se terminer. Définissez le seuil en fonction du comportement attendu de votre système et de la fréquence de collecte des données. Par exemple, si un site Web subit une perte totale de trafic, ou de débit, les données télémétriques correspondantes envoyées à New Relic cesseront également. la monitoring de cette perte de signal peut servir de système d'alerte précoce pour de telles pannes.
Ajouter des détails sur condition d'alerte
À ce stade du processus, vous disposez désormais d’une condition entièrement définie et définissez toutes les règles pour garantir qu’un incident est ouvert lorsque vous le souhaitez. En fonction des paramètres ci-dessus, si votre condition d'alerte reconnaît ce comportement dans votre système qui dépasse le seuil que vous avez défini, cela créera un incident. Il ne vous reste plus qu’à nommer cette condition et à l’associer à une politique.
La politique est le système de tri des incident. Lorsque vous créez une politique, vous créez l’outil qui organise tous vos incidents entrants. Vous pouvez connecter des politiques à workflows qui indiquent à New Relic où vous souhaitez que toutes ces informations entrantes soient envoyées, à quelle fréquence vous souhaitez qu'elles soient envoyées et où.
Les bonnes pratiques pour la dénomination des conditions impliquent un format structuré qui transmet les informations essentielles en un coup d'œil. Incluez les éléments suivants dans les noms de vos conditions :
Priorité: Indique la gravité ou l'urgence de l'alerte, comme P1, P2, P3.
Signal: Spécifiez la métrique ou la condition monitorée, comme latence moyenne élevée ou débit faible.
entité: identifiez le système, application ou le composant concerné, comme l'application WebPortal ou le serveur de base de données.
Un exemple de nom de condition bien formé suivant cette structure serait P2 | High Avg Latency | WebPortal App.
Si vous disposez déjà d’une politique que vous souhaitez connecter à une condition d’alerte, sélectionnez la politique existante.
Apprenez-en davantage sur la création de politiques ici.
Il est essentiel d'équilibrer la réactivité et la fatigue dans votre stratégie d'alerte, et vous avez défini les considérations clés concernant monitoring pageview de votre application WebPortal. Explorons les options politiques :
Un problème par politique (par défaut) :
Avantages : Réduit le bruit et assure une action immédiate.
Inconvénients : regroupe tous les incidents sous un seul problème, même s'ils sont déclenchés par des conditions différentes. Ce n'est pas idéal pour les problèmes de pages vues multiples.
Un problème par condition :
Avantages : crée des problèmes distincts pour chaque condition, idéal pour isoler et résoudre des problèmes de latence spécifiques.
Inconvénients : peut générer plus d’alertes, ce qui peut potentiellement entraîner de la fatigue.
À chaque incident son problème :
Avantages : Fournit des détails granulaires pour le système externe, mais n'est pas optimal pour la consommation interne en raison d'une surcharge potentielle.
Inconvénients : c’est l’option la plus bruyante et il est difficile de suivre les tendances plus larges et d’établir des priorités efficacement.
Apprenez-en davantage sur la création de politiques ici.
Un incident se ferme automatiquement lorsque le signal cible revient à un état de non-violation pendant la période indiquée dans le seuil de la condition. Ce temps d’attente est appelé période de récupération.
Par exemple, si vous mesurez la latence et que le comportement de violation est que duration pour charger des pages dans votre application WebPortal a augmenté de plus de 3 secondes, l'incident se fermera automatiquement lorsque duration sera égal ou inférieur à 3 secondes pendant 5 minutes consécutives.
Lorsqu'un incident se ferme automatiquement :
L'horodatage de clôture est rétroactif au début de la période de récupération.
L'évaluation se réinitialise et redémarre à partir du moment où l'incident précédent s'est terminé.
Toutes les conditions disposent d'un paramètre de limite de temps d'incident qui force automatiquement la fermeture d'un incident de longue durée.
New Relic définit automatiquement une durée de 3 jours par défaut et vous recommande d'utiliser nos paramètres par défaut pour votre première alerte.
Une autre façon de fermer un incident ouvert lorsque le signal ne renvoie pas de données est de configurer un seuil loss of signal . Reportez-vous à la section sur le seuil de perte de signal ci-dessus pour plus de détails.
Étant donné que vous créez une condition d'alerte qui vous permet de savoir s'il existe des problèmes de latence avec votre application WebPortal, vous souhaitez vous assurer que vos développeurs disposent de toutes les informations dont ils ont besoin lorsqu'ils sont informés de cet incident. Vous utiliserez le workflow pour informer un canal Slack d'équipe lorsqu'un incident est créé.
Apprenez-en plus sur les descriptions d’incidents personnalisées dans notre documentation.
L'utilisation du modèle de titre est facultative mais nous le recommandons. Une condition d'alerte définit un ensemble de seuil que vous souhaitez monitorer. Si l’un de ces seuils est dépassé, un incident est créé. Des modèles de titres significatifs vous aident à identifier les problèmes et à résoudre les pannes plus rapidement.
Apprenez-en plus sur les modèles de titres dans notre documentation.
Un runbook d'exploitation détaillant les étapes d'enquête, de triage ou de correction est souvent lié dans ce domaine.
Sélectionnez Alert Conditions dans la navigation de gauche.
Cliquez sur la condition d’alerte que vous souhaitez modifier.
De là, vous verrez la page Alert conditions details . Cette page contient tous les éléments que vous avez définis lors de la création de votre condition. Vous pouvez modifier des aspects spécifiques de la condition d'alerte en cliquant sur le crayon en haut à droite de chaque section.
Historique du signal
Sous Signal history, vous pouvez voir les résultats les plus récents de la requête NRQL que vous avez utilisée pour créer votre condition d'alerte. Pour cet exemple, vous verrez la latence moyenne sur l'application WebPortal pour la période spécifique que vous avez définie.
Pour toutes les conditions d'alerte construites avec une requête NRQL , le Signal history sera présenté avec un graphique linéaire.
Toute condition d'alerte construite avec un moniteur Synthétique sera un peu différente. Cela est dû au fait que le moniteur Synthétique vous permet de pinger votre application à partir de plusieurs emplacements, ce qui peut produire des résultats positifs ou négatifs à chaque exécution du moniteur. Ces données ne peuvent être présentées que sous forme de tableau.
Types de conditions
Le type de condition principal et recommandé est une condition d’alerte NRQL, mais il existe d’autres types de conditions. Nous avons inclus une liste complète de nos types de conditions ci-dessous.
Les alertes d'anomalie vous permettent de créer des conditions qui s'ajustent de manière dynamique aux données et aux tendances changeantes, telles que les modèles hebdomadaires ou saisonniers. Cette fonctionnalité est disponible pour les applications et , ainsi que pour les requêtesNRQL .
Vous pouvez définir des seuils qui ouvrent un incident lorsqu'ils sont violés par Java instance l'une des métriques de votre application .
En limitant le seuil à un cas spécifique, vous pouvez identifier plus rapidement l'origine des problèmes potentiels. Cela est utile, par exemple, pour détecter des anomalies qui se produisent uniquement dans un sous-ensemble de l'instance de votre application. Ces types d'anomalies sont faciles à manquer pour les applications qui sont agrégées sur un grand nombre d'instances.
Pour le moniteur d'applications Java d'APM, vous pouvez définir un seuil qui ouvre un incident lorsque la taille du tas ou le nombre de threads pour une seule JVM est hors de la plage de fonctionnement prévue.
Nous évaluons les violations du seuil d'alerte individuellement pour chacune des instances sélectionnées de l'application. Lors de la création de votre condition, sélectionnez JVM health metric comme type de condition pour la règle d'alerte de votre application Java , puis sélectionnez l'un des seuils disponibles :
Fils bloqués
Utilisation de la mémoire du tas
Temps d'utilisation du processeur
Temps CPU de collecte des déchets
L'incident se fermera automatiquement lorsque l'inverse du seuil sera atteint, mais en utilisant l'UI vous pouvez également modifier le moment où un incident se ferme de force pour une métrique de santé JVM . La valeur par défaut est 24 heures.
Nous incluons l'option permettant de définir un percentile comme seuil de votre condition lorsque le temps de réponse de votre application Web est supérieur, inférieur ou égal à cette valeur. Cela est utile, par exemple, lorsque le personnel des opérations souhaite alerter sur un percentile pour le temps de réponse Web de transactionoverall d'un serveur d'applications plutôt que sur le temps de réponse Web average.
Sélectionnez Web transactions percentiles comme type de condition pour la condition de votre application , puis sélectionnez une seule application. (Pour alerter sur plusieurs applications, créez une condition Web transactions percentiles individuelle pour chacune.)
Pour définir le seuil d'ouverture de l'incident, saisissez la valeur Percentile nth temps de réponse, puis sélectionnez sa fréquence (supérieure, inférieure ou égale à cette valeur).
Nous stockons le temps de transaction en millisecondes, bien que l'interface utilisateur affiche les valeurs critiques et d'avertissement en secondes. Si vous souhaitez définir des millisecondes, assurez-vous d'inclure le point décimal dans votre valeur.
En appliquant des étiquettes à l'application, vous pouvez automatiquement lier ces entités à votre condition. Cela facilite la gestion de toutes les applications dans un environnement dynamique. Nous vous recommandons d'utiliser le agent configuration fichier pour mieux gérer les étiquettes d'entité.
Une seule étiquette identifie all entité associée à cette étiquette (maximum 10 000 entités). Plusieurs étiquettes identifient uniquement les entités qui partagent toutes les étiquettes sélectionnées.
L'utilisation du ciblage dynamique avec votre condition nécessite également que vous définissiez un minuteur de fermeture d'incident.
Pour ajouter, modifier ou supprimer jusqu'à dix étiquettes pour une condition :
Sélectionnez APM > Application metric comme type de produit.
Lors de l'identification de l'entité, sélectionnez l'onglet Labels . Recherchez une étiquette par nom ou sélectionnez une étiquette dans la liste des catégories.
Vous pouvez également créer des conditions directement dans le contexte de ce que vous monitoring avec l'infrastructure.
Par exemple, pour obtenir une notification lorsqu'un agent d'infrastructure cesse de recevoir des données, utilisez le type de condition hôte ne signalant pas . Cela vous permet d'alerter dynamiquement sur des groupes d'hôtes filtrés et de configurer la fenêtre temporelle de 5 à 60 minutes.
Dans la liste des conditions d'alerte, cliquez sur l'icône à trois points de l'alerte que vous souhaitez copier et sélectionnez Duplicate condition.
À partir de Copy alert condition, recherchez ou faites défiler la liste pour sélectionner la politique à laquelle vous souhaitez ajouter cette condition.
Facultatif : modifiez le nom de la condition si nécessaire.
Facultatif : cliquez sur l'interrupteur à bascule pour Enable on save
Sélectionnez Copy condition.
Par défaut, la règle d'alerte sélectionnée ajoutera la condition copiée dans l'état Désactivé . Suivez les procédures standard pour ajouter ou copier davantage de conditions à la règle d'alerte, puis activez la condition selon vos besoins. De plus, la nouvelle condition ne copiera aucune balise ajoutée à la condition d'origine.
Activer/désactiver une condition
Pour désactiver ou réactiver une condition :
Allez à one.newrelic.com > All capabilities > Alerts > Alert Conditions. Ensuite, dans la liste de Alert conditions, utilisez la bascule pour activer ou désactiver la condition.
Cliquez sur le commutateur On/Off pour l'activer.
Si vous copiez une condition, elle est automatiquement enregistrée dans la nouvelle politique comme désactivée (Off), même si la condition était activée (On) dans la politique d'origine.
Supprimer une condition
Pour désactiver une condition tout en la conservant dans la politique, désactivez -la. Pour supprimer une ou plusieurs conditions :
Dans la liste de Alert conditions, sélectionnez une condition, puis cliquez sur Delete dans le menu à ellipses (...).
Conseil
Si vous ne voyez pas le bouton Supprimer, il se peut que l'administrateur de votre compte ait désactivé la suppression des conditions pour votre organisation.
Dépanner la page de condition d'alerte
Si vous voyez un signal vide dans le graphique historique sur la page Alert Condition, envisagez l'une des solutions suivantes :
Review the condition's settings:Vérifiez que tous les éléments sont correctement configurés.
Inspect NRQL queries: Assurez-vous qu'ils ciblent des métriques ou des événements valides et renvoient des données.
Examine entity configuration: Confirmez que l’entité est correctement configurée pour envoyer des signaux.
Consult New Relic documentation:Reportez-vous aux guides pertinents pour obtenir de l’aide sur des problèmes spécifiques.
