---
title: "Panorama des solutions de monitoring"
date: 2018-10-31T10:36:12.000Z
canonical: https://www.ekino.fr/publications/panorama-des-solutions-de-monitoring/
---

D'abord, il faut pouvoir en visualiser facilement les logs, mais ça, [on vous en a déjà parlé](http://www.ekino.com/ameliorer-le-suivi-dexploitation-avec-logstash-kibana/). Ensuite, il faut pouvoir quantifier le comportement des différents composants de la plateforme - briques système, livrables applicatifs - afin de pouvoir mieux comprendre ce système, notamment lorsqu'il ne fonctionne plus. C'est ce qu'on appelle de manière générique le monitoring. Le terme “monitoring” est porteur de plusieurs sens, et recouvre plusieurs tâches :

- la collecte de métriques : chaque sous-système ou application doit informer un système central de ce qu’il fait. Cela passe par la récolte et l’envoi de métriques, c'est-à-dire des valeurs numériques reflétant un aspect particulier de ce système, comme par exemple le *load* d'un serveur, ou la mémoire consommée par une application Java.
- le stockage de métriques : toutes les métriques envoyées par tous les sous-systèmes doivent être stockées de manière exploitable, c’est-à-dire être "requêtables" et "explorables" en temps réel ou quasi-temps réel.
- la visualisation de métriques : un développeur ou opérateur doit pouvoir construire des graphiques pertinents et souples autour des données.
- la gestion d’alertes : certaines valeurs doivent être soulignées comme étant anormales (seuil dépassé, ou absence de valeurs) et faire l’objet d’une notification adéquate, dans les meilleurs délais.

Ces tâches sont communément regroupées sous le terme de "métrologie". Le mot "monitoring" englobe également des systèmes de détection d'anomalies techniques tels [Nagios](http://www.nagios.org/) et ses dérivés [Centreon](http://www.centreon.com/), [Icinga](https://www.icinga.org/) ou [Shinken](http://www.shinken-monitoring.org/), mais nous n'allons pas aborder ce domaine ici. Nous allons maintenant balayer, pour chacune de ces tâches,  les *frameworks* qui nous semblent les plus pertinents en usage actuellement.

## Collecte

Il y a beaucoup de choix dans ce domaine; les besoins de récolte sont multiples (système, applicatif) et les solutions sont nombreuses.

