[
https://issues.apache.org/jira/browse/SOLR-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729770#comment-15729770
]
Andrzej Bialecki commented on SOLR-4735:
-----------------------------------------
Brief summary of the current state on the branch:
* {{SolrMetricManager}} is now the single central location responsible for
managing instances of {{MetricRegistry}} and {{SolrMetricReporter}}-s.
* plugin configurations are declared in {{solr.xml}}:
{code}
<solr>
<metrics>
<reporter name="foo" group="node, core"
class="org.apache.solr.metrics.reporters.SolrJmxReporter"/>
...
</metrics>
...
</solr>
{code}
* each reporter plugin can be configured so that it's automatically
instantiated:
** for a specific "group" or "registry". These attributes may contain multiple
comma- or space-separated values, in which case the reporter will be
instantiated for each matching group / registry.
** for every registry, when neither "group" or "registry" attribute is
specified.
* reporters are instantiated on component initialization and closed when a
component is closed / shut down. Currently this happens in: {{CoreContainer}}
for {{node}} group, {{SolrCore}} for {{core}} group and in
{{SolrDispatchFilter}} for {{jvm}} group.
* instances of metrics are maintained across core reloads and renames (or
swaps). They are only permanently deleted on core delete.
* {{SolrJmxReporter}} now maintains hierarchy of {{ObjectName}}-s that consists
of the following:
** registry name (split on dots into sub-paths)
** reporter name
** category
** scope
** metric type
** metric name
See the attached JConsole screenshot.
To do, possibly in another issues:
* add metrics for "jetty" and "http" groups.
* add a handler to report all this wealth of information :)
Comments, suggestions, review and patches are welcome!
> 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: [email protected]
For additional commands, e-mail: [email protected]
