To echo what Josh is saying, I keep hoping to prototype something that would include the metrics library from Coda Hale (http://metrics.codahale.com/) my idea was to pick a component, supplement with Coda Hale's library and a REST api in parallel with the current facilities to see how it plays out.
Ed Coleman Arshak Navruzyan wrote: Along these lines curious where and how monitor stores its stats currently. I imagine some of it comes from !METADATA but guessing not all of it does (for example the time series). If there was a clean way to access the stats there is no shortage of powerful and pretty monitoring tools. On May 12, 2014 10:07 AM, "Josh Elser" <[email protected]> wrote: > Personally, I'm not sold on the ability to integrate with an external > tool that will give us adequate functionality as compared to what we > presently have with the monitor (someone prove me wrong). It doesn't > *have* to be pretty -- the monitor is extremely functional already > which is the important part. > > A deployable war would be a big step up, as administrators could > deploy the monitor into existing application servers instead of the > embedded-jetty hack we currently use. > > Moving towards a monitor REST API (instead of baked into servlets) > would also be a big step for external systems to consume Accumulo > information and also allow for better testing. > > Regarding the shell in the monitor, I think it's been there since > 1.5.0ish > -- you just need to enable the monitor to run with SSL. There's a > generate_monitor_certificate.sh script in bin that will generate the > keystore and truststore for you, and also print out the configuration > to add to accumulo-site.xml. > > On 5/12/14, 10:24 AM, Mike Drob wrote: > >> Al, >> >> There's an existing JIRA for packaging the monitor as a war - >> https://issues.apache.org/jira/browse/ACCUMULO-1325 - so that is a >> good place to start. >> >> There's also been some discussion about going the other way - instead >> of building up the monitor we could tear it down and let somebody >> else maintain that code. The benefits are a reduced maintenance cost >> for us, especially on something that is not our forte. As a community >> we know how to make a good distributed storage system... less so on >> how to make a pretty web interface. You can check out >> https://issues.apache.org/jira/browse/ACCUMULO-1013 for more details >> there. >> >> Mike >> >> >> On Mon, May 12, 2014 at 9:53 AM, Al Krinker <[email protected]> wrote: >> >> All, >>> >>> Christopher and I exchanged some ideas during Accumulo Meetup last >>> week about how we can improve Accumulo Monitoring Page... I would >>> like to reach out to the community to flesh out some prototype ideas >>> and to make sure we are not duplication any ongoing efforts that may >>> take place. >>> >>> How do you feel about making Accumulo Monitoring Page a deployable >>> war file? Also, we probably should clean up the current site some >>> more (I noticed that some of the titles are not well alligned). In >>> addition, I am thinking about adding Spring Security to control the >>> access to certain pages. >>> >>> Another idea, would be to provide shell capabilities via web page... >>> For example, a user will be able to select a table from drop down of >>> all available tables, and then then do a simple scan to see the data. >>> >>> Neither Christopher or I use Cloudera, so we are not too familiar >>> with it or its features... and I've heard that Cloudera Manager >>> might already provide some of these features? Anyone can confirm it? >>> Even if it is true, I would still want to add as much capabilities >>> to Accumulo without having to use another tool. >>> >>> Also, Christopher mentioned that Billie Rinaldi (Hortonworks) did >>> add some shell interface to the web page. So hopefully, Billie will >>> be able to pitch in with his ideas. >>> >>> Thoughts? Comments? >>> >>> Thanks, >>> Al Krinker >>> >>> >>
