OpenTelemetry fournit un modèle de données métriques dimensionnelles, une API pour l'enregistrement de la télémétrie métrique et un SDK pour l'agrégation et l'exportation de données métriques.
Cette page décrit comment New Relic gère les métriques OpenTelemetry qu'il reçoit via le point de terminaison New Relic OTLP. Voir les pages suivantes :
- Pour connaître les exigences configuration du point de terminaison, consultez New Relic OTLP point de terminaison.
- Pour obtenir des instructions sur la configuration des services avec OpenTelemetry, consultez Monitoring APM OpenTelemetry.
Modélisation du type d'instrument au type de métrique
L'API de métriques OpenTelemetry définit plusieurs types d'instruments. Les mesures d'enregistrement des instruments, qui sont agrégées et exportées via OTLP sous la forme d'un type métrique particulier. Le tableau ci-dessous décrit le comportement par défaut de chaque instrument OpenTelemetry agrège et exporte. Consultez la modélisation métrique OTLP pour plus de détails sur la manière dont chaque type de métrique est traité dans New Relic.
Type d'instrument | Exemple d'utilisation | Agrégation par défaut | Type de métrique exporté |
|---|---|---|---|
Octets traités |
| ||
Observer le temps CPU total du processus |
| ||
Éléments dans une file d'attente |
| ||
Observer l’utilisation actuelle de la mémoire |
| ||
Durée des requestshttp | |||
Changer l'événement pour la vitesse du ventilateur du CPU | |||
Observer la température ambiante actuelle |
Consultez les directives supplémentaires relatives aux métriques OpenTelemetry pour plus de détails sur le choix du type d'instrument approprié.
[1] L'instrument d'histogramme peut également être agrégé en métriques d'histogramme exponentielles. Voir OTLP histogramme métriques pour plus de détails.
Modélisation métrique OTLP
New Relic mappe les métriques OTLP au type de donnéesMetric . Le tableau ci-dessous décrit comment les champs des messages proto métriques sont interprétés. Consultez le type d'instrument en type métrique pour plus de détails sur la manière dont les différents types métriques sont produits par les API et les SDK OpenTelemetry .
Champ protométrique OTLP | Champ |
|---|---|
| Chaque valeur clé est un attribut sur le |
|
|
|
|
| Chaque valeur clé est un attribut sur le |
|
|
|
|
|
|
|
|
|
|
| Chaque valeur clé est un attribut sur le |
| Cartes de New Relic |
| Cartes vers New Relic |
| Cartes de New Relic |
| Cartes de New Relic |
| Cartes de New Relic |
[1]: En cas de conflit dans les champs d'attribut de ressource, d'attribut de portée, d'attribut de point métrique et de métrique de niveau supérieur, l'ordre de priorité (du plus élevé au plus bas) est : champs de niveau supérieur Metric.* > Metric.*.data_points.attributes > ScopeMetrics.InstrumentationScope.attributes > ResourceMetrics.Resource.attributes.
Consultez les types d'attributs OTLP pour plus de détails sur les types d'attributs pris en charge par le point de terminaison OTLP de New Relic.
Somme métrique OTLP
Les métriques de somme OTLP représentent la somme des mesures au fil du temps. Les sommes incluent un champ aggregation_temporality et un champ is_monotonic , qui indique si les valeurs augmentent de façon monotone (c'est-à-dire qu'elles ne peuvent qu'augmenter) ou non (c'est-à-dire qu'elles peuvent monter et descendre). Le tableau suivant décrit comment New Relic traite les différentes variétés de sommes :
|
| Comportement |
|---|---|---|
|
| Cartes de New Relic |
|
| Cartes de New Relic |
|
| Cartes de New Relic |
|
| Non pris en charge car les données ne sont pas significatives. Voir cette discussion pour plus de détails. |
Histogramme métrique OTLP
Les histogrammes métriques OTLP et les histogrammes métriques exponentiels résument une population de mesures avec des informations telles que la somme, le nombre, le minimum, le maximum et les compartiments décrivant la distribution des valeurs de mesure. La variété d'histogramme (également appelée histogramme de compartiments explicites) comporte des compartiments avec des limites explicites. La variété exponentielle comporte des compartiments dont les limites sont décrites par une formule exponentielle. Les deux variétés incluent un champ de temporalité d’agrégation .
Les deux variétés d'histogramme sont traduites en New Relic distribution, qui est soutenu par une représentation d'histogramme exponentielle de base 2 interne. Cette représentation reflète étroitement le format d'histogramme exponentiel d'OpenTelemetry. Pour cette raison, New Relic préfère l'histogramme exponentiel (voir l'agrégation d'histogramme métrique pour plus de détails sur la configuration d'OTLP pour préférer l'histogramme exponentiel). La variété d'histogrammes de compartiments explicites OpenTelemetry est traduite en représentation exponentielle à l'aide d'une interpolation linéaire. Voir NrSketch pour une explication détaillée.
Les buckets avec des limites à l'infini négatif et positif sont représentés dans New Relic comme des buckets de largeur nulle. Par exemple, un bucket OpenTelemetry avec des limites [-∞, 10) est représenté dans New Relic comme [10, 10). Par conséquent, vous pouvez voir des nombres de buckets exagérés aux extrémités de votre distribution.
OTLP métrique récapitulative
Les métriques récapitulatives OTLP sont similaires à l'histogramme dans la mesure où elles résument une population de mesures, y compris la somme et le nombre. Cependant, lorsque l'histogramme inclut des compartiments pour décrire la distribution des mesures, les résumés incluent des quantiles. Ces quantiles sont d’une utilité limitée car ils ne peuvent pas subir de réagrégation spatiale ou temporelle. Les résumés sont inclus dans OpenTelemetry pour la prise en charge legacy , et les API et SDK OpenTelemetry ne produisent pas de résumés.
Les résumés sont traduits en New Relic summary. Notez que le type de résumé New Relic ne prend pas en charge les quantiles.
Important
Bien que les résumés soient ingérés et traduits dans un New Relic summary, ils ne sont pas correctement pris en charge. New Relic suppose que les résumés représentent un delta depuis la dernière mesure alors qu'en fait ce sont des métriques cumulatives (voir temporalité d'agrégation). Les résumés sont le plus souvent rédigés par Prometheus qui est un système de métriques cumulatives. Par conséquent, New Relic ne prend pas actuellement en charge le cas d’utilisation le plus courant. De ce fait, vous subirez un comportement inattendu pour votre récapitulatif métrique, notamment un échec d'ingestion.
Temporalité de l'agrégation
La notion OpenTelemetry de temporalité d'agrégation définit si un point de données métrique particulier regroupe un ensemble cumulatif de mesures (généralement depuis le démarrage de l'application) ou l'ensemble delta de mesures depuis la dernière exportation. Les métriques de somme OTLP et les métriques d'histogramme ont un champ aggregation_temporality qui décrit la sémantique de leurs points.
Bien que nous acceptions à la fois les métriques de temporalité cumulatives et delta, New Relic est généralement un système de métriques delta, et nous encourageons l'utilisateur à configurer votre exportateur OTLP pour préférer la temporalité delta.
Lorsque la temporalité est cumulative, les métriques sont converties en une représentation delta (avec la valeur cumulative conservée pour cumulativeCount, en utilisant une translation à état est un processus à état dans lequel calculer le delta à partir de deux points cumulatifs consécutifs de la même série. Le Metric.*.data_points.start_time_unix_nano est utilisé pour détecter les réinitialisations en série.
Exemples de support
Les OpenTelemetry exemples métriques ne sont actuellement pas pris en charge par New Relic.