Le plus fort c'est que commercialement il n'y a aucun intérêt à faire ça. Le pire qu'il peut être "reprocher" aux mainteneur des sondes était de dire clairement qu'elles étaient également pour les autres outils du monde nagios (centreon-engine, icinga, naemon et shinken). Enfin bon ce n'était pas non plus un crime si grave, pas de quoi flinguer le site sans aucun avertissements…
J'ai beau chercher là j'ai du mal à comprendre ce qu'il a fait. D'habitude il y a une raison commerciale assez claire, mais là ce sont juste les sondes, et je vois mal comment les modifier pour les monétiser.
Oh mais je ne disais pas du tout que c'était débile d'aller vers là, bien au contraire :)
Le truc c'est qu'à chaque fois que l'on parle d'économie & open source/libre on arrive au modèle des services genre intégration. Mais voila, ce modèle fait vivre les intégrateurs, pas les dev/éditeurs justement. Il ne faut donc pas s'étonner que de plus en plus d'outils s'orientent vers de l'open core ou cherchent à rendre l'utilisation sur certains OS payantes (en gros pour 99% des personnes devoir recompiler sous Windows est de l'ordre de l'impossible, donc on a bien créé une barrière virtuelle ici), ou la pub (on utilise la popularité de l'outil, mais ça demande donc une audience monstrueuse, qui par définition ne sera atteinte que par quelques outils seulement).
Pour le Big Daddy c'est bien ce que je disais. Le modèle est valide car justement de gros acteurs ont tout intérêt à ce que l'outil se développe fortement pour booster leur propre business. Donc là aucun soucis à ce que ça reste open source.
Mais dans le monde "normal", avec un outil "normal" on a pas la visibilité de Firefox, ni de gros acteurs qui veulent payer les dev (car on fait un outil qui concurrence les offres des gros par exemple). Or les intégrateurs sont ravis de pouvoir faire du chiffre avec la version open source, mais ne participent que très très peu au dev (quand ils participent tout cours…). Pouvoir payer un salaire avec du dev à la demande ça se fait, mais si on veux pouvoir embaucher pour faire plus de dev par exemple là ce n'est plus tenable comme modèle.
Le modèle open source n'est donc pas viable comme tel dans le système économique actuel. Or en effet il faut être réaliste et l'adapter (genre open core). Ce qui m'étonne c'est que beaucoup semblent encore penser que ce modèle est viable pour tous les outils. Or non, il ne l'est pas. On a quelques exceptions bien sûr, mais soyons sérieux dans la majorité des cas ça ne marche pas.
Il ne faut donc pas s'étonner que de plus en plus d'outil (surtout d'infrastructure) s'orientent vers de l'open core. On avait déjà Nagios et Centreon, on a aussi Puppet, Cfengine, Nginx et prochainement Shinken. C'est dommage mais bon réalité fait loi :)
Je me demande si ce n'est pas la méthode la plus efficace pour que l'auteur ne développe plus du tout sur la version libre :)
Le fait d'en arriver à un tel modèle économique devrait se faire poser des questions à pas mal de monde de la communauté, car c'est de plus en plus la norme. On en arrive à quand même contourner l'esprit (accès sans limite) avec une astuce (source!=binaire), il y a un vrai soucis d'adéquation entre le principe du libre et le système économique actuel. On pourra avoir quelques victoires de temps en temps sur des niches qui s'y prêtes bien (Firefox et OpenStack avec leur modèle économique "big daddy" ou RedHat avec son modèle "masse critique permettant la certification par les grosses applications"), mais on est pas prêt d'arriver à le généraliser en l'état.
Les deux sont pensés pour être des frameworks de supervision et non pas des "solutions". Ils sont donc à mettre dans les mains de quelqu'un qui souhaite maîtriser réellement sa supervision, en la concevant de bout en bout (même si dans Shinken on a à disposition des recettes pour les cas classiques, l'admin est encouragé à les adapter à son besoin).
Sinon pour icinga, c'est assez vaste en fait. En gros surtout du distribué (load balancing ET haute dispo), une focus sur la recherche des problèmes sources et une notion d'importance métiers sur les alertes (savoir qu'un serveur est tombé c'est bien, savoir qu'il a impacté à 20 niveaux de dépendances en dessous une application critique c'est mieux :) ).
Par contre icinga vient de base avec une interface de configuration (lconf de mémoire) là où il faut le mettre en place soit même pour Shinken. Ils ont aussi repris et amélioré l'interface de Nagios, là où Shinken a la sienne (en fait elle ne présente pas les mêmes choses tout simplement).
Le mieux ça reste encore de tester les deux, et d'aller lire le hors série Linuxmag de septembre 2012 dédié à Shinken pour mieux voir ce dont il est capable :)
Malheureusement ce sont ceux qui font le plus de bruits en effet. Je ne doute pas qu'il y ai aussi une armée de bonne volontés qui travaille à faire encore mieux que les cgroups pour les BSD, mais par définition ils travaillent, donc on ne les entends pas c'est dommage.
Tout à fait. Demander à ce que tous les noyaux soient au même niveau quand on souhaite améliorer les souches supérieures reviendrait à ne pas avancer. Linux et les BSD n'avancent pas sur les mêmes sujets en effet, mais est-ce un mal? De plus personne n'a le droit de demander à un autre d’arrêter d'avancer sur un sujet car son "camp" ne suit pas le rythme. Par contre ça doit motiver à suivre, voir innover ;)
Il me semble qu'elle a une petite sœur dans le genre, un peu plus large, ça a été évoqué dans un commentaire de la (longue) histoire Linkeo.
Puis bon, si je le fais c'est que je n'aurais pas encore compris comment ne pas me retrouver dans cette situation. Or là ça restera gravé dans ma mémoire au fer rouge, donc je suis sûr de ne pas l'oublier lors de mes prochains échanges avec des SSII/LL (j'arrive de moins en moins à faire de différence entre elles à vrai dire quand on parle des plus grosses).
Par ces clients là, car il pourraient en appeler à une sorte de diffamation : ils pourraient rétorqués que par rapport à certains contrats cadres qu'ils ont avec d'autres fournisseurs ça va leur porter préjudice.
Puis bon à la limite c'est le jeu, pourquoi pas. Ensuite à moi de faire comprendre que la règle sera que désormais pour avoir de l'aide, faudra faire un effort. Ca ne sert à rien de se plaindre d'une situation, autant en tirer des leçons pour ne pas recommencer les mêmes erreurs plus tard :)
Pas tout le reste. La documentation du projet reste (non documenté un code ne sert à rien), ni l'accès au forum car c'est un lieu d'échange pour ceux qui veulent s'entraider autour du projet.
Mais tout ce qui demande un certain investissement ou engagement (temps de réponse, support et donc présence) doit être uniquement disponible que pour ceux qui sont prêts à en payer le prix. Il en est de même pour l'industrialisation de la solution. Ceux qui souhaitent faire la leur le peuvent, ceux qui ne veulent pas faire cet effort eux même devront en payer le prix. On ne leur enlève aucune liberté au final, car ils ont toujours moyens de le faire eux même s'ils veulent.
J'aimerai que ça marche autrement, mais dans les faits non, si tu donnes tout gratuitement, pourquoi les personnes te rémunéreraient? Pour tes beaux yeux? J'aimerai, mais non, d'expérience ça ne marche pas. On va juste t'en demander encore plus. Exemple : il n'y a pas 10min on m'a demandé par tel du support gratuit sur un gros compte qui utilise Shinken car j'ai eu le malheur d'en faire dans le passé espérant que ça aiderait le projet. Bah là non, ça n'a en rien aidé le projet (même pas une référence :( ), donc là non, fini. RedHat a montré la voie, il suffit de suivre leur exemple désormais :D
Je dois bien avouer être dans la même situation, et sur le même "marché" de la supervision en plus :D
Avec le temps que je dis que monter la communauté puis en vivre n'était pas une solution très viable, car ça signifie faciliter l'accès à l'outil, or c'est encore ça le plus monétisable (cf RedHat justement). Vu que ta structure est petite, tu auras des soucis à t'aligner sur des prestations face aux SSII qui vont envoyer des stagiaires sous payés, il ne faut pas se leurrer.
Monter une grosse communauté signifie aider lors de la résolution des problèmes (support gratuit donc), implémenter de nouvelles fonctionnalités sur la demande d'un utilisateur car elles te plait vraiment et que ça va améliorer l'outil, et donc agrandir la communauté.
Or là il y a un soucis, car tu auras une grosse communauté, de gros utilisateurs (et bravo pour les références, j'attends encore des références pour 3 banques, 2 ministères et 1 constructeur allemand d'automobile "officielle" pour Shinken….) mais toujours aucun business model.
Là je vais être un peu sec, et cois mois ça me fait aussi mal qu'à toi d'en arriver là : fais ton deuil de monter une grosse communauté, penses d'abord à remplir ton assiette et payer ton loyer. Laisses les sources disponibles, mais place les VM sous licences genre gratuit pour pré-production sur 3mois, mais payant (et cher) sur de la production. Laisses de disponible facilement tout ce qui touche aux environnements libres, mais fait payer cher tout ce qui touche au propriétaire (genre le déploiement de sondes exchange ou weblogic).
Au final ceux qui font du libre, et uniquement du libre ne seront pas, ou peu, impactés car ils auront les sources, et s'ils prennent du temps (libre => "tu as du temps ou de l'argent?") ils pourront faire ce qu'ils souhaitent. Les autres se fichent bien du libre, ils veulent quelque chose qui marche et c'est tout. Et bien parfait, ils peuvent l'avoir et ce rapidement (genre une VM appliance toute prête), mais faut passer par la case achat.
Tu ne peux pas être totalement ouvert, déjà industrialisé (étonnant pour un outil facilitant l'industrialisation justement non? ;) ), réactif et vivre de ton outil. Tu vas te faire bouffer tout cru. C'est quelque choses que peuvent se permettre les grosses fondations qui sont financées de manières indirectes par ce que produit l'outil (genre HP vend des serveurs, et donc doit faire en sorte que Linux marche bien dessus).
RedHat fait très bien cela. Or tu n'as pas de support ou même accès aux rpm sans avoir déliés ta bourse. Tu peux partir sur CentOS, mais RedHat s'en fiche, car quand tu veux du support "imputable" (en cas de soucis majeur faut pouvoir rejeter la faute sur quelqu'un d'autre dans les grosses sociétés…) tu prends du RH, pas de la CentOS. Ceux qui partent sur CentOS n'auraient de toute manière jamais payés RedHat, donc RedHat n'a rien perdu, même "potentiellement".
Bref, pars à la campagne un jour ou deux, fais le point. Mais je te conseille de ne laisser que les sources de disponible, et que les versions faciles d'installations ne sont disponibles pour de la prod que si tu puisses en vivre. Vires donc tes VM toutes prêtes, elles te font du mal. Tu pourras vivre de ton travail direct : coder! et non pas tenter de vivre d'un moyen indirect genre de la prestation d'installation où tu seras en concurrence quasi déloyale avec des SSII qui vendent n'importe quoi et n'hésitent pas à mentir à leur client!
Bon courage, je comprends parfaitement ce que tu ressens, et que ça te déchire d'en arriver là. Mais mieux vaut qu'une partie du projet soit libre et qu'il continue à vivre, plutôt que tu te crames littéralement et qu'au final ils disparaisse totalement. Penses à comment le business model que tu montes va aider le projet, mais ne t'attends pas à ce que le projet te fournisse naturellement un business model. Est-ce dommage? Oui, car avec des moyens comme le revenu universel, on n'aurait pas besoin d'en arriver là. Mais ça n'est pas en place, et c'est pas demain que ça arrivera, donc on rentre les mouchoirs dans la poche, et on rentre dans le jeu en acceptant les règles à défaut de pouvoir les changer. Tu peux tenter le crownfounding, mais vu le marché, je n'y compterais pas trop (encore moins sur les dons, ça n'a jamais fonctionné pour du dev, et ça ne fonctionnera jamais).
Tu parles de Merethis à un moment (éditeur de Centreon et divers modules sous licences autour de Centreon). Sache qu'ils ont raison. S'ils n'étaient pas passés par ça, il n'y aurait plus de Centreon actuellement vu qu'ils étaient en concurrence sur de la prestation sur leur outil face à de grosses SSII qui faisaient du dumping sur les prix pour juste entrer sur les comptes et vendre ensuite d'autres outils à plus fortes rémunérations.
Bonne chance en tout cas, car c'est une décision très dure à prendre et à assumer. Mais poses-toi la question : combien sont ceux qui vont te crier dessus et qui vivent réellement de leur code (tu es un codeur, pas un formateur ou intégrateur) sur ce marché là en montant leur société? Les râleurs râleront, mais sincèrement, peu importe ce que tu fais, ils râleront quand même, ne les écoute pas et avance.
En effet, un module de Shinken permet de transformer des data lues des nodes collectd en data pour des services Shinken. ensuite ils seront soit transférés aux backend de perfdata (genre PNP ou Graphite), mais certaines données peuvent également être "analysées" afin de vérifier si elles sont bonnes ou pas.
Shinken ne garde pas lui même l'historique et ça ne fait que transiter par lui, donc point de RRDCache dans l'histoire (mais PNP le gère lui par contre à la sortie).
Pour les graphiques, les deux poids lourds restent PNP et Graphite. Je préfère ce dernier car il est possible de le mettre en architecture hautement disponible, même si le rendu des graphiques est très… moche faut le dire :)
En fait elle est juste cachée, il est très simple de la réactiver, mais vu qu'on a pas eu de temps pour l'avancer, et qu'on a eu pas mal de posts sur le forums sur "pourquoi ça bug là?" avec très très peu d'aide ensuite, j'ai préféré la cacher afin que seuls des personnes motivées et qui comprennent ce que beta signifie y auront accès :)
En fait c'est déjà possible de le détourner pour ça. Ce qu'il va manquer c'est justement les enchainements entre des actions. Shinken le fait, mais quand ça va "mal", un $U le fait au contraire quand ça va bien. Sinon conceptuellement ça reste lancer des scripts sur certaines périodes de temps bien précises, et les enchainer suivant les résultats :)
Concernant les outils liés, ce sont surtout tout ce qui est lié aux logs (logstash & co) et des outils de visualisations de graphes (genere PNP4Nagios ou Graphite).
Pour la partie la plus difficile, c'était clairement le calcul correct des périodes de temps, avec des cas un peu tordu genre "le prochain avant dernier mardi de novembre sachant qu'on est en décembre et qu'on a exclu les jours pairs du mois". Faire un algo efficace et complet pour résoudre ça m'a demandé 1 mois complet à l'époque. Certaines autres fonctionnalités n'étaient pas triviales non plus, mais rien d'un tel ordre de complexité :)
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?
# Difficile à comprendre de la part de l'auteur de Nagios
Posté par Jean Gabes (site web personnel) . En réponse au journal Changement d'URL pour les "plugins" Nagios. Évalué à 6.
Le plus fort c'est que commercialement il n'y a aucun intérêt à faire ça. Le pire qu'il peut être "reprocher" aux mainteneur des sondes était de dire clairement qu'elles étaient également pour les autres outils du monde nagios (centreon-engine, icinga, naemon et shinken). Enfin bon ce n'était pas non plus un crime si grave, pas de quoi flinguer le site sans aucun avertissements…
J'ai beau chercher là j'ai du mal à comprendre ce qu'il a fait. D'habitude il y a une raison commerciale assez claire, mais là ce sont juste les sondes, et je vois mal comment les modifier pour les monétiser.
[^] # Re: shareware ou logiciel libre payant ?
Posté par Jean Gabes (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 6.
Oh mais je ne disais pas du tout que c'était débile d'aller vers là, bien au contraire :)
Le truc c'est qu'à chaque fois que l'on parle d'économie & open source/libre on arrive au modèle des services genre intégration. Mais voila, ce modèle fait vivre les intégrateurs, pas les dev/éditeurs justement. Il ne faut donc pas s'étonner que de plus en plus d'outils s'orientent vers de l'open core ou cherchent à rendre l'utilisation sur certains OS payantes (en gros pour 99% des personnes devoir recompiler sous Windows est de l'ordre de l'impossible, donc on a bien créé une barrière virtuelle ici), ou la pub (on utilise la popularité de l'outil, mais ça demande donc une audience monstrueuse, qui par définition ne sera atteinte que par quelques outils seulement).
Pour le Big Daddy c'est bien ce que je disais. Le modèle est valide car justement de gros acteurs ont tout intérêt à ce que l'outil se développe fortement pour booster leur propre business. Donc là aucun soucis à ce que ça reste open source.
Mais dans le monde "normal", avec un outil "normal" on a pas la visibilité de Firefox, ni de gros acteurs qui veulent payer les dev (car on fait un outil qui concurrence les offres des gros par exemple). Or les intégrateurs sont ravis de pouvoir faire du chiffre avec la version open source, mais ne participent que très très peu au dev (quand ils participent tout cours…). Pouvoir payer un salaire avec du dev à la demande ça se fait, mais si on veux pouvoir embaucher pour faire plus de dev par exemple là ce n'est plus tenable comme modèle.
Le modèle open source n'est donc pas viable comme tel dans le système économique actuel. Or en effet il faut être réaliste et l'adapter (genre open core). Ce qui m'étonne c'est que beaucoup semblent encore penser que ce modèle est viable pour tous les outils. Or non, il ne l'est pas. On a quelques exceptions bien sûr, mais soyons sérieux dans la majorité des cas ça ne marche pas.
Il ne faut donc pas s'étonner que de plus en plus d'outil (surtout d'infrastructure) s'orientent vers de l'open core. On avait déjà Nagios et Centreon, on a aussi Puppet, Cfengine, Nginx et prochainement Shinken. C'est dommage mais bon réalité fait loi :)
[^] # Re: shareware ou logiciel libre payant ?
Posté par Jean Gabes (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 2.
Je me demande si ce n'est pas la méthode la plus efficace pour que l'auteur ne développe plus du tout sur la version libre :)
Le fait d'en arriver à un tel modèle économique devrait se faire poser des questions à pas mal de monde de la communauté, car c'est de plus en plus la norme. On en arrive à quand même contourner l'esprit (accès sans limite) avec une astuce (source!=binaire), il y a un vrai soucis d'adéquation entre le principe du libre et le système économique actuel. On pourra avoir quelques victoires de temps en temps sur des niches qui s'y prêtes bien (Firefox et OpenStack avec leur modèle économique "big daddy" ou RedHat avec son modèle "masse critique permettant la certification par les grosses applications"), mais on est pas prêt d'arriver à le généraliser en l'état.
[^] # Re: Rumeur ?
Posté par Jean Gabes (site web personnel) . En réponse au journal [Bookmark] Nagios fork. Évalué à 2.
Pourquoi ne pas envoyer directement un mail à l'auteur de naemon? Il est très ouvert et réponds volontiers aux mails :)
[^] # Re: Bon ben il est l'heure d'aller voir du côté de Shinken si l'herbe est plus verte.
Posté par Jean Gabes (site web personnel) . En réponse au journal [Bookmark] Nagios fork. Évalué à 2.
Ah ce n'est pas du click and run c'est certain :p
Les deux sont pensés pour être des frameworks de supervision et non pas des "solutions". Ils sont donc à mettre dans les mains de quelqu'un qui souhaite maîtriser réellement sa supervision, en la concevant de bout en bout (même si dans Shinken on a à disposition des recettes pour les cas classiques, l'admin est encouragé à les adapter à son besoin).
Facilité ou flexibilité en gros :)
[^] # Re: Bon ben il est l'heure d'aller voir du côté de Shinken si l'herbe est plus verte.
Posté par Jean Gabes (site web personnel) . En réponse au journal [Bookmark] Nagios fork. Évalué à 8.
Pour info on a de petits soucis de perf sur www.shinken-monitoring.org, je suis en train de creuser ça.
Sinon pour icinga, c'est assez vaste en fait. En gros surtout du distribué (load balancing ET haute dispo), une focus sur la recherche des problèmes sources et une notion d'importance métiers sur les alertes (savoir qu'un serveur est tombé c'est bien, savoir qu'il a impacté à 20 niveaux de dépendances en dessous une application critique c'est mieux :) ).
Par contre icinga vient de base avec une interface de configuration (lconf de mémoire) là où il faut le mettre en place soit même pour Shinken. Ils ont aussi repris et amélioré l'interface de Nagios, là où Shinken a la sienne (en fait elle ne présente pas les mêmes choses tout simplement).
Le mieux ça reste encore de tester les deux, et d'aller lire le hors série Linuxmag de septembre 2012 dédié à Shinken pour mieux voir ce dont il est capable :)
[^] # Re: Est ce que la solution...
Posté par Jean Gabes (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 3.
Malheureusement ce sont ceux qui font le plus de bruits en effet. Je ne doute pas qu'il y ai aussi une armée de bonne volontés qui travaille à faire encore mieux que les cgroups pour les BSD, mais par définition ils travaillent, donc on ne les entends pas c'est dommage.
[^] # Re: Est ce que la solution...
Posté par Jean Gabes (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 2.
Tout à fait. Demander à ce que tous les noyaux soient au même niveau quand on souhaite améliorer les souches supérieures reviendrait à ne pas avancer. Linux et les BSD n'avancent pas sur les mêmes sujets en effet, mais est-ce un mal? De plus personne n'a le droit de demander à un autre d’arrêter d'avancer sur un sujet car son "camp" ne suit pas le rythme. Par contre ça doit motiver à suivre, voir innover ;)
[^] # Re: Même situation, mais des pistes
Posté par Jean Gabes (site web personnel) . En réponse au journal L'open source va me tuer .... Évalué à 2.
Il me semble qu'elle a une petite sœur dans le genre, un peu plus large, ça a été évoqué dans un commentaire de la (longue) histoire Linkeo.
Puis bon, si je le fais c'est que je n'aurais pas encore compris comment ne pas me retrouver dans cette situation. Or là ça restera gravé dans ma mémoire au fer rouge, donc je suis sûr de ne pas l'oublier lors de mes prochains échanges avec des SSII/LL (j'arrive de moins en moins à faire de différence entre elles à vrai dire quand on parle des plus grosses).
[^] # Re: Même situation, mais des pistes
Posté par Jean Gabes (site web personnel) . En réponse au journal L'open source va me tuer .... Évalué à 2.
Par ces clients là, car il pourraient en appeler à une sorte de diffamation : ils pourraient rétorqués que par rapport à certains contrats cadres qu'ils ont avec d'autres fournisseurs ça va leur porter préjudice.
Puis bon à la limite c'est le jeu, pourquoi pas. Ensuite à moi de faire comprendre que la règle sera que désormais pour avoir de l'aide, faudra faire un effort. Ca ne sert à rien de se plaindre d'une situation, autant en tirer des leçons pour ne pas recommencer les mêmes erreurs plus tard :)
[^] # Re: Même situation, mais des pistes
Posté par Jean Gabes (site web personnel) . En réponse au journal L'open source va me tuer .... Évalué à 2.
Je ne suis pas sûr car je ne peux pas prouver qu'ils l'utilisent après tout :(
[^] # Re: Même situation, mais des pistes
Posté par Jean Gabes (site web personnel) . En réponse au journal L'open source va me tuer .... Évalué à 2.
Pas tout le reste. La documentation du projet reste (non documenté un code ne sert à rien), ni l'accès au forum car c'est un lieu d'échange pour ceux qui veulent s'entraider autour du projet.
Mais tout ce qui demande un certain investissement ou engagement (temps de réponse, support et donc présence) doit être uniquement disponible que pour ceux qui sont prêts à en payer le prix. Il en est de même pour l'industrialisation de la solution. Ceux qui souhaitent faire la leur le peuvent, ceux qui ne veulent pas faire cet effort eux même devront en payer le prix. On ne leur enlève aucune liberté au final, car ils ont toujours moyens de le faire eux même s'ils veulent.
J'aimerai que ça marche autrement, mais dans les faits non, si tu donnes tout gratuitement, pourquoi les personnes te rémunéreraient? Pour tes beaux yeux? J'aimerai, mais non, d'expérience ça ne marche pas. On va juste t'en demander encore plus. Exemple : il n'y a pas 10min on m'a demandé par tel du support gratuit sur un gros compte qui utilise Shinken car j'ai eu le malheur d'en faire dans le passé espérant que ça aiderait le projet. Bah là non, ça n'a en rien aidé le projet (même pas une référence :( ), donc là non, fini. RedHat a montré la voie, il suffit de suivre leur exemple désormais :D
# Même situation, mais des pistes
Posté par Jean Gabes (site web personnel) . En réponse au journal L'open source va me tuer .... Évalué à 5.
Salut,
Je dois bien avouer être dans la même situation, et sur le même "marché" de la supervision en plus :D
Avec le temps que je dis que monter la communauté puis en vivre n'était pas une solution très viable, car ça signifie faciliter l'accès à l'outil, or c'est encore ça le plus monétisable (cf RedHat justement). Vu que ta structure est petite, tu auras des soucis à t'aligner sur des prestations face aux SSII qui vont envoyer des stagiaires sous payés, il ne faut pas se leurrer.
Monter une grosse communauté signifie aider lors de la résolution des problèmes (support gratuit donc), implémenter de nouvelles fonctionnalités sur la demande d'un utilisateur car elles te plait vraiment et que ça va améliorer l'outil, et donc agrandir la communauté.
Or là il y a un soucis, car tu auras une grosse communauté, de gros utilisateurs (et bravo pour les références, j'attends encore des références pour 3 banques, 2 ministères et 1 constructeur allemand d'automobile "officielle" pour Shinken….) mais toujours aucun business model.
Là je vais être un peu sec, et cois mois ça me fait aussi mal qu'à toi d'en arriver là : fais ton deuil de monter une grosse communauté, penses d'abord à remplir ton assiette et payer ton loyer. Laisses les sources disponibles, mais place les VM sous licences genre gratuit pour pré-production sur 3mois, mais payant (et cher) sur de la production. Laisses de disponible facilement tout ce qui touche aux environnements libres, mais fait payer cher tout ce qui touche au propriétaire (genre le déploiement de sondes exchange ou weblogic).
Au final ceux qui font du libre, et uniquement du libre ne seront pas, ou peu, impactés car ils auront les sources, et s'ils prennent du temps (libre => "tu as du temps ou de l'argent?") ils pourront faire ce qu'ils souhaitent. Les autres se fichent bien du libre, ils veulent quelque chose qui marche et c'est tout. Et bien parfait, ils peuvent l'avoir et ce rapidement (genre une VM appliance toute prête), mais faut passer par la case achat.
Tu ne peux pas être totalement ouvert, déjà industrialisé (étonnant pour un outil facilitant l'industrialisation justement non? ;) ), réactif et vivre de ton outil. Tu vas te faire bouffer tout cru. C'est quelque choses que peuvent se permettre les grosses fondations qui sont financées de manières indirectes par ce que produit l'outil (genre HP vend des serveurs, et donc doit faire en sorte que Linux marche bien dessus).
RedHat fait très bien cela. Or tu n'as pas de support ou même accès aux rpm sans avoir déliés ta bourse. Tu peux partir sur CentOS, mais RedHat s'en fiche, car quand tu veux du support "imputable" (en cas de soucis majeur faut pouvoir rejeter la faute sur quelqu'un d'autre dans les grosses sociétés…) tu prends du RH, pas de la CentOS. Ceux qui partent sur CentOS n'auraient de toute manière jamais payés RedHat, donc RedHat n'a rien perdu, même "potentiellement".
Bref, pars à la campagne un jour ou deux, fais le point. Mais je te conseille de ne laisser que les sources de disponible, et que les versions faciles d'installations ne sont disponibles pour de la prod que si tu puisses en vivre. Vires donc tes VM toutes prêtes, elles te font du mal. Tu pourras vivre de ton travail direct : coder! et non pas tenter de vivre d'un moyen indirect genre de la prestation d'installation où tu seras en concurrence quasi déloyale avec des SSII qui vendent n'importe quoi et n'hésitent pas à mentir à leur client!
Bon courage, je comprends parfaitement ce que tu ressens, et que ça te déchire d'en arriver là. Mais mieux vaut qu'une partie du projet soit libre et qu'il continue à vivre, plutôt que tu te crames littéralement et qu'au final ils disparaisse totalement. Penses à comment le business model que tu montes va aider le projet, mais ne t'attends pas à ce que le projet te fournisse naturellement un business model. Est-ce dommage? Oui, car avec des moyens comme le revenu universel, on n'aurait pas besoin d'en arriver là. Mais ça n'est pas en place, et c'est pas demain que ça arrivera, donc on rentre les mouchoirs dans la poche, et on rentre dans le jeu en acceptant les règles à défaut de pouvoir les changer. Tu peux tenter le crownfounding, mais vu le marché, je n'y compterais pas trop (encore moins sur les dons, ça n'a jamais fonctionné pour du dev, et ça ne fonctionnera jamais).
Tu parles de Merethis à un moment (éditeur de Centreon et divers modules sous licences autour de Centreon). Sache qu'ils ont raison. S'ils n'étaient pas passés par ça, il n'y aurait plus de Centreon actuellement vu qu'ils étaient en concurrence sur de la prestation sur leur outil face à de grosses SSII qui faisaient du dumping sur les prix pour juste entrer sur les comptes et vendre ensuite d'autres outils à plus fortes rémunérations.
Bonne chance en tout cas, car c'est une décision très dure à prendre et à assumer. Mais poses-toi la question : combien sont ceux qui vont te crier dessus et qui vivent réellement de leur code (tu es un codeur, pas un formateur ou intégrateur) sur ce marché là en montant leur société? Les râleurs râleront, mais sincèrement, peu importe ce que tu fais, ils râleront quand même, ne les écoute pas et avance.
[^] # Re: Collectd
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 1.4. Évalué à 3.
En effet, un module de Shinken permet de transformer des data lues des nodes collectd en data pour des services Shinken. ensuite ils seront soit transférés aux backend de perfdata (genre PNP ou Graphite), mais certaines données peuvent également être "analysées" afin de vérifier si elles sont bonnes ou pas.
Shinken ne garde pas lui même l'historique et ça ne fait que transiter par lui, donc point de RRDCache dans l'histoire (mais PNP le gère lui par contre à la sortie).
Pour les graphiques, les deux poids lourds restent PNP et Graphite. Je préfère ce dernier car il est possible de le mettre en architecture hautement disponible, même si le rendu des graphiques est très… moche faut le dire :)
[^] # Re: shinken v1.4 et skonf
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 1.4. Évalué à 1.
En fait elle est juste cachée, il est très simple de la réactiver, mais vu qu'on a pas eu de temps pour l'avancer, et qu'on a eu pas mal de posts sur le forums sur "pourquoi ça bug là?" avec très très peu d'aide ensuite, j'ai préféré la cacher afin que seuls des personnes motivées et qui comprennent ce que beta signifie y auront accès :)
[^] # Re: Juste un idée a rajouter sur la pile
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 1.4. Évalué à 2.
En fait c'est déjà possible de le détourner pour ça. Ce qu'il va manquer c'est justement les enchainements entre des actions. Shinken le fait, mais quand ça va "mal", un $U le fait au contraire quand ça va bien. Sinon conceptuellement ça reste lancer des scripts sur certaines périodes de temps bien précises, et les enchainer suivant les résultats :)
[^] # Re: Quelques petites questions
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 1.4. Évalué à 2.
Concernant les outils liés, ce sont surtout tout ce qui est lié aux logs (logstash & co) et des outils de visualisations de graphes (genere PNP4Nagios ou Graphite).
Pour la partie la plus difficile, c'était clairement le calcul correct des périodes de temps, avec des cas un peu tordu genre "le prochain avant dernier mardi de novembre sachant qu'on est en décembre et qu'on a exclu les jours pairs du mois". Faire un algo efficace et complet pour résoudre ça m'a demandé 1 mois complet à l'époque. Certaines autres fonctionnalités n'étaient pas triviales non plus, mais rien d'un tel ordre de complexité :)
[^] # Re: Tutoriel d'installation
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 1.4. Évalué à 2.
Mais de rien :D
[^] # 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 :)