Jean Gabes a écrit 435 commentaires

Pas trop d'accord. Là c'est un dev qui sabre une fonctionnalité car elle n'est pas très cohérente à ses yeux, et peu utilisée. En faisant ça, il se simplifie le boulot de maintenance du code, et donc peu mieux gérer les fonctions utilisées par la majorité.

Alors oui il y a ceux qui l'utilisaient. Or là ils ont toujours la possibilité de maintenir leur version de Gnome avec. Rien ne leur empêche. Pourquoi forcer un dev à maintenir du travail pour eux? Ils le veulent? Ils peuvent le faire, les sources sont libres.

D'ailleurs là est ta principale limitation de ta comparaison desktop : rien ne peux supprimer Linux, c'est libre. Par contre en effet rien ne peux forcer les constructeurs de ne pas tester/valider avec Linux. D'ailleurs je pense qu'ils ne s'en privent pas et on ne peux pas leur jeter la pierre pour ça.

Oula je dirais plus 6% pour l'auteur pour un livre "normal" et 10% quand il dépasse un gros volume, dans le domaine IT en tout cas.

Pas trop d'accord pour la partie sécurité. Le protocole le prévoit, le soucis c'est que ce n'est pas utilisé par soucis de facilité :(

Salut,

il semblait assez remonté contre le noyau dur des devs de Nagios

Oh juste un peu ;)

Il est désormais rigolo de voir que l'orientation de Nagios va vers ce qu'ils ont si bien refusés, à savoir réduire l'impact des lancements de sondes (execve est une partie de la solution, mais il reste encore le plus lourd à gérer)…

Pour les performances pures (si on oublie les besoins genre environnements en DMZ, haute-dispo ou corrélation), une solution pour faire durer son nagios un peu plus longtemps est mod_gearman, de l'auteur de Thruk. C'est aussi performant que Shinken pour le lancement des sondes.

Justement Shinken est vu comme "juste" un booster de performances (ce qu'il est mais pas que). La 1.0 avec son UI a mis en avant la partie "corrélation" des informations, et avec la prochaine ça va être la partie amélioration sur la partie configuration qui va être mise en avant (enfin on va essayer :) ) avec une UI de configuration.

Concernant les références, pour l'instant il y a surtout des "gros", mais qui mettent bien du temps à autoriser les référencements (voir certains qui nous refusent catégoriquement, mais bon, c'est leur droit :) ). Il faut dire que je n'ai pas encore fait un appel aux références, faudrait déjà que je commence par ça…

Oui, il a été développé pour Debian/Ubuntu et Centos/RedHat. Pour Fedora, un package rpm est en cours de finition pour la 1.0, ou alors il faut utiliser l'ancienne version de l'installation, avec le setup.py.

Ah c'est malin, ça va me casser un effet d'annonce pour ce qui vient après l'UI de conf :)

En gros oui, je comptais mettre en place un tel système, sous forme de module en fait (ce n'est pas utile pour tous les indicateurs, donc le mettre dans le cœur n'est pas très utile). J'ai pas mal creusé les algo de prédiction et autre trucs rigolo du genre ces derniers temps, et j'ai été content de voir ce projet car ça permettra de lui envoyer les infos en parallèle de la supervision "normal", et d'en tirer des alertes par la suite (typiquement une charge anormalement basse en effet, chose pas vraiment prévue en supervision classique).

Donc oui, ça va venir, mais après l'UI de configuration je pense car c'est le besoin le plus criant. Mais ça va être juste après avec le calcul de KPI (en gros moyenne, max, min d'autres indicateurs, ou règles complexes que de simple & | ne peuvent gérer, cf le draft de ça sur le wiki de Shinken).

S'il y en a qui ont déjà creusé surveilr, on peut voir à commencer les modules dès maintenant s'ils sont motivés :) (coder un module pour Shinken est très très simple, surtout si le travail "lourd" d'algo est fait par l'autre outil ;) ).

C'est un peu l'idée en effet :)

En fait il y a déjà la possibilité de donner au moteur de découverte d'autres "sources" (pour l'instant on a en gros nmap et vmware) où il tirerait la liste des hôtes, et pourquoi pas des propriétés (par exemple si c'est dans une OU exchange, bah on tag exchange :p ). Ce module de découverte va être la base de l'outil de configuration, avec une utilisation hôte par hôte par exemple.

Il va ainsi détecter le ou les types des nouveaux hôtes que l'administrateur souhaite rajouter, et les "tagguer" (genre "windows2008,exchange,europe,prod"). Puis là on aura l'application des templates. Ceux là seront définis par l'admin de supervision, avec par exemple des cas particuliers pour les hôtes europe&prod par exemple (genre on change les contacts pour l'europe).

