Hi Walter, Dmitry, I opened https://issues.apache.org/jira/browse/SOLR-4735 for this, with some work-in-progress. Have a look!
Alan Woodward www.flax.co.uk On 23 Apr 2013, at 07:40, Dmitry Kan wrote: > Hello Walter, > > Have you had a chance to get something working with graphite, codahale and > solr? > > Has anyone else tried these tools with Solr 3.x family? How much work is it > to set things up? > > We have tried zabbix in the past. Even though it required lots of up front > investment on configuration, it looks like a compelling option. > In the meantime, we are looking into something more "solr-tailed" yet > simple. Even without metrics persistence. Tried: jconsole and viewing stats > via jmx. Main point for us now is to gather the RAM usage. > > Dmitry > > > On Tue, Apr 9, 2013 at 9:43 PM, Walter Underwood <wun...@wunderwood.org>wrote: > >> If it isn't obvious, I'm glad to help test a patch for this. We can run a >> simulated production load in dev and report to our metrics server. >> >> wunder >> >> On Apr 8, 2013, at 1:07 PM, Walter Underwood wrote: >> >>> That approach sounds great. --wunder >>> >>> On Apr 7, 2013, at 9:40 AM, Alan Woodward wrote: >>> >>>> I've been thinking about how to improve this reporting, especially now >> that metrics-3 (which removes all of the funky thread issues we ran into >> last time I tried to add it to Solr) is close to release. I think we could >> go about it as follows: >>>> >>>> * refactor the existing JMX reporting to use metrics-3. This would >> mean replacing the SolrCore.infoRegistry map with a MetricsRegistry, and >> adding a JmxReporter, keeping the existing config logic to determine which >> JMX server to use. PluginInfoHandler and SolrMBeanInfoHandler translate >> the metrics-3 data back into SolrMBean format to keep the reporting >> backwards-compatible. This seems like a lot of work for no visible >> benefit, but… >>>> * we can then add the ability to define other metrics reporters in >> solrconfig.xml. There are already reporters for Ganglia and Graphite - you >> just add then to the Solr lib/ directory, configure them in solrconfig, and >> voila - Solr can be monitored using the same devops tools you use to >> monitor everything else. >>>> >>>> Does this sound sane? >>>> >>>> Alan Woodward >>>> www.flax.co.uk >>>> >>>> >>>> On 6 Apr 2013, at 20:49, Walter Underwood wrote: >>>> >>>>> Wow, that really doesn't help at all, since these seem to only be >> reported in the stats page. >>>>> >>>>> I don't need another non-standard app-specific set of metrics, >> especially one that needs polling. I need metrics delivered to the common >> system that we use for all our servers. >>>>> >>>>> This is also why SPM is not useful for us, sorry Otis. >>>>> >>>>> Also, there is no time period on these stats. How do you graph the >> 95th percentile? I know there was a lot of work on these, but they seem >> really useless to me. I'm picky about metrics, working at Netflix does that >> to you. >>>>> >>>>> wunder >>>>> >>>>> On Apr 3, 2013, at 4:01 PM, Walter Underwood wrote: >>>>> >>>>>> In the Jira, but not in the docs. >>>>>> >>>>>> It would be nice to have VM stats like GC, too, so we can have common >> monitoring and alerting on all our services. >>>>>> >>>>>> wunder >>>>>> >>>>>> On Apr 3, 2013, at 3:31 PM, Otis Gospodnetic wrote: >>>>>> >>>>>>> It's there! :) >>>>>>> http://search-lucene.com/?q=percentile&fc_project=Solr&fc_type=issue >>>>>>> >>>>>>> Otis >>>>>>> -- >>>>>>> Solr & ElasticSearch Support >>>>>>> http://sematext.com/ >>>>>>> >>>>>>> On Wed, Apr 3, 2013 at 6:29 PM, Walter Underwood < >> wun...@wunderwood.org> wrote: >>>>>>>> That sounds great. I'll check out the bug, I didn't see anything in >> the docs about this. And if I can't find it with a search engine, it >> probably isn't there. --wunder >>>>>>>> >>>>>>>> On Apr 3, 2013, at 6:39 AM, Shawn Heisey wrote: >>>>>>>> >>>>>>>>> On 3/29/2013 12:07 PM, Walter Underwood wrote: >>>>>>>>>> What are folks using for this? >>>>>>>>> >>>>>>>>> I don't know that this really answers your question, but Solr 4.1 >> and >>>>>>>>> later includes a big chunk of codahale metrics internally for >> request >>>>>>>>> handler statistics - see SOLR-1972. First we tried including the >> jar >>>>>>>>> and using the API, but that created thread leak problems, so the >> source >>>>>>>>> code was added. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Shawn >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> Walter Underwood >>> wun...@wunderwood.org >>> >>> >>> >> >> -- >> Walter Underwood >> wun...@wunderwood.org >> >> >> >>
