[ https://issues.apache.org/jira/browse/SOLR-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729770#comment-15729770 ]
Andrzej Bialecki edited comment on SOLR-4735 at 12/7/16 8:43 PM: ------------------------------------------------------------------ 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 a 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 :) * add other reporter implementations - SLF4J reporter is a low-hanging fruit, and it doesn't bring any additional dependencies. Comments, suggestions, review and patches are welcome! was (Author: ab): 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 a 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, screenshot-1.png > > > 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