I'd argue refactoring the monitor to fit inside of Ambari, in addition
to whatever else, would be the ideal way to go. But that's why we can
"summit" together :P
On 01/28/2013 12:20 PM, John Vines wrote:
I think shifting all monitoring tools to something like Ambari would be the
best route to go. It offloads a majority of our development onto another
project while still providing monitoring, but also provided a command and
control interface.
On Mon, Jan 28, 2013 at 12:03 PM, Josh Elser <josh.el...@gmail.com> wrote:
A big concern with the monitor has always been data spillage due to tablet
split points being only base64 encoded.
Perhaps wrapping the currents calls with some authentication would make the
current monitor more extendable in addition to the ease of other monitor
processes being created.
Regardless, yes to think about the monitor :)
On Monday, January 28, 2013, Jim Klucar <klu...@gmail.com> wrote:
I think new monitor features could use a whole separate discussion. Being
able to do everything from the browser implies an officially supported
webservice of sorts.
Seems like monitor upgrades should be on the list though.
On Mon, Jan 28, 2013 at 10:46 AM, David Medinets
<david.medin...@gmail.com>wrote:
How about letting users see and restart processes from the Monitor page?
Splitting on tablet record count as well as tablet size?
