Créez votre première alerte

Tout d’abord, accédez au graphique intitulé Web transactions time et cliquez sur create an alert condition.

Il est important de donner à votre condition d’alerte un nom descriptif. Disons que vous nommez cette condition response time , puis que vous créez une autre condition pour une application complètement différente et que vous nommez également cette condition response time . Si cela se produit, vous ne serez pas en mesure de distinguer quelle condition correspond à quelle application. Assurez-vous donc de donner à votre condition un nom spécifique et unique. Dans ce cas, nous nommerions cette condition Response time: Example-app.

Une fois que vous avez nommé votre condition, vous pouvez apporter des modifications à la requête NRQL si vous le souhaitez. Pour votre première alerte, nous vous recommandons de ne pas ajuster la requête NRQL et de laisser cette section telle quelle, mais si vous souhaitez en savoir plus sur la façon d'utiliser NRQL pour personnaliser votre requête, visitez notre documentation.

Votre équipe crée cette condition d'alerte afin que vous soyez averti si le temps de transaction Web prend plus de temps que d'habitude. Mais disons que vous ne vous souciez pas de la durée de transaction Web supplémentaire et que vous souhaitez simplement savoir si le temps de transaction se comporte de manière anormale. Pour ce cas d'utilisation spécifique, nous vous recommandons d'utiliser notre anomaly threshold. Notre détection d'anomalies évalue en permanence vos données pour comprendre comment votre système se comporte normalement. En définissant un seuil d'anomalie, vous pouvez utiliser notre détection d'anomalie pour alerter votre équipe si le temps Web de transaction s'écarte de ses performances attendues. Étant donné que vous souhaitez uniquement savoir si le temps de transaction Web se comporte de manière inhabituelle, vous devez sélectionner upper and lower car vous souhaitez être informé de tout écart. Mais si vous souhaitez uniquement recevoir des alertes si les délais de transaction sur le Web prennent plus de temps que d'habitude, vous devez sélectionner upper only.

Ensuite, vous devez définir le niveau de priorité. Le niveau de priorité détermine ce qui créera un événement d'alerte. Nous vous recommandons de définir votre niveau de priorité sur critical pour votre première alerte. Vous pouvez en savoir plus sur les niveaux de priorité dans notre documentation sur les conditions d'alerte.

Ensuite, vous devez choisir ce qui définit un critical anomaly threshold breach. Pour cette première alerte, nous recommandons d'utiliser nos paramètres par défaut et de les ajuster selon vos besoins si nécessaire. Laissez donc les paramètres pour ouvrir un événement d'alerte "lorsqu'une requête renvoie une valeur s'écartant de la valeur prédite : for at least five minutes de 3 standard deviations".

Apprenez-en plus sur les anomalies dans notre documentation sur les anomalies.

/ <img title="Configure your anomaly thresholds" alt="A screenshot demonstrating how to configure custom anomalies" src="/images/alerts_screenshot-crop_configure-your-anomaly-thresholds.webp" /> /

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. Les seuils d'alerte statiques sont beaucoup plus personnalisables, et nous les recommandons si vous avez une connaissance approfondie de vos données et de ce que vous recherchez.

Apprenez-en plus sur notre condition d'alerte statique dans notre documentationNRQL .

Parfois, un signal entrant peut être perdu, et il est important de comprendre s'il s'agit simplement d'un retard ou de l'indication d'un problème plus large. Notre lost signal threshold nous indique combien de secondes le système doit attendre depuis la détection du dernier point de données avant de considérer le signal comme perdu. Si le signal ne revient pas avant le délai que vous avez défini, vous avez plusieurs options : ouvrir un nouvel événement d'alerte, fermer tous les événements d'alerte ouverts et/ou ignorer l'ouverture d'un événement d'alerte lorsque le signal est censé se terminer. Cliquez ici pour en savoir plus sur vos options de seuil de perte de signal.

La définition de votre seuil de signal perdu nécessite une connaissance de votre système et de ce que vous cherchez à comprendre. Dans le cas du temps de transaction Web, disons que New Relic collecte un signal toutes les minutes. Un signal perdu pourrait indiquer un problème de latence beaucoup plus important. Nous vous recommandons donc de régler l'heure en fonction de votre niveau de confort, puis de cocher la case open a new lost signal alert event.

/ <img title="" alt="" src="/images/alerts_screenshot-crop_lost-signal-threshold.webp"/> /

/ <img title="Window duration" alt="A screenshot depicting advanced custom settings for an alert condition." src="/images/alerts_screenshot-crop_window-duration.webp" /> /

La définition de la durée de la fenêtre pour votre condition d'alerte indique New Relic comment regrouper vos données. Si vous créez une condition d'alerte pour un ensemble de données qui envoie un signal à New Relic une fois par heure, vous souhaiterez définir la durée de la fenêtre sur une valeur plus proche de soixante minutes, car cela aidera à repérer les modèles et les comportements inhabituels. Mais si vous créez une condition d'alerte pour le temps de transaction Web et New Relic collecte un signal pour ces données toutes les minutes, nous vous recommandons de définir la durée de la fenêtre sur une minute.

Pour votre première alerte, nous vous recommandons de vous en tenir à nos paramètres par défaut, mais à mesure que vous vous familiariserez avec la création d'une condition d'alerte, nous vous encourageons à personnaliser ces champs en fonction de votre propre expérience.

Tout au long de la journée, les données affluent de votre application vers New Relic. Au lieu d'évaluer ces données immédiatement pour des événements d'alerte, les conditions d'alerte collectent les données sur une période de temps appelée aggregation window. Un délai supplémentaire permet aux points de données plus lents d'arriver avant que la fenêtre ne soit agrégée.

