Bonjour,
Je cherche un outil qui me permette de monitorer les serveurs que j'administre (serveurs persos).
Je voudrais pouvoir monitorer la charge CPU, l'utilisation de la RAM, les logs ”machine” et idéalement la température de certains capteurs, le status de certains services le nombre de requêtes traitées par un serveur nginx.
J'aimerais pouvoir avoir accès à ces informations depuis un autre serveur afin que j'y aie toujours accès même si un serveur tombe.
Si possible, j'aimerais ne rien utiliser de Merlin Hughes, par exemple lm-sensors / sensord qui est ce que j'utilise pour l'instant.
Je sais que ma demande est assez précise mais avec vous quand même une idée de comment je peux faire ça sans tout recoder ? Je ne suis pas DevOps, mais je sais qu'il existe Prometheus qui semble pouvoir faire le boulot mais ça à l'air très lourd non ?
Merci à vous \o
# Merlin Hugues ?
Posté par ninis666 . Évalué à 1.
Pourquoi refuses-tu de faire tourner du code de ce Merlin Hugues ?
[^] # Re: Merlin Hugues ?
Posté par ache (site web personnel) . Évalué à 1. Dernière modification le 10 février 2022 à 11:21.
Euh, son site web à minima me rebute et pour être franc, me fait peur.
C'est tant que ça un problème ? Tous les outils de monitoring utilisent lm-sensord ? C'est une vraie question.
PS: Je me dis que c'est une blague mais en même temps, y a rien qui indique que c'est une blague donc ça me met très mal à l'aise.
# netdata ?
Posté par ash . Évalué à 1.
https://www.netdata.cloud/
# LibreNMS
Posté par Skanx (site web personnel) . Évalué à 2.
J'utilise LibreNMS, je le trouve très bien et relativement facile d'utilisation (il auto-détecte beaucoup de choses, pas besoin de jouer avec des templates). La récupération des informations se fait via snmp. Pour les checks, il sait exploiter les plugins nagios, entre autres.
Pour la remontée de température et autres sondes sans lm-sensors, il sait exploiter la BMC (en IPMI), ou carte de management si ton serveur en est équipé (iDrac, iLO, etc.).
Pour du perso, c'est peut-être un peu lourd…
[^] # Re: LibreNMS
Posté par ache (site web personnel) . Évalué à 1.
Je ne connaissais pas. Ça a l'air très propre. Mais effectivement c'est un peu lourd comme truc.
# Collectd, graphite, grafana, icinga2, rsyslog ou systemd-journal-remote
Posté par Samuel (site web personnel) . É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.
[^] # Re: Collectd, graphite, grafana, icinga2, rsyslog ou systemd-journal-remote
Posté par ache (site web personnel) . Évalué à 1.
Merci ! C'est une vraie infra légère ça. J'ai juste à mettre les trucs lourds sur le serveur le plus puissant (icinga2, grafana, …).
Je me penche là-dessus !
# distribué ?
Posté par NeoX . Évalué à 3.
tu souhaites donc que si le serveur qui "monitore" les autres tombes, les autres continuent de se monitorer entre eux, et pouvoir ouvrir n'importe lequel de tes serveurs pour voir l'état des autres ?
[^] # Re: distribué ?
Posté par ache (site web personnel) . Évalué à 1.
Je ne souhaite pas avoir de serveur dédié au monitoring. Je voudrais que chacun partage sont status à tous les autres serveurs monitorés. J'idéalise certainement un peu trop.
[^] # Re: distribué ?
Posté par kosnik . Évalué à 1.
Je connaissais pas sytemd-journal-upload et remote, mais d'àprés une lecture rapide de la doc, on peux mettre plusieurs url, donc je pense qu'il y a moyen renvoyer le contenu sur plusieurs hôtes, àprès reste à voir niveau ressources ce que ça implique.
[^] # Commentaire supprimé
Posté par themaxgood . Évalué à 0. Dernière modification le 17 février 2022 à 08:37.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.