Si vous signalez des métriques cumulatives à partir de notre intégration OpenTelemetry ou de notre intégration d'écriture à distancePrometheus , cela vous aidera à comprendre comment New Relic gère ces données (par exemple, comment nous les convertissons en mesures delta). Cela vous aidera à comprendre les vues de votre UI New Relic, à interroger vos données et à comprendre les problèmes de reporting des données.
Explication des mesures cumulatives et delta
Lors de la collecte de données métriques à partir d'une application, il est important de prendre en compte la manière dont ces données ont été mesurées au moment de décider comment les utiliser et les interpréter au moment de la requête. Le type de métrique est un facteur important, certaines fonctions d'agrégation New Relic fonctionnant avec certains types et pas avec d'autres. Mais un autre facteur important est le temporality de la métrique.
Les deux temporalités sont delta et cumulative. Delta indique que les mesures sont réinitialisées entre les intervalles de rapport. Cumulative indique qu'il n'y a pas de réinitialisation et que les mesures sont accumulées. Prometheus est un exemple courant de collecteur de métriques cumulatives (documentation Prometheus sur les types de données), et OpenTelemetry définit également des moyens de collecter des métriques cumulatives (documentation OpenTelemetry sur la temporalité).
New Relic prend en charge les données cumulatives Prometheus et OpenTelemetry et effectuera une conversion delta lors de l'ingestion pour les rendre plus alignées avec d'autres métriques sur notre plateforme et plus faciles à interagir avec ces données via NRQL. Les compteurs cumulatifs sont stockés sous la forme de New ReliccumulativeCount et l'histogramme cumulatif est stocké sous la forme de New Relic distribution.
Prise en charge de l'écriture à distance de Prometheus
Pour plus d'informations, voir Intégration de l'écriture à distancePrometheus .
Prise en charge d'OpenTelemetry
Pour en savoir plus sur le support OpenTelemetry, voir OpenTelemetry métriques : bonnes pratiques.
Détails de conversion cumulatif en delta
À un niveau élevé, la conversion delta est effectuée en prenant deux points de données séquentiels dans le temps de l'événement et en calculant une différence. Mais dans la pratique, les choses ne sont jamais aussi simples. Voici quelques scénarios courants que nous anticipons et comment nous les gérons.
Réinitialisations
Si les données d'une série temporelle diminuent soudainement en valeur, nous traitons cela comme une réinitialisation et émettrons cette nouvelle mesure comme sa propre valeur delta (en d'autres termes, comme si elle était précédée d'une mesure 0 ).
OpenTelemetry définit également les situations dans lesquelles une diminution de valeur est inattendue, et nous faisons de notre mieux pour détecter ces cas et vous avertir via des erreurs d'intégration New Relic (voir le dépannage ci-dessous).
Réorganiser les données
Nous comprenons que de nombreux facteurs peuvent entraîner l'arrivée de points de données dans le désordre dans New Relic. Ainsi, nous mettrons en mémoire tampon les points de données et les réorganiserons si nous détectons un écart inattendu dans la série chronologique des rapports. Les lacunes sont déduites d’un intervalle de rapport prévu déterminé par la vitesse à laquelle nous recevons des données pour une série chronologique donnée. La mise en mémoire tampon est limitée et nous finirons par considérer qu'un point de données est « trop tard pour le reséquençage ». Dans ce cas, un delta est calculé sur l'écart détecté et le traitement de la série temporelle se poursuit.
Données obsolètes
La conversion delta étant une opération à état, nous devons être conscients des séries temporelles qui peuvent cesser de produire des rapports et éventuellement abandonner leur état. Si une série chronologique n'a signalé aucun nouveau point de données pour 5 minutes, nous viderons l'état dont nous disposons, y compris le calcul des deltas sur les éventuels écarts mis en mémoire tampon. Cela signifie que si un point de données arrive à un moment ultérieur, il sera traité comme s'il s'agissait du début de cette série chronologique, perdant ainsi efficacement le delta entre le dernier point de données avant le vidage et le premier point de données après le vidage. Cela signifie que les intervalles de rapport métrique doivent être inférieurs à 5 minutes pour bénéficier de la conversion delta.
Remarque spéciale sur les sommes cumulées
Même si les données ont été enregistrées par votre application et envoyées sous la forme d'une séquence de valeurs croissantes de façon monotone, l'appel de sum() les traitera comme s'il s'agissait d'une séquence de valeurs delta ; pas besoin de calculer de derivative()!
Lors de la conversion d'une somme en delta, New Relic émettra également la valeur cumulée à côté du delta pour vous permettre d'interroger la dernière valeur cumulée. Pour accéder à la valeur cumulée, vous pouvez utiliser getField() (voir Comment interroger les métriques pour des exemples).
Notez que les points de données sont tracés à leurs timestamps associés qui sont le début d'un intervalle. Cependant, les valeurs cumulatives sont associées au endTimestamp du point de données, vous devrez donc peut-être prendre en compte la largeur d'un point de données lors de l'interprétation de la requête cumulative.
Dépannage
Dans certains cas, nous signalerons une erreur d'intégration New Relic suite au processus de conversion cumulative en delta. Voici quelques raisons courantes.
Erreurs de traduction
La conversion delta implique l'hypothèse selon laquelle deux points de données séquentiels dans le temps de l'événement auront des valeurs cumulatives augmentant de manière monotone. Le seul moment où cette hypothèse est censée être rompue est lorsque le processus monitoré est redémarré. Si la monotonie est rompue pour une autre raison, nous traiterons toujours cela comme une réinitialisation, mais nous tenterons de vous en informer en générant un événement d'erreur d'intégration New Relic dans votre compte. Ceci est possible pour les données OpenTelemetry but not Prometheus, car OpenTelemetry inclut davantage d'informations qui peuvent être utilisées pour détecter de telles situations. La cause la plus courante d'une rupture inattendue de la monotonie survient lorsque l'application côté client atteint les limites de cardinalité et supprime des données pour soulager la pression de la mémoire. Dans certains cas, cela agit comme une réinitialisation inattendue et peut entraîner une diminution inattendue des valeurs envoyées à New Relic. Il est recommandé de rechercher un exemple de ceci dans votre log OTLP :
Instrument % has exceeded the maximum allowed accumulations (2000)Le SDK OpenTelemetry vous permet de configurer ses limites de cardinalité. OpenTelemetry fournit également un moyen de réduire la cardinalité côté client en utilisant Views et constitue le chemin recommandé pour résoudre ces problèmes. Une autre option consiste à explorer l’exportation de vos métriques OTLP à l’aide de la temporalité Delta, ce qui peut vous aider à économiser de la mémoire.
Limites de cardinalité
Lors de la traduction, nous appliquons également des limites de cardinalité métrique basées sur vos droits métriques en tant que protection du système. Plutôt que d'appliquer la limite par jour, comme nous le faisons avec les cumuls, cette limite est appliquée en fonction du nombre de séries chronologiques simultanées suivies. Une fois qu'il y a trop de séries temporelles métriques uniques simultanées, nous abandonnerons les nouvelles séries temporelles entrantes jusqu'à ce qu'une ancienne soit obsolète (voir Données obsolètes).
Réinitialisations métriques cumulatives
Les réinitialisations métriques cumulatives se produisent généralement lorsque le service ou l'application qui les signale redémarre. Lors de l'interrogation d'une métrique qui a été réinitialisée, il peut sembler que la valeur de la métrique a diminué, mais il s'agit d'un comportement attendu tel que décrit dans la spécification de métrique OpenTelemetry. Pour faire la différence entre les réinitialisations métriques normales et une métrique problématique qui diminue is manière inattendue, vérifiez votre compte pour détecter d'éventuelles erreurs d'intégration New Relic. Si aucune erreur d'intégration n'est signalée par rapport aux métriques avec des valeurs décroissantes, il est probable que votre application signalant les métriques cumulatives redémarre et réinitialise la valeur de la métrique.