• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

Cette traduction automatique est fournie pour votre commodité.

En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.

Créer un problème

Alertes en streaming : termes et concepts clés

La plateforme de streaming vérifie les incidents en fonction des données présentes ou manquantes dans votre flux de données, ou signal, entrant dans New Relic.

Vous pouvez utiliser les conditions NRQL pour contrôler la partie du signal dont vous souhaitez être informé. Votre condition NRQL filtre les données traitées par l'algorithme de streaming.

Il existe trois méthodes pour agréger les données filtrées via votre condition NRQL :

  • Flux d'événement (par défaut)
  • Minuterie d'événement
  • Cadence

Cette courte vidéo décrit la méthode des trois agrégations (5:31).

Pourquoi c'est important

Comprendre le fonctionnement des alertes en streaming vous aidera à affiner vos conditions NRQL pour être informé de ce qui est important pour vous.

A diagram that demonstrates how data is streamed into New Relic.

Seules les données correspondant aux conditions de la clause NRQL WHERE font l'objet d'alertes. Pour plus de détails sur chaque étape du processus, consultez Processus et descriptions des alertes en streaming.

Lorsque les données circulent dans New Relic, elles sont filtrées par la condition NRQL. Avant que les données ne soient évaluées, elles doivent répondre aux critères définis par la clause WHERE de la requête NRQL. Au lieu d'évaluer immédiatement ces données en cas d'incident, la condition d'alerte NRQL collecte les données sur une période de temps appelée fenêtre d'agrégation. Un délai/minuterie supplémentaire permet aux points de données plus lents d'arriver avant que la fenêtre ne soit agrégée.

Une fois le délai/la temporisation écoulé, New Relic regroupe les données en un seul point de données. Les alertes comparent ensuite le point de données aux critères de seuil de la condition pour déterminer si un incident doit être ouvert.

Même si un point de données répond aux critères d’un incident, il se peut qu’un incident ne soit pas ouvert. Un incident n'est ouvert que lorsque les points de données répondent systématiquement aux critères de seuil sur une période donnée. Il s'agit de la durée seuil. Si les points de données dépassent la durée totale du seuil, nous vous enverrons une notification en fonction de vos paramètres de politique.

Tous ces délais configurables vous donnent plus de contrôle sur la manière dont vous recevez des alertes sur les données sporadiques et manquantes.

Processus et descriptions des alertes en streaming

Processus

Description

données de streaming

Toutes les données entrant dans New Relic.

Clause WHERE

Filtre toutes les données de streaming entrantes. Nous monitorons uniquement les alertes sur les données qui passent à travers ce filtre.

Méthodes d'agrégation

L'une des trois méthodes qui contrôlent la manière dont les données sont collectées avant d'être évaluées.

Ils sont:

  • Flux d'événements (par défaut)
  • Minuterie d'événement
  • Cadence

Fenêtre d'agrégation

Les données dont l’horodatage se situe dans cette fenêtre seront agrégées puis évaluées.

Fenêtres coulissantes

Lorsqu'elle est activée, cette option provoque le chevauchement des fenêtres d'agrégation, créant ainsi des graphiques plus fluides.

Utilisez la durée des fenêtres coulissantes pour définir la durée pendant laquelle vos fenêtres d’agrégation se chevauchent.

Important

Les clients bénéficiant des plans tarifaires Advanced et Core Compute peuvent encourir des frais CCU supplémentaires lors de l'utilisation de l'agrégation de fenêtres coulissantes. Bien que cette méthode améliore l’analyse des données en atténuant les fluctuations, son utilisation peut entraîner une augmentation des coûts par rapport à d’autres méthodes. Pour plus de détails, consultez la section de tarification des fenêtres coulissantes. Pour déterminer si vous utilisez les plans tarifaires Advanced ou Core Compute, reportez-vous à votre commande.

Retard/minuterie

Un délai pour garantir que tous les points de données sont arrivés dans la fenêtre d'agrégation avant que l'agrégation ne se produise.

Données agrégées

Les données de la fenêtre agrégée sont réduites à un seul point de données pour l’évaluation de l’alerte.

Évaluation

Le point de données est évalué par la condition NRQL, qui est déclenchée par chaque point de données agrégé entrant.

