We have had success with starting up Jolokia in the same servlet container as Solr, and then using its REST/Bulk API to JMX from the application of choice. On 4 Feb 2014 17:16, "Walter Underwood" <wun...@wunderwood.org> wrote:
> I agree that sorting and filtering stats in Solr is not a good idea. There > is certainly some use in aggregation, though. One request to /admin/mbeans > replaces about 50 JMX requests. > > Is anybody working on https://issues.apache.org/jira/browse/SOLR-4735? > > wunder > > On Feb 4, 2014, at 8:13 AM, Otis Gospodnetic <otis.gospodne...@gmail.com> > wrote: > > > +101 for more stats. Was just saying that trying to pre-aggregate them > > along multiple dimensions is probably best left out of Solr. > > > > Otis > > -- > > Performance Monitoring * Log Analytics * Search Analytics > > Solr & Elasticsearch Support * http://sematext.com/ > > > > > > On Tue, Feb 4, 2014 at 10:49 AM, Mark Miller <markrmil...@gmail.com> > wrote: > > > >> I think that is silly. We can still offer per shard stats *and* let a > user > >> easily see stats for a collection without requiring they jump hoops or > use > >> a specific monitoring solution where someone else has already jumped > hoops > >> for them. > >> > >> You don't have to guess what ops people really want - *everyone* wants > >> stats that make sense for the collections and cluster on top of the per > >> shard stats. *Everyone* wouldn't mind seeing these without having to > setup > >> a monitoring solution first. > >> > >> If you want more than that, then you can fiddle with your monitoring > >> solution. > >> > >> - Mark > >> > >> http://about.me/markrmiller > >> > >> On Feb 3, 2014, at 11:10 PM, Otis Gospodnetic < > otis.gospodne...@gmail.com> > >> wrote: > >> > >>> Hi, > >>> > >>> Oh, I just saw Greg's email on dev@ about this. > >>> IMHO aggregating in the search engine is not the way to do. Leave that > >> to > >>> external tools, which are likely to be more flexible when it comes to > >> this. > >>> For example, our SPM for Solr can do all kinds of aggregations and > >>> filtering by a number of Solr and SolrCloud-specific dimensions > already, > >>> without Solr having to do any sort of aggregation that it thinks Ops > >> people > >>> will really want. > >>> > >>> Otis > >>> -- > >>> Performance Monitoring * Log Analytics * Search Analytics > >>> Solr & Elasticsearch Support * http://sematext.com/ > >>> > >>> > >>> On Mon, Feb 3, 2014 at 11:08 AM, Mark Miller <markrmil...@gmail.com> > >> wrote: > >>> > >>>> You should contribute that and spread the dev load with others :) > >>>> > >>>> We need something like that at some point, it's just no one has done > it. > >>>> We currently expect you to aggregate in the monitoring layer and it's > a > >> lot > >>>> to ask IMO. > >>>> > >>>> - Mark > >>>> > >>>> http://about.me/markrmiller > >>>> > >>>> On Feb 3, 2014, at 10:49 AM, Greg Walters <greg.walt...@answers.com> > >>>> wrote: > >>>> > >>>>> I've had some issues monitoring Solr with the per-core mbeans and > ended > >>>> up writing a custom "request handler" that gets loaded then registers > >>>> itself as an mbean. When called it polls all the per-core mbeans then > >> adds > >>>> or averages them where appropriate before returning the requested > value. > >>>> I'm not sure if there's a better way to get jvm-wide stats via jmx but > >> it > >>>> is *a* way to get it done. > >>>>> > >>>>> Thanks, > >>>>> Greg > >>>>> > >>>>> On Feb 3, 2014, at 1:33 AM, adfel70 <adfe...@gmail.com> wrote: > >>>>> > >>>>>> I'm sending all solr stats data to graphite. > >>>>>> I have some questions: > >>>>>> 1. query_handler/select requestTime - > >>>>>> if i'm looking at some metric, lets say 75thPcRequestTime - I see > that > >>>> each > >>>>>> core in a single collection has different values. > >>>>>> Is each value of each core is the time that specific core spent on a > >>>>>> request? > >>>>>> so to get an idea of total request time, I should summarize all the > >>>> values > >>>>>> of all the cores? > >>>>>> > >>>>>> > >>>>>> 2.update_handler/commits - does this include auto_commits? becuaste > >> I'm > >>>>>> pretty sure I'm not doing any manual commits and yet I see a number > >>>> there. > >>>>>> > >>>>>> 3. update_handler/docs pending - what does this mean? pending for > >> what? > >>>> for > >>>>>> flush to disk? > >>>>>> > >>>>>> thanks. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> View this message in context: > >>>> > >> > http://lucene.472066.n3.nabble.com/need-help-in-understating-solr-cloud-stats-data-tp4114992.html > >>>>>> Sent from the Solr - User mailing list archive at Nabble.com. > >>>>> > >>>> > >>>> > >> > >> > > -- > Walter Underwood > wun...@wunderwood.org > > > >
