[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=15761261#comment-15761261
]
Shalin Shekhar Mangar edited comment on SOLR-4735 at 12/19/16 2:16 PM:
---
[~dsmiley] - I didn't know that commits to {{jira/}} branches are skipped by
the commit bot before I created that branch. I figured that since multiple jira
issues will be committed to this branch before we merge it to master, I should
use a more descriptive name such as "feature/metrics". I have opened a ticket
with ASF INFRA to skip notifications for commits on all branches beginning with
{{feature/}} for Lucene/Solr project. See
https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13133
was (Author: shalinmangar):
[~dsmiley] - I didn't know that commits to "jira/*" branches are skipped by the
commit bot before I created that branch. I figured that since multiple jira
issues will be committed to this branch before we merge it to master, I should
use a more descriptive name such as "feature/metrics". I have opened a ticket
with ASF INFRA to skip notifications for commits on all branches beginning with
"feature/*" for Lucene/Solr project. See
https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13133
> Improve Solr metrics reporting
> --
>
> Key: SOLR-4735
> URL: https://issues.apache.org/jira/browse/SOLR-4735
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>Reporter: Alan Woodward
>Assignee: Andrzej Bialecki
>Priority: Minor
> Attachments: SOLR-4735.patch, SOLR-4735.patch, SOLR-4735.patch,
> SOLR-4735.patch, SOLR-4735.patch, screenshot-2.png
>
>
> Following on from a discussion on the mailing list:
> http://search-lucene.com/m/IO0EI1qdyJF1/codahale=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
[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=15742740#comment-15742740
]
Jeff Wartes edited comment on SOLR-4735 at 12/12/16 6:38 PM:
-
I've fallen behind keeping up with your changes, but for what it's worth, I
agree with this. Collection-level metrics are at the cluster level, in
aggregate. It's up to the thing you're reporting the metrics into to do the
aggregation. For example, what I really want on my dashboard in grafana is a
line, something like:
AVG(solr.[all nodes].[all cores belonging to a particular
collection].latency.p95)
Then I can drill into a particular node, or core, in my reporting tool if I
want. There's a requirement that the metrics namespaces being reported allows
for aggregation like this, which might mean a core needs to know the collection
to which it belongs, but I don't think the node itself should needs to report
collection metrics.
was (Author: jwartes):
I've fallen behind keeping up with your changes, but for what it's worth, I
agree with this. Collection-level metrics are at the cluster level, in
aggregate. It's up to the thing you're reporting the metrics into to do the
aggregation. For example, what I really want on my dashboard in grafana is a
line, something like:
AVG(solr.{all nodes}.{all cores belonging to a particular
collection}.latency.p95)
Then I can drill into a particular node, or core, in my reporting tool if I
want. There's a requirement that the metrics namespaces being reported allows
for aggregation like this, which might mean a core needs to know the collection
to which it belongs, but I don't think the node itself should needs to report
collection metrics.
> Improve Solr metrics reporting
> --
>
> Key: SOLR-4735
> URL: https://issues.apache.org/jira/browse/SOLR-4735
> Project: Solr
> Issue Type: Improvement
> Components: metrics
>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=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
[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=15737567#comment-15737567
]
Andrzej Bialecki edited comment on SOLR-4735 at 12/12/16 8:26 AM:
---
There is one important issue that is still unsolved in the current patch -
collecting per-collection metrics at the same time as we collect per-core
metrics. A single instance of Solr can hold multiple shards and / or replicas
that belong to the same logical collection and it would be useful to get
combined metrics at a collection level.
If they weren't needed at the same time, we could probably set up per-core
aliases (using {{overridableRegistryName}} or a similar mechanism) so that a
single per-collection registry would be used for all shards/replicas. However,
since all shards would then modify the same underlying {{Metric}} objects it
would not be possible anymore to separate per-shard metrics from these
aggregates. This is however the simple fallback solution of the problem - allow
either per-core or per-collection metrics and never both.
Codahale API doesn't support aggregation of child metrics - if it were possible
then we could fake the aggregated metrics on the fly when they are needed.
So far the only solution that comes to my mind that allows us to keep both
levels of reporting is to extend {{Metric}} subclasses so that they delegate
their updates to the parent instance(s), something like the following:
{code}
public class ChildCounter extends Counter {
public ChildCounter(Counter... parents) { ... }
public void inc(long n) {
super.inc(n);
for (Counter c : parents) {
c.inc(n);
}
}
}
{code}
I.e. all updates to the child instances would be applied at (nearly) the same
time to parent instances - and parent instances will be referenced by several
child instances from different shards. For example, the {{ChildCounter}}
instance would be registered in "solr.core.collection1_shard1" registry, and
the aggregate counter would be registered in "solr.core.collection1" registry,
and the same aggregate counter would be used by {{ChildCounter}} from
"solr.core.collection1_shard2".
In order to maintain this delegation Solr components would have to always use
{{SolrMetricRegsitry.counter(...), .timer(...), .meter(...), .histogram(...)}}
methods that would set up this delegation, by obtaining metric instances from
the parent registries and returning eg. {{ChildCounter}} instead of a regular
{{Counter}}, {{ChildTimer}} instead of regular {{Timer}} etc.
It's not clear however how to handle in this design shard / replica updates,
eg. split or merge shards, add / remove replica, etc. For performance reasons
the {{Child*}} metric implementations would use direct references to parent
metrics, without having to do a lookup each time the list of parents is
modified - which of course means that the list of parents will get out of sync
pretty quickly in presence of cluster changes...
Any other suggestions?
was (Author: ab):
There is one important issue that is still unsolved in the current patch -
collecting per-collection metrics at the same time as we collect per-core
metrics. A single instance of Solr can hold multiple shards and / or replicas
that belong to the same logical collection and it would be useful to get
combined metrics at a collection level.
If they weren't needed at the same time, we could probably set up per-core
aliases (using {{overridableRegistryName}} or a similar mechanism) so that a
single per-collection registry would be used for all shards/replicas. However,
since all shards would then modify the same underlying {{Metric}} objects it
would not be possible anymore to separate per-shard metrics from these
aggregates. This is however the simple fallback solution of the problem - allow
either per-core or per-collection metrics and never both.
Codahale API doesn't support aggregation of child metrics - if it were possible
then we could fake the aggregated metrics on the fly when they are needed.
So far the only solution that comes to my mind that allows us to keep both
levels of reporting is to extend {{Metric}} subclasses so that they delegate
their updates to the parent instance(s), something like the following:
{code}
public class ChildCounter extends Counter {
public ChildCounter(Counter... parents) { ... }
public void inc(long n) {
super.inc(n);
for (Counter c : parents) {
c.inc(n);
}
}
}
{code}
I.e. all updates to the child instances would be applied at (nearly) the same
time to parent instances - and parent instances will be referenced by several
child instances from different shards. For example, the {{ChildCounter}}
instance would be registered in "solr.core.collection1_shard1" registry, and
the aggregate counter would be registered in "solr.core.collection1" registry,
and the same aggregate counter would be
[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=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}
...
...
{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}
...
...
{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=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
[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=15729770#comment-15729770
]
Andrzej Bialecki edited comment on SOLR-4735 at 12/7/16 8:12 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}
...
...
{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!
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}
...
...
{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, screenshot-1.png
>
>
> Following on from a discussion on the mailing list:
> http://search-lucene.com/m/IO0EI1qdyJF1/codahale=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
[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=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 {{ ...}} . 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 ` ...` . 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=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
[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-tabpanelfocusedCommentId=14222847#comment-14222847 ] Shalin Shekhar Mangar edited comment on SOLR-4735 at 11/24/14 10:10 AM: That sounds like a reasonable start, Alan. Do you have any ideas on how we can introspect/discover metrics supported by a plugin? Also, does the metrics API have any support for merging stats from different servers? The last two questions are important to build aggregate stats API for SolrCloud (see SOLR-6325) and to easily build the next generation of Solr's Admin UI. We should also add stats support to the SearchComponents (maybe as a separate issue). was (Author: shalinmangar): That sounds like a reasonable start, Alan. Do you have any ideas on how we can introspect/discover metrics supported by a plugin? Also, does the metrics API have any support for merging stats from different servers? The last two questions are important to build aggregate stats API for SolrCloud (see SOLR-6325) and to easily build the next generation of Solr's Admin UI. We should also add stats support to the SearchComponents (maybe as a separate issue) and hopefully have the debug component be a wrapper around the metrics API. 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 Following on from a discussion on the mailing list: http://search-lucene.com/m/IO0EI1qdyJF1/codahalesubj=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