Les fenêtres coulissantes sont utiles lorsque vous avez besoin de lisser des graphiques « en pointe ». Un cas d'utilisation courant consiste à utiliser des fenêtres glissantes pour lisser les graphiques linéaires qui présentent de nombreuses variations sur de courtes périodes de temps dans les cas où l'agrégat glissant est plus important que les agrégats provenant de fenêtres temporelles étroites.

Nous vous recommandons d'utiliser notre agrégation de fenêtres glissantes si vous ne vous attendez pas à avoir un flux de données constant et cohérent, mais que vous vous attendez à des baisses et des pics de données.

Vous pouvez en apprendre davantage sur l’agrégation de fenêtres glissantes dans ce didacticiel NRQL ou en regardant cette vidéo.

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. Pour mieux comprendre quelle méthode de streaming choisir, nous vous recommandons de regarder cette courte vidéo.

La fonctionnalité de délai vous protège contre une collecte de données incohérente. Cela donne à la condition d'alerte une petite marge de manœuvre avant de décider de créer un événement d'alerte. Si, au cours d'une minute donnée, vos données arrivent dans New Relic avec des horodatages provenant d'une seule minute, alors un paramètre de délai faible est suffisant. En revanche, si au cours de cette minute New Relic reçoit des points de données avec des horodatages de plusieurs minutes dans le passé ou le futur, alors votre signal est plus incohérent et nécessitera un réglage de délai plus élevé.

Nous créons une condition d'alerte pour informer notre équipe de tout problème de latence avec le temps de transaction Web. Dans ce cas, notre application envoie systématiquement des données New Relic. Il y a un flux constant de signaux envoyés depuis notre application vers New Relic et il n'y a pas d'écart prévu dans le signal, nous n'aurons donc pas besoin de sélectionner une stratégie de comblement des écarts. Pour ce cas d'utilisation, et pour votre première alerte, nous vous recommandons de laisser le gap-filling strategy défini sur none.

Si vous disposez d'un ensemble de données plus incohérent envoyant des signaux à New Relic une fois toutes les vingt-quatre heures, nous vous recommandons de personnaliser cette fonctionnalité en fonction des besoins spécifiques de votre équipe.

Apprenez-en davantage sur les stratégies de comblement des lacunes dans nos documents sur les signaux perdus.

Si vous disposez déjà d’une politique que vous souhaitez connecter à une condition d’alerte, sélectionnez la politique existante.

Découvrez comment créer des politiques ici.

Si nous voulons créer une nouvelle politique pour cette condition d'alerte, c'est l'occasion. N'oubliez pas qu'une politique est liée à des workflows et que les workflows contrôlent la fréquence à laquelle nous sommes notifiés des événements d'alerte. C'est un équilibre délicat entre s'assurer que nous prenons connaissance de tout problème lié aux temps de transaction web aussi vite que possible et veiller à ne pas recevoir tant d'alertes que nos développeurs en éprouvent de la fatigue et commencent à manquer des informations importantes à cause de la surcharge d'informations.

Les politiques peuvent contenir une ou plusieurs conditions. Si vous cherchez à monitorer la latence des transactions Web, vous disposez de quelques options.

Tout d'abord, vous pouvez créer une stratégie qui n'associe qu'un seul problème par stratégie (l'option par défaut). Un problème par politique réduit le bruit mais nécessite également une action immédiate. Mais cela signifie que si vous avez associé plusieurs conditions à cette stratégie, et pas seulement à Response time: Example app, alors tous les événements d'alerte de cette stratégie seront regroupés en un seul incident, quoi qu'il arrive.

Ou nous pourrions créer un problème par condition. Cela signifie que chaque fois que la condition Response time: Example app ouvre un événement d'alerte, tous ces événements d'alerte seront regroupés en un seul problème lié à notre condition. Pour ce cas d'utilisation spécifique, vous devriez choisir cette option car elle répond à l'objectif principal, qui est de monitorer les problèmes de latence liés au temps de transaction web.

Ou nous pourrions créer un ticket pour chaque événement d'alerte. Cette option est la plus bruyante, mais elle peut s'avérer efficace si vous souhaitez envoyer des informations vers un système externe.

Découvrez comment créer des politiques ici.

Un événement d'alerte se fermera automatiquement lorsque le signal ciblé reviendra à 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 le comportement de violation est "le temps de transaction web est supérieur à 0,50 secondes au moins une fois en 5 minutes", alors l'événement d'alerte se fermera automatiquement lorsque le temps de transaction web est égal ou inférieur à 0,50 pendant 5 minutes consécutives.

Lorsqu'un événement d'alerte se ferme automatiquement :

1. L'horodatage de clôture est rétroactif au début de la période de récupération.

2. 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 durée d'événement d'alerte qui force automatiquement la fermeture d'un événement d'alerte de longue durée.

   Nous définissons automatiquement la durée par défaut sur 3 jours et vous recommandons d'utiliser nos paramètres par défaut pour votre première alerte.

Puisque nous créons une condition d'alerte qui nous permet de savoir s'il y a des problèmes de latence concernant le temps de transaction web, nous voulons nous assurer que nos développeurs disposent de toutes les informations nécessaires lorsqu'ils sont notifiés de cet événement d'alerte. Nous allons utiliser 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.

Si vous souhaitez créer un lien vers un runbook, vous pouvez placer l'URL dans le champ URL du runbook.