Nouvelles annonces sur les technologies sans serveur et réseau ainsi que sur le RUM (Real-User Monitoring) dévoilées à la conférence Dash ! Nouvelles annonces dévoilées à la conférence Dash !

Métriques

Introduction

Cette section décrit le fonctionnement et l’utilité des métriques. Après avoir lu cette section, vous saurez comment envoyer des métriques custom et comprendrez plus clairement le fonctionnement de Datadog. Pour obtenir plus d’informations sur DogStatsD (qui permet d’implémenter ces métriques), consultez la documentation relative à DogStatsD.

Envoyer des métriques

Il existe plusieurs façons d’envoyer des métriques à Datadog :

  1. Directement via l’Agent Datadog. Découvrez comment rédiger une intégration ou jetez directement un œil au code source de l’agrégateur.
  2. Via le serveur DogStatsD (fourni avec l’Agent Datadog) et une bibliothèque client.
  3. Directement via l’API HTTP de Datadog.
  4. Via la bibliothèque de métriques Java Dropwizard avec le backend metrics-datadog. Nous tenons à remercier les équipes de Vistar Media, Coursera et Bazaarvoice pour leurs contributions.
Les timestamps de métrique ne peuvent pas correspondre à une date plus d'une heure avant l'événement et plus de 10 minutes après celui-ci.

Nommer les métriques

Il convient de suivre les règles suivantes concernant les noms de métriques :

  • Ils doivent commencer par une lettre.
  • Ils doivent seulement contenir des caractères alphanumériques ASCII, des underscores et des points.
    • Les autres caractères, y compris les espaces, sont remplacés par des underscores.
    • La norme Unicode n’est pas prise en charge.
  • Ils ne doivent pas dépasser 200 caractères. Nous vous recommandons d’utiliser moins de 100 caractères pour l’interface utilisateur.

Les métriques renvoyées par l’Agent respectent un format pseudo hiérarchique séparé par des points (p. ex., http.nginx.response_time). La hiérarchie n’est ni appliquée ni interprétée, mais elle peut être utilisée pour déduire des éléments concernant les serveurs. Par exemple, si hostA et hostB renvoient tous les deux http.nginx.*, il doit s’agir de front-ends web.

Types de métriques

Dans l’application Datadog, le type des métriques affecte leur interprétation dans les résultats de requêtes et les visualisations graphiques. Ce type est visible et peut être modifié sur la page de résumé des métriques. Attention, si vous modifiez le type de métrique, toutes les données historiques seront peut-être incompréhensibles.

Il existe quatre types de métriques dans l’application Web de Datadog (l’une d’entre elles est cependant obsolète) :

  • COUNT
  • COUNTER (obsolète)
  • GAUGE
  • RATE

Le type d’une métrique est stocké sous forme de métadonnées de métriques et est utilisé pour déterminer l’interprétation d’une métrique dans l’application, en établissant la fonction d’agrégation temporelle par défaut et le comportement as_rate()/as_count(). Les modificateurs as_count() et as_rate() se comportent différemment selon les types de métriques de l’application Web.

Types d’envois et de métriques au sein de l’application Datadog

Datadog prend en charge l’envoi de métriques à partir de diverses sources. Par conséquent, le type d’envoi (c’est-à-dire, le cas d’utilisation) ne correspond pas toujours exactement au type de métriques au sein de l’application Datadog :

Source de l’envoiMéthode d’envoi (python)Type d’envoiType au sein de l’application Datadog
APIapi.Metric.send(type="count", ...)countcount
APIapi.Metric.send(type="gauge", ...)gaugegauge
APIapi.Metric.send(type="rate", ...)raterate
DogStatsDdog.gauge(...)gaugegauge
DogStatsDdog.histogram(...)histogramgauge, rate
DogStatsDdog.increment(...)counterrate
DogStatsDdog.set(...)setgauge
Check de l’Agentself.count(...)countcount
Check de l’Agentself.gauge(...)gaugegauge
Check de l’Agentself.histogram(...)histogramgauge, rate
Check de l’Agentself.increment(...)counter obsolèterate
Check de l’Agentself.monotonic_count(...)monotonic_countcount
Check de l’Agentself.rate(...)rategauge
Check de l’Agentself.set(...)setgauge

