La détection des valeurs aberrantes de New Relic est une fonctionnalité avancée conçue pour identifier automatiquement les entités qui se comportent de manière significativement différente de leurs pairs. Contrairement à la détection d'anomalies traditionnelle, qui recherche des modèles inhabituels au fil du temps, la détection des valeurs aberrantes se concentre sur les écarts au sein d'un groupe à un moment précis.
Cette fonctionnalité vous aide à identifier de manière proactive les problèmes potentiels, tels que :
- Un seul serveur présentant une utilisation CPU élevée par rapport aux autres dans son cluster
- Un broker Kafka ne traitant pas les messages correctement
En identifiant ces « valeurs aberrantes », vous pouvez rapidement trouver les systèmes en aval liés et déduire la probabilité de défaillance, réduisant ainsi le temps moyen de détection (MTTD) et le temps moyen de rétablissement (MTTR).
Concepts clés
Comprendre ces concepts fondamentaux vous aidera à configurer efficacement la détection de valeurs aberrantes :
DBSCAN : Un algorithme de clustering basé sur la densité qui regroupe les points très rapprochés tout en identifiant les valeurs aberrantes comme des points n'appartenant à aucun cluster.
Epsilon (Eps) : Définit la distance maximale entre deux points pour qu'ils soient considérés comme faisant partie du même voisinage. Une valeur plus faible crée des clusters plus serrés, tandis qu'une valeur plus élevée crée des clusters plus lâches.
Points minimum (MinPts) : Le nombre minimum de points requis pour former un cluster. Une valeur supérieure à 3 est recommandée pour la plupart des cas d'utilisation.
Groupes d'évaluation : Permet de segmenter votre analyse des valeurs aberrantes selon différentes facettes (telles que l'environnement, la région ou l'application) afin que les valeurs aberrantes soient détectées séparément au sein de chaque groupe plutôt que sur l'ensemble du jeu de données. Cela garantit que les valeurs aberrantes sont détectées au sein de chaque groupe séparément, réduisant ainsi le besoin de multiples conditions d'alerte.
Mode auto vs manuel
Vous disposez de deux modes distincts pour définir les paramètres principaux, garantissant ainsi l'alerte adéquate pour vos données :
Le Auto mode est le moyen le plus rapide de configurer votre alerte de valeurs aberrantes. Cela vous permet de faire abstraction des détails techniques de l'algorithme, vous évitant d'avoir à comprendre des paramètres complexes d'apprentissage automatique.
Au lieu de définir des paramètres techniques, vous ajustez un simple curseur de sensibilité. Le système utilise des estimations automatiques pour calculer instantanément les valeurs optimales d'Epsilon (Eps) et de Points minimum (MinPts) correspondant à votre niveau de sensibilité sélectionné.
Pour vérifier si les estimations automatiques sont correctes pour vos données, observez la visualisation des données. Si les signaux identifiés comme valeurs aberrantes sur le graphique correspondent à votre perception intuitive d'une anomalie, le mode automatique fonctionne efficacement.
Manual mode est destiné aux utilisateurs expérimentés ou aux situations où les estimations automatiques du système ne correspondent pas tout à fait aux caractéristiques uniques de vos données. Passer en mode manuel vous permet de contrôler directement les paramètres DBSCAN.
Vous devriez passer en mode manuel si les résultats du mode automatique sont inexacts :
- Le système signale comme valeurs aberrantes des signaux qui font visuellement toujours partie d'un cluster.
- Le système ne parvient pas à signaler un signal clairement distant du cluster de données principal.
- Déplacer le curseur de sensibilité sur toute sa plage ne produit que peu ou pas de changement significatif dans les valeurs aberrantes détectées.
Créer une condition d'alerte de détection des valeurs aberrantes
Suivez ces étapes pour créer une condition d'alerte avec détection des valeurs aberrantes :
Dans votre compte New Relic, allez sur one.newrelic.com > All capabilities > Alerts > Alert Conditions.
Cliquez sur + New alert condition et sélectionnez Use guided mode ou le mode Query**. Quel que soit le mode choisi, vous définissez les seuils de votre condition d'alerte sur la page Définir les seuils.
Suivez les étapes jusqu'à ce que vous atteigniez la page de définition des seuils.
Sélectionnez outliers.
Choisissez le mode de l'algorithme :
- Si vous choisissez le mode Auto, ajustez le curseur de sensibilité pour affiner la détection. Dans ce mode, le système détermine automatiquement les paramètres internes optimaux (tels qu'Epsilon et les points minimum pour DBSCAN) en fonction de vos données historiques.
- Si vous choisissez le mode Manual, vous pouvez définir vous-même les valeurs Epsilon et Points minimum.
En option, configurez un groupe d'évaluation.
Terminez le reste de la configuration de la condition d'alerte.
Bonnes pratiques de configuration
Choix des valeurs epsilon
- Commencez par les valeurs par défaut et ajustez-les en fonction des caractéristiques de vos données.
- Monitorez les taux de faux positifs et ajustez en conséquence.
- Epsilon plus petit pour une détection plus sensible.
- Epsilon plus grand pour une détection moins sensible.
Définition des points minimum
- Utilisez des valeurs supérieures à 3 pour la plupart des scénarios.
- Des valeurs plus élevées réduisent le bruit mais peuvent manquer des valeurs aberrantes subtiles.
- Prenez en compte la taille typique de vos groupes lors de la définition de cette valeur.
Utilisation efficace des groupes d'évaluation
- Grouper par limites logiques (environnement, région, service).
- Évitez la sur-segmentation, qui peut réduire l'efficacité.
- Prenez en compte la saisonnalité et les cycles d'activité lors du regroupement.
Gestion des données retardées et des horodatages plus anciens
La détection des valeurs hors norme fonctionne en comparant les métriques de plusieurs entités au même moment. Pour effectuer une comparaison équitable, toutes les entités doivent transmettre des données sur la même fenêtre temporelle.
Le problème des horodatages retardés
Imaginez que vous effectuez le monitoring de l'utilisation du CPU sur trois serveurs à 14 h 00 :
- Serveur A rapporte 45 % de CPU avec horodatage
2:00 PM - Serveur B signale 50 % de CPU avec horodatage
2:00 PM - Serveur C signale 95 % de CPU avec horodatage
1:30 PM
Les données du serveur C ont un horodatage plus ancien (13:30 au lieu de 14:00). Le système ne peut pas comparer les données de 13 h 30 à celles de 14 h 00 — c'est comme comparer des pommes et des poires. Par conséquent, le serveur C est entièrement exclu de l'analyse des valeurs hors norme. Même si le serveur C rencontre clairement un problème, vous ne recevrez pas d'alerte car il n'a jamais été évalué.
Cela se produit lorsqu'une entité rapporte systématiquement des données avec des horodatages plus anciens que la fenêtre temporelle actuelle en cours d'analyse.
Causes courantes
Interrogation du fournisseur de cloud : AWS CloudWatch et des services similaires collectent des métriques à intervalles réguliers, puis New Relic les interroge plus tard. Par exemple, une métrique représentant 14:00 pourrait ne pas arriver à New Relic avant 14:05, créant un retard de 5 minutes.
Transactions de longue durée : les tâches d'arrière-plan reçoivent un horodatage lorsqu'elles démarrent, et non lorsqu'elles se terminent. Un job qui commence à 13 h 30 et s'exécute pendant 30 minutes aura un horodatage de 13 h 30 lorsque ses données arriveront à 14 h 00.
Données en mémoire tampon : des problèmes de réseau ou les paramètres de l'agent peuvent entraîner la mise en file d'attente locale des données. Lorsque la connectivité est rétablie, toutes les données en mémoire tampon arrivent avec leur horodatage d'origine.
Identifier les entités exclues
Pour voir quelles entités sont exclues et pourquoi, exécutez une requête sur l'événement NrAiSignal :
FROM NrAiSignalSELECT *WHERE conditionId = 1234 AND outlierProcessingSkippedReason IS NOT NULLRemplacez 1234 par votre ID de condition d’alerte. Champs clés à examiner :
outlierProcessingSkippedReason: pourquoi le signal a été exclu (affiche généralementLATEpour les données en retard)outlierProcessingSkippedTimeDelta: la différence de temps en secondes entre l’horodatage des données et la fenêtre d’évaluation actuelle
Résolution du problème
Si vous voyez un avertissement dans l'éditeur de conditions indiquant que des signaux sont exclus :
Option 1 : diviser la condition (recommandé)
Créez des conditions d’alerte distinctes pour les entités ayant des comportements de reporting différents :
- Une condition pour les serveurs d’applications en temps réel
- Une autre condition pour les ressources interrogées dans le cloud (comme les métriques AWS CloudWatch)
Cela garantit que la fenêtre d'agrégation de chaque condition correspond à la façon dont ses entités rapportent réellement les données.
Option 2 : augmenter la fenêtre d'agrégation
Élargissez votre fenêtre d'agrégation pour tenir compte des retards. Par exemple, si vos données sont systématiquement en retard de 3 à 5 minutes, utilisez une fenêtre d'agrégation de 5 minutes au lieu de 1 minute.
Compromis : des fenêtres plus grandes lissent les pics à court terme et augmentent le délai avant le déclenchement d'une alerte. Un serveur qui connaît un pic à 14:00 pourrait ne pas déclencher d'alerte avant 14:05 ou plus tard.
Cas d'utilisation et exemples
- Brokers Kafka déséquilibrés : identifiez rapidement les brokers présentant des temps d'attente d'E/S CPU anormaux, permettant aux administrateurs de rééquilibrer les charges de travail de manière proactive avant que les performances ne soient impactées.
- Valeurs aberrantes d'utilisation des ressources : Identifiez les ressources systématiquement sous-utilisées ou surutilisées. Cela permet une meilleure planification de la capacité et évite le gaspillage ou les goulots d'étranglement potentiels.
- Identification des « voisins bruyants » : Détectez les entités accaparant les ressources qui consomment une quantité disproportionnée de ressources partagées. Cela permet une action corrective pour équilibrer l'allocation des ressources.
- Problèmes de mémoire des applications Java : Détection précoce des machines virtuelles Java (JVM) présentant des taux anormaux d'erreurs de mémoire insuffisante (OOM), permettant une intervention rapide pour éviter une défaillance généralisée de l'application.
- Monitoring spécifique à l'environnement : Utilisez des groupes d'évaluation pour monitorer séparément les environnements de pré-production et de production, en veillant à ce que les valeurs aberrantes d'un environnement n'interfèrent pas avec la détection dans un autre.