[
https://issues.apache.org/jira/browse/SOLR-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15693036#comment-15693036
]
Kelvin Wong commented on SOLR-4735:
-----------------------------------
Thanks Jeff.
The attached patch really just piggybacks off of Alan's work and tries to flesh
out the design. For now, only RequestHandlerBase exposes metrics through this
framework. The idea is to eventually convert other SolrInfoMBeans into
SolrMetricProducers so they can start providing reportable metrics too. This
seems to be fairly doable.
Re SharedMetricsRegistries: that's something we can definitely do. My rationale
for not using it is so that logical groups of metrics can be nicely isolated at
a per-core level. This ensures that any metric in a MetricManager's registry
must have been registered through MetricManager::registerMetrics. A nice
side-effect is that we can also store meta-information about each metric and
pass that on to the reporters.
I realize that using SharedMetricsRegistries provides a level of flexibility
that this patch's approach does not. For example, if we wanted to share the
registry on a CoreContainer level. I think there are ways around this and my
personal preference is still for this logical grouping of metrics. But perhaps
there may be use cases I'm neglecting to consider?
Would be interested to hear your thoughts on this. Thanks!
> 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,
> 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