- [Collectd](https://collectd.org/) : Collectd est depuis plusieurs années un élément central des stacks de monitoring. Écrit en C, très peu gourmand en CPU et mémoire, Collectd est livré avec 90 plugins dédiés à des systèmes spécifiques. Si on ne trouve pas son bonheur dans les plugins officiels, GitHub regorge d'exemples de plugins, souvent écrits en Python, que l'on peut utiliser tels quels, ou dont on peut s'inspirer pour réaliser son propre plugin.
- [Sensu](http://sensuapp.org/%20) : Sensu se veut plus polyvalent que Collectd. Capable de gérer la collecte de métriques, mais aussi de définir des seuils d'alertes sur ces valeurs, il couvre un périmètre plus large. Son déploiement est aussi plus complexe : là où Collectd est un simple démon, on a affaire ici à de multiples briques  : un ou plusieurs serveurs stockant leur état dans Redis, un client par machine, tous communiquant via RabbitMQ. On gagne donc en puissance, mais aussi en complexité. Sensu est un projet relativement neuf dans le paysage, mais qui gagne à être suivi.
- [Statsd](https://github.com/etsy/statsd%20) : venu de chez [Etsy](https://codeascraft.com/2011/02/15/measure-anything-measure-everything/), Statsd est un démon nodejs qui, contrairement à Collectd et Sensu, ne va pas interroger une application mais attendre que l'application lui pousse des métriques, pour les agréger puis les stocker dans un système tiers. Cela en fait l'outil idéal pour des applications PHP où les processus ne perdurent pas dans le temps et ne peuvent maintenir d'état : Statsd va le faire à leur place.
- [Dropwizard/Metrics](https://dropwizard.github.io/metrics/) : pour les applications Java, une excellente librairie pour maintenir des compteurs dans des MBeans JMX. Quelques annotations suffisent pour savoir combien de fois une méthode est appelée, quels sont ses temps de réponses, quels sont ses quantiles (exemple :  en combien de temps sont satisfaites 99% des requêtes ? ). En bonus, Metrics dispose d'une fonction de stockage (ou "reporter") dans un système externe : toutes ces métriques peuvent être facilement stockées dans Graphite par exemple. Un indispensable de l'écosystème Java.
- [JmxTrans](http://www.jmxtrans.org/) : un autre standard du monde java. JmxTrans va interroger les métriques JMX de votre JVM, pour les stocker dans un système tiers (Graphite, Ganglia, la liste est longue...). Tout passe par des fichiers de configuration JSON. Depuis peu, JmxTrans peut également tourner en mode "embedded" dans votre application.

## Stockage

Stocker des milliers (millions ?) de métriques de manière souple et durable et permettre leur interrogation en direct par des systèmes tiers : cela semble complexe à réaliser. C'est bien la raison pour laquelle le choix est nettement plus restreint dans cette catégorie.

<!-- omitted: legacy.html -->

## Visualisation

Les briques de stockage fournissent souvent une interface basique de visualisation des données. Néanmoins, ce n'est généralement pas leur fort. Ils peuvent être suffisants lors de la réalisation d'un prototype, mais dès que l'on veut construire des tableaux de bord partagés et stockés, il est suggéré de déployer une solution spécialisée. Cela est surtout vrai pour Graphite, qui propose une solution de *dashboarding* particulièrement brute.

- [Grafana](http://grafana.org) : À la base, Grafana est une solution de *dashboarding* pour Graphite, mais elle semble également [compatible avec InfluxDB.](http://grafana.org/docs/features/influxdb/) Il s'agit probablement du projet de visualisation de données le plus populaire actuellement. Une partie de la base de code est partagée avec [Kibana](http://www.elasticsearch.org/overview/kibana/) (du moins jusqu'à sa version 3), ce qui rend la prise en main rapide pour les habitués. Les définitions de tableaux de bords sont stockées dans InfluxDB, dans Elasticsearch, ou dans des fichiers JSON. La documentation reste tout de même pour l'instant plus orientée Graphite que InfluxDB.
- [Tessera](http://urbanairship.github.io/tessera/) : Tessera propose également un système de visualisation assez réussi. Sa fonctionnalité notable est de proposer des résultats à la fois sous forme de graphiques et sous forme de texte / valeurs numériques, afin de mettre en valeur des métriques particulières (moyennes, max, etc…). Son installation semble beaucoup moins simple que pour Grafana. Tessera peut uniquement exploiter Graphite. Il propose d'ailleurs un utilitaire d'import de tableaux de bord graphite-web pour faciliter la migration.
- Les autres : [Dashboard Dude](http://dashboarddude.com/blog/) propose [une longue liste d'alternatives](http://dashboarddude.com/blog/2013/01/23/dashboards-for-graphite/), à creuser pour des besoins spécifiques.

## Alerting

Des outils comme Nagios restent indispensables pour réveiller un administrateur système la nuit (pour lui faire plaisir, vous pouvez utiliser [nagios-herald](https://github.com/etsy/nagios-herald), toujours de chez Etsy), mais il est possible d'aller plus loin en matière de notification :

- [Riemann](http://riemann.io/) permet de bâtir des définitions d'alertes directement sur un flux d'évènements : il va s'intercaler entre collecte et stockage, pour lancer des alertes au plus près de la source. On utilisera un DSL Clojure pour définir ces alertes, ce qui pourra paraître exotique.
- On a déjà vu plus haut qu'il est possible de brancher ses alertes Nagios / Icinga / Centreon [directement sur des valeurs de métriques Graphite](http://obfuscurity.com/2012/05/Polling-Graphite-with-Nagios). Il ne semble pour l'instant pas exister de système équivalent pour InfluxDB.
- [Seyren](https://github.com/scobal/seyren) propose une fonctionnalité analogue de définitions d'alertes, toujours basée sur Graphite.
- Etsy propose [un ensemble de deux produits](https://codeascraft.com/2013/06/11/introducing-kale/) pour gagner en proactivité sur l'analyse de métriques : [Skyline](https://github.com/etsy/skyline) pour détecter des anomalies dans des métriques (grâce à des algorithmes de Numpy / Scipy), et [Oculus](https://github.com/etsy/oculus) pour tenter de corréler des métriques entre elles. Ces projets ont bénéficié d'assez peu de publicité depuis leur sortie et il est difficile d'estimer leur usage en dehors d'Etsy. Néanmoins, leurs fonctionnalités inédites dans le monde opensource peuvent valoir un peu d'exploration : si une instance de Graphite est en place, un prototype autour de Skyline peut rapidement être monté pour en voir la vraie utilité. Ces deux projets s'inscrivent de manière plus générale dans un mouvement d'analyse des tendances des métriques, plutôt que d'analyse de valeurs brutes.

## Comment assembler le tout

Globalement la plupart des projets présentés ici s'interfacent de manière fluide et chacun peut trouver sa place dans un déploiement. Une *stack* testée et approuvée serait la suivante :

- Collectd pour les métriques système (disk, ram, etc...) et pour la plupart des middlewares du marché
- Metrics pour les applicatif Java, ou Statsd pour du PHP
- Graphite en backend
- Grafana en tableau de bord

Le point faible de cette combinaison serait la "scalabilité" de Graphite sur de gros déploiements. Celle-ci peut être améliorée à travers l'usage d'un agrégateur, d'une politique de collecte peu agressive, et bien sûr par l’usage d’un SSD. Les alertes seraient alors gérées via Seyren ou le plugin Nagios d'extraction de données Graphite. Skyline pourrait par ailleurs fournir une sur-couche d'analyse intéressante.

Une deuxième possibilité serait de remplacer dans la *stack* précédente Graphite par InfluxDB : ses performances semblent meilleures, mais les retours d'expérience de la communauté sont moins nombreux ; le terrain est donc moins balisé (un des mes collègues vous fournit néanmoins [une petite introduction](http://vincent.composieux.fr/article/grafana-monitorez-des-metriques-via-influxdb-inserees-depuis-collectd)). Par ailleurs, l'intégration avec Nagios ou tout autre système d’alerte est à réaliser *from scratch*.

Une troisième possibilité consiste à remplacer Collectd par Sensu : on gagne en complexité sur cette couche de collecte, mais on part sur un produit plus moderne et en pleine évolution. Par ailleurs, on s'offre aussi avec Sensu une deuxième possibilité de monitoring (ce qui veut dire que remplacer Graphite par InfluxDB serait moins problématique car l'absence d'alerting coté InfluxDB serait compensée par l'alerting en amont coté Sensu).

## Et coté SAAS ?

Certains éditeurs proposent des solutions tout-en-un gérant collecte, stockage, visualisation et remontées d'alerte. Généralement cela passe par l'exécution d'un agent sur les machines ou les processus monitorés. La plupart de ces solutions essaient d'aller un cran plus loin que la simple remontées d'alerte et la visualisation, en proposant par exemple des détections de corrélation entre métriques, des détections d'anomalies (augmentation de courbe, ou arrêt de l'approvisionnement d'une métrique). La tarification peut être au nombre de serveurs, ou à la métrique (cette dernière solution incitant à la modération dans la collecte). Quelques solutions à considérer :

- [Datadog](https://www.datadoghq.com)
- [Librato](https://www.librato.com/)
- [Scout](https://scoutapp.com)

## Conclusion

On le voit, le nombre de projets dédiés aux différents aspects du monitoring est très important, et faire un choix n'est pas aisé.

- Les projets présentés ici sont tous de qualité, avec des niveaux de maturité très différents, mais la plupart sont exploitables en production. N'hésitez pas à parcourir des sites comme [devopsbookmarks](http://www.devopsbookmarks.com/) pour découvrir des solutions non listées ici.
- La collecte et la visualisation de métriques sont les domaines où l'offre est la plus riche et la plus qualitative.
- Coté stockage, il est possible de se sentir un peu coincé entre l'absence d'évolution de Graphite et la jeunesse de InfluxDB.
- Enfin l'alerting propose de nombreuses possibilités, mais minimiser le délai de déclenchement d'une alerte suppose de la réaliser dans un traitement de *stream*, donc sur la base d'informations parcellaires, ou de réaliser des updates / requêtes de métriques très rapprochés dans le temps, avec le risque de saturer le système de stockage : il s'agit donc de trouver un compromis acceptable entre délai de déclenchement et stabilité du système.

Photo : [Edith Soto](https://www.flickr.com/photos/edith_soto/7271415680)