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).
On Tue, Jan 28, 2014 at 8:28 PM, Roy Russo email@example.com 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
On Wed, Jan 29, 2014 at 2:42 AM, Ivan Brusic iv...@brusic.com 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.
On Tue, Jan 28, 2014 at 5:33 PM, Mark Walkom ma...@campaignmonitor.comwrote:
Or perhaps something could come from the new cat API if they don't want
to go that route.
On 29 January 2014 12:21, joerg...@gmail.com joerg...@gmail.comwrote:
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
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 firstname.lastname@example.org.
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.