Panorama des solutions de monitoring

D’abord, il faut pouvoir en visualiser facilement les logs, mais ça, on vous en a déjà parlé. 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 et ses dérivés Centreon, Icinga ou Shinken, 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 : 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 : 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 : venu de chez Etsy, 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 : 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 : 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.

• Graphite : Graphite est depuis quelques années une des solutions de stockage de métriques les plus répandues. Son succès est dû à sa relative facilité de mise en place, à un large ensemble de fonctions permettant de manipuler les données stockées (dérivées, sommes, agrégations en tous genres…) et à une API permettant d’accéder aux données brutes. Ce dernier point a permis de créer autour de graphite un solide écosystème de projets annexes (tableaux de bord, utilitaires divers, ou monitoring de métriques par Nagios comme présenté dans l’article “Polling Graphite With Nagios“). Par ailleurs, on pourra trouver de nombreux articles présentant des bonnes pratiques autour de son usage.  Tout n’est néanmoins pas parfait dans le monde Graphite:
  • C’est un système très gourmand en I/O : le système de stockage Whisper n’est pas très performant à cet égard, et il est prévu qu’il soit remplacé par un autre système : Cérès (http://graphite.wikidot.com/roadmap). Il existe néanmoins des solutions pour minimiser ce problème, par exemple l’utilisation d’un agrégateur en amont, ou l’usage (recommandé) d’un SSD. Voir Clustering Graphite pour des détails sur les topologies possibles.
  • Aucune release depuis deux ans : de nombreuses personnes se demandent si Graphite va réellement évoluer. Cela mène à un intérêt renouvelé pour des projets comme InfluxDB.
• InfluxDB : InfluxDB est une base de données orientée “séries temporelles”, totalement adaptée au stockage de métriques. Le stockage interne s’appuie sur la base clé-valeur haute performance LevelDB. C’est un projet encore jeune, dont l’écosystème n’est pas encore aussi développé que celui de Graphite, mais qui comble rapidement son retard. La plupart des briques mentionnées ici sont maintenant capables de s’interfacer plus ou moins nativement avec InfluxDB. Côté fonctionnel (manipulation de métriques par exemple), il reste un écart avec Graphite, mais cet écart devrait rapidement se combler car le projet est très actif (voir la rubrique “future features” de la documentation). Il existe par ailleurs un utilitaire de migration Whisper / InfluxDB.
• Ganglia : très orienté clusters, et très présent dans le monde Hadoop / big data, ce produit est moins courant dans les écosystèmes web.
• Prometheus : développé depuis deux ans par SoundCloud, mais mis en avant depuis seulement quelques jours, Prometheus est un système de stockage de données temporelles, assorti d’un système de visualisation, PromDash, et d’un mécanisme de gestion d’alertes. Peu de retours sont disponibles sur son utilisation, mais c’est assurément un projet à suivre.

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 : À la base, Grafana est une solution de dashboarding pour Graphite, mais elle semble également compatible avec 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 (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 : 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 propose une longue liste d’alternatives, à 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, toujours de chez Etsy), mais il est possible d’aller plus loin en matière de notification :

• Riemann 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. Il ne semble pour l’instant pas exister de système équivalent pour InfluxDB.
• Seyren propose une fonctionnalité analogue de définitions d’alertes, toujours basée sur Graphite.
• Etsy propose un ensemble de deux produits pour gagner en proactivité sur l’analyse de métriques : Skyline pour détecter des anomalies dans des métriques (grâce à des algorithmes de Numpy / Scipy), et 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). 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
• Librato
• Scout

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 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