I am sure there will be more than a few bugs to work out. Not bashing
their great work, that is how software works.
Creating a new 0.90.10 instance right now. I have been pushing to upgrade
for a while (no rolling restarts makes it harder to schedule upgrades),
perhaps this would be the time.
My current code is not compatible with 0.90.10, so I will try again in the
future. Still, great job. Couldn't convince the higher ups to use SPM, but
perhaps self-hosted Marvel might be easier (although I wish the pricing was
more transparent).
--
Ivan
On Tue, Jan 28, 2014 at 3:09 PM, Ivan Brusic ivan@brusic.com wrote:
I am sure there will be more than a few bugs to work out. Not bashing
their great work, that is how software works.
Creating a new 0.90.10 instance right now. I have been pushing to upgrade
for a while (no rolling restarts makes it harder to schedule upgrades),
perhaps this would be the time.
I've made a few changes to the way the the indexes are handled with this,
which I've been meaning to properly fork and push back up. It'd be great if
anyone else could look at what can be done with it if they are interested.
On 29 January 2014 11:08, Ivan Brusic ivan@brusic.com wrote:
My current code is not compatible with 0.90.10, so I will try again in the
future. Still, great job. Couldn't convince the higher ups to use SPM, but
perhaps self-hosted Marvel might be easier (although I wish the pricing was
more transparent).
--
Ivan
On Tue, Jan 28, 2014 at 3:09 PM, Ivan Brusic ivan@brusic.com wrote:
I am sure there will be more than a few bugs to work out. Not bashing
their great work, that is how software works.
Creating a new 0.90.10 instance right now. I have been pushing to upgrade
for a while (no rolling restarts makes it harder to schedule upgrades),
perhaps this would be the time.
I've made a few changes to the way the the indexes are handled with this,
which I've been meaning to properly fork and push back up. It'd be great if
anyone else could look at what can be done with it if they are interested.
On 29 January 2014 11:08, Ivan Brusic ivan@brusic.com wrote:
My current code is not compatible with 0.90.10, so I will try again in
the future. Still, great job. Couldn't convince the higher ups to use SPM,
but perhaps self-hosted Marvel might be easier (although I wish the pricing
was more transparent).
--
Ivan
On Tue, Jan 28, 2014 at 3:09 PM, Ivan Brusic ivan@brusic.com wrote:
I am sure there will be more than a few bugs to work out. Not bashing
their great work, that is how software works.
Creating a new 0.90.10 instance right now. I have been pushing to
upgrade for a while (no rolling restarts makes it harder to schedule
upgrades), perhaps this would be the time.
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.
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.
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.
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.
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 ivan@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.
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.
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 <iv...@brusic.com<javascript:>
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.
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.
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).
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 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.
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.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
Not bashing