Nos agents et ont des limites sur le nombre d'événements qui peuvent être signalés. Ce document explique :
- Pourquoi les limites de déclaration d'événements sont-elles nécessaires
- Comment fonctionne l'échantillonnage
- Comment travailler avec et comprendre les données échantillonnées
Différence entre événement et métriques
Ce document concerne les limites des données d'événements et la manière dont ces limites conduisent à l'échantillonnage. Tout d’abord, il peut être utile de comprendre les différences entre ces deux types de données :
- Metrics:mesures agrégées au fil du temps. Exemples : temps de réponse moyen sur une plage de temps d'une minute, débit au fil du temps, utilisation du processeur au fil du temps.
- Events:événement discret qui se produit à un moment précis dans le temps. Exemples : un log ou une erreur signalée, ou un changement configuration . Certains événements sont agrégés au fil du temps pour former des métriques (par exemple : un décompte des erreurs au fil du temps).
Ces deux types de données ont des utilisations différentes : les métriques sont utiles pour reconnaître des modèles au fil du temps dans votre système, et les événements sont utiles pour approfondir et obtenir des détails sur les causes de ces modèles. Étant donné que les métriques sont agrégées au fil du temps, elles sont utiles pour repérer les tendances et les changements dans le comportement du système. Pour les métriques qui représentent un nombre agrégé d'événements (comme une métrique de temps de réponse HTTP), l'événement individuel vous donne des détails granulaires sur ce qui s'est passé et vous permet de sélectionner les attributs qui ont une forte cardinalité (comme un compte ou un ID utilisateur).
Pourquoi l'échantillonnage d'un événement est-il nécessaire
Nos agents APM et agents mobiles ont des limites sur le nombre d'événements pouvant être signalés par cycle de collecte. Ceci est nécessaire car s'il n'y avait pas de limite, un très grand nombre d'événements envoyés pourrait avoir des impacts sur les performances de votre application ou sur New Relic. Lorsque la limite est atteinte, les agents commencent à échantillonner l'événement. Les différents agents ont des limites différentes, mais l’objectif est de donner un échantillon représentatif de l’ensemble du cycle de collecte.
De plus, les agents peuvent effectuer un échantillon s'ils ne peuvent pas se connecter à New Relic. Lorsqu'un agent ne peut pas se connecter à New Relic, il continue de stocker des données localement. Mais cela doit limiter la taille de la charge utile qui est finalement envoyée. Pour cette raison, il échantillonne l'événement pendant la période déconnectée. Plus il est déconnecté longtemps, plus il échantillonnera.
L'impact de l'échantillonnage
L’un des résultats de l’échantillonnage est qu’il peut y avoir une divergence entre les données métriques non échantillonnées et les données d’événement échantillonnées. Exemples de ceci :
- Un graphique APM montrant des données métriques non échantillonnées peut vous montrer un débit plus élevé qu'une requête NRQL équivalente de données d'événement échantillonnées. Pour en savoir plus sur la différence entre nos données d'intervalle de temps métrique et nos données d'événement, voir Types de données.
- Un service monitoring autre que New Relic peut afficher des résultats différents de ceux de New Relic.
Les événements plafonnés et sujets à échantillonnage comprennent :
TransactionTransactionErrorSpan(voir l'échantillonnage de tracing distribué)- événement personnalisé signalé via l'API d'agent (exemple : le RecordCustomEvent de l'agent .NET)
MobileMobileRequestMobileCrashMobileHandledException
Important
Pour APM, vous pouvez compenser l'échantillonnage lors de l'interrogation des données.
Modifier la façon dont l'échantillonnage se produit
Avant de tenter de modifier la manière dont l'échantillonnage se déroule, veuillez lire ces mises en garde et recommandations :
- Le signalement de plus d'événements entraînera une utilisation plus importante de mémoire par l'agent.
- Il existe généralement un moyen pour vous d'obtenir les données dont vous avez besoin sans augmenter la limite de rapport d'événements d'un agent.
- La limite de taille de charge est de 1 Mo (10^6 octets) (compressé), donc le nombre d'événements peut toujours être affecté par cette limite. Pour déterminer si les événements sont supprimés, consultez le log de l'agent pour un message d'état HTTP 413.
Voici quelques moyens d’influencer l’échantillonnage :
- La plupart des agents disposent d'options de configuration permettant de modifier la limite des transactions échantillonnées (exemples :
max_samples_storedde l'agent Java ousetMaxEventPoolSizede l'agent mobile Android). - S'il est important pour vous qu'une activité d'application spécifique ne soit pas échantillonnée, vous pouvez utiliser l' API événement.
- Vous pourriez déployer votre application sur un plus grand nombre d'instances. Étant donné que les limites sont par agent, un plus grand nombre d'agents signifiera un plus grand réservoir d'événements.
APM : Compenser l'échantillonnage
Lors de l'interrogation d'un événement signalé par APM, vous pouvez compenser l'échantillonnage en utilisant EXTRAPOLATE. Cela vous donnera une approximation de ce à quoi ressemblent les données non échantillonnées.