Types de métriques OTLP

Présentation

L’Agent Datadog et l’exportateur Datadog pour le Collector OpenTelemetry peuvent ingérer les métriques au format OpenTelemetry (OTLP), qui sont générées par les applications instrumentées via OpenTelemetry.

Les types de métriques OTLP suivants peuvent être ingérés par l’Agent Datadog et l’exportateur Datadog pour le Collector OpenTelemetry :

  • Sum
  • Gauge
  • Histogram
  • Summary

Ces types de métriques OTLP sont mis en correspondance avec les types de métriques Datadog :

  • COUNT
  • GAUGE
  • DISTRIBUTION

Une même métrique OTLP peut être mise en correspondance avec plusieurs métriques Datadog différentes, un suffixe étant ajouté pour indiquer leur signification.

Remarque : OpenTelemetry offre des instruments pour l’API Metrics (Gauge, Counter, UpDownCounter, Histogram, etc.) dont les mesures peuvent être exportées en tant que métriques OTLP (Sum, Gauge, Histogram). Les métriques OTLP peuvent également provenir d’autres sources. Certaines applications et bibliothèques permettent de personnaliser les métriques OTLP qu’elles génèrent. Consultez la documentation de votre SDK OpenTelemetry ou de votre application qui génère des métriques OTLP pour mieux comprendre ces métriques et découvrir comment les personnaliser.

Remarque : le protocole OpenTelemetry peut représenter de deux manières l’évolution temporelle des métriques, avec la temporalité cumulative et delta. Cette temporalité s’applique aux métriques décrites plus bas. Définissez la préférence de temporalité de l’implémentation OpenTelemetry sur DELTA, car la méthode CUMULATIVE peut ignorer certains points de données lors du lancement de l’application (ou du collecteur). Pour en savoir plus, consultez la section Générer des métriques de temporalité delta avec OpenTelemetry.

Types de métriques

Correspondances

Une métrique OTLP de type Sum représente une somme de mesures transmises sur un certain intervalle. Par exemple, une métrique Sum peut être utilisée pour suivre le nombre total de connexions à une base de données ou le nombre total de requêtes vers un endpoint. La mise en correspondance des métriques Sum dépend de deux caractéristiques différentes :

  • Leur agrégation temporelle, qui peut être cumulative ou delta. Les intervalles de temps des métriques delta ne se chevauchent pas, tandis que les métriques cumulatives représentent un intervalle de temps avec un point de départ fixe.
  • Leur monotonicité. Les métriques Sum monotones ne diminuent jamais, et le count sous-jacent peut uniquement être additionné.

Les correspondances par défaut sont les suivantes :

  1. Dans le cas des métriques Sum cumulatives monotones, le delta entre les points consécutifs est calculé et transmis à Datadog en tant que count. Le premier point est stocké mais ignoré. Pour récupérer la valeur dans la charge utile OTLP, utilisez la fonction arithmétique cumsum.
  2. Les Sums cumulatives non monotones sont exportées en tant que gauges Datadog.
  3. Les Sums delta sont exportées en tant que counts Datadog.

Une métrique OTLP de type Gauge représente une valeur échantillonnée à un moment donné. Seule la dernière valeur sur un intervalle de temps donné est incluse dans les métriques OTLP.

Les Gauges OTLP correspondent à des Gauges Datadog, étant donné que ces métriques ne fournissent pas de sémantique d’agrégation. Les points de données sous forme d’entiers et de nombres à virgule flottante des métriques Gauge correspondent à des nombres à virgule flottante dans Datadog.

Une métrique OTLP de type Histogram représente la distribution statistique d’un ensemble de valeurs sur un intervalle de temps donné, certaines métriques d’agrégation telles que les Sums ou Counts d’une population de points étant stockées avec une série de counts de bucket. La mise en correspondance des métriques Histogram dépend d’une caractéristique :

  • Leur agrégation temporelle, qui peut être cumulative ou delta. Les intervalles de temps des métriques delta ne se chevauchent pas, tandis que les métriques cumulatives représentent un intervalle de temps avec un point de départ fixe.

