[ https://issues.apache.org/jira/browse/SOLR-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15715107#comment-15715107 ]
Kelvin Wong commented on SOLR-4735: ----------------------------------- Hi Andrzej, {quote} I added a notion of "group" of metrics, which corresponds to a top-level subsystem in a Solr node {quote} * Nice! I really like this concept. Will we be instantiating separate reporters for each `Group` then? That way, reporting can be more flexibly configured. (ex. Jetty goes to JMX and Graphite, JVM goes to only JMX, etc...) {quote} I'll look into reusing single global-level reporters when possible, and creating new instances only if there are per-collection overrides. {quote} * It looks like [JmxReporter|https://github.com/dropwizard/metrics/blob/3.2-development/metrics-core/src/main/java/com/codahale/metrics/JmxReporter.java#L701] takes only one `MetricRegistry` at a time (and [GraphiteReporter|https://github.com/dropwizard/metrics/blob/3.2-development/metrics-graphite/src/main/java/com/codahale/metrics/graphite/GraphiteReporter.java#L145], etc. for that matter). Will we need to build some sort of `AggregateMetricRegistry` to join each core's registries? Or do you have something else in mind? * On a separate note, it would be nice if we could just specify which registry we'd like a reporter to attach to. So for example, we can attach one reporter to `collection1`, another to `zookeeper`, and one more to `jvm`. These are at different levels in the metrics hierarchy but perhaps we can just pass in the registry's name as part of the config for a reporter? > Improve Solr metrics reporting > ------------------------------ > > Key: SOLR-4735 > URL: https://issues.apache.org/jira/browse/SOLR-4735 > Project: Solr > Issue Type: Improvement > Reporter: Alan Woodward > Assignee: Andrzej Bialecki > Priority: Minor > Attachments: SOLR-4735.patch, SOLR-4735.patch, SOLR-4735.patch, > SOLR-4735.patch > > > Following on from a discussion on the mailing list: > http://search-lucene.com/m/IO0EI1qdyJF1/codahale&subj=Solr+metrics+in+Codahale+metrics+and+Graphite+ > It would be good to make Solr play more nicely with existing devops > monitoring systems, such as Graphite or Ganglia. Stats monitoring at the > moment is poll-only, either via JMX or through the admin stats page. I'd > like to refactor things a bit to make this more pluggable. > This patch is a start. It adds a new interface, InstrumentedBean, which > extends SolrInfoMBean to return a > [[Metrics|http://metrics.codahale.com/manual/core/]] MetricRegistry, and a > couple of MetricReporters (which basically just duplicate the JMX and admin > page reporting that's there at the moment, but which should be more > extensible). The patch includes a change to RequestHandlerBase showing how > this could work. The idea would be to eventually replace the getStatistics() > call on SolrInfoMBean with this instead. > The next step would be to allow more MetricReporters to be defined in > solrconfig.xml. The Metrics library comes with ganglia and graphite > reporting modules, and we can add contrib plugins for both of those. > There's some more general cleanup that could be done around SolrInfoMBean > (we've got two plugin handlers at /mbeans and /plugins that basically do the > same thing, and the beans themselves have some weirdly inconsistent data on > them - getVersion() returns different things for different impls, and > getSource() seems pretty useless), but maybe that's for another issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org