Durée du seuil

Une durée spécifique qui détermine si un incident est créé. Si votre condition NRQL spécifiée répond aux critères de seuil pendant la durée du seuil, un incident se produit.

Lorsqu'un point de données manque de données, une valeur personnalisée est insérée pour combler le vide.

Choisissez votre méthode d'agrégation

Vous pouvez choisir entre trois méthodes d’agrégation différentes, en fonction de vos besoins.

Le flux d'événement (par défaut) fonctionne mieux pour les données qui arrivent fréquemment et généralement dans l'ordre.

Le minuteur d'événement fonctionne mieux pour les données qui arrivent rarement par lots, telles que les données cloud d'intégration ou les logs des erreurs peu fréquentes.

Cadence est notre méthode d'agrégation originale et inférieure. Il regroupe les données sur des intervalles de temps spécifiques détectés par l'horloge interne de New Relic, quel que soit l'horodatage des données.

Voici une courte vidéo (5:35 minutes) expliquant les méthodes d'agrégation :

Déroulement de l'événement

Le flux d'événements agrège une fenêtre de données lorsque le premier point de données arrive dans une fenêtre ultérieure. Le délai personnalisé définit les données de fenêtre suivantes qui commenceront à se remplir pour déclencher l'agrégation de la fenêtre actuelle. Un délai personnalisé fournit un délai supplémentaire pour que les données arrivent. Ces heures sont basées sur l'horodatage des données et non sur l'horloge de New Relic.

Par exemple, supposons que vous monitoring l'utilisation du processeur dans des fenêtres de durée d'une minute et un délai de 3 minutes.

Lorsqu'un point de données d'utilisation du processeur arrive avec un horaire compris entre 12h00 et 12h01, le flux d'événements n'agrégera pas cette fenêtre jusqu'à ce qu'un point de données apparaisse avec un horaire compris entre 12h04 et 12h05. Lorsque le flux d'événements reçoit le premier point de données avec un horodatage de 12h04 ou plus tard, il envoie les données de 12h00 à 12h01 à agréger.

Prudence

Si vous prévoyez que vos points de données arriveront à plus de 65 minutes d'intervalle, veuillez utiliser la méthode du minuteur d'événement décrite ci-dessous.

Minuterie d'événement

Comme le flux d'événements, le minuteur d'événements agrégera uniquement les données d'une fenêtre donnée lorsque les données arriveront pour cette fenêtre. Lorsqu'un point de données arrive pour une fenêtre d'agrégation, un minuteur dédié à cette fenêtre commence le compte à rebours. Si aucune autre donnée n’arrive avant la fin du compte à rebours, les données de cette fenêtre sont agrégées. Si davantage de points de données arrivent avant que le compte à rebours du minuteur ne soit terminé, le minuteur est réinitialisé.

Par exemple, supposons que vous monitoring des données CloudWatch qui arrivent assez rarement. Vous utilisez une durée de fenêtre de 1 minute et une minuterie de 3 minutes.

Lorsqu'un point de données CloudWatch arrive avec un horodatage compris entre 12h00 et 12h01, le compte à rebours commence. Si aucun autre point de données n'apparaît pour cette fenêtre 12h00-12h01, la fenêtre sera agrégée 3 minutes plus tard.

Si un nouveau point de données avec un horodatage compris entre 12h00 et 12h01 arrive, le minuteur se réinitialise. Il continue de se réinitialiser chaque fois que de nouveaux points de données arrivent pour cette fenêtre. La fenêtre ne sera pas envoyée pour agrégation tant que le minuteur n'atteindra pas 0.

Si le délai d'un point de données ultérieur s'écoule avant un point de données antérieur, la méthode du délai d'événement attend que le délai antérieur s'écoule avant d'agréger le point de données ultérieur.

Pour de meilleurs résultats, assurez-vous que votre minuterie est égale ou supérieure à la durée de votre fenêtre. Si le délai est inférieur à la durée de votre fenêtre et que votre flux de données est incohérent, vos données peuvent être évaluées avant l'arrivée de tous vos points de données. Cela pourrait entraîner une notification erronée.

Cadence

Nous vous recommandons d’utiliser l’une des deux autres méthodes.

