I shouldn't comment about the viability of various revenue generating opportunities since I have no experience in such matters. To me, Marvel seems like a value-add for customers choosing the support subscription. Here is an exclusive software package for signing up. I would be curious to see if many sign up just for Marvel and not the whole kit and kaboodle.
As far as the code goes, it would be nice to see some of it opened up. The publishing of event data should be pluggable for those that might want to add a step before indexing into elasticsearch. Perhaps multiple clusters can publish to redis/kafka which then is read by the actual Marvel cluster. Is the value in the Java side code or the Kibana side? Many of us have managed with compiling metrics in one way or another, but perhaps those metrics are not display with a focus on elasticsearch (mine aren't). -- Ivan On Tue, Jan 28, 2014 at 8:28 PM, Roy Russo <[email protected]> wrote: > > Although I agree with the code transparency in principle, it isn't a sound > business idea. Scaling an OSS company on support/services revenue alone is > very linear and that's not something investors want. You also risk becoming > a consulting company, rather than a software distributor. > > In the end, all successful OSS companies have a commercial component. This > is ES's first stab at it and I think it's a good one. > > > > On Tuesday, January 28, 2014 11:02:50 PM UTC-5, Lukáš Vlček wrote: > >> If my memory serves me well one of the issues with plugins is missing >> classloading isolation. If you have two plugins installed on a single node >> they can clash (we have been hit by this with our own plugins and it took >> us some time to figure it out because the symptom was not deterministic). >> If Marvel contains Java code that is installed as a plugin it would be imo >> useful if the code were a bit more transparent, especially for plugin >> developers. >> >> Regards, >> Lukáš >> >> >> On Wed, Jan 29, 2014 at 2:42 AM, Ivan Brusic <[email protected]> wrote: >> >>> Marvel doesn't different much from elasticsearch plugins in that the >>> code now runs in the same JVM instead of a separate process. The event data >>> is pushed rather than pulled. It is great not having to re-invent the >>> wheel, but having monitoring outside of elasticsearch is not an issue. >>> Great observation about the tribe node BTW. >>> >>> Given that efficient JSON parsing libraries exist in most languages, I >>> rather go that route over the cat API. Time to re-visit monitoring. >>> >>> Ivan >>> >>> >>> On Tue, Jan 28, 2014 at 5:33 PM, Mark Walkom >>> <[email protected]>wrote: >>> >>>> Or perhaps something could come from the new cat API if they don't want >>>> to go that route. >>>> >>>> Regards, >>>> Mark Walkom >>>> >>>> Infrastructure Engineer >>>> Campaign Monitor >>>> email: [email protected] >>>> web: www.campaignmonitor.com >>>> >>>> >>>> On 29 January 2014 12:21, [email protected] <[email protected]>wrote: >>>> >>>>> Marvel comes with hidden Java plugin code for an event pusher. Node >>>>> events, route events, and shard events of ES can be indexed into ES. Very >>>>> useful for historic analysis and post mortem views. >>>>> >>>>> It seems this was also a motivation for the tribe node mode: grow two >>>>> separate clusters, one for the data, another one for the metrics. >>>>> >>>>> It would be nice if also the event pushing source code could be >>>>> opened, so other monitoring tools are able to build on this facility too. >>>>> Or at least documenting the event pushing API, for re-implementing it from >>>>> scratch. >>>>> >>>>> Jörg >>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQADV5z5mVHsZAfSuw%2Bn5kOQ5-V5AcWX%3DWk_2c4wWLf%2BeA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
