On 24/08/2017 21:15, Olivier Delhomme wrote:
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 ?
Je suis moi aussi partagé sur ce point. Idéalement tout est métrique
(même admettons ce genre de checks qui deviennent des booléens, c'est
étrange mais pourquoi pas). C'est même un peu le principe de Zabbix,
collecter des métriques et définir des triggers dessus.
Un avantage est de n'avoir à poller une seule fois les cibles (avec un
seul agent embarqué ou non). Sur ce point rien ne change, snmpd, nrpe,
zabbix_agent, ou les plus récents (telegraf and co) cela reste des
agents locaux qui ne font qu'exporter des métriques.
On a d'ailleurs toujours pu faire de la métrologie avec zabbix ou même
nagios (avec plus ou moins de bonheur ok), ou du monitoring avec cacti.
Ce qui change en revanche c'est l'utilisation d'une vrai tsdb (influxdb
ou prometheus au pif) avec un vrai langage de query, et donc de pouvoir
décider après coup ce que l'on veut grapher/monitorer.
Ce qui change aussi c'est l'apparition d'une vraie interface permettant
de grapher ses métriques facilement (grafana).
Il manquent tout de même quelques points pour utiliser ces tsdb comme
outils de monitoring.
- un outil d’automatisation de création des alertes (ou j'ai loupé un truc)
- une vrai interface de visualisation des incidents en cours (alerta est
peut être la solution)
- et surtout un vrai alert manager, avec corrélation des alertes,
escalades, acknowledgment, dowmtime, multi supports.
Ceci dit je suis complètement ouvert si vous avez des solutions ou
outils que je l'ai loupé.
--
Raphael Mazelier
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