Les correspondances par défaut sont les suivantes :

  1. Les Histograms delta sont transmis en tant que distributions Datadog. Consultez la documentation sur les distributions pour découvrir les agrégations disponibles.
  2. Dans le cas des métriques Histogram cumulatives, le delta entre les points consécutifs est calculé et transmis à Datadog en tant que distribution. Vous pouvez utiliser la fonction arithmétique cumsum ou des agrégations individuelles pour récupérer la valeur dans la charge utile OTLP.

Remarque : dans OTLP, les métriques histogram sont mappées aux métriques de distribution. En raison du processus d’envoi de ces données par OTLP, les agrégations max, min et percentile représentent des valeurs approximatives et ne sont pas le résultat de calculs précis.

L’Agent Datadog et l’exportateur Datadog pour le Collector OpenTelemetry permettent de changer l’exportation des métriques Histogram dans la sous-section histogram.

  • Si le mode est défini sur counters, les métriques suivantes sont générées :
<NOM_MÉTRIQUE>.bucket, avec les tags lower_bound et upper_bound
Count du bucket sur l’intervalle de temps du bucket, avec les limites inférieure et supérieure spécifiées.
Type stocké dans Datadog : COUNT
  • Si le paramètre send_count_sum_metrics est activé, les métriques suivantes sont générées :
<NOM_MÉTRIQUE>.sum
Somme des valeurs transmises pendant l’intervalle de temps.
Type stocké dans Datadog : COUNT
<NOM_MÉTRIQUE>.count
Nombre de valeurs transmises pendant l’intervalle de temps.
Type stocké dans Datadog : COUNT

Remarque : send_count_sum_metrics est uniquement utile lorsque vous n’utilisez pas le mode distributions.

Les métriques OTLP de type Summary, désormais obsolètes, indiquent les quantiles pour une population sur un intervalle de temps donné. Ces métriques ne sont pas générées par les SDK OpenTelemetry, mais d’autres composants sont susceptibles d’en générer à des fins de rétrocompatibilité.

<NOM_MÉTRIQUE>.sum
Somme des valeurs depuis que l’application a commencé à générer cette métrique.
Type stocké dans Datadog : COUNT
<NOM_MÉTRIQUE>.count
Nombre de valeurs dans la population.
Type stocké dans Datadog : COUNT
<NOM_MÉTRIQUE>.quantile, avec le tag quantile
Valeur d’un quantile spécifique.
Type stocké dans Datadog : GAUGE

Mappage des attributs

OTLP prend en charge deux types d’attributs : les attributs de points de données et les attributs de ressources. Ces attributs peuvent suivre les conventions sémantiques d’OpenTelemetry et ont une sémantique bien connue.

L’Agent Datadog et l’exportateur Datadog pour le Collector OpenTelemetry convertissent les attributs de points de données en tags. Les attributs de ressources qui respectent les conventions sémantiques d’OpenTelemetry sont mis en correspondance avec les conventions Datadog équivalentes, si elles existent.

Vous pouvez ajouter l’ensemble des attributs de ressources en tant que tags à l’aide du paramètre resource_attributes_as_tags.

Résolution du hostname

OpenTelemetry définit certaines conventions sémantiques liées aux hostnames. Si une charge utile OTLP possède un attribut de hostname connu, Datadog respecte ces conventions et tente d’utiliser sa valeur comme hostname. Les conventions sémantiques sont appliquées dans l’ordre suivant :

  1. datadog.host.name, une convention de hostname propre à Datadog
  2. Les conventions utilisées par les fournisseurs de cloud, en fonction de la convention sémantique cloud.provider
  3. Les conventions Kubernetes provenant des conventions sémantiques k8s.node.name et k8s.cluster.name
  4. host.id, l’ID unique du host
  5. host.name, le hostname du système

