[
https://issues.apache.org/jira/browse/SOLR-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15693809#comment-15693809
]
Shalin Shekhar Mangar commented on SOLR-4735:
---------------------------------------------
bq. I share Jeff's concern though that we need to consider how to maintain
metrics that outlive any particular core instance (even core reload events )
Having a reload reset stats is a bad idea. We can provide an explicit API to
reset stats for a node or a core if required.
bq. Perhaps SolrMetricManager should use long-lived MetricRegistry instances
that are managed in SharedMetricsRegistries?
+1
Also see the patch on SOLR-9788 which adds instrumented classes to Jetty that
are managed by SharedMetricsRegistries. The JVM metrics can also be exposed in
a similar way. It currently adds all jetty statistics to a metric registry
named "solr" but we can split them out into multiple ones if needed. I'll
rebase my patch over this pull request.
As far as the pull request is concerned I'd suggest that we rename
SolrMetricManager to SolrCoreMetricManager because it is tied to a single core.
> 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
