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/