Si aucune convention n’est présente, Datadog attribue un hostname propre au système aux charges utiles. Si vous envoyez des données à partir d’un host à distance, ajoutez le processeur ‘resource detection’ à vos pipelines pour une résolution efficace du hostname.

Exemple

Imaginons que vous utilisez un instrument Counter OpenTelemetry depuis une seule application qui, par défaut, exporte des métriques Sum cumulatives et monotones. Le tableau suivant décrit le comportement de Datadog :

Période de collecteValeurs CounterValeur Sum OTLPValeur transmise à DatadogType stocké dans DatadogRemarques
N° 1[1,1,1,2,2,2,3,3]15AucuneCOUNTLa valeur de la première période de collecte n’est pas transmise.
N° 2[3,4,1,2]2510COUNTLa différence entre les valeurs est transmise.
N° 3[]250COUNTAucune nouvelle valeur n’a été transmise pendant cette période.

Imaginons que vous utilisez un instrument UpDownCounter OpenTelemetry depuis une seule application qui, par défaut, exporte des métriques Sum cumulatives. Le tableau suivant décrit le comportement de Datadog :

Période de collecteValeurs UpDownCounterValeur Sum OTLPValeur transmise à DatadogType stocké dans Datadog
N° 1[1,1,1,2,2,2,3,3]1515GAUGE
N° 2[3,-4,1,2]1717GAUGE
N° 3[-1]1616GAUGE

Imaginons que vous utilisez un instrument Gauge penTelemetry, temperature, depuis une seule application. Le tableau suivant décrit le comportement de Datadog :

Période de collecteInstrument GaugeValeur Gauge OTLPValeur transmise à DatadogType stocké dans Datadog
N° 171.571.571.5GAUGE
N° 2727272GAUGE
N° 3707070GAUGE

Imaginons que vous utilisez un instrument Histogram OpenTelemetry, request.response_time.histogram, à partir de deux serveurs Web : webserver:web_1 et webserver:web_2. Lors de la période de collecte donnée, webserver:web_1 renvoie les valeurs [1,1,1,2,2,2,3,3] pour la métrique, tandis que webserver:web_2 renvoie les valeurs [1,1,2]. Durant cette période de collecte, les cinq agrégations suivantes représentent la distribution statistique globale de l’ensemble des valeurs recueillies à partir des deux serveurs Web :

Nom de la métriqueValeurType stocké dans Datadog
avg:request.response_time.distribution1.73GAUGE
count:request.response_time.distribution11COUNT
max:request.response_time.distribution3GAUGE
min:request.response_time.distribution1GAUGE
sum:request.response_time.distribution19COUNT

Consultez la documentation sur les distributions pour comprendre comment configurer d’autres agrégations.

Par ailleurs, si vous utilisez le mode counters et que vous activez le paramètre send_count_sum_metrics, les métriques suivantes seront transmises si les limites du bucket de l’histogram sont définies sur [-inf, 2, inf] :

Nom de la métriqueValeurTagsType stocké dans Datadog
request.response_time.distribution.count8S.O.COUNT
request.response_time.distribution.sum15S.O.COUNT
request.response_time.distribution.bucket6lower_bound:-inf, upper_bound:2GAUGE
request.response_time.distribution.bucket2lower_bound:2, upper_bound:infGAUGE

Imaginons que vous envoyez une métrique OTLP de type Summary, request.response_time.summary, à partir d’un serveur Web. Lors de la période de collecte donnée, le serveur Web renvoie les valeurs [1,1,1,2,2,2,3,3] pour la métrique. Si les quantiles min., max. et médian sont activés, les métriques suivantes seront alors transmises :

Nom de la métriqueValeurTagsType stocké dans Datadog
request.response_time.distribution.count8S.O.COUNT
request.response_time.distribution.sum15S.O.COUNT
request.response_time.distribution.quantile1quantile:0GAUGE
request.response_time.distribution.quantile2quantile:0.5GAUGE
request.response_time.distribution.quantile3quantile:1.0GAUGE

Pour aller plus loin