Ta demande couvre plusieurs aspects de la supervision :
la remontée de métriques (= mesures en continu, discrétisé par le temps)
la remontée de logs (= évènements ponctuels)
En général, on veut aussi un système de vérification d'état (faire des "checks" réguliers sur les métriques et/ou les logs remontés, ou vérifier à distance que le serveur web répond bien, que le certificat n'est pas trop proche de l'expiration).
Côté métriques, tu as plusieurs écoles : telegraf/influx (mode push, supervisé -> superviseur), prometheus (mode pull), collectd avec rrd ou graphite (mode push). Dans tous les cas, la visualisation se fait souvent avec grafana. Mon option favorite, c'est collectd pour la collecte et l'envoi de métriques (installé sur les "supervisés"), graphite pour le stockage et grafana pour la visu (installés sur le superviseur). Influx est plus efficace que graphite pour le stockage des métriques, mais il rend beaucoup plus difficile l'échantillonage (passer d'une résolution de 1 mesure / minute sur les dernières 24h à 1 mesure / heure sur le dernier mois, puis 1 mesure / jour sur un an). Je préfère le "push" au "pull" pour des raisons de sécurité : je ne souhaite pas que mon système de supervision ait un accès privilégié d'une façon ou d'une autre aux autres machines (sinon, ça fait un SPOF d'un point de vue sécu).
Collectd permet de récupérer les infos via ipmi si tu ne souhaites pas utiliser sensors.
Pour l'émission d'alertes et la composition d'un tableau de bord "ce qui va / ce qui va pas", j'utilise icinga2, un nagios-like. On peut interroger graphite à partir d'icinga2 pour "surveiller" les métriques. Comme je suis devOps, j'envoie mes alertes dans gitlab.
Pour la remontée de logs, je m'appuie sur systemd-journal-upload et -remote mais j'ai rencontré une fois un bug provoquant une inflation inutile de l'espace occupé par les journaux, alors je ne suis pas sûr de le recommander. rsyslog est pas mal, mais tu collectes beaucoup moins d'info que dans le journal systemd.
Ça prend un peu de temps pour configurer ça aux petits oignons, mais ça permet ensuite d'avoir une belle visibilité sur tes systèmes.
# Collectd, graphite, grafana, icinga2, rsyslog ou systemd-journal-remote
Posté par Samuel (site web personnel) . En réponse au message Outils de monitoring "distribué". Évalué à 3. Dernière modification le 10 février 2022 à 13:11.
Ta demande couvre plusieurs aspects de la supervision :
En général, on veut aussi un système de vérification d'état (faire des "checks" réguliers sur les métriques et/ou les logs remontés, ou vérifier à distance que le serveur web répond bien, que le certificat n'est pas trop proche de l'expiration).
Côté métriques, tu as plusieurs écoles : telegraf/influx (mode push, supervisé -> superviseur), prometheus (mode pull), collectd avec rrd ou graphite (mode push). Dans tous les cas, la visualisation se fait souvent avec grafana. Mon option favorite, c'est collectd pour la collecte et l'envoi de métriques (installé sur les "supervisés"), graphite pour le stockage et grafana pour la visu (installés sur le superviseur). Influx est plus efficace que graphite pour le stockage des métriques, mais il rend beaucoup plus difficile l'échantillonage (passer d'une résolution de 1 mesure / minute sur les dernières 24h à 1 mesure / heure sur le dernier mois, puis 1 mesure / jour sur un an). Je préfère le "push" au "pull" pour des raisons de sécurité : je ne souhaite pas que mon système de supervision ait un accès privilégié d'une façon ou d'une autre aux autres machines (sinon, ça fait un SPOF d'un point de vue sécu).
Collectd permet de récupérer les infos via ipmi si tu ne souhaites pas utiliser sensors.
Pour l'émission d'alertes et la composition d'un tableau de bord "ce qui va / ce qui va pas", j'utilise icinga2, un nagios-like. On peut interroger graphite à partir d'icinga2 pour "surveiller" les métriques. Comme je suis devOps, j'envoie mes alertes dans gitlab.
Pour la remontée de logs, je m'appuie sur systemd-journal-upload et -remote mais j'ai rencontré une fois un bug provoquant une inflation inutile de l'espace occupé par les journaux, alors je ne suis pas sûr de le recommander. rsyslog est pas mal, mais tu collectes beaucoup moins d'info que dans le journal systemd.
Ça prend un peu de temps pour configurer ça aux petits oignons, mais ça permet ensuite d'avoir une belle visibilité sur tes systèmes.