Détection des anomalies

La détection d'anomalies permet à votre équipe la plus grande polyvalence lors de la détection de comportements inhabituels dans votre système. La détection d'anomalie donne à votre équipe la possibilité d'alerter sur n'importe quelle entité ou signal et d'ajuster et d'optimiser votre seuil de sensibilité. La détection d'anomalies utilise le même pipeline d'alerte en continu que les alertes de seuil statiques et partage les mêmes paramètres de réglage avancés. Cela garantit que le traitement du flux est aligné sur les caractéristiques de votre signal de télémétrie afin de réduire les fausses alertes.

Vous pouvez enrichir votre configuration de détection d'anomalies avec des métadonnées supplémentaires pour fournir un contexte supplémentaire et ajouter des descriptions incident personnalisées qui peuvent fournir des instructions supplémentaires à votre ingénieur d'astreinte. Par défaut, les conditions d'anomalie exploitent la détection automatique de saisonnalité par New Relic. Vous pouvez également définir des paramètres de saisonnalité personnalisés.

Configurer le seuil de sensibilité aux anomalies

Vous pouvez créer un seuil de sensibilité aux anomalies à partir d'une condition d'alerte. Voici quelques conseils pour définir le seuil d’anomalie :

• Définissez la direction de l'anomalie pour monitorer les incidents qui se produisent au-dessus ou en dessous de l'anomalie.
• Définissez la saisonnalité pour spécifier un modèle de saisonnalité connu.
• Utilisez la barre coulissante pour régler le seuil de sensibilité Critical , représenté dans le graphique d'aperçu par la zone gris clair autour du signal. Plus la bande autour du signal est serrée, plus il est sensible et plus il générera d'incidents.
• Vous pouvez créer un seuilWarning (la zone grise plus foncée autour de l'anomalie).

Suivez ces étapes pour créer une condition d’alerte de détection d’anomalie :

1. Allez à one.newrelic.com > All capabilities > Alerts > Alert Conditions.

2. Cliquez sur + New alert condition > Use guided mode (ou sur le mode de requête plus avancé).

3. Suivez les étapes guidées jusqu'à arriver à Set thresholds.

4. Sélectionnez Anomaly.

   

5. Sélectionnez une option pour calculer la saisonnalité de la condition d’alerte. Pour comprendre la saisonnalité et son impact sur votre état d'alerte, reportez-vous à Saisonnalité.

6. Configurez les paramètres pour un ou plusieurs seuils. La détection d'anomalies permet de prédire quel sera le prochain point de données en fonction de l'activité antérieure. La valeur de seuil pour la détection d'anomalie contrôle la sensibilité de la condition d'alerte pour tolérer l'écart entre la valeur réelle et la valeur prédite. Le seuil est le nombre d'écarts types qui séparent la valeur de votre signal de la valeur prédite. Nous suivons l’écart type entre la valeur prédite et la valeur réelle pour les 7 jours de données précédents.

   Pour configurer le seuil, vous devrez :

   • Définissez la « direction du seuil » sur supérieur, inférieur ou les deux. Cela signifie que nous ne créerons un incident que si la valeur du signal (la sortie de la requête) est supérieure à la valeur prédite, inférieure à la valeur prédite ou les deux, respectivement.

     Ce champ indique le nombre de points de données pendant une période donnée qui doivent être en dehors du seuil. Les options sont for at least et at least once in. La sélection de for at least signifie que TOUS les points de données de votre signal doivent être en dehors du seuil pendant la période spécifiée avant qu'un incident ne soit ouvert. L’inverse doit être vrai pour clôturer l’incident. L'option at least once in signifie simplement que dès que l'un des points de données de votre signal se trouve en dehors du seuil, un incident s'ouvre. Avec cette option, la durée n’est pas pertinente pour déterminer quand ouvrir un incident. Cependant, cela est pertinent pour la clôture de l'incident. Tous les points de données de votre signal doivent être dans le seuil pendant la période spécifiée

   • Définissez la « durée du seuil ». Considérez cela comme la durée pendant laquelle la valeur du signal doit rester en dehors du seuil avant qu’un incident ne soit ouvert. À l’inverse, c’est aussi la durée pendant laquelle un signal doit rester dans le seuil pour qu’un incident soit clôturé.

     Ce champ répond à la période mentionnée ci-dessus. Il s'agit de la durée pendant laquelle le signal dépasse le seuil défini. Il s’agit de la durée réelle du seuil.

   • Définir le « niveau de seuil ». Pour la détection d'anomalies personnalisées, il s'agit du nombre d'écarts types entre le point de données du signal et la valeur que nous avions prédite.

7. Ajoutez les détails de la condition d’alerte et cliquez sur Save condition.

Définition du seuil pour les conditions multi-signaux (requête à facettes)

Selon la manière dont vous avez défini votre requête à l'étape 1, la condition d'alerte peut consister monitoring plusieurs signaux, et non un seul. Lorsque vous travaillez avec NRQL, ces requêtes utilisent la clauseFACET . Le nombre maximal de signaux qu'une condition d'alerte peut monitorer est de 5 000. Les paramètres de seuil que vous spécifiez s'appliquent de la même manière à tous les signaux monitorés par cette condition. Chaque signal est monitoré et évalué individuellement, mais les paramètres s'appliquent de manière cohérente à tous les signaux. Nous n'afficherons qu'un maximum de 500 signaux sur le graphique d'aperçu. Cependant, nous n'affichons pas le signal prédit et les bandes de seuil lorsqu'il y a plus d'un signal affiché sur le graphique. Pour afficher ces informations tout en déterminant la valeur de seuil idéale, sélectionnez l'un des signaux de séries chronologiques de la légende pour filtrer le graphique sur une seule série chronologique.

Direction de l'anomalie : sélectionnez les plages supérieures ou inférieures

Vous pouvez choisir si vous souhaitez que la condition recherche un comportement qui dépasse la valeur prédite (« supérieure ») ou qui descend en dessous de la valeur prédite (« inférieure »), ou qui descend au-dessus ou en dessous. Vous les choisissez avec le sélecteur de direction de prédiction.

Exemples de cas d’utilisation pour cela :

• Vous pouvez utiliser le paramètre Supérieur pour une source de données comme le taux d'erreur, car vous n'êtes généralement concerné que s'il augmente et non s'il diminue.
• Vous pouvez utiliser le paramètre inférieur pour une source de données telle que le débit, car les fluctuations soudaines à la hausse sont assez courantes, mais une forte baisse soudaine indiquerait un problème.

Voici quelques exemples de la manière dont les fluctuations importantes de vos données seraient traitées selon les différents paramètres de direction des anomalies. Les zones rouges représentent les incidents.

Règles régissant le calcul de la valeur prédite

L’algorithme de calcul de la prédiction est mathématiquement complexe. Voici quelques-unes des principales règles régissant ses capacités prédictives :

• Age of data Lors de la création initiale, la prédiction est calculée en utilisant entre 1 et 4 semaines de données, selon la disponibilité des données et le type de prédiction. Actuellement, les requêtes qui utilisent la clause FACET ne sont pas formées sur les données stockées. Après sa création, l'algorithme prend en compte les fluctuations continues des données sur une longue période, même si un poids plus important est accordé aux données plus récentes. Pour les données qui n’existent que depuis peu de temps, la valeur prédite risque de beaucoup fluctuer et de ne pas être très précise. C'est parce qu'il n'y a pas suffisamment de données pour déterminer ses valeurs et son comportement habituels. Plus les données ont d’historique, plus la prédiction sera précise.
• Consistency of data Pour les valeurs métriques qui restent dans une plage cohérente ou qui évoluent lentement et régulièrement, leur comportement plus prévisible signifie que leur seuil de sensibilité deviendra plus serré autour de la prédiction. Les données plus variées et imprévisibles auront un seuil de sensibilité plus lâche (plus large).
• Regular fluctuations Pour les fluctuations cycliques d'une durée inférieure à une semaine (telles que le déploiement hebdomadaire du mercredi à 13 heures ou les rapports nocturnes), l'algorithme de prédiction recherche ces fluctuations cycliques et tente de s'y adapter.

Saisonnalité

Pour gérer les fluctuations récurrentes de vos signaux, telles que les pics de trafic en semaine, vous pouvez spécifier la saisonnalité d'une condition. Par défaut, la détection d'anomalies calcule automatiquement la saisonnalité de chaque signal à l'aide de ** New Relic calculation**. Cependant, vous pouvez choisir de définir le calcul de saisonnalité sur une valeur spécifique ou de le désactiver complètement. Les options disponibles sont :

• New Relic calculation (par défaut) : Détermine automatiquement la saisonnalité de chaque signal en fonction de plusieurs facteurs, notamment l'âge des données, la cohérence des données et les fluctuations régulières.
• Hourly: Applique un modèle horaire à tous les signaux dans la condition de détection d'anomalie.
• Daily: Applique un modèle quotidien à tous les signaux dans la condition de détection d'anomalie.
• Weekly: Applique un modèle hebdomadaire à tous les signaux dans la condition de détection d'anomalie.
• None: Désactive entièrement la saisonnalité, garantissant qu'aucun modèle saisonnier n'est pris en compte lors de l'évaluation des signaux.