Grâce aux alertes, vous pouvez commencer à détecter les problèmes avant qu'ils ne deviennent critiques. En utilisant NRQL, notre langage de requête New Relic, vous pouvez créer et personnaliser votre condition d'alerte qui se concentre sur ce qui vous préoccupe le plus. Utilisez pour être informé des comportements inhabituels dans vos données, acheminer les notifications aux personnes qui doivent les voir et prendre des décisions efficaces tout en connaissant la cause première de votre problème.
Améliorez votre couverture d'alerte en utilisant nos recommandations sur la meilleure façon d'utiliser la réponse aux alertes, la maintenance, la qualité et les paramètres avancés. Consultez notre guide de gestion de la qualité des alertes pour savoir comment mesurer et améliorer la qualité de vos alertes.
Vous pouvez suivre ces actions recommandées pour améliorer et tirer le meilleur parti de votre configuration d’alerte.
Conseil
Avez-vous déjà créé votre première alerte ? Sinon, consultez notre série de tutoriels pour connaître toutes les étapes dont vous avez besoin pour commencer.
Améliorer la réponse aux alertes
Que dois-je faire | Avantage |
|---|---|
Donnez un nom explicatif à l'alerte | La description et la balise doivent vous donner des alertes autodescriptives pour savoir quel service est erroné, quel environnement est impliqué, quelle équipe en est propriétaire et si cela a un impact sur l'utilisateur final. Cela vous aide à répondre plus rapidement et à décider quoi faire. |
Ajoutez une balise à votre état d'alerte | Vos problèmes et incidents ont ces tags dans leurs métadonnées. Utilisez-les pour effectuer des filtres flexibles dans le workflow ou ajoutez-les à vos frais notification . Les problèmes ont 3 sources de balises :
|
Catégoriser la condition d'alerte | Dans votre organisation, définissez des catégories d'alertes, des attentes en matière de gestion de leurs notifications et une destination unique. Par exemple, proactif pour Slack pour notifier avant que l'incident ne se produise ; réactif pour PagerDuty pour détecter et notifier un incident en cours ; ou informatif pour Jira. |
Définir la méthode de communication et d'escalade | Décider des moyens de notifications. Certaines méthodes de notifications sont : e-mail, Slack, PagerDuty ou Jira. |
Ajoutez une équipe responsable | Cette équipe est en charge de gérer la première notification. |
Ajoutez une URLrunbook à chaque condition d'alerte | Le runbook doit décrire les étapes de correction à suivre et les personnes à impliquer ou à contacter. |
Utiliser des enrichissements | Priorisez et triez vos notifications d'alerte plus rapidement en fournissant des mesures supplémentaires spécifiques au problème. |
Améliorer la maintenance des alertes
Que dois-je faire | Avantage |
|---|---|
Organisez vos politiques | Nous vous recommandons de créer une politique pour chaque destination ou public distinct qui doit recevoir une notification. Envisagez de regrouper par entité, service ou technologie pour correspondre à l’orientation de vos équipes respectives. |
Ajoutez une équipe propriétaire à chaque condition d'alerte | L'équipe propriétaire garantit que l'alerte reste pertinente. Ils approuvent toute modification de la condition. |
Planifier un examen périodique de l'état d'alerte | Utilisez la page d’aperçu des alertes pour vérifier l’incident créé et décider de l’action à effectuer. Nous vous recommandons de tagger l'état avec la date de la dernière révision, ce qui vous permettra d'identifier les alertes obsolètes. |
Automatisez la création de vos alertes avec Terraform | Vous éviterez les modifications non documentées et clarifierez la traçabilité. |
Améliorer la qualité des alertes
Que dois-je faire | Avantages |
|---|---|
Avoir des SLI et des SLO dans un rapport | Les violations des SLI et des SLO ne sont pas toujours des incidents et ne nécessitent pas d'alerte, sauf si vous avez documenté des mesures pour les empêcher. SLI/SLO peut mettre en évidence le domaine sur lequel l'équipe doit se concentrer pour apporter des améliorations plutôt que de répondre à un événement. |
Désactiver les alertes pendant la maintenance | Cela supprimera les notifications bruyantes. |
Adopter une approche systémique lors de la définition des alertes pour un service | Vous aide à vous assurer de couvrir l'intégralité de votre stack de manière cohérente. Vous pouvez organiser vos alertes par technologie, équipes impliquées, etc. |
Examiner les décisions suggérées | Chaque jour, nous analysons vos données d'alerte et fournissons des suggestions de décisions ainsi que des commentaires sur les décisions existantes. Cela améliorera la réduction du bruit. |
Identifier et régler les alertes de bagottement | Ces alertes indiquent une mauvaise configuration de l'état d'alerte qui crée du bruit. Ils peuvent encore indiquer un problème de longue date dans votre système, mais il ne s’agit pas d’un incident. |
Augmentez le seuil ou la durée de la fenêtre et utilisez l'agrégation de fenêtres glissantes | Les alertes qui se résolvent d'elles-mêmes avant que votre équipe ne puisse prendre des mesures peuvent encombrer votre boîte de réception et créer du bruit. Utilisez un tableau de bord si vous souhaitez voir les pics de courte durée et lisser les pics temporaires. Vous comprendrez l’impact que cela aura sur la clôture de votre incident. |
Utiliser les décisions | Tirez parti de votre balise personnalisée et de vos métadonnées dans les décisions. Les incidents connexes seront regroupés dans un seul numéro complet. Gardez les décisions par défaut activées lorsque vous démarrez. Dans quelques semaines, vous serez en mesure d’évaluer l’efficacité de ces décisions. |
Si vous utilisez des décisions, augmentez le délai de grâce de notification | Vous obtiendrez davantage d’incidents liés à vos problèmes. Vous obtiendrez un contexte plus riche et plus exploitable dès la première notification. Plus le délai de grâce est long, plus la notification est tardive. |
Consultez régulièrement le flux des problèmes | Faites défiler la colonne Notified pour vous assurer que tous les problèmes sont acheminés vers au moins une destination. Si aucun routage n'est nécessaire, envisagez de supprimer la condition car il peut s'agir de bruit. |
création de conditions d'alerte et paramètres avancés
Si vous êtes nouveau dans le domaine des alertes ou si vous souhaitez des suggestions pour optimiser votre couverture d'alerte, prêtez attention à ces recommandations :
- Recevez des alertes recommandées par technologie
- Laissez New Relic trouver vos lacunes de couverture
- Obtenez des recommandations sur l'état
Comprendre le signal
Chaque condition d’alerte génère un signal ou plusieurs signaux si la condition contient une clause de facette. Chaque valeur de facette possible créera un signal distinct.
Vous pouvez interroger tous les signaux dans NrAiSignal. Cela vous permet d'obtenir des détails sur la valeur observée, le nombre de points de données pris en compte et, dans le cas de conditions d'anomalie, la valeur attendue et l'écart type. Il fournit également des informations sur le delta de temps entre l'heure New Relic et l'heure de vos données brutes (si vos données sont des horodatages), ce qui peut vous aider à trouver le paramètre de délai le plus précis lors de la création de vos conditions.
Maintenir la santé de l'entité
Nous utilisons des signaux pour déduire la santé et la couverture d’alerte d’une entité. Si les résultats d'une condition d'alerte contiennent des données provenant d'une seule entité, New Relic les liera à la santé de cette entité, et ces événements s'afficheront en contexte dans l'interface utilisateur de New Relic.
Il est recommandé, dans la plupart des conditions, de maintenir l’existence d’un signal. L'absence de signal peut entraîner l'affichage par New Relic d'un état de santé gris (inconnu) pour certaines entités, ainsi que l'ajout de ces entités à la liste des entités non couvertes.
Si la clause where de votre condition exclut toutes les données, il ne restera plus de données. Il s'agit d'une perte de signal pour New Relic et la condition d'alerte NE PEUT être évaluée par rapport à AUCUN seuil. Cela signifie que le résultat de la requête NRQL ne contient pas de données, mais cela ne signifie pas que New Relic ne reçoit pas de données. Si vous souhaitez recevoir une notification, vous devez ajouter un seuil de perte de signal.
Utilisez les filtres les plus génériques dans votre section where et les plus spécifiques dans votre section select . Utilisez la fonction de filtre pour mesurer avec précision ce qui vous intéresse. Par exemple:
Select filter(count(*), where ErrorCode=123) from Transaction where AppName='Application1' and Environment='Production'Délai d'alerte ou durée de la minuterie
Essayez d'ajuster le délai/temps avec le comportement de vos données. Un court délai peut déclencher de fausses alertes en raison de données incomplètes et un délai important peut augmenter le temps pendant lequel vous êtes averti. New Relic ne sait pas quelle quantité de données attendre ni à quel moment ces données pourraient atteindre un point de terminaison de New Relic. En fonction de l'expéditeur log et configuration, les données log peuvent être regroupées et entraîner un retard important pour les logs à faible volume.
Définissez votre seuil de condition
Définissez des niveaux de seuil significatifs pour optimiser les alertes pour votre entreprise. Voici quelques lignes directrices suggérées :
Action | Recommandations |
|---|---|
Définir des niveaux de seuil | Évitez de régler le seuil trop bas. Par exemple, si vous définissez un seuil de condition CPU de 75 % pendant 5 minutes sur vos serveurs de production et que ce niveau est régulièrement dépassé, cela augmentera la probabilité d'alertes non exploitables ou de faux positifs. |
Expérimenter avec les paramètres | Vous n’avez pas besoin de modifier les fichiers ou de redémarrer le logiciel, alors n’hésitez pas à apporter des modifications rapides à vos niveaux de seuil et à les ajuster si nécessaire. |
Ajuster les paramètres | Ajustez vos conditions au fil du temps.
|
Désactiver les paramètres | Vous pouvez disable any condition dans une politique, si nécessaire. Cela est utile, par exemple, si vous souhaitez continuer à utiliser d’autres conditions dans la politique pendant que vous expérimentez d’autres métriques ou seuils. |
L' indicateur d'état de santé à code couleur dans l'interface utilisateur de New Relic change à mesure que le seuil d'alerte augmente ou revient à la normale. Cela vous permet de monitorer une situation via l'interface utilisateur avant d'avoir un seuil critique, sans avoir besoin de recevoir de notification spécifique à ce sujet. Il existe deux seuils incident : critique (rouge) et avertissement (jaune). Définissez ces seuils avec différents critères, en gardant à l'esprit les suggestions mentionnées ci-dessus.
Assurez l'exécution de vos tâches quotidiennes par lots
Vous pouvez configurer une condition d’alerte pour recevoir une notification si vos tâches par lots échouent.
En supposant que vous envoyez un événement à New Relic dans le cadre de votre tâche par lots, vous pouvez configurer une condition d'alerte pour vous avertir si vos tâches par lots ne parviennent pas à s'exécuter.
Configurer une requête de comptage simple sur l'événement.
SELECT count(*) FROM MyBatchEventDéfinissez la perte de signal pour ouvrir un nouvel incident après 24 heures et 30 minutes. Vous pouvez ajuster cela, mais c'est une bonne idée d'autoriser un travail par lots à exécution tardive.
Assurez-vous d'utiliser la méthode d'agrégation de streaming événement Timer . Étant donné que vous n'obtiendrez qu'un seul point de données toutes les 24 heures, vous pouvez régler la minuterie sur son réglage le plus bas, 5 secondes.
Utiliser des valeurs non nulles lorsqu'il n'y a pas de signal
Par défaut, les lacunes dans les signaux de données sont comblées par des valeurs nulles. Dans les cas où vous devez pouvoir créer des conditions basées sur ces lacunes de données, vous pouvez combler les lacunes avec une valeur personnalisée ou la dernière valeur connue. Vous pouvez configurer ce paramètre par condition dans l'interface utilisateur ou configurer des valeurs de remplissage des espaces via NerdGraph.
Important
La configuration du remplissage des espaces n'empêche pas le déclenchement de la « Perte de signal ».
Définissez vos préférences de création de problèmes
Décidez quand vous recevez une notification de problème afin de pouvoir répondre aux problèmes lorsqu'ils surviennent.
Si vous n'êtes pas familier avec les alertes, découvrez-en plus sur vos options de préférences de problème.
Le paramètre de préférence de problème par défaut combine toutes les conditions d'une politique en un seul problème. Modifiez votre paramètre de préférence de problème par défaut pour augmenter ou diminuer le nombre de problèmes et la notification de problème que vous recevez.
Chaque équipe au sein de votre organisation peut avoir des besoins différents. Posez à votre équipe deux questions importantes pour déterminer vos préférences en matière de problèmes :
- Voulons-nous être avertis chaque fois que quelque chose ne va pas ?
- Souhaitons-nous regrouper toutes les notifications similaires et être avertis une seule fois ?
Lorsqu'une politique et ses conditions ont une portée plus large, comme la gestion de la performance de plusieurs entités, augmentez le nombre de problèmes que vous recevez. Vous aurez peut-être besoin de plus de notifications car deux problèmes ne peuvent pas nécessairement être liés l'un à l'autre.
Lorsqu'une politique et ses conditions ont une portée ciblée, comme la gestion des performances d'une entité, optez pour la préférence de problème par défaut. Vous avez besoin de moins de notifications lorsque 2 problèmes sont liés l’un à l’autre ou lorsque l’équipe est déjà notifiée et corrige un problème existant.
Quelle est la prochaine étape ?
Pour en savoir plus sur l’utilisation des alertes :
- Découvrez les concepts et les termes d'alerte.
- En savoir plus sur l'API.
- Lisez les détails techniques sur les limites min/max et les règles.
- En savoir plus sur les cas dans lesquels vous pourriez avoir besoin d'utiliser les paramètres de perte de signal et de remplissage d'espace.