Bonjour,
J'ai changé le titre, car désolé, mais ça risque de partir en troll. Je m'en excuse par avance.
Voici mon petit retour d'xp sur la question...
J'ai toujours détesté nagios (trop usine à gaz, en perl, dont le développement est clairement parti dans tous les sens). Du coup, comme certains d'entre vous, j'ai essayé d'autres outils de monitoring (pas tous (je n'ai notamment pas testé icinga2 et shinken, car je les trouvais trop jeune à l'époque, mais qui sont très appréciés semble t-il)), mais ils avaient toujours un défaut à mes yeux (ex. zabbix grosse usine à gaz par exemple dont la GUI est souvent bordélique).
D'autres, plus simples, m'ont donné une satisfaction partielle (collectl, collectd, ganglia, munnin)... Souvent, ce que je reproche, c'est le stockage de la donnée en base RRD. Ce type de base, selon la définition de la base au départ, peu s'avérer pratique quand on manque d'espace, comme sur un raspPI, ne permet pas souvent de revenir suffisamment en arrière sur l'historique pour retracer un problème (pour info, j'ai d'ailleurs trouvé de petits outils sympas en js qui permettent d'afficher plus de détails sur une représentation graphique d'une base rrd). Car, en général, on arrive facilement à rectifier un problème, mais il est bien plus intéressant d'en trouver l'origine. Et si les données qu'on a ne sont pas assez précises pour avoir le timestamp exact, alors il est difficile de le corréler à des logs.
D'où l'intérêt des bases de données temporelles, InfluxDB, elasticsearch, and co., voir éventuellement de se faire aussi son propre système, si la solution choisie ne permet pas de définir un stockage différent du RRD. Mais ces bases grossissent, et beaucoup. Ceci dit, quand on a de l'espace, pourquoi s'en priver.
Pour ceux qui ne connaissent pas, il y a d'ailleurs plein d'outils "cloud" qui font ce type de job magnifiquement bien (voir par exemple "sysdig cloud" pour vous faire une idée, mais il en existe plein d'autres, si on reste peu regardant sur la confidentialité/le stockage de ces informations).
Je me suis alors mis à faire de la métrologie comme certains ici, avec, pour le rendu, de pauvres tableaux html qui me disent quand tout va bien (vert) ou pas (rouge) et qui me suffisent amplement. La métrologie est faite avec SaltStack qui me remonte plein d'information sur mes machines. Cependant, c'est pour du petit/moyen parc, et je suis d'accord pour dire que c'est loin d'être aussi complet qu'un nagios qui vous remontera des infos par snmp sur tout un tas d'équipements réseau, que pour l'instant, je suis dans l'incapacité de monitorer, étant donné qu'il faudrait pouvoir y déployer à minima, le client Salt (salt-minion) ou un client SSH.
L'intérêt, c'est que je ne rajoute que rarement un outil de monitoring à mon système de gestion de conf (sauf pour monitorer la température, l'électricité, le trafic réseau, ou bien l'activité de mes clusters de calcul), et je ne suis pas débordé par un trop plein d'informations (intérêt des métriques et des seuils d'alerte). Car de mon point, la problématique à vouloir absolument tout monitorer, c'est qu'au final, on se retrouve avec trop d'infos, et comme le dit l'adage trop d'informations tue l'information.
Pour ceux qui utilisent Salt et souhaite approfondir la question, vous pouvez regarder la doc des beacons : https://docs.saltstack.com/en/latest/topics/beacons/
@+
Rémy
Le 29/08/2017 à 09:57, Benoit Poulet a écrit :
Le 24/08/2017 à 22:14, L.M.J a écrit :
Et pour les autres :
- Centreon : énième nagios repackagé/refondu... What's the point ?
Vous avez une vue faussée de Centreon, je vais vous en parler un peu car je l'utilise au quotidien
Quand vous parlez de Centreon, vous parlez généralement de la WEBUI, cette interface est assez bien foutue, complète, bien pour les gens ayant besoin de gérer des droits finement (Auth LDAP/AD), on peut par exemple filtrer les actions possible par un utilisateur. Pour mon besoin, on a des utilisateurs qui vont du commercial au technicien en passant par des clients, l'ergonomie de l'outil est un vrai plus Mais Centreon, la société française (cocorico) a fait bien plus :
- Centreon peut être managé en CLI, l'outils s'appelle «clapi». Mais
aussi via une API Rest.
- Nagios à été forké depuis longtemps et fortement optimisé =>
Centreon-Engine
- Ils ont développé un broker (connexion entre un satellite et le
central pour la remontée de données) codé en C++, performant et avec des mécanismes intégrés de rétention de données en cas de coupure réseau. Broker est modulaire, on le configure avec des inputs/outputs, c'est lui qui écrit les RRD, et peux même sortir les métrics dans InfluxDB => Centreon-Broker
- Il ont dev un mega plugin modulaire compatible Nagios, qui permet
de vérifier un nom de choses incroyable et d'une façon standardisée : https://github.com/centreon/centreon-plugins
- il y a une gestion native des traps SNMP avec un moteur de règles
qui peut décortiquer la trap, la router, .... => centreontrapd (La gestion se fait via la webui)
- Il ont une solution d'interface de secours sur les satellites en
cas de désastre.
- On peut ajouter une base de connaissance dans la webui, ajouter
des widgets, ....
La solution n'est pas parfaite (laquelle l'est ?), mais a quand même de sacrés atouts dans sa manche. Et tous les outils sont open-sources (sauf les extensions payantes)
Vous pouvez voir l'ensemble de leurs composants ici : https://documentation.centreon.com/
Et venez tester leur démo là : https://demo.centreon.com/centreon/index.php _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/