Créer une condition d'alerte NRQL

Nous vous recommandons de créer une alerte à l'aide d'une condition d'alerte NRQL . Ce document vous guidera dans le formatage et la configuration de votre condition d'alerte NRQL pour maximiser l'efficacité et réduire le bruit. Si vous venez de commencer avec New Relic, ou si vous n'avez pas encore créé de condition d'alerte, nous vous recommandons de commencer par la condition d'alerte.

Vous pouvez créer une condition d'alerte à partir de :

• Un graphique
• Une page de politique
• La page Alert coverage gaps

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 choisir parmi les options recommandées et faire créer votre requête NRQL pour vous.

Peu importe où vous commencez à créer une condition d'alerte, que ce soit via un graphique ou en écrivant votre propre requête, NRQL est la pierre angulaire sur laquelle vous pouvez définir votre signal et définir votre seuil.

Syntaxe d'alerte NRQL

Voici la syntaxe de base pour créer toutes les conditions d'alerte NRQL .

SELECT function(attribute)
FROM Event
WHERE attribute [comparison] [AND|OR ...]

Reformatage NRQL incompatible

Certains éléments de NRQL utilisés dans les graphiques n'ont pas de sens dans le contexte des alertes en streaming. Voici une liste des éléments incompatibles les plus courants et des suggestions pour reformater une requête d'alerte NRQL afin d'obtenir le même effet.

SELECT percentile(largestContentfulPaint, 75)
FROM PageViewTiming
WHERE (appId = 837807) SINCE yesterday

SELECT count(foo), average(bar), max(baz)
FROM Transaction

SELECT count(foo) FROM Transaction

SELECT average(bar) FROM Transaction

SELECT max(baz) FROM Transaction

SELECT count(*)
FROM Transaction
TIMESERIES 1 minute SLIDE BY 5 minutes

Exemples de seuil d'alerte NRQL

Voici quelques cas d’utilisation courants pour les conditions NRQL. Ces requêtes fonctionneront pour les types de conditions statiques et d'anomalie.

SELECT average(duration)
FROM Transaction
WHERE account_id IN (91290, 102021, 20230)

SELECT percentile(duration, 95)
FROM Transaction
WHERE name LIKE 'Controller/checkout/%'

SELECT percentile(duration, 95)
FROM Transaction

SELECT percentile(databaseDuration, 75)
FROM Transaction

SELECT max(duration)
FROM Transaction

SELECT min(duration)
FROM Transaction

SELECT average(duration)
FROM Transaction

SELECT percentage(count(*), WHERE duration > 2)
FROM Transaction

SELECT percentage(count(*), WHERE http.statusCode = '500')
FROM Transaction

SELECT apdex(duration, t:0.5)
FROM Transaction
WHERE appName LIKE '%prod%'

Conditions NRQL et ordre des opérations de requête

Par défaut, la durée de la fenêtre d'agrégation est de 1 minute, mais vous pouvez modifier la fenêtre en fonction de vos besoins. Quelle que soit la fenêtre d'agrégation, New Relic collectera les données pour cette fenêtre à l'aide de la fonction dans la requête de la condition NRQL. La requête est analysée et exécutée par notre système dans l'ordre suivant :

1. FROM clause. Quel type d’événement doit être saisi ?
2. WHERE clause. Que peut-on filtrer ?
3. SELECT clause. Quelles informations doivent être renvoyées à partir de l’ensemble de données désormais filtré ?

Exemple : valeur nulle renvoyée

Disons que c'est votre requête de condition d'alerte :

SELECT count(*)
FROM SyntheticCheck
WHERE monitorName = 'My Cool Monitor' AND result = 'FAILED'

S'il n'y a aucun échec pour la fenêtre d'agrégation :

1. Le système exécutera la clause FROM en récupérant tous les SyntheticCheck événements sur votre compte.
2. Ensuite, il exécutera la clause WHERE pour filtrer ces événements en recherchant uniquement ceux qui correspondent au nom du moniteur et au résultat spécifié.
3. S'il reste des événements à analyser après avoir terminé les opérations FROM et WHERE , la clause SELECT sera exécutée. S'il n'y a aucun événement restant, la clause SELECT ne sera pas exécutée.