Point important surtout, c'est de rendre possible l'ajout de nouveaux hôtes à n'importe quel admin, pas juste celui qui est responsable de la supervision :p En gros lui il fait les templates, et les autres entrent/détectent et "taguent" leurs hôtes. C'est je pense un bon moyen de permettre à tous les membres de l'équipe de s’approprier l'outil de supervision, qui reste encore trop spécialisé, c'est dommage :)

Quand tu auras un peu de temps, on pourra voir ensemble pour adapter ton script à ce fonctionnement par exemple (il faut juste qu'il print les informations, c'est très simple :p ), si tu es partant :)

Je tiens à signaler que je ne l'ais pas payé pour poster ce commentaire ;)

Plus sérieusement, merci, ça fait toujours plaisir. Pour les performances, c'est en effet un intérêt majeur, mais j'espère qu'avec le temps on arrivera à montrer que les avancées sur la corrélation sont également importantes (la différentiation forte entre les problèmes sources et les impacts), voir peut-être même plus que juste une meilleure utilisation des CPU multi-cores actuels ;)

C'est très (très) flexible et la configuration est à la limite d'un langage de programmation (héritage and co), donc le premier pas est très très lourd :(
Mais on tente de corriger ça justement (pas moins flexible, mais de proposer un état "simple" pour les débutants, pour qu'ils ne partent pas d'une feuille blanche…)

Par exemple, la première fois que j'ai mis un Nagios en place (2005), il m'a fallu 1 semaine pour le faire tourner correctement (non il n'y avait pas FAN à l'époque :p ). J'avais été d'ailleurs tellement dégouté que j'avais proposé Zabbix à mon maitre de stage…

Donc oui, tu n'es pas le seul, loin de là :)

Celui de le mettre sur ton réseau actuel :)

Merci beaucoup :)

Il ne faut pas hésiter pour les bugs, l'interface étant encore un peu jeune, il doit y avoir un ou deux bugs qui trainent.

N'hésites pas si tu as besoin des infos pour l'édition du site (pour ceux qui n'ont pas suivi l'histoire depuis le début, mon niveau d'anglais est bas donc j'ai un gros besoin de relecteurs pour le site et la documentation). De même pour ton projet, je suis toujours partant ;)

Une petite note aux lecteurs d'ailleurs, si vous utilisez déjà Shinken, n'hésitez pas à nous le faire savoir, le projet est toujours ravi d'avoir des références d'installations :)

Ceci va dépendre de ton profil en fait. Elle n'a pas pour vocation de faire tout, le café avec, mais d'être largement suffisante pour une grosse majorité d'utilisateurs. Pour pallier cela, elle a avoir des "interfaces" avec les autres UI plus complètes (et remplies de liens dans tous les sens) comme Thruk ou Centreon.

D'un point de vue technique oui elle est en Python. c'est un "simple" module du daemon Broker qui agrège le données tout simplement. Le framework utilisé est bottle.py, c'est minimaliste, mais très suffisant. Pour la partie javascript, c'est du mootools.

Pour les clignotants, c'est un peu fait exprès, il faut que les chefs arrivent également à comprendre les informations ;) Plus srieusement, oui, il y a un ou deux blocs qui vont moins clignoter mais ça restera tout de même très.. interactif et pas compatible avec les épileptiques :p

Salut,

J'en profite pour compléter la partie sur Shinken : la nouvelle version (0.8) devrait être sur les rails vers mi-septebmbre je pense.

Le core a quelques nouveautés intéressantes, mais c'est surtout sur "tout le reste" que ça évolue avec un outil CLI pour l'administrer et une première version d'une interface graphique dédiée à Shinken qui devrait plaire à beaucoup de monde ;)

Pour en revenir à la news, on voit une activité en forte hausse en ce qui concerne Zabbix sur les forums, avec une version 20 qui semble fort intéressante. On avait prédis une année 2011 riche du côté de la supervision avec la stagnation du core Nagios, je pense qu'on ne s'est pas trompé, surtout que le sujet est de plus en plus important pour les administrateurs :p

Salut,

Pour les 10000 objets de Shinken oui, c'est pas mal en fait :) (quand on sait que Nagios en fait beaucoup moins par exemple ;) ).

Pour le mix entre Nagios et Shinken je pense que ça ne devrait pas poser de soucis, mais va rendre indisponible certaines vues qui sont spécifiques à Shinken je pense et qui aident à trouver facilement la source des problèmes. A tester donc :)

Salut,

