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 > > > >