Cadence est notre ancienne méthode d'agrégation de streaming. Cette méthode utilise l'horloge temps de New Relic pour déterminer quand les données sont agrégées et évaluées. Il ne prend pas en compte l'horaire des points de données au fur et à mesure de leur arrivée.

Outils d'alertes en streaming

Les alertes en streaming fournissent un ensemble d'outils pour vous donner un meilleur contrôle sur la manière dont vos données sont agrégées avant d'être évaluées afin de réduire les notifications incorrectes que vous recevez. Ils sont:

  • Durée de la fenêtre
  • Retard/minuterie
  • Détection de perte de signal
  • Comblement des lacunes

Conseil

Cet article couvre ces outils à un niveau conceptuel. Vous trouverez des instructions directes sur la façon d'utiliser ces outils dans Créer une condition d'alerte NRQL .

Durée de la fenêtre

Afin de rendre la détection de perte de signal plus efficace et de réduire les notifications inutiles, vous pouvez personnaliser les fenêtres d'agrégation en fonction de la durée dont vous avez besoin.

Une fenêtre d’agrégation est un bloc de temps spécifique. Nous rassemblons des points de données dans une fenêtre d’agrégation, avant d’évaluer les données. Une fenêtre d'agrégation plus longue peut lisser les données, car un point de données de valeur hors norme aura plus de points de données avec lesquels être agrégé, ce qui lui donnera moins d'influence sur le point de données agrégé envoyé pour évaluation. Lorsqu'un point de données arrive, son horodatage est utilisé pour le placer dans la fenêtre d'agrégation appropriée.

Vous pouvez définir votre fenêtre d'agrégation sur une valeur comprise entre 30 seconds et 6 hours. La valeur par défaut est 1 minute.

Retard/minuterie

Le paramètre de délai/minuterie contrôle la durée pendant laquelle la condition doit attendre avant d'agréger les données dans la fenêtre d'agrégation.

Les méthodes de flux et de cadence d'événements utilisent le délai. Le minuteur d'événement utilise un minuteur.

Le délai par défaut est 2 minutes. La valeur par défaut du minuteur est 1 minute, sa valeur minimale est 5 seconds et sa valeur maximale est 20 minutes.

Détection de perte de signal

La perte de signal se produit lorsqu'aucune donnée ne correspond à la condition NRQL sur une période de temps spécifique. Une perte de signal est causée par différentes choses. La clause WHERE de votre requête NRQL peut filtrer les données avant qu'elles ne soient évaluées en cas d'incident. Cela peut également signifier qu'un service ou une entité est hors ligne ou qu'une tâche périodique n'a pas pu être exécutée et qu'aucune donnée n'est envoyée à New Relic.

Afin d'éviter toute notification inutile, vous pouvez choisir le temps d'attente avant d'être averti en cas d'incident de perte de signal. Vous pouvez utiliser la détection de perte de signal pour ouvrir un incident et être averti lorsqu'un signal est perdu. Alternativement, vous pouvez utiliser une perte de signal pour fermer un incident pour des services éphémères ou des données sporadiques, telles que le nombre d'erreurs.

Comblement des lacunes

Le remplissage des lacunes vous permet de personnaliser les valeurs à utiliser lorsque vos signaux ne contiennent aucune donnée. Vous pouvez combler les lacunes dans vos flux de données avec la dernière valeur reçue, une valeur statique, ou bien ne rien faire et laisser le vide là. La valeur par défaut est None.

Les lacunes dans les données de streaming peuvent être causées par des problèmes de réseau ou d'hôte, un signal peut être clairsemé ou certains signaux, tels que le nombre d'erreurs, peuvent uniquement contenir des données lorsque quelque chose ne va pas. En comblant les lacunes avec des valeurs connues, le processus d’évaluation des alertes peut traiter ces lacunes et déterminer comment elles devraient affecter l’évaluation de la perte du signal.

Conseil

Le système d’alertes comble les lacunes dans les signaux signalés activement. Cet historique de signal est supprimé après 2 heures d'inactivité. Pour combler les lacunes, les points de données reçus après cette période d'inactivité sont traités comme de nouveaux signaux.

Pour en savoir plus sur la perte de signal et le remplissage des espaces, consultez cette publication du forum d'assistance.

Droits d'auteur © 2025 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.