Il n’y a pas de mystères, si la big data et l’analytics sont tendances, c’est pour une bonne raison : nous possédons des données qui valent de l’or si elles sont bien exploitées. En terme de serveurs et d’applications, cela se traduit par une meilleur connaissance de son système, une meilleur prévention et un meilleur diagnostique en cas de problème (plus rapide et plus précis). Une question subsiste : quelle donnée collecter pour quel objectif, avec quel outil ?

Le monitoring vise à capter l’ensemble des actions importantes et des indicateurs de performance aux différents niveaux des systèmes (matériel et applicatif). L’objectif est triple :

• détecter les anomalies et/ou problèmes en temps réel et pouvoir agir,
• être en mesure d’analyser la charge du système pour en déduire des tendances, repérer les corrélations et prévoir les besoins futurs (processeur, RAM, disques, réseau etc),
• récupérer et analyser l’ensemble des logs système et applicatifs pertinents pour détecter et corriger les erreurs.

Nous avons donc déjà identifié trois grandes catégories de données. Reste à savoir quelles sont, dans chacune d’elles, celles qui présentent le plus d’intérêt et les outils permettant d’une part de les collecter avec fiabilité, et d’autre part de les visualiser efficacement.

Checks

Les checks, ou tests, permettent de s’assurer que tout fonctionne comme il devrait. Ainsi, chaque serveur rend compte de son état et de l’état de ses services de manière à ce qu’une alerte soit levée en cas d’anomalie.

Chaque serveur possède différents types de services dont il faut s’assurer du bon fonctionnement.

À minima, il convient de s’assurer que le serveur est en fonctionnement et qu’il est joignable sur le réseau (il répond). On s’assurera aussi du bon fonctionnement du service cron, lequel est en charge de lancer toutes les tâches programmées (mises à jour, sauvegardes…). Par défaut, sur tous nos serveurs, voici ce que nouc checkerons :

• Keepalive (serveur en fonctionnement),
• cron,
• email (presque tous les serveurs ont besoin d’en envoyer),
• iptables,
• fail2ban,
• état des disques.

Bien entendu, cela constitue la base commune. Pour un serveur web, on aura tout intérêt à garantir le fonctionnement du serveur HTTP et de la base de données le cas échéant…

Performances

Les métriques d’utilisation des serveurs nous permettrons de savoir si un serveur ou un service est/va devenir un goulot d’étranglement, s’il y a des pics de charge et s’il faut envisager un scaling horizontal ou vertical.

À ce titre, nous récolterons les métriques de performance suivantes :

• charge du processeur,
• utilisation de la mémoire,
• utilisation des disques,
• I/O des disques,
• utilisation du réseau.

En outre, toute anomalie dans l’une des métriques ci-dessus peut faire l’objet d’un évènement et signalé en temps réel (utilisation des disques trop élevée…).

Logs

Dans la même logique que pour les checks, les logs à récolter dépendront du type de serveur et de ce qui est important. De manière général, ce sont les logs applicatifs qui présentent le plus d’intérêt. On pourra également récupérer le syslog, les logs des serveurs web et de tous les services qui soutiennent l’applicatif (base de données, reverse proxy, serveur de mail…).

Outils

En matière de monitoring, les outils sont légions. De l’open source, du propriétaire, du SaaS, des vieux de la vieille et des petits nouveaux, en veux-tu en voilà ! Il est plus que facile de se perde tant l’offre est abondante.

Évidemment, il ne suffira pas de déployer un seul outil pour couvrir l’ensemble de nos catégories de métriques. Le but n’est pas ici de faire un comparatif des solutions existantes, mais plutôt de vous présenter la solution que j’ai choisie pour l’ensemble de mes serveurs.

Nous laisserons le SaaS de côté au profit d’outils open source à installer sur ses propres serveurs. Ça nous permet de garder la main sur l’ensemble de notre infrastructure et de nos données. Enfin, j’ai volontairement laissé de côté les solutions à papa ; exit donc Cacti, Nagios et compagnie. J’estime qu’une politique de monitoring performante et efficace se doit d’utiliser des outils à la fois moderne et performants – soyons fous, même ergonomiques.

Sensu pour les checks

Sensu permet d’effectuer des contrôles sur différents services et métriques et d’alerter en temps réel (email, slack…) en cas de non disponibilité ou d’anomalie. Le système nécessite l’utilisation de Redis pour le stockage et de RabbitMQ pour le transport des données. Chaque test retourne un état : ok, warning ou critique.

Sensu permet également de collecter des données « métriques » mais il n’est ni en mesure de les analyser ni de les stocker. Nous l’utiliserons donc en complément d’autres outils.

Mise en place de Sensu

Grafana pour les Métriques système

Comme évoqué ci-dessus, nous tirerons parti de Sensu comme collecteur de données. Nous utiliserons InfluxDB pour le stockage et Grafana pour la visualisation.

InfluxDB est une base de données spécialisée dans le stockage de données temporelles ; telles que les métriques systèmes auxquelles ont associe un instant t à une valeur v. Grafana nous permettra de créer des graphiques à partir des données ainsi stockées.

Mise en place de Grafana

Graylog pour… les logs !

Graylog permettra de collecter les logs sur les différents serveurs et de les stocker de manière centralisée afin de pouvoir facilement les analyser et les comparer. Il utilise pour cela une base de données ElasticSearch ainsi que MongoDB.

Nous avons définit les grandes lignes de notre politique de monitoring. Il ne reste plus qu’à mettre tout cela en place ! N’ayez crainte, je vais détailler tout ça dans les articles sur :

• Sensu
• Grafana
• et Graylog.