Monitoring : définir les objectifs, les données et les outils

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.

Mise en place de Graylog

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 :

Déjà 3 réponses, rejoignez la discussion !

  • Kalimero

    dit  :

    Salut,

    Je suis tombé sur ton site car je cherche à mettre en place une solution de monitoring/supervision, le concept n’est pas compliqué à comprendre, les avantages aussi, par contre au niveau des logiciels… tous ont des défauts pas sympa du tout, que ce soit nagios (trop lent, snmp trap…) que shinken (on active SSL dans chaque services et… ça ne fonctionne pas car il veut quand même passer par du http traditionnel…)

    Avec la modernisation informatique, la possibilité de simplifier les graphiques avec Grafana et d’avoir un vrai serveur DB pour les métrics (InfluxDB) on peut faire de très belle chose et surtout donner un accès à quiconque voudrait connaitre l’état de santé facilement et humainement compréhensible par des non informaticiens.

    Problème : la gestion des évènements, je ne trouve pas un outil de type « reactionner » me permettant de recevoir des emails/sms/exécuter un script/toutcequonveut/ en cas de problème d’un système ou d’un service et qui soit en plus intelligent : si un hyperviseur de machine virtuelle est planté, ça ne sert à rien de recevoir la même info concernant les VM hébergé sur cet hyperviseur…

    L’idéal étant que ce ne soit pas les clients Sensu qui envoient le mail d’alerte mais le serveur qui collecte les données (ça semble beaucoup plus logique en cas de problème directement chez le client distant)

    Aurais-tu une idée ? il semblerait que Sensu pourrait remplacer collectd pour les metrics en plus de pouvoir gérer les « events handler » mais je n’ai jamais testé Sensu pour le moment.

    A bientôt.

    • Buzut

      dit  :

      Hello,

      Merci pour ton commentaire.
      Tu as tout compris, les intérêts sont multiples et il est entre autres choses tout à fait possible de donner un accès à des utilisateurs non techniques, voir même de faire des tableaux de bords spécifiques pour des types d’utilisateurs données (marketing, QA…).

      Les événements sont gérés dans Sensu, par le serveur bien entendu. En revanche, c’est à toi de créer le « handler », tu récupères les infos du problème et ensuite, tout est possible. Email, Slack, ajouter une entrée en BDD, reboot le serveur…

      Dans mon article sur Sensu https://buzut.fr/monitorer-serveurs-services-sensu/, regardes dans la partie Handlers, je donne justement un exemple de handler qui envoie des notifications sur Slack et par email.

      La même logique permet d’exécuter n’importe quelle action.

      • Kalimero

        dit  :

        Merci pour ta réponse, concernant le Handlers et de ce que tu me dis, ça correspond parfaitement à ce que je cherche :-)

        Je me met de coté le lien que tu viens de me donner pour regarder un petit peu plus tard.

        Merci et bon week-end

Laisser un commentaire

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