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/
--
Rémy Dernat
Ingénieur d'Etudes
MBB/ISE-M
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
