I’m not fond of polling for performance stats. I’d rather have the app report them.
We could integrate existing Jetty monitoring: http://metrics.dropwizard.io/3.1.0/manual/jetty/ <http://metrics.dropwizard.io/3.1.0/manual/jetty/> From our experience with a similar approach, we might need some Solr-specific metric conflation. SolrJ sends a request to /solr/collection/handler as /solr/collection/select?qt=/handler. In our code, we fix that request to the intended path. We’ve been running a Tomcat metrics search filter for three years. Also, see: https://issues.apache.org/jira/browse/SOLR-8785 <https://issues.apache.org/jira/browse/SOLR-8785> wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Nov 14, 2016, at 3:25 PM, Erick Erickson <erickerick...@gmail.com> wrote: > > What do people think about exposing a Collections API call (name TBD, > but the sense is PERFORMANCESTATS) that would simply issue the > admin/mbeans call to each replica of a collection and report them > back. This would give operations monitors the ability to see, say, > anomalous replicas that had poor average response times for the last 5 > minutes and the like. > > Seems like an easy enhancement that would make ops people's lives easier. > > I'll raise a JIRA if there's interest, but sure won't make progress on > it until I clear my plate of some other JIRAs that I've let linger for > far too long. > > Erick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
