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?
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 :)
[^] # 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 :)
[^] # 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 :)