Cela signifie que les agrégateurs comme count() et uniqueCount() ne renverront jamais une valeur nulle. Lorsqu'il y a un compte de 0, la clause SELECT est ignorée et aucune donnée n'est renvoyée, ce qui donne une valeur de NULL.

Exemple : valeur zéro renvoyée

Si vous disposez d'une source de données fournissant des zéros numériques légitimes, la requête renverra des valeurs zéro et non des valeurs nulles.

Disons qu’il s’agit de votre requête de condition d’alerte et que MyCoolEvent est un attribut qui peut parfois renvoyer une valeur zéro.

SELECT average(MyCoolAttribute)
FROM MyCoolEvent

Si, dans la fenêtre d'agrégation en cours d'évaluation, il existe au moins une instance de MyCoolEvent et si la valeur moyenne de tous les attributs MyCoolAttribute de cette fenêtre est égale à zéro, alors une valeur 0 sera renvoyée. S'il n'y a aucun événement MyCoolEvent pendant cette minute, un NULL sera renvoyé en raison de l'ordre des opérations.

Exemple : valeur nulle ou valeur zéro renvoyée

Pour déterminer comment les valeurs nulles seront gérées, ajustez les paramètres de perte de signal et de remplissage d'espace dans l'UI de condition d'alerte.

Vous pouvez éviter les valeurs NULL avec un raccourci d'ordre des opérations de requête. Pour ce faire, utilisez une sous-clause filter , puis incluez tous les éléments de filtre dans cette sous-clause. Le corps principal de la requête doit inclure une clause WHERE qui définit au moins une entité afin que, pour toute fenêtre d'agrégation où le moniteur effectue une vérification, le signal soit lié à cette entité. La clause SELECT s'exécutera ensuite et appliquera les éléments de filtre aux données renvoyées par le corps principal de la requête, qui renverra une valeur de 0 si les éléments de filtre ne génèrent aucune donnée correspondante.

Voici un exemple pour alerter sur FAILED résultats :

SELECT filter(count(*), WHERE result = 'FAILED')
FROM SyntheticCheck
WHERE monitorName = 'My Favorite Monitor'

Dans cet exemple, une fenêtre avec un résultat réussi renverrait un 0, permettant au seuil de la condition de se résoudre de lui-même.

Pour plus d'informations, consultez notre article de blog sur le dépannage des valeurs zéro et nulles.

Alertes NRQL d'agrégation imbriquée

Les requêtes d'agrégation imbriquées sont un moyen puissant d'interroger vos données. Cependant, ils comportent quelques restrictions qu’il est important de noter.

SELECT max(cpu)
FROM
  (
    SELECT min(cpuPercent) AS 'cpu'
    FROM SystemSample
    FACET hostname
  )

SELECT max(cpu)
FROM
  (
    SELECT min(cpuTime) AS cpu TIMESERIES 30 seconds
    FROM Event
  )

Conseils de création de conditions NRQL

Voici quelques conseils pour créer et utiliser une condition NRQL :

Gestion des balises sur les conditions

Lorsque vous modifiez une condition NRQL existante, vous avez la possibilité d'ajouter ou de supprimer une balise associée à l'entité de condition. Pour ce faire, cliquez sur le bouton Manage tags sous le nom de la condition. Dans le menu qui apparaît, ajoutez ou supprimez une tag.

Les modifications de condition peuvent réinitialiser l'évaluation de la condition

Lorsque vous modifiez la condition d'alerte NRQL de certaines manières spécifiques (détaillées ci-dessous), leurs évaluations sont réinitialisées, ce qui signifie que toute évaluation jusqu'à ce point est perdue et l'évaluation recommence à partir de ce point. Les deux façons dont cela vous affectera sont :

