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 incident. Nous vous recommandons de définir votre niveau de priorité sur critical pour votre première alerte. Vous pouvez en apprendre davantage sur les niveaux de priorité dans nos documents sur les conditions d'alerte.

Ensuite, vous devez choisir ce qui définit un critical anomaly threshold breach. Pour cette première alerte, nous vous recommandons d'utiliser nos paramètres par défaut et de les ajuster selon vos besoins si nécessaire. Alors, laissez les paramètres ouvrir un incident « lorsqu'une requête renvoie une valeur qui s'écarte 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.

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. Les seuils d'alerte statiques sont beaucoup plus personnalisables et nous les recommandons si vous avez une idée précise 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 d'une indication d'un problème plus large. Notre lost signal threshold nous permet de savoir combien de secondes le système doit attendre à partir du moment où le dernier point de données a été détecté avant de considérer que le signal est perdu. Si le signal ne revient pas avant la limite de temps que vous avez définie, vous avez plusieurs options : ouvrir un nouvel incident, fermer tous les incidents ouverts et/ou ignorer l'ouverture d'un incident au moment où 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 incident.

// TODO a besoin d'une nouvelle capture d'écran

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 circulent depuis votre application vers New Relic. Au lieu d'évaluer immédiatement ces données en cas d'incident, la condition d'alerte collecte 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 la 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 incident. Si, à un moment donné, vos données arrivent à New Relic avec un horodatage d'une seule minute, un paramètre de délai faible est suffisant. En revanche, si pendant cette minute New Relic reçoit des points de données avec un horodatage de plusieurs minutes passées ou de plusieurs minutes en avant, alors votre signal est plus incohérent et nécessitera un paramètre 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.

Apprenez-en davantage sur la façon de créer des politiques ici.

Si nous voulons créer une nouvelle politique pour cette condition d’alerte, voici notre chance. N'oubliez pas qu'une politique est liée au flux de travail et que le flux de travail contrôle la fréquence à laquelle nous sommes informés de tout incident. Il s'agit d'un équilibre délicat entre s'assurer que nous sommes informés le plus rapidement possible de tout problème lié au temps de transaction sur le Web et s'assurer que nous ne recevons pas trop d'alertes au point que nos développeurs se fatiguent et commencent à manquer des informations importantes en raison d'une 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 politique qui n’associe qu’un seul problème par politique (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 attaché plusieurs conditions à cette politique, pas seulement à Response time: Example app, alors quoi qu'il en soit, tous les incidents de cette politique seront regroupés en un seul problème.

Ou nous pourrions créer un problème par condition. Cela signifie que chaque fois que la condition Response time: Example app ouvre un incident, tous ces incidents seront regroupés dans un seul problème connecté à notre condition. Pour ce cas d'utilisation spécifique, vous devez choisir cette option car elle répond à l'objectif principal, qui est de monitorer les problèmes de latence avec le temps de transaction Web.

Ou nous pourrions créer un problème pour chaque incident. Cette option est la plus bruyante mais peut bien fonctionner si vous souhaitez envoyer des informations à un système externe.

Apprenez-en davantage sur la façon de créer des politiques ici.

Un incident sera automatiquement fermé lorsque le signal cible reviendra à 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 le comportement de violation est « le temps de transaction sur le Web est supérieur à 0,50 secondes au moins une fois toutes les 5 minutes", puis l'incident se fermera automatiquement lorsque le temps Web de transaction sera égal ou inférieur à 0,50 pendant 5 minutes consécutives.

Lorsqu'un incident 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'incident précédent s'est terminé.

   Toutes les conditions disposent d'un paramètre de limite de temps d'incident qui forcera automatiquement la fermeture d'un incident 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 avec le temps de transaction Web, nous voulons nous assurer que nos développeurs disposent de toutes les informations dont ils ont besoin lorsqu'ils sont informés de cet incident. Nous allons utiliser le workflow pour notifier un canal Slack d'équipe lorsqu'un incident est créé.

Apprenez-en plus sur les descriptions d’incidents personnalisées dans notre documentation.

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