De combien de RAM dans les faits? D'après ce que j'ai vu sur de gros environnements, un simple serveur milieu de gamme absorbe sans aucun soucis 120K checks en 5min. Il est clair qu'il va consommer plus que Nagios (bien qu'en général la vraie consommation vienne des sondes, pas des ordonnanceurs), par contre ses capacités en terme de corrélation sont bien plus étendues. Comme d'habitude ça va donc dépendre de ses besoins :)
En ce qui concerne les temps de démarrage, tu as comparé avec un nagios + les temps qu'il faut au module NDO pour se charger dans les faits? :)
Si tu veux de l'aide pour optimiser un Shinken n'hésites pas à me demander, comme pour Nagios il y a pas mal de leviers actionnables et de bonnes pratiques :)
Pour Oseo bah ça reste une banque. Là je suis passé avec un concours, ça permet de ne rien avoir à rembourser :p
Pour JEI, oui je suis en train de regarder, mais ça ne règle qu'une partie des soucis, pas les principaux (ça règle la gestion, mais en rien monter un business model viable sur de l'open source).
Concernant le market place, pour que ce soit adopté, il faudra qu'OAT soit utilisé très très largement, ça sera ton vecteur d'entrée. Je te conseille donc de dropper la distrib, te focaliser sur OAT et la plugger sur des distribs à succès genre CES. Tu auras un vecteur d'accès un peu plus adapté mais pas trivial non plus :)
Arg, oui ça calme! Merci l'administration française… là je suis à la phase de business plan, je suis soutenu par Oseo qui commence à écouter quand on parle d'Open Source :p
Pour les sondes, oui, ça pourrait être un très bon modèle, mais qui là par définition va aller à contre-sens de la distribution simplifiée par exemple. Là tu vas changer ton ciblage du tout au tout, mais avec désormais une audience à forte valeur ajoutée (savoir superviser un Linux ou un Windows c'est à la portée de tous, un SAP c'est déjà pas pareil). Cependant ça veux dire se focaliser là dessus, ou au minimum réorienter ton outil vers cela.
Pour FAN et EON faut leur demander, mais à ma connaissance il n'y a pas trop d'échanges. Tu verras que c'est souvent le cas entre des solutions de ce genre, car ce sont des "solutions" justement, pas des "outils". Il y a d'ailleurs beaucoup moins d'aide (les 2~3%) sur ce genre de solutions que sur des librairies de développements justement. Ceci tient justement de ton public, ton cœur de marché.
D'un côté tu vas parler à des dev, ou des intégrateurs qui cherchent à avoir un outil parfaitement adapté à leur besoin, et qui savent donc qu'ils vont devoir faire un travail d'adaptation (code ou autre).
De l'autre pour les solutions les utilisateurs veulent quelque chose qui leur correspond directement, sans avoir à creuser. Le soucis va venir de l'adéquation avec leurs besoins. Eux ne vont pas coder/adapter. Ils cherchent un outil qui colle sans avoir à faire cela. Un conseil donc : si c'est trop loin de leurs attentes, rediriges les vers autre chose, car ils vont juste te faire perdre du temps pour que tu adaptes ta solution à leur besoin précis, mais étant parti sur une relation où tu donnes la solution, ils voudront cela gratuitement. Ceci ne peut donc durer que le temps de des allocations chômages. J'ai un peu tiré les traits entre les deux blocs, mais je pense que tu as déjà vu que c'est déjà ce que tu es en train de vivre.
Pour pôle emploi justement ça devrait aussi arriver en priorité sur ta todo list :)
Me concernant je suis en train de monter un business autour d'un projet open source sur le même sujet, et je te confirme que c'est loin d'être facile. Il y a bien la solution du "tout service", donc faire le travail d'une SSLL par exemple, mais côté "éditeur open source" c'est déjà bien moins trivial.
Tu peux donc continuer à développer pour deux raisons : la gloire ou un salaire (ou les deux si tu as de la chance). Ce derniers temps j'arrive à penser que la recherche de la gloire ça a surtout un coût ;)
D'expérience, vu le sujet, il n'y a pas de solution idéale et simple en matière de supervision. Elle est soit idéale, soit simple. Pas les deux. Essais un peu de voir quelle partie tu préfères et comment tu veux orienter tes projets (open source et commercial, ce ne sont pas les mêmes) par rapport à ça. Pas simple comme exercice, mais bienfaiteur une fois fait :)
Tout à fait d'accord avec David. Monter une communauté prends un temps considérable, et le ratio à attendre est bien de l'ordre de 2~3% qui vont participer activement au bout d'un moment. Reste ensuite la type d’utilisateur de ta solution. Elle simplifie la gestion d'une solution de supervision. Donc là tu présente de manière simple (mais pas simpliste) une problématique plutôt complexe, le tout depuis un OS qui apparait au yeux de beaucoup comme étant dédiés aux débutants.
Par définition tu vas donc attirer ceux qui ne veulent pas s’embêter, et qui ne vont même pas chercher la plus simple des informations genre ils vont ouvrir un ticket sur le forum sur un message inconnu genre "no space left on device"…). Il faut donc savoir une chose : plus tu auras des utilisateurs, plus tu auras des questions du genre, mais pas forcément un ensemble de membres de communautés qui vont chercher à t'aider vu la physionomie de tes utilisateurs. Ton outil est peut être scalable, mais toi non par définition. Tu devrais chercher à régler ce problème de "conception" de ta communauté au plus vite, car sinon tu ne tiendras pas bien longtemps (burnout and co, qui ne devrait pas tarder à arriver).
Tu devrais peut être te recentrer sur un des deux outils seulement (OAT) et l'adapter pour se connecter à une distribution existante, qui a déjà sa communauté d'experts (et non pas que de mecs qui ne veulent pas chercher, car eux ne t'aideront jamais en rien). Tu pourras t'appuyer sur leur expertise et ils se chargeront des soucis qui doivent en général pointer sur la distrib, non pas sur ton outil vu que par définition il doit simplifier les choses.
Solution annexe, concentres-toi sur la partie business de ton offre avec plus que l'outil mais bien une grosse valeur ajoutée en terme de maintenance de sa configuration et cie. Tu pourras alors embaucher un community manager, et alors ça ne sera plus ton problème :) (ça s’appelle le jeu de la patate chaude :) ).
Bon courage en tout cas, ce n'est pas simple, mais je te conseille fortement de poser ton navigateur et ton emacs afin de réfléchir à cela dès maintenant, car pour en avoir fait l'expérience, se cramer la santé sur un projet open source ça n'a rien d'agréable :)
Justement : s'ils ne font que te copier sans innover, tu n'as qu'à innover juste un peu pour être au dessus. Si tu as du mal, c'est bien qu'au final ils n'ont pas juste copié, mais bien innové aussi non?
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.
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 ;) ).
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…
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
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
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 :)
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.
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 :)
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 ;)
[^] # Re: Perf Nagios/Centreon et Shinken
Posté par Jean Gabes (site web personnel) . En réponse au message Supervision: je ne sais lequel choisir. Évalué à 1.
De combien de RAM dans les faits? D'après ce que j'ai vu sur de gros environnements, un simple serveur milieu de gamme absorbe sans aucun soucis 120K checks en 5min. Il est clair qu'il va consommer plus que Nagios (bien qu'en général la vraie consommation vienne des sondes, pas des ordonnanceurs), par contre ses capacités en terme de corrélation sont bien plus étendues. Comme d'habitude ça va donc dépendre de ses besoins :)
En ce qui concerne les temps de démarrage, tu as comparé avec un nagios + les temps qu'il faut au module NDO pour se charger dans les faits? :)
Si tu veux de l'aide pour optimiser un Shinken n'hésites pas à me demander, comme pour Nagios il y a pas mal de leviers actionnables et de bonnes pratiques :)
[^] # Re: concept intéressant
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Overmon : la supervision couplée à l’inventaire. Évalué à 1.
Pour Oseo bah ça reste une banque. Là je suis passé avec un concours, ça permet de ne rien avoir à rembourser :p
Pour JEI, oui je suis en train de regarder, mais ça ne règle qu'une partie des soucis, pas les principaux (ça règle la gestion, mais en rien monter un business model viable sur de l'open source).
Concernant le market place, pour que ce soit adopté, il faudra qu'OAT soit utilisé très très largement, ça sera ton vecteur d'entrée. Je te conseille donc de dropper la distrib, te focaliser sur OAT et la plugger sur des distribs à succès genre CES. Tu auras un vecteur d'accès un peu plus adapté mais pas trivial non plus :)
[^] # Re: concept intéressant
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Overmon : la supervision couplée à l’inventaire. Évalué à 2.
Arg, oui ça calme! Merci l'administration française… là je suis à la phase de business plan, je suis soutenu par Oseo qui commence à écouter quand on parle d'Open Source :p
Pour les sondes, oui, ça pourrait être un très bon modèle, mais qui là par définition va aller à contre-sens de la distribution simplifiée par exemple. Là tu vas changer ton ciblage du tout au tout, mais avec désormais une audience à forte valeur ajoutée (savoir superviser un Linux ou un Windows c'est à la portée de tous, un SAP c'est déjà pas pareil). Cependant ça veux dire se focaliser là dessus, ou au minimum réorienter ton outil vers cela.
[^] # Re: concept intéressant
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Overmon : la supervision couplée à l’inventaire. Évalué à 2.
Pour FAN et EON faut leur demander, mais à ma connaissance il n'y a pas trop d'échanges. Tu verras que c'est souvent le cas entre des solutions de ce genre, car ce sont des "solutions" justement, pas des "outils". Il y a d'ailleurs beaucoup moins d'aide (les 2~3%) sur ce genre de solutions que sur des librairies de développements justement. Ceci tient justement de ton public, ton cœur de marché.
D'un côté tu vas parler à des dev, ou des intégrateurs qui cherchent à avoir un outil parfaitement adapté à leur besoin, et qui savent donc qu'ils vont devoir faire un travail d'adaptation (code ou autre).
De l'autre pour les solutions les utilisateurs veulent quelque chose qui leur correspond directement, sans avoir à creuser. Le soucis va venir de l'adéquation avec leurs besoins. Eux ne vont pas coder/adapter. Ils cherchent un outil qui colle sans avoir à faire cela. Un conseil donc : si c'est trop loin de leurs attentes, rediriges les vers autre chose, car ils vont juste te faire perdre du temps pour que tu adaptes ta solution à leur besoin précis, mais étant parti sur une relation où tu donnes la solution, ils voudront cela gratuitement. Ceci ne peut donc durer que le temps de des allocations chômages. J'ai un peu tiré les traits entre les deux blocs, mais je pense que tu as déjà vu que c'est déjà ce que tu es en train de vivre.
Pour pôle emploi justement ça devrait aussi arriver en priorité sur ta todo list :)
Me concernant je suis en train de monter un business autour d'un projet open source sur le même sujet, et je te confirme que c'est loin d'être facile. Il y a bien la solution du "tout service", donc faire le travail d'une SSLL par exemple, mais côté "éditeur open source" c'est déjà bien moins trivial.
Tu peux donc continuer à développer pour deux raisons : la gloire ou un salaire (ou les deux si tu as de la chance). Ce derniers temps j'arrive à penser que la recherche de la gloire ça a surtout un coût ;)
D'expérience, vu le sujet, il n'y a pas de solution idéale et simple en matière de supervision. Elle est soit idéale, soit simple. Pas les deux. Essais un peu de voir quelle partie tu préfères et comment tu veux orienter tes projets (open source et commercial, ce ne sont pas les mêmes) par rapport à ça. Pas simple comme exercice, mais bienfaiteur une fois fait :)
[^] # Re: concept intéressant
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Overmon : la supervision couplée à l’inventaire. Évalué à 2.
Tout à fait d'accord avec David. Monter une communauté prends un temps considérable, et le ratio à attendre est bien de l'ordre de 2~3% qui vont participer activement au bout d'un moment. Reste ensuite la type d’utilisateur de ta solution. Elle simplifie la gestion d'une solution de supervision. Donc là tu présente de manière simple (mais pas simpliste) une problématique plutôt complexe, le tout depuis un OS qui apparait au yeux de beaucoup comme étant dédiés aux débutants.
Par définition tu vas donc attirer ceux qui ne veulent pas s’embêter, et qui ne vont même pas chercher la plus simple des informations genre ils vont ouvrir un ticket sur le forum sur un message inconnu genre "no space left on device"…). Il faut donc savoir une chose : plus tu auras des utilisateurs, plus tu auras des questions du genre, mais pas forcément un ensemble de membres de communautés qui vont chercher à t'aider vu la physionomie de tes utilisateurs. Ton outil est peut être scalable, mais toi non par définition. Tu devrais chercher à régler ce problème de "conception" de ta communauté au plus vite, car sinon tu ne tiendras pas bien longtemps (burnout and co, qui ne devrait pas tarder à arriver).
Tu devrais peut être te recentrer sur un des deux outils seulement (OAT) et l'adapter pour se connecter à une distribution existante, qui a déjà sa communauté d'experts (et non pas que de mecs qui ne veulent pas chercher, car eux ne t'aideront jamais en rien). Tu pourras t'appuyer sur leur expertise et ils se chargeront des soucis qui doivent en général pointer sur la distrib, non pas sur ton outil vu que par définition il doit simplifier les choses.
Solution annexe, concentres-toi sur la partie business de ton offre avec plus que l'outil mais bien une grosse valeur ajoutée en terme de maintenance de sa configuration et cie. Tu pourras alors embaucher un community manager, et alors ça ne sera plus ton problème :) (ça s’appelle le jeu de la patate chaude :) ).
Bon courage en tout cas, ce n'est pas simple, mais je te conseille fortement de poser ton navigateur et ton emacs afin de réfléchir à cela dès maintenant, car pour en avoir fait l'expérience, se cramer la santé sur un projet open source ça n'a rien d'agréable :)
[^] # Re: i.flop
Posté par Jean Gabes (site web personnel) . En réponse au journal L'histoire d'un bide prévisible.... Évalué à 10.
Justement : s'ils ne font que te copier sans innover, tu n'as qu'à innover juste un peu pour être au dessus. Si tu as du mal, c'est bien qu'au final ils n'ont pas juste copié, mais bien innové aussi non?
[^] # Re: Installation cool
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 1.2. Évalué à 2.
Très bonne remarque :)
Aller hop, je me note d'acheter un certificat pour ce site :)
[^] # Re: Grâce à ce journal.....
Posté par Jean Gabes (site web personnel) . En réponse au journal GNOME et la suppression progressive des fonctions. Évalué à 5.
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.
[^] # Re: oui mais...
Posté par Jean Gabes (site web personnel) . En réponse au journal [Prix des ebooks] coup de gueule. Évalué à 2.
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.
# Sécurité & bluetooth
Posté par Jean Gabes (site web personnel) . En réponse au journal Ford Keyfree Login (on est presque dredi), des créatifs en action.... Évalué à 2.
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é :(
[^] # Re: Shinken
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Sortie de Nagios 3.4.0. Évalué à 9.
Salut,
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…
[^] # Re: Fedora
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 1.0 est de sortie. Évalué à 2.
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.
[^] # Re: Surveilr
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 1.0 est de sortie. Évalué à 4.
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 ;) ).
[^] # Re: Ça ne vient pas de moi...
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 1.0 est de sortie. Évalué à 8.
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 :)
[^] # Re: Yes !
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 1.0 est de sortie. Évalué à 6.
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 ;)
[^] # Re: Ça ne vient pas de moi...
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 1.0 est de sortie. Évalué à 3.
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à :)
[^] # Re: Top moumoute !
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 0.8 : arrivée d’une interface de supervision dédiée. Évalué à 2.
Celui de le mettre sur ton réseau actuel :)
[^] # Re: Top moumoute !
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 0.8 : arrivée d’une interface de supervision dédiée. Évalué à 4.
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 :)
[^] # Re: Interface Web dédiée à Shinken
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 0.8 : arrivée d’une interface de supervision dédiée. Évalué à 4.
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
# Quoi de neuf pour Shinken
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Quelques brèves sur la supervision. Évalué à 9.
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
[^] # Re: Hierarchie
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Publication de Thruk 1.0. Évalué à 1.
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 :)
[^] # Re: Matrice fonctionnelle Nagios et Shinken
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Sortie de Shinken 0.6 . Évalué à 2.
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.
[^] # Re: Site web
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Sortie de Shinken 0.6 . Évalué à 1.
Aide acceptée avec plaisir :)
Tu peux te créer un compte là et je te mettrai les droits en écritures.
[^] # Re: Matrice fonctionnelle Nagios et Shinken
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Sortie de Shinken 0.6 . Évalué à 2.
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 :)
[^] # Re: Matrice fonctionnelle Nagios et Shinken
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Sortie de Shinken 0.6 . Évalué à 2.
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 ;)