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/

Répondre à