Grâce à la logique de corrélation des alertes, les problèmes liés sont regroupés pour réduire les alertes intempestives et redondantes. À mesure que les événements entrent dans votre système, ils sont éligibles à notre logique de corrélation. Les problèmes éligibles sont évalués en fonction du temps, du contexte de l'alerte et des données de relation. Si plusieurs problèmes sont liés, notre logique de corrélation regroupera les événements d'alerte associés en un seul problème complet.
Nous appelons cette logique de corrélation decisions. Nous proposons des décisions intégrées, mais vous pouvez également créer et personnaliser les vôtres sur la page des décisions. Pour trouver la page des décisions, rendez-vous sur one.newrelic.com > All capabilities > Alerts > Decisions. Plus vous configurez vos décisions pour répondre au mieux à vos besoins, mieux New Relic peut corréler vos événements d'alerte, réduire le bruit et fournir un contexte accru aux équipes d'astreinte.
/* <img title="NRAI_Decisions_Page.png" alt="Une capture d'écran montrant l'interface utilisateur des décisions d'alerte." src="/images/alerts_screenshot-full_new-relic-decisions-page.webp" /> <figcaption> <DNT>**[one.newrelic.com > All capabilities](https\://one.newrelic.com/all-capabilities) > Alerts > Alert event intelligence > Decisions**</DNT>: notre interface utilisateur montre comment chaque décision corrèle les événements d'alerte. </figcaption> */
Qu’est-ce que la corrélation et comment fonctionne-t-elle ?
Vos événements d'alerte les plus récents et actifs sont disponibles pour notre logique de corrélation. Par exemple, supposons que votre système ait reçu deux alertes indiquant qu'un moniteur synthétique est en échec en Australie et à Londres. Ces deux alertes auront créé leurs propres événements d'alerte uniques. Ces événements d'alerte généreront leurs propres problèmes uniques en fonction de la politique de création d'événements d'alerte existante de votre équipe. La logique de corrélation de New Relic testera alors ces événements d'alerte les uns par rapport aux autres pour trouver des similitudes. Dans ce cas, c'est le même moniteur qui échoue sur plusieurs emplacements, donc New Relic fusionnera les deux événements d'alerte en un seul problème contenant chaque événement pertinent.
Lorsque nous corrélons un événement, nous vérifions chaque paire de combinaisons les unes par rapport aux autres et en combinons autant que possible. Par exemple:
- Notre algorithme corrèle les événements d'alerte A et B (appelons-le "AB").
- Notre algorithme corrèle les événements d'alerte B et C (appelons-le "BC").
- Comme B est présent dans les deux problèmes, l'algorithme corrèle alors les trois événements d'alerte en un seul problème.
Configurer la politique de corrélation
Pour activer la corrélation sur les problèmes basés sur des alertes , vous devez vous connecter à la corrélation pour la règle d'alerte correspondante.
Cochez la case Correlate and suppress noise pour activer la corrélation pour la règle d'alerte.
Types de décisions
Les Décisions déterminent comment l'intelligence des événements d'alerte corrèle les problèmes entre eux. La logique de corrélation de New Relic est disponible pour votre équipe dans trois types de décision différents :
- Global decision:Un large ensemble de décisions par défaut est automatiquement activé lorsque vous commencez à utiliser des alertes.
- Suggested decision:Le moteur de corrélation de New Relic évalue en permanence vos données d'événement pour suggérer des décisions qui capturent des modèles de corrélation afin de réduire le bruit. Vous pouvez prévisualiser les résultats de simulation d’une décision suggérée et choisir de l’activer.
- Custom decision:Votre équipe peut personnaliser les décisions en fonction de votre cas d’utilisation pour améliorer l’efficacité de la corrélation. L'UI de décision de New Relic vous offre la flexibilité de configurer toutes les dimensions d'une décision.
Passez en revue vos décisions actives
Pour revoir les décisions existantes de votre équipe :
- Allez à one.newrelic.com> Alerts > alert event intelligence > Decisions.
- Consultez la liste des décisions actives. Pour voir la logique de règle qui crée des corrélations entre vos problèmes, cliquez sur la décision.
- Pour voir des exemples d'événements d'alerte que la décision a corrélés, cliquez sur l'onglet Recent correlations.
- Vous avez la possibilité d'activer ou de désactiver ces décisions globales.
Configurer les sources
Avant de configurer vos décisions, il est important de déterminer les sources que vous souhaitez corréler. Les sources sont vos entrées de données.
Vous pouvez obtenir des données à partir de l’une des sources suivantes :
Décisions mondiales
Les décisions globales sont automatiquement activées lorsque votre équipe commence à utiliser des alertes. Ils ne nécessitent aucune configuration et sont immédiatement disponibles pour votre équipe. Les décisions mondiales couvrent une variété de scénarios de corrélation.
Le tableau ci-dessous fournit des descriptions pour toutes les décisions globales qui sont automatiquement activées.
Nom de la décision | Description |
|---|---|
Nom de cible du même nom New Relic (NRQL) | La corrélation est activée lorsque le nom de l'entité avec un seuil dépassé et la requête NRQL sont identiques. L'événement pertinent de la même condition d'alerteNRQL sera identifié. Cette décision permet de relier les problèmes qui présentent le même écart de latence de requête de transaction par exemple. |
Nom de cible du même nom New Relic (non NRQL) | La corrélation est activée car les New Relic NRQL seuils d'alerte non sont les mêmes. Ne s'applique pas à la source REST. L'entité nonNRQL fait référence à l'entité, généralement à l'application, aux types HOST, voir le référentielNew Relic GitHub (dépôt) sur la synthèse des entités. Avec cette décision, les questions pertinentes de la même entité seront identifiées. Par exemple, un problème de mémoire élevée de l'hôte et un problème de non-signalement de l'hôte pourraient être très probablement dus à la même cause. |
Même identifiant de cible New Relic | La corrélation est activée car les New Relic NRQL seuils d'alerte non sont les mêmes. Ne s'applique pas à la source REST. Utilisez l'ID d'entité pour identifier de manière unique une instance d'entité. Apprenez-en davantage sur entity.guid. |
Même état New Relic | La corrélation est activée car les ID de condition New Relic sont identiques. Par exemple, une augmentation de l'utilisation du CPU avec des services associés déclenchera des événements d'alerte à partir de la même condition d'utilisation du CPU, et sera ainsi identifiée. Cette logique est utile au-delà de l'option de préférence de création d'incidents de politique d'alerte pour un incident par condition, en raison de la granularité au niveau de la condition et de la flexibilité dans la définition de la fenêtre temporelle de corrélation. |
Même état New Relic et URL de lien profond | La corrélation est activée car les ID de condition New Relic et l'URL de lien profond sont identiques. L'URL de lien profond fournit des informations sur les séries temporelles et la plage temporelle en plus de la condition d'alerte. La corrélation de ces problèmes vous permet de consulter plus facilement les événements d'alerte liés dans le flux de réponse aux événements d'alerte avec des métriques temporelles, et d'effectuer une analyse approfondie. L'URL de lien profond peut être générée automatiquement si les événements d'alerte sont déclenchés par des conditions d'alerte New Relic, tandis que pour une source REST, deepLinkUrl doit être définie par l'utilisateur. |
Même état et même titre New Relic | La corrélation est activée car les noms et titres des conditions New Relic sont identiques. Il s'agit d'une option affinée comparant les titres en plus des conditions pour révéler une pertinence plus étroite avec le même message d'alerte. |
Même déploiement de K8s | La logique de corrélation est activée car les déploiements Kubernetes sont identiques. De nombreux événements d'alerte proviennent de modifications de déploiement uniques. Cette décision vise à réduire les problèmes provenant du même déploiement d'entité Kubernetes problématique. |
Même nom d'application, même politique et même identifiant | La logique de corrélation est activée car le nom de l’application personnalisée, la politique et l’ID personnalisé sont identiques. Nous corrélons les problèmes avec ces éléments pour réduire les problèmes application , en particulier pour répondre aux besoins des utilisateurs tag personnalisées. En savoir plus sur la balise. L'ID tag personnalisé peut être défini par l'ID de famille de conditions ou d'autres valeurs d'ID utilisées comme clé pour identifier les connexions entre les données. |
Message d'alerte similaire | La corrélation est activée car les événements d'alerte ont des titres similaires et proviennent de la même entité. Cela permet de réduire les problèmes provenant de la même entité causés par des conditions d'alerte similaires. |
Même identifiant sécurisé, même emplacement public et même type | La corrélation est activée car les informations d'identification sécurisées, l'emplacement public et le type personnalisé sont respectivement les mêmes. Il s'agit de corréler les problèmes provenant de la même localisation géographique/région avec les mêmes informations d'identification de sécurité qui sont normalement déclenchés par une seule cause première (par exemple, une défaillance du moniteur Synthetics) et qui pourraient très probablement être résolus avec la même solution. Ajoutez une balise pour bénéficier de cette décision. |
Structure de problème similaire | La corrélation est activée car les deux événements d'alerte ont une structure d'attributs et un contenu de données similaires. Il s'agit d'une version simplifiée du clustering, qui adopte des algorithmes de similarité avancés dans le calcul matriciel pour réduire les problèmes fortement liés. |
Topologiquement dépendant | La corrélation est activée car des événements d'alerte sont générés à partir d'instances ayant des relations de dépendance. En savoir plus sur la corrélation topologique prête à l'emploi. |
Utiliser les décisions suggérées
Les données provenant de vos sources sélectionnées sont continuellement inspectées à la recherche de modèles afin de contribuer à réduire le bruit. Une fois les modèles observés dans vos données, notre logique de corrélation suggérera des décisions uniques qui permettront à ces types d’événements d’être corrélés à l’avenir.
Pour commencer, cliquez sur l’onglet Suggested decisions sur le sujet de la page UI Decisions. Vous pouvez voir la logique derrière la décision suggérée et le taux de corrélation estimé en cliquant sur chaque décision suggérée.
one.newrelic.com > All capabilities > Alerts > Decisions:Quelques exemples de statistiques issues de l'UI des décisions.
Pour activer une décision suggérée, cliquez sur Add to your decisions. Une fois activée, la décision apparaîtra dans le tableau de décision principal de votre équipe. Toutes les décisions suggérées afficheront le créateur comme étant New Relic AI (cela fait référence aux alertes New Relic).
Si la décision suggérée ne correspond pas à vos besoins, cliquez sur Dismiss.
Créer des décisions personnalisées
Vous pouvez réduire le bruit et améliorer la corrélation en créant vos propres décisions personnalisées. Pour commencer à prendre une décision, accédez à one.newrelic.com > All capabilities > Alerts > Decisions, puis cliquez sur Create new decision.
Il existe deux versions du générateur de décision :
- Générateur de décision de base (en avant-première)
- Générateur de décision avancé
Pour en savoir plus sur la façon d’utiliser ces outils de prise de décision, continuez à lire.
Éléments de décision
Une décision est composée de ces éléments :
- Corréler par attributs : Corrélez tous les événements d'alerte selon les similitudes ou les différences de leurs attributs.
- Filtrer par valeurs spécifiques : Limitez les événements d'alerte à ceux ayant des valeurs spécifiques.
- Filtrer par entité liée : Sélectionnez les types de connexions partagées ou de dépendances que vous souhaitez que nous recherchions.
- Plage de temps de corrélation : définit la différence de temps maximale autorisée entre les heures de création de deux événements d'alerte pour qu'ils soient pris en compte pour la corrélation.
Une fois les connexions entre les événements d'alerte établies, notre algorithme regroupe les événements d'alerte corrélés en un seul problème.
Générateur de décision de base
This feature is currently in preview and available for only some customers. Si vous n'y avez pas accès, consultez les instructions du générateur de décision avancé.
Voici une courte vidéo (3:25 minutes) montrant comment utiliser le générateur de décision de base :
Le générateur de décisions de base couvre la majorité des cas d'utilisation et se concentre sur « Corréler par attribut », où vous pouvez spécifier des conditions de filtrage pour les correspondances de corrélation. Vous pouvez également appliquer la même logique de filtrage pour des valeurs spécifiques aux deux événements d'alerte corrélés. Par exemple, vous pouvez corréler des événements d'alerte si le nom de l'entité est host 1 pour les deux.
Pour créer votre propre décision personnalisée à l’aide du générateur de décision de base, procédez comme suit. Gardez à l’esprit que les étapes 1, 2 et 3 sont facultatives en elles-mêmes, mais au moins l’une des trois doit être définie pour prendre une décision.
Étape 1 : Corrélation par attribut
Choisissez un attribut dans le menu liste déroulante. L'opérateur equal , l'option la plus populaire, est présélectionné, ou vous pouvez choisir un autre opérateur.
Le deuxième attribut correspond généralement au premier, il est donc renseigné automatiquement. Vous pouvez conserver l'option de remplissage automatique ou choisir un autre opérateur.
Une fois terminé, une simulation s'exécute automatiquement.
Vous pouvez répéter ces étapes pour ajouter jusqu'à huit filtres logiques.
/* <CollapserGroup> <Collapser id="basic-correlate-attributes-ui" title="Voir une capture d'écran de l'interface" > <img title="Une capture d'écran du générateur de décisions de base, effectuant une corrélation avec des attributs." alt="Une capture d'écran du constructeur de décisions de base, en corrélation avec des attributs." src="/images/alerts_screenshot-crop_basic-decision-builder-correlate-attributes.webp" /> </Collapser> </CollapserGroup> */
Étape 2 : Filtrer par valeurs spécifiques
- Pour ouvrir la section
Filter by specific valueset voir des filtres supplémentaires, cliquez sur See more options. - Choisissez un attribut.
- L'opérateur
equalest présélectionné, ou vous pouvez sélectionner un autre opérateur. - Sélectionnez les valeurs attendues pour l'attribut choisi, avec plusieurs sélections prises en charge.
Une fois terminée, la simulation s'exécutera automatiquement.
Vous pouvez répéter ces étapes pour ajouter jusqu'à huit filtres logiques.
/* <CollapserGroup> <Collapser id="basic-builder-filer-values-ui" title="Voir une capture d'écran de l'interface" > <img title="Une capture d'écran du générateur de décision de base, filtrant par valeurs." alt="Une capture d'écran du générateur de décisions de base, filtrant par valeurs." src="/images/alerts_screenshot-crop_basic-decision-builder-filter-values.webp" /> </Collapser> </CollapserGroup> */
Étape 3 : Filtrer par entité liée
Cliquez sur Filter by related entities et choisissez les classes d’entité.
Lorsque vos données sont collectées par l'agentNew Relic , vous obtenez une corrélation topologique automatique. En savoir plus sur notre corrélation de topologie par défaut.
Vous pouvez également configurer les paramètres de topologie à l'aide de notre API NerdGraph. Cela permet à toute décision liée à la topologie d'être mise en correspondance avec vos données topologiques. En savoir plus sur la configuration de la corrélation de topologie.
/* <CollapserGroup> <Collapser id="basic-builder-related-entities-ui" title="Voir une capture d'écran de l'interface" > <img title="Une capture d'écran du générateur de décision de base, filtrant par entités." alt="Une capture d'écran du générateur de décision de base, filtrant par entités." src="/images/alerts_screenshot-crop_basic-decision-builder-filter-related-entities.webp" /> </Collapser> </CollapserGroup> */
Étape 4 : définir la plage de temps de corrélation
Cela définit la différence de temps maximale autorisée entre les heures de création de deux événements d'alerte pour qu'ils soient pris en compte pour la corrélation. Les événements d'alerte compris dans cette plage seront évalués selon des règles spécifiées, tandis que ceux en dehors de la plage ne seront pas corrélés.
La plage horaire est définie par défaut sur 20 minutes. Vous pouvez l'ajuster entre 1 et 120 minutes.
/* <CollapserGroup> <Collapser id="basic-builder-time-range" title="Voir une capture d'écran" > <img title="Une capture d'écran du générateur de décision de base, définissant une plage temporelle de corrélation." alt="Une capture d'écran du générateur de décisions de base, définissant une plage de temps de corrélation." src="/images/alerts_screenshot-crop_basic-decision-builder-time-range.webp" /> </Collapser> </CollapserGroup> */
Étape 5 : Tester votre décision à l’aide d’une simulation
Après l'ajout d'une logique de filtrage, le système exécute automatiquement une simulation en utilisant les données d'événements d'alerte des 7 derniers jours pour vous aider à valider la décision avant de l'appliquer.
Vous pouvez également déclencher manuellement la simulation en cliquant sur Simulate, ce que vous souhaiterez peut-être faire si quelque chose a changé dans la décision.
/* <CollapserGroup> <Collapser id="basic-builder-test-with-simulation-ui" title="Voir une capture d'écran" > <img title="Une capture d'écran du générateur de décision de base, testé avec une simulation." alt="Une capture d'écran du générateur de décisions de base, testant avec une simulation." src="/images/alerts_screenshot-crop_basic-decision-builder-run-simulation.webp" /> </Collapser> </CollapserGroup> */
Étape 6 : Nommez et enregistrez votre décision
Pour accéder au panneau nom et description, cliquez sur Create decision. Le système génère un nom en fonction de votre décision. Personnalisez le nom et la description comme vous le souhaitez.
/* <CollapserGroup> <Collapser id="basic-builder-save-decision-ui" title="Voir une capture d'écran" > <img title="Une capture d'écran du générateur de décisions de base : nommer et enregistrer la décision" alt="Une capture d'écran du générateur de décisions de base : nommer et enregistrer la décision" src="/images/alerts_screenshot-crop_basic-decision-builder-name-describe.webp" /> </Collapser> </CollapserGroup> */
Générateur de décision avancé
Le générateur de décisions avancé permet de créer des décisions plus complexes en appliquant différents filtres logiques aux deux événements d'alerte en cours de corrélation. Par exemple, vous pouvez corréler des événements d'alerte si l'un a le nom d'entité host 1 et l'autre le nom d'entité host 2. Il existe également des paramètres plus avancés que la simple configuration de la fenêtre temporelle.
Pour utiliser le générateur de décision avancé :
- Allez à one.newrelic.com > All capabilities > Alerts > Decisions.
- Cliquez sur Create new decision, puis sur Use advanced builder.
Pour plus de détails sur les options disponibles, continuez à lire.
Termes importants :
- Filtre logique : Condition logique définie avec un opérateur sur un attribut.
- Segment : Un groupe d'événements d'alerte qui satisfont une combinaison de filtres logiques.
Pour créer votre propre décision personnalisée, procédez comme suit. Gardez à l’esprit que les étapes 1, 2 et 3 sont facultatives en elles-mêmes, mais au moins l’une des trois doit être définie pour prendre une décision.
Étape 1 : Filtrez vos données
Une corrélation se produit entre deux événements d'alerte. Si aucun filtre n'est défini, tous les événements d'alerte entrants seront pris en compte par la décision. Plus vous configurez vos décisions pour répondre à vos besoins, mieux nous pouvons corréler vos événements d'alerte, réduire le bruit et fournir un contexte enrichi aux équipes d'astreinte.
Votre équipe peut définir vos filtres pour le premier segment d'événements d'alerte et le deuxième segment d'événements d'alerte. Les opérateurs de filtrage vont de la correspondance de sous-chaîne à la correspondance par expression régulière pour vous aider à cibler les événements d'alerte que vous souhaitez et à exclure ceux que vous ne voulez pas.
/* <CollapserGroup> <Collapser id="advanced-decision-builder-filter-data-ui" title="Voir une capture d'écran" > <img title="Une capture d'écran du générateur de décisions avancé : filtrer vos données" alt="Une capture d'écran du générateur de décisions basique : filtrer vos données" src="/images/alerts_screenshot-crop_advanced-decision-builder-filter-data.webp" /> </Collapser> </CollapserGroup> */
Étape 2 : Corrélation par attribut
Une fois vos données filtrées, définissez la logique utilisée pour comparer le contexte des événements d'alerte. Vous pouvez corréler les événements selon les méthodes suivantes :
- Comparaisons de valeurs d'attributs avec des opérateurs standard
- Similarité des valeurs d'attributs à l'aide d'algorithmes de similarité
- Expression régulière de valeur d'attribut avec groupes de capture
- Comparaisons d'événements d'alerte complets à l'aide d'algorithmes de similarité ou de clustering
/* <CollapserGroup> <Collapser id="advanced-decision-builder-correlate-attributes-ui" title="Voir une capture d'écran de l'interface" > <img title="Une capture d'écran du générateur de décisions avancé : corrélation par attributs" alt="Une capture d'écran du générateur de décisions de base : corrélation par attributs" src="/images/alerts_screenshot-crop_advanced-decision-builder-correlate-attributes.webp" /> </Collapser> </CollapserGroup> */
Étape 3 : Corrélation par entité liée
Pour une corrélation topologique automatique, assurez-vous que vos données télémétriques sont collectées par l'agentNew Relic . En savoir plus sur la corrélation de topologie prête à l'emploi.
Vous pouvez également configurer les paramètres de topologie à l'aide de notre API NerdGraph. Cela permet à toute décision liée à la topologie d'être mise en correspondance avec vos données topologiques. En savoir plus sur la configuration de la corrélation de topologie.
/* <CollapserGroup> <Collapser id="advanced-builder-related-entities-ui" title="Voir une capture d'écran" > <img title="Une capture d'écran du générateur de décisions avancé : corréler par entités associées" alt="Une capture d'écran du générateur de décisions de base : corréler par entités associées" src="/images/alerts_screenshot-crop_advanced-decision-builder-related-entities.webp" /> </Collapser> </CollapserGroup> */
Étape 4 : Donnez-lui un nom
Après avoir configuré votre logique de décision, donnez-lui un nom reconnaissable et une description.
Conseil
Minimisez les problèmes de sécurité en vous assurant de ne pas ajouter d’informations sensibles ou personnelles à ces champs de texte ouverts.
Ceci est utilisé dans les notifications et d'autres zones de l'interface utilisateur pour indiquer quelle décision a provoqué la corrélation d'une paire d'événements d'alerte. Si vous ne souhaitez pas modifier les paramètres avancés par défaut à l'étape suivante, cliquez sur Create decision pour terminer la création.
/* <CollapserGroup> <Collapser id="advanced-builder-name-decision" title="Voir une capture d'écran de l'interface" > <img title="Une capture d'écran du générateur de décisions avancé : nommer la décision" alt="Une capture d'écran du générateur de décisions de base : nommer la décision" src="/images/alerts_screenshot-crop_advanced-decision-builder-name-decision.webp" /> </Collapser> </CollapserGroup> */
Étape 5 : Utiliser les paramètres avancés
Utilisez la zone des paramètres avancés pour personnaliser davantage le comportement de votre décision lors de la corrélation d'un événement. Chaque paramètre a une valeur par défaut, la personnalisation est donc facultative.
- Time window: Définit la durée maximale entre l'heure de création de deux événements d'alerte pour qu'ils soient éligibles à la corrélation.
- Issue priority: Remplace le paramètre de priorité par défaut (
inherit priority) pour attribuer une priorité supérieure ou inférieure si les événements d'alerte sont corrélés. - Frequency: Modifie le nombre minimum d'événements d'alerte qui doivent respecter la logique de décision pour que la décision se déclenche.
- Similarity:Si vous utilisez des opérateurs
similar todans votre logique de décision, vous pouvez choisir parmi une liste d'algorithmes et définir sa sensibilité. Cela s'appliquera à tous les opérateurssimilar tode votre décision.
/* <CollapserGroup> <Collapser id="advanced-builder-advanced-settings-ui" title="Voir une capture d'écran" > <img title="Décision - paramètres avancés" alt="Une capture d'écran du générateur de décisions montrant comment configurer les paramètres avancés." src="/images/alerts_screenshot-full_decision-builder-settings.webp" /> </Collapser> </CollapserGroup> */
Opérateurs logiques
Decision fournit un ensemble d'opérateurs pour vous aider à définir de manière flexible comment la valeur d'attribut d'un événement d'alerte est évaluée dans un filtre logique. Les éléments de base sont equals, contains, starts with, ends with, exists, ainsi que leurs opérateurs de négation respectifs. Par exemple, does not equal.
Il existe un opérateur de similarité is similar to, l'algorithme de similarité sous-jacent peut être spécifié pour cet opérateur. Par défaut, il utilise la distance de Levenshtein.
L'opérateur contains (regex) permet de définir une condition regex. Puissant pour faire correspondre des valeurs de données arbitraires.
Algorithmes de similarité
Voici les détails techniques sur les algorithmes de similarité que nous utilisons :
Opérateurs Regex
Lors de la construction d'une décision, les opérateurs disponibles incluent :
contains (regex): utilisé à l'étape 1 : Filtrez vos données.regular expression match:utilisé à l'étape 2 : Corrélation contextuelle.
Le générateur de décisions suit les normes décrites dans ces documents pour les expressions régulières.
Assistant de corrélation
Vous pouvez utiliser l'assistant de corrélation pour analyser plus rapidement les événements d'alerte, créer une logique de décision et tester la logique avec une simulation. Pour utiliser l'assistant de corrélation :
- Accédez à l’onglet one.newrelic.com > All capabilities > Alerts > Issues & activity > Alert events.
- Cochez les cases des événements d'alerte que vous souhaitez corréler. Ensuite, au bas de la liste des événements d'alerte, cliquez sur Correlate alert events.
- Pour obtenir les meilleurs résultats lors de la corrélation des événements d'alerte, sélectionnez des attributs communs avec un faible pourcentage de fréquence. En savoir plus sur l'utilisation de la fréquence.
- Cliquez sur Simulate pour voir l’effet probable de votre nouvelle décision sur la dernière semaine de vos données.
- Cliquez sur des exemples de paires de corrélations pour déterminer les corrélations à utiliser.
- Si vous aimez ce qui a été simulé, cliquez sur Next, puis nommez et décrivez votre décision.
- Si le résultat de la simulation affiche trop d'événements d'alerte potentiels, vous pouvez choisir un ensemble différent d'attributs et d'événements d'alerte pour votre décision, et lancer une autre simulation. En savoir plus sur la simulation.
Simulation vs corrélation en temps réel
Il est important de comprendre la différence entre la simulation et la corrélation en temps réel dans les décisions :
Simulation: La corrélation de simulation consiste à analyser deux événements d'alerte distincts pour comprendre leur relation dans des conditions simulées. Ces événements d'alerte peuvent provenir soit du même problème sous-jacent, soit de problèmes différents. L'accent est mis sur la détermination des facteurs causaux potentiels ou des caractéristiques communes entre les événements d'alerte individuels. La simulation vous permet de tester et de valider votre logique de corrélation sur des données historiques avant de l'appliquer en temps réel.
Real-time correlation (decisions): En revanche, la corrélation en temps réel cible des problèmes distincts, chaque problème pouvant englober plusieurs événements d'alerte. L'objectif est de détecter et de relier des modèles à travers ces multiples événements d'alerte afin d'identifier les problèmes sous-jacents pour une corrélation plus efficace. La corrélation en temps réel exploite les flux de données en direct, permettant une identification et une réponse rapides aux problèmes émergents.
Utilisation de la simulation
La simulation teste votre logique de corrélation en analysant deux événements d'alerte distincts issus de la dernière semaine de vos données, vous indiquant combien de corrélations se seraient produites. Cela vous permet de valider votre logique de décision avant qu'elle ne soit appliquée à la corrélation des problèmes en temps réel. Voici le détail des informations d'aperçu de la décision affichées lors d'une simulation :
- Potential correlation rate: Le pourcentage d'événements d'alerte testés que cette décision aurait affectés.
- Total created alert events: Le nombre d'événements d'alerte testés par cette décision.
- Total estimated correlated alert events: Le nombre estimé d'événements d'alerte que cette décision aurait corrélés.
- Alert event examples: Une liste de paires d'événements d'alerte que la décision aurait corrélées, incluant les attributs et valeurs de la règle, ainsi que d'autres attributs populaires dans chaque paire. Cliquez sur les événements d'alerte pour afficher les détails.
Exécutez la simulation avec différents attributs autant de fois que nécessaire jusqu'à ce que vous obteniez les résultats souhaités. Lorsque vous êtes prêt, suivez l’invite UI pour enregistrer votre décision.
Corrélation de topologie
Pour les alertes New Relic, la topologie est une représentation de votre carte de services : la manière dont les services et les ressources de votre infrastructure sont liés les uns aux autres.
Pour les décisions utilisateur, une décision de topologie par défaut est ajoutée et activée dans votre compte. Vous avez également la possibilité de créer des décisions personnalisées.
Notre corrélation topologique identifie les relations entre les sources d'événements d'alerte pour déterminer si les événements d'alerte et donc leurs problèmes respectifs doivent être corrélés. La corrélation de topologie est conçue pour améliorer la qualité de vos corrélations et la vitesse à laquelle elles sont trouvées.
Exigences
Pour la corrélation automatique de la topologie (sans avoir besoin de configurer explicitement le graphe de topologie), assurez-vous que vos données de télémétrie sont collectées par des agents New Relic. Plus il y a de types d'agents New Relic installés dans vos services et votre environnement, plus les décisions de topologie ont d'opportunités de corréler vos événements d'alerte.
Comment fonctionne la corrélation topologique ?
Dans cette carte de service, les hôtes et les applications sont les sommets et les lignes montrant leurs relations sont les arêtes.
Pour configurer votre topologie en plus de l'entité et des relations collectées par l'agentNew Relic , utilisez notre APINerdGraph.
La corrélation de topologie personnalisée repose sur deux concepts principaux :
- Vertex: Un sommet représente une entité monitorée. Il s'agit de la source d'où proviennent vos événements d'alerte, ou qui décrit un symptôme problématique. Un sommet possède des attributs (paires clé/valeur) configurés, tels que des GUID d'entité ou d'autres identifiants, qui permettent de l'associer aux événements d'alerte entrants.
- Edges: Une arête est une connexion entre deux sommets. Les arêtes décrivent la relation entre les sommets.
Il peut être utile de comprendre comment la topologie est utilisée pour corréler les événements d'alerte :
Tout d'abord, New Relic collecte tous les événements d'alerte pertinents. Cela inclut les événements d'alerte pour lesquels les étapes 1 et 2 de la logique de décision sont vraies et qui se situent également dans la fenêtre temporelle définie dans les paramètres avancés.
Ensuite, nous tentons d'associer chaque événement d'alerte à un sommet de votre graphe de topologie, en utilisant les attributs définissant un sommet et les attributs disponibles sur l'événement d'alerte.
Un exemple des étapes pour associer les événements d'alerte aux informations dans le graphe de topologie.
Ensuite, les paires de sommets associées à des événements d'alerte sont testées à l'aide de l'opérateur « topologiquement dépendant » pour déterminer si ces sommets sont connectés entre eux.
Cet opérateur vérifie s'il existe un chemin dans le graphique qui relie les deux sommets en cinq sauts.
Les événements d'alerte sont ensuite corrélés et les problèmes sont fusionnés.
Ajouter des attributs aux événements d'alerte
Les événements d'alerte sont connectés aux sommets à l'aide des attributs de définition d'un sommet. (Dans l'exemple de topologie sous Explication de la topologie, chaque sommet possède un attribut de définition "CID" avec une valeur unique.) Ensuite, le système d'alertes de New Relic trouve un sommet qui correspond à l'attribut.
Si l'attribut de définition que vous souhaitez utiliser sur vos sommets ne figure pas déjà dans vos événements d'alerte, utilisez l'une de ces options pour l'ajouter :
Créer ou afficher la topologie
Pour configurer votre topologie ou afficher la topologie existante, consultez le didacticiel sur la topologie NerdGraph.