Monitorer des applications en production avec Metrics


Après nous avoir rappelé que les métriques sont une mesure essentielle pour l’optimisation des performances, Damien nous a présenté Metrics, un framework Java développé par Coda Hale pour la société Yammer, et dont la gouvernance est assurée par la Communauté Dropwizard. Son intérêt réside dans l’obtention d’indicateurs métiers, donc la perception du produit par le client. Les métriques ainsi obtenues permettront d’identifier les points critiques de l’application, et de savoir ce qui aura un impact fort lors d’un refactoring.
Les types de mesures qu’on peut obtenir sont :

  • Gauge : c’est une valeur à un instant donné. Elle permet par exemple de mesurer le nombre de jobs en attente ou le nombre de sessions HTTP actives.
  • Counter : une valeur qui est incrémentée ou décrémentée. Elle permet par exemple de mesurer le nombre de jobs en cours d’exécution, ou le nombre de requêtes HTTP en cours de traitement.
  • Meter : nombre moyen d’évènements sur une période de temps. Elle permet par exemple de mesurer la fréquence des requêtes en base.
  • Histogram : la distribution des valeurs dans un flux de données. On peut par exemple surveiller le nombre de résultats retournés par une requête, et obtenir la moyenne, le maximum, minimum…
  • Timer : c’est une combinaison de Meter et Histogram. Par exemple, on va obtenir la fréquence et la durée d’une requête en base sur une période de temps.

Metrics peut être intégré dans un framework comme Spring pour simplifier encore plus sa mise en place. On peut utiliser alors les annotations au niveau des méthodes pour ajouter des métriques rapidement et avec simplicité. La méthode pour une intégration dans Spring est expliquée dans cet article (qui est issu d’une série sur Metrics montrant également d’autres intégrations).

Un gros avantage de Metrics est le découplage entre la description de ce qui est mesuré et la manière dont les résultats sont modélisés : les systèmes de collecte de données et de calcul des statistiques sont séparés, ce qui limite le nombre de dépendances.

Il existe plusieurs manières de visualiser les mesures obtenues :

  • Reporting : dans la console, dans un CSV, avec JMX, Graphite, Ganglia ou par HTTP/Servlet ;
  • Monitoring-as-a-service : une exportation vers une application dans le cloud comme Librato, SPM ou Datadog ;
  • Une intégration avec une application comme Elasticsearch, Statsd ou InfluxDB est également possible.

Avant la démonstration, la présentation s’est terminée par un rappel de bonnes pratiques concernant les métriques, indépendamment de l’outil utilisé :

  • Donner des noms significatifs ;
  • Enregistrer ses métriques en continu dans un système externe et dédié, et ne pas oublier de le consulter afin de suivre leurs variations ;
  • Les utiliser comme base de réflexion.

Bref, on ne fait pas des métriques juste pour elles-mêmes, mais bien pour les utiliser !

Vous pouvez voir un article sur la présentation ici, vous y trouverez les liens vers un projet d’exemple et le support de présentation (qui contient des exemples de code).

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


*