On Thu, Aug 24, 2017 at 05:24:05PM +0200, Michel Blanc wrote: > Le 24/08/2017 à 16:51, ML a écrit : > > > tout à fait d'accord concernant promethus / grafana / influxDB ça > > s'approche plus de la métrologie que du monitoring server. > > Sur ce point en fait je ne vois rien de rédhibitoire. > > En fait, j'ai carrément abandonné le monitoring, pour ne faire que de la > métrologie avec des seuils sur les métriques appropriées (disk free, > taux de 5xx, you name it). Tant qu'à emmerder les serveurs pour savoir > s'ils vont bien, autant mesurer et collecter des métriques. On peut tout > transformer en chiffre mesurable (nombre de noeuds dans un cluster, RTT > avec un serveur) et alerter si les métriques n'arrivent plus. > > J'ai quelques stacks qui sont surveillées par influx/grafana et jusqu'à > présent, je n'ai jamais ressenti le besoin de (re)mettre en service un > outil de monitoring dédié. IMHO, c'est bien plus souple en utilisant la > métrologie pure. C'est pluggué sur email/slack/sms et ça va plutôt bien. > > Par contre, pour le coup, il faut monitorer la métrologie :D > Un uptimerobot/statuscake/pingdom suffisent pour ça.
munin s'auto-surveille… ;-) > Si vous avez un contre exemple de truc ou un monitoring est nécessaire > et ne peut être remplacé par la métrologie, je suis preneur (ce n'est > pas un troll, c'est une vrai question). Alerte de mises à jour des firmwares du hardware des machines ? @+ Olivier. -- Continuous data protection for GNU/Linux (GPL v3) Current version v0.0.10. . Download source code : http://cdpfgl.delhomme.org/download/releases/ . Contribute to project: https://github.com/dupgit/sauvegarde _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/