• Pour les seuils "pendant au moins x minutes" : la fenêtre d'évaluation ayant été réinitialisée, il y aura un délai d'au moins x minutes avant que des événements d'alerte ne puissent être signalés.
• Pour les conditions d'anomalie: la condition recommence et tout apprentissage d'anomalie est perdu.

Les actions suivantes entraînent une réinitialisation de l'évaluation des conditions NRQL :

• Modification de la requête
• Modification de la fenêtre d'agrégation, de la méthode d'agrégation ou du paramètre de délai/minuterie d'agrégation
• Modification du paramètre « clôturer les événements d'alerte en cas de perte de signal »
• Modification des paramètres de remplissage des espaces
• Modification de la direction de l'anomalie (le cas échéant) - plus haut, plus bas ou plus haut/plus bas
• Modifier la valeur de seuil, la fenêtre de seuil ou l'opérateur de seuil
• Modifier l'intervalle de défilement (uniquement sur les conditions d'agrégation des fenêtres glissantes )

Les actions suivantes (ainsi que toutes les autres actions non couvertes dans la liste ci-dessus) ne réinitialiseront pas l'évaluation :

• Modification de la fenêtre temporelle de perte de signal (durée d'expiration)
• Modification de la fonction de temps (passage de « pendant au moins » à « au moins une fois dans » ou vice-versa)
• Basculer le paramètre "ouvrir un événement d'alerte en cas de perte de signal"

Types de conditions d'alerte

Lorsque vous créez une alerte NRQL, vous pouvez choisir parmi différents types de conditions :

Définir le seuil de perte de signal

La perte de signal se produit lorsqu'aucune donnée ne correspond à la condition NRQL sur une période de temps spécifique. Vous pouvez définir la durée de votre seuil de perte de signal ainsi que ce qui se passe lorsque le seuil est dépassé.

/ <img width="80%" title="signal loss options" alt="screenshot of signal loss options" src="/images/queriesnrqlSignalLossOptions.webp" /> /

Vous pouvez également gérer ces paramètres à l'aide de l'API GraphQL (recommandé) ou de l'API REST. Cliquez ici pour des exemples spécifiques d'API GraphQL.

Loss of signal settings:

Les paramètres de perte de signal incluent une durée et quelques actions.

• Signal loss expiration time

  • Étiquette UI : Signal is lost after:
  • Nœud GraphQL : expiration.expirationDuration
  • La durée d’expiration est un minuteur qui démarre et se réinitialise lorsque nous recevons un point de données dans le pipeline d’alertes en streaming. Si nous ne recevons pas un autre point de données avant l’expiration de votre « délai d’expiration », nous considérons que ce signal est perdu. Cela peut être dû au fait qu'aucune donnée n'est envoyée à New Relic ou que la clause WHERE de votre requête NRQL filtre ces données avant qu'elles ne soient transmises au pipeline d'alertes. Notez que lorsque vous avez une requête à facettes, chaque facette est un signal. Ainsi, si l’un de ces signaux se termine pendant la durée spécifiée, cela sera considéré comme une perte de signal.
  • La perte du temps d'expiration du signal est indépendante de la durée du seuil et se déclenche dès que le temporisateur expire.
  • La durée d'expiration maximale est de 48 heures. Cela est utile lors de monitoring de l’exécution de tâches peu fréquentes. Le minimum est de 30 secondes, mais nous recommandons d'utiliser au moins 3 à 5 minutes.

• Loss of signal actions

  Une fois qu'un signal est considéré comme perdu, vous avez plusieurs options :

  • Fermer tous les événements d'alerte actuellement ouverts : cela ferme tous les événements d'alerte ouverts liés à un signal spécifique. Cela ne fermera pas nécessairement tous les événements d'alerte pour une condition. Si vous configurez une alerte sur un service éphémère ou un signal sporadique, choisissez cette action pour garantir que les événements d'alerte soient correctement fermés. Le nom du nœud GraphQL pour cela est closeViolationsOnExpiration.
  • Ouvrir de nouveaux événements d'alerte : cela ouvrira un nouvel événement d'alerte lorsque le signal est considéré comme perdu. Ces événements d'alerte indiqueront qu'ils sont dus à une perte de signal. En fonction de vos préférences d'événements d'alerte, cela devrait déclencher une notification. Le nom du nœud graphQL pour cela est openViolationOnExpiration.
  • Lorsque vous activez les deux actions ci-dessus, nous fermons d'abord tous les événements d'alerte ouverts, puis nous ouvrons un nouvel événement d'alerte pour perte de signal.
  • Ne pas ouvrir d'événements d'alerte "signal perdu" lors d'un arrêt prévu. Lorsqu'un signal est censé se terminer, vous pouvez choisir de ne pas ouvrir de nouvel événement d'alerte. Cela est utile lorsque vous savez qu'un signal sera perdu à un moment donné et que vous ne souhaitez pas ouvrir un nouvel événement d'alerte pour cette perte de signal. Le nom du nœud GraphQL pour cela est ignoreOnExpectedTermination.

Pour créer une alerte NRQL configurée avec détection de perte de signal dans l'UI:

1. Suivez les instructions pour créer une condition d’alerte NRQL.
2. À l’ étapeSet thresholds , vous trouverez l’option Add lost signal threshold. Cliquez sur ce bouton.
3. Définissez la durée d’expiration du signal en minutes ou en secondes dans le champ Consider the signal lost after .
4. Choisissez ce qui doit se passer lorsque le signal est perdu. Vous pouvez cocher l'une ou la totalité des options suivantes : Close all current open alert events, Open new "lost signal" alert event, Do not open "lost signal" alert event on expected termination. Ceux-ci contrôlent la manière dont les événements d'alerte de perte de signal seront traités pour la condition.
5. Vous pouvez éventuellement ajouter ou supprimer un seuil numérique statique/anomalie. Une condition qui n'a qu'un seuil de perte de signal et aucun seuil numérique statique/anomalie est valide et est considérée comme une condition de perte de signal « autonome ».

6. Continuez à suivre les étapes pour sauvegarder votre état.
7. Si vous avez sélectionné Do not open "lost signal" alert event on expected termination, vous devez ajouter le tag termination: expected à l'entité pour empêcher l'ouverture d'un événement d'alerte de perte de signal. Voir comment ajouter le tag directement à l'entité.

Les événements d'alerte ouverts suite à une perte de signal se ferment lorsque :

• le signal revient. Les événements d'alerte de perte de signal nouvellement ouverts se fermeront immédiatement lorsque de nouvelles données seront évaluées.
• l'état auquel ils appartiennent expire. Par défaut, les conditions expirent après 3 jours.
• vous fermez manuellement l'événement d'alerte avec l'option Close all current open alert events.

Paramètres avancés du signal

Lors de la création d'une condition NRQL, il existe plusieurs paramètres de signal avancés:

• Durée de la fenêtre d'agrégation
• Agrégation de fenêtres coulissantes
• Méthode de diffusion en continu
• Retard/minuterie
• Combler les lacunes en matière de données
• Retard d'évaluation

Pour lire une explication de ce que sont ces paramètres et de la manière dont ils sont liés les uns aux autres, consultez Concepts des alertes en streaming. Vous trouverez ci-dessous des instructions et des conseils sur la façon de les configurer.

Durée de la fenêtre d'agrégation

Vous pouvez définir la durée de la fenêtre d'agrégation pour choisir la durée pendant laquelle les données sont accumulées dans une fenêtre de temps de streaming avant d'être agrégées. Vous pouvez le régler entre 30 secondes et 120 minutes. La valeur par défaut est d'une minute.

Agrégation de fenêtres coulissantes

Vous pouvez utiliser des fenêtres coulissantes pour créer des graphiques plus fluides. Cela se fait en créant des fenêtres de données qui se chevauchent.

Apprenez à configurer des fenêtres coulissantes dans cette courte vidéo (2:30 minutes) :

Une fois activé, définissez le « diaporama par intervalle » pour contrôler le temps de chevauchement de vos fenêtres agrégées. L'intervalle doit être plus court que la fenêtre d'agrégation tout en étant divisé uniformément dans celle-ci.

Méthode de diffusion en continu

Choisissez entre trois méthodes d’agrégation de streaming pour obtenir les meilleurs résultats d’évaluation pour vos conditions.

Retard/minuterie

Vous pouvez ajuster le délai/la minuterie pour coordonner notre algorithme d'alerte en streaming avec le comportement de vos données. Si vos données sont rares ou incohérentes, vous pouvez utiliser la méthode d’agrégation du minuteur d’événement.

Pour la méthode de cadence, la latence totale prise en charge est la somme de la durée de la fenêtre d'agrégation et du délai.

Si le type de données provient d'un de APM langage agent et est agrégé à partir de plusieurs instances d'application (par exemple,,, Transaction TransactionErroretc.), nous vous recommandons d'utiliser la méthode de flux d'événement avec les paramètres par défaut.

Combler les lacunes en matière de données

Le remplissage des lacunes vous permet de personnaliser les valeurs à utiliser lorsque vos signaux ne contiennent aucune donnée. Vous pouvez combler les lacunes dans vos flux de données avec l’un de ces paramètres :

• None: (Par défaut) Sélectionnez cette option si vous ne souhaitez effectuer aucune action sur les fenêtres d'agrégation vides. Lors de l'évaluation, une fenêtre d'agrégation vide réinitialise le minuteur de durée du seuil. Par exemple, si une condition stipule que toutes les fenêtres d'agrégation doivent contenir des points de données supérieurs au seuil pendant 5 minutes, et que l'une des 5 fenêtres d'agrégation est vide, alors la condition ne constituera pas un événement d'alerte.
• Custom static value: Choisissez cette option si vous souhaitez insérer une valeur statique personnalisée dans les fenêtres d’agrégation vides avant qu’elles ne soient évaluées. Cette option dispose d'un paramètre supplémentaire obligatoire de fillValue (comme nommé dans l'API) qui spécifie quelle valeur statique doit être utilisée. La valeur par défaut est 0.
• Last known value:Cette option insère la dernière valeur vue avant que l'évaluation ne se produise. Nous maintenons l'état de la dernière valeur vue pendant un minimum de 2 heures. Si la durée du seuil configurée est supérieure à 2 heures, cette valeur est conservée pendant cette durée.

