You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Andrzej Bialecki (JIRA)" <ji...@apache.org> on 2016/12/02 18:53:59 UTC
[jira] [Comment Edited] (SOLR-4735) Improve Solr metrics reporting
[ https://issues.apache.org/jira/browse/SOLR-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15715931#comment-15715931 ]
Andrzej Bialecki edited comment on SOLR-4735 at 12/2/16 6:53 PM:
------------------------------------------------------------------
bq. Will we be instantiating separate reporters for each `Group` then?
Part of the refactoring I'm working on is moving reporter configs to {{solr.xml}} under {{<solr><metricReporters><reporter name="graphite" group="jvm" class="..."/> ...}} . Then appropriate reporters would be created for each group at the time when the component that manages this group of metrics is initialized (eg. "core" on {{SolrCore}} creation, "node" when {{CoreContainer}} is loaded etc).
Regarding reporters that could take multiple registries ... yeah, it seems a waste to create separate reporters for each core if they have identical configs. I'm not sure yet how to solve this - eg. for JMX reporting any sort of aggregate reporter would have to create multiple {{JMXReporter}}-s anyway, one per registry, because that's how the API is implemented.
bq. it would be nice if we could just specify which registry we'd like a reporter to attach to
Hmm, we could perhaps use either {{group}} or {{registry}} attribute in the reporter config.
(edit: ugh, Markdown vs Jira markup)
was (Author: ab):
bq. Will we be instantiating separate reporters for each `Group` then?
Part of the refactoring I'm working on is moving reporter configs to `solr.xml` under `<solr><metricReporters><reporter name="graphite" group="jvm" class="..."/> ...` . Then appropriate reporters would be created for each group at the time when the component that manages this group of metrics is initialized (eg. "core" on SolrCore creation, "node" when `CoreContainer` is loaded etc).
Regarding reporters that could take multiple registries ... yeah, it seems a waste to create separate reporters for each core if they have identical configs. I'm not sure yet how to solve this - eg. for JMX reporting any sort of aggregate reporter would have to create multiple `JMXReporter`s anyway, one per registry, because that's how the API is implemented.
bq. it would be nice if we could just specify which registry we'd like a reporter to attach to
Hmm, we could perhaps use either `group` or `registry` attribute in the reporter config.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org