C'est tout à fait possible en effet. J'avoue ne pas être un grand fan de cette méthode passive, qui n'est là que pour pallier un gros manque de performance de Nagios, mais qui utilises beaucoup de fichiers plats et de configurations externes à l'ordonnanceur, et qui fait donc que c'est très difficilement utilisable dans un environnement distribué.

Pour utiliser check_mk avec Shinken oui, la partie passive ne devrait pas avoir de soucis à gérer cela. Elle est faite pour ce genre de traitements en batch.

Je pense plus à un "check_mk" en module, mais sans les parties non pratique, out en conservant les checks (ce sont des sortes de modules python, pratique) et la compatibilité avec les agents. A voir donc, mais ça pourrait être très pratique en effet.

Aide acceptée avec plaisir :)
Tu peux te créer un compte là et je te mettrai les droits en écritures.

Oui, en même temps c'est tellement vrai :)

Avec un bon exemple et une phrase qui incite moins au troll, ça ferait un très bon point pour Shinken justement, vu qu'il est classique désormais de vouloir des escalades de notifications sur tout son parc, mais pas avec les mêmes règles suivant les environnements (tu n'escalade pas une qualification comme une prod, voir même tu ne l'escalades pas en fait). Et là avec Nagios c'est vraiment complexe à mettre en place sur un parc un minimum grand, alors que c'est bien plus simple avec Shinken. Mais bon, c'est moins marrant de le dire comme ça, je préfère encore la phrase du site, ce qui démontre bien qu'un bon comparatif objectif serait sympa :)

Salut,

Il y a ce genre de matrice là. Mais grosso modo, il y a très peu de choses que Nagios gère que Shinken ne gère pas, et la plupart c'est par choix, car l'auteur de Nagios lui même conseille de ne pas les utiliser (à raison).

Ensuite c'est une question de maturité des alternatives du côté Shinken (par exemple pour utiliser l'interface Ninja, le module actuel dans Shinken manque de quelques données qui peuvent manquer sur l'interface ou le module de reporting par exemple), même si ça devient bien sûr de moins en moins en la défaveur de Shinken :)

Il serait c'est vrai intéressant de rajouter des exemples précis sur les items de cette page comme par exemple montrer en quoi il est bien plus simple de configurer les escalades de notifications avec Shinken qu'avec Nagios par exemple.

Un comparatif effectué par une personne non impliqué dans l'un des deux projets serait bien entendu bien plus intéressant que si c'est moi qui le fait (et aussi au dessus de tout soupçons :) ). Si tente quelqu'un ;)

Merci. Mais j'ai été bien aidé dans cette tâche qui n'a rien de naturel pour moi. J'en profite pour remercier Romuald, du site monitoring-fr.org pour son aide précieuse, surtout quand on voit ce que j'avais produit dans les premières versions du site... :)

Par contre il doit encore y avoir quelques fautes sur le site, je prends toutes les remarques, et mêmes les propositions d'aide pour corriger le site, j'ouvre un compte en écriture à qui veut aider :)

Pas bête, disons flexible ;)

Mon mail est dispo sur cette page (partie "who wrote Shinken") ou direct sur la mailing list ici, comme ça vous pourrez synchroniser vos efforts avec le packageur actuel et ce sur quoi il travaille.

Merci de la proposition en tout cas :)

Salut,

En fait un package est en cours, mais pas encore fini, donc pour l'instant on propose ce qui est le plus simple pour les utilisateurs :)

Toute aide sur ce point est acceptée avec grand plaisir bien entendu :)

Bonjour,

Oui ce n'est pas un soucis, en fait le module en question est très modulaire car les informations de "liens" sont en fait retournées par un script sous format json, donc si quelqu'un à un Xen sous la main, c'est tout à fait possible et rapide :)

S'il y en a intéressé pour ça ou pour la partie découverte (pareil, c'est un script qui renvoie les informations) vous pouvez venir sur la mailing list, je vous donnerai les pointeurs sur comment faire, et j'intégrerai cela avec un grand plaisir :)

Oh merci ça fait toujours plaisir de lire ce genre de post :)

Bon sûr ce je retourne coder un module de découverte (réseaux+systèmes) pour Shinken d'ailleurs ;)

Oh je suis content que ça marche :)

J'avais déjà essayé sur un Androïd 1.6 avec le Python ACE (2.6 de mémoire) et ça roulait pas mal déjà :)

Serais- tu d'accord pour faire une entrée sur cette installation sur le wiki du projet (http://www.shinken-monitoring.org/wiki/) ? :)

Si tu as besoin d'aide sur le reste de l'installation ou autre, n'hésites pas à demander :)