lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kelvin Wong (JIRA)" <>
Subject [jira] [Commented] (SOLR-4735) Improve Solr metrics reporting
Date Fri, 02 Dec 2016 13:19:58 GMT


Kelvin Wong commented on SOLR-4735:

Hi Andrzej, 

I added a notion of "group" of metrics, which corresponds to a top-level subsystem in a Solr
* 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...)

I'll look into reusing single global-level reporters when possible, and creating new instances
only if there are per-collection overrides.

* It looks like [JmxReporter|]
takes only one `MetricRegistry` at a time (and [GraphiteReporter|],
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:
>             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:
> 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|]] 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message