Modifier le type d’une métrique

Bien que cette opération ne soit généralement pas requise, vous pouvez modifier le type d’une métrique. Par exemple :

  1. Vous disposez d’une métrique app.requests.served qui compte les requêtes traitées, mais vous l’avez envoyée par inadvertance via StatsD en tant que gauge. Le type de métrique dans Datadog est donc gauge.

  2. Vous souhaitez envoyer app.requests.served en tant que métrique counter StatsD pour l’agréger temporellement. Cela vous permettrait de déterminer le nombre de requêtes traitées lors des dernières 24 heures, en envoyant sum:app.requests.served{*}. Cette requête est cependant illogique pour une métrique de type gauge.

  3. Vous souhaitez conserver le nom app.requests.served. Ainsi, au lieu d’envoyer un nouveau nom de métrique avec un type counter plus approprié, vous pouvez modifier le type de app.requests.served en mettant à jour :

    • Votre code d’envoi, en appelant dogstatsd.increment('app.requests.served', N) après le traitement de N requêtes.
    • Le type au sein de l’application Datadog, via la page de résumé des métriques, en le définissant sur rate.

Ainsi, les données envoyées avant le changement de type pour app.requests.served affichent un comportement incorrect, car elles ont été enregistrées dans un format qui doit être interprété comme un type gauge et non comme un type rate au sein de l’application. Les données envoyées après les étapes 3a et 3b sont interprétées correctement.

Si vous ne souhaitez pas perdre les données historiques envoyées en tant que type gauge, créez un nom de métrique avec le nouveau type, en laissant le type de requête app.requests.served inchangé.

Remarque : pour le check de l’Agent, self.increment ne calcule pas le delta pour un accroissement uniforme de counter, mais signale la valeur transmise lors du check. Pour envoyer la valeur delta pour un accroissement uniforme de counter, utilisez self.monotonic_count.

Unités

Pour éliminer toute ambiguïté et vous aider à mieux comprendre vos systèmes, les unités suivantes peuvent être associées aux métriques soumises à Datadog.

typeunité(s)
BYTESbit / byte / kibibyte / mebibyte / gibibyte / tebibyte / pebibyte / exbibyte
TIMEnanosecond / microsecond / millisecond / second / minute / hour / day / week
PERCENTAGEpercent_nano / percent / apdex / fraction
NETWORKconnection / request / packet / segment / response / message / payload / timeout / datagram / route / session
SYSTEMprocess / thread / host / node / fault / service / instance / cpu
DISKfile / inode / sector / block
GENERALbuffer / error / read / write / occurrence / event / time / unit / operation / item / task / worker / resource / garbage collection / email / sample / stage / monitor / location / check / attempt / device / update / method / job / container / execution / throttle / invocation / user / success / build / prediction
DBtable / index / lock / transaction / query / row / key / command / offset / record / object / cursor / assertion / scan / document / shard / flush / merge / refresh / fetch / column / commit / wait / ticket / question
CACHEhit / miss / eviction / get / set
MONEYdollar / cent
MEMORYpage / split
FREQUENCYhertz / kilohertz / megahertz / gigahertz
LOGGINGentry
TEMPERATUREdegree celsius / degree fahrenheit
CPUnanocore / microcore / millicore / core / kilocore / megacore / gigacore / teracore / petacore / exacore

Les unités sont affichées automatiquement sur des graphiques de série temporelle, des widgets de valeur de requête et des Top Lists, comme indiqué sur la capture d’écran du dashboard Redis ci-dessous :

Sur des graphiques de série temporelle, déplacez votre curseur sur un graphique pour afficher les unités pertinentes. Les données brutes sont automatiquement converties en unités d’affichage lisibles (fractions de seconde en ms, millions d’octets par seconde en MiB/s, etc.) :

Les unités sont également affichées en bas des graphiques de timeboard. Vous pouvez accéder aux descriptions des métriques en sélectionnant Metrics Info dans la liste déroulante :

Pour aller plus loin