[
https://issues.apache.org/jira/browse/SOLR-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222807#comment-14222807
]
Alan Woodward commented on SOLR-4735:
-------------------------------------
I did some thinking on this over the weekend. Here's what I think the API
should look like:
* we use dropwizard metrics: https://dropwizard.github.io/metrics/3.1.0/. This
is the same library I used in the initial patch, moved on a bit.
* each core has its own MetricRegistry
* SolrInfoMBean is replaced by an interface called SolrMetricsProducer, which
has just three methods:
** String getName()
** Category getCategory()
** void registerMetrics(MetricsCollector registry)
* when core.inform() is called with the SolrMetricsProducer, it creates a
MetricsCollector using the name and category, and then passes it to
registerMetrics(). The producer can then add its own metrics as individual
Counter, Gauge, Histogram, etc, instances to the collector. The Core then adds
all these to its MetricRegistry, with appropriate names.
* getStatistics() calls are replaced by a NamedListMetricReporter, as in the
initial patch
* the metrics JmxReporter will have to be extended slightly so that it knows
about corehash values, to make sure that we deal with core reloads correctly.
* CoreContainer could have its own MetricRegistry for any node-wide stats
(things like System/Memory/JVM info - there's a metrics/jvm subproject which
has a bunch of useful stats that we could add here).
This way, all the individual stats are independent, and reporting and
collection are nicely isolated.
I also suggest we bin getSource(), getVersion() and getDocs() as they're
generally left unimplemented, and probably getDescription() as well. And the
Category enum could be replaced with a plain String, to allow plugins to add
their own types.
> 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: Alan Woodward
> Priority: Minor
> Attachments: 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
