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 événement d'alerte est créé. Il constitue le point de départ essentiel pour créer toute alerte pertinente. Les conditions d'alerte contiennent les paramètres ou les seuils atteints avant que vous ne soyez informé. Ils peuvent atténuer les alertes excessives ou informer votre équipe lorsque des comportements nouveaux ou inhabituels apparaissent.
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 événement d'alerte lorsque le seuil est atteint pour 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.
/ <img title="définir une requête" alt="Une capture d'écran montrant à un utilisateur comment définir le comportement du signal pour une condition d'alerte." src="/images/alerts_screenshot-crop_set-a-query.webp" /> /
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.
/ <img title="affiner les paramètres d'alerte" alt="Une capture d'écran illustrant les paramètres avancés des signaux." src="/images/alerts_screenshot-crop_fine-tune-alert-signals.webp" /> /
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 délai dans les conditions d'alerte protège contre les problèmes potentiels découlant d'une collecte de données incohérente. Il agit comme un tampon, accordant un délai supplémentaire pour que les données arrivent et soient traitées avant de déclencher une alerte. Cela permet d'éviter les faux positifs et garantit une création plus précise des événements d'alerte.
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 respecter. À mesure que les données affluent dans votre système, la condition d'alerte recherche tout événement d'alerte lié à ces règles. Si la condition d'alerte détecte des données de votre système répondant à toutes les conditions que vous avez définies, elle créera un événement d'alerte. Un événement d'alerte signale que quelque chose ne va pas dans votre système et que vous devriez vérifier.
/ <img title="définir un seuil" alt="Une capture d'écran illustrant comment définir le seuil d'une condition d'alerte." src="/images/alerts_screenshot-crop_set-a-threshold-for-an-alert-condition.webp" /> /
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 par les paramètres par défaut : ouvrez un événement d'alerte lorsqu'une requête renvoie une valeur qui s'écarte de la valeur prévue de trois écarts-types pendant au moins cinq minutes.
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 aux seuils d'anomalie, un seuil statique n'examine pas votre jeu de données dans son ensemble et ne détermine pas quel comportement est inhabituel en se basant sur l'historique de votre système. Au lieu de cela, un seuil statique ouvrira un événement d'alerte chaque fois que votre système se comportera 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.
La détection des valeurs hors norme identifie les entités qui se comportent de manière significativement différente de leurs pairs à un moment précis. Contrairement à la détection d'anomalies qui recherche des schémas inhabituels au fil du temps, la détection de valeurs hors norme se concentre sur la déviation au sein d'un groupe en utilisant le cluster DBSCAN.
Ce type de seuil est idéal pour :
Identification des serveurs présentant une consommation de ressources inhabituelle par rapport à leur cluster
Détection des brokers Kafka ne traitant pas correctement les messages
Détection des scénarios de « voisin bruyant » dans les environnements multi-locataires
Principaux paramètres de configuration :
Epsilon: Distance maximale entre les points d'un même cluster
Points min. : Points minimums requis pour former un cluster (recommandé > 3)
Groupes d'évaluation: Analyse segmentée par facettes telles que l'environnement ou la région
Dans New Relic, les entités sont associées à des statuts de santé codés par couleur. Vous pouvez consulter l'état actuel de ces entités à partir de leurs index et cartes respectifs. Lorsqu'une condition d'alerte est associée à une entité, l'état de santé de l'entité est déterminé par la condition d'alerte. Si l'alerte déclenche un événement d'alerte, l'état de santé de l'entité change en fonction du niveau de gravité de l'événement d'alerte.
Si vous souhaitez que la condition d’alerte n’affecte pas l’état de santé de l’entité associée, activez la bascule Do not report system health status . Ceci est utile lorsque vous souhaitez monitorer une entité sans affecter son état de santé général.
Important
Lorsque vous créez une condition d'alerte inter-comptes, la bascule Do not report system health status est désactivée par défaut. Pour empêcher la condition d’alerte inter-comptes de déterminer l’état de santé de l’entité associée, activez-la.
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 perte de signal détermine la durée d'attente 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 événement d'alerte ou de fermer tout événement associé. Vous pouvez également choisir d'ignorer l'ouverture d'un événement d'alerte lorsqu'un signal est censé 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 de télémétrie correspondantes envoyées à New Relic cesseront également. Le 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 avez configuré toutes les règles pour garantir qu'un événement d'alerte soit ouvert lorsque vous le souhaitez. En fonction des paramètres ci-dessus, si votre condition d'alerte détecte ce comportement dans votre système franchissant les seuils que vous avez définis, elle créera un événement d'alerte. Maintenant, il vous suffit de nommer cette condition et de l'associer à une stratégie.
La stratégie est le système de tri pour l'événement d'alerte. Lorsque vous créez une stratégie, vous créez l'outil qui organise tous vos événements d'alerte entrants. Vous pouvez connecter des politiques à workflows qui indiquent à New Relic où vous souhaitez acheminer toutes ces informations entrantes, à quelle fréquence vous souhaitez qu'elles soient envoyées et où.
/ <img title="nommer une condition d'alerte " alt="Une capture d'écran montrant comment créer une nouvelle condition d'alerte." src="/images/alerts_screenshot-crop_name-your-alert-condition.webp" /> /
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.
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 événements d'alerte 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ématiques 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.
Un problème pour chaque événement d'alerte :
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.
Un événement d'alerte se ferme automatiquement lorsque le signal ciblé revient à un état de non-violation pendant la période indiquée dans les seuils de la condition. Ce temps d'attente est appelé la période de rétablissement.
Par exemple, si vous mesurez la latence et que le comportement de violation indique que duration pour charger les pages dans votre application WebPortal a augmenté à plus de 3 secondes, l'événement d'alerte se fermera automatiquement lorsque duration sera inférieur ou égal à 3 secondes pendant 5 minutes consécutives.
Lorsqu'un événement d'alerte 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'événement d'alerte précédent s'est terminé.
Toutes les conditions disposent d'un paramètre de limite de temps d'événement d'alerte qui force automatiquement la fermeture d'un événement d'alerte 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 événement d'alerte ouvert lorsque le signal ne renvoie pas de données consiste à configurer un seuil de loss of signal. Reportez-vous à la section sur le seuil de signal perdu ci-dessus pour plus de détails.
Puisque vous créez une condition d'alerte qui vous permet de savoir s'il y a des problèmes de latence avec votre application WebPortal, vous voulez vous assurer que vos développeurs disposent de toutes les informations dont ils ont besoin lorsqu'ils sont notifiés de cet événement d'alerte. Vous utiliserez des workflows pour notifier un canal Slack d'équipe lorsqu'un événement d'alerte est créé.
En savoir plus sur les descriptions personnalisées d'événements d'alerte dans notre documentation.
/ <img title="page des détails de l'alerte" alt="Une capture d'écran illustrant la dernière étape de la création d'une condition d'alerte : la page des détails de l'alerte" src="/images/alerts_screenshot-crop_adding-alert-details-to-an-alert-condition.webp" /> /
L'utilisation du modèle de titre est facultative, mais nous la recommandons. Une condition d'alerte définit un ensemble de seuils que vous souhaitez monitorer. Si l'un de ces seuils est dépassé, un événement d'alerte est créé. Des modèles de titre pertinents 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 événement d'alerte lorsqu'ils sont franchis par l'une des métriques d'instance de votre application Java.
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 les applications Java monitorées par APM, vous pouvez définir des seuils qui ouvrent un événement d'alerte 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 dépassements de 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 politique 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
les événements d'alerte se fermeront automatiquement lorsque l'inverse du seuil sera atteint, mais en utilisant l'interface utilisateur, vous pouvez également modifier le moment où un événement d'alerte se ferme de force pour une métrique de santé de la JVM. La valeur par défaut est de 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 les seuils qui déclenchent l'événement d'alerte, saisissez la valeur du temps de réponse Percentile nth, 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.
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 politique d'alerte sélectionnée ajoutera la condition copiée à l'état Disabled. Suivez les procédures standard pour ajouter ou copier d'autres conditions dans la politique d'alerte, puis Enable la condition au besoin. De plus, la nouvelle condition ne copiera pas les tags ajoutés à 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.