Options de modification des paramètres d’écart de données :

• Dans l’ des NRQL conditions UI, accédez à Condition settings > Advanced signal settings > fill data gaps with et choisissez une option.
• Si vous utilisez notre API Nerdgraph (préféré), ce nœud est situé à : actor : account : alerts : nrqlCondition : signal : fillOption | fillValue
• NerdGraph est notre recommandée API pour cela, mais si vous utilisez notre API REST, vous pouvez trouver ce paramètre dans API l'explorateur REST sous la "signal" section de l'des NRQL conditions d'alerte .API

Retard d'évaluation

Vous pouvez activer l'indicateur Use evaluation delay et définir jusqu'à 120 minutes pour retarder l'évaluation des signaux entrants.

Lorsqu’une nouvelle entité est déployée pour la première fois, l’utilisation des ressources de l’entité est souvent inhabituellement élevée. Dans les environnements de mise à l'échelle automatique, cela peut facilement créer de nombreuses fausses alertes. En retardant le démarrage de la détection des alertes sur les signaux émis par la nouvelle entité, vous pouvez réduire considérablement le nombre de fausses alarmes associées au déploiement dans des environnements orchestrés ou autoscale.

Options pour activer le délai d’évaluation :

• Dans l’ des NRQL conditions UI, accédez Adjust to signal behavior > Use evaluation delay à.
• Si vous utilisez notre API Nerdgraph, ce nœud est situé à : actor : account : alerts : nrqlCondition : signal : evaluationDelay

Conditions HNR NRQL en mode guidé

Le mode guidé des conditions NRQL offre une expérience organisée pour la création de conditions NRQL d'infrastructure « hôte ne signalant pas » (HNR). Il s'agit de l'alternative préférée à la création de conditions d'infrastructure « hôte sans rapport ».